I'm fairly sure the disk in the "v0" listings is a precursor of the RB09, with half the capacity. The read vs write bit is the correct location. The code to convert from a disk block to a disk address first divides by 80 (the RB09 has 80 sectors per track) and then "BCD-izes" both the quotient (the track number) and the remainder (the sector number). The words/sector is 64, which matches the RB09 as well. The IOTs in the listing also match the RB09. The transfer count is always -64 and is loaded with IOT 707124. The transfer address is loaded with IOT 707142.

The "half capacity" comes from the limit check on the disk address, which is 2 <= da <= 7999. An RB09 has 200*80 = 16000 sectors. The disk in "Unix v0" has only 8000. Based on the way the code does the BCD conversion, it is expecting only two decimal digits for the track number and the sector number. This seems entirely plausible, because the RB09 was a head-per-track disk with heads on both sides of the platter. A predecessor (or lower cost model) with heads on only one side would be 8000 sectors.

There is no standard disk with the PDP-7 simulator, but it's trivial to add an "RB07" and provide a half size option: a hell of a lot easier than it probably was in real life. Information on the RB09 is scarce (just a section in the PDP-9 Handbook), but it was clearly a buyout product, not a DEC design. DEC never did a BCD-addressed disk in its history.

The PDP-7 for Unix v0 must have an EAE, but it does not require automatic priority interrupts. The PI chain is a bit difficult to decode, because of all the cross-outs and hand-written notes, but it appears to be:

clsf - clock
dssf - disk
ksf - console keyboard
tsf - console printer
rsf - paper tape reader
psf - paper tape punch
crsf - card reader

So a Unix v0 emulation apparently will need a card reader but not DECtape. Both PDP-7 card readers used the same instructions; they varied only in performance.

The system call is the CAL instruction.

Unix v0 does not, surprisingly, appear to use the extended memory function or the protection trap that came with it. EEM (enter extend mode) isn't even defined. This would seem to imply it ran in 8KW of memory.

/Bob Supnik








_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh

Reply via email to