Apple ][ Graphics – !Change is !bad (It’s alive!)

Reading about odd/even frames and bytes was pretty, well, confusing at the beginning.  Took me a few times to get through it and experiment, but I figured it out.

Firstly, there are two choices:

  1. Move one pixel at a time, which really turns into only moving every other cycle.
  2. Move two pixels at a time, which actually looks okay.

There really is no way to move 1 pixel and not change colors which, looking back (again), makes total sense.

Secondly, I figured out the odd/even frames and bytes logic.

In the book, he generates frames at bit shift of 0, 2, 4, 6 as frames 0, 1,  2, and 3 then generates frames at bit shift offset of 1, 3, and 5 as frames 4, 5 and 6.  Which means show even offset frames in even bytes and odd offset frames in odd bytes.  The tricky part is right at the middle of the frames at frame 3.

If we plot this out over 14 shifts (enough to get through both an even and odd byte)

  • X = 0/1 we show frame 0 (even byte, even offset frame)
  • X = 2/3 we show frame 1 (even byte, event offset frame)
  • X = 4/5 we show frame 2 (even byte, event offset frame)
  • X = 6/7 we show frame 3
    • Except 7 is in the odd byte, but if we move it to the first odd frame 4) then we show frame 3 for 1 cycle and show frame 4 for 3 cycles.
    • And we can’t put an even offset frame in an odd byte or the color will change.
    • The fix is that for X = 7, we actually just do X = 6 again.  Put frame 3 in the even byte
  • X = 8/9 we show frame 4 (odd byte, odd offset frame)
  • X = 10/11 we show frame 5 (odd byte, odd offset frame)
  • X = 12/13 we show frame6 (odd byte, odd offset frame)

Not sure that made it any clearer, maybe some code will.  I have a lookup table that you index into with your X value and you get back byte # and frame #.  Unlike the book, I generate the frames in bit-shift order to keep even/odd consistent between byte, offset and frame #.


char xToByteFrame[280][2] = {
{ 0, 0 },
{ 0, 0 },
{ 0, 2 },
{ 0, 2 },
{ 0, 4 },
{ 0, 4 },
{ 0, 6 },
{ 0, 6 },
{ 1, 1 },
{ 1, 1 },
{ 1, 3 },
{ 1, 3 },
{ 1, 5 },
{ 1, 5 },
...


Notice there are 8 entries that update byte offset 0 and 6 that update byte offset 1.  The second { 0 , 6 } handles the fix for X = 7.Screen Shot 2016-03-18 at 11.58.30 PM

You can see that we have 2 at each X off set.  This is a move from 0-13 moving by 1 pixel.  I put each frame below the previous one for comparison.

Here is the final product of the little monster man moving across the screen.  I opted to move 2 pixels at a time, I could have halved the delay between moves and moved by 1 but why copy unneeded data around.

Here is my main() code.

Screen Shot 2016-03-19 at 12.17.04 AM

putImage() takes care of figuring our what frame needs to be displayed based on the X value passed in.

More progress In the right direction.

Leave a Reply

Your email address will not be published. Required fields are marked *