[Simh] Unix v0 disk is an RB09 or equivalent

[Bob Supnik]

I've gone through the disk IO routines line by line, with this result: 
while Unix confines reads and writes to blocks <= 79999, it maps those 
blocks to the SECOND 512KW of the the disk. See the attached analysis. 
So the Unix v0 disk is an RB09 equivalent, and the RC09 on the field 
service listings is probably an RB09. The reason for the different names 
remains unexplained. (The drive was made by Burroughs - thanks to Tim 
Litt for finding the reference.)

dsksav copies side 1 to side 0, and dskres does the reverse, so side 0 
was used as a backup for the main disk image: handy if a programming 
experiment wrecked the disk image.

/Bob Supnik
-------------- next part --------------
Analysis of the UNIX v0 disk driver, or,
Why the Unix v0 disk is, in fact, an RB09, or,
The RB09 and the RC09 are the same thing

To start, remember that the Unix v0 disk (and the RB09
and the RC10/RD10) are BCD addressed, with 80 sectors
per track and 200 tracks. The disk is dual sided, with
100 sectors on each side. So the disk parameters are:

sector # = 0 to 79, in BCD format
track # = 0 to 199, in BCD format

The track # goes in bits<1:9>, the sector # in <10:17>.
Thus, bit<1> = 0200000 is the "dividing line" between
the two sides of an RB09.

The Unix v0 disk driver has three layers:

dskrd/dskwr - called to read or write a block of data in dskbuf
	The block number is in the AC

diskio - called by dskrd/dskwr to convert the block number
	to a hardware disk address
	It takes an inline argument, the read vs write flag
	The block number is in the AC

dsktrans - called by diskio (and elsewhere, as will be seen)
	to do an actual disk IO operation

Both dskrd and dskwr call betwen to assure that the disk
block number is between 2 and 7999. If it isn't, the system
halts, which is fairly drastic.

diskio executes the following code (I'm using standard PDP7
comments for this - / rather than "):

diskio:	0			/return address stored here
	dac dskaddr		/save block #
	cll			/assure unsigned divide
	idiv			/divide AC
	80			/by 80 (# sectors per track)
	dac 9f+t		/save remainder (sector #)
	lacq			/mq (track #) -> AC
	idiv			/divide AC
	10			/by 10 (for BCD conversion)
	dac 9f+t+1		/save remainder (low digit)
	lls 22			/MQ<14:17> (high digit) -> AC<10:13>
	xor 9f+t+1		/(x)or in low digit
	als 8			/move BCD track # to AC<2:9>
	dac 9f+t+1		/save BCD track #
	lac 9f+t		/get sector #
	idiv			/divide AC
	10			/by 10
	dac 9f+t		/save remainder (low digit)
	lls 22			/MQ<14:17> (high digit) -> AC<10:13>
	xor 9f+t		/(x)or in low digit
	xor 9f+t+1		/(x)or in track #
	xor o200000		/(x)or in 200000 (bit 1)
	dac 9f+t		/save converted disk address
	jms dsktrans		/do actual transfer
	-64			/64 words
	dskbuf			/buffer address
	9f+t			/address of converted disk address
	diskio			/address of pointer to read vs write
	isz diskio		/skip argument
	jmp i diskio		/return

Now there are several points to notice here. First, XOR is used for
inclusive or (the PDP-7 had no IOR instruction). Second, the track
number conversion code would not work if block numbers exceeded
9999; that's why betwen is used to limit check them. Third, and most
critically, is that all disk addresses are pushed up to the SECOND
side of the fixed head disk - that's what the "xor o200000" does.
In short, all disk IO that goes through the dskio layer is confined
to the second 512KW of the disk, and the disk must be a full
RB09. The RC09 on the field services listing is an RB09 equivalent.

As for side 0... routines dsksav, dskres, and dskio have their
own disk IO routines, which allow for explicit control of which side
of the disk is accessed. dsksav copies all of side 1 to side 0, and
dskres does the reverse. (The transfers are done in 640 word increments,
or 10 sectors at a time.) Thus, it appears that side 0 was used
as a backup to the main disk.