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.