Today I managed to find a bug that I had inadvertantly caused in the Amiga port of Xevious. So I think jotd will be happy about that!
I also found myself stuck en-route to dinner tonight with about an hour to kill, so I pulled out the laptop and worked through more of the RE of Super Xevious. I started with the SUB CPU and whilst I'm labelling all the routines and variables, I'm not adding any comments, unless the code differs from Xevious.
That's finished now and it turns out that there's only three (3) differences (of any significance) to the two SUB CPU ROMs, and they're all data structures:
- The object data (where objects appear in aeach area)
- The handler function lookup for various objects (to cater for new objects)
- The flying enemy offset table (which determines which flying enemies and how many appear)
Since there are no additional handler functions (these functions are only responsible for adding new objects to the object table) - as several object types share the same handler here - my theory is that replacing the SUB CPU ROM in Super Xevious with the ROM from Xevious, will result in Super Xevious playing exactly like Xevious, but with a different title.
I'll try to put that to the test shortly...
UPDATE: after patching 2 bytes in the Xevious SUB CPU ROM to ignore the FREEZE setting and replacing the Super Xevious SUB CPU ROM, Super Xevious does indeed run as Xevious. I only played through Area 1, but it shows that it is at least highly compatible.
What's most important here is the possibility of using a single source base for the SUB CPU ROM for both Xevious and Super Xevious, with assembler directives around the three data structures. Since the transcode doesn't implement the FREEZE dipswitch, that's not an issue either.
No comments:
Post a Comment