Super Xevious transcode complete! Now to squeeze both into the same binary...

 I've finished the Super Xevious transcode, though I'm yet to test the new objects.

To give you an idea of how little code has changed, MAIN has 10 uses of an assembler directive to differentiate code, whilst SUB has only 2. These are mainly for title screen and high score table differences in MAIN, and the data structures in SUB that drive gameplay.

The code for the additional object handlers are included in build options for both, as they simply won't be called when playing Xevious. It's neater than adding more assembler directives, which only makes the code harder to read. And one of the tables in SUB has an extra 6 bytes on the end; one for each new object type. The negligible 'wasted' resources are hardly an issue on a typical 68K system.

My next challenge is to get both variants building in a single binary. The difficulty arises because Xevious is split into MAIN & SUB src (object) files, with a whole bunch of locations (labels) shared between them (so global). I don't really like the idea of reorganising into a single source file (using .include, for example).

What I think I need to do is separate the shared locations (RAM, more-or-less) into their own object file that need only be linked once, and then go from there. Both MAIN and SUB only have 2 entry points, so it's not difficult to duplicate for each variant. And hopefully that's about it.

I'll post my success, or lack there-of, here of course!

UPDATE: SUCCESS!!!

I pulled all the RAM variables out into a separate source file to be assembled once (shared by the two variants). MAIN & SUB are assembled twice within the target, using --defsym OPT_SUPER=0/1 to differentiate the build. Now there are two (s)xevious_reset and two (s)xevious_im1_irq entry points exported. As it turns out, there's no difference between the two irq handlers, so it's possible to just call the original from either variant. As a result, the variant chosen is wholly dependent on which reset function is called!

It wasn't quite that easy; some duplicate routines that I was exporting from MAIN rather than re-implementing in SUB had to subsequently be copied into SUB. And there were a couple of data structures shared between MAIN & SUB that had to be either duplicated, or constructed in RAM.

The binary is larger now, so I had to arrange the objects to preserve my 16-bit branches.

The Neo Geo target now prompts to select the variant from the splash screen.

Selection of Xevious or Super Xevious on the Neo Geo

All that remains now is to support separate high score load/save for each variant.

Then test the new objects in Super Xevious, fix the sound, and the sparklies. And investigate some weird graphics 'sparklies' when shooting toroids... will it ever be finished?