Indy and indigo2 emulation in MESS (WIP)

MAME/MESS, Vice(C64), Stella(VCS2600), UAE(Amiga) and more.
User avatar
dexter1
Moderator
Moderator
Posts: 2726
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Indy and indigo2 emulation in MESS (WIP)

Unread postby dexter1 » Mon Mar 07, 2016 4:11 pm

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:

Code: Select all

Can't determine CPU speed



                         Running power-on diagnostics...


Initializing tod clock.
setting secs=0 min=0 hour=0 day=1 month=1 year=0

Keyboard/Mouse diagnostic                  *FAILED*

        Check or replace:  CPU board

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.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

User avatar
darkninja
Posts: 16
Joined: Wed Apr 15, 2009 10:58 am
Location: Nashville, TN USA

Re: Indy and indigo2 emulation in MESS (WIP)

Unread postby darkninja » Mon Mar 28, 2016 3:14 pm

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.

User avatar
dexter1
Moderator
Moderator
Posts: 2726
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: Indy and indigo2 emulation in MESS (WIP)

Unread postby dexter1 » Mon Mar 28, 2016 5:19 pm

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:

Code: Select all

chdman -createhd input.raw output.chd [inputoffs [cylinders heads sectors [sectorsize [hunksize]]]]

in our case that should be:

Code: Select all

chdman -createhd inputfile.dd irix62.chd 0 C H S 512

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.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

User avatar
mia
Posts: 1054
Joined: Wed Feb 19, 2003 1:54 pm

Re: Indy and indigo2 emulation in MESS (WIP)

Unread postby mia » Sat Feb 18, 2017 8:14 am

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

User avatar
scottE
Posts: 410
Joined: Mon Jul 14, 2003 12:20 pm
Location: Wasilla, not so close to super Indian Food
Contact:

Re: Indy and indigo2 emulation in MESS (WIP)

Unread postby scottE » Fri Mar 24, 2017 1:06 pm

This is incredible this is even partially a thing.
Scott Elyard cgfx.us
:Octane2: Sarcosuchus_imperator :Octane: Liopleurodon :Indigo2: Carcharodon :Indy: Helicoprion :Indigo: Paradoxides

User avatar
luchford
Posts: 26
Joined: Sat Jun 10, 2006 2:56 am

Re: Indy and indigo2 emulation in MESS (WIP)

Unread postby luchford » Sun Apr 09, 2017 2:41 pm

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)?

User avatar
dexter1
Moderator
Moderator
Posts: 2726
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: Indy and indigo2 emulation in MESS (WIP)

Unread postby dexter1 » Tue May 09, 2017 1:36 am

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.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

User avatar
jaggies
Posts: 3
Joined: Mon Aug 21, 2017 10:16 pm

Re: Indy and indigo2 emulation in MESS (WIP)

Unread postby jaggies » Mon Aug 21, 2017 10:55 pm

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:

Code: Select all

% telnet localhost 8888
Trying ::1...
Connected to localhost.
Escape character is '^]'.

NVRAM checksum is incorrect: reinitializing.



                         Running power-on diagnostics...



Cannot open video() for output
Cannot open video() for output


System Maintenance Menu

1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor

Option? 5
Command Monitor.  Type "exit" to return to the menu.
>> hinv
                   System: IP22
                Processor: 200 Mhz R4000, with FPU
     Primary I-cache size: 8 Kbytes
     Primary D-cache size: 8 Kbytes
              Memory size: 256 Mbytes
                SCSI Disk: scsi(0)disk(1)
                SCSI Disk: scsi(0)disk(2)
                SCSI Disk: scsi(0)disk(3)
                    Audio: Iris Audio Processor: version A2 revision 0.0.0
>> single


                 Starting up the system in single user mode...

Loading scsi(0)disk(1)rdisk(0)partition(8)/sash: 72912+9440+3024+331696+23768d+3644+5808 entry: 0x97f9a950
1585056+190464+159456 entry: 0x880038c0
IRIX Release 5.3 IP22 Version 11091812 System V
Copyright 1987-1994 Silicon Graphics, Inc.
All Rights Reserved.

WARNING: time of day clock behind file system time--resetting time
WARNING: clock gained 11640 days
WARNING: CHECK AND RESET THE DATE!
WARNING: This system may require the revision C Memory Controller (MC) chip
   in order to operate correctly with the type of memory SIMMs installed.
   You do not need the new MC unless you experience memory errors.

T
...

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:

Code: Select all

>> single


                 Starting up the system in single user mode...

Loading scsi(0)disk(1)rdisk(0)partition(8)/sash: 72912+9440+3024+331696+23768d+3644+5808 entry: 0x97f9a950
1585056+190464+159456 entry: 0x880038c0
IRIX Release 5.3 IP22 Version 11091812 System V
Copyright 1987-1994 Silicon Graphics, Inc.
All Rights Reserved.

WARNING: time of day clock behind file system time--resetting time
WARNING: clock gained 11640 days
WARNING: CHECK AND RESET THE DATE!
dks0d1s0: cannot mount: write-protected device
dks0d1s0: Write error.
Filesystem on device may be corrupted: unmount and fsck it.
WARNING: initial mount of root device 0x2000010 failed with errno 30

PANIC: vfs_mountroot: no root found


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:

Code: Select all

                 Starting up the system in single user mode...

Loading scsi(0)disk(1)rdisk(0)partition(8)/sash: 135200+22752+3216+341792+49344d+4552+6800 entry: 0x97fa5f00
Attempting to load debugger at "scsi(0)disk(1)rdisk(0)partition(8)symmon" ...
4096+261932+125176 entry: 0xa8008200
Cannot open video() for output
Cannot open video() for output

Symbolic Debugger SGI Version 6.5 IP22  Oct  9, 2001
Entering client program at 0x88072530
IRIX Release 6.5 IP22 Version 10100654 System V
Copyright 1987-2001 Silicon Graphics, Inc.
All Rights Reserved.

PANIC: TLBMISS: KERNEL FAULT
PC: 0x88179108 ep: 0x88426690
EXC code:8, `Read TLB Miss '
Bad addr: 0xff800000, cause: 0x608<CE=-2011657888
Keyboard interrupt

DBG:


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.

User avatar
dexter1
Moderator
Moderator
Posts: 2726
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: Indy and indigo2 emulation in MESS (WIP)

Unread postby dexter1 » Tue Aug 22, 2017 12:36 am

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?
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

User avatar
jaggies
Posts: 3
Joined: Mon Aug 21, 2017 10:16 pm

Re: Indy and indigo2 emulation in MESS (WIP)

Unread postby jaggies » Tue Aug 22, 2017 11:57 am

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.

User avatar
dexter1
Moderator
Moderator
Posts: 2726
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: Indy and indigo2 emulation in MESS (WIP)

Unread postby dexter1 » Tue Aug 22, 2017 2:52 pm

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.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

cesss
Posts: 98
Joined: Mon Apr 27, 2009 8:02 am

Re: Indy and indigo2 emulation in MESS (WIP)

Unread postby cesss » Tue Sep 19, 2017 5:00 am

jaggies wrote: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).

Did you try the cycle-accurate MIPS emulator from the CEN64 project? I believe that if its CPU emulation isn't 100% complete, it will be around 99% complete and only minor work would be necessary. Moreover, having a cycle-accurate MIPS emulator opens the door to more accurate IRIX emulation.

However, in this moment I'm not sure if the N64 CPU misses some important component/feature from the R4K-series CPUs used in SGI boxes.

User avatar
Dodoid
Posts: 581
Joined: Mon Jul 04, 2016 1:36 pm
Location: Ottawa, Canada
Contact:

Re: Indy and indigo2 emulation in MESS (WIP)

Unread postby Dodoid » Wed Sep 20, 2017 6:08 am

That would be R4000 architecture, not the R3000 he says he's having problems with.
:Onyx: :O2000: :Fuel: :Octane: :Octane: :Octane: :O2: :O2: :Indigo2: :Indigo2: :Indy: :Indy:
and a small army of Image


Return to “Emulation”

Who is online

Users browsing this forum: No registered users and 1 guest