Chapter 18- March 30, 2015
ROM wasn't built in a day!It's been a long time between drinks and this project had appeared to stall in recent months. With free time a rare commodity and a variety of distractions engulfing what little was left, I began to lose my creative focus on the project.
After a reassessment of my goals and priorities, I have clawed myself back into a steady routine where I can resume work on this project. It's good to be back doing something I enjoy without the outside interferences.
Goodbye floppy days
Having acquired Darren Atkinson's excellent SDC controller, I have found that between it and Drivewire, I have not had a need to turn on my old mechanical floppy disk drives. I have since packed them away and now enjoy the benefit of a leaner and cleaner CoCo3 desktop. This got me thinking...
Some years ago, I had acquired several 5.25 inch floppy disk media packs still shrink wrapped from when they were produced and as new. But upon opening them, I found that writing to them was unreliable and that they were spilling deteriorated magnetic media all over my drive heads. I began to question what the reliability of this media would be in another 5 or 10 years? Is it practical to distribute software on old magnetic media anymore?
The simple solution was to abandon the floppy disk media and distribute it as an emulator DSK file. This would also reduce postage costs. As tempting as this would seem, I was hesitant with this idea since I felt that this reduced my software to... just software.
When software goes hard
I have been a collector of Atari 2600 game cartridges for a some time with about 50 cartridges collected from the late 70's and early 80's. The main appeal for me was that each game was a collectable item. The design of the cartridge case, the artwork on the label and the electronics inside makes it feel special. It's like holding a piece of history in your hand and admiring all the work that went into producing the physical product... even if the actual game itself was crap.
I was hoping that it would become my first ROM Pak game and that it would some day also become a collectable.
Recently, this idea to release a ROM Pak title has returned and after examining the logistics of such a scope change for my game, I believe it can be done.
The Super Program Pak
On page 58 of the June 1990 issue of The Rainbow is an article by Greg L. Zumwalt titled Breaking the 32K Barrier. It explains the Super Program Pak created for the CoCo3 and was used in ROM Pak games such as Predator, RoboCop and Super Pitfall. This article explains the operation of the Super Program Pak and even includes a schematic diagram detailing how a large ROM chip can be bank switched to operate in a smaller ROM space.
So I starting investigating this medium for distribution and decided to settle on a 64K ROM (27512) of which I have several on hand to play with. This ROM is available off ebay for under $5 each and board manufacturing has become easier and cheaper than what it once was.
Cases to contain the boards will be hard to come by but if I design the ROM board to fit into a standard ROM Pak cartridge, then most CoCo enthusiasts may have access to an old ROM Pak that they could recycle and I would only need to sell the populated board.
The actual hardware details can happen closer to the end of the software development part of the project. The priority now is to ensure the game fit into a 64K address space. Space wasn't an issue when the game was destined for floppy distribution but now I can't have any wasted space.
One area that will need optimization is the Title Page graphic. I stored this complete with no compression and it occupied 16K (2 x 8K MMU blocks). This was wasteful and so I have incorporated a simple compression which has reduced the graphics down to 1 x 8K MMU block.
This is the title graphic taking up 2 x 8K blocks (16K)
And here it is taking up 1 x 8K block (with some space left over)
Another area of concern is the area reserved for sound samples. I was planning on allocating 4 x 8K MMU blocks (32K) for these but this will need to be reduced.
My current planned memory allocation is as follows...
Total usage is 7 x MMU blocks which is under the maximum limit of a 27512 ROM of 8 x MMU blocks but this is assuming my program code will only require 1 block. I also may want to expand the map encoding to 2 blocks to enlarge the game scrolling length. It's good to have some space for expansion.
Just one more thing
We're almost ready to start coding the new tile based scroll routine. Only one more optimization to do before we can begin. This optimization is not a compression to gain more memory space but an optimization that will improve execution speed within the upcoming scroll routine.
You will recall that I have created all the graphics using a 2D paint program on my Amiga. This makes it easy to create and design the graphics and output to a standard GIF format file which I can open on the Color Computer using a program called RS-DOS GIF READER written by Chris Babcock. Once the image is loaded into the Color Computer's memory, I can then manipulate it further and SAVEM the parts into standard Color Computer BIN files.
There are 3 main graphic components as shown in the table above. Fonts and other graphics, the title page graphics and the graphic tiles which contains up to sixty 16x16 pixel tiles that will be used for the scrolling landscape. These tiles are a standard Color Computer 16 color bitmap where each byte occupies 2 pixels and memory is organized in horizontal bands mapped from left to right.
For clarity and help make my explanation easier to follow, let's assume each tile is 4 bytes wide by 4 bytes high as shown in the table below.
The scrolling routine will draw the next incoming piece of the display in 1 byte vertical strips. Therefore my scrolling routine will read each required tile in vertical strips one byte wide for each scrolling frame.
The numbers above represent the order the data is READ from the tile graphic.
Each tile is store in memory as a normal bitmap (4x4 bytes in this example) and our bitmap area is 160 byes wide for each horizontal line of graphics. Looking at the tile sample above, the bytes are stored 04, 08, 12, 16 then we jump forward 156 byes (160 minus 4) to 03, 07, 11, 15 and forward again 156 bytes for 02, 06, 10, 14 and forward again 156 bytes for 01, 05, 09, 13.
But when we write the vertical strips of each tile during the scrolling routine, the data stream required is read from memory starting with byte 01 then goes back in the bitmap 160 bytes to obtain byte 02, back another 160 bytes for byte 03 and again another 160 bytes for byte 04.
While the scroll routine can be coded to read the data this way, the execution overhead of reading the data this way steals valuable CPU cycles.
If the tiles are remapped into memory so the data is obtained sequencially, the code is simplified and executes considerably faster.
The data can now be read sequencially as shown in the remapped 4x4 sample below.
It also means that each tile is stored sequencially and the desired tile is easier to access, further improving the overall code execution.
Hopefully I have explained this clearly and not left everyone confused. The key lesson of this is that by preparing your data in a way that simplifies access, it will optimize the execution of the code.
Next chapter we delve into the new tile based scroll routine.
Copyright 2013 by Nickolas Marentes