Apple Network Server MacOS based ROMs found

[Jockelill]

Can a ROM SIMM be created that has a switch to switch between two different ROMs while the Power Mac is running?

The first ROM would be a working ROM to boot into Open Firmware.

The second ROM would be the target for flashing.

Boot the first ROM into Open Firmware, then flick the switch to select the second ROM for flashing. Then use the serial port to transfer the flashing program and the new ROM.

This would eliminate the need for an external flasher and it would add safety to the ROM flashing process.

Yes, is the short answer, but it’s a little bit more complicated than that. Essentially the ISP that @zigzagjoe has created does this for the se/30 and Quadras, it even has a reset output that automatically restarts the computer when flash is finished. It uses a RP2040 which you hook up to your PC, the ROM then appears as a storage device, and you reflash it with uf2-files. Since it has 16MB of storage, there is a switch onboard, switching between two banks, so on one of them you can put “last known working ROM”. This device is perfect for playing with the rom and for rapid development.

Something like this is what I would like to see also for the PPC . Issue is of course the 64 bit data path, so even with an 2350B with 48 GPio it would need multiplexers to work, plus buffers towards the machine and so on.

For a first test of hacking I believe @dougg3 idea of 8 standard chips is easier to have up and running.

 

[joevt]

As long as it's running fully from RAM at the point that you switch ROMs it would work fine.

Should perform a test in DPPC to see if anything (exception handlers?) in ROM is accessed after Open Firmware is set-up. Can do a copy to RAM and virtual memory to compensate maybe.

 

[dougg3]

Yeah, if the ROM is accessed after OF is up, it would be tricky to add a switch because it's game over after the switch is flipped to the second ROM.

If you can prove the ROM is not accessed, or guarantee to not access the ROM after a certain point and give the user a chance to flip the switch after that point, then yes, I think a switch could potentially work. You could have the switch re-route the /OE and /WE signals to a different set of 8 flash chips, or maybe find larger chips and use the switch to toggle the highest address line on them or something. I think that's similar to what Garrett's Workshop's ROM SIMM does with the separate selectable ROMs.

 

[joevt]

The name of the ROM Flashing Utility is "Flasher (TNT 0.6)". I ran it in DingusPPC emulating a Power Mac 9600 v1.
DingusPPC shows the code below after setting the RomWE bit of the ROM Timing Register.
It uses 8 byte read/writes to FFC00000 and FFE00000 to probe the ROM (offset 0 and offset 2 MiB).
It writes patterns 9090909090909090 and 909090909090909.
Then it tries to read the results.
DingusPPC doesn't emulate flashing yet, so the result is just the bytes of the ROMs at those addresses.
I guess real flash chips would return some kind of Flash Chip ID.

It looks like the code for read-ROM-id-AMD-4M? or read-ROM-id-intel-4m? in the B&W G3 Firmware update code which also uses 64-bit read/writes.

You can probably also find similar flash id code in flashrom.
https://github.com/joevt/flashrom

Working on porting B&W G3 Firmware update to ANS/TNT Open Firmware.
I'll try making DingusPPC emulate flashable ROM to test that and to see "Flasher (TNT 0.6)" work to completion.

 

[joevt]

"Flasher (TNT 0.6)" expects AMD 28F020 (vendor/ID = 01,2A) or Intel 28F020 (vendor/ID = 89,BD). Since these chips are 2 Mb there are 16 chips = 4 MiB.

8 chips are accessed using 8 bytes at ROM base + 0 (1 byte per chip). The other 8 chips are accessed using 8 bytes at ROM base + 2 MiB (1 byte per chip). All chips must report the same vendor / ID.

 

[Jockelill]

"Flasher (TNT 0.6)" expects AMD 28F020 (vendor/ID = 01,2A) or Intel 28F020 (vendor/ID = 89,BD). Since these chips are 2 Mb there are 16 chips = 4 MiB.

8 chips are accessed using 8 bytes at ROM base + 0 (1 byte per chip). The other 8 chips are accessed using 8 bytes at ROM base + 2 MiB (1 byte per chip). All chips must report the same vendor / ID.

Yes, unless you hack the flasher tool you're stuck with those chips. I know @dougg3 managed to hack the flasher tool to at read the M29F160FB5AN6F2 chips (those are used for Rominator and similar), but I think @dougg3 idea here was to use socketed chips and then flash them one by one (8 times) with an external flasher like the TL-866.

 

[Figgy2112]

I love that we are getting all this cool Mac OS on stuff it didn’t release for, My favorite type of ****ery with old computers

 

[joevt]

Yes, unless you hack the flasher tool you're stuck with those chips. I know @dougg3 managed to hack the flasher tool to at read the M29F160FB5AN6F2 chips (those are used for Rominator and similar), but I think @dougg3 idea here was to use socketed chips and then flash them one by one (8 times) with an external flasher like the TL-866.

Did Apple reverse the order of the data bits for 8 of the 16 Am28F020 chips?
i.e. D0-D7 -> D7 D0?

 

[dougg3]

Did Apple reverse the order of the data bits for 8 of the 16 Am28F020 chips?
i.e. D0-D7 -> D7 D0?

When I was investigating an older version of the Flasher app, I saw that there was an option bit that would cause the unlock/erase/etc. sequence data bits to be reversed on the second set of chips, and at least one of the items in the table of possible machines+SIMMs had the option set. So yeah, I think at least on some programmable stuff, they reversed the data bits.

I'm pretty sure the reason would be that it greatly reduces the complexity of the PCB routing. The data bits are along the bottom of the chip:

So if you have 8 chips on the other side of the board, reversing the data bits on them allows DQ7 on the back chip to be hooked to the same data line as DQ0 on the front for example.

 

[joevt]

What is 28F020 command 30h? I don't see it in the Intel or AMD data sheets. Do flashable ROM SIMMs have extra logic to catch this command?

 

[SuperSVGA]

What is 28F020 command 30h? I don't see it in the Intel or AMD data sheets. Do flashable ROM SIMMs have extra logic to catch this command?

Sounds like chip erase but I think that's only the AM28F020A.

 

[dougg3]

Sounds like chip erase but I think that's only the AM28F020A.

Agreed, I think it's chip erase. In my disassembly of Flasher I did see command 30h used in the erase function for a PowerBook Duo flash ROM that has Am28F020A chips (manufacturer 01h, device 29h).

Interestingly, it's also used for erasing with several other configs including a ROM SIMM in several Quadra models that looks for manufacturer 01h and device 2Ah, which matches the Am28F020. I'm not sure if it was an undocumented command in that flash chip, or a bug in the Flasher app, or what. Because some other SIMMs with the Am28F020 use the documented "write all zeros and then command 20h for erase" algorithm instead. Dunno what's up with that!

 

[joevt]

Sounds like chip erase but I think that's only the AM28F020A.

Right. There's some code that chooses between different Erase and Program methods.
My emulation return 01/2A as manufacturer / device IDs so I don't know why the code would use the 30h command for erase.

 

[joevt]

"Flasher (TNT 0.6)" expects AMD 28F020 (vendor/ID = 01,2A) or Intel 28F020 (vendor/ID = 89,BD). Since these chips are 2 Mb there are 16 chips = 4 MiB.

8 chips are accessed using 8 bytes at ROM base + 0 (1 byte per chip). The other 8 chips are accessed using 8 bytes at ROM base + 2 MiB (1 byte per chip). All chips must report the same vendor / ID.

It appears that "Flasher (TNT 0.6)" cannot do Intel 28F020 chips because it's looking for a device ID of DB instead of BD from 8 of the chips.

Right. There's some code that chooses between different Erase and Program methods.
My emulation return 01/2A as manufacturer / device IDs so I don't know why the code would use the 30h command for erase.

AM28F020.PDF has device ID 2A. It describes non-embedded erasing/programming commands (20h, A0h, 40h, C0h).
AM28F020A.PDF has device ID 29. It describes embedded erasing/programming commands (30h, 50h)

For AMD chips, "Flasher (TNT 0.6)" expects device ID 2A from AM28F020.PDF but uses the embedded erasing/programming commands of AM28F020A.PDF.
Maybe the PDFs got the device IDs reversed? I dunno.

For Intel chips, "Flasher (TNT 0.6)" uses the non-embedded erasing/programming commands of AM28F020.PDF.

I finished the emulation in my fork of DingusPPC of the AMD chips for "Flasher (TNT 0.6)" (code not committed yet).
It can also do Intel chips (a hack can be used to make 8 of the chips return DB instead of BD to work around the bug in "Flasher (TNT 0.6)" but probably the better solution is to change DBDBDBDBDBDBDBDB to BDBDBDBDBDBDBDBD in the XCOFF resource in "Flasher (TNT 0.6)").

The PDM flasher (Power Mac 6100/7100/8100) and New World Open Firmware flashers (iMac G3, B&W G3) are not supported yet in DingusPPC.

 

[joevt]

Another note: "Flasher (TNT 0.6)" doesn't try to detect the ROM type before flashing. It says AMD for both AMD and Intel chips.

"Flasher (TNT 0.6)" has direct drawing to the screen to show a progress bar - vertically oriented. 480 lines tall, 80 bytes wide. It fills up for each stage of the flashing - three different colors - white, black, checkerboard (or strips if not using B&W mode)

 

[joevt]

There are newer Flasher utilities that support later PowerPC Macs besides PDM and TNT but that doesn't matter for this ANS project.

read 'XCOF' (128) ":Objects:xcoffResources:CopyToFlashPDM.xcoff";
read 'XCOF' (129) ":Objects:xcoffResources:CopyToFlashTNT.xcoff";
read 'XCOF' (130) ":Objects:xcoffResources:CopyToFlashCAT.xcoff";
read 'XCOF' (131) ":Objects:xcoffResources:CopyToFlashPBX.xcoff";
read 'XCOF' (132) ":Objects:xcoffResources:CopyToFlashM2.xcoff";
//read 'XCOF' (133) ":Objects:xcoffResources:CopyToFlashPSX.xcoff";
read 'XCOF' (134) ":Objects:xcoffResources:CopyToFlashTanzania.xcoff";
read 'XCOF' (135) ":Objects:xcoffResources:CopyToFlashOpus.xcoff";
read 'XCOF' (136) ":Objects:xcoffResources:CopyToFlashGossamer.xcoff";
read 'XCOF' (137) ":Objects:xcoffResources:CopyToFlashPEx.xcoff";
read 'XCOF' (138) ":Objects:xcoffResources:CopyToFlashGrackleROM.xcoff";
read 'XCOF' (139) ":Objects:xcoffResources:CopyToFlashGrackleRAM.xcoff";