Emulation

I love indy's, but since one of my Indy's mainboard bit the dust last september 2015 i have come to the conclusion that it's time to finish the indy emulation in MESS.

Over the past few months i've researched if the SGI Indy emulation in MESS is usable and if there is a real possibility of getting this driver into a complete working state.
This means that the machine should be capable of running IRIX in some form or flavor straight from a disk image or installed via CDROM up to running the desktop.
The CPU emulated should of course match a real CPU-option inside an indy.

Indy emulation started to appear in MESS0144u5 by virtue of a coding spree by a user called Arbee and Ryan Holtz (Mooglyguy) in april 2005, as stated here http://rbelmont.mameworld.info/?m=200504
They have published emulation code for the wd33c93 and newport XL graphics as well as the central Indy MC controller and HPC3 peripheral controller.
Because the Indigo2 shares many common features with the Indy, they are now sharing the same driver in MESS.

From MESS0145 to MESS0147 the indy and indigo2 emulation is functional up to and including booting the PROM, displaying graphical output and responding to keyboard input. You can go into prom, print 'hinv' and 'printenv'.

The working emulated systems are:
ip224613 : Indy R4600PC 133MHz, 128MB Memory, 24 bit newport, B6 PROM sept 28 1994
ip225015 : Indy R5000PC 150MHz, 128MB Memory, 24 bit newport, B10 PROM feb 12 1996
ip244415 : Indigo2 R4400PC 150Mhz, 128MB memory, 24 bit newport, B PROM sept 16 1993

ip204415 is a non-working emulation of the R4400PC 150MHz indigo. The console outputs:


There also is no emulation driver for the Indigo1 Entry LG1/LG2 hardware yet.


This is the cool testing stuff so far...

Some notes i've collected:

- MESS swapped the designation for the roms and the Indy/Indigo2 systems: it uses ip22xxyy for the Indy and ip24xxyy for the Indigo2, but the systems true ip hardware/software designations are ip24/ip22 for the Indy and ip22/ip22 for the Indigo2.
- PROM cannot accurately determine the clockspeed and displays 16 MHz for all CPUs.
- All CPU's are being emulated without L2 or Secondary Cache. In MESS the MIPS3 emulation does not seem to have code to support the secondary cache controller for the R4000/R4400 cores. The actual QED R4600/R5000 MIPS designs do support secondary cache but lack hardware control on the die, so this is externally provided via ASICs on the CPU-board for the SC models. AFAIK documentation for these ASICs have not been released, so they cannot be emulated.
- With MESS0148 keyboard input was lost, so interaction with the PROM was not possible. This regression continues up to at least MESS0168. I have not tested MESS0171 yet, but the sgi.cpp and indy_indigo2.cpp code shows no significant changes.

What needs to be done is the following:
- Get w33c93 SCSI DMA back on track so that we can boot with CDROM images again. We probably need to include code for linked lists in w33c93 driver
- Get VDMA on the MC coded. There is a code example in vdma.ps to get people started.
- Add Semaphore registers on the MC
- Keyboard emulation needs to be better
- Check Newport driver state. It should be nearly finished, but maybe there are commands missing.
- Also check if the Newport driver can emulate an XL8 instead of an XL24
- Check Dallas EEPROM save and restore. It should be possible to handle EEPROM settings from a file
- Fix proper initialisation of the MC registers. currently upon power-cycle every register is initialized to zero, but it has a defined state, see mc.ps
- Check/Fix PROM settings for the CPU, it can be read by the MC so it should be correct.
- Need some form of HAL2 device support, otherwise we have no sound on the emulated Indy/Indigo2
- VINO and the INDYCAM ae not supported. VINO is documented, but you need a PC/machine with video in signal, and the INDYCAM interface has no documentation.
- Need CHD images from an Indy with R4600PC or R5000PC XL24 IRIX 5.3 6.2 or 6.5 installation. Should not be too difficult to make, if you have the exact hardware/PROM/GFX combination.
- Also need CHD image of an Indigo2 R4400 XL IRIX 5.3 6.2 or 6.5 installation. Should be doable but Indigo2 XL cards are uncommon.

Well, i'll start with VDMA. I'll let you know in what millennium i will finish

Sources:
https://www.linux-mips.org/wiki/Indy
http://www.progettosnaps.net/mess/repository/
/usr/include/sys from a recent IRIX 6.5 install.

I have this Indy http://forums.nekochan.net/viewtopic.php?f=14&t=16728856&p=7371124 that sounds like the correct config. How would I make a CHD image though? Note it has Irix 6.2, but by no means a fresh install.

In order to make a CHD file from an IRIX installation, it is necessary to hook up the IRIX root drive to a Linux machine and copy the raw data with dd from the drive to a file. Then invoke chdman. The MESS 0145 syntax is:


in our case that should be:


Where CHS are the numbers for the actual disk geometry and 512 is the sector size.

Actually you beat me to it i tried to make an IRIX 6.2 and 6.5.22 CHD of an Indy R5K with XL24 with the SCSI2SD emulator. it uses an SD card to emulate a harddisk, which obsoletes the use of an actual SCSI card inside a modern PC. Obtaining the IRIX disk image is simply a matter of dd'ing the SD card contents to a file.

Any update on this, I wish we had more emulators for this stuff.

This is incredible this is even partially a thing.

I would be happy to support development on SGI MESS through Patreon (?), Kickstarter or similar, and guess there is a bit of interest in this. Anyone up to the task of starting a project (Dexter already has started - but maybe some additional incentive to work on it would be nice)?

I'm not sure a kickstarter or crowdfunding would be applicable to getting specific emulation drivers into MESS. The authors of MAME and MESS are quite closed and unapproachable about code development and apart from hacking it yourself, there is not much else one can do besides bugging them.

As a fact, the SGI Indy emulation is on their TODO list, see https://www.mess.org/mess/todo so it might take a bit of friendly poking to get things going.

I managed to get SCSI and DMA working on my own emulator for the Personal Iris and Indy. I'm currently using QEMU for MIPS emulation, which has some limitations, at least for the R3k, which makes emulating the PI impractical (no R3k TLB support). However, I have enough of the Indy hardware emulated to boot the PROM, ide, fx and sash and nearly boot Irix:


It's booting from a disk image of my Indy. It looks like it got far enough to read the time off the filesystem. It starts to write to the disk and then hangs after printing the "T". Anyone want to guess what the next letters are?

It has a clean shutdown if I make the disk read-only:


It kind of boots Irix 6.5, though it crashes with a missing TLB entry for 0xFF800000 before it gets to the point of mounting the disk:



I suspect the problem lies somewhere in the SCSI emulation. Or possibly DMA. I can run ide and see some HPC3 error messages, but they are too terse to know what they mean.

Wow, excellent Work!

This looks like it's on par with the emulation in MAME. You have confirmed my assessment of Qemu as the best platform to start this project. MAME is old school C and too dense with macros to develop fruitfully. Folkerts MIEP, another emulator, has some interesting code and a MIPS3 engine from scratch, see https://github.com/flok99/miep and https://www.vanheusden.com/miep/

SCSI emulation of the wd33c93 can be problematic, but i believe the amiga 3000 has relatively complete wd33c93 support, see http://eab.abime.net/showthread.php?t=67211&page=2
I am planning to look at their code. Apparently scatter-gather doesn't work in the MAME driver but is functional in theirs.

So the image is from an indy? I gather you haven't implemented a framebuffer and REX3 support since that would explain why it fails to find a video device.
I have other images available, i can probably also make a 6.2 Indy image and a 6.5 Challenge S image, once my second SCSI2SD has arrived.

As for DMA, i assume you have programmed DMA either in a separate thread, or you are performing 'atomic', i.e. one byte, transfer per cycle in a function called from the main emulation cycle.
Do make sure you correctly identify that some DMA registers are being copied upon initialisation and start of the DMA transfer. I've told this to Folkert and that part of the code is correct, but he got the DMA initialisation unfortunately wrong.
I have some DMA transfer code which i can show you that fixes the init .Let me know if you want to see it.
As soon as time permits i'll be revisiting indy emulation, which will be somewhere next month.

Do you have a github repo of your code by any chance?

Thanks.

I don't have any graphics at this point. The priority is IRIX, then networking. Once I have networking working, it should be fairly straight forward to do remote-display until I figure out the graphics hardware. Because documentation on the graphics engine is sparse, I think direct hardware emulation will never happen in a meaningful way. Newport graphics is rather limited since geometry transforms are all host-side. The best path would probably be to replace libgl.so with a custom version that speaks to the native hardware of the host.

I found a bug in my DMA code over the weekend where, as you suggest, the registers need to be preserved across transfers. If you assume the hardware does the simplest thing (leaving the registers untouched), it's usually right But software needs to actively preserve them. In this case the current count needs to be preserved across invocations.

Looks like IRIX will set up the full DMA chain (say a 256kB block) and then do two 128kB transfers. Ordinarily, the hardware would just handle this since the wd33c93 would stop once each transfer is complete. Initiating a second transfer presumably lets the DMA continue. It's kind of hard to tell based on looking at my logs.

I haven't uploaded this to github yet because the code is in pretty rough shape. I'm patching a rather old version of QEMU (2014) and the code is quite messy at this stage. First step is to understand what's going on.

I found the NetBSD source quite handy for understanding the hardware. They seem to know at least a few of the hardware tricks.

jaggies wrote: I don't have any graphics at this point. The priority is IRIX, then networking. Once I have networking working, it should be fairly straight forward to do remote-display until I figure out the graphics hardware.

The Seeq8003 network interface with the GIO bus is handled by the HPC3 along with the PBUS and the SCSI channel(s). It looks like there are code examples on the net describing the interface to it, but emulation might be nontrivial.

Because documentation on the graphics engine is sparse, I think direct hardware emulation will never happen in a meaningful way.

Oh, i beg to differ. The documentation of the Indy at https://www.linux-mips.org/wiki/IP22 is quite complete. All the custom onboard and Newport ASICS, except the HAL2 sound chip and the VINO video module, is well documented via released internal documents from SGI engineers themselves.
The main Newport graphics interface with the GIO bus is the Raster Engine chip REX3 and is documented at ftp://ftp.linux-mips.org/pub/linux/mips ... y/rex3.pdf
You will find the rest of the Newport graphics components on that site as well.

I found a bug in my DMA code over the weekend where, as you suggest, the registers need to be preserved across transfers. If you assume the hardware does the simplest thing (leaving the registers untouched), it's usually right But software needs to actively preserve them. In this case the current count needs to be preserved across invocations.

Yes, a DMA transfer is time-limited to a number of GIO bus cycles. It will stop at certain intervals to allow the MC3 and CPU to handle interrupts. The DMA engine can even issue interrupts on its own when it encounters a problem.

Looks like IRIX will set up the full DMA chain (say a 256kB block) and then do two 128kB transfers. Ordinarily, the hardware would just handle this since the wd33c93 would stop once each transfer is complete. Initiating a second transfer presumably lets the DMA continue. It's kind of hard to tell based on looking at my logs.

This could actually be the result of the DMA engine being time-limited and returning GIO bus control to the MC3 after a certain time, handle interrupts (probably from the wd33c93 or network or PBUS), and resume DMA transfer again.

I haven't uploaded this to github yet because the code is in pretty rough shape. I'm patching a rather old version of QEMU (2014) and the code is quite messy at this stage. First step is to understand what's going on.

There are many people knowledgeable about the innards of an Indy on this forum and we're still running IRIX on these systems on a daily basis. So ask anything and don't hesitate to call for help.

I found the NetBSD source quite handy for understanding the hardware. They seem to know at least a few of the hardware tricks.

The linux port of the Indy in 2.6 kernel is also pretty good. They have drivers for the analog part of the indy sound chip i haven't seen elsewhere.