Development environments and title screens

Now that I had reverse-engineered the title screen display routine, and hence knew the format of the title data, I decided to set up my development environments for the ports and code the routine to display the title.

The Apple II hires screen is unique in that video memory is in effect 7-bit - and line-interleaved at that! In fact, my mind still boggles at how anyone could have the patience to write any graphics software with that hardware architecture... it's simply horrid. Anyway, the title graphics data is stored as 7-bit data with the high bit used (quite effectively) for RLE encoding.

Original Apple II Title Screen (AppleWin)

It would be quite silly to attempt to retain that format simply for the sake of it. I coded up a small program in C using the allegro graphics library (my weapons of choice for little projects like this) that first displayed the title screen from the original data (fortunately the actual title screen data isn't line-interleaved; the code uses a look-up able to calculate the address of each scan line). Then I modified it to save 8-bit data in a standard C array (and re-display to verify), then RLE-encoded it (and again re-displayed) and finally output as ASM '.db' statements. This file can be .include'd in both projects as-is.

Next I set up my TRS-80 Model 4 (Z80) development project. A few weeks earlier I had finished porting a couple of games from the TRS-80 to the Microbee using the ASZ80 assembler; I'd chosen that primarily because IDAPro supported it. It has the added advantage of being part of a suite of assemblers that includes a 6809 assembler - whose linker could output a Coco RSDOS .BIN file natively - and they also have similar syntax to the GNU as68000 assembler I've been using for the Neo Geo. So there really was no contest when it came to choosing assemblers for the project.

Leveraging off the above-mentioned earlier projects, and also lifting code from my TRS-80 Space Invaders Bootleg project, it didn't take long to have something building which should, in theory, display the title screen on the TRS-80 Model 4. I also had the scripts and tools in place to create a CMD file from the binary output from ASLINK.

Next to choose an emulator (MESS is not an option as there's currently no Model 4 - let-alone hires - drivers), and George Phillip's trs80gp was a natural choice as it's geared towards developers, allowing you to launch the emulator and instruct it to execute a /CMD file directly from the command-line. I could build and run in seconds. After fixing a few bugs and pixel-doubling the display, I was greeted with the following:

TRS-80 Model 4/4P w/uLabs Grafyx Solution Hires Board (trs80gp)

Now it was the Coco's turn. I lifted my GIME initialisation routine straight from my Tutankham project (having to re-learn exactly what it did) and then managed to coax a version of the display routine out of the depths of my already-limited 6809 coding knowledge.

The assembler and build script was the easy part - the hard part was working out the best way to get the code running in an emulator, keeping in mind the fact that I will be doing this for hundreds of build-and-test cycles over the ensuing months. In the end I settled on the MESS emulator (always my preference for any development work anyway), and the File2DSK utility for injecting the BIN file into a DSK image from the command line.

Along the way I discovered that the .BIN file output from ASLINK doesn't seem to have the correct execution address, which is annoying but at least doesn't stop me from doing what I need to do - it's just more typing each time I want to run my code.

TRS-80 Color Computer 3 (MESS)

Initially I'll be programming the Coco3 in monochrome mode, to simplify the porting process and to defer having to learn about the Apple IIe artifact color mode. Ultimately the intention is to utilise the Coco's 4-colour mode to replicate the Apple II colour rendition of the game.

Now that I've set up the development environments, it's time to return to the disassembly. There's little point in porting anything more until I am able to render the level data at least, which is pretty much the next thing that the game does anyway when it enters the demo/attract mode. I don't really have much feel for how much time and effort that's going to take, so it could be a while before I get to post an update - unless I cave and set up a Neo Geo environment too!