(This post was repurposed and embellished from my FaceBook post).

Well, more baby steps. Did a bunch of reading in the arcade book about bitmap images and rendering. Learned a lot.

Realized I need 7 shift frames for each bitmap I want to move around since 1 byte in hi-res is 7 pixels.  That is because the expense to calculate the image shift of the fly will be complex and costly.  Remember, with the 7-bits and a high bit for color control (g/v vs b/o) you can’t simply shift each byte by one bit and be done.

112u8a

That’s because the high bit needs to be left alone so it doesn’t change color, so the 7th bit needs to moved the low bit of the next byte (if shifting right), etc.  Not to mention doing this EVERY time.

Time for graph paper? Umm, no… If necessity is the mother of invention, then laziness is the father. I wrote a tool to draw my bitmaps and added code to generate each of the 7 shifts.  Needs some cleaning up, but it works great.

Features:

  • Drawing the bitmap (duh)
  • Buttons to manually shift left/right
  • Button to clear
  • Generarates output data in textarea boxes. (C array for main frame, JSON for loading/unloading, C array for all frames).  These are updated in real-time.

 

The video shows my bitmap tool, the build pipeline in Xcode and the results running.

Proof is in the pudding they say. So, without further ado, the pudding.

Moving something around the screen needs to be fast, and drawing each line pixel by pixel isn’t going to cut it.  This is where bitmap graphics comes in.  Basically, drawing out the pictures pixel by picture before hand, keeping it in memory then copying it to the write spot on the screen for each frame of the movement.

We can do this with block moves over data, but can only move blocks of sequential data.  Each line (even if they were in sequential order on the screen) is at a different memory location.  Pixels byte 2 on line 2 are not sequential with byte 2 on line 3.  So, we can only block move in one line of the image at time.  To complicate things we need to figure out where in memory each line starts since they are not in order.

We can do a couple of ways.  Compute the start address of the line, which will take a lot of instructions include division and multiplication (remember we’re on an 8-bit machine here at 1Mhz) or we can do look up tables.  A lookup table is basically a list of 192 addresses (the number of lines in Hi-Res) in line order. that we can index into with our Y coordinate.  Takes up 384 bytes of memory, but saves us a bunch of time.

Here is the formula from the book:

Screen Shot 2016-03-18 at 6.54.53 PM

Needless to say, I went through and wrote something to dump out all the line addresses and generated the lookup table.  You’ll notice “SN” above referring to Hi-Res page 1 or 2.  The Apple ][ screen has two pages, only one of which can be visible at a time.  To avoid flickering images when moving them, it’s a common (not trivial) to erase/redraw on the page not being displayed, then switch which page is visible, then repeat.

Then I took a bitmap example from the book and wanted to get it moving across the screen.  Since I’m learning here and wanted to do it the right way, I decided to also do the page flipping.

You can see my first attempt:

It’s not the cleanest, but not too bad.  At least it moves and I can tell the pages are flipping (the garbage at the bottom).

But, notice that it’s moving jerky.  That’s because I’m moving it a whole byte (7 pixels) each frame instead of moving individual pixels.  That’s going to take some more work, but at least we have movement.  Baby steps.

I decided to get back into working on my game, but this time I decided I should learn to program graphics on the Apple ][ as part of it.  Something I never really did what I was younger.  I’m follow the Apple ][ Enthusiasts group of FaceBook so I reached out to them about pointers to books, sites, and tutorials for it.  I’ve see some people in the group do some pretty amazing things.  I had a lot of suggestions and tips.

One book that people recommended was “Apple Graphics & Arcade Game Design” by Jeffery Stanton.  (You can find it on the Internet Archive, if you are interested).  I started reading that on Hi-Res graphics and learned a ton.  I highly suggest the book.

One main thing I learned, is that Hi-Res graphics is that it’s not easy.  The way the hardware designers laid out the hardware (to keep costs down) was pretty much a mess.

Lines are not sequential in memory.  It’s hard to explain, but if you’ve ever seen a Hi-Res image load you can see the “interlacing” effect when it loads.  Here is an image from the book the illustrates writing sequential data to the screen:

Screen Shot 2016-03-18 at 5.57.40 PM

Now, if that isn’t bad enough.  One byte in memory contains 7 horizontal pixels, bits 1-7. And the bits alternate colors within the 7 bits.  It’s a mess really.  It makes me even more impressed at how game developers in the day were able to make the amazing games they did.  My hats off to them.

Back to the 7-bits of pixels.  It gets more fun.  In even bytes the pixels alternate violet-green, in odd bytes they alternate green-violet. Well, unless the high bit is on then they alternate blue-orange and orange-blue respectively.  But, if you turn on bits 1 and 2, you get a 2 pixel white line. If you turn on bits 1 and 3 you get a 3 pixel line of violet, 2 and 4 you get a 3 pixel line of green.  Clear as mud?

Here is a picture:

Screen Shot 2016-03-18 at 6.10.48 PM     Screen Shot 2016-03-18 at 6.14.42 PM

Lines in order (second image has high bit set in each byte)

  1. Bit 1 on
  2. Bit 2 on
  3. Bit 1 and 2 on
  4. Bit 1 and 3 on
  5. Bit 2 and 4 on
  6. Bit 1, 2, and 3 on
  7. Bit 1, 2, 3, and 4 on

Also notice, you need to choose between using green/violet in those 7 pixels or orange/blue.  Not both.

Enough of this, let’s draw something.

I wanted to work on a game for the Apple ][, mainly because it gives me something to focus on while getting back into programming on the Apple ][.

In my younger days, I did most of my programming in BASIC with a little dabbling in assembly.  I figured now is the time to move forward to using something faster.  I’m a long time C developer, so that seemed natural.

Enter CC65.  CC65 is a cross-compiling toolchain to the 6502.  Basically, that means I can develop and build on a modern machine and the output is binary code that will run on retro machines.  In my case, the Apple ][.

In the beginning, I’d write code in a text-editor, compile it, place it on a disk image and boot that disk image in an emulator.  Slow going, but it was just playing around so it didn’t matter too much.

Fast forward and time to get serious.

Some of the people in the Apple ][ community put together a build pipeline for Xcode that make this all nice and smooth.  Develop in on modern IDE (Xcode), click build and it compiles, puts it in a disk image, boots Virtual ][ and runs the program.  Very nice.

Several months back, I had an idea for a game I wanted to do for the Apple ][.  For now, I’m not saying what the game is but it’s a puzzle game.  I wrote the engine and had it working fine, but it was basically taking the game board plus the moves then says “WIN!” or “LOSE!”.  Not real exciting.

I started working on the visual aspects of it and started with just moving test around to simulate what would be happening in the game.  I didn’t very far but what I did put in worked okay but, as you can guess, was pretty lackluster.  Plus, I lost interest and got busy.

Fast forward again.

 

As I work through getting back into retro-programming, I thought I might as well document it here.

That way, anything I learn I can easily share with others that might also take it on.  And, really, a place for me to keep things so I don’t forget them.