Again, working with Morten Shearman Kirkegaard and Peter Wilhelmsen on this, so any time I say ‘we’ I mean those 2 with me doing the MAME / emulation side of things.
Tracking down Alligator Hunt boards where the Co-processor (DS5002FP) battery was still alive and the SRAM intact was no easy task. Due to the amount of time unprotected / hacked roms of the game have been available, and the fragility of the boards, a lot had already died, or unfortunately have been converted over prematurely by people wanting to avoid them dying, making it impossible to know if they still had valid code in the SRAM or not.
Things got off to a good start when DarkSoft donated an Alligator Hunt PCB to the cause, the battery on that one was showing a worryingly low voltage, but the SRAM was still intact, and we managed to get a dump (complete with Highscores of a previous owner) However, as the dumping process still damages random bytes, a single board was not enough to be confident in enough in the dumped SRAM to say it was good; infact a number of bytes in a data table had to be handfixed just to get it to pass an internal checksum, luckily those bytes all came from one big table which was also present in the unprotected version, however, the code area of the DS5002FP SRAM had no such checksum.
Many sellers of the game were contacted, all but one were selling boards that had already been converted to use the unprotected set, something that is easy to tell from the program checksum printed on the startup screen of the game. The one board that didn’t match the checksum of the unprotected set was however still something of a mystery, it didn’t match the known checksum of the protected set either, so we weren’t exactly sure what it was going to be, but decided to take a gamble on buying it.
When it was arrived, it was dumped, and it turned out to be another unprotected set, which would have been a bit of a downer except for the fact that it was actually a very different set to the one in MAME. The new set has a different background on the title screen and skips the first 2 levels with the skateboarding kids, instead jumping straight to the ship launch and space levels. Obviously my first thought was that it might be some kind of hack, but all the code / data offsets in the ROM strongly indicate it’s compiled / assembled from scratch. Possibly a set used for a show or competition?
What was more curious about this set however, is despite being an unprotected set, not making use of the DS5002FP or SRAM, the voltage on the battery still showed good and the DS5002 box looked like it had never been opened or tampered with. This again makes me wonder if the ROMs on the PCB had been swapped on for a specific event, and then never swapped back to the protected set.
So, come the weekly dumping session it was decided that an attempt would be made to dump the SRAM on this board, to see if it actually contained anything valid. To cut the story short, it did, so this unknown version of Alligator Hunt, despite having an unprotected ROMset on the PCB, actually still contained the original code in the SRAM and gave us the 2nd dump we needed to verify the dump from the board DarkSoft provided. With the 2 dumps I was able to construct what I’m confident is a 100% correct version of the SRAM content which can be used to emulate the protected version of the game with certainty that the correct code is running and correct data is being provided by it.
The protected version we had was actually interesting for other reasons too, it’s has Spanish ‘win-quotes’ between levels, and Spanish subtitles on the cutscenes. Maybe not too surprising because Gaelco is a Spanish developer, but unexpected. I did for a while wonder if the DS5002FP might provide the region as it’s not unheard of for protection devices to supply a region byte; IGS did that all the time for example. You can see an English quote, and a Spanish quote on the screenshots below.
Anyway, my uncertainty over what determined the language was quickly put to rest when I checked my email and found an email from a long-time MAME user who wishes to be identified as ‘Pablo’ saying that they’d dumped the program ROMs from a dead Alligator Hunt they had and one of them didn’t match MAME. The new dump quickly pointed at a byte in the main program ROM controlling the game region thus giving us a new parent set in MAME and making the Spanish set a clone.
Being the curious kind, I decided to see if the byte in question controlled anything else, and to my surprise it did. The byte in question not only controls the game language, but also the region warning (US, NON-US, or none) and maybe most interestingly the title screen. One bit in the byte causes the game to identify as ‘Lizard Hunt’ instead of Alligator Hunt. I’ve not heard of the game actually being released with this title, and no ROM using that title has ever been dumped, but it certainly existed as a possibility, maybe it was intended to be released to the US market with this title instead?
Anyway, here are some videos, first from the newly emulated protected set, second from the new unprotected set.
Hopefully next in line is Glass, we have one SRAM dump from that which works, but like Alligator Hunt, we need to verify it with a 2nd. That would have been done already, except one of our PCBs was in too bad condition to cleanly attach the dumping device, so even if that PCB was working before we started, it didn’t survive the process. We’ve got another PCB on the way, hopefully that one is better, and hopefully we don’t need a 3rd to be 100% sure on it (there’s a possibility of that, Glass uses a lot of data tables, they’re not easy to verify against the unprotected set either)
We’ve still not managed to locate a single working PCB for ‘Play 2000’ which is worrying. Gambling titles are some of the most ‘at risk’ out there due to regulation etc. and ones like this where we know in a few years they’ll definitely all be dead due to the battery are especially at risk. Again, if there’s any possibility you might have one in your collection, please consider donating it.
With the space theme and the title “Lizard Hunt”, is it possible that it was meant to be a reference to the 1984-1985 TV series “V”?
Nice write up Haze. So now which is gonna be the parent rom now? I assume it’s gonna be the protected 1 now with fully working DS5002FP emulation.
I doubt “Lizard Hunt” is a reference to anything, it just feels a bit like a dumbed down title, although at the same time it feels more fitting to the game.
I do wonder if that space take-off scene is a nod to an earlier Spanish game ‘Ambush’ tho. It’s easier to understand than Ambush, but very similar presentation.
The parent set will be the newly dumped English / World ‘Alligator Hunt’ set using the DS5002FP protection.
The current parent (which was the spanish set using the DS5002FP) becomes a clone
The 2 unprotected sets remain clones.
This went in too late for 0.189, so will be in 0.190.
Haze, very nice work. Thank you and the team. It is nice to see the flipsy doodle thing of the space craft and looks fun.
thank you Haze, love seeing it in action in those videos
Sorry, its a bit off-topic question, but how is the progress with the namco system 10 emulation?
Target Hits wasn’t mentioned for a reason?
We have 1 Target Hits and another on the way. We’ll look at it when the 2nd arrives (and cross fingers that the inevitable bad bytes created when dumping are obvious and that we don’t need a 3rd)
Namco System 10 emulation is going nowhere, it was decrytped a while back now, but there’s some other protection device holding things back.
Thank you for the response Haze, hope someone figure it out, threre are some grate games on the system.
hi there david
i did search for your email but could not find it
in the same topic
can you please contact me here :
(address removed for privacy reasons)
Thanks :) And, to complete the DS5002FP topic, could you also mention the protected version of Maniac Square?
We have a dump, it works, we’re waiting on arrival of another PCB to verify it, there are some obviously bad bytes in what we have, but we’ll only be sure with verification; one of the MCU commands doesn’t seem to get used at all.
The PCB that is on the way has a different checksum on the boot screen to any set in MAME, so hopefully it’s also an alt revision, maybe if we’re really lucky it will be an earlier revision that uses all the commands the MCU has (it’s possible one is buggy so they just replaced it with native 68k code in later revision, but that’s just a theory)
Are those “random damaged bytes” really random? The only mention of the source of “bad bits” I’ve seen is in the “DS5002FP Dumping” article, about PCB reset while writing the high scores, but nothing about the ones that possibly appear during the dumping process, nor any examples of the bytes changed.
at some point during the process, maybe when lifting the WE pins etc. on the SRAM some bytes get corrupted, it’s not a bit change, just maybe 10 bytes over the content of the entire RAM end up with random values in them.
strangely this didn’t happen for the first few dump attempts, where perfect reads were obtained (but there was another flaw in the dumping scheme causing some data to be missed) however nothing fundamental was changed in that time space, so was probably just luck.
the bytes definitely weren’t corrupted before the process, as (for example) the first Alligator Hunt board showed CoProcessor OK before we touched it, but CoProcessor Bad after it, because the data area had some corrupt bytes in it and the data area is checksummed.
so why it happens, we don’t know, but it definitely happens. as long as we can get multiple copies of each board it’s pretty easy to work out which the correct bytes should be tho.
worst case the same byte gets corrupt in each dump, but the chances of that are very very low.
Thanks haze for the work. Off- Topic: Any particular idea when seibu original roms gets working without making the clones job? Or they have the same issues like galeco? Thanks.