Code and data structures starting to take shape

Now that the "secrets" map is complete I've returned to RE'ing the code.

The architecture of the code and data structures in memory are slowly starting to take shape. I won't go into any detail at this point - mainly because it's early days and I could have made some wrong assumptions - but there are some interesting aspects to it. And some puzzling ones too. But as I said, early days yet. I will say it's similar to a few other arcade games I've RE'd recently, yet more complex.

It's becoming clear that the SUB (graphics) CPU does little more than set up map and graphics-related data for the MAIN CPU. It doesn't seem to handle any of the game logic at all. There are sections of it that I still need to understand but, if I'm not mistaken, I've RE'd the majority of the functionality.

[I'm wondering now whether it was used - unchanged - on Super Xevious? I should check that.]

There's a fair bit of RAM shared between the CPUs, but very little in the way of communication between them. I haven't found any mechanism for passing or queuing of any messages, for example. I suspect there's a handful of interlock/semaphore bytes, but that's probably about it.

I have actually identified how/where the MAIN CPU handles each of the objects now. I'm still fleshing out my understanding of it but I have, for example, identified a few routines for certain objects from the map. It's interesting how it's done, and probably worth a blog entry on its own.

For now there's still plenty of work to be done in this area, so I'll forge ahead.