SGI: Hardware

The GXemul site ( http://gavare.se/gxemul/ )mentions that you can dump the PROM on an O2 but it doesn't support IP32 enough to work. So I was thinking about dumping the PROM on my Indy but wasn't sure if he PROM was at the same location.

Dumping the PROM on a SGI O2:
The general ideas in this section applies to using ROM images from other machines as well. Besides DECstation, I've also tried this on an SGI IP32 ("O2").

For the O2, a suitable command to dump the prom memory range is

>> dump -b 0xBFC00000:0xBFC80000

Make sure you capture all the output (via serial console) into a file, and then run experiments/sgiprom_to_bin on the captured file.

(2005-01-16: The emulator doesn't really emulate the IP32 well enough to actually run the PROM image without using special hacks, but it might do so some time in the future.)

What do you think? Does an Indy R5000SC keep its PROM in the same location?

I have no clue if the Indy has the same address range. I did however dumped the PROM of the Indy some time ago. Just an EEPROM reader with 40 pin EEPROM support was enough, no hassles

In case you need the O2 PROM, easiest thing is to extract the O2 PROM from a recent overlay. They are on the second disk:

and contain only one file

To extract them, just copy those three files in /tmp and start inst as 'inst -f /tmp -r /tmp -m CPUBOARD=IP32'
- Select from
- List the subsystems to be installed, it should be marked with an 'i'
- 'set rulesoverride on'
- go
- exit

The prom is then in /tmp/usr/cpu/firmware/ip32prom.image

All MIPS processors have their boot ROMs located at 0xBFC00000, so yes, it will work. Incidentally, if you want to emulate an R5K Indy, just grab the boot ROM here: http://einstein.etsu.edu/~zrah2/ip225015.zip - it's off of a 150MHz R5K Indy. Fair warning, you might have to swap it for endianness, though. It's only in its current format because that's what my own emulator takes.

MooglyGuy wrote: All MIPS processors have their boot ROMs located at 0xBFC00000, so yes, it will work. Incidentally, if you want to emulate an R5K Indy, just grab the boot ROM here: http://einstein.etsu.edu/~zrah2/ip225015.zip - it's off of a 150MHz R5K Indy. Fair warning, you might have to swap it for endianness, though. It's only in its current format because that's what my own emulator takes.

Which emulator do you use?

edit: Something MAME related?

MooglyGuy wrote: All MIPS processors have their boot ROMs located at 0xBFC00000, so yes, it will work. Incidentally, if you want to emulate an R5K Indy, just grab the boot ROM here: http://einstein.etsu.edu/~zrah2/ip225015.zip - it's off of a 150MHz R5K Indy. Fair warning, you might have to swap it for endianness, though. It's only in its current format because that's what my own emulator takes.

I can confirm that this image is indeed exactly the same as my rev 11 PROM dump at home. It is byteswapped over 4 bytes however, so you have to swap it back to read all the nice text

Check out http://nova.stanford.edu/~curtis/resear ... byteswap.c
and perform the byteswap with: ./byteswap -o ip225015be.bin 4 ip225015.bin

Thanks Moogly for that info!

Stonent wrote: Which emulator do you use?

edit: Something MAME related?

Well, I'm not so much "using" an emulator as I am coding one. Currently Indy is on the backburner, what I'm really after is the R4K Indigo. It doesn't run well, but it's at least coherent enough to spit out this log ("loading ip204415.bin" is output by the emulator, the rest is from the Indigo):

http://einstein.etsu.edu/~zrah2/log.txt

And yeah, I'm using MESS's architecture to create an Indigo driver. MESS is the sister project to MAME, only it emulates computers and game consoles instead of arcade machines. Incidentally, I'm always looking for more PROM dumps of anything R5K and prior. I'm mostly looking for dumps from R3K machines, if only because the R3K is the most well-supported in MESS and MAME.

dexter1 wrote: Thanks Moogly for that info!

No problem!

EDIT: Well, I mapped in RAM at 0x00000000 and mirrored it at 0x80000000 and 0xA0000000, that got rid of those strange errors at the bottom of the log. I then kludged in the HPC's VME Interrupt Mask registers and LIO Register Mask registers, now it doesn't complain about the interrupt controller. Just fails on the SCSI controller diagnostic and Keyboard/Mouse diagnostic.

MooglyGuy wrote: All MIPS processors have their boot ROMs located at 0xBFC00000, so yes, it will work.

MIPS, but not MIPS64. I know at least some SGI's have their PROM at an address too large for a 32bit pointer, which makes it impossible to run a 32bit kernel on them (assuming you would like to, that is).

I stand corrected. So the R5000 is still MIPS32, then?

Well, that's a bit better:



Does anyone have any idea exactly how the HPC1.5 interfaces with the on-board WD33C93 controller? Apparently 0x1fb80120 and 0x1fb80124 can be used to both read and write from some place on the WD33C93, but I'm not 100% sure either way. All I know is that if it writes 0x00 to ...120 and a value to ...124, then when it reads ...124 it expects the value written to ...124, and if it writes 0x17 to ...120, then it expects 0xa5 to be returned on the next read from ...124.

Well, that was interesting. Byteswapping worked though. Now I can run strings on the file and actually read the text inside it.

That's exactly what happens to me, too. Incidentally, trying to run the swapped Indigo PROM that I have in gxemul (since it says it has basic IP20 support) just causes it to hang, waiting for something (I believe) in the MC. It's pleasing to know that even in its broken state, my driver in MESS is still better.

I like gxemul because it is easy to use. The last time I played with MESS was about a year ago. It was really hard to get things going. I wish the win32 gui for MESS was ported to Linux/Unix etc.

Here's a shout out to anyone who has one of the following:
- An R5000-based O2
- An RM5271-based O2
- An RM7000-based O2
- An R4x00-based Indigo 2

If you could hook up your machine via the serial console, and from the command monitor, run a "dump -w -x 0xbfc00000:0xbfc80000" in a terminal that supports logging, and then post a link to the log, I'd appreciate it.

And for anyone who has one of the following:
- Any R1x000-based machine (including Tezro or Fuel, for you lucky few)

If you could hook up your machine via the serial console, and from the command monitor, run a "dump -w -x 0xffffffffbfc00000:0xffffffffbfd00000" in a terminal that supports logging, and then post a link to the log, I'd appreciate it.

For reference, the former are candidates for emulationg in MESS - even if they're just skeleton drivers without functionality, it's good to have the stuff preserved - and the latter don't actually have CPU cores that would make them emulatable by MESS, but I file them under the "good to have" heading.

MooglyGuy wrote: - An R4x00-based Indigo 2

If you could hook up your machine via the serial console, and from the command monitor, run a "dump -w -x 0xbfc00000:0xbfc80000" in a terminal that supports logging, and then post a link to the log, I'd appreciate it.

One 150MHz R4400 Indigo2 PROM coming up:

minicom dump
bigendian binary dump

To check whether this dump went ok, i extracted the boot image and boot tune(s):


boottune(s)

As for the O2's i doubt that these will be different. They are flash upgraded, so you can extract them from irix overlays

Thanks for the Indigo 2 dump! As for extracting the boot PROM image from overlays - nope, you can't. The appropriate file does indeed contain part of the upgraded boot PROM image, but it does not contain the entire image, and most importantly, it doesn't contain most of the actual bootup code (negating any usefulness it might still have).

Sorry to bump the old topic, but here's something you all may like:

http://einstein.etsu.edu/~zrah2/ip225015_0.png
http://einstein.etsu.edu/~zrah2/ip244415_0.png
http://einstein.etsu.edu/~zrah2/ip244415_1.png

The terrible brokenness is because I currently have a grand total of one (1) Newport graphics command implemented. But hey, it's better than I thought - I was just expecting to get the gradiented background when I implemented it.

Fan-Bloody-Tastic!

Extremely cool done. I wonder how fast these babies run emulated.

Newport is the only Gfx for which docs are readily available, but the dudes porting Linux on Mips have a good trackrecord of reverse engineering Impact Gfx so this might be a future option for the IP22 Indigo2. Don't bother with the GR2 boards like the XZ, though for historical reasons they might be fun to emulate too...

Indeed. Oh, and incidentally, I implemented a second Newport command, and my coding partner fixed up keyboard support. You can find better screenies here: http://rbelmont.mameworld.info/

Yeah, the "16MHz R5000" in the hinv is pretty funny, but then again, I'm not making the slightest effort to accurately emulate any timers, either.

EDIT: As for how fast they run emulated, currently the Indy is about as fast as the games emulated in MAME that run on the Midway Seattle hardware. That is to say, about two or three frames per second on an Athlon XP 2100, and you'd be lucky to get 10fps on a top-of-the-line PC. On the bright side, the 133MHz R4600 Indy runs at about 10fps on my Athlon XP 2100, so maybe it would be 20-25fps on a top-of-the-line PC.