The Pippin never really had a fair chance at life. Produced by Bandai under license to Apple, it was too expensive for a gaming console yet overshadowed in the computer market by full desktop machines. The system suffered a bit of an identity crisis as well: Was it for gaming? The Internet? Neither? Both? Pippin was one of those late-90s, pre-Jobs Apple experiments that didn’t take the world by storm and as such is largely ignored by retro gaming and computing enthusiasts.
Which is, of course, why I have one. 😀
Essentially a Power Mac 6100/66 crammed into a set-top box, in my opinion the Pippin packs a bit more power than a lot of folks realize. The Pippin had the most success in Japan, and most titles developed for it were localized for that region. Unfortunately many of those titles were authored in Macromedia Director and did little to show off the capabilities of the console. There were a number of third parties lined up to develop English software for the system in 1996 and early 1997, but this was also the era of Nintendo 64 and PlayStation, so Pippin was cancelled before many of these titles would ever ship– in some cases even before projects got off the ground. One of those titles was Presto Studios’ The Journeyman Project: Pegasus Prime, which I’ve had and continue to enjoy the tremendous honor of maintaining a modern rerelease for Windows, macOS, and Linux. Pegasus Prime almost didn’t ship at all– that Pippin was based on the Macintosh platform allowed Bandai to publish it for Power Macs instead, where certainly the returns were more promising. A number of Pippin discs could run on Macs– this was in fact a hallmark of the system. But this could also go both ways– if Pippin software is also Mac software, then shouldn’t the reverse be true? Why isn’t there a homebrew scene for the Pippin?
The only built-in software shipped with the Pippin came in the form of a circuit board with four megabytes of ROM that fit into a slot on the logic board inside the system’s case. The Pippin itself has no built-in operating system– each title shipped on one or more bootable CD-ROM discs containing a modified version of System 7.5.2. In a time before ubiquitous broadband Internet access like we have today, this allowed Bandai/Apple to provide upgrades and new features in software without having to download patches or release new hardware. But only titles that were signed or “Pippinized” by Apple could boot the system. This was done less to combat piracy (as the CDs themselves were and continue to be easily duplicated), but more to control the library, limiting the selection of titles to those produced by officially licensed developers. This is not that different from how Sony, Microsoft, and Nintendo prepare software for their respective consoles today. While the check for Pippinized discs could be skipped on test or retail kits using a special dongle provided by Apple (extremely hard to find today), development units came with a special ROM that removes the check entirely, allowing programmers to more conveniently test and debug multiple revisions before finally reaching “Gold Master” status and sending their final CDs off to be signed and pressed.
There were a couple different ROM board PCB styles– very early developers typically would get pre-production hardware with a ROM board populated with erasable Flash chips. These developers would periodically be asked to send their boards back to Apple to be reflashed with the latest ROM revision. Once the ROM was finalized and the Pippin went into production, boards shipped populated with mask ROM chips that could not be rewritten. I know of two developer ROMs, plus three ROM revisions that were released with retail consoles: 1.0 (white atMark Pippins in Japan), 1.2 (black @WORLD Pippins in the US and late atMarks), and 1.3 (very late Pippins). I have images of these three retail ROMs plus an image of the “GM Flash” developer ROM; I have never seen a retail ROM 1.1. As ROM 1.3 only shipped with a small number of Pippin units late in the system’s lifecycle, it is very rare but represents the last revision of the Pippin ROM, culminating a number of bug fixes and other changes.
ROM 1.3 also… I am told… removes the authentication check at boot, much like the developer ROMs do. 😉
I want to find out how. 😀
Power Macs produced in 1998 or later boot from Open Firmware and tend to have their ROMs loaded from a file on disk and loaded into RAM– the “New World” model. Earlier Power Macs like the Pippin also boot from Open Firmware but still have a ROM burned into a physical chip or chips attached to the logic board– the “Old World” model. Open Firmware is contained within the last 1MB of these ROMs, and overall its job is to start the 68LC040 emulator and use it to boot the rest of the ROM, which is written predominantly in 68K. Thus, the first 3MB of an Old World ROM is straight 68K code, mostly comprising the Mac Toolbox APIs and some necessary drivers for booting the system and loading the OS from a startup device. These drivers can be found in what are known as “resources”– self-contained chunks of data addressed by a four-byte “type” and a two-byte ID (or occasionally a human-readable name as a Pascal string). Resources aren’t just segments of code– they can contain any type of data such as pictures, icons, sounds, and fonts, just to name a few.
I’m quite familiar with resources– my earliest work on Pegasus Prime involved reverse-engineering some custom resource formats developed to hold metadata about the game’s QuickTime-based animations. I did some work a number of months ago trying to reverse-engineer the MacWorks XL ROM for the Apple Lisa, in an effort to port the HD20-enabled .Sony driver to it so my Floppy Emu could boot it (One of these days I should revisit that and do a writeup about it, but that project is definitely on the backburner). In the course of dissecting that ROM, I learned a lot about the Mac boot process and how the ROM’s address space in general is laid out. For example, the first four bytes of a 68K Mac ROM consist of a checksum of the ROM’s contents. Four bytes at offset 4 provide a reset vector, which the Mac uses to boot. And, at offset $1A, four bytes provide an offset to where the ROM’s resources are stored. An easy first step to understanding a Mac ROM– or in this case, that of a Pippin– would be to extract its resources and examine them in a tool such as ResEdit.
I think one of the reasons why I couldn’t readily find a utility that took a binary ROM image and spit out a .rsrc file is that the way resources are stored in the ROM has changed since the earliest Macs. The Mac Plus ROM, for example, literally stores a resource map as one would find in an actual resource fork or .rsrc file– quite simple. By the time of the Pippin, though, this had changed to a slightly more complicated scheme. I spent a few hours last night successfully reverse-engineering this and then halfway through writing an extraction tool before the evening got too late. This evening, I was greeted by a pleasant surprise:A few seconds later, I had the resources extracted from all four of my ROM images. I spent a little time tonight skimming through all I’ve found. A few highlights:
– The initials “kc” and the name “Kurt” are used for padding– these refer to Kurt Clark, presumably an engineer at Apple at the time.
– Open Firmware contains strings referencing TFTP in all the ROM revisions I have. Maybe the Pippin can boot from TFTP somehow, bypassing the authentication check?
– Gary Davidian’s 68LC040 emulator and Eric Traut’s dynarec can both be found after Open Firmware in the last 1MB of the ROM. Maybe they can be replaced with the versions found in Connectix’s Speed Doubler, saving the need for loading that INIT into RAM?
– All four ROMs contain the resources for the blinking ? and X floppy icons, as well as the recognizable Happy Mac. These icons are shown during the boot process on a real Mac but unused on the Pippin.
– There are two PPC-based ‘ndrv’ resources: .Display_Video_Apple_Control (to drive the “taos” graphics hardware) and .DAVInput, which might be used with the rear RCA audio jacks. The Pippin doesn’t have any video input capabilities, but the Power Mac 6100AV did… maybe .DAVInput and some of its associated hardware is borrowed from that machine?
– There are five 68K-based ‘DRVR’ resources– .rdrvr (for the internal 128KB of Flash storage), .AppleCD, .Sound, .Sony, .AppleSoundInput, and .EDisk. The latter two are a bit interesting– .AppleSoundInput because it’s either used for the rear audio jacks or the internal connection to the CD-ROM drive’s audio, and .EDisk because it suggests the existence of a ROM disk somewhere.
– The CD-ROM driver is identical between the GM Flash and 1.0 ROMs. But then there are major changes going into 1.2– in addition to code changes, a new drive model appears to be added to a whitelist: the Matshita CR-8006, a.k.a. the Apple CD 600e. But then, in 1.3, the whitelist reverts back to that of 1.0, while incorporating additional code changes. I’ve successfully got a Toshiba DVD-ROM drive to boot my @WORLD, so I’m not entirely sure what this whitelist is used for yet.
More to come as I dig deeper…