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.
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)
Being able to crash a Linux kernel from unprivileged user code is more fun.
I wonder if that is still true due to online shopping.
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.
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.
Also one of my favorite PalmOS games! It is worth noting that this game has been open sourced under a new name, Hostile Takeover.
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.
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.
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
Haha, this brought me back to working on a project with some people overseas. So much 'work' done, so little progress made.