Apple Network Server MacOS based ROMs found

[ClassicHasClass]

What version of Mac OS are you using?
What version of the Startup Disk control panel?
Post output from DumpNameRegistry. It should show if the ANS comes up as a AAPL,9500 or as a AAPL,ShinerESB. The latter should be the case when Open Firmware detects the internal SCSI (vendor/device ID 1000:0003).
The PowerSurge script fixes a few bugs in Open Firmware 1.0.5. It probably shouldn't be used for the ANS versions of Open Firmware as I've explained in a previous post. I've attached a version which explains some of the patches. It includes some of my own patches for XPostFacto.

I agree it shouldn't be used and it does not seem necessary. This is OS 9.1.

There is nothing in the CDEV's table that matches AAPL,ShinerESB, so that wouldn't match the behaviour nor the Gestalt ID.

Meanwhile, there is a difference in MACE Ethernet between the two ROMs: onboard works with 2.0 and also 1.1.22 but not 1.1.20. The device exists on all three. I cannot find an ndrv or nlib that corresponds to it in 2.0.

What's the issue with ttya? It is a devalias that should exist in Open Firmware and points to the modem port.
The devalias for ttya is /bandit/gc/escc/ch-a
printenv shows that the default input-device and output-device is kbd and screen so something must change them to ttya.
input-device and output-device only affect Open Firmware so it shouldn't be a problem for Mac OS 9.
The default for PowerSurge machines is ttya. The default is set when the PRAM is zapped.

Yes, it's pesent, but it's handled differently. In ANS Open Firmware, a 'ttya' setting is taken literally, so the machine will come up with a black screen. While the system will start, no graphics output will appear on any video card or internal video, including the Open Firmware prompt. The ideal situation is that MacOS not try to change input-device and output-device. It doesn't seem that Startup Disk is doing this, however, because it has no string in either fork for 'ttya' - unless it's doing this some other way.

 

[ClassicHasClass]

My socketed connectors arrived, waiting on the other rom board to make it. The sockets feel good, once this is done, if anyone needs anything tested, i gotcha. (if it is preferable, and if it works good, i can ship it out to whomst ever would make best use of it.)

Tried 1.1.20.1, booted into OF on internal display, setenv bootcommand bye would let me boot, i could hear it booting into mac os, but got no display out of either internal or my rage 128...

It also would crash with my 256k cache card (i do not have another )(but also it being 256k is probably the issue, but i cannot find a larger one)

So i desoldered the 1.1.20.1 chips, flashed the 2.0 and it boots again. very strange...because 2.0 can display from the 128 completely fine...

Also, if someone needs a production rom, i will happily get rid of mine, i really have no intention on ever installing aix again.

Just remove the 256K cache card. The ROM is not expecting it and it almost certainly won't work properly. That was never a supported configuration.

You could try hard setting output-device to the Open Firmware path for the Rage 128. The path will vary based on where you installed it. Try looking for it with dev / and ls. For example, on my machine with a Twin Turbo in slot 1, the path is /bandit@F2000000/IMS,tt128mbA@D.

I have a Rage Orion somewhere (a Mac-specific Rage 128) I can try to dig out to reproduce what you're seeing, but I don't have it handy. Does your Rage 128 card work in another Mac?

 

[mizerable]

Just remove the 256K cache card. The ROM is not expecting it and it almost certainly won't work properly. That was never a supported configuration.

You could try hard setting output-device to the Open Firmware path for the Rage 128. The path will vary based on where you installed it. Try looking for it with dev / and ls. For example, on my machine with a Twin Turbo in slot 1, the path is /bandit@F2000000/IMS,tt128mbA@D.

I have a Rage Orion somewhere (a Mac-specific Rage 128) I can try to dig out to reproduce what you're seeing, but I don't have it handy. Does your Rage 128 card work in another Mac?

Yeah, was just reporting it didnt like it on the 1.1.20.1 rom, it currently isnt in the system. wish i had a 512k, theyre impossible to find for some reason.

Strange, though, the 2.26NT rom reads it fine, dunno if it actually uses it, but at least doesnt crash.
2.0 obvi doesnt see it, so no crash.

Ill have to try that setting when i get the other rom board, hopefully tomorrow, as i wanted my ans up n running again.

I have not tried the gpu in another mac, although it does work. im currently using it just fine on the 2.0 rom, just didnt output in the 1.1.20.1 rom. (also have not tested in my 2.26NT rom)

also also, i offered up my production rom, but forgot its actually a 2.26NT lol

 

[joevt]

There is nothing in the CDEV's table that matches AAPL,ShinerESB, so that wouldn't match the behaviour nor the Gestalt ID.

Are you using different ROMs in the same ANS? Which ROMs are you trying? You should probably zap PRAM when changing the ROM.

ANS 2.0 identifies itself as AAPL,9500. Maybe you used this which causes the PowerSurge nvramrc script to be used?
All other ANS ROMs identify themselves as AAPL,ShinerESB. Since there's no OFpt for this model, the nvramrc does not get changed?

Open Firmware, 2.0
To continue booting the MacOS type:
BYE<return>
To continue booting from the default boot device type:
BOOT<return>
For Open Firmware serial I/O type:
TTYA IO<return>
 ok
0 > dump-device-tree 
/
PROPERTIES:
name                    device-tree
model                   Power Macintosh
compatible              AAPL,9500
                        MacRISC
AAPL,cpu-id             3900A69D 
#address-cells          00000001 
#size-cells             00000001 
clock-frequency         02FAF080 

METHODS:
make-cpu-properties             make-motherboard-l2-prop        dma-sync        dma-map-out     
dma-map-in      dma-free        dma-alloc       map-out         map-in          decode-unit     
close           open            ?pdm            

/cpus@0
PROPERTIES:
name                    cpus
device_type             cpus
                        
More [<space>,<cr>,q] ?  ok

Meanwhile, there is a difference in MACE Ethernet between the two ROMs: onboard works with 2.0 and also 1.1.22 but not 1.1.20. The device exists on all three. I cannot find an ndrv or nlib that corresponds to it in 2.0.

Run DumpNameRegistry for each ROM so we can compare. It will show some hex from the driver. Then you can grep your System folder for that hex.

Yes, it's pesent, but it's handled differently. In ANS Open Firmware, a 'ttya' setting is taken literally, so the machine will come up with a black screen. While the system will start, no graphics output will appear on any video card or internal video, including the Open Firmware prompt. The ideal situation is that MacOS not try to change input-device and output-device. It doesn't seem that Startup Disk is doing this, however, because it has no string in either fork for 'ttya' - unless it's doing this some other way.

That seems like a bug in the ndrv for the ANS graphics. An ndrv should not require the graphics controller to be opened in Open Firmware.
Using ttya, you could try loading the ndrv into Open Firmware (download it over serial port), then see if booting behaves better than your system extension method.


Question about 1.1.20.1: Is it doing something weird (doubling the characters?) on the LCD for these messages?

BBeeggiinn  DDRRAAMM  TTeesstt  ##11    

BBeeggiinn  RROOMM  SSIIMMMM  TTEESSTT  

BBeeggiinn  NNVVRRAAMM  TTeesstt        

BBeeggiinn  DDRRAAMM  TTeesstt  ##22    
BBeeggiinn  LLOONNGG  DDRRAAMM  TTeesstt

------------------------------------

RRAAMM//RROOMM//NNVVRRAAMM::PPAASSSSEEDD

This is from my DingusPPC emulation. The other four ANS ROM versions don't do this character doubling behaviour.

 

[mizerable]

Question about 1.1.20.1: Is it doing something weird (doubling the characters?) on the LCD for these messages?

BBeeggiinn  DDRRAAMM  TTeesstt  ##11   

BBeeggiinn  RROOMM  SSIIMMMM  TTEESSTT 

BBeeggiinn  NNVVRRAAMM  TTeesstt       

BBeeggiinn  DDRRAAMM  TTeesstt  ##22   
BBeeggiinn  LLOONNGG  DDRRAAMM  TTeesstt

------------------------------------

RRAAMM//RROOMM//NNVVRRAAMM::PPAASSSSEEDD

This is from my DingusPPC emulation. The other four ANS ROM versions don't do this character doubling behaviour.

When i tried the 1.1.20.1 on my ANS, no, the display worked exactly as expected.

 

[ClassicHasClass]

Are you using different ROMs in the same ANS? Which ROMs are you trying? You should probably zap PRAM when changing the ROM.

1.1.20.1. And yes, this is not my first rodeo, thanks. I don't even have the PRAM battery installed for all this and regularly reset the board between tests.

ANS 2.0 identifies itself as AAPL,9500. Maybe you used this which causes the PowerSurge nvramrc script to be used?
All other ANS ROMs identify themselves as AAPL,ShinerESB. Since there's no OFpt for this model, the nvramrc does not get changed?

That's my point exactly: it uses the PowerSurge script anyway, even on 1.1.20.1. That's why I don't think it's matching on that table.

Run DumpNameRegistry for each ROM so we can compare. It will show some hex from the driver. Then you can grep your System folder for that hex.

I'm not following you here. On the same install of 9.1, 1.1.20.1 doesn't enable the MACE Ethernet and 2.0 does. The difference has to be in the ROM, not the System Folder, unless there is something you're trying to look for (and if you are, please be specific).

That seems like a bug in the ndrv for the ANS graphics. An ndrv should not require the graphics controller to be opened in Open Firmware.

Politely, I disagree. I think the ANS ROMs handle this better than PowerSurge 1.0.5 ROMs. If *-device is set to the serial port, I expect it to talk to me over the serial port. There should not be a phantom console somewhere else. That's how you can run an ANS entirely over serial, which is a supported and even useful configuration for AIX.

In any event, regardless of why, that's what it does on real hardware. I don't want the *-device paths messed with; they should stay what they were set to, which on a freshly-reset ANS board is kbd and screen for internal ADB and VGA. I cannot see anywhere in the nvramrc scripts in Startup Disk where this is being set, and I can't even find the string ttya in the data fork or resource fork, so I can only conclude something else is doing it.

Question about 1.1.20.1: Is it doing something weird (doubling the characters?) on the LCD for these messages?

BBeeggiinn  DDRRAAMM  TTeesstt  ##11   

BBeeggiinn  RROOMM  SSIIMMMM  TTEESSTT 

BBeeggiinn  NNVVRRAAMM  TTeesstt       

BBeeggiinn  DDRRAAMM  TTeesstt  ##22   
BBeeggiinn  LLOONNGG  DDRRAAMM  TTeesstt

------------------------------------

RRAAMM//RROOMM//NNVVRRAAMM::PPAASSSSEEDD

This is from my DingusPPC emulation. The other four ANS ROM versions don't do this character doubling behaviour.

No, it does not do that on my real 700. The LCD display is normal. Good news to hear progress on the emulator, though.

 

[joevt]

When i tried the 1.1.20.1 on my ANS, no, the display worked exactly as expected.

To be clear, all the other messages appear normally. It's just these messages that the ANS ROM is doing strangely (outputting the same character more than once).

Do these messages appear at all?

Begin  DRAM  Test  #1   

Begin  ROM  SIMM  TEST 

Begin  NVRAM  Test       

Begin  DRAM  Test  #2   
Begin  LONG  DRAM  Test

------------------

RAM/ROM/NVRAM:PASSED

That's my point exactly: it uses the PowerSurge script anyway, even on 1.1.20.1. That's why I don't think it's matching on that table.

Is dump-device-tree in Open Firmware and DumpNameRegistry in Mac OS 9.1 showing the model as AAPL,ShinerESB?
What's the gestalt ID for the ANS with the 1.1.20.1 ROM?

I'm not following you here. On the same install of 9.1, 1.1.20.1 doesn't enable the MACE Ethernet and 2.0 does. The difference has to be in the ROM, not the System Folder, unless there is something you're trying to look for (and if you are, please be specific).

The different ROMs may cause different things to happen to the Name Registry. We want to dump the Name Registry to see how it differs for each ANS ROM. The contents of the Name Registry will show what driver is loaded for each device. We can then search for the driver in the ROM or in the System Folder.

Politely, I disagree. I think the ANS ROMs handle this better than PowerSurge 1.0.5 ROMs. If *-device is set to the serial port, I expect it to talk to me over the serial port. There should not be a phantom console somewhere else. That's how you can run an ANS entirely over serial, which is a supported and even useful configuration for AIX.

input-device and output-device are nvram variables defined in Open Firmware for Open Firmware. Mac OS 9 ignores them. BootX might use them to select a default display for booting Mac OS X. I guess AIX might use them to decide what to use for a console?

For Mac OS 9, there isn't a console. An ndrv should turn on the display if it wasn't already enabled by Open Firmware. Open Firmware does not usually enable a display, especially for Old World Macs. New World Macs may enable the display in Open Firmware, especially for multi-boot or FireWire target disk mode.

In any event, regardless of why, that's what it does on real hardware. I don't want the *-device paths messed with; they should stay what they were set to, which on a freshly-reset ANS board is kbd and screen for internal ADB and VGA. I cannot see anywhere in the nvramrc scripts in Startup Disk where this is being set, and I can't even find the string ttya in the data fork or resource fork, so I can only conclude something else is doing it.

Have you tried narrowing down when the nvram gets modified?
Use setenv in Open Firmware to set the nvram variables. printenv to verify your changes. Boot into Mac OS 9.1. Shutdown. Use printenv to see if your nvram settings got changed.

Good news to hear progress on the emulator, though.

I'll see if I can get ANS on DingusPPC to boot Mac OS. Then see when the NVRAM gets modified.
I haven't tried booting AIX or Mac OS yet because I've been working on other stuff and I wanted to get more of the SCSI and graphics emulation done.

 

[joevt]

Do these messages appear at all?

Ok the reason for the doubled character printing of those LCD messages is that it is outputting the message to both the LCD and the Serial port. DingusPPC displays them together in stdout. DingusPPC doesn't have a separate output for the LCD but you can specify a separate output for the serial port.

 

[joevt]

I can't get the emulation to boot. Do I need any special setup for ANS ROM 1.1.20.1 besides attaching the HD to external SCSI?
Maybe a dump-device-tree from a real ANS 1.1.20.1 would help.
What's the output of these commands before booting Mac OS 9.1?

F301A000 @ 8 u.r
F301E000 @ 8 u.r
dump-device-tree
printenv

 

[ClassicHasClass]

To be clear, all the other messages appear normally. It's just these messages that the ANS ROM is doing strangely (outputting the same character more than once).

Do these messages appear at all?

Begin  DRAM  Test  #1  

Begin  ROM  SIMM  TEST

Begin  NVRAM  Test      

Begin  DRAM  Test  #2  
Begin  LONG  DRAM  Test

------------------

RAM/ROM/NVRAM:PASSED

I see you answered your own question later on, but these messages only ever appear briefly on the LCD. On the serial port they will be emitted as well (9600bps).

Is dump-device-tree in Open Firmware and DumpNameRegistry in Mac OS 9.1 showing the model as AAPL,ShinerESB?
What's the gestalt ID for the ANS with the 1.1.20.1 ROM?

The Gestalt ID is 67, same as the 9500/9600. I won't be able to access the console for a few days, but I'll dump when I get back. Note that of 1.1.20.1, 1.1.22 and 2.0, only 2.0 lacks this string: the others have it.

The different ROMs may cause different things to happen to the Name Registry. We want to dump the Name Registry to see how it differs for each ANS ROM. The contents of the Name Registry will show what driver is loaded for each device. We can then search for the driver in the ROM or in the System Folder.

I appreciate the explanation of what you're looking for. I'll confirm this then as well.

I guess AIX might use them to decide what to use for a console?

Yes, that's exactly the idea. As part of the install process (or booting from CD), AIX will ask where the console is. If the Open Firmware devices point to the serial port, then AIX will send this prompt out over the serial port. All AIX systems work this way, including my larger POWER6. It also appears that Cyberpunk was intended to boot (or at least support booting) that way.

I note that console handling is different for the 2.0 ROMs and more like regular OF 1.0.5, but those ROMs don't boot AIX and I'm working with the 1.1.20.1 ROM here.

Have you tried narrowing down when the nvram gets modified?
Use setenv in Open Firmware to set the nvram variables. printenv to verify your changes. Boot into Mac OS 9.1. Shutdown. Use printenv to see if your nvram settings got changed.

From a cleanly reset board, Boot Variables shows them already changed by the time the Finder is up. More than that would require debugging. I might check with extensions off just for yuks.