Even less Xevious happening...

Scool holidays means even less time to work on my projects. Not that I've been particularly motivated lately. Xevious has been a no-go for a few weeks now... it's getting ridiculous now - I need to release a new Beta with better sound before everyone forgets all about it.

I have done some more work on Donkey Kong though. I think I've finished converting all the tilemap accesses to osd_w_vram calls. I should now be able to fill out the routine to actually update the Neo Geo sprites, and then remove the call that renders the entire tilemap every VBLANK.

I'm not too keen on how I did the transcode all those years ago. I was more concerned with mirroring the Z80 register usage than optimising for the 68K registers. Even then I don't think I was entirely consistent. As a result, it's a bit of a dog's breakfast. I've already re-allocated some registers in the routines that I've been updating for vram access.

When I finish Xevious and start on the transcode in earnest, I'm going to go back to the start and work through all the existing code. There's a few other areas where I diverted from the way the original code works when I really shouldn't have. I want to fix all that up - I'm much happier with the way Xevious turned out, and want to use that as the template for my transcodes going forward.

This week I'll make a concerted effort to finish off Xevious and release a new Beta, even if it is just the sound. There's really only one last bug that I need to find - spurious Toroids (flying objects?) destroyed when firing continuously.

Not much Xevious happening...

Currently finding it difficult to work on Xevious due to other commitments, but I should have some free time in the coming week and hoping to be able to release a Beta by the end of it.

In the mean time I've been doing bits and pieces on Donkey Kong, updating all the tilemap accesses so they are done via the OSD layer. Not quite as efficient as simply writing to video ram, but a lot more flexible and allows the choice of either on-the-fly updates or, for example, dirty tile updates during VBLANK. It also makes it much easier to rotate the screen, which I am planning to support on the Neo Geo. I don't think the Neo Geo or Amiga will have anywhere near the performance concerns of Xevious for this transcode.

Not being "in the zone" for Donkey Kong does makes things a little more difficult. There are things I've done in the code that I am now questioning; things that will take more time to analyse. It has been around 10 years since I touched it last... but I can't afford investing that time until Xevious is done and dusted.

Regardless of the countless changes, it is still mostly working. I've broken the intro animation where Kong has kidnapped Pauline and climbs the ladder before stomping on the girders - it loops endlessly. But the attract mode demo runs - for a while before rebooting. It's annoying that I can't simply coin up and start a game to test my OSD changes, but it's nothing to be overly concerned about atm.

Hopefully my next post will be announcing the next beta release of Xevious!?!

UPDATE: I fixed the broken intro sequence; I had recently 'optimised' one of the RST routines, not realising that some callers relied on a side-effect (setting the HL register pair). I can coin up and start a game, but there are multiple gameplay issues now.

NGFX SoundBuilder

More RE - this time Blastar's NGFX SoundBuilder Z80 ROM.

I wanted to learn more about how the Neo Geo sound works in general, and how the SoundBuilder Z80 ROM works in particular. Together with the Neo Geo Development Wiki, the YM2610 (incomplete) datasheet and some sample driver code, I was able to decypher most of it today.

Pretty neat how Blastar has designed his driver to cater for most situations. It provides 5 channels of ADPCM allocated in a round-robin fashion for short samples, a 6th channel that can play background sounds (optionally looped) for longer samples or voice/music, and a 7th independent channel (again, optionally looped) that can also play background sounds. On the NGCD, the 7th channel is replaced - seemlessly - with CDDA tracks.

The way it works is that the driver code itself doesn't need to change, just the data table(s) at the end of the ROM. One for the (optional) eye-catcher, and one for the game sounds. After you insert the samples into the GUI and allocate channels, it produces a Z80 ROM image and accompanying PCM data ROM ready to go for either cart or CD systems.

Now that I understand how it all works internally, hopefully I can get the sound working in Xevious without any glitches sooner rather than later.

Sound complications holding up Beta 2 release

Been quite a while since my last post. There are a combination of reasons, but primarily it's that work has gone from 1 to 100 and kids' soccer season is in full swing. And I also have to admit that I'm just a little bit over Xevious now.

However, I have still been working on the next Beta release when I can. The particular issues that remain include sound, and artifacts that only appear on real hardware; so working on either isn't possible during lunchtime at my desk. That hasn't helped matters either.

I had a theory on the artifacts (aka "sparklies") but that hasn't panned out. I've decided - for now at least - that I can live with them. Nothing that a crappy composite picture won't mask anyway! Maybe sometime down the track when working on other projects I may get another insight?

The sound isn't proving to be going well either. I re-allocated some of the sounds to make use of ADPCM-B on the cartridge-based systems, and CDDA on the NGCD. This allows me to mix the Solvalou background 'tune' and the Andor Genesis sound. It was also supposed to simplify some of the logic that calculates when to stop certain sounds.

However it seems to run amok fairly frequently now, sometimes playing sounds when they shouldn't and sometimes muting sound altogether. I'm yet to actually confirm, but I'm fairly certain it's to do with the 68K writing sound commands faster than the Z80 can process them. Of course the arcade code just writes sound commands whenever it needs to, and I have no control over that. It won't be trivial to solve...

These issues aside, the Beta is all-but-ready for release. A few minor enhancements/fixes that jotd has discovered during the Amiga port, and I'm well and truly ready to wrap it all up.

NaggyNaggerson created this awesome 'flyer'
for the Neo Geo version of Xevious

On other news, I've been working a little on Donkey Kong, mainly during lunchtimes at work when I can't work on Xevious for reasons outlined above. I've eliminated all the old macros that didn't really work the way I want them to now, and it's only a little broken! In the process I replaced all the branch and jump opcodes with the gnu pseudo opcodes that automatically calculate the optimum instruction. Next step is to replace all the video/sprite calls with osd_XXXX functions.

Finally, I've been tweaking the Xevious makefile and project directory structure to accommodate the new sound and ultimately produce a .CHD rather than a .ISO to accommodate the audio tracks. That was a learning exercise in itself. Of course that will need to be carried over to DK as well.

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?