Apple Network Server MacOS based ROMs found

[Image: 1761519938098.png]

@johntucker, @joevt, @ClassicHasClass, and myself have been working to get these ROM's dumped and some analysis done on them to see the differences (I'll let @joevt post his OF analysis below).

Current Status: We have the ROM's dumped, but now need a way to program them. The ROM board/s are AM28F020 and I believe are the same/similar to what other PowerMacs had (photo via @johntucker )

[Image: 1761490029513.png]

I'll keep this first post updated as all the details emerge.

Many thanks to everyone (especially @johntucker) for making this possible!

This is awesome, amazing group effort - can't wait to see what is possible! [clap]

For those unclear on the historical context (there were even Windows NT ROMs promised), I did a summation here.

[Image: oldvcr.blogspot.com]

The Apple Network Server MacOS ROMs have resurfaced

The 1996 Apple Network Server was Apple's first true Unix-through-and-through server (the Apple Workgroup Server 95, actually a Quadra 950...

[Image: oldvcr.blogspot.com] oldvcr.blogspot.com

I will post ROMs to my MacROMan fork and add some notes here later.

The last ROM we're working on has problems. It has errors in byte lane 2 (8 lanes numbered 0 to 7).
Byte lane 2 is the address with least significant bits = 010.

077d.28f2.1  "Boot TNT 0.1p..]"  4096
9630c68b    045a3ff2.04a8169b.03334745.03ffe575    02d3e2e8.0324a294.0219ffa8.02895fd8.02ada29f.038afd23.023e4a4a.02aac18a:a71fb907dd180b8a
93e6ab8b x  045a3ff2.04a8169b.0330fd2a.03ffe575 x  02d3e2e8.0324a294.0217b58d.02895fd8.02ada29f.038afd23.023e4a4a.02aac18a:a4d59e07dd180b8a
    ^^                        ^^^^^^^^                               ^^^^^^^^                                                  ^^              <- errors in byte lane 2

Maybe there's an issue with one of the chips not being seated? Or corrosion on one of the pins related to byte lane 2? Try cleaning the pins or pressing the flash chips.

The attached Open Firmware script will calculate the checksums of an Old World Power Mac.
Connect via serial port, type dl to begin download, then paste the contents of the file. I added the "end of file" marker (Control-D) at the end of the script which ends the download and begins execution of the script.

The output should look like this:

0 > dl
calced: 962F6C13  045A4042.04A81401.033345A1.03FFE57D  02CDF1E7.031ED7CA.0213F083.0283859E.02A7B7CC.0385549F.02388B9D.02A4FFAA:D540B3DD5BCF9CAA
stored: 962F6C13  045A4042.04A81401.033345A1.03FFE57D  02CDF1E7.031ED7CA.0213F083.0283859E.02A7B7CC.0385549F.02388B9D.02A4FFAA:D540B3DD5BCF9CAA
 ok
0 >

"stored" is the values that is stored in the ROM.
"calced" is the values calculated by my script using the bytes of the ROM.

Compare with previous results in romlist.txt.

>> joevt said:

The last ROM we're working on has problems. It has errors in byte lane 2 (8 lanes numbered 0 to 7). Byte lane 2 is the address with least significant bits = 010. Click to expand...

According to the checksums (and doing a binary compare) the broken last ROM is identical to the first new ROM that we received (2.26b6) except for the byte 2 lane errors in the first 2 MiB of the ROM so I don't think we need to try and fix it. The broken ROM was able to get into Open Firmware because Open Firmware is in the last 1 MiB of the ROM.

It looks like my ROM chips are 8x:

Japan 9510
HN27C40000FP-
0000GSSO

Maybe: https://pdf.dzsc.com/88889/23478.pdf

Looks like one time programmable so will probably have to go the 16 AM28F020 route :)

I just wanted to say -- this is amazing. A big thank you to the person who shared the ROM and the people working to preserve it!

The ROMs

I've uploaded the 3 new ANS ROMs to https://github.com/joevt/MacROMan
There's 4 total now. They are similar to the Power Mac 9500 v2 ROM. In fact, the 2.26B6 ROM has identical first 3 MiB.

077d.28f2.1  9630c68b  045a3ff2.04a8169b.03334745.03ffe575  02c6b097.0317a71b.020d1a9e.027c620c.02a0a3bd.037df94c.0231514d.029e06b3:4db4a42fea3b53b3  2623a0c438045ea04d2cc67310c97743  "1.0.5 PM 7200 & 7500 & 8500 & 9500 (v2), SuperMac S900 (v2)"
077d.28f2.1  962f6c13  045a4042.04a81401.033345a1.03ffe57d  02cdecec.031ec3af.0213d883.02837b28.02a7be75.03853500.023892c2.02a52e8a:c60da96de537f08a  23a7bbda5681be978972517d4758bbdd  "1.1.20.1 ANS 300 & 500 & 700"
077d.28f2.1  962f6c13  045a4042.04a81401.033345a1.03ffe57d  02cdf1e7.031ed7ca.0213f083.0283859e.02a7b7cc.0385549f.02388b9d.02a4ffaa:d540b3dd5bcf9caa  676809c236138574282fa8416c6c5a6d  "1.1.22 ANS 300 & 500 & 700"
077d.28f2.1  9630c68b  045a3ff2.04a8169b.03334745.03ffe575  02d3e2e8.0324a294.0219ffa8.02895fd8.02ada29f.038afd23.023e4a4a.02aac18a:a71fb907dd180b8a  d1d3720c38143eb2bac86b8393318529  "2.26B6 ANS 300 & 500 & 700"
077d.7dd0.1  49b2be8f  044701df.046e7c5d.02fa6527.03dc24a2  02c4eb7f.0302e5d4.01f7e0a8.0273a3f7.029f509f.0368984a.021b27e4.0295cecb:5f2aeeb25507b2cb  83be626679b5c74a606cd31443063a53  "2.0 ANS 300 & 500 & 700"

I've attached some listings of the ROMs for ExceptionTable/Start, HWInit, and Open Firmware (OpenFW).

Capturing ROMs

Capturing ROM notes:
https://www.emaculation.com/doku.php/capturing_rom

AutoCopyROM:
https://www.geocities.ws/terry_teague/autocopyrom.html

There's a CopyROMs utility that comes with vMacs but it appears from the source code to only work with ROMs it knows about.

A classic Mac OS app might not work if the ROM is not mapped into virtual memory correctly.
https://macintoshgarden.org/forum/project-looking-mac-roms

I don't think any of the classic Mac OS apps do any virtual memory mapping but I haven't checked all of them. I only have the source code for CopyROMs (different than CopyROM and AutoCopyROM).

I haven't seen source code for any of the other apps except my GrabMem app which also doesn't do any virtual memory mapping. My utility for Mac OS X does do virtual memory mapping.

Disabling virtual memory might help if an app doesn't capture the ROM?

Some notes here:
https://forums.macrumors.com/thread...l-work-in-a-beige-power-macintosh-g3.2303689/
https://forums.macrumors.com/thread...eige-power-macintosh-g3.2303689/post-31329170
https://forums.macrumors.com/thread...eige-power-macintosh-g3.2303689/post-31329386
https://forums.macrumors.com/thread...eige-power-macintosh-g3.2303689/post-31491349
https://forums.macrumors.com/thread...eige-power-macintosh-g3.2303689/post-31494103

Definitely use ttya:57600 for input and output.
It's faster. I could create a nvram script to enable 115200 or 23400 bps.

Simple command:

ffc00000 400000 dump

But that's not efficient since it outputs hex addresses on every line with the binary bytes.

This command is more efficient:

0 ffc00000 do i 3f and 0= if cr then i l@ 8 u.r 4 +loop cr

It outputs 64 bytes (128 hex digits) per line.

You can change 3f to 1f for 32 bytes or 0f for 16 bytes per line.

I'm not sure which is faster: longer lines or shorter lines. Shorter lines means more linefeeds and less text to scroll but scrolls more often. Shorter lines might be less console escape characters - if console escape characters are happening. I guess one would have to capture hex bytes from serial to see if any characters other than hex digits and line feeds are being transmitted.

Open Firmware Documentation and Notes

Go to https://developer.apple.com/library/archive/navigation/#section=Platforms&topic=macOS
Search for Open Firmware. Three of the items are named "Fundamentals of Open Firmware".
Sort by date and read them in order.

The OpenBIOS page has a documentation section. IEEE 1275-1994 is for the main spec. Bindings is for all the extras (graphics, PCI, etc.)

Hold Command-Option-O-F to get into Open Firmware. Type printenv at the Open Firmware prompt to list the settings.

OpenFirmware1.1.22
To continue booting from the default boot device type:
BOOT<return>
 ok
0 > printenv
security-#badlogins 0
security-password
security-mode       none

little-endian?      false               false
real-mode?          false               true
auto-boot?          false               true
diag-switch?        false               false
fcode-debug?        false               false
oem-banner?         false               false
oem-logo?           false               false
use-nvramrc?        true                false
f-segment?          true                true
real-base           -1                  -1
real-size           100000              100000
virt-base           -1                  -1
virt-size           100000              100000
load-base           4000                4000
pci-probe-list      -1                  -1
screen-#columns     64                  64
screen-#rows        28                  28
selftest-#megs      0                   0
boot-device         /AAPL,ROM           disk2:aix
boot-file                            
diag-device         cd fd:diags         cd fd:diags
diag-file                            
input-device        ttya                kbd
output-device       ttya                screen
oem-banner                           
oem-logo                             
nvramrc             dev /AAPL,ROM : open true ; : load load <bye> ; unselect-dev
boot-command        boot                boot
 ok
0 >

Also check the devalias command:

0 > devalias
vci0                /chaos@F0000000
pci1                /bandit@F2000000
pci2                /bandit@F4000000
fd                  /bandit/gc/swim3
kbd                 /bandit/gc/via-cuda/adb/keyboard
ttya                /bandit/gc/escc/ch-a
ttyb                /bandit/gc/escc/ch-b
enet                /bandit/gc/mace
scsi                /bandit/gc/53c94
scsi-int            /bandit/gc/mesh
lcd                 /bandit/gc/lcd
screen              /bandit/54m30@F
 ok

And if you have a serial connection, then capture a dump of the device tree for us using the dump-device-tree command. zip the result and attach to a post.

You can just hold the space bar while it's dumping until it's done.

There's a lines/page value that is set to 20 by default.

lines/page .d

Change it to 0x7fffffff to remove the need to hold space bar.

7fffffff to lines/page

If you were using a terminal app that properly supports VT100 to capture the text in a scroll back buffer then the More [<space>,<cr>,q] ? prompts would be removed after accepting your input - Copy and Paste can then be used to copy the result to a text file.

On macOS, I use Serial.app when connecting to Open Firmware of a Mac via serial (older Power Macs) or telnet (newer Macs that don't have serial).
You can limit the scroll back buffer in Serial.app to a billion lines (2147483647 max). More than enough to capture 4 MB ROM dump.
I bought 2.0 for more features such as telnet support.
https://www.decisivetactics.com/products/serial/release-notes

Both versions let you change the scroll back buffer number of lines.

The DingusPPC emulator outputs serial data to a socket backend. Then I use the socat command in Terminal.app for input and output.
socat UNIX-CLIENT:dingussocket -,cs8,parenb=0,echo=0,icanon=0,isig=0,icrnl=0

Examining ROMs

tbxi dump can split the ROM into its parts (68K code, DeclData, resources, ExceptionTable, HWInit, OpenFW, Nanokernel).
https://github.com/elliotnunn/tbxi

SlotsParse can parse the DeclData (probably nothing useful as in most Power Macs).
https://github.com/joevt/SlotsDump

ROM Fiend can dump the DeclData, Dispatch Table, and Universal Tables.
https://github.com/joevt/rom_fiend

DumpMacRom.sh can convert the OpenFW part into assembly and Forth. I think this is where the Mac OS boot difference may be found, or at least the first part.
https://github.com/joevt/OpenBIOSStuff

DeRez for resources.

DumpPEF for PEFs.
https://github.com/ksherlock/mpw

etc.

Comparing the TNT and ANS ROMs

ANS 1.1.22 vs TNT 1.0.5

ANS ROM is close enough to TNT ROM that I've assigned ROM Map tnt_2.8f2_rominfo.txt to be used with the ANS ROM in ROM Fiend.

077d.28f1.1  "Boot TNT 0.1p..]"  "ROM 1.0.5 1995-08 - 96CD923D - Power Mac 7200&7500&8500&9500 v1"
077d.28f2.1  "Boot TNT 0.1p..]"  "ROM 1.0.5 1995-08 - 9630C68B - Power Mac 7200&7500&8500&9500 v2, SuperMac S900"
077d.28f2.1  "Boot TNT 0.1p..]"  "ROM 1.1.22 ANS 500 & 700"

ROM Fiend only accounts for the 68K part of the ROM. Comparing that part with TNT there's only a couple small changes (other than build dates in the PEFs). ANS has some extra code in Exception Table and HWInit (some is doing output to the LED display). TNT has OF 1.0.5 so it's difficult to compare - OF 1.1.22 from ANS has all words defined external or headers but TNT has many words defined as headerless (unnamed).

The first thing to fix in the ANS Open Firmware to allow booting Mac OS would be to fix the open and load words of the AAPL,ROM device like this:

dev /AAPL,ROM
: open true ;
: load load <bye> ;
unselect-dev

Put that in the nvramrc script using
nvedit, Control-C to end editing, nvstore to save to nvram,
do setenv use-nvramrc? true, reboot, see how far it gets.

Be sure to use a CD or hard drive connected to the SCSI bus that matches the SCSI controller used in the TNT machines.

Hopefully nothing in ExceptionTable or HWInit needs to be patched.

ANS 1.1.20.1

1.1.20.1 is very similar to 1.1.22 except for these differences:

ExceptionTable/Start stuff
- ?
HWInit
- ?
Open Firmware
- real-mode? default is false instead of true.
- diag-device default is cd fd:diags /AAPL,ROM instead of cd fd:diags
- Doesn't have properties dimm-sizes and dimm-interleaves
- Allows booting from /AAPL,ROM but will report:
  "MacOS is currently unsupported, use at your own risk.".
  Does it boot MacOS successfully?
Mac68KROM
- There's no changes (all 3 MiB of the 68K stuff).

ANS 2.26B6

ANS 2.26B6 has many changes and fixes (like the difference between 9500 v2 and Beige G3) which makes sense since it is version 2 instead of version 1. (2.26 vs 1.1.22 or 1.0.5 where Beige G3 is 2.0f1).

However, the first 3 MiB (the 68K part) is identical to 9500 v2 ROM.

The device-tree of ANS 2.26B6 has OpenFirmware2.26 while the ANS 1.1.22 has OpenFirmware1.1.22
- 2.26B6 Adds device alias for a mouse. Mouse device adds words to check the mouse button.
- 2.26B6 Adds pe-loader package
- 2.26B6 many minor changes and additions.

ANS 2.0 (for booting Mac OS)

Has version number (7dd0) which seems strange. The second digit is usually 0-9.

The 2.0 ROM has many words declared headerless (unnamed) which makes it difficult to compare to 1.1.22 or 2.26.

<bye> in ROM 2.0 has extra code to clear bit 16 (PowerPC counting) of the MSR register (disables external interrupts). I guess Mac OS expects interrupts to be disabled before booting? Is this bit normally cleared in Open Firmware? Is it set in Open Firmware of ANS? Things to look into...

The following nvramrc script code adds clearing of that bit in the MSR:

dev /AAPL,ROM
: open true ;
: load load msr@ h# ffff7fff and msr! <bye> ;
unselect-dev

Exception handlers 0x1000, 0x1100, 0x1200 are different.
I see the ExceptionTable section is missing LCD strings. There's a lot of differences here.

In HWInit, the code after Serial Test Manager is smaller and missing strings.

ANS Misc Notes

I need to add the 53c825 PCI devices to DingusPPC so that the ROM detects the hardware as AAPL,ShinerESB like in the device tree of a real ANS. The presence of a 53c825 PCI device causes the ?esb value to be set to true.

In the current emulation without a 53c825 device, the device tree has AAPL,9500.

?esb causes a few changes.
- changes AAPL,slot-name and slot-names
- changes the number of slots and allocation between bandit1 and bandit2
- ?esb true removes mesh (second built-in SCSI bus)
- serial port AAPL,connector names
- etc.

If you have 53c825 model NCR,825A then that means you have ?esb-evt2 set to true. This model has an over temperature flag that gets checked by Open Firmware while waiting for a keypress.

Flashing ANS or TNT ROMs

New World Macs have flashable ROM chips. Old World Macs usually do not.

Some ANS ROMs have erasable programable ROMs (AM28F020) and are usually/always in the ROM SIMM slot.

The Power Mac 9600 schematics show the ROM SIMM slot (sheet 6) has a ROMWE_I signal that comes from ROMDATAWEN of Hammerhead (sheet 3).
https://www.macdat.net/files/pdf/apple/schematics/apple/

The Hammerhead ERS document says 8 byte writes to the ROM will work when the RomWE bit is enabled in the Hammerhead ROM Timing Register.

This means a ROM should be flashable in place. Such ROM flashing utilities ("flash gordon") exist for classic Mac OS for 68K and PPC Macs as discussed at 68kmla, but we need an Open Firmware method for ANS that doesn't boot Mac OS. B&W G3 firmware updater has Open Firmware code for doing flashing. It could maybe be adapted for ANS. A failure that requires a reboot means the ROM SIMM would need to be flashed externally. A failure that doesn't require a reboot means you can try again with different firmware update code.

Would be nice to be able to make ROM SIMMs but any such SIMM would need to be flashed externally since they won't come with a ROM for booting to flash in place.

Found ANS 300/500 Service Source at
http://www.applerepairmanuals.com/the_manuals_are_in_here/Network_Server_500_700.pdf

>> Code:

Code: ffc00000 400000 dump Click to expand...

Wasn't it

h# ffc00000 h# 00400000 dump

? Or are the h#'s unnecessary?

Something that was pointed out to me a while ago: this PCI Power Macintosh DDK disk has a TNT version of Apple's Flasher app on it. Probably mainly useful for reflashing a flash ROM DIMM that you're already booted from, but on the off chance that it gives you any extra context I thought I'd bring it up.

>> eric said:

If you've been following my ANS 700 tinker log you'll have seen that @johntucker has recent come forward having a ANS that is able to boot into MacOS! This was a much talked about and sought after ROM back in the day as ANS's only run AIX, until now! MacOS 8.6 Booting on an ANS via @johntucker View attachment 24311 @johntucker , @joevt , @ClassicHasClass , and myself have been working to get these ROM's dumped and some analysis done on them to see the differences (I'll let @joevt post his OF analysis below). Current Status : We have the ROM's dumped, but now need a way to program them. The ROM board/s are AM28F020 and I believe are the same/similar to what other PowerMacs had (photo via @johntucker ) View attachment 24298 I'll keep this first post updated as all the details emerge. Click to expand...

Isn't this the same type of flashable DIMM found for the early PPCs?

>> ClassicHasClass said:

Wasn't it Code: h# ffc00000 h# 00400000 dump ? Or are the h#'s unnecessary? Click to expand...

They are usually unnecessary, since the default conversion radix is sixteen.
Alternatively, you could use hex ffc00000 400000 dump
Check the current conversion radix with this:

base @ .d

If the conversion radix is not 16, then ffc00000 cannot be interpreted, causing the remainder of the command to stop being interpreted and an error message is output.

>> Jockelill said:

Isn't this the same type of flashable DIMM found for the early PPCs? Click to expand...

Probably. Does anyone have schematics for a PPC flashable DIMM?

>> dougg3 said:

I'll have a look. Running it in DingusPPC may help show how it flashes a ROM.
For ANS we'll need a utility that works in Open Firmware if the goal is to write a ROM that can boot Mac OS onto a ROM that can't boot Mac OS.

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

[Flasher ( 163.916s) 00AA3518: dingusdbg> context auto 00AA3518: dingusdbg> si 100 00AA3518: 7C0004AC sync 00AA351C: 7DE803A6 00AA3520: 4E800020 blr 00AA2F2C: 48000075 bl 00AA2FA0: 4E108182 00AA2FA4: 7F5DD378 mr 00AA2FA8: 7FDDE214 add 00AA2FAC: 8050009C lwz 00AA2FB0: 807000AC lwz 00AA2FB4: 809000BC lwz 00AA2FB8: 80B000CC lwz 00AA2FBC: D8DD0000 00AA2FC0: D8FE0000 00AA2FC4: 7C0006AC eieio 00AA2FC8: C81D0000 lfd 00AA2FCC: C83E0000 lfd 00AA2FD0: C85D0008 lfd 00AA2FD4: C87E0008 lfd 00AA2FD8: 7C0006AC eieio 00AA2FDC: D89D0000 00AA2FE0: D8BE0000 00AA2FE4: 7C0006AC eieio 00AA2FE8: D81000E4 00AA2FEC: D85000EC 00AA2FF0: 80D000E4 lwz 00AA2FF4: 80F000E8 lwz 00AA2FF8: 811000EC lwz 00AA2FFC: 813000F0 lwz 00AA3000: 7C063800 00AA3004: 4C820020 bnelr 00AA2F30: 40820034 bne 00AA2F64: Error; Disable 00AA2F64: 6403F300 00AA2F68: 90030024 stw 00AA2F6C: 60028000 ori 00AA2F70: 64018000 00AA2F74: 7C23152C 00AA2F78: 38420100 00AA2F7C: 28028B00 00AA2F80: 7C0006AC eieio 00AA2F84: 4082FFF0 bne 00AA2F74: 7C23152C 00AA2F78: 38420100 00AA2F7C: 28028B00 00AA2F80: 7C0006AC eieio 00AA2F84: 4082FFF0 bne 00AA2F74: 7C23152C 00AA2F78: 38420100 00AA2F7C: 28028B00 00AA2F80: 7C0006AC eieio 00AA2F84: 4082FFF0 bne 00AA2F74: 7C23152C 00AA2F78: 38420100 00AA2F7C: 28028B00 00AA2F80: 7C0006AC eieio 00AA2F84: 4082FFF0 bne 00AA2F74: 7C23152C 00AA2F78: 38420100 00AA2F7C: 28028B00 00AA2F80: 7C0006AC eieio 00AA2F84: 4082FFF0 bne 00AA2F74: 7C23152C 00AA2F78: 38420100 00AA2F7C: 28028B00 00AA2F80: 7C0006AC eieio 00AA2F84: 4082FFF0 bne 00AA2F74: 7C23152C 00AA2F78: 38420100 00AA2F7C: 28028B00 00AA2F80: 7C0006AC eieio 00AA2F84: 4082FFF0 bne 00AA2F74: 7C23152C 00AA2F78: 38420100 00AA2F7C: 28028B00 00AA2F80: 7C0006AC eieio 00AA2F84: 4082FFF0 bne 00AA2F74: 7C23152C 00AA2F78: 38420100 00AA2F7C: 28028B00 00AA2F80: 7C0006AC eieio 00AA2F84: 4082FFF0 bne 00AA2F74: 7C23152C 00AA2F78: 38420100 00AA2F7C: 28028B00 00AA2F80: 7C0006AC eieio 00AA2F84: 4082FFF0 bne 00AA2F74: 7C23152C 00AA2F78: 38420100 00AA2F7C: 28028B00 00AA2F80: 7C0006AC eieio 00AA2F84: 4082FFF0 bne 00AA2F88: 38200100 li 00AA2F8C: 6421FFF0 00AA2F90: 7C3A03A6 00AA2F94: 38201040 li 00AA2F98: 7C3B03A6 00AA2F9C: 4C000064 rfi (TNT 0.6) log: ( 163.916s) hammerhead.cpp:84 INFO| Hammerhead: read ROM_TIMING @80.l = 0000008a hammerhead.cpp:147 INFO| Hammerhead: write ROM_TIMING @80.l = 0000008b mtlr r15 ; in{ r15:AA2F2C } out{ lr:AA2F2C } ; in{ lr:AA2F2C } 0x00AA2FA0 ; in{ lr:AA2F2C } crclr crb16 ; out{ cr:20000000 } r29, r26 ; in{ r26:FFC00000 } out{ r29:FFC00000 } r30, r29, r28 ; in{ r29:FFC00000 r28:200000 } out{ r30:FFE00000 } r2, 0x9C(r16) ; in{ r16:AA2DA4 } out{ r2:89898989 } r3, 0xAC(r16) ; in{ r16:AA2DA4 } out{ r3:BDBDBDBD } r4, 0xBC(r16) ; in{ r16:AA2DA4 } out{ r4:1010101 } r5, 0xCC(r16) ; in{ r16:AA2DA4 } out{ r5:2A2A2A2A } stfd f6, 0x0(r29) ; in{ f6:9090909090909090 r29:FFC00000 } stfd f7, 0x0(r30) ; in{ f7:909090909090909 r30:FFE00000 } f0, 0x0(r29) ; in{ r29:FFC00000 } out{ f0:960E4BE90000002A } f1, 0x0(r30) ; in{ r30:FFE00000 } out{ f1:4B757274C0A00000 } f2, 0x8(r29) ; in{ r29:FFC00000 } out{ f2:77D4EFA00684EFA } f3, 0x8(r30) ; in{ r30:FFE00000 } out{ f3:32BFC0000005C } stfd f4, 0x0(r29) ; in{ f4:0 r29:FFC00000 } stfd f5, 0x0(r30) ; in{ f5:0 r30:FFE00000 } stfd f0, 0xE4(r16) ; in{ f0:960E4BE90000002A r16:AA2DA4 } stfd f2, 0xEC(r16) ; in{ f2:77D4EFA00684EFA r16:AA2DA4 } r6, 0xE4(r16) ; in{ r16:AA2DA4 } out{ r6:960E4BE9 } r7, 0xE8(r16) ; in{ r16:AA2DA4 } out{ r7:2A } r8, 0xEC(r16) ; in{ r16:AA2DA4 } out{ r8:77D4EFA } r9, 0xF0(r16) ; in{ r16:AA2DA4 } out{ r9:684EFA } cmpw r6, r7 ; in{ r6:960E4BE9 r7:2A } out{ cr:80000000 } ; in{ cr:80000000 lr:AA2F30 } 0x00AA2F64 ; in{ cr:80000000 } all DMA channels, goto reset vector FFF00100 oris r3, r0, 0xF300 ; in{ r0:0 } out{ r3:F3000000 } r0, 0x24(r3) ; in{ r0:0 r3:F3000000 } r2, r0, 0x8000 ; in{ r0:0 } out{ r2:8000 } oris r1, r0, 0x8000 ; in{ r0:0 } out{ r1:80000000 } stwbrx r1, r3, r2 ; in{ r1:80000000 r3:F3000000 r2:8000 } addi r2, r2, 0x100 ; in{ r2:8000 } out{ r2:8100 } cmplwi cr0, r2, 0x8B00 ; in{ r2:8100 } out{ cr:80000000 } 0x00AA2F74 ; in{ cr:80000000 } stwbrx r1, r3, r2 ; in{ r1:80000000 r3:F3000000 r2:8100 } addi r2, r2, 0x100 ; in{ r2:8100 } out{ r2:8200 } cmplwi cr0, r2, 0x8B00 ; in{ r2:8200 } out{ cr:80000000 } 0x00AA2F74 ; in{ cr:80000000 } stwbrx r1, r3, r2 ; in{ r1:80000000 r3:F3000000 r2:8200 } addi r2, r2, 0x100 ; in{ r2:8200 } out{ r2:8300 } cmplwi cr0, r2, 0x8B00 ; in{ r2:8300 } out{ cr:80000000 } 0x00AA2F74 ; in{ cr:80000000 } stwbrx r1, r3, r2 ; in{ r1:80000000 r3:F3000000 r2:8300 } addi r2, r2, 0x100 ; in{ r2:8300 } out{ r2:8400 } cmplwi cr0, r2, 0x8B00 ; in{ r2:8400 } out{ cr:80000000 } 0x00AA2F74 ; in{ cr:80000000 } stwbrx r1, r3, r2 ; in{ r1:80000000 r3:F3000000 r2:8400 } addi r2, r2, 0x100 ; in{ r2:8400 } out{ r2:8500 } cmplwi cr0, r2, 0x8B00 ; in{ r2:8500 } out{ cr:80000000 } 0x00AA2F74 ; in{ cr:80000000 } stwbrx r1, r3, r2 ; in{ r1:80000000 r3:F3000000 r2:8500 } addi r2, r2, 0x100 ; in{ r2:8500 } out{ r2:8600 } cmplwi cr0, r2, 0x8B00 ; in{ r2:8600 } out{ cr:80000000 } 0x00AA2F74 ; in{ cr:80000000 } stwbrx r1, r3, r2 ; in{ r1:80000000 r3:F3000000 r2:8600 } addi r2, r2, 0x100 ; in{ r2:8600 } out{ r2:8700 } cmplwi cr0, r2, 0x8B00 ; in{ r2:8700 } out{ cr:80000000 } 0x00AA2F74 ; in{ cr:80000000 } stwbrx r1, r3, r2 ; in{ r1:80000000 r3:F3000000 r2:8700 } addi r2, r2, 0x100 ; in{ r2:8700 } out{ r2:8800 } cmplwi cr0, r2, 0x8B00 ; in{ r2:8800 } out{ cr:80000000 } 0x00AA2F74 ; in{ cr:80000000 } stwbrx r1, r3, r2 ; in{ r1:80000000 r3:F3000000 r2:8800 } addi r2, r2, 0x100 ; in{ r2:8800 } out{ r2:8900 } cmplwi cr0, r2, 0x8B00 ; in{ r2:8900 } out{ cr:80000000 } 0x00AA2F74 ; in{ cr:80000000 } stwbrx r1, r3, r2 ; in{ r1:80000000 r3:F3000000 r2:8900 }( 182.348s) grandcentral.cpp:497 WARN| GrandCentralTnt: Unsupported DMA channel DMA_AUDIO_IN write @00.l = 00000080 addi r2, r2, 0x100 ; in{ r2:8900 } out{ r2:8A00 } cmplwi cr0, r2, 0x8B00 ; in{ r2:8A00 } out{ cr:80000000 } 0x00AA2F74 ; in{ cr:80000000 } stwbrx r1, r3, r2 ; in{ r1:80000000 r3:F3000000 r2:8A00 } addi r2, r2, 0x100 ; in{ r2:8A00 } out{ r2:8B00 } cmplwi cr0, r2, 0x8B00 ; in{ r2:8B00 } out{ cr:20000000 } 0x00AA2F74 ; in{ cr:20000000 } r1, 0x100 ; out{ r1:100 } oris r1, r1, 0xFFF0 ; in{ r1:100 } out{ r1:FFF00100 } mtsrr0 r1 ; in{ r1:FFF00100 } out{ srr0:FFF00100 } r1, 0x1040 ; out{ r1:1040 } mtsrr1 r1 ; in{ r1:1040 } out{ srr1:1040 } ; in{ msr:3072 srr0:FFF00100 srr1:1040 } out{ msr:1040 }]

>> Jockelill said:

Isn't this the same type of flashable DIMM found for the early PPCs? Click to expand...

I really don't know much about OF Mac's. Have a link to that flashable dimm?

>> eric said:

I really don't know much about OF Mac's. Have a linxk to that flashable dimm? Click to expand...

Sure, it was on the other forum :)

Power Macintosh PPC ROM DIMMs

Incomplete List of ROM modules: type-number voltage computer model chips special features reprogrammable 820-0961-A 3.3V ? 4x AM29LV800 unpopulated sop & plcc yes? 820-0954-01 3.3V PM G3 2x KM2316205Y 2x 70 pin chips no 341-0758 5V PM 9500 8x HM27C4000FP-12 no, OTP? 341-0757 5V PM...

[Image: 68kmla.org] 68kmla.org

Been looking a little bit in my head to create a flashable dimm for the PPC, but it haven't materialized yet. I think the best way would do something with a RP2350B and the UF2-format, chips needs to be 2x 32bit or 4x 16bit for the 64 data path.

The quickest path I see to testing something in an ANS is to whip up a ROM DIMM board with eight PLCC sockets. You could use something like SST39SF040 chips programmed in an external flash programmer. That should cover the full 64-bit data bus and give you 4 total megabytes of ROM space to work with. I'm assuming the pinout should be the same as the other era PPC Macs so the leaked 7200 and 9600 schematics would give you pinout info. Looks like it's similar to the later 68k ROM SIMMs in that there's a pin (116) that can be pulled high to signal to the logic board that a ROM DIMM is installed and disable its onboard ROM chips.

Edit: try to verify pinouts, of course, since we don't have schematics of the ANS.

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.

>> joevt said:

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. Click to expand...

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