I'm pretty sure it was there for a long time. It's under memory layout suboptions. When it says "any memory layout changes" say yes, then when it asks what, say ODT. paul

I have a Monitor ODT manual from RSTS V4, I should find a way to make that available. It's pretty nearly standard ODT, there are a few extensions for mapping addresses -- essentially a "software MMU". But for the moment you should not need that. Yes, ODT is an undocumented option. Enter that and give the start address (for example "51K"). You can use the memory LIST option to see what is free. Right after the kernel is a good spot. It needs to be below 124K. You may have XBUF in the way; if so move it first. Once it's set, ODT will be loaded with RSTS at startup. It will be entered on a crash, or if you enter control-P at the console. That gives you a "BE" message ("breakpoint error") because entry is with the BPT instruction but there isn't an ODT breakpoint at that address. The ODT prompt is _ (underline) rather than *. You can examine stuff or do all the usual ODT things, then enter P to proceed. To find LOG$DK, you can either look in the link map (RSTS.MAP) from the SYSGEN, or ask the init PATCH option to tell you: RSTS V7.0-07 V7dm (DM0) Option: PA File to patch? Module name? Base address? LOG$DK Offset address? 0 Base Offset Old New? 104030 000000 016104 ? ^C Those empty entries are Line Feed to accept the default. This is a simple way to query the RSTS symbol table.

What we have here is a confusion on my part. The LOG$xx symbols are for the most part defined in the kernel definitions file KERNEL.MAC. They are EMT instructions with a device code in the low byte; in the kernel an EMT is handled as a request to invoke the error logging machinery. Dispatching for that goes through a table indexed by the EMT code, so what you actually need is to look in the correct entry of that table to find the RK11 driver logging entry point. A breakpoint set there should trigger when a disk error is reported by the driver. Here's how: RSTS V06C-03 FRITZTS (DK0) Option: PA File to patch? ERRTBL Illegal file name File to patch? Module name? ^C Option: PA File to patch? Module name? Base address? ERRTBL Offset address? LOG$DK-104000 Base Offset Old New? 030162 000030 055230 ? ^Z Offset address? ^Z Base address? 55230 Offset address? 0 Base Offset Old New? 055230 000000 004537 ? ^C Option: So in this example, 55230 is the error logging entry point for the RK11 driver. In V10.1, that code looks like this; I suspect the V6C code is the same or nearly so: .SBTTL ERROR LOGGING ERRENT LOG$DK CALLX ERLDSK,R5 ;;;USE COMMON ROUTINE .BYTE ERC$DK ;;;ERROR CODE .BYTE -1 ;;;OVERLAPPED SEEK .BYTE RKDS,6 ;;;OFFSET, 6 REGISTERS .BYTE 0,0 ;;;THAT'S ALL RETURN ;;; AND BACK In any case, that doesn't really matter. If you have a breakpoint at this location, you'll be able to capture the controller CSR contents which -- I hope -- will explain why the system is not happy. The way to set the breakpoint is simply to enter control/P for ODT, then 55230;B to set the breakpoint, then P to proceed. paul

The ODT command syntax is correct. I confirmed by setting a breakpoint at DSQ$DK, the "queue a disk request" driver entry point, and that breaks correctly -- just to make sure my memory hasn't faded. Plan B: set a breakpoint at "ERL" (040672 in your map) which is the entry point to the error logging code. That's where the display register is incremented as part of logging an error. On entry, R0 is the EMT code (a LOG$xx code, because these are EMTs in kernel mode). Many of those codes are fixed and defined in KERNEL.MAC which is in the kit. The ones that are configuration-dependent are in the RSTS.MAP listing, for example LOG$KB. The log code would tell us which device or component is unhappy. paul

Well, this is VERY interesting. The error code is LOG$CK, which is "run time system reported error". There are a couple of possibilities. That code is logged from within the kernel if a pseudo-vector (pointer to code in the runtime system) is invalid. It is also generated if the runtime system issues a .ERLOG EMT. BASIC does so if the .BAC file it wants to run has a bad checksum. So the likely answer is that either your INIT.BAC program, or your BASIC.RTS, is damaged. If you can rename INIT.BAC to something else, you can then try to start and you'd expect to see startup messages like this: ...You currently have crash dump enabled. 04-Jan-99? 08:09 PM? ?Can't find file or account ?Program lost-Sorry Ready If so, then reload INIT.BAC. Or if you have the source (INIT.BAS) just say "old init" and "compile". If you still get a loop, then I'd suspect [0,1]BASIC.RTS. Can you read the RK05 from the machinery you used to fill it originally? It might make sense simply to read parts of it, or all of it, and verify the contents are correct. paul

Okay, I?ve managed to pull back an image of the RSTS pack I?ve been trying to boot, with PDP11GUI. A quick look with od and diff shows many differences between the two, but that?s not totally surprising I guess since the image on the real hardware was reconfigured with ODT, and its swap, error log, and crash files may be different? I?ll have to dig a little deeper there to sort the wheat from the chaff. But what *is* surprising is that the pulled back image boots and runs just fine under SIMH! Hmm... I guess I?ll go ahead and finish up my standalone sector CRC hack and run it both on the real hardware and on the just retrieved image with no changes on either end and make sure those are really identical. If that?s the case, it will come down to what?s different between my machine and SIMH. Maybe I?ve got some flaky memory on my machine? I can push harder on diagnostics on the MS11 and see if I can find anything fishy I guess. Lurking bug in the RK11 maybe? All the CPU, FPU, KT11, KW11, and RK11 MAINDECS are passing just fine. Puzzler... --FritzM.