[Simh] KA/KI READIN mode

[Timothe Litt]

On 23-Jan-17 06:40, Lars Brinkhoff wrote:
> Timothe Litt wrote:
>> Readin mode for the PTR (KA10/KI10) sets the reader to (hardware)
>> binary mode, reads one IOWD, does a BLKI until exahusted, and XCTs the
>> last word loaded.
> Was it possible to use readin mode with disk controllers?
With DECtape (almost a disk), yes.  Not with (most) conventional
rotating disks.
> The reason I ask is that ITS DSKDMP seems to include code for a disk
> boot block, but it's a bit of mystery how it was used, if at all.  ITS
> people say the KA machines were cold started using paper tape.
>
The issue with most conventional rotating disks is that they used DF10
data channels for DMA, and the IOB RDI signal doesn't set them up.

Readin works by the processor executing a DATA <dev>, 0, then BLKI
<dev>, 0 until the BLKI expires (e.g. doesn't 'skip' - LH of 0 becomes
0).  The last word is XCT'd.  <dev> comes from the console switches.

The disks don't transfer data with DATAI/BLKI ... so it can't work -
well, mostly.

Readin devices that do work are the PTR (104), DTC (320/330) and TMC
(340/350).  RH10 (170/174) is special.

The Massbus spec reserves sector 0 (of track 0, cyl 0) for a boot
block.  The RH10 (gates were cheaper) will use it to boot off the
switches; it holds a small program that sets up the channel to read
blocks 4-7.  I believe the hardware responds to "BLKI" when in readin
mode - it doesn't normally. 

The RS04 apparently also had a readin block (I never used an RS04.)

For some details, see WTBOOT.MAC
(http://pdp-10.trailing-edge.com/de-10-omona-v-mc9/01/wtboot.mac.html) &
BOOTS.MAC

The usual way that a KA/KI was booted was from PTR - PTR would hold
boots, which knew to read the disk.  Later monitors (starting around
700) had a smarter bootstrap (BOOT, written by Chuck OToole) in blocks
4-7, so  that would be read by a paper tape & started.  [Boot knew how
to do crash & continue dumps, load device microcodes, etc.But most
important, it read more than one block at a time, making it blindingly
fast.]  Later, BOOT was combined with BOOTM (the magtape boostrap) - on
the KL, the boostrap lives on the -11's file system, so size wasn't an
issue. 

Lazy people made use of the DECtape hardware bootstrap to load BOOTS -
loading a DECtape is a lot less fussy than a paper tape.  On DECtape,
blocks 0 -2 held the bootstrap.  If booting from DECtape (mostly
diagnostics in later years), the bootstrap would be DTBOOT, which knows
how to navigate a DECtape file system.

For (industry) magtape on the TM10a/b, the first record was read - the
controller rewinds, sets core-dump format  & 556 BPI on unit 0.  The
TM10B in readin mode doesn't use the DF10.

ITS might have used a paper tape bootstrap that loaded a disk bootstrap
from the boot block...or you may be seeing support for the Massbus
disks.  [I never operated, and very rarely used, ITS.]



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20170123/0b617696/attachment.bin>