The Secret Life of the Fisher-Price Pixter

Children of the early 2000s spent lots of time begging their parents for a Game Boy Advance. It was a big step up from the handheld consoles that came before it, and every gamer wanted one. You can imagine the emotional rollercoaster these kids experienced when they tore open a Game Boy Advance-sized gift on their birthday only to find a Fisher-Price Pixter inside instead. “It won’t rot your brain,” concerned parents would say. But 2000s kids didn’t care about unimportant things like their future — they just wanted to play Super Mario Advance.

However, the Pixter did grow on those who had one. It certainly wasn’t a Game Boy, but it did have some fun games. And aside from that, the touchscreen and drawing mode were unique for the time, and could entertain a child for hours. Dmitry Grinberg may have come across the Pixter later in life, but he still fell in love with it — so much so that he wants to preserve what he has learned about it for others. Grinberg has published the first-ever complete documentation of the device that he gathered via extensive reverse engineering.

What started as an effort to port PalmOS onto the Fisher-Price handheld quickly spiraled into a full-scale digital archaeology project. Grinberg painstakingly disassembled multiple Pixter models, traced motherboard connections, dumped ROMs from mysterious epoxy-covered “black blob” chips, and reverse engineered the entire software architecture behind the toy line. Along the way, he uncovered a bizarre and ingenious system hiding inside a device meant for children.

Among Grinberg’s findings was the fact that the Pixter Color was powered by a severely stripped-down ARM7-based Sharp SoC with almost none of the optional features developers would expect. There was no cache, no memory protection unit, and no MMU. Most game logic wasn’t even written in native ARM code. Instead, Grinberg discovered that nearly every Pixter game ran inside a custom 16-bit virtual machine interpreted by the console’s firmware in real time.

This revelation explained why dumped game cartridges initially appeared to contain almost no recognizable executable code. The games were essentially streams of VM instructions, with high-level opcodes responsible for everything from drawing graphics to playing audio and handling touchscreen input. Grinberg documented the instruction set in enough detail that fellow developer Nathan Korth was able to begin building a working emulator for the system.

If you have any interest in the Pixter, or in learning how to reverse engineer another complex system, Grinberg’s deep dive is something that you won’t want to miss. You can read all of the documentation on his website.