Go Retro! Portable – Cracking the Mystery 8-Pin Chip with Another AI-Generated Trojan!

 

After our recent adventures with the Konami Picno, VTech Socrates, and Class200, it was time to tackle another interesting system with a missing piece of firmware.

This time, our target was the Go Retro! Portable from Retro-Bit.

Released in 2018, this Game Boy-style handheld comes packed with more than 260 built-in games. Unlike many other inexpensive multicarts, the Go Retro! Portable includes a surprisingly interesting selection of officially licensed classics from Capcom and Data East.

We're talking about games such as Mega Man 2, Mega Man 3, Ghosts 'n Goblins, 1942, 1943, Bionic Commando, Bad Dudes, BurgerTime, and many more.

Under the hood, the system is based on NES-derived VT-series hardware, combining a familiar gaming architecture with some rather unusual custom features.

The complete game collection is stored in a massive 32 MB flash ROM.

The system was already supported experimentally in MAME, but something had been bothering us for quite some time.

A mysterious little 8-pin chip was still hiding a piece of the puzzle!

And naturally, we wanted to find out what was inside.

The Missing Protection ROM

While the main 32 MB game ROM had already been dumped, the Go Retro! Portable contains another small chip used during the system's initialization.

This mysterious 8-pin device supplies a small amount of data that the console copies into RAM and subsequently uses as executable code.

Without this data, the original software cannot behave exactly as intended.

The MAME driver already contained a workaround, but it wasn't the real thing.

Instead, the emulation relied on a modified version of protection code borrowed from another system, adapted just enough to make the Go Retro! Portable's menu work.

The corresponding protection.bin was therefore marked BAD_DUMP in MAME.

It was a clever workaround, but from a preservation perspective, it left an important question unanswered.

What exactly does the original 8-pin chip contain?

Could we somehow convince the console to read that chip again and reveal its contents?

After our previous successes with Trojan-based ROM dumping, the answer seemed obvious.

Let's try another Trojan horse!

But first, there was some hardware work to do.

Goodbye BGA, Hello DIP42!

Instead of having a conventional flash chip soldered directly onto the motherboard, the system contains a small PSOP44 subboard carrying a 32 MB BGA flash chip.

Now, a BGA chip isn't exactly something you want to repeatedly remove, program, and solder back into place.

And since our experiments would certainly require multiple custom ROM versions, I needed a much more convenient solution.

Fortunately, the PSOP44 subboard gave me an idea.

Why not remove the entire subboard and connect an ordinary EPROM socket instead?

So that's exactly what I did!

First, I completely desoldered the PSOP44 subboard from the Go Retro! motherboard.

Luckily, the exposed PSOP44 solder pads were reasonably accessible, making this modification considerably easier than the tiny trace-scratching adventure we had recently experienced with the Class200.

Using individual wires, I connected the necessary address, data, and control signals to an external DIP42 socket.

This allowed me to use standard 27C322 EPROMs, each capable of holding 4 MB of data.

Of course, the original Go Retro! uses a much larger 32 MB ROM, so this raised an important question.

Would the console even start with just 4 MB?

There was only one way to find out!

The First Test – 4 MB Is Enough!

Before attempting any complicated Trojan code, I wanted to confirm that our hardware modification actually worked.

I took the original 32 MB ROM image, trimmed it down to its first 4 MB, and programmed it into a 27C322 EPROM.

Then I inserted the EPROM into our newly installed DIP42 socket and powered up the console.

And guess what?

 

It worked immediately!

The Go Retro! Portable started normally and displayed its original game-selection menu, complete with music!

This was fantastic news.

We had just confirmed two very important things.

First, our homemade EPROM adapter was working correctly.

And second, the initial 4 MB of the original ROM contained enough of the startup code and menu software to get the system running.

Naturally, a 4 MB EPROM couldn't replace the entire original 32 MB game collection, but that wasn't our goal anyway.

We only needed a working environment in which to launch our own code.

The door was open for another Trojan attack!

 

Our First Trojan – Not Quite There Yet!

With the hardware ready, we started examining the Go Retro! firmware and the existing MAME driver.

The interesting part was the way the console communicated with its mysterious 8-pin chip.

During startup, the original firmware sends a command to the chip and reads back a stream of data.

That data is copied into RAM, where the game software can access and execute parts of it.

We wanted to take advantage of this existing communication routine.

Rather than reverse-engineering the chip's electrical interface completely from scratch, we could reuse the console's own code to perform the read operation.

The plan was simple:

1. Start the console using our modified game ROM.

2. Execute a custom Trojan program.

3. Read the original 8-pin chip.

4. Display the recovered bytes on the screen.

5. Reconstruct the data into a binary ROM image.

Simple enough in theory!

Our first experimental ROM attempted to use the display as an optical data-transfer interface.

Instead of hexadecimal text, the initial idea involved rapidly changing screen colors to represent binary data.

Unfortunately, the first attempts didn't produce a usable dump.

We saw some visual activity, but not the reliable data transmission we were hoping for.

Clearly, something wasn't quite right.

And that's where the real reverse-engineering adventure began.

The Menu Appears... and Then Everything Goes Black!

Our next approach was more conservative.

Rather than trying to take over the console immediately during startup, we decided to let the original firmware initialize everything normally.

The original game menu would appear first.

Only after a short delay would our Trojan take control.

This approach had several advantages. The hardware would already be initialized, the screen would be working, and the original protection-chip communication would have completed successfully.

We inserted a small hook into the menu code, redirecting execution to our custom routine after approximately two seconds.

The result was encouraging!

The console booted normally.

The menu appeared.

The music played.

And after approximately two seconds...

The screen went completely black!

Well, that wasn't exactly what we wanted.

But it was still progress!

The timing strongly suggested that our code was being executed.

The problem now seemed to be related to our custom display routines rather than the console's ability to run the Trojan.

We had successfully reached the next stage.

Now we needed to make the screen cooperate.

Making the Screen Talk!

Instead of immediately attempting another full ROM dump, we switched to a series of smaller diagnostic tests.

First, we developed a ROM that simply switched the existing menu display on and off.

If the screen blinked at the expected intervals, we would know that our hook was executing and that we could manipulate the video hardware.

This worked!

Next, we experimented with different display colors.

The console eventually responded with the expected color changes, confirming that our custom code could control the visual output.

Our optical transmission idea was finally becoming practical.

The original concept used different colors to encode binary values, with a separate synchronization color helping the decoder identify the transitions.

Technically, this could have worked.

But there was one disadvantage.

Capturing hundreds of rapidly changing colors from the handheld's screen and reconstructing the exact data would have been rather cumbersome.

And after all the experience we had gained with our previous ROM-dumping adventures, we knew there was a much more convenient solution.

Why not simply display the ROM contents as hexadecimal text?

From Colored Screens to Pure HEX!

For the next major revision, we abandoned the color-based data transmission and developed a proper hexadecimal display routine.

This required some additional work.

The original game menu wasn't designed to display arbitrary memory contents as HEX values, so our Trojan needed its own small character set and text-output routines.

We created a custom hexadecimal font, allowing the handheld to display values from 00 to FF directly on its screen.

And this time, the results looked much more promising!

Our fifth major Trojan revision successfully displayed the protection-chip data as hexadecimal text.

The output was divided into numbered pages, each containing 16 bytes and an additional SUM16 checksum.

The system displayed the data page by page, giving us enough time to photograph the screen and record the contents.

But there was another important detail.

The original firmware didn't simply preserve the raw data exactly as it arrived from the 8-pin chip.

It also modified parts of the data in RAM during initialization.

For emulation and preservation purposes, we didn't want those modified bytes.

We wanted the original, untouched contents of the chip!

So our Trojan performed another read of the 8-pin device, using the original communication routine, and captured the newly received data before the firmware could apply its RAM modifications.

That distinction was essential.

We weren't just dumping a memory area that happened to contain some protection code.

We were recovering the actual raw data supplied by the physical chip!

The Final Trojan – 256 Bytes of Pure HEX!

Instead of relying on colored screens, we developed a proper hexadecimal display routine with a custom character set, allowing the console to show the actual contents of its mysterious 8-pin chip.

The Trojan reused the original chip communication routine to capture the raw data directly into RAM, without the modifications normally applied by the game's initialization code.

After several experiments and adjustments, we finally had a working solution!

The console booted into its familiar game menu, and after a short delay, our Trojan took over and started displaying the recovered data.

 

        

All 256 bytes were presented across 16 pages, each containing 16 hexadecimal values and a SUM16 checksum.

We photographed the screens, reconstructed the complete binary image, and independently verified every page against its displayed checksum.

All 16 pages passed!

And there it was: the complete original 256-byte protection data, recovered directly from the real Go Retro! Portable hardware!

Another mystery solved!

All of that work for just 256 bytes!

Color LCD Classic Game 200-in-1 (class200) – Another Internal Boot ROM preserved! From a Trojan Horse to Running Games in MAME!

 

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!

Jakks Pacific Bass Angler (2005) – Hidden Test Menu Discovered!

 Today I spent some time investigating Jakks Pacific's Bass Angler, a Plug & Play fishing game released in 2005.

This particular game belongs to a rather interesting group of Jakks Pacific Plug & Play titles that use Winbond hardware, with the game's ROM stored internally inside the chip rather than on a separate external ROM.

This makes things particularly interesting from a preservation and emulation perspective. Unlike systems where the game data can simplier be extracted from an external memory chip, these Winbond-based units present an additional challenge when it comes to dumping their internal software.

During today's hardware investigation, I started tracing connections on the PCB, examining the chip-on-board (COB) components, and identifying various test points and signal lines. The ultimate goal is, of course, to better understand the hardware and eventually find a way to extract the internal ROM for preservation and MAME emulation.

But along the way, I made another interesting discovery!

A Hidden Factory Test Menu!

While investigating the game, I noticed that there was practically no information available online about how to access its hidden diagnostic functions.

So I decided to experiment with different button combinations myself.

And I found it!

At the very first Jakks Pacific title screen, enter the following button sequence:

B → C → B → C → A

This secret combination activates the game's hidden diagnostic functions!

Interestingly, the same combination triggers two different diagnostic routines, alternating between them on successive console starts.

Mode 1 – Save Game Test & Memory Clearance

The first diagnostic mode performs a save-game memory test and provides a memory-clearing function. This was presumably intended for factory testing or servicing the unit.

 

 Mode 2 – CRC Verification & Hardware Test Menu

The second mode is even more interesting!

The console first displays a series of CRC verification screens, presumably used to check the integrity of the internal game data.

 After these screens, the system enters a hidden test menu, providing access to diagnostic functions that are normally inaccessible during gameplay.

 

To exit this test menu, simply press:

A + B (simultaneously)

 

Another Little Piece of Plug & Play History Preserved!

It's always fascinating to discover features that have been hiding inside these inexpensive Plug & Play consoles for more than two decades.

Factory diagnostics, hidden menus, undocumented hardware features – they're all small pieces of information that can easily disappear as these devices age.

And while today's discovery doesn't yet solve the challenge of extracting the internal Winbond ROM, it gives us another interesting glimpse into how these games were developed and tested.

One more hidden secret uncovered, and another small step toward preserving these obscure Plug & Play systems!

VTech Socrates – Speech Emulation Progress and French Speech ROMs Successfully Dumped!

Another exciting breakthrough in VTech Socrates preservation!

Today, we made significant progress extending the MAME Socrates driver with support for the Toshiba TC8802AF speech synthesizer. At the same time, we developed a custom cartridge ROM that allows us to read and verify the speech ROM contents directly on original hardware.

And the best part? We successfully dumped and verified both speech ROMs from the French Socrates!

Turning the Socrates Into Its Own ROM Dumper

The Socrates speech hardware uses a dedicated Toshiba speech synthesizer (tc8802) with internal ROM and support for additional external Voice Synthesis Memory (VSM).

Unlike ordinary cartridge ROMs, these memories cannot simply be read through the console's normal address bus. Instead, they must be accessed through the speech chip's command interface.

Our solution was to develop a custom Z80 cartridge ROM that communicates directly with the speech synthesizer and displays its memory contents on the television screen.

The dumper supports two memory regions:

• INTERNAL: The 8 KB internal mask ROM, accessed using read condition 00. Its contents are displayed across 32 pages of 256 bytes each.

• EXTERNAL: The complete 64 KB external VSM address space (4 x 16kb), accessed using read condition 04, displayed across 256 pages of 256 bytes each.

Each page displays the extracted bytes as hexadecimal values, together with a SUM16 checksum in the footer.

 

To make the results even more reliable, we implemented a second complete reading pass. The program compares the results against the first pass and displays OK or ERROR in a dedicated column.

 

This makes it possible to detect unstable reads directly on the original console!

Built-In Checksum Verification

One of the most useful features is the integrated checksum calculation.

The dumper calculates both SUM16 and standard ZIP-compatible CRC32 checksums for the internal ROM and all four external VSM memory regions.

This allows direct comparison with the CRC32 values used by MAME.

It also reads the identification sequence A5 53 4F, displaying the identification text SOCRATES,VTEL88.

The read timing can be adjusted by changing the delay after each START transition, which is particularly useful when testing the stability of the speech hardware.

Combined with the second reading pass, these features make the dumper much more than a simple hexadecimal viewer. It is a practical hardware verification tool.

Dumper Controls

The entire program can be operated using the original Socrates controller.

Button	Function
Left directional pad	Previous / next page (±1)
Right directional pad	Jump backward / forward by 16 pages
Left red button	Switch between INTERNAL, EXTERNAL and CHECKSUM screens
Right red button	Toggle automatic page advancement in hexadecimal display mode
Right red button (checksum screen)	Restart the complete measurement
Left directional pad (checksum screen)	Adjust the delay after each START transition

The automatic page advancement feature changes the displayed page every 2 seconds, making it especially useful when recording the ROM contents using a video capture card.

Rather than manually stepping through hundreds of screens, the console can automatically display the entire memory region while the capture device records the output.

The screenshots can then be processed on a PC to reconstruct the original binary ROM images, with each page checked against its displayed SUM16 value.

The French Speech ROMs – Successfully Recovered!

Using this new dumper on original French Socrates hardware, we successfully recovered both populated speech memories.

ROM	Size	CRC32
speech_fra_internal.bin	8 KB	D08310A3
speech_fra_vsm1.bin	16 KB	B1146420

The French speech cartridge uses only VSM1. VSM2, VSM3 and VSM4 are not populated, so there is no additional speech data to recover from those positions.

Both ROMs were read and verified multiple times, with consistent results. The reconstructed data also matched the checksums reported by the dumper.

This confirms a complete, verified 24 KB speech ROM set for the French Socrates!

What's Next?

With the French speech ROMs successfully preserved and the MAME driver now being extended to support the speech hardware, we are moving closer to accurately reproducing the original Socrates speech capabilities.

The custom dumper will also be extremely useful for checking other regional speech cartridges, comparing ROM revisions, and validating additional speech hardware.

Nearly 38 years after the Socrates was released, another missing piece of its history has finally been preserved.

The Socrates is getting its voice back!

 

 

Konami PICNO Emulation Is Taking Shape!

Things are moving fast with the Konami PICNO!

After finally overcoming one of the biggest obstacles — extracting the previously inaccessible internal ROM from the HD6435328F10 — the PICNO is no longer just a collection of ROM dumps and hardware notes. It is actually starting to come to life in emulation.

With the internal ROMs of both known revisions, RX001-Z8-V3J and RX001-Z8-V4J, successfully dumped using our trojan method, we finally have the missing pieces needed to understand how the system boots and communicates with its cartridges.

And the first results are looking very promising!

 

 

 

As the screenshots show, the emulator is already producing recognizable output from several PICNO titles. Boot screens, Konami logos, drawing interfaces, menus and graphics are appearing — including software such as Fushigi no Kuni no Alice and Picno de A-I-U-E-O.

Of course, this doesn't mean the emulation is finished. There is still plenty of hardware behaviour to understand and reproduce correctly, and several parts of the system need further investigation. But compared to where we started — with an undumped internal ROM hidden inside a Hitachi MCU — seeing actual PICNO software running is a huge step forward.

The little drawing console from 1993 is finally beginning to reveal its secrets.

The Konami PICNO is coming to life!

More to come…

A Trojan Horse for the Konami Picno — Dumping the ROM That Kept Us Waiting for Nine Years

 

Sometimes, the smallest missing ROM becomes the biggest obstacle.

Back in 2017, I had the chance to dump the Konami Picno’s external base ROM and several cartridges. That preserved a substantial part of this unusual console’s software, but one crucial piece remained out of reach: the 32 KB internal ROM inside its Hitachi HD6435328F10 microcontroller.

It could not be dumped through the usual ROM-reader approach. And without it, emulating the machine was missing the very code that brings the hardware to life.

Today, October 5, 2026, we finally persuaded the Picno to reveal that missing piece — by sneaking a Trojan horse into a cartridge and making the console display its own internal ROM.

Konami’s Lesser-Known Console

When you hear “Konami,” you probably think of Castlevania, Contra or Gradius. A children’s drawing console is perhaps a little further down the list.

Yet that is exactly what the Konami Picno was: a Japan-only educational system combining a drawing tablet and pen with a television display. Released in 1992, and followed by the Picno 2 in 1993, it offered drawing, colouring and cartridge-based learning activities.

Even without a cartridge, its external base ROM provided built-in drawing functions. The cartridges themselves were remarkably thin, almost reminiscent of PC Engine HuCards — but their unusual ROM pinouts made the original dumping work an adventure of its own.

In 2017, I documented those connections and built a cartridge dumper around an Arduino Mega 2560. The external 512 KB base ROM could also be desoldered and read using a conventional programmer.

The microcontroller’s internal ROM was a different story.

Getting the Trojan Through the Gate

The trick was to let the Picno do the reading for us.

Although an external programmer could not simply extract the internal ROM, the console’s own processor could access it. What we needed was a way to run our code on the real hardware.

Our Trojan horse was Picno Art Puzzle, cartridge RX109.

We modified its ROM image and redirected a callback pointer in the cartridge header to a small routine of our own. Loaded onto a flash cartridge, the patched image gave the Picno a familiar cartridge structure to process — with our dumping code hidden inside.

The initial wrapper called the original Art Puzzle callback first, allowing the normal setup to take place. It then read the complete internal ROM address range, 0x0000–0x7FFF, and copied those 32,768 bytes into video memory.

The first proof-of-concept payload was just 59 bytes long.

A tiny passenger, carrying the key to a nine-year-old problem.

Turning a TV Picture Into a ROM Dump

Getting the bytes onto the screen was only half the challenge. We still had to recover them accurately on a PC.

The first approach displayed the ROM contents directly as pixel values, producing a colourful image of apparently meaningless data. For the final extraction, we moved to clearly defined black-and-white bit patterns.

The ROM was split into 64 pages of 512 bytes. Each page represented its data as a 128 × 32 matrix of bits, using enlarged pixel cells and markers to help locate the grid in captured frames.

That turned the Picno’s ordinary video output into a data export channel.

We recorded the output with a capture card, decoded the patterns on the PC and assembled the pages back into a binary file. A console designed to put children’s drawings on a television was now putting its own firmware there instead.

5 Runs, One ROM

We repeated the capture to check the result.

All runs reconstructed the same complete 32 KB ROM.

The resulting dump has CRC32 41C381AB.

Its contents also make sense as genuine firmware: a valid reset vector, coherent H8/500 startup code, a table of 192 jump entries and mathematical lookup data consistent with drawing and geometry routines.

After almost nine years, the missing internal ROM is finally preserved. 

Next Step: The Second PICNO Revision

With the first PICNO successfully dealt with, the next target was the second known console revision. Since it uses a different internal ROM revision, we had to repeat the process:

And it worked! The second PICNO revision was successfully trojaned as well, allowing us to extract its previously inaccessible internal ROM. Multiple dump runs produced consistent results, giving us a good and verified dump of the second revision.

That means we now have clean internal ROM dumps from both known PICNO console revisions — another major piece of the puzzle finally preserved.

The Next Chapter

This does not instantly give us complete Picno emulation. The custom video hardware, memory behaviour, pen input and sound still need work.

But we can now study and execute the real internal firmware alongside the base ROM and cartridges, replacing a major unknown with actual code.

Back in 2017, I ended my original Picno post hoping that the last undumped chip could be read soon.

“Soon” turned out to take almost nine years.

And the way out was wonderfully appropriate for a drawing console: we made it draw its own ROM. 

Preservation of Jakks Pacific Plug & Play Systems: Discovery of a Previously Unknown GameKey Release

This post is a short overview of my work over the past 18 months, and how I ultimately discovered something very special.

Over the last few years, many Jakks Pacific Plug & Play consoles were dumped thanks to the work of Sean Riddle. A number of these could be accessed via the GameKey port—a cartridge interface that allowed certain consoles to be expanded with additional games by purchasing dedicated cartridges.

However, not all consoles were easy to work with. Some of the Jakks Pacific systems had no straightforward way to dump their ROMs. The ROM chip was hidden under a glob top, making it very difficult to identify the individual lines coming out of it. On top of that, physically connecting to those extremely thin lines for dumping was a real challenge.

If you’ve been following the work of David Haywood (“Haze”) and myself in MAME over the past year and a half, you may have noticed that in late 2024 I found a method to dump these consoles using inexpensive equipment and materials. Even better, the process takes only about 2–3 hours per console. I’ll go into detail about this technique in a future blog post, as I’d like to document it thoroughly so others can replicate it.

Fast forward a few months to mid-2025: most of the remaining Jakks Pacific games had been successfully dumped and are now working in MAME. At this point, only a handful of first-generation Plug & Play consoles from 2003–2004 remain undumped. These systems don’t use any external ROM on the PCB—we believe they rely on MCUs with internal ROM, which currently cannot be accessed. We also know that some games had later revisions released, but those versions have not yet been found or acquired.

In short, the past 18 months have been incredible—we’ve preserved a huge amount of content. In my opinion, Jakks Pacific Plug & Play consoles stand out as some of the highest-quality systems of their kind, both in terms of gameplay and graphical design.

Now, back to the main topic. The GameKey system was not a commercial success for Jakks Pacific, and only a small number of cartridges were ever released. The entire GameKey initiative was discontinued after roughly a year.

Many consoles were advertised as “GameKey-ready,” promising future expansions that ultimately never materialized. A good example is the Winnie the Pooh: Piglet’s Special Day console. Across the internet, you’ll find claims that a GameKey for this system was in development but never released. The console itself includes a cartridge port and was clearly designed to support it. The GameKey was supposedly planned for release in 2006, yet all available sources insist it never came out:

 

But what if that assumption is wrong?

Two weeks ago, I came across an auction listing for a GameKey—not just one, but two. Both were in perfect condition and still sealed. I bought them immediately.

    

 And yes—this is the missing GameKey for Winnie the Pooh: Piglet’s Special Day. It appears that it was actually released in Italy, but only in extremely small quantities. While the box art is entirely in Italian, the manual and all included games are fully in English.

It took me about an hour to build a GameKey dumper and extract the data. Haze has already added it to MAME, meaning that another previously unknown game has now been preserved—and will soon be playable by everyone in the next MAME release. 

Enjoy some snaps from MAME:

 

 

Ninja Spirit (World) MCU preserved

 While i already decapped and dumped many (37) 8751H mcu's the last couple of years, there are still some left which will be needed to get done!

I received another undumped one from Darksoft today.

Did not took more than 10 minutes and this one is now preserved too.

 

 Credits: Darksoft & TeamEurope

Casio PV-2000 Multicart [27 in 1]

 Finally, as many of you asked for it...here it is. 

 A Multicart for the PV-2000, which has 27 games inside. All 12 commercial games and 15 homebrew games.

 As with the PV-1000 multicart i used here a Megadrive-Shell with CNC-cut hole for the DIP-Switch and a high quality printed cartridge-cover

 

 

Here's the DIP-Sheet: