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)
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)
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 – 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.
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.
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.
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.
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.
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.
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.
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!
Hi,
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.