Archive for November, 2015

Sometimes it’s difficult to know if the emulation of a game is correct without studying reference videos, and sometimes those reference videos don’t surface until much later.

That was the case with the FACE shooter Nostradamus, which has a number of video effects we didn’t know were missing until they were highlighted by somebody watching a 1CC (1 Credit Clear) of the game recorded from a PCB.

There were a number of effects, including a sprite masking effect and a shadow flicker effect missing, as well as the arms of the final boss (this one we did actually suspect was a bug for a long time, the PCB evidence provided confirmation)

I’ve uploaded a recording of the game after making several fixes to YouTube (the video has cheats enabled, it’s not meant to be a gameplay video) You’ll probably want to make sure you’re watching a 60fps version.

Here are some links to specific parts of the video
Stage 6 Boss appearing – This is a masking / stencil effect created by putting a sprite behind the background layer causing it to cut holes in other sprites without being directly visible

Stage 7 Boss appearing – This flickering shadow is not actually a sprite and is done by using the tilemap enable register, turning it on and off every few frames, previously the tilemaps were alwyas enabled and the shadow was displayed as solid.

Final Boss arms – The arms are priority 0 sprites, and due to the way we cleared the priority buffer to 0 they were never being displayed.

Luca’s addition of Trivia R Us to the Crystal System driver, and discovery that it needed the stack aligned reminded me of something I’d looked at a long time ago with ‘Donggul Donggul Haerong’ another Crystal System game.

I’d made an observation in the past that ram writes on most Crystal System games were aligned, except on the two non-working ones, which at the time seemed like merely an interesting co-incidence.

Looking back at it there might actually be more to this discovery than it first seemed, because patching out the unaligned reads/writes (simply disallowing them in the core) allows the game to work 95% of the time. Sometimes, for reasons unknown it still boots up in a broken state so there is a possibility that the unaligned writes are a symptom of whatever is failing, and causing the RAM corruption, rather than the cause of the failure, or there could simply be multiple issues.

Either way, if you boot the game and it starts without a problem (no graphical glitches) you seem to be able to play it now. Due to not being 100% reliable the game will still be marked as NOT WORKING in MAME, but it has definitely improved.

The 2 Player mode, which switches to a higher 640×480 (presumably interlaced) resolution also doesn’t work properly, it runs twice as fast as it should and only updates one of the playfields correctly, I suspect this is some kind of raster effect involving changing the scroll-values mid-screen and the driver *really* isn’t set up to support this.

It’s possible the CPU can’t do unaligned reads / writes, or possible that disabling them in the core is nothing but a gross hack, it’s hard to tell as other games don’t seem to use them at all, although I would appreciate people giving the other Crystal games a good workout in 0.168 to ensure nothing has broken, if it has, obviously this progress will end up being reverted.

The game is often described as a modern take on Wonder Boy from Korea, it’s easy to see why.

Office Yeo In Cheon Ha also stops crashing with these changes (although there are still some ugly graphics) however not all controls are mapped, so again that one can’t really be considered working yet despite the improvement.

I also moved 2 other games which are meant to be basically Crystal System hardware (same integrated SoC but slightly different surrounding hardware) into the driver just in case somebody like Luca is interested in looking at them too.