Boot from tape

[larsbrinkhoff]

SIMH has the ability to boot from a tape. I would like that feature in KLH10 too.

(Why? Because I'm working on an automated ITS installation, which starts from boot tapes.)

[larsbrinkhoff]

When SIMH boots from a tape (or disk), it loads "boot ROM" into memory at location 377000, and jumps to that. Does this seem like something we could copy to KLH10?

[brouhaha]

A KL10 doesn't have a boot ROM that is accessible to the PDP-10 processor. The first 11/40 front end in a KL10 has a BM873-Yx boot ROM module. It boots RSX-20F on the front end from RP06, DECtape (w/ TC11 control), or RX01. The main programs used on RSX-20F are KLINIT and PARSER. KLINIT is used for KL10 initialization, including memory and cache configuration, loading the microcode, and loading and starting the PDP-10 bootstrap (BOOT for RP06, BOOTM, or MTBOOT for magtape), all via the DTE20 interface between the Unibus and the PDP-10 processor. PARSER provides a command-line equivalent of "front panel" operation of the PDP-10 processor.

Most of this is not relevant to KLH10, but I think KLH10 should ideally handle booting as if the front end were present, by loading BOOT/BOOTM/MTBOOT then having the processor run it, rather than inventing a new "boot ROM" for the KL10.

I'm not famiilar with the method of booting ITS on a KL10, but I'd be somewhat surprised if it didn't use the same BOOT/BOOTM/MTBOOT method used for loading the DEC operating systems.

The BOOT and MTBOOT I'm familiar with appear to be the ones in the run/klt20 directory, which should work with TOPS-20 and with 7.x of TOPS-10.

[Rhialto]

So it seems that what KLH10 does isn't too dissimilar from having a front-end which "magically" puts some stuff into memory and run it. Just without having an actual programmable CPU which does it.
Booting the Panda distribution has this command in its ini file:

; Load disk bootstrap directly
load boot.sav

Doing the same with run/klt20/mtboot.sav should allow booting from tape then. The tape installation of TOPS-20 works that way, via the run/klt10/inst-klt20.ini file.
So if ITS on real hardware uses MTBOOT, that can be done already. If it uses something else, you can hopefully find the file and maybe convert it to the format that KLH10 likes.

[larsbrinkhoff]

@brouhaha I'm primarily interested in booting on a KS10, because the version of ITS we have today ran on that machine.

The 8080 front end has an MT command which boots from a tape. It first reads the microcode RAM file. Next it reads a boot block, which is executed on the KS10.

Of course, KLH10 would have to skip the microcode. But it would be nice if it could pick out the boot block and run that.

[larsbrinkhoff]

@Rhialto I did try the klt20/mtboot.sav file, but it doesn't work with the ITS configuration. I believe the IO instructions are incompatible with the ITS MUUOs.

I will try extracting the boot block from an ITS tape, and run that. But it would be nice if this functionality was built into KLH10. That would be closer to what the actual KS10 front end did.

[Rhialto]

@larsbrinkhoff Ok, that sounds reasonable, but here we're getting into territory I'm less familiar with. (I worked on pretty much the other end of the emulation: connecting the network stuff to NetBSD). And I won't have so much time in the near future since I'm starting a new job. So in other words: patches are gladly considered!

[brouhaha]

I didn't realize you were working with the KS10. I don't know very much about KS10 operations; my KS10 hardware is too flaky to even load the diagnostics. Your description of skipping the microcode and reading the boot block sounds like a good plan. After the 8080 firmware loads the first block of the second file at 1000, it sets loc 36 to the base I/O address of the RH11, 37 to the unit number, and 40 to the density.