David Haywood's Homepage
MAME work and other stuff

DS5002FP Dumping

July 17, 2017 Haze Categories: General News. 11 Comments on DS5002FP Dumping

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.

World Rally 2 seems fully playable

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.

TH Strikes Back can be played until the first boss, but then crashes

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
World Rally 2 screenshots, you can see the direction indicators that were missing before

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

(Dead) Glass PCB (owned by Peter Wilhelmsen)
A Glass PCB that was used in early testing, but unfortunately killed

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

Go to article.. »

Any good Thunder Hoop (1) players with a PCB?

July 15, 2017 Haze Categories: General News. No Comments on Any good Thunder Hoop (1) players with a PCB?

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)

Go to article.. »

The Super Real Darwin Award

July 11, 2017 Haze Categories: General News. 6 Comments on The Super Real Darwin Award

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

Super Real Darwin Super Real Darwin

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.

Go to article.. »

Lucky Poker this isn’t, just plain lucky it certainly is.

July 1, 2017 Haze Categories: General News. 3 Comments on Lucky Poker this isn’t, just plain lucky it certainly is.

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)

eBay picture

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.

Explorer Explorer
Explorer Explorer
Explorer Explorer
Explorer Explorer
Explorer Explorer
Explorer Explorer

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

Go to article.. »

You Don’t Know (Lumber)Jack

June 29, 2017 Haze Categories: General News. 4 Comments on You Don’t Know (Lumber)Jack

Logger is a terrible Donkey Kong rip-off. If the horrible controls don’t put you off (up moves you forward) The even worse collision detection might, the broken jumping mechanics will push you in that direction, the anaemic implementation of Donkey Kong play mechanics are unforgivable, the music offensive to the ears; there’s really nothing at all good to be said about Logger.

If revision labels are to be believed however, Logger actually looked a bit LESS like Donkey Kong in an earlier revision. It still played the same old terrible game, but it looked a bit different. Andrew Welburn and Craig Anstett provided what is meant to be Logger ‘Revision 2’ while the one already in MAME is said to be Revision 3. Here are some screenshots with the newly dumped Revision 2 on the left and the existing Revision 3 on the right

Logger (Revision 2) Logger (Revision 3)

Logger (Revision 2) Logger (Revision 3)

Logger (Revision 2) Logger (Revision 3)

Logger (Revision 2) Logger (Revision 3)

Logger (Revision 2) Logger (Revision 3)

Logger (Revision 2) Logger (Revision 3)

Logger (Revision 2) Logger (Revision 3)

Logger (Revision 2) Logger (Revision 3)

Logger (Revision 2) Logger (Revision 3)

So.. yes, the graphics were redrawn between revisions. I guess it’s important to note that Revision 2 shows an ‘E T Marketing’ copyright while Revision 3 shows the Century, the expected copyright, so it’s possible the changes were down to E T Marketing rather than the revision, but if you look carefully at Revision 3 you’ll see a few graphics that still seem to fit better with Revision 2; the leaf on the 3rd stage for example.

Other than that the Revision 2 set is noteworthy because it uses the traditional Donkey Kong girder level as the gameplay demo, while the Century set uses the 4th and final stage as the demo, which for a newer revision is a little odd because you don’t actually get to play that stage until last, making those attract instructions almost useless for somebody who hasn’t played before.

The Revision 3 set has additional animations, such as the bird flying off and falling down after the 4th stage, Revision 2 has no such animations.

Strangely Revision 2 more correctly refers to the player button as the ‘Jump’ button while Revision 3 calls it the ‘Fire’ button. Revision 3 also re-adds the first incomplete ladder to the girder stage after Revision 2 didn’t bother to copy that from Donkey Kong.

It’s also worth mentioning that the ladder graphics used in Revision 3 do actually appear to be in Revision 2, just unused; the entire reason the platforms are sightly different angles in Revision 2 is that while the Ladder graphics appear to have partial tiles for each of the 8 possible lengths a ladder could be within a tile, while the vine graphics do no, there’s only a single 8×8 tile so everything must be on 8×8 boundaries. It seems like the Donkey Kong ladder theme was actually developed first, but then not used until later? Revision 1 might be interesting if it ever shows up.

Some of the palettes are ugly on both sets, especially the large Crow / Squirrel graphics, but I imagine that’s just how things are.

Let’s be fair, neither of these is worth playing, but it’s great to see them documented as it shows the influence Donkey Kong had on gaming at the time and how others tried to cash in on the success of that game in completely shameless ways.

Go to article.. »

toning down the Waka Waka

June 24, 2017 Haze Categories: General News. 1 Comment on toning down the Waka Waka

The MAME list of supported machines contains a lot of clones, many of them fascinating for one reason or another, just as many quite ordinary, all historically significant.

Sometimes people will ask which clones are interesting and which are not, but a lot of that comes down to personal opinion; if you grew up with a specific clone you’re more likely to have a special place, even if it was just a weak hack to everybody else. Other times you might find a clone with a built-in autofire feature while the other sets don’t have it (or vice versa – the Japanese Raiden II sets lack button C autofire for example, making the game tougher) In other cases there are interesting enemy placement changes, sometimes the games are running different hardware altogether.

Maintaining a list of such sets would be both subjective and a huge undertaking, but from time to time I feel it’s worth pointing out differences when something new comes up, which is where this post comes in.

I recently took a look at the Japanese “Lock ‘n’ Chase” dump, that was apparently dumped 4 years ago, but never added. It required a simple decrypt function to be added for this cassette, but otherwise wasn’t a challenging addition.

Here are two side-by-side screenshots showing the US version (left) vs the Japanese version (right)

Lock 'n' Chase (US) Lock 'n' Chase (Japan)
Lock 'n' Chase (US) Lock 'n' Chase (Japan)

Most obvious changes, the maze is different. The Japanese version contains a ‘pen’ area where the enemies start, very reminiscent of Pacman. In the US version this pen area is gone, and the enemies start near the edges of the maze. The pen area is tricky to navigate without becoming trapped, making the Japanese maze more difficult.

The Japanese version also only contains a single tunnel at the edges of the screen, while the US version contains two.

The Japanese version allows longer high-score names, fairly normal, a lot of Japanese games of the period did, Nichibutsu especially did this often.

Look more closely, on the Japanese version the enemy sprites look more like the ghosts from Pacman, but in disguise, the wavy bottoms of the sprites found in the Japanese version were replaced with standard looking legs in the US one.

Finally let’s do a video comparison (skip ahead to the 3 minute mark, not sure YouTube allows start time to be specified on embedded videos)

Listen to the background sound, and collection sound. Notice how the Japanese version uses sounds cloned almost exactly from Pacman while the US version sounds have been changed to a sound that could pass as unique.

While the game doesn’t actually share any code with Pacman (it’s entirely different hardware, including the CPU and Sound chips) it was clearly heavily influenced by Pacman, with Data East covering this up by making significant modifications for the later US release. Who knows if Namco had a word with Data East and forced these changes, or if Data East felt it wise to make them before that happened.

There was also another version of Data East’s Graplop added, a Japanese release, which again is different to the already supported US sets (title screen actually shows Graplop, as opposed to Cluster Buster on the US parent, or no title at all on the current clone) while the gameplay is closer to, but the same as, the existing clone.

Go to article.. »

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.