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.

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

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.

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)

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.

Have you ever played one of the following Taito titles in MAME?

Rumba Lumber

Chack’n Pop

Onna Sanshirou – Typhoon Gal

Field Day (The Undoukai)

Get Star (Guardian)

or either of the following by Technos and Kaneko respectively.

Nekketsu Kouha Kunio-kun (original Japanese release of Renegade)

Prebillian

If you have played any of them it may (or may not) surprise you to hear that until now they’ve been relying on high level simulations of the protection devices present on the original PCBs, which may have resulted in inaccuracies in the emulation.

The protection devices used were M68705P5 MCUs, a secure part protected against reading. For some Taito games we got lucky and found parts without the security bits set, and for some we found bootlegs and have been unknowingly using bootleg versions of the MCU code for years (much as was the case with Bubble Bobble when we thought the M68705 protected set was the original) however for the above games we simply had no dumps at all of the MCUs and had to rely on simulations.

Thankfully due to new techniques + hardware developed by Brizzo (+ a team of collaborators including Sean Riddle) and access to the collections of ShouTime, Team Japump, and ‘Anonymous Donator’ a way was found to read out even protected M68705 chips with a reasonable degree of success. The technique isn’t perfect yet, as some games gave completely invalid results, but hopefully that’s just a case of further refinement.

As a result of the new techniques the MCUs for the games listed at the start of the article have been dumped, and added to MAME. The relevant Git commits can be seen below

Rumba Lumber
Onna Sanshirou – Typhoon Gal
Get Star
Field Day
Chack’n Pop
Nekketsu Kouha Kunio-kun
Prebillian

As you can see, this allows the removal of a large amount of simulation code, which has been simply replaced with emulation of the actual MCU using the freshly dumped code. In cases like Rumba Lumber the simulation was known to be inaccurate so the game is now emulated correctly, in others, the simulation code was doing things that simply wouldn’t reflect how the MCU would work (plucking values straight from main RAM etc.) so the new handling is a lot more correct to hardware.

In addition to the previously mentioned games the dumps have helped confirm the MCUs MAME is already using for ‘The Fairyland Story’, ‘The Legend of Kage’, ‘Buggy Challenge’, ‘Arkanoid’ (some versions), ’40 Love’, ‘Elevator Action’, ‘Puzznic’ and a number of others to be the correct original MCU code (the dumps MAME expects might change because the new technique can dump previously unreadable parts of the MCU)

The new technique also confirms something that was long suspected: the MCU we’re using for ‘Return of the Invaders’ is a bootleg reproduction. Unfortunately that’s one of the ones where the dumping technique didn’t give us a usable dump at this point, so for now we’re still depending on the bootleg MCU.

The M68705 was a widely used protection device, so having the ability to dump any of them without having to decap is an important step in the preservation of these systems.

Those who have been paying attention to MAME releases may have noticed that back in 0.181 ‘Tokio’ aka ‘Scramble Formation’ also had it’s M68750 dumped and emulated. This was part of the same process and got the ball rolling with some M68705 CPU CORE refactoring in MAME to make the addition of these new dumps a smoother process. Obviously that’s older news now, but a couple of people have asked me if it was related, and yes, it was, it was also one of the more important cases because until then there was no remotely correct simulation of the MCU, only a bootleg where the bootleggers had also failed to understand the protection properly, resulting in many game features not working in their bootleg. The dumping of that MCU was the first time anybody could experience the gameplay correctly outside of the original PCB.

Tokio / Scramble Formation

The other piece of news worth writing about is the addition of a game called Jump-Kun. Ironically this comes from a Taito PCB with a socket for a M68705 but for this game, maybe due to it being a prototype, the socket was left unpopulated and the game unprotected. (The PCB is a Pit ‘n’ Run PCB, in the case of Pit ‘n’ Run the MCU is actually used) It’s believe to have been developed by Kaneko and plays like you’d expect a classic arcade platformer to play. Again, thanks to ShouTime, Team Japump and ‘Anonymous Donator’ for this one.

Jump Kun (prototype)

I also put a video of that one on my YouTube channel

I haven’t really been doing much emulation work lately, even after trying to get back into it I found it to be even less enjoyable than before, just feels like all the fun has been sucked out of working on it, so decided to just delete my MAME account over at Github and get on with other things.

What I have been doing is looking more at the previous generation of games, building a nice collection of Playstation 3 games and trying to expand my knowledge and understanding of things. How games work, not just in terms of code, but logic, systems, balance etc. has always fascinated me, seeing how genres advance, get split up, get combined and how new ideas get thrown into the mix and evolve over time, all that type of thing; this more than anything else is what I’m passionate about researching and building an understanding of.

I always felt that I had a good knowledge for generations before the PS3, especially the arcade side of things from working on MAME for so long, and many of the home systems right from the 8-bit era through to 32-bit, but having been rather put off by some things I was seeing in newer generations I haven’t had that much interest in studying them until now.

I’m not sure why I value this kind of knowledge so greatly, maybe it’s because I do at some point see myself more in a ‘design’ role, looking at game mechanics, refining how the games actually play etc. supported by some programming skills, rather than primarily a programming one, but despite a huge depth to my knowledge already it’s definitely not an easy role to really get a foot in the door with. Maybe it’s just personal curiosity, maybe I just want to create the games in my head and play them out, I definitely do that all the time anyway.

Anyway, something I’ve been considering for a while is doing mini-reviews of the games I’ve picked up, highlighting things I enjoyed, things that irritated me about them, ways in which I feel they could have been improved, or ideas that weren’t used to their full potential, or cases where things have really stood out. I guess there’s potential for it to be a little controversial because some of the games that actually put me off the generation entirely for a long time are ones that others seem to cherish, Heavy Rain comes to mind.

Outside of building the PS3 collection and playing those games I’ve spent an awful lot of time with Terraria on the PC, there are very few games I’d describe as masterpieces, but that is one of them and on top of being an excellent game it has one of the most enthusiastic development teams I’ve seen, always putting out new feature updates, fixing bugs, it’s twice the game it was when I paid for it and probably the only game where I’d be quite happy to buy it again just because I can appreciate the work being done on it, definitely the kind of project I’d jump at the opportunity to be involved with the design of because there’s just so much potential.

Honestly tho, I don’t actually know exactly where my life is heading, I’m definitely good at doing emulation work, but I do need to be able to use the creative skills I have in some way and while the arts in a traditional sense aren’t my strong point I think creativity at a more technical, logical level is more my thing and emulation doesn’t really provide any kind of outlet for that.

For now, I’ll collect, analyse, learn, and hope to actually make use of that knowledge one day.

There are 4 Toaplan games with no sound in MAME 0.180.

These games are Fire Shark, Vimana and Teki Paki and Ghox. The original Japanese release of Whoopee is lacking in sound too but in that case the Export version is not.

The reason these lack sound is simple, the chip shown below.

Each of the above games contains one of these chips. The chip is an MCU containing a Z(1)80 core and various peripherals as well as 16kb of internal ROM data. That ROM data contains all the sound information for the game, all the sound effects, all the music sequences, everything; it makes no use of external data.

Without the internal ROM for each game sound simply can’t be emulated properly, because there’s nothing to use to emulate it. Due to everything being squeezed into the internal ROM space there’s no exploit using external code / data that can be used to dump the roms either as was done for the NMK004 sound system and a number of others.

As a result, these have been considered ‘holy-grail’ targets by quite a large number of people. With that said, I present to you the following 3 videos.

Those videos are all showing proper emulation of the sound, not some ugly trick using samples from the PCB, but the actual sound code running in MAME, driving the emulated YM3812 sound chip.

This was made possible by the decapping work done by ‘Team Caps0ff’ who managed to acquire the various chips that had previously been sent for decapping, take stock, and resume work on them – identifying weaknesses and coming up with a solution, in this case clearing the security bit inside the chip and reading out the data. (They also provided the MCU hookups in the drivers meaning this ended up being a simple case of sitting back and enjoying the results)

Ghox and the Japanese Whoopee PCB using this chip have not been done yet because Caps0ff doesn’t currently have those chips, and has a backlog of other chips to process, but the method used to dump the ones you see is now proven and tested and will also work for those once they’ve been acquired.

The Caps0ff blog contains more detailed technical information on the process used, it’s a fascinating read and shows that these guys really know their stuff :-) Please check it out and show support if you can.

(and yes, this has been my favourite news of the year to wake up to, hence giving it a bit of coverage)