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)