On Wed, Jul 2, 2014 at 9:57 AM, Ethan Dicks <ethan.di...@gmail.com> wrote: > On Wed, Jul 2, 2014 at 8:44 AM, Cory Smelosky <b...@gewt.net> wrote: >>> root device? rb0* <--- Enter "rb0*" here. >>> idc0: lost interrupt <--- This error repeats infinitely. > > One should be able to attach an RA81 to the emulated 11/730, run from > that, then use the running system to debug problems with the RB730 > code. It would at least allow a controlled poking at the driver, and > even adding driver debug code.
OK... so getting caught up on this, I see that device debugging support is already included in recent versions of SIMH. Very nice. I've enabled it ("set rb debug") and gone through the boot process described previously and there aren't that many register writes up to the "lost interrupt" point... root device? rb0* DBG(319687933)> RB REG: reg 0 write, value = 100C6 DBG(319687934)> RB REG: reg 3 write, value = 250000 DBG(319687940)> RB REG: reg 0 write, value = 46 DBG(319687957)> RB REG: reg 0 read, value = 4000046 DBG(319688004)> RB REG: reg 0 read, value = 4000046 DBG(319688051)> RB REG: reg 0 read, value = 4000046 DBG(319688090)> RB CMD: Seek, CYL=37, TRK=0, SECT=0 DBG(319688090)> RB CMD: Done, INT DBG(319688098)> RB REG: reg 0 read, value = 50100C6 DBG(319688104)> RB REG: reg 0 read, value = 50100C6 DBG(319688104)> RB REG: reg 0 write, value = 50000C6 DBG(319688105)> RB REG: reg 0 read, value = 40000C6 DBG(319688140)> RB REG: reg 0 read, value = 40000C6 DBG(319688143)> RB REG: reg 0 write, value = C0 DBG(319688440)> RB CMD: Done, INT DBG(319688558)> RB REG: reg 0 read, value = 50000C1 DBG(319688561)> RB REG: reg 0 write, value = C0 idc0: lost interrupt DBG(523421810)> RB REG: reg 0 read, value = 40000C1 DBG(523421813)> RB REG: reg 0 write, value = C0 idc0: lost interrupt DBG(729448369)> RB REG: reg 0 read, value = 40000C1 DBG(729448372)> RB REG: reg 0 write, value = C0 idc0: lost interrupt I haven't traced out every bit of every transaction there (I see the disk address (DAR) write, but no bus address (BAR) or byte count (BCR) writes yet), but once it's in the loop, the CSR is reading back R80+CRDY+IE+DRDY (R80 selected, controller ready, interrupts enabled, and drive ready) and the BSD driver is writing into it a "Get status" function (010 in F2:F0) and clearly not seeing what it is expecting. So from thee top, I see the BSD driver put in a Seek command, the SIMH rb handler process that seek and interrupt the BSD driver, which then fiddles a few things (ATTN0 and IR) to acknowledge the interrupt, then sends a status request, which appears to trigger the second interrupt, but the BSD driver must not be seeing what it likes because it loops on sending that status request every few seconds. Probably time to hit the idc driver in 4.3BSD to see what _it_ thinks should be happening. -ethan _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh