Do not mark indigo2_4415 as not working

[hbent]

indigo2_4415 is currently marked as MACHINE_NOT_WORKING. With the latest sources from git I was able to do a full install of IRIX 5.3 (everything on the base CD) and log in to root's desktop, so I think this can be marked as some sort of functional; perhaps this to match the Indy configs? I can provide a screenshot if necessary.

MACHINE_IMPERFECT_GRAPHICS | MACHINE_IMPERFECT_SOUND | MACHINE_NODEVICE_LAN | MACHINE_NODEVICE_MICROPHONE

Interestingly, attempting to install both 5.3 and 6.2 on an Indy does not work at the moment, but I'll file a separate bug for that.

[rb6502]

@MooglyGuy can you comment on why Indigo2 is NOT_WORKING vs. Indy?

[MooglyGuy]

@rb6502 The main thing is that it doesn't support ISA slots at the moment. It can probably have NOT_WORKING removed though. Having said that, I'm skeptical that IRIX 5.3 can't be installed on the emulated Indy, because I was successfully able to do that just a month or two ago.

[hbent]

Installing 5.3 from CD on indy_4610 gets all the way through "Copying installation tools to disk" and then spits out a GIO2 error which I have attached here as a screenshot. The exact same thing happens when trying to install 6.2.

I have also attached a screenshot of my install of 5.3 on indigo2_4415, booted to the desktop, from the same 5.3 CD image I am using to try to install on the Indy.

[MooglyGuy]

Yeah, no - you need to set your Indy's MAC address, or that's exactly what will happen.

Prior to booting sashARCS and fx, you need to do the following:

setenv -f eaddr 08:00:69:xx:yy:zz

where xx, yy, and zz are whatever bytes you want your MAC address to read as. If you don't set it up, the installer(s) will panic exactly as described.

[hbent]

Why not set it to a default, like 08:00:69:FF:FF:FF and then the user can override that? Why cause extra, and not at all obvious, work for the user?

[MooglyGuy]

Honestly? Oversight. If you'd like, I can demote the Indy driver back to non-working until such time I have the time and energy to provide a default NVRAM.

[hbent]

No, that seems like overkill. I see that there's a comment in src/mame/drivers/indy_indigo2.cpp , that's probably fine until a default NVRAM can be supplied. It's been years since I've owned a real Indy but I do have a vague memory that if the NVRAM was wiped on real hardware then it would also refuse to boot.

Also fwiw 08:00:69:ff:ff:ff does not work but 08:00:69:12:34:56 does.

While I have you on the line, so to speak, do you know if it's possible to dump an IP20 ROM through software? I see that only 4.0.5D rev A is dumped. My Indigo is running right now so I can't physically check the rom but I'm 100% sure it's newer than that because at one point I did a mainboard swap to a newer rev board.

[MooglyGuy]

Yes - though forgive me if I'm a bit vague on the details as it's been about a decade or more since I documented the process back on the Nekochan forums.

I believe if you look up the relevant details of the "dump" PROM command, you can effectively dump the PROM over a serial console as ASCII hex bytes, then reassemble it into a proper binary file using a simple utility.

Many years have wiped away my recollection of which exact address it was to start dumping from, but the boot ROM is mirrored at 1FC00000, 9FC00000, and BFC00000. One or two of these will just make the dump command bail with a segfault, but I know at least one will allow you to dump the PROM data to the serial console.

For what it's worth, this process works with literally any SGI machine that can be accessed via a serial console, so by all means dump as many as you can.

[hbent]

Attached is a dump of the PROM from my machine. --removed link to attached file, it's copyrighted and goes against the github rules--

I distributed it to the irix.cc community but realized that it would probably be worth placing here too.