Apple Network Server MacOS based ROMs found

[joevt]

I'm going through the code in the extension and I see the string but not where it is checked. What offset in the code fragment did you see that at?

I used Jasik's MacNosy to disassemble the "mace" container from the Apple Enet 2.4.5 extension.
I made a script to dump the string tables from the .asm file.
The property name PLSCCPort is at offset $7C1 in the string list global glob72 in AppleEnet.asm (the .list file disagrees on global numbers - a bug in MacNosy probably).
This string is accessed in proc12.

In the DumpPEF output, the access is at offset 0158C in the first container of the file (the first container "mace" is at offset 0 in the file).
The access is at offset 0150C of the code section in that container (find it in the .dumppef output and the .list output).

 

[ClassicHasClass]

Hey, thank you, that's very helpful.

 

[ClassicHasClass]

Status update on the 1.1.20.1 extension pack. Besides the already working ndrv for the video (the SCSI controller will be extracted the same way), I now have a working hack of Boot Variables that fixes the console between reboots. This goes in Startup Items and undoes whatever is messing with the input and output devices, and doesn't require me patching the system otherwise.

I also tried changing the nvramrc in the Boot Variables hack to add the necessary property to the MACE Ethernet. I can successfully commit the nvramrc, but it doesn't work, even though I can tell the nvramrc has executed due to debugging messages I put in it.

My second attempt was to use the Name Registry to patch it from inside the Boot Variables hack. I can find it in the device tree and set the property, but the Name Registry is too old and will not let me save a property name of that length to NVRAM. So now I'm working on either an ndrv or an INIT that will run before Apple Enet and set that property, since it does seem to work at runtime. In fact, this approach may be cleaner anyway.

Anyway, getting closer to a universal boot-anything solution. It's hacky but it will run any available OS for Shiner.

 

[eric]

This might have been asked already but I have a 1.1.20.1 ROM. To install MacOS do I just boot off a retail cd and install? Any other things to be aware of? I've been out of the loop for a while (summer+kids==busy!) - Want to try to install for VCFMW coming up (way too fast)

 

[mizerable]

Status update on the 1.1.20.1 extension pack. Besides the already working ndrv for the video (the SCSI controller will be extracted the same way), I now have a working hack of Boot Variables that fixes the console between reboots. This goes in Startup Items and undoes whatever is messing with the input and output devices, and doesn't require me patching the system otherwise.

I also tried changing the nvramrc in the Boot Variables hack to add the necessary property to the MACE Ethernet. I can successfully commit the nvramrc, but it doesn't work, even though I can tell the nvramrc has executed due to debugging messages I put in it.

My second attempt was to use the Name Registry to patch it from inside the Boot Variables hack. I can find it in the device tree and set the property, but the Name Registry is too old and will not let me save a property name of that length to NVRAM. So now I'm working on either an ndrv or an INIT that will run before Apple Enet and set that property, since it does seem to work at runtime. In fact, this approach may be cleaner anyway.

Anyway, getting closer to a universal boot-anything solution. It's hacky but it will run any available OS for Shiner.

Exciting! I have an extra ROM & simm waiting to be programmed!

 

[ClassicHasClass]

This might have been asked already but I have a 1.1.20.1 ROM. To install MacOS do I just boot off a retail cd and install? Any other things to be aware of? I've been out of the loop for a while (summer+kids==busy!) - Want to try to install for VCFMW coming up (way too fast)

Unfortunately, not quite that simple. The problem with the 1.1.20.1 ROM is that it does not support the internal SCSI nor the internal video for MacOS (they work in AIX), and it does not properly enable the onboard MACE Ethernet. Also, Mac OS will treat it as a generic PowerSurge system and whack the nvramrc as well as the Open Firmware input and output devices after it starts up, meaning the ANS will boot once, and then go to a black screen on the next boot after that. Everything else will work, even ADB, but you'll get no video at all - even from a discrete video card - until you change the devices from the serial port, or zap PRAM. After that, once again you'll get one boot and the same thing will happen.

Without the extension pack I'm working on, you'll need the following:
- Something for the external SCSI port to boot from and store to. I use a 25-pin external BlueSCSI. Works fine on termination power. It has both the 9.1 CD image and the 9.1 hard disk image. You can use the front floppy, but none of the internal drive trays will otherwise work for Mac OS (they will still work for AIX).
- A PCI video card. Any Mac compatible one will work. I use a Twin Turbo, but an ATI card should be fine, like a Rage or Rage 128 or early Radeon.
- A copy of Boot Variables ( ftp://ftp.netbsd.org/pub/NetBSD/arch/macppc/macos-utils/bootvars/ ) or some other way of setting Open Firmware variables from inside Mac OS.
- (optional) A PCI Ethernet card. I use a real ANS 10Mbit card, but if you don't care about it working in AIX, then any Mac compatible card will do.

I would use at least Mac OS 8. 7.6 will boot, but does not support the ANS 10Mbit card, whereas I know 9.1 does at least, and I'm pretty sure 8.6 and 8.1 do too.

Install the ROM stick, ensure PRAM is clean (e.g., have the PRAM battery out, etc.) and connect to the onboard VGA first. Assuming no AIX drives are found, it will drop to Open Firmware on screen. Move your monitor to the video card and blindly type "bye" on the ADB keyboard. After a pause you should see a Happy Mac as it boots from your CD image or external CD. Install Mac OS as usual.

After Mac OS boots, run Boot Variables immediately and make sure input-device is kbd (not ttya), output-device is screen, and use-nvramrc? is not checked, and Write them to NVRAM. You may want to save these settings as a file to reduce some keyboard work. You need to do this every time Mac OS runs, or you will get a black screen the next time.

The extensions pack plan is to enable internal video (which can mirror or be a screen of its own if you use a PCI video card too), internal SCSI (but not for booting, sorry), internal Ethernet and also fix the black screen problem between reboots by doing those patches for you.

More about Mac OS on 1.1.20.1: https://oldvcr.blogspot.com/2026/01/hands-on-with-two-apple-network-server.html

 

[joevt]

Status update on the 1.1.20.1 extension pack. Besides the already working ndrv for the video (the SCSI controller will be extracted the same way), I now have a working hack of Boot Variables that fixes the console between reboots. This goes in Startup Items and undoes whatever is messing with the input and output devices, and doesn't require me patching the system otherwise.

You're talking about fixing the Open Firmware console?
Does it matter if it's screen/keyboard or serial port?
Some might prefer serial if they have another computer and a serial port connection.
Default for PowerSurge machines is modem port.
Usually it doesn't matter because boot usually skips entering the Open Firmware console.

I also tried changing the nvramrc in the Boot Variables hack to add the necessary property to the MACE Ethernet. I can successfully commit the nvramrc, but it doesn't work, even though I can tell the nvramrc has executed due to debugging messages I put in it.

How can nvramrc not work, unless it is getting overwritten?

This should be sufficient:

dev enet
1 encode-int " PLSCCPort" property
device-end

My second attempt was to use the Name Registry to patch it from inside the Boot Variables hack. I can find it in the device tree and set the property, but the Name Registry is too old and will not let me save a property name of that length to NVRAM.

Right. The limit for NVRAM non-volatile name registry properties on Old World Macs is 4 characters for the property name and 8 bytes for the property value. Also, for Old World Macs, the device path is limited to PCI devices behind up to 6 PCI bridges. mace is not a PCI device.

So now I'm working on either an ndrv or an INIT that will run before Apple Enet and set that property, since it does seem to work at runtime. In fact, this approach may be cleaner anyway.

It might work at runtime if there was a way to close and reopen the driver? But an INIT would definitely be cleaner.

Have you found the software that writes the incorrect PowerSurge nvramrc script? Or is your INIT going to override that by executing after that?

 

[ClassicHasClass]

You're talking about fixing the Open Firmware console?
Does it matter if it's screen/keyboard or serial port?
Some might prefer serial if they have another computer and a serial port connection.
Default for PowerSurge machines is modem port.
Usually it doesn't matter because boot usually skips entering the Open Firmware console.

A reminder that ANS Open Firmware seems to take the input device and output device literally. If they are set to the serial port, video is never initialized. If they really want this, the solution is just not to run the NVRAM fixer. This is in Startup Items - it's a regular application, so it runs after all the INITs and CDEVs but prior to entering the Finder.

How can nvramrc not work, unless it is getting overwritten?

This should be sufficient:

dev enet
1 encode-int " PLSCCPort" property
device-end

That is almost exactly what I have (except I have dev /bandit/gc/mace) and while I can dump the .properties in the nvramrc, which appears on-screen to demonstrate the nvramrc is being executed, the property is never set. I don't know what's different about doing it from the nvramrc when it works doing it manually, but since I'm going to solve this with the Name Registry INIT, I guess it doesn't matter.

Have you found the software that writes the incorrect PowerSurge nvramrc script? Or is your INIT going to override that by executing after that?

No, and it's not just the nvramrc, it's also the input and output devices. But running it from Startup Items will get around the problem. I've got that much working and it reboots reliably now.

 

[joevt]

A reminder that ANS Open Firmware seems to take the input device and output device literally. If they are set to the serial port, video is never initialized. If they really want this, the solution is just not to run the NVRAM fixer. This is in Startup Items - it's a regular application, so it runs after all the INITs and CDEVs but prior to entering the Finder.

I suppose I can understand that the ndrv might not be sufficient to opening the graphics device if it wasn't opened in Open Firmware beforehand. That just means the ndrv was poorly written.

That is almost exactly what I have (except I have dev /bandit/gc/mace) and while I can dump the .properties in the nvramrc, which appears on-screen to demonstrate the nvramrc is being executed, the property is never set. I don't know what's different about doing it from the nvramrc when it works doing it manually, but since I'm going to solve this with the Name Registry INIT, I guess it doesn't matter.

Looking at the code for property, it uses my-self if it is not zero. Otherwise, it uses active-package.

tokenizer[ 110 next-fcode ]tokenizer

: property							
	my-self							
	?dup							
	if								
		>in.device-node				
		@							
	else							
		active-package				
	then							
	dup								
	if								
		(property)					
	else							
		no-active					
	then							
	;

During execution of nvramrc, my-self is set to the device-tree node at /.
We don't want to open the enet device (using select-dev) to change my-self. Instead we can just set my-self to 0.
dev enet sets active-package to /bandit/gc/mace

install-console
dev / ls
dev enet
." my-self:" my-self 8 u.r ."  -> " my-self ihandle>phandle dup 8 u.r cr to active-package .properties
0 to my-self
dev enet
1 encode-int " PLSCCPort" property
.properties
device-end
cr ." [ probe-all" cr
probe-all
cr ." ] probe-all" cr
dev / ls
banner