• Please review our updated Terms and Rules here

Understanding HGR mode is driving me insane

I was not sure how much this software would let a guy write first thing out the gate, so I am using two comments to be safe.

Back to graphics!

Remember that bitfield and color clock relationship:

CC CC CC C C CC CC CC
PP PP PP P P PP PP PP
8192 8193

S bits ignored as they do not create pixels, just affect them.

And now I come to the final positive! I really like Apple graphics despite their crazy nature and limitations, and I like the Apple graphics because they deliver good color without sacrificing resolution.
I explained all I did about DMA and bytes per line and what not because I wanted to make a subtle, but important point about COLOR RESOLUTION.

The Apple has a 280x192 screen at all times. There is no "4 color" mode that cuts resolution in half to deliver more colors. Instead, there are just pixels and colors.

Try this: Set your HCOLOR = 7. This is basically "white" and it will set any pixel you want to be on. Using other HCOLORS is like a mask. The Apple will only set those pixels associated with a given color, ignoring others. This is nice, but also more confusing at this stage. We just need to turn any pixel we want on or off. HCOLOR = 7 does that.

Now, HPLOT 0,0 and you will see a single, blue pixel. (that is if you do it from a cold boot to insure the high bits are in the same state I am assuming right now.

That's a single, blue pixel. On a good display, it will look half the size of the usual 2 bpp type pixels seen often.

Now HPLOT 2,0 and 4, 0, and 6, 0, and then skip one and do 10, 0 to get another single blue pixel.

Try the same with odd pixels, say on line 5 to see things clearly:

HPLOT 1, 5 3, 5 5, 5 and then 9, 5 to get a single one again.

Now, on those two lines, you can unset any pixel you have set to get black, and you can set an additional one, even and odd together to get white.

The rules are then:

Two sequential unset pixels are black. Two set sequential pixels are white. A single even or odd pixel will be one of two possible colors given the state of the S shift bit.

This is different from a simple 2bpp display. THere can be details not possible on a display with half the resolution and it's this point that makes Apple 2 graphics as flexible as they are! Many patterns are possible to give the illusion of more colors and it's all quite a bit more robust than one might expect at first glance. The game art out there shows it all off pretty well.

So goes the "Total Replay" start screen.

Now, back to that 2 byte group bitfield:

CC CC CC C C CC CC CC
PP PP PP P P PP PP PP

Say we want red. That's an odd pixel, with the S shifter bit set to zero.

We do this, just set every "even" bit, right?

CC CC CC C C CC CC CC
01 01 01 0 1 01 01 01

And blue:

CC CC CC C C CC CC CC
10 10 10 1 0 10 10 10

And there is another rule!

Any 01 or 10 combination will produce a single color pixel, unless it's adjacent to another such combination, in which case the color will fill in to form a "full" or "bigger" pixel!

01 01 01 = a red bar, assuming S bit is 0

01 00 01 = two red dots!

Try it:

HGR to clear it all

HCOLOR = 7

HPLOT 1, 0 and then 5, 0 followed by 3,0

You get a red dot, then another one, then a single red bar.

Next comment
 
Lets flip that S bit!

HCOLOR = 3 This color requires S = 1 where the other one required it be 0.

HPLOT 0, 0

What happened!

We are now seeing the color clash, and even better:

HPLOT 9, 0
HPLOT 7, 0

We get GREEN now!

The Apple has to switch the S bit in any byte it tries to draw HCOLOR 3 in. Gets messy real fast.

Now, I am going to stop there. More rules have appeared, but they are pretty simple:

All the bit pattern and resolution stuff remains the same. The difference is which colors get seen.

I hope this helps.

When I do Apple graphics in machine language, not just plotting dots in BASIC, I think of it like 20, two byte, 7 pixel strips! (Sort of!) Really, it's 14 pixels that can form many shapes that may or may not look like 7 colored pixels, depending. Remember the rules!

When I am on an Atari, I think of it as 40, one byte, 4 pixel strips.

On the Atari, just as an example I know well, the rules are actually similar!!

Any 00 combo is the background color
Any 11 combo is the foreground color
Any 10 or 01 combo will be a single, high res pixel, unless it's next to the same combo, in which case it all fills in.

And, of course the Atari has no S bits meaning there are just the two artifact colors. But it can do other things, no worries. I'm just wanting to highlight Apple 2 graphics, which are very interesting to me, not for competing reasons, more like pixel are reasons.

I'll stop now. Wait a bit.
 
I lied!!!

What you should do at this point, is get an emulator and plot the dots with me. Use PEEK and POKE to look at the screen bytes 8192, 8193 and maybe 8194 and 8195, if you want to. Those numbers will tell you which bits are set and where in the bytes they are set.

You can then draw a chart like I have been doing and get it exactly right!

Here is a quickie:

HGR to clear

HCOLOR = 7 so we know S bit is 0

HPLOT 0, 0

Print Peek( 8192) : Print Peek (8193)
129 and 0

!!!

8192 = %1000_0001

I HAVE HAD THAT $#@@#$^(*&# S BIT WRONG THE WHOLE TIME!!

LOL

That is what I get for jumping in by memory. I won't edit my posts. They show the technique by which I came to understand Apple 2 HGR graphics perfectly.

And notice that S bit in the adjacent byte is 0, until we put a dot there with HCOLOR = 7.

Go ahead, try it.

Also, notice one other thing? The pixel bits are written to the graphics screen in reverse order. Least significant bit of screen byte zero is at position zero! I had forgotten about this.

So, here is what that means and you can check me with HPLOT and friends:

Byte 8192 = S PPPPPPP Right?

Starting at Zero, S is read first, then the least significant bit is pixel 0 in the X, next significant bit is pixel 1, and so on.

Let's number the bits just to beat this into the ground solid:

S 654 3210

Bit 7 is the S bit, bits 0 - 6 are pixel bits. Here is what happens:

S 0123 456

And:

CC CC CC C C CC CC CC
01 23 45 6 ???

HPLOT 7, 0
print peek(8193)
129

Same pattern!!

CC CC CC C C CC CC CC
01 23 45 6 0 12 34 56

And there we are at the bottom of this rabbit hole.

Now I'll stop for a bit and see where all this leads and whether I did any good or not maybe just adding to the confusion!!
 
HEY! Is this the same potatohead from the Parallax forums?? If so, you really should write a book.
You have helped me more times than I can count. Thank you so much for coming over here.

I see you have several posts in a row. I'm going to copy them all out and read them over and over. I've already read through one and it has helped me tremendously. You always had a way of explaining things in a very clear format.

potatohead said:
And the library of games proves all that out nicely enough in my book.
Click to expand...


**EDIT**
Oh, sorry, you meant the phrase "in my book". LOL. I read that as if you did write a book. Of course if you did, I would buy it. :-)


Thanks again! Now let me read through these. I just had to reply quickly to see if it was you. But either way, extremely helpful!
 
Yeah, I've not written a book, though I believe you may be right! I should.

It's me! LOL

Your posts were timed SPOT on. I just scored an Apple //c + in the local thrifty and had just powered it up, connected a FujiNET and was searching for some related info when I saw your name and the post title, LMAO!

I absolutely had to make an account. And I've helped mostly because you tend to do the sorts of things I tend to know something about. It works for us. No worries here.

What I put here is long, but it's my own personal method for sorting stuff like this out on older machines where they permit such ways. I bet it gets you there, but if not, post up and we will see what happens. I literally had the machine on my lap, ready to go. Figured why not? I can re-discover how that all works and just leave the post for others to make use of when I don't have an Apple computer in my lap.
 
I knew it had to be you. :)

Wait, you got a IIc+ from a thrift store? That's amazing. I have two IIc's but they are the normal ones. However, they have been upgraded. One of them came with an internal Z80 card with 512K of RAM that the seller didn't know was in there (nice little surprise) and the other has an internal Mockingboard clone. Great little machines. I bought them both but my last two computers were quite an amazing find. I found a C64 breadbin in the local recycle dumpster along with a 1541. Works great and amazing shape. Manager said I could have them. A month later, I found a C128 with 1571 in the same dumpster! Got those for free and they look amazing too. I kept going back to see if I could find an Amiga. lol. But no such luck.
 
Last edited:
I am envious of your 128! That is one 8 bit machine I've never spent much time with and after hearing Bil Herd talk about the development of it, I want one!

But yeah full on found it in a Goodwill BIN store. One key was snapped off, and it was right there in the bin. Easy fix. Seems to me it works great. I've got to pull the covers and see just what is in the thing, and run a floppy. Haven't done that. It's a 3.5, and I've got a couple, but need to get disk images and the like lined up.

FujiNET worked great! I have been running one on my Atari, and of course it's total amazeballs! The Atari has device independent I/O, the early ancestor of USB in ROM. FujiNET on that thing is as integrated as any peripherial back in the day could have been. And it provides a few new drivers, N: being the best one. Network... Love it.

I must say, the Apple experience was very good, and it brings CP/M and PLATO to the Apple right along with SD cards holding various images. Spiffy!
 
The funny part is that about two weeks before I found the free C128, I bought a really orange, non-working C128 off eBay for about $160 shipped. I knew it was pricey but I wanted another C128. Then I find one that is in pristine condition that works. lol
 
.
I have had similar things happen to me before too. It's disquieting and kind of neat all at the same time. Would have been nice to hit on the cheaper path, but it's nice to get the machine and be in a position to use it and have fun right away too.

By the way, I never thanked you for this:

I've already read through one and it has helped me tremendously. You always had a way of explaining things in a very clear format.
Click to expand...

Back in the 90's, when I had stepped away from most of this stuff, the giants at that time were early home brewers making software run anywhere they could. Game systems, computers, even appliances!

Those people seem like they are on another plane of existence! So good, right?

Some of them were helpful to me, and in particular when I revisited the Parallax forums, I was struck by the sheer brain power there and Chip in particular as we became friends. He and some others never let me feel out of place or behind all while explaining pretty much anything I needed. Baggers and a few others too.

When I can I like to give back, and for you to write what you did is great! Means I maybe hit the mark.

And I also think this era of tech remains one of the better ways to learn this stuff. I've helped and been helped right into doing some pretty complex modern day stuff all boot strapped from these skills.

Anyhow, thank you. Made my day.
 
Last edited:
You're welcome. I like to help out when I can as well. This week has been tough so I hope to get back on the emulator this week. I have lots of stuff working so I'm excited to load up that first disk.
 
A couple notes about the half dot shift.
1) A shifted byte has its last bit truncated in half when followed by a byte that is not shifted.
2) A non-shifted byte has its last bit extended by half when followed by a byte that is shifted.
You need a real Apple II to see how the left and right edge of the display is handled.
The left edge is black so probably a shift in the first byte extends the black by half a bit.
But for the right edge, does a shifted bit in the last byte get truncated in half?

Here's a couple recent threads on the subject of HGR:
https://tinkerdifferent.com/threads...dgr-and-dhgr-image-files-in-the-apple-ii.3534
https://68kmla.org/bb/index.php?threads/apple-iie-card-an-apple-iie-inside-my-macintosh-lc475.49836

I wonder if the 560-bit stream can be converted to RGB using a pixel shader that implements the algorithm mentioned at:
https://tinkerdifferent.com/threads...r-image-files-in-the-apple-ii.3534/post-33233
I've never created a pixel shader before so I don't know. I suppose if it can work then it could also operate on the original 320 bit stream of HGR.
 
This is an interest subject, since I had "unintended" colours from a hires IBM CGA plasma demo I wrote (discussed elsewhere here). But users in the UK and Europe never see these effects because there are no NTSC monitors here, which is a downside of that method. Possibly one reason why the A2 didnt do so well here?

Back then, I had thought that the pixels simply had fixed colours RGB depending on pos, and you made colours by dithering. Is that the case for rev0 A2s?

One little point mentioned by PH: the C64 can run without DMA pauses if you run in full hires mode - the DMA "badlines" are caused by UDG/Text mode having to grab 40 chars for the next text line. The 2114 colour ram has its own data bus direct to the VIC2 chip.

I know this because back in the day I designed and sold a Vic20 to ZX-Printer bitbanged interface ("Printerface"), and couldnt work out why it didnt work on the c64! The solution was to blank the video, like the tape routines.
 
Last edited:
Apple II color is generated not by the pixel value itself (0 or 1) but rather by a transition between neighboring pixels where one of them is 1 and the other is 0. Depending on how this transition is aligned with the NTSC color burst, a specific color is generated. Because color bandwidth is lower than luma bandwidth, generated color spreads to the couple of neighboring pixels (producing solid color instead of vertical bars, but sometimes these color stripes can be visible). For the Lo-Res graphics, it is sufficient to assume the whole block is one color, but for Hi-Res, NTSC must be at least somewhat emulated to produce correct colors. It is easier to generate a monochrome image and convert it to the color one instead of emulating color image directly.
I've seen two articles which describe Apple II artifact color in detail:
nerdlypleasures.blogspot.com

Apple II Composite Artifact Color - NTSC, PAL and Filters

Vintage computers and retro gaming
nerdlypleasures.blogspot.com nerdlypleasures.blogspot.com
www.xtof.info

HIRES Graphics on Apple II

In 1977, the Apple II was the very first personal computer providing color graphics capabilities with its LORES and HIRES modes. This feat was achieved in a very clever, but peculiar way.
www.xtof.info www.xtof.info
 
You must log in or register to reply here.
Back
Top