A Moogle  🏳️‍🌈 💻 🎮 🎶 🇸🇪

A wide variety of MCUs were used in seriously vintage LCD/VFD things: The NatSemi COP400 range, the TI TMS1xxx range (Speak 'n Spell, anyone?), Mitsubishi MELPS 4, AMI S2000, Rockwell PPS-4, Sharp SM5-series, and many others. For the most part, 4-bt architecture.

Yes, 4-bit architecture: Register widths tended to be one nybble in width, getting paired together for bytewise operations. ROM sizes were on the order of 1-2 kilobytes, RAM usually between 64 and 128 nybbles.

As for dumping the ROM contents, it boils down to one of two ways, with some overlap: 1a) Depackage the chip using sulfuric or nitric acid, remove the metallized layer with fluoric acid. Remove chip die, clean in Whink.

1b) Throw the exposed chip die under a metallurgist's microscope, since they light downward from the objective, not upward through the slide. Hopefully have good X/Y control of the stage. Take lots of photos. Stitch. Manually transcribe bits.

Sometimes the ordering of bits into usable ROM words is obvious. Sometimes it isn't, and some additional tracing of the silicon is needed. This tends to only work when it's a mask-ROM part, since the ROM bits are physically "printed" on the die through the manufacturing process.

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.