Scoring differences in Super Xevious, and a 'cheat'?

Quite fortuitously I decided to watch a YouTube video of someone playing Super Xevious to see the new objects in action as they were intended - ie. on a non-patched ROM. The video features the score reaching 9,999,990 which is when the game starts to crash...

Halfway through the player was seemingly stuck on the screen where a series of Garu Zakato (large bombs) explode on the screen, releasing 4 Brag Spario. These Brag Spario circle the Solvalou in a display of celestial mechanics (quite impressive), and the player was trying (fruitlessly) to destroy them whilst trying to evade them. My tactic since 1984 has been to sit near the bottom of the screen, where you have more time to react, and they also promptly disappear before they can circle back (in fact, I didn't even know they circled back until I was testing the transcode in 'invincible' mode, and ventured up the screen!)

Brag Spario circling the Solvalou can't be destroyed...

I was wondering why the player hadn't worked this out, and then I noticed they had racked up a massive score! Watching closely, I realised that the score was incrementing quite rapidly each time a Brag Spario was shot; they can't be destroyed, but as they circle they can be shot multiple times.

Checking the code, I noticed each shot was scoring 2,000 points! Wondering why I'd never seen this tactic in Xevious before, I checked the original code - only 500 pts! On EASY setting (as this video seemed to be), on Super Xevious you could earn an extra Solvalou by hitting a Brag Spario just 20 times - easy to do when 4 of them are circling!

Of course this meant I now had to go through all the scoring in Xevious and compare it with Super Xevious... and found just one other case; Sol Towers have been reduced from 2,000 pts to 1,000 pts.

I hope I haven't missed any other subtle changes in Super Xevious...

Today I (also) added support for separate high score load/save for Xevious and Super Xevious on the Neo Geo. It's painful to test on both BRAM and memory card, but all done now.

Now... sound or sparklies???

Super Xevious post mortem.

I've finished testing the Super Xevious transcode additions.

I can only say that Super Xevious was a half-arsed, almost apathetic exercise that couldn't have taken more than a week. The main enhancement is the increased difficulty (table entries), and the new objects don't really add much to the gameplay experience at all. In fact, you should actually ignore all of them except the Galaxian.

*** WARNING: some spoilers here, though they're really not that exciting...

• Galaxian; technically worth 150 pts but you can't actually hit it. Always spawns away from the Solvalou, and will turn away before you can get under it. Shoots at you though.
• Jet Taking Off; appears once (area 10). Unique in that it is a flying enemy, but shooting it results in a crater on the ground. You can't get close enough for it to hit the Solvalou before it leaves the screen, Don't shoot it - you have been warned!
• Jet; the most pointless addition. Appears once (area 15). Flies down the screen at a random (relatively shallow) angle but is completely and utterly benign. It can't hurt you, and you can't destroy it. What was the point?
• Helicopter; appears once (area 14). Don't bomb it - you have been warned!
• Tank; appears once (area 8). Don't bomb it - you have been warned!
• Bridge; appears once (area 15) and is purely cosmetic (completely benign). 'Allows' the Domograms to cross the river. 

And that's it really. To be fair, there was very little free ROM space available (they had to remove some copy protection routines) but I feel they could have done more than that. There are existing object handlers that aren't used - they could have (re)used them too?!?

As I mentioned, the code base now builds both variants.

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?

Amiga performance, Super Xevious ready for transcode, and Donkey Kong updates.

I've been playing around with the (transcoded) Xevious source in order to facilitate better performance on the Amiga. I think I was somewhat successful.

On the original machine, the MAIN CPU gets a VBLANK interrupt and updates the lower 32 (ground-based object) sprites. It then sets a pair of memory variables (aka semaphores) to signal to both MAIN and SUB ROMs to stop spinning and calculate the next frame. The MAIN doesn't touch any hardware, but the first thing SUB does is update the upper 32 (air-based object) sprites and then hits the h/w scroll register. This is why the ground-based objects "shake" a little even on real hardware!

In order to handle this on one processor, the transcode updates the lower 32 sprites and sets the memory variables in the VBLANK ISR as per the original. When MAIN is signalled, it first calls the SUB ROM routine, which updates its hardware (as described above), runs the rest of its code to completion, and then MAIN can complete the frame processing, before spinning again waiting for the next VBLANK.

So SUB ROM gets to update its hardware immediately after MAIN finishes its VBLANK ISR - just like on the original - which comprise the most time-critical tasks. But on the original, it wasn't clear which CPU was finishing its processing first. This could be important, since the last thing SUB does is update the sprite shadow registers with data from the current frame - including data updated by MAIN. HOWEVER, the transcode is calling MAIN *AFTER* SUB has run to completion. And this is still the case atm. It's something that requires more investigation on my part.

One thing the code couldn't handle though, is 'frame-skipping' which is especially important to get the game running at 60Hz on a PAL (50Hz) machine. So I added an 'ISR' for SUB, comprising the two h/w-related routines, and removed them from the SUB main loop. This 'ISR' gets called directly from the MAIN VBLANK ISR.

I then modified the code to treat the 'semaphore' variable (I removed the superfluous SUB semaphore) more like a real semaphore - a count instead of a flag. The result being, if you set the semaphore to 2 instead of 1, it'll call the main and sub routines twice, whilst updating the screen just once. Perfect for adding an extra frame every 5.

jotd has reported better performance on the Amiga, though I can't immediately eplain why, unless excessive lag was causing the two semaphores to get out of sync and delay an extra frame? Regardless, it's getting a lot closer to a release and is certainly very playable on suitable Amiga harwdare now!

The other thing I've done is completed the RE for the new objects in Super Xevious. They aren't particularly exciting, or very complex at all, though to be fair there wasn't much spare memory to play with as the Xevious ROMs were pretty full; they even removed some of the copy protection to fit them in.

At the risk of spoilers, I will say that of the six new objects, 3 are better left alone and one is completely benign! I was wondering why they went to the trouble of adding an object that effectively does nothing, and only appears in one place - until I saw it in action; it's a bridge to allow Domograms to cross a river. Purely cosmetic of course, as there was nothing stopping them from crossing before, but a clever addition.

The bridge 'allowing' Domograms to cross the river.

The rest I'll let you discover yourselves.

It won't take me long now to add Super Xevious to the transcode, at least as a build option. I'll probably add it before the next beta release on the Neo Geo.

Oh and when I haven't had the opportunity to work on Xevious, I've been working on Donkey Kong. I've updated the makefile to bring it in line with the Xevious makefile, including eliminating any need for masquerading. I've also moved the Neo Geo-specific code from MAIN into the now-familiar OSD routines, and also removed some macros that I'm not sure why I implemented.

I still need to fix the mess I made of the graphics routines, where I attempted to support rotation by changing tile/sprite coordinates on-the-fly in the code, rather than writing the original values to shadow memory and converting then or during VBLANK rendering. Once that's done the MAIN code will be 'clean' and even suitable for jotd to work with on the Amiga.

Super Xevious coming soon!

I've fixed one bug in the Amiga port (it was copied from my code) but I haven't been working on the next beta or the Amiga version as I should be... instead I've been distracted by the possibilty of adding Super Xevious to the transcode.

To this end, I've been going through the MAIN CPU and naming all the labels; IOW a complete RE except for the comments. And I finished this morning.

In a nutshell, the Super Xevious MAIN CPU code is a super-set of the Xevious code. The only real differences are the addition of six (6) object handlers at the end of the object handler table and the table of flying enemy types. And of course slight changes to the title screen and copyright messages. Some of the copy protection code has been sacrificed for the new object handlers.

Adding the additional object handlers wouldn't affect the Xevious gameplay in any way, so there wouldn't be any need to #define those out for a Xevious build. That just leaves the title, copyright and flying enemy table, which would be trivial.

And as mentioned previously, the SUB CPU code would just require those three (3) different lookup-tables to be selected for each respective build.

Almost too easy!

UPDATE: I've updated my map parsing tool (it's more accurate now and handles the new objects) and have confirmed that none of the previously unused add-object functions in the SUB CPU, and none of the previously unused object handlers in the MAIN CPU are being used by Super Xevious. Thus additions are purely the six new objects. In fact, much of the map, and object counts throughout the map, are very similar to Xevious - it really doesn't play that differently, except perhaps the difficulty level in the new flying enemy table.

I also looked at the execution flow of the original vs the transcode (the context of the VBLANK interrupt and graphics hardware accesses) in light of the 'shaking ground objects' in the Amiga port. TBH I can't really explain it atm, without suggesting that the Amiga is eg. simply updating the scrolling outside the blanking period?!? I need to discuss further with jotd...

When is Super Xevious not Super?

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:

1. The object data (where objects appear in aeach area)
2. The handler function lookup for various objects (to cater for new objects)
3. The flying enemy offset table (which determines which flying enemies and how many appear)

The only other differences are a re-organisation of some of the routines (it goes about half-way towards implementing all the handler routines in the same order as they appear in the tables), and inversion of the FREEZE dipswitch setting (and a few extra instructions to handle it).

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.

A short break, and thinking (too far) ahead.

Just having a few days break fom Xevious before I get back to it in ernest this week.

Over 100 downloads of Beta 1 which I'm a bit surprised about, although I've never had any statistics on any of my projects in the past.

A bit of feedback; some issues with FREEPLAY (which I've already fixed) but no other reports of glaring bugs other than those related to sound. I will be re-arranging my sound channel allocation for the next Beta. I've also done away with masquerading in MAME thanks to Blastar who handed me a better solution on a platter!

Next task though is to take a step back and look at the code from a higher level again, to address the issue of both 'sparklies' on Neo Geo real hardware, and 'shaking ground objects' in the Amiga port. I'm not entirely sure they're related issues, but I have a few things to confirm and try out.

I should also dig into the Amiga code and try to understand more about how it works.

I've started migrated my hosted files to github, starting with my RE listings. I just need to update some of the links on my 'Projects & Downloads' page. Then I'll look at re-homing my transcodes... somewhere...

And of course looking (way too far) forward, I've started to think about what my next transcode will be after Donkey Kong. I think I'm still going to target the Neo Geo as it's one of my favourite systems and so capable. Of course an Amiga port is always on the cards, and possibly a few others, especially as I'm looking to (finally) do a horizontal title. Contenders at this stage are Ghosts 'n' Goblins and Bubble Bobble.

The possibility of doing Super Xevious also occurred to me; identical hardware, identical graphical assets - even though several new enemies appear in the game! It wouldn't require any changes to the OSD layer, only parts of the ROMs transcoded. All 6 devices appear to have different code, though I suspect 90% of the code is unchanged. So probably relatively easy to do, but I'm a bit over Xevious atm...

Screenshot for attention

UPDATE: had a VERY quick look at the Super Xevious disassembly; no doubt it's little more than an enhanced version of the original code, reassembled.

UPDATE: Curiosity got the better of me. I've taken a closer look at the disassembly...

The SUB ROM is not a lot different, but they have re-ordered some of the code and data. All the object data is still at the same location at the end of the ROM though.

I've only taken a preliminary look at the MAIN ROM, but so far it's not a lot different either. I have identified the object hander table; they've added six (6) new objects to the end of the table (rather than utilising unused slots in the table for some reason). The flying enemy table is different too.

It uses the same background map ROMs, so there's no difference in the landscape. What is different is the object data, so things appear in (potentially) different locations. There are (again) 46 Sol Towers (I wonder if they're all accessible this time?) and 4 Bonus Flags in the same areas. I have generated the maps for each area, detailing the locations of Sol Towers and Bonus Flags... I've only looked at the first few... no spoilers!!!

I was wondering whether it would be possible to simply add to the original transcode and produce source that you could build for both variants of the game. The re-arrangement of some routines and data is a little inconvenient, but it may still be possible. It would probably take a few weeks to at least add labels to all the routines and data areas, then check that nothing has changed in the existing code. It does run a bit faster though, so there would have to be some differences...

Now back to the Amiga and also getting Beta 2 out there!