Archive for July, 2017

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.

The following item was sold on eBay. If you look at the text on the block to the left it says ‘Lucky Poker’ so it was assumed by the seller, and even the buyer (Brian Troha) to be a mostly ROM based version of the Deco Cassette game ‘Lucky Poker’ and sold as such (Luky Poker, for parts)

Now, what actually escaped everybody’s attention at the time is firstly, there’s no way that’s a functioning setup, there’s no such thing as a ROM-only Deco Cassette game unless you install one of Dave Widel’s multigame kits, and furthermore the ROM board pictured to the right is actually something we’ve seen before, it’s the same ROM board used for a ROM overlay on the cassette version of Treasure Island, however Treasure Island only uses 4 roms, this is fully populated.

Now, this detail wasn’t even picked up on even after the PCB has been purchased and dumped, however, since nobody had actually looked at the dump for a few weeks Osso decided to forward details to me and asked if I’d like a look at it.

Since I’d been working on the Deco Cassette driver recently (including working on Treasure Island specifically to decrypt an additional set) a couple of things were fresh in my mind, firstly that this was a ROM overlay board, there are no code roms on it, and secondly that there are only 2 games known to be using such a board: Treasure Island, for which the board has been dumped for years and Explorer, which has proven to be elusive since Al Kossow dumped the cassette back in 2001 (MAME 0.37b13!)

At this point evidence was starting to mount. A closer look at the picture above shows all the roms have stickers with the number ’18’ on them. 18 is the game code for Explorer. At this point I was certain, somehow, almost by complete chance, we’d ended up with one of the hardest to find Data East ROM boards, the missing part of something that had been sat in MAME as non-working for 16 years.

With this in mind I decided to task myself with getting it working in the driver. This wasn’t too tricky, just requiring an additional bank bit to be handled (as Treasure Island only used half the roms so it was never implemented) and a quick change to a bad assumption in the driver that prevent RAM writes when the ROM was banked in. With that done it started working.

So there you have it, a story 16 years in the making with a healthy dose of good luck. Here’s a video.