Cloning the Pippin Flash ROM board

[blitter]

Hi all,

Since Dandu's dump of the 1.3 Pippin ROM (which supposedly does no authentication checks), my interest in Apple's only foray into the gaming console space has been renewed. I do a bit of homebrew game development for the Atari 2600 and Nintendo Virtual Boy in my spare time, and a few years ago ported an unreleased Pippin title to OS X and Windows, so I'm very interested in the possibility of unlocking homebrew for the Pippin.

I currently have in my custody two Pippin units on loan: a retail US @WORLD model, and a late atMark prototype. Both kits have the stock 5MB of RAM. I have dumped the ROMs of both units-- the @WORLD has ROM 1.2, and the prototype unit has the "Golden Master" pre-release ROM. Using Pease Turbo, I can (occasionally-- it's pretty flaky) mount an AppleShare over the printer port and run my own software, albeit very slowly. Relying on Pease Turbo however (or even the "Tuscon" CD-ROM) imposes additional constraints, particularly with regard to what INITs and other system files I may or may not choose to load at startup. I can alternatively mount an external hard drive using a dual drive SCSI ribbon cable in either kit, but only the prototype with the GM ROM can boot from an external drive. This by itself opens up a world of possibilities for running my own software on the Pippin-- anything that can run well in 3500K of RAM on a Power Mac 6100 is a solid candidate.

However, therein lies the rub-- I can only fully take control of the prototype system. Pippins are scarce enough, pre-release units even more so, 1.3 ROM Pippins possibly rarer than that. Seems I've hit a wall if I want a realistic shot at this.

Maybe not. All Pippin ROM boards are 120-pin PCBs with an as-of-yet unknown pinout. Retail Pippin ROM boards are populated with four custom Apple chips-- most probably ROM chips of some type, but without public datasheets or other relevant documentation, that's a dead end. *However* the GM ROM my prototype has is populated not with custom Apple chips, but with 16 AMD erasable Flash chips; AM28F020-120JC chips to be precise. Bonus points: the datasheet for that chip *is* available! Looks like my GM ROM was for the most part built with off-the-shelf components, the PCB itself notwithstanding.

What does all this mean? If the GM ROM board can be traced, and thereby cloned (not entirely unlike dougg3/BMOW's ROM SIMMs), then one could conceivably flash their own Pippin ROM and use it in a dev kit, a retail kit, or any Pippin really. In the absence of the RSA signing key and process to create new authenticated Pippin boot discs, this could be the key to making Pippin homebrew available to a wider audience. I don't know the capabilities of the 1.3 ROM since I have yet to experiment with it, but I do know that the GM ROM does allow for arbitrary software to boot and run, so at the very least, a cloned ROM board could be flashed with this ROM and thereby run homebrew software. As a test, I swapped out the 1.2 board for the GM board in my @WORLD with no observed issues, so if there are any differences in the final hardware, they appear to be irrelevant.

Now, I have some good news and some bad news. The bad news is that unfortunately, the GM ROM board appears to be a multi-layer PCB, so tracing it out will be non-trivial. I do not have access to an x-ray machine (yet, but I'm working on it) nor am I willing to destroy this rare board in my efforts by sanding down each layer. The good news though is that I think(?) I've determined the pin numbering based on labels near the ROM socket on the Pippin logic board, and based on those labels and the datasheet for the Flash chips, I've traced out a small percentage (about 1/6th) of the pins that have visible traces on the outer layers of the PCB.

I admit that I am in way over my head with this endeavor; I am very much a software guy, and I'm doing this mostly so I can get to the software part. Is there anybody with experience tracing multi-layer boards who could give me tips as to what to do next, what questions to ask, and/or who to go to for help?

Thanks

 

[trag]

Does the Pippin ROM module resemble any of these?

https://www.prismnet.com/~trag/PCB/ROM_Modules_back.jpg

https://www.prismnet.com/~trag/PCB/ROM_Module_front.jpg

These were in common use by Apple at the time. The pinout is here:

https://www.prismnet.com/~trag/Apple_pinouts/Firmware_Module_Pinout.txt

Oh, just noticed the 120 pin description. The modules above are 160 pins. Nevertheless if the chips on them appear the same then they're well known 44 pin PSOP chips which have essentially the same pinout whether they are ROMs or flash chips. A chip programmer with PSOP44 adapter should be able to read them using the description for the Atmel or Hyundai flash in the same package.

 

[blitter]

Thanks for the insight, trag! The GM ROM uses 32-pin PLCC chips, but looking at the retail 1.2 ROM, the chips used on that board appear to be 44 pins each. Maybe these are PSOP chips as you suggest?

I have to assume these chips are 5V, since the GM ROM uses 5V chips and works in my retail kit. Maybe it would be easier (or might provide more info) if I try to trace the retail board as well?

Using PSOP chips would actually be easier since the byte ordering for those chips is known-- dumps of at least one retail Pippin ROM are available as one 4MB image and as images of each individual chip. I do not have a PLCC programmer so my GM ROM dump is monolithic. (I wonder if the byte ordering corresponds to the labeling on the board? U1, U2, U3, etc.)

 

[Compgeke]

Use a multimeter in continuity mode to see what pin goes to where. Stick one probe on a ROM pin and swipe along the gold contacts until it beeps, that'll be where that pin goes. Repeat for each pin.

If a pin doesn't go down to the fingers, use the same method along the rows of the other ROMs to see if for some reason one ROM connects to another.

 

[Trash80toHP_Mini]

Primer for casual readers: address and data lines will be likely each be tied together across ROMs in the form of a group of buses. CAS and RAS lines select which portions of the resulting grid are activated for any given read.

IIRC of course.

 

[trag]

I posted some datasheets for those 44 pin PSOPs at http://www.prismnet.com/~trag/Datasheet .

The 29f800, 28f800 and hy29f800 are the files. They're all similar. Of course a ROM will be a little different, but all the pins for reading the chip are in exactly the same place. I've read Apple's ROMs this way before on a chip programmer.

At a guess, the Pippin module is very similar to the 160 pin module but only has 32 data pins instead of 64, maybe. Do you know, does the Pippin have a 32 bit data bus?

 

[blitter]

Thanks to trag, Compgeke, and a friend whose multimeter I'm borrowing, I now have a pinout of the retail Pippin ROM board. Since the pins are not visibly numbered on the board itself, I've numbered them starting with pin 1 on the chip side looking left to right with the pins facing down, and then continuing with pin 61 on the back side from left to right, again with the pins facing down. I used a datasheet of a 29F800 SOP44 chip as my reference, and the pinout seems organized and makes some amount of sense to me, so I think this is correct.

(Edit: code formatting apparently doesn't work? So I put it in a pastebin document instead: https://pastebin.com/YM7U9ufP)

Some observations:

- Each chip has all of its 16 data pins mapped 1-1 to pins on the edge connector, for a total of 64 data pins.

- Each of the 19 address lines are tied together across the four chips. Combined with the above point, it looks to me like the ROM has a 64-bit word size?

- Pin 26 and pin 95 show that the Output Enable lines for the respective chip pairs U1/U2 and U3/U4 are tied together. Not sure why this is, when all data lines are connected-- maybe the Pippin has a 32-bit data bus and there's some magic going on that allows each 64-bit word to be read in 32-bit halfwords? It's also possible that OE# for all chips is always active, allowing the Pippin to grab the full 64-bit word at once.

Some questions:

- Reading the datasheet for the 29F800, there are some pins that look like they should be connected to logic high/low (RESET# immediately comes to mind), but I couldn't trace them. Maybe they're going to a power plane or ground plane that I can't easily access?

- What are the bypass caps on the chip side of the board connected to? (Are those caps polarized? I didn't test them for fear of accidentally blowing them. I am a noob at this, after all-- better to be safe than sorry, especially with rare hardware like this.)

 

[blitter]

Follow-up to my last post: The bypass caps are probably just bridging Vcc and GND to filter out noise, given their proximity to the Vcc pins on the chips themselves. Probably 0.1uF ceramics or similar.

 

[defor]

This is relevant to my interests...

I've got a GM system, a preproduction Dev system, and two retail systems

I've done some hardware hacks to to restore ADB, soft power on, and cd-rom emulation on one of my retails, but I've been looking closely at options for populating the onboard rom pads and custom rom boards over the last couple years.

I can see about making up proper schematics for the rom boards- I'm also interested in the rom splitting layout, so I think it's worth the time time to remove the rom chips off the pcbs and dump them- would also facilitate getting a more accurate pcb trace.

 

[defor]

 

[defor]

I don't believe there's any need to clone the GM ROM PCB, as all the functionality, save /WE (write enable) is implemented in the retail ROM PCB, and /WE can be enabled by soldering 4 wires, one to each FLASH chip on the PCB.

I finished the tracing of the retail and the GM ROM and today.

A few notes:

• For whatever reason, pin 1-2 is a straight pass-through, connecting to no other components, and both pins are connected to the same +12v bus that is present on both the Molex and PSU connector.
  
   
• /WE pins are only present on the GM ROM PCB, but if Flash is installed on a Retail PCB, you should be able to wire to the /WE pin of each chip to allow programming from the card edge.
   
• /ROM appears to function as ROM card insert detect. It is jumped to GND on the Retail PCB, but is N/C on GM. Presumably, this means that if the motherboard ROM pads are populated, a retail PCB can override them, but a GM (FLASH) PCB cannot. A simple jumper between pin 42 and 44 on the GM ROM PCB should allow this functionality, should someone solder rom to the motherboard. The pin terminates at Pin 77 of U1. A resistor at R83 will also work to pull this signal low, and bypass any onboard ROM. Strangely, this resistor is NOT present on the GM motherboard, yet the system still boots from ROM card, so perhaps it sets priority if BOTH motherboard and ROM card are present.
   
• The motherboard ROM chip layout (if you want to transfer the ROMs from the ROM PCB to the motherboard) is as follows:
  ​U31=U1
• U35=U2
• U15=U3
• U20=U4

[*]The GM ROM PCB is functionally equivalent, but uses (4) 28F020 chips for each of the 28F800 equivalent chips to substitute for the planned 28F800-equivalent Mask ROMs that were not yet ready. The correlation is as follows:

• 
  U1=U8-9,16-17
• U2=U6-7,14-15
• U3=U4-5,12-13
  
• U4=U2-3,10-11
  

Without further ado, here's my final pinout of the Retail ROM card:

Apple Pippin ROM PCB Pinout
(c) 2017 defor (Eastrain Design)

Rear of Pippin
:------:------:
+V12 |- 2 1 -| +V12
Data 0 (U1) |- 4 3 -| Data 0 (U3)
Data 1 (U1) |- 6 5 -| Data 1 (U3)
Data 2 (U1) |- 8 7 -| Data 2 (U3)
Data 3 (U1) |- 10 9 -| Data 3 (U3)
+5V |- 12 11 -| Ground
Data 4 (U1) |- 14 13 -| Data 4 (U3)
Data 5 (U1) |- 16 15 -| Data 5 (U3)
Data 6 (U1) |- 18 17 -| Data 6 (U3)
Data 7 (U1) |- 20 19 -| Data 7 (U3)
Ground |- 22 21 -| +5V
Data 8 (U1) |- 24 23 -| Data 8 (U3)
Data 9 (U1) |- 26 25 -| Data 9 (U3)
Data 10 (U1) |- 28 27 -| Data 10 (U3)
Data 11 (U1) |- 30 29 -| Data 11 (U3)
+5V |- 32 31 -| Ground
Data 12 (U1) |- 34 33 -| Data 12 (U3)
Data 13 (U1) |- 36 35 -| Data 13 (U3)
Data 14 (U1) |- 38 37 -| Data 14 (U3)
Data 15 (U1) |- 40 39 -| Data 15 (U3)
Ground |- 42 41 -| +5V
/ROM |- 44 43 -| No Connect
:------:------:
:------:------:
No Connect |- 46 45 -| No Connect
No Connect |- 48 47 -| No Connect
+5V |- 50 49 -| Ground
No Connect |- 52 51 -| Address 1
Address 0 |- 54 53 -| Address 2
Address 3 |- 56 55 -| No Connect
Address 5 |- 58 57 -| Address 4
Address 7 |- 60 59 -| Address 6
Address 9 |- 62 61 -| Address 8
Address 11 |- 64 63 -| Address 10
No Connect |- 66 65 -| Address 12
/Write Enable (U1/U2) |- 68 67 -| /Write Enable (U3/U4)
/Output Enable (U1/U2) |- 70 69 -| /Output Enable (U3/U4)
Ground |- 72 71 -| +5V
Address 13 |- 74 73 -| Address 14
Address 15 |- 76 75 -| Address 16
Address 17 |- 78 77 -| Address 18
No Connect |- 80 79 -| No Connect
+5V |- 82 81 -| Ground
Data 0 (U2) |- 84 83 -| Data 0 (U4)
Data 1 (U2) |- 86 85 -| Data 1 (U4)
Data 2 (U2) |- 88 87 -| Data 2 (U4)
Data 3 (U2) |- 90 89 -| Data 3 (U4)
Ground |- 92 91 -| +5V
Data 4 (U2) |- 94 93 -| Data 4 (U4)
Data 5 (U2) |- 96 95 -| Data 5 (U4)
Data 6 (U2) |- 98 97 -| Data 6 (U4)
Data 7 (U2) |- 100 99 -| Data 7 (U4)
+5V |- 102 101 -| Ground
Data 8 (U2) |- 104 103 -| Data 8 (U4)
Data 9 (U2) |- 106 105 -| Data 9 (U4)
Data 10 (U2) |- 108 107 -| Data 10 (U4)
Data 11 (U2) |- 110 109 -| Data 11 (U4)
Ground |- 112 111 -| +5V
Data 12 (U2) |- 114 113 -| Data 12 (U4)
Data 13 (U2) |- 116 115 -| Data 13 (U4)
Data 14 (U2) |- 118 117 -| Data 14 (U4)
Data 15 (U2) |- 120 119 -| Data 15 (U4)
:------:------:

I have also posted a copy here until this CODE block formatting is fixed: https://pastebin.com/raw/6CLsf9VL

 

[trag]

The reset# pin on the 29F800 must be tied inactive (can't remember low or high, high I think) in order to read the chip.   So when using it in a purely ROM type application, you'll want build your board to be able tie that pin High, IIRC.  But, you might not always want to use a chip which has a Reset, so it's best to design the board with a resistor position that will tie that pin high.   Then, if you use a Flash that has a Reset pin, install the resistor.

The 12V on pin 1/2 is there so that they could build the module with EEPROMs that require 12V on the program pin in order to reprogram the contents.   But most modules probably weren't laid out to bring the 12V to the appropriate pin.

This thread:  https://68kmla.org/forums/index.php?/topic/15485-pex-rom-project/?p=154632 goes into detail about the relationship between software ROM dumps and the content of the chips on Apple's ROM modules.   The real meat starts around page 2, but you might need the context on page 2.   It is possible to dump the ROM contents to disk on a working machine and then create the four chip programming files, without ever desoldering and reading the chips.

 

[blitter]

Looks like your pinout of what I assume is the ROM *socket* on the Pippin motherboard matches pin-for-pin my tracing of the retail 1.2 Pippin ROM board, defor (plus filling in a few missing pins in mine, namely the Write Enable, +12V, and /ROM). Thanks for sharing, this is very reassuring.

EDIT: Scratch what I said-- of course it's the socket, but it's also the PCB, since it fits in the socket. That's what I get for posting at 230am...

 

[defor]

Looks like your pinout of what I assume is the ROM *socket* on the Pippin motherboard matches pin-for-pin my tracing of the retail 1.2 Pippin ROM board, defor (plus filling in a few missing pins in mine, namely the Write Enable, +12V, and /ROM). Thanks for sharing, this is very reassuring.

Heh, no worries- yes, I used the 1.2 PCB mostly, then compared it with the GM PCB to sort out the pinout and the reserved pins.

While the GM seems the logical starting point for a reprogrammable/repro PCB, the retail design makes more sense to work from.

I'm also not 100% sold on /ROM, but it's the most likely candidate. for what the pin does.

The reset# pin on the 29F800 must be tied inactive (can't remember low or high, high I think) in order to read the chip. 

The 12V on pin 1/2 is there so that they could build the module with EEPROMs that require 12V on the program pin in order to reprogram the contents. 

Good point about reset- I haven't worked much with 29F800 and the like (Normally most of my projects only use traditional DIP EPROMS, so I wasn't fully aware of the operation of /RESET.

Looking at some documents from the SNES repo community, word is that /WE and /RESET need to be held high when in read mode.

This matches what you're saying as well

I wasn't thinking down the thought process of a programming voltage, but that's fair.

I agree the 1.3 dump we have is all that's necessary, I just like to verify the proper byte/chip splitting manually.

 

[defor]

Got a SOP adapter in the mail today.

I dumped my ROM chips directly this time as a 29F800 device.

As expected, my programmer detects pins 43 & 44 (/WE & /RESET) as not connected- no surprise there of course.

Dump matches existing per-chip dumps for the retail ROM.

The data is split across all four chips, each stripe 16 bits wide and byte swapped.

I made two quick python scripts for merging and splitting the rom (This should allow the burning of the 1.3 ROM using 29F800's.

# merge_pippin.py - Apple Pippin ROM Merge

rom = open("rom.bin","wb")
u1 = open("u1.bin","rb")
u2 = open("u2.bin","rb")
u3 = open("u3.bin","rb")
u4 = open("u4.bin","rb")

while True:
  data = u1.read(2) + u2.read(2) + u3.read(2) + u4.read(2)
  if not data: break
  rom.write(data[::-1])
rom.close()

# split_pippin.py - Apple Pippin ROM Split

u1 = open("u1.bin","wb")
u2 = open("u2.bin","wb")
u3 = open("u3.bin","wb")
u4 = open("u4.bin","wb")
rom = open("rom.bin","rb")

while True:
  data = rom.read(
  if not data: break
  u1.write(data[:5:-1])
  u2.write(data[5:3:-1])
  u3.write(data[3:1:-1])
  u4.write(data[1::-1])
rom.close()

 

[trag]

Do you have a source for the blank flash/EEPROMs?  I'm swamped at the moment (seven exams in next 44 hours) but I have a bunch of them in the attic.  Oh, and I recommend you get 90 ns or faster.  I think I tried 120ns once and they didn't work.

 

[defor]

I was gonna order from digikey (part number 1092-1083-ND)- I was a bit confused about the top/bottom boot sector, but I'm not finding anyone using bottom... also not even sure if it even matters.

I also did some test fitting, and while I'm not sure I will, it DOES appear that the GM PCB design will fit PLCC32 sockets- they'd be butted up against either flush, but the pads DO line up.

It's possible that at one point Apple even had development units using the sockets, given the spacing.

I mean, GM's aren't exactly prototypes, but they're also not exactly COMMON either.

 

[blitter]

I think top/bottom only matters with regards to writing, specifically a small bootstrap program, and since the Pippin ROM isn't organized that way then it's pretty irrelevant for our purposes.

 

[defor]

Yeah- that was exactly what I was thinking as well...