Apple Network Server MacOS based ROMs found

[ClassicHasClass]

OK, I've finally posted my detailed work log on the 1.1.20.1 and 2.26NT ROMs with a lot of commentary.

Hands-on with two Apple Network Server prototype ROMs

Grateful acknowledgement made to the several former Apple employees who materially contributed to this entry. This article wouldn't have bee...

oldvcr.blogspot.com

 

[joevt]

OK, I've finally posted my detailed work log on the 1.1.20.1 and 2.26NT ROMs with a lot of commentary.

The nvramrc script and nvram variables that get modified by classic Mac OS are stored in OFpt resources in the Startup Disk control panel.

'OFpt' (128, "PowerSurge")
'OFpt' (129, "PowerExpress")
'OFpt' (130, "Gossamer")
'OFpt' (131, "PowerMac G3")
'OFpt' (132, "Wallstreet")
'OFpt' (133, "Mainstreet")
'OFpt' (134, "Hooper")
'OFpt' (135, "Kanga")
'OFpt' (136, "Alchemy")

A similar set of resources exist in XPostFacto.

It looks like the control panel is choosing the PowerSurge script. That script is meant for Open Firmware 1.0.5. It is not suitable for the ANS versions of Open Firmware.

For example, the line 6ED '& execute executes fcode 0x6ED.
6ED is different for each version of Open Firmware:

• 1.0.5: 6ED = restore-ttp800 (but the name for this fcode and most others is not stored in OF 1.0.5)
• 1.1.20.1, 1.1.22: 6ED = key=locked?; 6E8 = restore-ttp800
• 2.0: 6ED = do-map; 6DA = restore-ttp800
• 2.26B6, 2.26NT: 6ED = status; 6F7 = restore-ttp800

The choice is made using the OFtc resource which maps a model identifier (such as AAPL,9500) to a OFpt resource ID. It should have been choosing by Open Firmware version or by the 64-bit checksum of the ROM (which covers the entire 4 MiB instead of just the first 3 MiB - Open Firmware is in the last 1 MiB).

Creating an nvramrc script for each ANS ROM requires the following:

1. Decipher what is being patched for PowerSurge.
2. Do the same for all the other OFpt resources in case they have relevant changes that don't exist for PowerSurge.
3. Translate all the relevant patches for your version of Open Firmware.

This is optional since you have seen that the ANS is bootable without any patches.

I've documented most of the PowerSurge patches used by my version of XPostFacto.

Regarding the CLAIM failed error, I suppose a patch can be created to see what is attempting the CLAIM (by dumping the return stack) and what it is trying to CLAIM (a physical or virtual memory range)... I want to add this patch to my Open Firmware Extender to see why Open Firmware 2.4 won't boot Mac OS X 10.2 if auto-boot? is false. The Open Firmware Extender is mentioned at #5,071 . I want to port it to different versions of Open Firmware. Maybe it can inject the ndrv for ANS graphics and for the ANS SCSI controllers for versions of the ANS ROM that don't include those.

 

[cc333]

The ANS has suddenly become much more interesting and useful!

That said, with all that is being learned here, might it someday be possible to create a single hybrid ROM that can boot the factory AIX, Mac OS/Mac OS X (with necessary patches so internal SCSI and video work) and Windows NT? I think that would be an excellent accomplishment, and if I read this thread correctly, you all are already well on your way to doing just that.

I don't know why I would ever need to have an ANS, but, if by some chance, I ever come across one, I now know that I can actually use it for normal Mac-related things if I want to!

c

 

[ClassicHasClass]

It would be nice (I don't know if you, @joevt , have developed such tools already) to have some way to do debugging in Open Firmware. Rairii/Wack0 asked about getting a register dump to analyse that veneer exception and understand why it won't run it, but I'm not aware of an easy way to do that.

 

[joevt]

It would be nice (I don't know if you, @joevt , have developed such tools already) to have some way to do debugging in Open Firmware. Rairii/Wack0 asked about getting a register dump to analyse that veneer exception and understand why it won't run it, but I'm not aware of an easy way to do that.

I have a Trace for Open Firmware script that can show what's getting executed. It needs more work but can do some simple stuff.

It works by patching every word or words that you explicitly ask to patch. Then when you enable tracing, it will output each word as it enters and exits, and displays the stack at each point.

The script won't patch words that are not safe to patch but I need to expand the list of unsafe words because if you try to patch all words it will hang for some words. Maybe the words that hang need a different kind of patch.

Some words disable tracing temporarily for itself or for words called by itself. This behaviour can be set per word.

Some words are really simple and only patch entry or exit (not both).

It has dump-return-stack for dumping the return stack.

It has list-tokens to list the tokens for a compiled word. This helps creating patches.

I would patch ?claim-abort to use dump-return-stack.

The Copland Open Firmware has a disassembler and a debugger that allows setting breakpoints. I included them in my Open Firmware 2.4 Extender. I haven't tried the breakpoints functionality so I don't know how useful it is.

 

[ClassicHasClass]

That would be good for studying words, and I may well use that soon, but we wanted to get a little more information on the PowerPC exception that got thrown. Can the DEFAULT CATCH! routine be patched to do a full PowerPC register dump?

 

[joevt]

That would be good for studying words, and I may well use that soon, but we wanted to get a little more information on the PowerPC exception that got thrown. Can the DEFAULT CATCH! routine be patched to do a full PowerPC register dump?

@startvec.>'excp stores the default exception handler which is _exception
This does a throw of the exception vector number. Maybe it can be replaced by something that saves more info (copy all the registers and the stacks?).
@startvec.>'syscatch stores the default catch handler which is _syscatch
This is stored on the bottom of the return stack to catch anything that is not caught be a more recent catch higher up the return stack. You want a syscatch that outputs the info saved by the modified exception handler.

Changing @startvec.>'syscatch is probably not sufficient. The items at the bottom of the return stack that point to _syscatch would also need to be replaced. As an alternative, _syscatch itself can be patched instead of changing @startvec.>'syscatch