The security around developing these things pre launch was a bit hilarious, even compared to later mobile devices/tablets. A few of the members of one team I worked on were instructed to bring their passports to work in the months running up to any expected announcement, and when notified they would be dispatched to a basement in Cupertino with laptops with self contained build environments (a major headache) to produce the game, which would then appear on stage.

We've largely forgotten what a strangely big deal iPod launches used to be. I remember being mildly amused/amazed by the fact you could see them announced online and in use on the London Underground within hours.

▲

q3k 6 days ago | parent [-]

Ooh, I have a lot of questions if you're willing to answer them :). I've been reverse engineering the original iPod software for the iPod Nanos for some time now, and I've seen the interface to 'eApps' (what they seem to call loadable applications) from the OS point of view [1], but I've always wondered about the app developer experience.

What was the SDK/toolchain like? Did you have any way to test the software in an emulator/simulator on a PC? What was debugging like? Was the iPod software/hardware you were developing against in any way special?

[1] - IIRC after the binary is decrypted, loaded into memory at a fixed address, and a symbol table (based on numeric IDs, not strings) is used to populate a trampoline with function pointers that the app requested. There seems to be no privilege separation between the app and the rest of the OS, as is the case for the iPod software in general.

▲

fidotron 6 days ago | parent [-]

TBH had I known too many of the specifics of the platform by now they would be forgotten or I wouldn't be able to mention them!

These games were largely heavily derived from their Brew/WinMo/Symbian versions, which were (subset of) C++ games developed on PCs and then retargeted to embedded devices using compilers with annoying licensing servers. Almost everyone that did this enough had their own PC runtime, and would barely touch any device/platform specific emulator even if it existed, a situation that remained the case until Unreal/Unity took over.

> There seems to be no privilege separation between the app and the rest of the OS, as is the case for the iPod software in general.

This was/is common for most RTOS type environments where MMUs were not a thing. For example, the whole point of Brew and J2ME was to provide some level of separation prior to the later Symbians and then Android/iOS etc.

	▲	q3k 6 days ago \| parent \| next [-]
		> TBH had I known too many of the specifics of the platform by now they would be forgotten or I wouldn't be able to mention them! Thanks anyways! :) > This was/is common for most RTOS type environments where MMUs were not a thing. For example, the whole point of Brew and J2ME was to provide some level of separation prior to the later Symbians and then Android/iOS etc. Right - although all the S5L series chips used in the later iPods had an MMU (other than the S5L8701 in the Nano 2G, which only had an MPU). They also had a pretty tight boot chain (all stages signed/encrypted). It's a weird contrast to the pretty lax security measures within the OS itself :). But I guess reworking the old iPod codebase (which started with PortalPlayer chips) to make use of the MPU/MMU would have been too much effort.
	▲	aleph_minus_one 5 days ago \| parent \| prev [-]
		> Brew/WinMo/Symbian To save you googling: * BREW (Binary Runtime Environment for Wireless): https://en.wikipedia.org/wiki/Binary_Runtime_Environment_for... * WinMo: Windows Mobile