Archive for August, 2015

Ever wondered how the HDDs on arcade games get updated to new versions? Probably not, but I’m going to show you one example anyway.

Sometimes floppy disks would be used (but this could be inconvenient, as most arcade systems didn’t have floppy drives by default) and in other cases CDs would be used (again not ideal if the game didn’t have a CD drive)

The alternative, and case I’m going to cover here is when a game was updated by using ROMs.

If you owned a Gauntlet Legends ‘1.2’ and wanted to update it to ‘1.6’ then it was necessary to update the game data on the hard drive because this is where the bulk of the game code is stored – the main bios ROM is just a boot loader. In order to facilitate the upgrade Midway provided a kit for this, it looked like this

opened up, the box contains the following

As you can see, there are 4 ROMs in the box. One of them (the one with the Red/Orange sticker) is a replacement BIOS / boot rom. The other 3 exist to upgrade the hard drive.

Show below is a Gauntlet Legends PCB set (not the best picture, just one I found, if anybody has a better one I’d like to replace it)

You can clearly see the bios rom with the Red/Orange sticker on the lower part of the middle PCB, and next to it is a single empty socket.

How does that work? Well, the socket there is used for upgrading the hard drive data, but as you saw from the kit pictures there are 3 upgrade ROMs but there is only one socket. It turns out the upgrade is a 3 step process, you must boot up the PCB with each of the roms in turn, let it do it’s work, then move on to the next one. This is because the update data is larger than could fit in a single ROM.

Thanks to rtw and Smitdogg those roms pictured are actually dumped, and just for fun I decided to hook them up in MAME.

If you load the 1.2 set in MAME you can see the following.

Without any update the 1.2 set boots up and has 1.2 in the corner of the boot screen, and in the test mode shows ‘GUTS 1.4 Oct 22 1998 11:23:04’ which is the code revision on the hard drive, yes, a 1.2 Gauntlet Legends is actually version 1.4 but that’s Midway for you.

Boot with one of the upgrade ROMs in the empty socket and the bios recognizes it and gives you the following

The first ROM takes a while because it does a disk check, but eventually you’ll get

Follow the instructions (power off) and boot with the 2nd rom in place

Same process, but without the disk check. Do it with the 3rd ROM and you get

A reboot later, with the update ROM removed (all the update data is loaded to the hard drive at this point) and the game actually starts performing the update.

Reboot again and you have a version 1.6

Version 1.6 actually has an internal code of GUTS 1.5 Jan 14 1999, but again, that’s Midway being Midway.

This was all fairly straightforward to hook up in MAME, and while it’s a little pointless (we already have 1.6 as the parent set) it’s nice to be able to go through the whole process in an emulated environment. There was one hitch, the CHD for 1.2 had been created with bad geometry, and upon attempting to write to it the updater software actually corrupted the HDD rather than updating it. By recompressing the 1.2 CHD with valid geometry for a Quantum Fireball 2.5Gb this problem was bypassed, although it makes me wonder just how many other CHDs in MAME have been created with bad geometry, even more worrying is that the badly guessed sizes are slightly shorter than the actual drive type used so we’re probably lucky there was no data at the end.

These update roms have actually been dumped for quite a while (thanks again rtw and Smitdogg) but until now nobody really showed an interest in them.

If you want to follow the procedure yourself I’ve hooked it up in MAME so that you can use
mame64 gauntleg12 -bios up16_1
mame64 gauntleg12 -bios up16_2
mame64 gauntleg12 -bios up16_3
to run with the different update roms, although it does expose a limitation of the -bios system, because we really need to allow for multiple different bootroms too, and -bios is a global. For this reason I’m actually contemplating putting the update roms in a software list instead, using a slot device, it seems more logical to me, afterall they are purely optional. (meaning things could change between the code that’s in the GIT right now and what gets released in 0.165)

If you’ve been following the GIT you might have noticed that MooglyGuy checked in a change to the Midway Zeus driver to improve the blending / transparency effects in Mortal Kombat 4.

Mortal Kombat 4 makes rather heavy using of the blending in places, applying it to a large number of particle effects, projectiles etc.

Pictures convey this far better words, so in short we’ve gone from this

to this

He advises me to make clear that the code is still a little hacky (the bit that controls the blending hasn’t been fully isolated) so it might not alwas be 100% correct, but as you can see, his work has made a dramatic improvement to the visuals in a driver that had been left untouched for far too long.

Note, this doesn’t improve Crusin’ Exotica, that runs on Zeus 2 which is significantly different.

What’s Yellow and Blue and absolutely everywhere right now? Minions of course..

I therefore find it rather fitting that the protagonist for this next game is likewise rather Minion like. Of course, being a 1994 prototype from Kaneko it isn’t actually a Minion, unless they invented Minion robots and sent them back in time, but it’s close enough to make me smile.

The game, aquired by rtw is one we’ve been sitting on for a little while actually, it runs on Berlin Wall hardware (in the kaneko16 driver originally by Luca, but where I’ve also done a fair amount of work, eg. B.Rap Boys etc. a few years back)

A few unemulated hardware features were used including brightness controls on the background layer, Berlin Wall actually uses this too to fade the colour on the title screen after inserting a coin (clone sets only) but the need for it wasn’t as apparent. One thing that actually caught me out and needed verification is that backgrounds actually fade OUT during gameplay, so most of the time you’re playing against a black screen, odd choice, but that is how the game is, possibly due to it being a prototype.

One thing that is definitely due to the game being a prototype is a crash you can trigger.

In normal circumstances the game has no continue feature, however, if you’re playing on the ‘Normal’ or ‘Hard’ courses the game has bonus rounds (where for example you fight the spider, last screenshot above)

If you die on one of these rounds the game DOES offer you the chance to continue, if you take the continue the game will either immediately crash with an ‘ADDRESS ERROR’ flashing briefly onscreen after an explosion (for about 1 frame before restting) or give you a level with a corrupt enemy then crash after that. Again this happens on the PCB, due to the game being a prototype. With a bug like this the game would not have survived a location test as it simply steals your credit if you attempt to continue.

The game has a dipswitch controlling the region (World, Japan or Korea) for Japan the text is Japanese, for Korea the text is English but the Kaneko Cat logo is used on the title screen. These make no difference to the above crash issue tho, nor do any other dipswitches (there’s no way to disable said broken continue feature)

The game actually has a flyer, and (strangely for a prototype) an operators manual, suggesting this was quite late into production.

What’s interesting about the flyer is that it depicts a number of screens that do not appear to be used in the version of the game we have, the enemy select screens for example never appear. The background graphics for them are in the ROM, and can be viewed in the background viewer, but they’re not used, this actually suggests there might be a more ‘final’ version of the game than the one we have, assuming the shots aren’t mockups. Other differences include a dividing marker between the two halves of the playfield, again simply not present in the version we have and the backgrounds being active during gameplay when the set we have very specifically fades them out. If a more final version does exist we’ve never seen it (until this one showed up we’ve never even heard of this game, so it’s quite possibly already lost)

There are other unused graphics in the background viewer (or at least I think they’re unused) including what looks like an alternative title screen.

The game? I haven’t really written much about the game here, it’s a simple Vs. competitive game (Vs. CPU or Vs. Player) Each player stands on a number of blocks, bombs drop down from the top of the screen, you’re restricted to your half of the screen and must catch the bombs and toss them over to the opponents side, after a short time (in which the opponent can try to pick them back up, assuming they’re not on the spikes at the bottom) they’ll explode, destroying blocks. If either player falls on the spikes they lose, this usually happens once you’ve blown up all their blocks.

In all honesty I can see why it wasn’t the most popular of games. Berlin Wall was released in 1991, and while it’s not as much fun as the home adaptation Kaneko did (Wani Wani World on the Mega Drive, one of my favourites on the platform) it’s still a challenging and decent ‘Space Panic’ clone. This game seems as much luck as anything else, rounds are over very quickly, and if you end up behind there doesn’t seem to be much chance for recovery; in a 2 player game you’re likely to get less than a minute of competitive gameplay for your money.

Overall, this is an interesting piece of Kaneko history, especially considering we really don’t have much in the way of prototype material from Kaneko, but I don’t think it was ever going to be a hit, not even if somebody were to reskin it and rereleased it today with actual Minions.

Again big thanks to rtw for this one, it wasn’t cheap.