Flippin' Hell

Another couple of short sessions - reverse-engineering the sprite rendering code.

Something I haven't seen before; read on! Sprites can be flipped horizontally and/or vertically on the screen. There's a single copy of the sprite data in memory due to memory size restrictions. Rather than flip during rendering, the sprite data is actually flipped - if required - in-place and then rendered, with each sprite data block keeping track of the current flip state. Clever, if sprites aren't flipped alternatively on the same screen (at least not very often).

Sprites must also be rendered at any bit offset and this is done at display time however - via self-modifying code. Not exactly uncommon for this type of operation though.

Generally with the low-level routines such as rendering there's no sense at all attempting to replicate the existing code since the underlying hardware can be quite different and often I'll convert the graphics data to a more suitable format. It also makes sense to optimise these routines for the CPU and hardware of the target platform. You'll find, for example, the Coco code for rendering graphics in Lode Runner bares absolutely no resemblance to the original Apple II code, and nor should it. The same will be true for the Coco code for sprite rendering in this port.

So with this in mind, I'm already thinking about optimisations that can be done on a machine with considerably more RAM. Like pre-flipping all the sprites and just choosing the appropriate memory bank to render to the screen. Perhaps even pre-rendering the bit offset sprites as well, especially if/when using 4-colour mode which will require only 2 offsets rather than 8!

As I delve into the code more, I'm feeling a little better about the port. Since so much of the game is concerned with rendering graphics, there may be less code that warrants line-by-line translation.

I'll probably spend the next few sessions doing more reverse-engineering until I fully understand all the rendering of sprites, complex objects and screens.

Made some time at lunch today to work on the new port again.

Added some more structure to the graphics data and commented the basic text display routines, allowing me to decode the font data which I subsequently rendered on the PC. I continued attempting to decode the graphics and managed to render the raw sprite data and had partial success rendering compound objects (made from multiple sprite blocks).

The game font in technicolour glory!

Here is where the format documentation on the net is somewhat lacking (and in some cases, actually not quite right) as I am yet to understand exactly how compound objects are put together. I made some basic assumptions and roughly half the objects look OK. I was hoping to be able to render a game screen in its entirety, but I'll have to defer any further progress on that front until I reverse-engineer the sprite/object rendering code.

What I've seen of the code doesn't bode well for portability to another CPU, however. The Z80 alternate register set, IX & IY, and self-modifying code are all used throughout the game. Preserving colour information is also going to be a task in itself. That said, I may need to take a different approach to my other ports, and rather than attempt a line-by-line translation, perhaps a routine-by-routine translation would be a better approach.

Oh well, if it was easy, every man and his dog would be doing it!

Jump, jump, jump, if you feel you want to

Got another couple of hours in tonight - mostly defining code and data sections and transcribing descriptions of the data blocks. Most of the code/data definitions are done.

The disassembly documents little more than the above, with a few dozen easy-to-deduce routines having been labelled; mainly to do with displaying on the screen, menu selections, playing audio and accepting user input. Pretty much the same routines I start with for all my disassemblies. Beyond that, very little has been commented, and literally only a handful of variables have been identified. It's a good head start, but soon it'll have reached its usefulness.

I haven't really looked much at the code, but I have noticed plenty of jump tables defined, and also fairly extensive use of the IX and IY registers. That's going to be... interesting... to port to the 6809.

I think next session I'll render the graphics objects on the PC.

Glutton for punishment

Back onto the subject of my new port - I've been toying with the idea of (also) porting it to the TRS-80 Model 4 (with hires board). Avid followers of this blog may recall that I originally attempted to port Lode Runner from the Apple II to both the TRS-80 Model 4 and the Coco in parallel. I gave it a good go but not long after rendering the title and level graphics I decided to discontinue the Model 4 port; 6502 to both Z80 and 6809 proved to be too much work.

I will reveal that this time around, the original game is actually written in Z80 (hint #1). The two main issues with a Model 4 port are the limitation of monochrome graphics, and the graphics bandwidth required for the animation in the game.

The original game doesn't make much use of colour at all - in fact it has even seen monochrome ports to other platforms in the past (hint #2). And the animation is quite modest for the most part, and arguably some slow-down wouldn't completely break the game. In any case, given the relatively little amount of work required, it may even be worth it even if it only ran 'properly' in an emulator, or on an enhanced (no wait state) graphics board which, BTW, is also on my to-do list.

Dusting off Neo Kong

John Kowalski has remixed Donkey Kong on the Coco 3 (added additional gameplay elements) and is reportedly in the process of back-porting his code to the original arcade hardware!

Anyway, I thought I'd dust off the arcade disassembly and send him a copy, which then resulted in John asking me a few questions about my Neo Geo port. And since I don't have a video of the latest developments, I thought I'd record a quick one tonight and post it on the blog.

To re-iterate, the disassembly of the arcade original is roughly 50% complete, and accordingly the Neo Geo port is also roughly 50% complete. What remains is the ironing out of a bug when Mario jumps, then adding all of the dynamic objects in the game, scoring and sound.

On the shoulders of giants

Got a little bit more time tonight and have loaded the binary into IDAPro and started on the disassembly. Still in the process of defining data and code segments - there's a lot of data in this game. I have a partial disassembly and data format document to work from, and I'm still in the process of transcribing that information into IDAPro. Probably have a few more sessions before I have to start thinking for myself.

Before I get too far into the disassembly I'll revisit the data format and write some code to render all the graphics objects on the PC. Then I'll write code to render each of the screens. Once that's done I should be very familiar with the data formats in the code.

Hopefully next update, which may not be for a few weeks, will have some eye candy - and no doubt will then reveal the game that I'm porting.

Interestingly, the graphics and controls may well be suitable for a Neo Geo port too...

It's a new day, it's a new game...

Far from finishing Donkey Kong or Lode Runner, I haven't touched any port nor any hardware project since the birth of my son in February.

Donkey Kong is waiting on the Neo Geo Flash Cartridge, which is laid out and ready for review but I currently don't have the funds to produce the prototype so it's on ice temporarily.

Similarly Lode Runner is waiting on the Coco Flash Cartridge, which I haven't even started.

So in order to get back into the swing of things, I've decided to start work on a new port to get me enthused. The target platform is, once again, the Coco 3. At this stage I'm not prepared to divulge the source machine (except to say that it's not the Apple II this time), nor the game itself, but suffice it to say that it was a landmark title in the day, specifically for its graphics.

I've been impressed with this title since I first read about it, and have had the idea of porting it for quite a while, despite the fact that I've never seriously played it. No doubt that will change during this process. Somewhat fortuitously the game has been disassembled to some degree and the data structures reasonably well documented, though work on it seems to have halted over a decade ago.

I'll say no more about it at this time, until I'm absolutely certain that a port is feasible (I'm fairly sure it is) and I have some eye candy to show off. Tonight was the maiden session and I've loaded the program image into a RAM array on the PC and wrote code to dump the data structures purely to familiarise myself with them.

The plan is to render the screens on the PC, and then start actually porting the code - which includes documenting the original platform source - to the point where I can do the same on the Coco 3.