The collected works of jaggies

jaggies
Who joined Aug. 21, 2017, 10:16 p.m.

Wrote on the subject of Indy and indigo2 emulation in MESS (WIP) at Aug. 21, 2017, 10:55 p.m...

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.

jaggies
Who joined Aug. 21, 2017, 10:16 p.m.

Wrote on the subject of Indy and indigo2 emulation in MESS (WIP) at Aug. 22, 2017, 11:57 a.m...

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.