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.
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.
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.
I love posts like this. Amazing work!
I love your work, it's always very fascinating. Been reading your posts for years
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
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.
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
> 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
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.
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.
I love posts like this. Amazing work!
I love your work, it's always very fascinating. Been reading your posts for years
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
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.