Hi Jerry, Yup, I have previously had RT-11 running on this machine without incident. Yep, got that in there. Easy enough experiment to try; would need to re-jumper the G740 disk selection flip chip in the RK11-C too, I guess? Only a DL11-W in this system. Ah, haven?t checked that one yet. I will carefully check my basement for squid! --FritzM.

On 1/5/19 11:17 PM, Tony Duell via cctalk wrote: I have used a Diablo drive with 1 of 4 selection on a third party RKV11 controller which was 3 bit binary. It only worked as DK1, DK2 or DK4 for obvious reasons.

On Sun, Jan 6, 2019 at 5:45 AM Fritz Mueller via cctalk <cctalk at classiccmp.org> wrote: Ooops... Yes, you do have to fit the jumper there. Actually, is there a good reason not to fit all jumpers on that board? -tony

Okay, finished up the standalone CRC utility, and verified (to very long odds) byte identical contents between reading the physical pack on the machine and reading the downloaded pack under SIMH. And that image doesn?t boot on real HW, but works under SIMH. I?ll post the CRC utility code up on my '11/45 project blog (http://fritzm.github.io/category/pdp-11.html) when I do a write-up later tonight, in case anybody else is interested in it. So, I?m left with something probably odd with my HW tripping up RSTS but not being caught by MAINDECs :-( I think I?ll switch gears for a bit and work on the USB FIFO to DR11-C hack, since that will help make further experimentation much faster in general. cheers, --FritzM.

Hm. Can you read data back from the RK05 pack? I'd have to refresh my memory on how but it's clearly possible to force a crash dump. That would allow us to dig into exactly what went wrong, provided you can read the dump file (or the whole disk). paul

Here is the procedure. 1. Make sure crash dump is enabled (in the "default" option). Start the system. Let it run for at least one minute. (I'm not entirely sure about older versions, but I think that a crash within one minute of startup is handled differently and doesn't do all the usual dump and restart machinery.) 2. Set the data switches all UP. (In SIMH, enter "D SR 177777".) 3. Set a breakpoint. 4. When you hit the breakpoint, change the PC to 52, like this: 0B:055244 _$7/055244 52 _P (you enter only "$7/" and "52<return>" and "P", the rest is output from ODT.) The system will write the crashdump and then automatically restart. 5. You should now have the crash dump in [0,1]CRASH.SYS, so you can either extract that file and the OS image (the RSTS "SIL" file), or the whole disk. To analyze it, you can use the standard utility ANALYS, or the unsupported SDA Forth program. I haven't tried SDA on a V6C image, though; it will probably work but no guarantees. ANALYSIS needs to be the version that came with that particular OS release, so probably the best way to do it is to boot your system disk image copy on SIMH and run it there. The key question in this instance is who called LOG$CK, the "RTS originated" log call. The stack should help answer that, through tracing through it is a bit painful since there are no explicit stack frames so the equivalent to "print me the call stack" does not exist. If the error originated in a .ERLOG user mode EMT, that means the RTS was unhappy. The RTS itself isn't included in the crash dump, but the saved user mode PC will indicate where the error came from and looking at the BASIC.RTS image will indicate what it was doing at the time. paul

Hi Paul, Thanks, I?ll give that a go! --FritzM.