David Haywood's Homepage
MAME work and other stuff
July 17, 2014 Haze Categories: General News. 4 Comments on Semi-Semicom

Osso recently purchased an unknown Korean title called ‘Rolling Crush’ and donated the board to Caius for dumping.

Upon arrival Caius posted a picture of the PCB.

Rolling Crush PCB
(Rolling Crush PCB)

There are a few distinguishing features about the PCB, first of all it uses an MC68EC020 rather than a regular 68k like most Korean games, second and most significantly it had an AT89C52 MCU. These features instantly allowed me to identify it as a Semicom PCB, and as it happens it turned out to be the same PCB as Dream World.

Dream World PCB
(Dream World PCB)

The boards are essentially identical, but Rolling Crush does not have one of the AD-65 (sound chip) positions populated (top of the images). Interestingly this would bring it closer to the Baryon profile, which uses only a single AD-65 as opposed to the dual ones used by Dream World, however that PCB is a slightly different design.

Baryon PCB
(Baryon PCB – not identical)

Now this was interesting because the game was not sold as a Semicom game, nor did any of the provided screenshots or videos show a Semicom logo or Semicom copyright, furthermore it does not appear on any official list of Semicom games I’ve seen. The video Caius provided is embedded below. The blue-white colour fade on startup is the same as Baryon, and the sound effects (coin etc.) are also clearly Semicom but that’s as far as the obvious signs go.

Content not available.
Please allow cookies by clicking Accept on the banner

Once the dump arrived I looked in the main program roms of the game, and as expected there were a variety of Semicom related messages, looking in the graphic roms further bolstered my view that this was a Semicom development, the usual Semicom ‘Unicorn’ and could clearly be seen there too.

Rolling Crush

Unsurprisingly it was also protected like the other Semicom games too, with the MCU supplying the interrupt routine for the game at startup. This kind of protection is easy enough to deal with, I modified some code I’d used to extract the data from Dream World and Baryon, Caius then ran that code on the original hardware and took some pictures.

Rolling Crush

After entering all the data the game successfully booted in MAME. I tried playing with the various dipswitches to see if one showed a Semicom copyright, but none of them had that effect.

Rolling Crush Rolling Crush
Rolling Crush Rolling Crush
Rolling Crush Rolling Crush
Rolling Crush Rolling Crush
Rolling Crush Rolling Crush
Rolling Crush Rolling Crush
Rolling Crush Rolling Crush
Rolling Crush Rolling Crush
Rolling Crush Rolling Crush

One thing I had noticed when looking at the program roms was a credits roll including names of Semicom staff, viewing this of course meant I would have to complete the game, and even on the easiest setting things started to get very difficult on the later stages. Thankfully MAME has cheat finding capabilities built into the debugger, and even if they’re not as good as they used to be I was sill able to use them to find some cheats allowing me to finish the game.

Finishing the game (50 stages) yielded the following credits roll after a psychedelic ‘Congratulation’ message.

Rolling Crush Rolling Crush
Rolling Crush
Rolling Crush
Rolling Crush
Rolling Crush
Rolling Crush

So there you have it, the actual Semicom copyright, inexplicably only visible for a brief second once you finish the entire game! I don’t think the game is a hack or a bootleg* instead it was probably simply licensed to ‘Trust’ for sale / distribution. I wonder if there is an alt. version out there actually using the other Semicom graphics that are present in the roms.

*I’m aware the gameplay is a complete rip-off of Puzzloop, but the code and other assets are original

*edit* ArcadeFlyers has a flyer for the game, also mysterious because it too lacks any manufacturer information.

Rolling Crush Rolling Crush

While the flyer lacks manufacturer information it does still hint at Semicom, the layout of the back page is similar to More More Plus with the ‘MEMO’ box.

More More Plus


You can follow any responses to this entry through the RSS 2.0 feed.

Hey, Haze!
Can you explain us the funcioning of the custom code you’ve developed and run on the original board and how does that break the protection? I’d be glad to learn how these techniques work and what are the encoding/decoding/math principles involved.

Is this code published somewhere for us to study it?

happy hacking,
Felipe Sanches

Thanks for taking the time to work on this game!


the code is nothing special, because the protection is so simple.

All I did was take a copy of Dream World, patch it not to use the protection (but instead use a ROM copy of the code that usually gets placed in RAM), then replaced the code that draws the sprites with code to draw the content of RAM so we could see what this MCU returns instead.

I split the viewer into 0x40 byte pages, controlled by a dipswitch, with a CRC32 on each page to validate the data.

It’s crude, and a bit glitchy because the board is fussy about sprite timing and / or some sprite addresses but it got the job done. I don’t think the actual internal ROM of the MCU can be dumped, but this extracted protection data is all the game needs to function because they make no use of the MCU other than reading out a stream of protection data on start up.

The screenshot in the update is a view of Page 0006 (value shown bottom left), so the dipswitches were set to 000000110 (6) this means it was viewing address 0xffd000 (RAM) + 0x6 * 0x40
the value bottom right is the CRC32 of the 0x40 bytes shown onscreen.

Thanks for the explanation. I think I get it (maybe!). My understanding based on what you said is that the ROM data is scrambled with some protection algorithm and that by running an alternative program in the board and fetching a log of the RAM contents via sprites on the screen you can map that to the actual ROM you loaded and then figure out the scrambling patterns. Then this scrambling is implemented as driver code in MAME (instead as emulated microcontroler code running in a core emulationg in MAME) in order to run the game properly. This would mean the microcontroller unit is not even instantiated in the MAME driver, right?

If that’s the case, then, the driver does not tightly map to the actual hardware… I think that’s fine, as long as we keep comments in the driver making it clear that “this portion of C code replaces the behaviour of the original firmware that runs in a microcontroller in the board because up-to-now we were not able to dump it”.

Please correct-me if I’m mistaken in my interpretation.

I’ve run into this kind of problem while developing the PVE500 driver. The device uses 2 small mask-rom MCUs to drive two knobs. It is a very simple task that is performed. Basically interpreting the pulses of a rotary encoder and outputing a 4-bit speed value and a direction bit. There’s no (cheap/easy) way to extract the code that I am aware of and it can easily be replaced by plain C code in the driver.

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.