Open larsbrinkhoff opened 7 years ago
Related:
I have a fairly complete set of KLAD diags at sky-visions.com/dec/klad.tap This is a tops 10 backup. It includes some peripheral diags that I got from Living Computer Museum in Seattle, and the stuff off trailing-edge. It has full KA and KI diags sources. I have not checked the KL10 stuff out yet, and did not grab some of the KL specific diags.
There's a processor test suite that runs under timesharing in the MAINT; directory. It only tests KA10 instructions
MAINT; PART A etc seems to be the KLAD diagnostics.
MAINT; PDP6 1 to 5 is the PDP-6 diagnostics.
KLDCP added in #974.
Some notes about KLDCP:
When the KL-10 processor was introduced, the monitor was loaded via KLDCP. RSX-20F did not yet exist. KLDCP originally booted from DECtape; floppies came later. It can also be loaded from RSX-20F on the KLAD pack.
Tymnet used KLDCP to load their monitor (TYmcom-X) until they replaced their KL-10 systems with a pair of Toad-1s.
KLDCP was madly hacked at SAIL to support loading WAITS, to support a Xerox Ethernet card in the front end PDP-11, and to support a TOY card in the front end (a TCU-100). Our TCU-100s developed faults, so we've decided to use a TCU-150 instead, with concomitant changes to WAITS and KLDCP (including a SET CLOCK command for the latter) when we can find a Round Tuit(TM).
We boot WAITS by booting RSX-20F, loading WAITS.EXE into the 10-side memory with BOOT, then loading the Stanford KLDCP into the -11 and starting it. We start WAITS from there.
Thank you @rmaldersoniii, followup question:
AI WP 227 "spells and incantations" details how to cold boot KL10 ITS. It doesn't mention DECtape. It says to push the ENABLE switch, then the DISK button, and this should load KLDCP. Did it also have the capability to boot off disk?
That would be an MIT hack. Here's how booting a standard KL-10 works:
There are 4 momentary-contact switches in the nameplate above the PDP-11/40 front end processor, labeled ENABLE, FLOPPY or DECTAPE, DISK, and SW REG. If the ENABLE switch is not held, the others have no effect; holding ENABLE and pushing one of the others generates an interrupt to the -11 forcing it to execute code from the boot ROM which determines which switch was used and dispatches accordingly.
If the SW REG switch is used, the console switches are read by the ROM code, and non-default values are set for which disk to address for booting, which DH11 line to use as console, and whether or not to start the KLINIT task once RSX-20F is running (the 4 bit). In particular, if the 200 bit is off, boot from floppy or DECtape (only one of which is supported in the front end); if it is on, boot from an RP04 or RP06 disk.
If one of the other switches is used, boot from unit 0 on whichever controller is selected (TC11/RX11 or RH11). Any value in the console switches is ignored.
Booting consists of reading in 4 blocks starting at sector or block 0 (depending on disk or DECtape), the first of which is an analog of the ROM code loaded by the use of the switches. For RP04/6, the code looks in the HOM block for the address on disk of the front end area and loads RSX-20F from there.
If MIT-MC (MIT-MX) was booted via KLDCP using the DISK switch, then the front end area was formatted a la DOS-11 rather than RSX-11M and a copy of the diagnostic loader was stored in its boot region. I do not think that this was supported by DEC--I only ever heard of KLDCP booting directly from DECtape or floppy.
I'm attaching raw dumps of the ROM and disk boot code and analyses of same which I did more than 10 years ago as we were restoring the 2065 here at the museum to working condition. This may not be the best place for them, but I'm not an Github expert.
BOOTSTRAP.dump.txt DSKB.bootsector.dmp.txt DSKB.bootsector.txt KLAD.bootsector.dmp.txt KLAD.bootsector.txt
In case anyone reads here about booting KLDCP off disk, there's more information in #744.
@aap has run some of the MAINT; PDP6 files to test his pdp6 simulator.
I have dumped out and disassembled some of the contents of MC's front end disk, including the boot sector. analysis.txt
It might be interesting to run some of the KLAD diagnostics.
http://pdp-10.trailing-edge.com/klad_sources/
KS Diagnostics:
http://pdp-10.trailing-edge.com/ks_diag_gs/
In particular, I'm curious how the emulator instruction timings compare to @jfcl's FPGA results: https://github.com/KS10FPGA/KS10FPGA/wiki/Benchmarks