AppleSoft BASIC HPLOT issue

[Subvoltic]

Can anyone tell me why the following code does not produce the expected result? I am trying to draw a 30-point circle, but half is missing. Using INT produces the same result, also some of the pixels seem to be half width somehow...

   10  HGR
   20  HCOLOR= 6
   30  FOR C = 0 TO 29
   35    R = C * 3.14159265 / 15
   40    X = 140 + 60 * COS (R)
   50    Y = 96 + 60 * SIN (R)
   55    PRINT X;:
         PRINT " ";:
         PRINT Y
   60    HPLOT X,Y
   70  NEXT C

 

[inexorabletash]

Hires colors on the Apple II are created by alternating on/off bits that NTSC interprets as color. If you plot a horizontal line with something other than black or white it'll be an alternating bit pattern.

HPLOT X,Y modifies a single bit in screen memory. Since blue alternates on/off bits depending on whether X is even or odd it will set a bit to 1 or 0. Since the screen is filled with black, if it's a 0 there will be no change and nothing appears.

Try HPLOT X,Y TO X+1,Y which will guarantee that two bits are modified which will be enough to produce blue dots.

(This is overly simplified, but you gotta start somewhere.)

 

[Subvoltic]

Yes, that did work as you described and I appreciate the help. This however is quite odd as nothing in the AppleSoft BASIC manual indicates that this is not the intended functionality of HPLOT. It simply states that you can set any HGR coordinate to the HCOLOR by just using HPLOT X,Y. How was I supposed to know that is not the case? Is X: 0-279 not the actual X axis resolution? Is there recommend documentation I should be following that isn’t the official manual?

 

[inexorabletash]

Apple II graphics are so weird you could write an entire book about it. Manuals "back in the day" didn't know what people would do and what they should explain. I don't remember any introductory manuals that explained this well. You could dive into something like "Understanding the Apple II" by Sather but that's kind of like jumping from grade school to a graduate degree, unfortunately. In the 1970s/80s you just... played around and tried things until you understood.

The simplest explanation is that Apple II graphics are fundamentally 560x192 monochrome. Everything else is an approximation. The color patterns give a color resolution of about 140x192 when viewed on an NTSC monitor. Single-hires graphics is approximately 280x192 monochrome - you can plot white and black dots with that resolution, which are two of those fundamental 560 units wide. Color emerges from the alternating patterns. It gets really wacky when you use blue and orange... those not only generate alternating 280x dots by setting bits, but also set an invisible 8th bit in the byte (you see, only 7 bits in every byte are visible...) that shifts the byte's dots by half a hi-res 280x unit or one fundamental 560x unit.

If your head is spinning... that's why books didn't try to explain this.

 

[Subvoltic]

Wow that is some great info, thank you. So if I want to utilize all colors in HGR mode I need to treat the screen as if it is only 140x192? How do I use Hi-Res monochrome mode? Or is just simply using only HCOLOR 0,3,4 or 7? I will also assume that using Lo-Res mode is much simpler.

 

[george]

The simplest explanation is that Apple II graphics are fundamentally 560x192 monochrome.

This is Apple ][e and later models double hires, not Apple ][ HGR, which is supported by AppleSoft BASIC.

 

[inexorabletash]

This is Apple ][e and later models double hires

While a true 560x192 monochrome addressable display is only present with DHR on the IIe and later, everything on every Apple II's display is fundamentally 560x192 monochrome. Including lo-res and text.

Consider at the display of this in monochrome:

HCOLOR=1 : HPLOT 0,0 TO 279,0
HCOLOR=5 : HPLOT 0,1 TO 279,1

If you look closely, the half-pixel shift on the second line reveals that the display is ultimately decomposed into 560 units across. It's true that individual 560 unit elements are usually not addressable without DHR on the IIe and later, but half-shifted bytes reveal their presence. Add this to the mix in addition to the lines above:

HCOLOR=6 : HPLOT 6,2

This produces a "pixel" half as wide as normal hi-res "pixels" - and it's exactly 1/560th of the width of the screen! This is because it turns on a bit in a byte with the half-pixel shift turned on, but the subsequent byte does not have the half-pixel shift turned on, so it is truncated.

Lo-res colors are also produced with patterns that vary at 560 units across the screen within the large 40x48 blocks. These are the same 16 distinct patterns that in DHR on the IIe and later you can use to produce arbitrary colors approximating 140x192 resolution using the complex aux/main and 7-pixels-per-byte memory scheme.

to utilize all colors in HGR mode I need to treat the screen as if it is only 140x192

Sort of, but it's even more complex than that. Try this:

HCOLOR=1 : HPLOT 0,3 TO 1,3
HCOLOR=2 : HPLOT 2,3 TO 3,3

If you're thinking about the screen as 140x192 pixels, that should be a green pixel next to a purple pixel, right? Nope - you get a short white "pixel". Why? Because you've lit up two hires dots on the screen next to each other. Two hires dots are four 560 units, and four 560 "on" units anywhere on a line are interpreted by NTSC as white.

So 140x192 is the maximum color resolution you can expect, but you are not just using a weird scheme to address 140 distinct pixels.

 

[potatohead]

I just typed in your program and it worked perfectly giving me a nice circle. I made a few changes on the way through and I chose:

11 PI=3.14159

I seem to recall it will run faster using a constant.

20 HCOLOR=7

I did this so I would see all the pixels. I very strongly suspected the masking that happens with color graphics statements on the Apple HGR screen were hiding most of your pixels. And that was true!! Using HCOLOR 7 meant I would see all the dots, and they would be red or blue depending on their position.

35 R = C * P1 / 15

I also simplified line 55 to be:

55 PRINT X;" ";Y

Your program would work just fine with only HCOLOR = 7 being changed. I suggest you run it that way and look at the pixels.

I've got a post explaining how the graphics work, made just a couple days ago. I actually disagree on 140 pixels being the full color resolution. It's actually better than that, in terms of detail possible to display on screen. But, I also agree with the other users explanation and that in terms of positioning things, showing motion, etc... 140 is the number to use.

FInally, I have a low resolution TV that is kind of neat. It ignores interlaced displays and it's circut seems to quantize things down to an NTSC color clock, and there are 160 of those in the active display area, and the Apple can address 140 of them, due to the width of it's screen display and how the graphics addressing is all setup.

Photos in next post:

 

[potatohead]

Here are images from that low resolution television. It has a little 5" color CRT with just enough of a fine pitch on the mask to make 160 horizontal lines of detail work. Despite it being a composite signal input, this TV does not show dot crawl on those signals that would make it present.

I have two pictures, one with:

HPLOT X, Y: HPLOT X+2, Y

and one with:

HPLOT X, Y TO X+2, Y

This TV basically blends pixels together giving one close to 140 pixels of resolution.

The three pixel solution (x, y to x+2, y) looks different than the two pixel solution does.

The colors stay more true to form with two set pixels separated by an unset pixel. Basically, one gets blue or orange depending on the coordinates.

 

[potatohead]

On the high resolution TV, I present a quick color study along side a run of the circle program using the two set pixel solution rather than the 3 set pixel one.

The color study shows an ability to add color detail at twice the resolution one would expect of a 140 pixel machine.

The same shape is drawn using 140 pixel resolution just to compare. Note the inverted one too.

Artifact graphics on this machine are both weird and wonderful at the same time. I love the art possible.

Please ignore the little micro pixels you see right below the real ones. That is a display artifact unique to my particular display type. Those have nothing to do with apple graphics.