We picked up 2 more TH Strikes Back PCBs (thanks to Kevin Eshbach for providing one of them) and dumped the DS5002FP SRAM on each of them.

Using the existing read, and these 2 new reads we were able to apply a ‘majority wins’ rule on each byte and obtain a correct dump. (about 5 or 6 bytes differed from each board but never the same bytes)

These bytes have all been hand verified, so now I’m confident we now have a 100% good dump of the DS5002FP SRAM for TH Strikes Back (Thunder Hoop 2) as a result the game works fine in MAME (aside from some video priority glitches on the title screen but these are unrelated to the protection)

Note, we still need another PROTECTED (not converted to de-suicide ROMS) Alligator Hunt to verify the dump we did of that before releasing it and at least one additional Target Hits (we only have 1 copy) before we can confidently release that also. It’s fairly clear at this point that random bytes get corrupted during the process, so without multiple copies to dump we can’t trust the data.

Also the call still goes out for anybody with a working Play 2000, ideally 2 people.

It’s easy enough to tell if you have an Alligator Hunt where the battery still works as the protected sets will save the Top 2 high scores to the SRAM so those scores are retained even after powering down the PCB. The desuicide sets have nowhere to save it so the top 2 scores reset to default when you power off. We need another working copy of the protected version (ie the one that saves the top 2 scores)

The other way to identify the protected version is if it shows ‘CHKSUM ROM: 2B34128B’ on startup, these boards are useful to us.

A board that’s already been hacked to not use the battery will show ‘CHKSUM ROM: F9C6891D’ instead, such boards are useless to us as the SRAM on them is already dead.

There are no known unprotected versions of Target Hits or of Play 2000, so if you have either of those in working condition we could do with them.

We currently have a number of Glass boards, and hopefully 2 Maniac Square boards and will tackle those soon.

Please note that once we have reads we’re happy with they can be used to repair dead boards, but we don’t want to release dumps until we’re confident about them as there becomes a risk of people trying to repair boards with bad data, making it more difficult to obtain the PCBs we need to verify it.

Here’s a video of TH Strikes Back

“neohyphengeo productions” picked up a rather rare clone a few months back and has kindly had it dumped. This, luckily for us means it’s not going to end up becoming one of those clones that seems more like a myth than a reality.

The clone in question is a rare version of “DoDonPachi Dai-Ou-Jou” that simply goes by the title “DoDonPachi III” and was meant for non-Japanese markets.

Revision-wise it sits somewhere between the original release of DoDonPachi Dai-Ou-Jou and the Black Label version, and apparently incorporates some of the gameplay mechanics from the latter. I’m not however versed on the actual details.

Some strings, such as the character select page have elements translated to English, the ending appears to have been as well, although a lot of text remains in Japanese.

This will be supported in MAME 0.189, thanks again to “neohyphengeo productions”
I believe more details will be released over at the neo-geo.com forums fairly soon.

The new DoDonpachi III set, aimed at Non-Japan markets

The better known Japanese release ‘DoDonPachi Dai-Ou-Jou’ for comparison

Team Caps0ff proved that they could handle the HD647180 MCUs used by a number of Toaplan games last year when they managed to deprotected and read out the sound MCUs from Fire Shark, Vimana and Teki Paki.

Now, using chips provided by members of The Dumping Union they’ve completed the task of dumping the HD647180 MCUs used by Toaplan by processing Ghox and the Japanese release of Whoopee (which for whatever reason used a HD647180 while the World release used a Z80) Assuming no music was changed (and I don’t think it was) Whoopee is identical from the point of view of an end user and is more of a technical achievement. Ghox however is more interesting, and not only because it’s the first time the game has had proper sound emulation.

I’d actually been curious about Ghox for a long time, not because of the sound like most people, but because of a background rendering glitch on the High Score table. I’d rewritten the video code for the Toaplan games a few years back but was never able to figure out why the background didn’t appear properly and ended with a gut feeling it had something to do with the protection.

With the sound MCU dumped it turns out that feeling was correct; when running the original MCU code the background appears correctly. Not too surprising because the MCU actually supplies data in shared ram, and a tiny snippet of 68k code for the main CPU to run in the case of this game.

As more people are likely to be interested in the sound, here’s a video of me playing the game badly followed by me going through sounds in the sound test.

Morten Shearman Kirkegaard and Peter Wilhelmsen devised a method to dump Dallas DS5002FP chips.

Anybody familiar with arcade games will know that these chips are found on a number of Gaelco games that were released in the 1990s.

The chips are particularly evil because they have sophisticated anti-tamper methods with code stored encrypted in a battery backed SRAM chip. Just looking at them funny can cause them to fail. Until now nobody with any emulation connections has been able to dump them.

The guys published a paper on their methods, it can be found here. It outlines the weakness that was exploited, and the code + hardware that was used to do it.

What we’ve found is that a number of these Gaelco games do seem to already be on their last legs, system11 recently had a malfunctioning Glass board, and the World Rally 2 board that was used for these tests also had a pre-existing fault which turned out to be due to at least one byte going bad in the internal SRAM. It’s absolutely critical that these things are dumped soon or chances are they’ll no longer work. It’s also important that each one is dumped twice from different PCBs to guard against bad bits that might influence how the games run.

The main benefit in terms of MAME from this dumping process is that World Rally 2 now appears to be playable after I took the time to track down the bad byte (it was in the steering code, which is mostly shared with the original World Rally luckily enough) Here is a video of it running in MAME.

Touch and Go was also dumped, and appears to run, although has trouble finding it’s high score data for reasons I haven’t yet figured out. Unless I’m mistaken (which is possible) the games actually use the SRAM not only to store critical game code and data, but also in some cases it appears to store scores and even as temporary work ram. That actually scares me because it means one crash of the game while the CPU is in a state with memory access could potentially wipe out important game data, which might be how some of these bad bytes came about. Touch and Go has the same sound problems as the Korean set, but that’s not surprising as that seems to be an issue in the Gaelco sound core and needs investigating.

The other thing that was dumped at this time is TH Strikes Back (aka Thunder Hoop 2) but unfortunately even with the DS5002 dump the game is still crashing when you reach the end of a level. This is a big improvement on before, but we currently don’t know if this crash is a dumping error (faulty PCB?) or an emulation bug (the i8051 core that’s used as the basis of the DS5001FP emulation isn’t as well tested as many others) Here’s a video showing the first level. I did work out a level select cheat, and you get similar problems at the end of all but 1 of the other levels.

Thanks to the generosity of people including Charles MacDonald, Brian Troha and Darksoft at least one copy of most of the other PCBs is on the way to be dumped, or to be used as verification for the dumps that have been done. As I said, ideally at least 2 copies of each board are needed and given the high level of risk involved in the process (there’s always a chance of it completely failing) in some cases more might be needed.

We have not managed to source a working copy of the ‘Nova Desitec’ gambling / poker Game “Gran Tesoro? / Play 2000” (title could be incorrect) which is the only other title confirmed to use this protection chip. Even back when that was dumped the two boards that were found were both completely dead, so if you do have a working one of those, or any other previously unknown board using the DS5002FP then you should probably consider donating it to the cause because as mentioend these things really do seem to be on their way out at this point.

World Rally 2 screenshots, you can see the direction indicators that were missing before

An Alligator Hunt PCB that has been sent by Darksoft for tests, cover for DS5002FP not removed

A Glass PCB that was used in early testing, but unfortunately killed

The Gran Tesoro? / Play 2000 PCB, already dead, anybody have a working one?

Just putting this out there

I’m trying to improve the priorities in this game (and some of the other older Gaelco drivers in general, as the priority handling seems a bit hacky)

However, I can’t find any playthroughs of Thunder Hoop 1 that were recorded on an original PCB, only videos from MAME with all the priority bugs present, so ideally, if anybody out there has the actual PCB for the game and is good enough to do a playthrough and record it at a high quality for YouTube that would assist me in knowing what to aim for; there are quite a lot of priority cases where I’m not really sure what should be displayed.

Also if anybody can verify, on the PCB, the bug whereby if you die for the first time on level 4 without dying earlier in the game it crashes, that would be handy too, but given how easy it is to die in the game that’s quite a bug ask. It seems unlikely this bug is emulation related, and much more likely it’s an original game bug, but it would be handy to know for sure.

The best video I can find is https://www.youtube.com/watch?v=ThB-RQfcLBc (which is an excellent quality video, and shows me a number of good cases in the first level, but that doesn’t cover the whole game)

Super Real Darwin is a game that was released by Data East in 1987

It has been emulated in MAME for a VERY long time. Imperfectly.

If we look at the MAME history of the driver, this is an important entry.

“0.35b12: Boss order in Super Real Darwin should be correct [Jose Miguel Morales Farreras]. Added 2nd player.”

MAME 0.35b12 was released on 1 May 1999, that was the last development on the driver that had any real impact on the gameplay.

The change listed above, made in 1999 is the source of the following piece of code in the simulation of the i8751 protection device that Super Real Darwin makes use of. Prior to this the boss order was *completely* wrong.


The table below is hopefully correct thanks to Jose Miguel Morales Farreras,
but Boss #6 is uncomfirmed as correct.
*/
if (m_i8751_value == 0x8000) m_i8751_return = 0xf580 + 0; /* Boss #1: Snake + Bees */
if (m_i8751_value == 0x8001) m_i8751_return = 0xf580 + 30; /* Boss #2: 4 Corners */
if (m_i8751_value == 0x8002) m_i8751_return = 0xf580 + 26; /* Boss #3: Clock */
if (m_i8751_value == 0x8003) m_i8751_return = 0xf580 + 2; /* Boss #4: Pyramid */
if (m_i8751_value == 0x8004) m_i8751_return = 0xf580 + 6; /* Boss #5: Snake + Head Combo */
if (m_i8751_value == 0x8005) m_i8751_return = 0xf580 + 24; /* Boss #6: LED Panels */
if (m_i8751_value == 0x8006) m_i8751_return = 0xf580 + 28; /* Boss #7: Dragon */
if (m_i8751_value == 0x8007) m_i8751_return = 0xf580 + 32; /* Boss #8: Teleport */
if (m_i8751_value == 0x8008) m_i8751_return = 0xf580 + 38; /* Boss #9: Octopus (Pincer) */
if (m_i8751_value == 0x8009) m_i8751_return = 0xf580 + 40; /* Boss #10: Bird */
if (m_i8751_value == 0x800a) m_i8751_return = 0xf580 + 42; /* End Game(bad address?) */


A couple of months ago Caps0ff dumped the actual i8751 MCU from Super Real Darwin, and today I studied that dump, and hooked it up.

Maybe it shouldn’t come as too much of a surprise that the above piece of simulation code is incorrect, and has been incorrect since 1st May 1999, over 18 years ago.

The value in the table for Boss 6 is actually incorrect as the comment speculates is possible. The code for handling MCU command 0x80xx in the actual MCU dump is as follows, you can see where I’ve commented the different value in the actual code compared to the existing simulation.


-- handling 0x80 (boss selection)
01E7: 75 D0 00 mov psw,#$00
01EA: 11 E7 acall $00E7
01EC: 54 0F anl a,#$0F
01EE: C3 clr c
01EF: 33 rlc a
01F0: FA mov r2,a
01F1: 24 11 add a,#$11
01F3: 83 movc a,@a+pc // 0x1f4 + 0x11 (Table below)
01F4: F8 mov r0,a
01F5: 0A inc r2
01F6: EA mov a,r2
01F7: 24 0B add a,#$0B
01F9: 83 movc a,@a+pc // 0x1fa + 0x0b (Table below)
01FA: F9 mov r1,a
01FB: 89 80 mov p0,r1
01FD: 31 00 acall $0100
01FF: 88 80 mov p0,r0
0201: 11 F9 acall $00F9
0203: 01 D2 ajmp $00D2

-- protection table
0205: F5 80 mov p0,a /* Boss #1: Snake + Bees */
0207: F5 9E mov $9E,a /* Boss #2: 4 Corners */
0209: F5 9A mov $9A,a /* Boss #3: Clock */
020B: F5 82 mov dpl,a /* Boss #4: Pyramid */
020D: F5 86 mov $86,a /* Boss #5: Snake + Head Combo */
020F: F5 8E mov $8E,a /* Boss #6 - F598 is used in the simulation! */
0211: F5 9C mov $9C,a /* Boss #7: Dragon */
0213: F5 A0 mov p2,a /* Boss #8: Teleport */
0215: F5 A6 mov $A6,a /* Boss #9: Octopus (Pincer) */
0217: F5 A8 mov ie,a /* Boss #10: Bird */
0219: 00 nop
021A: 00 nop


Boss 6 has 2 forms, after you destroy the first form / pattern it evolves into the 2nd form. The value in the table above puts the boss directly in the 2nd form which causes issues with how it appears, priority, and of course makes it a lot easier than it should be as you only have to destroy the 2nd form. Using the real MCU dump (or a corrected value obtained from it) gives the correct boss form / order.

I’ve recorded 2 videos of this. First is the old, buggy behavior. (Cheats are enabled to make demonstration easier, so nothing can kill me)

The 2nd video is the fixed behavior, which should be how things are as of the next MAME release.

I’ve had to bump the interleave in the driver significantly to stop it missing protection commands from time to time and crashing (hopefully what I’ve done is good enough) but the actual data from the MCU is now 100% correct to the original as we’re running the actual MCU code rather than a simulation. This is just one of many reasons why getting certain MCUs to people who can dump them is important, you never quite know if things are accurate until you’ve studied the real code.