The Bandai Pippin has finally been cracked.
They say a picture is worth a thousand words. So I put together a fun proof-of-concept demo, and made a video to summarize these last few months.
For an in-depth technical explanation of what’s happening here, here’s some further reading:
- Exploring the Pippin ROM(s), in which I do my best to briefly explain what the Pippin is and why I set out to crack it
- Exploring the Pippin ROM(s), part 2, in which I discover that the Pippin’s boot process loads an ‘rvpr’ resource of ID 0 during the Start Manager’s phase of locating a bootable volume from the Pippin’s internal CD-ROM drive
- Exploring the Pippin ROM(s), part 3, in which I skim ‘rvpr’ 0, question its multitude of seemingly similar subroutines, and show how it patches itself in place before jumping to
main - Exploring the Pippin ROM(s), part 6: Back in the ‘rvpr’, in which I do a surface dive of ‘rvpr’ 0’s
mainloop, all the while deriving the overall structure, purpose, and usage of the PippinAuthenticationFile - Exploring the Pippin ROM(s), part 7: A lot to digest, in which I deep dive into the guts of ‘rvpr’ 0’s
mainloop, completely reverse-engineering the format of the PippinAuthenticationFile and the Pippin’s public/private RSA keys
This is awesome! 😀 Do you have plans to make the pippinizer utility you made available to the public? I’m sure a few folks would be interested in that if so.
Yep. 😉
You did God’s work, mate. Your Pippin series was a wild ride, and I’m more than glad to see you managed to get to the happy end. 😀 Can’t wait for the Pippinizer to be public!
Brilliant!
Are you creating an image with a placeholder PippinAuthenticationFile, then post-processing the image with the proper authentication data?
This might help if you’re mucking around with HFS images: https://pypi.org/project/machfs/
I apologize for my lack of knowledge in this arena. I’ve tried to follow along but this all seems way over my head. I commend you for your tremendous achievement. But I’m curious about the creation of software that would run on a pippin. We all know the system runs on a modified version of Mac system software(can’t remember the exact version) and that the system software is on each disc. How does the pippin know which software to load at boot? Also, would it then be possible to have a sort of base system disk that people could then modify by adding their own software or possibly even classic Macintosh software from that era? Then once they’ve got everything on there they could just run your utility to pippinize it and run said software. I know there would be an issue of how do you somehow map the Gamepad controls to each app but that would be another hurdle. Thanks again. This has been a fascinating adventure to watch unfold.
This Pippin technote describes the “official” process used to create bootable Pippin CD-ROMs: http://www.macgeek.org/museum/pippin/downloads/CreatPipCDs004.pdf
Some details in this technote are misleading– for instance, Pippin OS is based on System 7.5.2, not 7.5.1 as indicated. System 7.5.2 is the first version of Mac OS capable of booting a PCI-based Mac, upon which the Pippin hardware is based. In addition, this technote only mentions authentication software in passing– it’s not clear to me exactly how finalized CD-ROMs were “Pippinized” by Apple, so my utility just brute-forces the authentication file onto a finalized disc image “in-place” right now. It’s a bit messy, very time-consuming, and currently only exists as a command-line app, so I’m working on cleaning that up / making it more “user friendly.” 🙂
AppleJack (the gamepad) support was only ever provided as part of the Pippin SDK via a custom API that games had to explicitly support… until InputSprocket shipped in 1996. By then a limited number of ADB-equipped AppleJack controllers were on the market for use with Power Macs, so InputSprocket came with an AppleJack plugin allowing games supporting IS to target the Pippin’s gamepad. I don’t know whether any Pippin games were released built against InputSprocket (DrawSprocket was encouraged, though), but IS definitely works on the Pippin and has much better documentation/support than the original AppleJack software does/did, so I recommend it over the original AppleJack API.
Later versions of the AppleJack INIT apply a predefined mapping to the keyboard if the gamepad is not explicitly handled. When testing AppleJack 2.2.0 I found that the d-pad is mapped to the arrow keys, the “Stop” button on the front of the gamepad is mapped to Command-Q (for quit), and the face buttons are mapped to the q, w, e, and r keys in clockwise order, starting with the blue button. A good starting point would be to map these buttons on a real Mac, then saving the app’s prefs file to the System Folder of the target boot CD-ROM. 🙂
Fascinating. My pippin and I are looking forward to this. Granted my clumsy tinkering I’m sure will not lead to anything. It’s still fun to try.
Wow, really that was it for making a Pippin cd from existing software?! Apple certainly made it easy for developers to port their software over. I find it funny that their elegant solution to automatically launching software was to get you to make an alias and drop it in the startup items folder.
It’s interessant, but many games do not use the default mapping.
I have tried a lot of game with a keyboard, and the correspondance change between games (Power Rangres use the arrow *and* WASD for the mouvement, etc.). And many game do not use the button, and only the trackball and the two button