Avian’s Blog

Over-optimization does terrible things to the code...

So far I've disassembled and annotated two large chunks of Galaksija's ROM - the video interrupt handler and cassette loading and saving routines. I had to do that to find out how the original hardware worked. Fortunately these two parts were simple to figure out compared to some other parts of the code that resides in that tiny 4K EPROM.

Some parts are written in a way that I would never otherwise consider possible: you probably heard about parts of code that are also used as ASCII strings, but how about jumps that are no not aligned with opcode boundaries? Apart from a handful of documented ROM functions there is almost no structure in the code. A single RET instruction for example can be used as an exit point for tens of separate functions.

To give you some idea of the complexity involved, here are some call graphs. Each box represents a chunk of machine code. Thin black arrows show jumps and loops, thick black arrows show neighboring blocks of code (where execution goes from one block to the other without a jump), red arrows show function calls and blue arrows show calls by RST instructions.

Circular boxes are entry points (two interrupt vectors and a reset vector), rectangular boxes are code in the first 256 bytes of the ROM that can be accessed by RST instructions. Other boxes represent other parts of the code.

This graph is only approximate of course. Various tricks in the code make it impossible to do an accurate static analysis (especially with my 175 line Perl script). Dynamic jumps and jumps not aligned with opcodes for example are not shown or are shown wrong.

Here's the original Postscript file I used to create images above. Make sure you have plenty of swap space and a good Postscript interpreter before you open it.