A Moogle  🏳️‍🌈 💻 🎮 🎶 🇸🇪

In other cases, this was done for the first few handhelds, then some additional time was spent investigating the surrounding circuitry to look for a possible verification mode for the chip, where it'll spit out its internal ROM if poked the right way on its pins.

The idea is that the IC manufacturer's customer typically needs a way to verify that the product is programmed correctly. So, if that can be done, then there's: 2) Use documented (or not) methods to dump the ROM contents electronically.

Once the data is in-hand, it's a straightforward enough thing to handle. It's just adding another CPU core to MAME (if it's an unsupported architecture), and bashing out a machine driver. The machine driver itself is usually pretty small, too.

Art-wise, there's usually some additional doing that needs done: Either wire up the VFD/LCD so that you can photograph all elements, and hand-vectorize them, since MAME supports segmented artwork in SVG format.

Also, that photo appears to be rotated 90 degrees clockwise compared to the orientation in which I photographed it, and the orientation that Paint Dot NET presented it in. Ah well.

Beyond that, there are LCD handhelds that've been decapped, and use an MCU, but we haven't been able to determine which. In other, really cheap handhelds, it's managed purely by a gate array. Since MAME has a netlist solver, it's not a fatal blocker, but it'd need transcription.

What I find interesting from all that is the long relationship Nintendo have had with Sharp. They used Sharp MCUs in the entire Game & Watch line. They used Sharp MCUs for the security ICs in their cartridge-based consoles. And a Sharp LR35902 for the Game Boy's CPU.