After our recent successes with the Konami Picno and the VTech Socrates, it was time to tackle another system with an undumped internal ROM: the Color LCD Classic Game 200-in-1, better known in MAME as class200.
At first glance, it's just another inexpensive handheld packed with 200 built-in games. Nothing particularly spectacular, right?
Well, things become much more interesting when you discover that a tiny piece of code hidden inside its processor is preventing proper emulation of the entire system.
And that's exactly where our latest adventure began!
The Missing 8 KB
The Class200 is based on the Sitronix ST2302U, a 6502-derived system-on-chip that combines the CPU and several hardware functions.
The console also contains a 4 MB external flash ROM. This flash had already been dumped and documented in MAME.
Unfortunately, that wasn't the whole story.
The ST2302U also contains an internal boot ROM responsible for initializing the hardware, preparing the memory layout, setting up essential routines, and eventually handing control over to the external game software.
Without this code, MAME had to rely on simulated initialization routines to get anywhere at all.
The original MAME driver even included a manually reconstructed 40-byte RAM routine to work around some of the missing initialization.
What we really needed was the actual internal ROM.
And as usual, there was one small problem: you can't simply remove the internal ROM chip and put it into a programmer. It's part of the processor itself!
A Needle, Some Tiny Wires, and a TSOP48 Socket!
Before we could even think about running our own code on the console, there was another challenge to overcome.
The Class200 stores its 4 MB external game ROM in a TSOP48 flash chip soldered directly onto the pcb.
Now, anyone who has worked with these chips knows that their tiny pin spacing isn't exactly soldering-friendly!
And since developing a working Trojan would probably involve quite a few experiments, I certainly didn't want to desolder the flash chip, reprogram it, and solder it back onto the board every single time we wanted to test another version.
That would have been a nightmare!
So I decided to give the console its very own external TSOP48 socket.
Of course, there wasn't enough room to simply solder wires directly onto all those tiny flash pins. Instead, I took a rather unconventional approach.
Armed with a sharp needle, I carefully scratched away the protective coating from the extremely fine PCB traces at small accessible spots, exposing just enough copper to make a solder connection.
Then came the delicate part: soldering individual thin wires onto those tiny exposed traces without damaging the connections or creating shorts.
One wire after another, I connected the necessary signals to an external TSOP48 socket.
The result wasn't exactly something you'd expect to see coming out of a factory, but it did the job!
The Class200 now had a conveniently accessible flash socket, allowing me to repeatedly program and test modified ROM images without having to desolder the flash chip from the motherboard every time.
What used to be a tedious hardware operation had become a much simpler process: prepare a new ROM image, program the flash, put it back into the socket, and power up the console.
And believe me, considering how many experimental ROM versions we would eventually go through, this little hardware modification was worth its weight in gold!
With our newly modified Class200 ready for experiments, it was finally time to attack the real problem.
Time to Send in Another AI-Generated Trojan Horse!
Having successfully used Trojan-style dumping techniques on other systems, we decided to give the Class200 the same treatment.
The idea was simple in theory:
Instead of trying to read the processor externally, why not convince the console to read its own internal memory and show us the contents?
The external 4 MB flash ROM provided our entry point.
And thanks to our homemade TSOP48 socket, we could now experiment with modified flash images without repeatedly performing delicate soldering operations.
First, we investigated the system's boot sequence and memory banking. The CPU uses a 64 KB address space with bank-switching mechanisms to access the much larger external ROM.
The internal boot ROM turned out to occupy 8 KB at addresses $6000–$7FFF, with the reset vector pointing to $6000.
We also discovered that the BIOS copies a small routine into RAM, checks the external flash, and eventually transfers control over to the game software.
That gave us the opportunity we needed.
We developed a custom Trojan program for the external flash, including RAM-based routines to handle the bank switching without losing control of the CPU.
Getting this right was essential. One incorrect memory mapping or jump, and the console would crash instead of revealing anything useful.
After investigating the hardware, adjusting the code, and testing our approach, we finally had a working way to access the internal ROM!
Thousands of Screens – Three Bytes at a Time!
Now came the really fun part.
The Class200 doesn't exactly offer USB, serial debugging, or an easy way to transfer data back to a computer.
But it does have something very useful: a color LCD screen!
So we turned the display into our data-transfer interface.
Our final Trojan reads the internal boot ROM and displays its contents as hexadecimal values directly on the handheld's screen.
However, instead of displaying large tables of hexadecimal data, we decided to use a rather unusual approach.
The console displayed just three ROM bytes at a time!
That's right. Each screen showed a single six-digit hexadecimal value representing three consecutive bytes from the internal ROM.
For example, a screen showing
641878 represented the three bytes A2 0A A0.The display then switched to the next three bytes, and the next, and the next...
To keep everything organized and verifiable, the data was divided into numbered blocks.
Each regular block consisted of 16 consecutive data screens, giving us 48 ROM bytes per block. Special marker screens identified each block, while an additional SUM16 checksum screen allowed us to verify the captured data.
Since the internal ROM contains exactly 8,192 bytes, the complete transmission required 171 numbered data blocks, with the final block containing the remaining bytes and an additional repeated control byte.
But here's the really crazy part:
Those 171 blocks actually meant more than 3,000 individual screen changes!
And how did we capture all that information?
With a phone camera, of course!
We simply recorded the handheld's display while our Trojan cycled through the hexadecimal values, three bytes at a time.
Imagine watching a little 200-in-1 handheld transform into a hexadecimal data transmitter, slowly revealing the contents of its supposedly inaccessible processor ROM.
What a sight!
The resulting video was then processed on a computer. The individual hexadecimal values were extracted, placed back into their correct sequence, and reconstructed into a single binary ROM image.
Of course, recovering thousands of rapidly changing hexadecimal values from a video recording isn't exactly foolproof.
Every single byte matters.
After carefully checking the captured data and verifying the reconstructed ROM image, the moment we'd been waiting for had finally arrived.
We had successfully recovered the complete 8 KB internal boot ROM of the Class200!
The Next Challenge: Getting It Running in MAME!
Dumping the ROM was a major achievement, but we weren't finished.
After all, what's the point of recovering a missing boot ROM if we don't try to bring the console to life in an emulator?
With the real internal ROM available, we started improving the existing MAME driver.
This turned into another reverse-engineering adventure.
The original driver wasn't yet configured for all the details of our particular Class200 hardware. We had to investigate the boot process, memory banking, interrupts, timers, and especially the LCD controller.
A major part of the work involved implementing a suitable ST7775R LCD path, including the handheld's 176 × 220 display arrangement and rotation.
Several experimental driver revisions followed.
Some improvements allowed the CPU to progress further. Others revealed additional hardware behavior that the existing emulation did not yet handle correctly.
And then, with our fifth major test revision, something wonderful happened.
The Class200 booted in MAME using its actual internal ROM and original 4 MB flash image!
Not just a few instructions executing.
Not just a blank screen.
We reached the real game-selection menu!
And even better, we successfully launched King Boxing, one of the handheld's built-in games.
For the first time in our experimental driver, we could watch the Class200 running its original software with the recovered internal boot ROM.
A sixth revision followed, correcting the RGB/BGR color channel order and improving the visual output.
What started as a missing 8 KB ROM had suddenly turned into a working proof of concept for emulating the entire handheld!
Another Victory for Hardware Preservation!
What makes these projects so exciting is that the solution doesn't always require expensive equipment or sophisticated laboratory techniques.
Sometimes all you need is an AI which is understanding the hardware, a carefully crafted piece of code, a camera pointed at a tiny LCD screen, and quite a lot of patience.
And sometimes, it also takes a sharp needle, a soldering iron, and a ridiculous number of tiny wires!
From scratching microscopic PCB traces to installing a homemade flash socket, developing an AI-assisted Trojan, capturing 171 pages of hexadecimal data, reconstructing an 8 KB firmware image, and finally watching actual games running in MAME – this has been another fantastic little reverse-engineering adventure.
One more NO_DUMP mystery solved. One more system taking a step closer to accurate emulation.
And one more reminder that even the cheapest little handheld can hide some fascinating secrets.
But the story doesn't end here!
David Haywood has already picked up the newly recovered internal boot ROM and is working his magic on the MAME driver!
He's currently reviewing, cleaning up, and improving the emulation code, turning our initial experimental implementation into a much cleaner and more accurate solution.
And the best part?
He already has the Class200 fully up and running in MAME!
It's absolutely amazing to see how quickly things have progressed. Just a short time ago, the internal boot ROM was still missing, and now the system is running in MAME with its original firmware!
This is exactly what makes hardware preservation and the emulation community so special. One person manages to recover a previously inaccessible piece of firmware, and another takes that discovery and transforms it into something even greater.
And instead of just talking about it, here's a video showing David's latest progress with the Class200 running in MAME!
A huge thanks to David Haywood for taking our initial work to the next level, cleaning up the driver, and helping bring another forgotten little gaming system back to life!
From a needle scratching tiny PCB traces to a fully running system in MAME – what an incredible journey!
Stay tuned for more MAME adventures!
No comments:
Post a Comment