I was an intern at Fisher Price when they introduced the Pixter Color. I did QA on some of the games, the Dora one comes to mind. You can imagine the torture playing a level over and over.
The games were developed overseas (India I think?). I would send them bug reports in Mantis and overnight they would send a new build. Sometimes they would even fix the bugs. I would burn the builds on to EEPROMs and verify them the next day. The EEPROMS had a little round window so they could be erased in a UV box before programming.
Fisher Price used a video codec from Actimagine to fit video clips onto the game cartridges. That's how I learned about Virtualdub. I remember editing clips from a show called Winx.
The big competition was the Leapster LeapPad and they were trouncing us.
One fun thing the engineers did periodically was a toy teardown to see how competitors saved on cost. Cost was critical. They told me how Walmart basically dictates toy cost because they controlled the shelf space.
I have an upcoming article on Pixter itself which includes giving them a LOT of credit for cost cutting. There are some quite clever things there. I also worked out how to dump games (not easy with those damn melody chips, or what did you call them?) and will release an archive of all games and working emulators.
Nice work Dmitry, looking forward to read your next article.
The later model Pixter Multimedia had the full memory space accessible via JTAG, which is how some carts and even boot ROM got dumped a while ago [1], is it the same deal with Pixter Color?
That OpenOCD script was a bit flaky, and sometimes the boot ROM would be already unloaded before reading, maybe you have some insights in how to make it more robust.
btw, have you looked into the original Pixter? The cart connector seems to have a very narrow bus, so it doesn't look like those carts have code, and probably can only be dumped with a decap.
That only dumps the data. That’s the easy part. None of that dumps the melodies.
The pin outs that page links to are also not quite accurate. I need to finish editing my other article on this.
I have indeed looked into the original Pixter. Deeply: I have decoded the bus, documented the device, dumped games, and produced a working emulator.
The cartridges do contain memory. Most of them are about 1 MB in size, split between code (the maximum for which is 32 kB) and audio effects + images which occupy the rest of the space. If you are very, very curious and don’t want to wait for me to finish my editing, email me and I can explain how it works.
Very impressive hack. Looking at this I now think I may have overpaid for my Palm Pilot back in the day!
For the Pixter Color in 2003 I found a price of $80 US at release. The specs aren't directly comparable (less RAM and I bet less battery life too). But still! That's less than half the cost of a black-and-white Palm m105 around the same time.
I wonder how cheap PDAs might have been if mass market forces had been applied to them. Handheld computers didn't really get the cost reduce it like a mass market kid's toy treatment until the smartphone era.
Dmitry is a mad genius. He has been doing stuff like this for 20 years, he was fixing palm’s issues for years. All his hardware projects are phenomenal, and so is his writing.
It's fascinating to see the mergers of 2 dead tech. This isn't emulation or archiving; it's something that only a few hundred people can even experience. Yet it's a fascinating journey. I'm not quite sure why I like it. The excessive detail? The passion and drive? I didn't expect to enjoy it, and those kinds of surprises are nice to stumble on.
Possible user-space DoS on Linux when running on an ARM7 CPU in just two instructions. Would that be a record? If the kernel was configured to support OABI (exclusively or together with EABI), I think the following two-ARM-instr binary will simply crash the kernel if the core has alignment checking: SUB PC, PC, #2; SWI 0. I am not sure how common such configs are, but someone should maybe fix that? The fix would be only one extra instruction.
https://lkml.org/lkml/2024/12/4/503 states that OABI support is quite obscure these days and will probably be outright unbuildable at some time in the future, but what you've found still qualifies as a (likely minor) security issue that should be properly reported as such. The kernel page on security reporting is https://docs.kernel.org/process/security-bugs.html
Hai there, kernel guys. Now... assuming you first rob a museum for a working ARM7TDMI-based board, then find a way to flash it with a kernel and a rootfs to boot it, and if your kernel has an obscure and not-used-anymore ABI enabled, and you then somehow give an untrusted party ability to run code on it, they could crash the kernel using this 8-byte userspace binary.
:)
It is academically cool, no more. Quite possibly some old industrial control stuff is still running on old ARM7 boards with OABI enabled, but (i hope) they are not exposed to third party code. I guess I could send in the one line patch, if i find the time. The fix is quite trivial, funnily enough. You simply mask off the bottom 2 bits instead of assuming that LR in ARM mode is 4-byte-aligned, since on ARM7 it might not be
6502 can do it in one. 12 opcodes are glitched in a way that permanently halts the CPU, by causing it to never reset the internal tick counter (...sortof) that starts the next instruction. Recovery is only possible with a power cycle.
I was an intern at Fisher Price when they introduced the Pixter Color. I did QA on some of the games, the Dora one comes to mind. You can imagine the torture playing a level over and over.
The games were developed overseas (India I think?). I would send them bug reports in Mantis and overnight they would send a new build. Sometimes they would even fix the bugs. I would burn the builds on to EEPROMs and verify them the next day. The EEPROMS had a little round window so they could be erased in a UV box before programming.
Fisher Price used a video codec from Actimagine to fit video clips onto the game cartridges. That's how I learned about Virtualdub. I remember editing clips from a show called Winx.
The big competition was the Leapster LeapPad and they were trouncing us.
One fun thing the engineers did periodically was a toy teardown to see how competitors saved on cost. Cost was critical. They told me how Walmart basically dictates toy cost because they controlled the shelf space.
> The EEPROMS had a little round window so they could be erased in a UV box before programming.
Nitpick: That'd be a EPROM ("erasable programmable read-only memory"), not EEPROM ("electrically erasable programmable read-only memory"), right?
(But also thanks for the insight; I did wonder a bit as I was reading dmitrygr's article what the other side was of building these)
> Virtualdub
There's a blast from the past.
I remember using it to remux and join 2CD XviD movies into a single avi. Making sure to identify any duplicated key frames and delete them.
I still have a YouTube video I encoded with virtual dub ~20yrs ago.
I have an upcoming article on Pixter itself which includes giving them a LOT of credit for cost cutting. There are some quite clever things there. I also worked out how to dump games (not easy with those damn melody chips, or what did you call them?) and will release an archive of all games and working emulators.
Nice work Dmitry, looking forward to read your next article.
The later model Pixter Multimedia had the full memory space accessible via JTAG, which is how some carts and even boot ROM got dumped a while ago [1], is it the same deal with Pixter Color?
That OpenOCD script was a bit flaky, and sometimes the boot ROM would be already unloaded before reading, maybe you have some insights in how to make it more robust.
btw, have you looked into the original Pixter? The cart connector seems to have a very narrow bus, so it doesn't look like those carts have code, and probably can only be dumped with a decap.
[1]: https://qufb.gitlab.io/writeups/pixter
That only dumps the data. That’s the easy part. None of that dumps the melodies.
The pin outs that page links to are also not quite accurate. I need to finish editing my other article on this.
I have indeed looked into the original Pixter. Deeply: I have decoded the bus, documented the device, dumped games, and produced a working emulator.
The cartridges do contain memory. Most of them are about 1 MB in size, split between code (the maximum for which is 32 kB) and audio effects + images which occupy the rest of the space. If you are very, very curious and don’t want to wait for me to finish my editing, email me and I can explain how it works.
When are you going to teach a Masterclass? Reverse engineering hardware is how you get the best internship money can't buy.
I do once every few months as articles on https://dmitry.gr
> They told me how Walmart basically dictates toy cost because they controlled the shelf space.
I wonder if that is still true due to online shopping.
> when it came time to run my favourite PalmOS game - Warfare, Inc..
Also one of my favorite PalmOS games! It is worth noting that this game has been open sourced under a new name, Hostile Takeover.
https://github.com/spiffcode/hostile-takeover
Noted. Thank you!
Very impressive hack. Looking at this I now think I may have overpaid for my Palm Pilot back in the day!
For the Pixter Color in 2003 I found a price of $80 US at release. The specs aren't directly comparable (less RAM and I bet less battery life too). But still! That's less than half the cost of a black-and-white Palm m105 around the same time.
I wonder how cheap PDAs might have been if mass market forces had been applied to them. Handheld computers didn't really get the cost reduce it like a mass market kid's toy treatment until the smartphone era.
Do note that I had to add RAM to make Pixter color boot PalmOS. Pixter multimedia CAN do it standalone though.
Hats off; this kind of mad genius is the best of what I hope to read on Hacker™ News.
Dmitry is a mad genius. He has been doing stuff like this for 20 years, he was fixing palm’s issues for years. All his hardware projects are phenomenal, and so is his writing.
I aspire to be half the mad genius reverse engineer he is.
It's fascinating to see the mergers of 2 dead tech. This isn't emulation or archiving; it's something that only a few hundred people can even experience. Yet it's a fascinating journey. I'm not quite sure why I like it. The excessive detail? The passion and drive? I didn't expect to enjoy it, and those kinds of surprises are nice to stumble on.
The short of it is: I always wanted to have kids. I don’t. So I dump my excesses energy and enthusiasm into my projects.
I love posts like this. Amazing work!
I love your work, it's always very fascinating. Been reading your posts for years
Very impressive. Nice work.
Possible user-space DoS on Linux when running on an ARM7 CPU in just two instructions. Would that be a record? If the kernel was configured to support OABI (exclusively or together with EABI), I think the following two-ARM-instr binary will simply crash the kernel if the core has alignment checking: SUB PC, PC, #2; SWI 0. I am not sure how common such configs are, but someone should maybe fix that? The fix would be only one extra instruction.
https://lkml.org/lkml/2024/12/4/503 states that OABI support is quite obscure these days and will probably be outright unbuildable at some time in the future, but what you've found still qualifies as a (likely minor) security issue that should be properly reported as such. The kernel page on security reporting is https://docs.kernel.org/process/security-bugs.html
I can just imagine the report:
Hai there, kernel guys. Now... assuming you first rob a museum for a working ARM7TDMI-based board, then find a way to flash it with a kernel and a rootfs to boot it, and if your kernel has an obscure and not-used-anymore ABI enabled, and you then somehow give an untrusted party ability to run code on it, they could crash the kernel using this 8-byte userspace binary.
:)
It is academically cool, no more. Quite possibly some old industrial control stuff is still running on old ARM7 boards with OABI enabled, but (i hope) they are not exposed to third party code. I guess I could send in the one line patch, if i find the time. The fix is quite trivial, funnily enough. You simply mask off the bottom 2 bits instead of assuming that LR in ARM mode is 4-byte-aligned, since on ARM7 it might not be
6502 can do it in one. 12 opcodes are glitched in a way that permanently halts the CPU, by causing it to never reset the internal tick counter (...sortof) that starts the next instruction. Recovery is only possible with a power cycle.
6502 doesn’t host Linux :)
Being able to crash a Linux kernel from unprivileged user code is more fun.
You are sooooo cool, spending lifetime on... SHIT.