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.