Preserving Pixter - Dmitry.GR

Fully Preserving Fisher-Price Pixter TLDR: First ever complete reverse engineering, documentation, emulation, and preservation of all Fisher-Price/Mattel Pixter device series and [almost] all the games. Table of ContentsPixter ColorThe beginningSometimes, you get luckyShow me the code!Analysis of the Pixter Color ROMAnd find out I did...The weirdness gets weirder...Dumping the Color CartsGetting Emulation Started"Audio" PlaybackMelodiesCommunicating with the Melody ChipsCapturing the MusicInternal MelodiesThe Strangely Good ScreenPixter MultimediaPixter ClassicStarting with Pixter ClassicThe Weird BusDumping a Classic CartAnother damn VMKNOWN_GAME_IDNative Callouts againWhat is "Native"? How do you define "Native"?Dumping the Pixter Classic ROMHow to output with no output devices?Initial analysisHow memory paging worksSome fun to be hadIdentifying the SoCThe BEX busAcquiring a GPBA01BUsing the GPBA01BMelodies on Pixter ClassicProgramming the Pixter ClassicThe one weird pin on the cartResistive Touch Panels on the CheapResistive Touch Panels beyond CheapPixter Plus and Pixter 2.0Pixter PlusPixter 2.0Pixter PocketPreservationFile formatEmulating Pixter ColorHow hard could it be to emulate?Saving images is hardMaking game carts workAudio is hardThat cursed adapterEmulating Pixter MultimediaEmulating Pixter ClassicEmulating Pixter 2.0 and Pixter PlusSome final challengesMusic StudioSymphony PainterPixter CameraPreserved and not-yet-preserved GamesDownloadsClassicDisasmColorDisasmPalmosLauncherMultiuM23uARMpixteruPixterAppendix A - Pixter Color VMPixter Color VM instructionsTYPE

A instrsTYPE B instrsTYPE C instrsTYPE D instrsTYPE F instrsTYPE G instrsTYPE H instrsTYPE J instrsTYPE K instrsTYPE L instrsTYPE M instrsTYPE E instrsPixter Color Cart HeaderPixter Multimedia Cart HeaderPixter Color VM structuresObject TableColor Tables4-to-16 mapsAudio ObjectsFont ObjectsLarger ImageAudio effectsColor UI LayoutUI SettingsAppendix B - Pixter Classic VMPixter Classic VM instructionsALU opsSPECIAL opsPixter Classic StructuresPixter Classic Cart HeaderClassic UI LayoutClassic Image and Sound lookupClassic Image Format and compressionEEPROM use in Pixter Classic/2.0Appendix C - connections and pinoutsPixter Classic cartPixter Classic to Color adapterPixter Multimedia NAND cartPixter Color cartComments...Pixter ColorThe beginningIn 2000, the famous American toy company Fisher-Price released a simple drawing-oriented handheld gaming console for kids called Pixter. It featured no brain-rotting social media and focused, instead, on drawing, sketching, and educational games. The initial sales figure from the holiday season of the release was half a million units, which is not too shabby at all. Besides letting kids draw using an included stylus on the 80x80 monochrome display while catchy tunes played on repeat from the speaker, the device also allowed plug-in games to expand the possible activities. There exist 25 known games for Pixter (I had to edit wikipedia to correct their record). Soon after, there was a Pixter Plus, which added more memory and expanded the built-in game. Then there was Pixter 2.0, which added wireless comms. Neither of those radically changed the device itself and all the games remained cross-compatible. One cool feature of Pixter devices was that you could draw an image in one game, using its stamps and tools, save it to internal memory, plug in another game, load it, and draw on top of it. So you could, literally, customize a cool car in "Cool Wheels", save the image, plug in "Barbie Fashion Show" and plop a barbie into your cool car image. What joy this must have been! In 2003, Pixter Color came out, adding color, 4x the screen resolution, and a new game cartridge connector.

An adapter came with it to allow it to run old games, and it ran them all (pixel-doubled) perfectly! Obviously, the old monochrome Pixters could not run new color games. The main purpose of the device remained the same - sketching and stickers with ability to save your compositions in memory, just in color now! Games got more advanced and intricate. There was even a camera attachment! There are 32 games known to exist for Pixter Color. In 2005, Pixter Multimedia came out, which added a better screen (quality-wise, the resolution remained the same) and a yet another game cartridge connector (a superset of the Pixter Color connector), allowing for Multimedia-only carts. Nine of these Pixter Multimedia exclusive game are known to exist. As I had written before, my friend Josh pointed me at Pixter Color as potential PalmOS porting target, and after a lot of work, I got PalmOS fully working on that device. This is not that story, however! To get PalmOS working, the device had to be understood, a method to run code on it had to be found, and among all that research, a lot of work was done on documenting Pixter Color. Previously, a few places online mentioned that “THERE ARE CURRENTLY NO EMULATORS FOR THIS DEVICE OR PLATFORM. ANY CLAIMS TO OFFER THEM ARE SCAMS!”. This is no longer true, I am happy to report. I am here to present a complete historical preservation of all information pertaining to how Pixter devices work and almost all the games. However, let us go in order... Sometimes, you get luckyPixter Color Slot 1A0||2D0 3A1||4D1 5A2||6D2 7A3||8D3 9A4||10D4 11A5||12D5 13A6||14D6 15A7||16D7 17A8||18D8 19A9||20D9 21A10||22D10 23A11||24D11 25A12||26D12

27A13||28D13 29A14||30D14 31A15||32D15 33A16||34PE1 35A17||36PE0 37A18||38nCS2 39A19||40nCS3 41A20||42nOE 43A21||44nWE 45A22||46PG6 47A23||48PD0 49PD2||50PD1 51PD4||52PF6 53PD3||54PF4 55PD5||56AUD 57PD6||58Vdd 59Vss||60?? As there were no official docs on writing Pixter games or code, the first step of the process was to open a Pixter and see what was inside. It would later turn out that starting with Pixter Color was quite lucky -- its main SoC is the LQFP version of Sharp LH75411. Why is this lucky? Unlike other chips and chip package types, this specific one makes probing individual pins trivial, allowing even careful soldering to them. No other Pixter-family device has this property, but I did not yet know this. The main board had the main SoC, 128KB of x16 SRAM, and two black blobs. The blobs are of course Chip-on-Board dies of some sort. These are not labeled nor can they be easily probed. In most cases removing the epoxy is destructive. Black blobs are the worst! Sadly, they are common in cheap devices, and Fisher-Price were always kings of cost-cutting. As I went through this project, I, in fact, gained more respect for their cost cutting abilities than I had had before. First, it is worth taking a moment to talk about the LH75411 and the surrounding chips on the Pixter Color motherboard, from a performance standpoint. I ranted about it already in my PalmOS-on-Pixter article, but in case you missed it, I'll summarize. This is the most minimal ARM7 instantiation I've ever seen.

Everything that was optional was excluded, everything that could be sized was configured in the most minimal configuration. The SoC has 16KB of TCM inside, which is pretty fast - single cycle access in fact. There is also another 16KB of SRAM in the SoC, which is accessed using an internal AHB bus, meaning that reads effectively take 2 cycles. There is some SRAM on the board, as I had mentioned - 128KB on a 16-bit-wide bus. It is configured with one wait state (an extra clock of delay to allow signals to propagate and slow/cheap memories to process). A word read from this memory thus takes two bus operations, each using 3 cycles. This is getting slow, as you see. Luckily, this is where cache comes in handy. Cache automatically stores recently-accesses memory close to the CPU for fast access, covering up for high-latency and/or low-bandwidth memory. At least, it would, had Sharp (the manufacturer of the SoC) bothered to instantiate some cache in the chip. There is none. This is not nearly the end of the performance troubles though. The ROM is also on a 16-bit-wide bus, though luckily without wait states. Due to this, fetching 32-bit-wide ARM instructions would be painfully slow, and almost all of the code in the ROM uses the 16-bit Thumb instructions -- a problem not unlike those faced by Gameboy Advance programmers, and for the same reason. ARM processors use a table of vectors to handle interrupts and exceptions. The table can be located at one of two addresses: 0x00000000 or 0xFFFF0000. The first option for the address is also the value of NULL, and preferably, there should be no memory at that address to allow easy detection of logic bugs. The problem is that it is uncommon for SoCs to place memory that high in the address space so as to have anything at 0xFFFF0000. Luckily, an MMU can be used to map virtual addresses to physical addresses, and 0xFFFF0000 is a virtual address. All that is needed is to enable the MMU and make the mapping.

There is no MMU in this SoC. Well, OK, fine, I guess we are stuck with vectors at zero, but while an MMU does take up some silicon area and would make the chip slightly more expensive to make, ARM had designed a much simpler option - an MPU. It does not map memory but it allows setting various protection settings on some ranges of it. The Pixter ROM could then configure the memory at 0x00000000 to be only accessible by supervisor mode, and run all software in user mode, thus still trapping accidental NULL accesses. The MPU is such a small cost to implement that of course it should be present, even the very-cost-reduced ARM chip in the NintendoDS has this option enabled. There is no MPU! There is also no alignment checking, no cp15 coprocessor, no ... anything that is optional at all. Just a chip full of "no". The practical upshot is that it is easy to crash this thing and not even know you did. It will also never be fast. Fine, it was meant to be cheap, not fast or stable. Let's see how the system works... Show me the code!I painstakingly dumped a cart's ROMs in a way that I thought would work. This is of no difficulty, once you source the proper $10 ea(!!) connector. Since I knew that the SoC is ARM, I opened up IDA Pro and loaded a game cart ROM. Out of the 2 megabytes of ROM, only about 300 bytes were recognizable ARM or thumb assembly. The rest either looked like bitmaps, or looked like nothing recognizable at all. It lacked the entropy to suspect that it was encrypted or compressed, and anyways the CPU would not be fast enough to support such a scheme. Whatever it was, it surely was not ARM code. Weird... Maybe I had a bad dump? Redoing it proved that I did not. Maybe this one game was weird? Checking another dump showed even less ARM code. Very very strange. At least the first few bytes always matched, which is plausibly the header. Clearly, I was not going to get anywhere that easily. It was time to dig deeper in. The device can operate without a game cart at all. Thus, clearly, the main SoC needs to boot from somewhere if there is no cart inserted.