Team Europe dug up a Yie Ar Kung-Fu running on a Track and Field board.

There are some similarities in the hardware, but this still requires some fairly significant changes to the game code to run (it also seems to be a completely different revision of the game to any of the supported sets, which make me wonder what the source of it is)

I haven’t managed to get the sound working yet, it looks like they’re bypassing the Z80 sound hardware that Track and Field used completely (there is no rom for the z80, assuming it isn’t missing)

The problem was the old code was rendering all the layers in multiple passes (calling sprite draw functions once for each priority and such) which broke basic things like sprite-sprite priority. Each game was rendering different layers in arbitrary order depending on the specific needs of that game to compensate for this.

In cleaning up the code I managed to reduce all the single VDP cases to a single call to draw all the graphics in the correct order, this however broke Batsugun and Dogyuun because the self-contained rendering function broke the hacks which were interleaving the output from each of the VDPs. Batsugun had never worked properly anyway (and had various priority glitches on certain levels and the ending), but with the new code it was completely unplayable in some levels.

I originally wanted to fix this before submitting it, and it was left sitting for a while. Eventually somebody else took a hand at ‘fixing’ the Toaplan2 driver, however the fixes submitted were nothing but further hacks to the driver (checking which level was currently running and further hacking the priority of each layer based on that). The code submitted was gross to say the least, so I decided to submit my code, and demote Batsugun and Dogyuun to Non-working status instead, pending proper fixes which weren’t hacks. My new code was a lot cleaner for every other game in the driver, and I knew it would form the basis of a correct solution eventually, so this was a worthwhile step even if it meant the games were unplayable for several versions.

I tried various things to get the mixing correct with very little luck, and the driver remained in the broken state for quite a few releases. In the meantime I did some further cleanups to the VDP rendering code, and converted it all to use the new C++ devices Aaron had been adding support for in the core. With the GP9001 extracted to its own file, as a proper device, I decided to take another look at the priority mixing, strongly believing that there must be some kind of PAL on the board to mix the output of the two VDPs, because it didn’t seem entirely logical.

One of the big problems was I didn’t know exactly what each VDP output externally. By displaying the output of each VDP on separate screens it was clear the the individual mixing of each VDP was correct, as expected (the mixing code for single VDPs worked fine) However, I didn’t know if the VDPs output any kind of priority data externally to mix with, or just the colour data. A few more attempts later, and I was still getting nowhere with the dual mixing, and almost ready to give up.

At that point Quench came forward with some information that proved to be very useful in the end. He’d managed to reverse the equations of a Pal which sat between the two VDPs on a Batsugun board. From his equations it was clear that the VDPs didn’t output any kind of priority information externally, and the mixing had to be entirely based on the palette index.

I implemented his equations directly, which in theory should have worked, but the results were disappointing, the output was a mess, pixels were showing through where pixels shouldn’t have shown through, and I didn’t know why. I took a break for a week to try and figure out why this might have been, then tried re-implementing it in a slightly different way. Same result.

All was not lost at this point however, because despite the equation not working directly it had provided me with some useful information. I now knew exactly which bits were being fed into the pal, and thus which bits could potentially be used to determine the mixing order, even if the given equation wasn’t working.

Rearranging things a bit I came up with my own solution, making use of the same bits that Quench had figured out were being input into the PAL. The first attempt left some random black dots in the level, quickly realising that where those dots appeared should actually be showing the other VDP I amended my code and had something which worked. Testing the game from start to end showed that all the problematic test cases I’d documented were now correct. Finally.

The other benefit of this mixing was that the tile number hack, which was being used to hide some garbage on the first level of Batsugun could be removed, as it happens the palette index of the garbage is set so that it appears behind the background anyway.

Dogyuun was still an issue, it didn’t work with the new code, however, a bit of testing later, and I’m pretty sure that just uses a simple mixing system, with the output of one VDP appearing above the other, nothing complex.

The net result of this is that for the first time Batsugun can be rendered without hacks, and looks correct on all levels. There is still room for optimization in the code (I’d made it as verbose as possible when debugging, rather than optimized, but it’s correct)

The next step for Batsugun will be adding the missing opcodes and features to the V30 core so that all the V35+ features it needs are supported (register banking etc.) Currently AWJ is meant to be working on this, but I haven’t heard any progress recently. That will allow for full sound emulation in the game.

I may add more technical details to this post later, but for now I have to go out ;-)

I’m *guessing* based on the list at Tilt.it that it’s ‘Gun Champ’ because the description doesn’t match Super Shot (there are no balloons etc.) and it’s definitely not Clay Busters because that appears to be a clone of Allied Leisure’s Clay Shooting. It could of course been an unlisted title. The boards are marked CS235A and CS238A.

If anybody can positively identify this (I’m assuming it was distributed mainly in Italy) then it would help with the name in MAME.

It’s currently unplayable due to some issues with inputs / the shifter emulation (I don’t think it expects the same behavior as the one on Space Invaders)

The answer to this is simple, it isn’t. The actual PGM emulation (aside from the sound chip) is mostly complete. The problem is that every single PGM game has it’s own protection scheme, and the later ones (which is the real reason people complain) are very, very well protected, and are IMPOSSIBLE to emulate properly without expensive hardware decapping because even with trojans you can’t read out all the internal ROM code. (So don’t ask about them)

With that said some of the older ones still present interesting challenges to study. The Killing Blade has been emulated for a long time, but it’s always bothered me that in order for it to run a dump of the RAM content from a running machine was required to bypass proper emulation of a scrambled DMA device. A few days ago XingXing sent me some data from tests he did on the PCB, allowing me to properly implement the transfers and remove the fake ROM. This means that both sets of The Killing Blade now work correctly (previously only the parent set worked, because the RAM dump was incorrect for the clone).

Not that exciting, but from an emulation point of view, good to understand, and it was interesting to find that the xor/add/subtraction table used for the transfers is actually stored at the start of the MCU data rom. Emulating the device also revealed another interesting oddity. Previously an entire block of startup code for the game was missing, because it was put in ram, executed, and erased, and thus missing from the RAM dump. This performs some additional security checks, these haven’t been figured out yet (and aren’t that important, they were completely missing before afterall!), but will present another interesting challenge at some point.

Slightly more interesting is the fact that the chip which is thourgh to be responsible for the scrambled DMA (IGS022) can be exchanged between games, although the chip it’s used in conjunction with (IGS025) can’t..

There is one other game running on PGM that uses this combination of chips, and that’s Dragon World 3, which at this point becomes a potentially interesting target. XingXing provided a RAM dump similar to the Killing Blade one which allows the game to boot, but I’m hoping that it can be elimiated quickly by reusing the DMA code (IGS022) code tha was figured out for The Killing Blade. The problem is the game makes much more extensive use of the IGS025 chip, and currently doesn’t even appear to attempt to trigger any DMA operations. It does boot now, but until those chips are emulated it won’t work, it crashes when you attempt to start a game. Unlike the later games it’s a realistic emulation target at this point however.

Thanks to XingXing for the hardware work / information.

That’s MoonWar, as it’s been emulated in MAME for several years now, and if that was all I was going to tell you then this would be a pretty boring update wouldn’t it?

There are a few things about MoonWar that never quite added up. Firstly, the original boards / roms are all marked as MW2, leading to several people buying them, thinking it was a sequel to the game in MAME, only to find out it was exactly the same game, with exactly the same titlescreen.

A few years ago another board marked MoonWar turned up, but this time it was a Frenzy board, Stern’s old hardware, not related in any way to the hardware on which the known version of MoonWar ran on. Sadly, the only thing populated on this board were the Speech roms, for the S14001A sound chip which Berzerk, and Frenzy used for speech. Sure enough, the roms contained speech clips which sounded like they could be from a game called ‘Moon War’, but there were no other roms, and the whole thing looked like it was probably just some one-off prototype that was lost forever.

This left as many questions as answers, because the Frenzy hardware is vastly inferior to the hardware that the known MoonWar game ran on and definitely wouldn’t have been capable of running a game resembling the known game. Frenzy was also released in the same year as the known MoonWar game, and only a year after Berzerk which didn’t exactly leave a large timeframe for the development of two ‘MoonWar’ games, so what exactly was this mysterious board, and did Stern really make 2 MoonWar games?

Yesterday that question was finally answered. Team Europe & Volker Hann dumped a Frenzy board which was missing it’s sound roms. That board turned out to be running MoonWar. The existing game in MAME really is a sequel, hence the MW2 markings. Stern probably weren’t happy with how limited this game on Frenzy hardware looked, so just aborted the project before giving it a wide release. By combining the old ‘speech only’ and the new dump which was missing the speech roms we appear to have a complete set. As you can see from the screenshots below, it’s a significantly less advanced looking game than the previously known MoonWar (and it really was developed in the same year) but unlike the ‘sequel’ / released game it’s full of Speech just like Berzerk was, it’s a shame they didn’t include any of that in the sequel!. There’s even a nice little Evil Otto reference in there.

It uses some kind of analog dial for rotation of the player ship, which I haven’t quite managed to hook up correctly yet (I can only rotate in one direction) Other than that it an be played. My only concern is if there is a mismatch between the program roms and the speech roms, because the speech sometimes talks about ‘Hyperflip’ and I haven’t worked out what it means yet. (although I have warped from one side of the screen to the other sometimes, so it might just mean that)

Another rare piece of history uncovered anyway, such things always bring a smile to my face especially when they just turn up out of the blue like this.

Here is an audio recording of it running in MAME, for those interested.

The same guys also dumped a very rare version of Berzerk with German speech. It’s a different code revision (appears to be based on the ‘new’ rules found in the parent set) Somehow the Robots sound even more intimidating when they speak in German! You can hear that here. It’s been a very good week!

A few days ago the Dumping Union acquired an interesting looking Korean arcade title called Mr. Dig. The game was released by Korean company ‘Sun’ (no, not the Java people) and runs on an arcade PCB using the Hyperstone CPU. This hardware was used for a number of Korean games and the CPU wasn’t really used for any arcade titles developed outside of Korea.

From the screenshots the game looked like some kind of copy of Namco’s Mr. Driller. Unlike most Korean games we knew that it couldn’t just be a bootleg of Mr. Driller with various hacks applied because it was running on completely different hardware; the original Mr. Driller runs on Playstation 1 based hardware, which is driven by a MIPs based CPU and is ’3d’ hardware. The Hyperstone CPU definitely isn’t binary compatible with the PSX code, and the graphics hardware is completely different. Screenshots also showed a 2 player mode, which Mr. Driller doesn’t have.

Let me stress again, this game is not a bootleg, it contains no Namco code at all. I actually don’t even think it directly steals any art from the original game, it’s a reprogrammed game, the code has been rewritten from scratch, and the art, while clearly influenced by the original art appears to have been redrawn too.

With that in mind, look at the screenshots below to see just how far ‘Sun’ went in order to try and imitate the look and feel of the original ‘Mr. Driller’ game when they produced their own version ‘Mr. Dig’ (note, the Mr. Driller screenshots are scaled for easier comparison, the original runs at a higher resolution than Mr. Dig)

I’ve also included some screenshots at the end which demonstrate the unique features that ‘Sun’ added which aren’t present in the original game. These include Bombs (which explode a few seconds after you touch them and are hazardous as a result) and ‘EXTRA’ letters to collect. In addition there is the aforementioned 2 player mode. You’re not prompted to start a 2 player game, but one can be started by pressing the 2nd player start button during the mode select screen. The winner appears to be the player who can survive the longest, or, I assume, get the the bottom first. You can’t simply wait around to avoid dying either as the game will kill you if you don’t move for a while.

I’d like to thank the Dumping Union for getting this PCB, I know it wasn’t the cheapest game but it’s a fascinating insight into Korean development, showing what was going on during a transitional period in the industry as they were moving from producing mostly bootlegs using hacked code from popular games with new graphics / sounds) to actually writing their own code; in this case writing their own code, but learning by imitating others. Cheesy as it might appear I think it’s an important part of history :-)

New stuff only in Mr. Dig

There are still some 1 frame sprite glitches (like the other GX Type 4 games), and a problem with the background layer not wrapping properly (see the crowd, Rushing Heroes suffers from the same issue), bad sound (the sound rom is still bad), and the only the left screen working properly, but it’s basically fully playable for the first time, as can be seen below.

That’s not the only unification that’s going on at the moment however. As followers of this site may have noticed, I’ve always prefered the MAME style ‘software lists’ over the open-ended approach taken by MESS with regards to loading software hence the creation of side-projects such as HazeMD and TinyCDI which serve to document both the hardware AND the software released on a platform. Changes are underway in MESS right not to bring that concept to MESS alongside the existing open-ended loading (for homebrew etc.)

This will bring MESS much closer inline with MAME’s level of documentation and policies, properly documenting what software was available for each system. The MAME / MESS database format provides a more comprehensive way to document cartridges than the existing databases which are available, and will allow proper cart dumps, with proper rom naming to be supported just as easily as in MESS. It will also inherit the parent/clone relationship system from MAME, and have fields for Manufacturer, and Year information, just as can be found in MAME.

Hopefully with changes like this MESS can become the ultimate database for Console informaiton, much as MAME has become for Arcade systems. The current databases are limited, and despite their intentions are unable to properly document some details about the cartdiges (such as the actual ROM labels, # of roms, sizes etc.) so assuming MESS can get some traction in this area it is more than capable of becoming a far better reference than those already out there. This is something I’ve wanted to see for a long time because while the existing console ROM formats are great if you just want to play games in any given emulator they fail to actual document things the way MAME does. As the games become older starts to become more of a priority, and isn’t something you can rely on the various rereleases on modern platforms because those are simply about playing the games, so it’s important for other people to document it. There are other advantages to the MESS / MAME database too, for example, the development team make no claims of ownership over the database, once exported from the executable you’re free (and even encouraged) to use / import the information for use in your own emulator, so that things can be consistently and correctly supported.

This should also lead to it being possible to create sites like The fantastic MAWS from the MESS database, and also easier set-name based bugtracking and regression testing as is used on Mametesters. It’s a large undertaking, but as long as people can get behind the idea, and support it then it could be of great benefit to everybody who cares about the history of Computer / Console software, and the emulation of these systems.

This could well be the start of a unified database system for Computers / Consoles, and the first step in the Console emulation scene growing up to be something that’s more than just about ‘playing the games’. Here’s hoping.