[Simh] PDP10 RP06 parameters

[Timothe Litt]

On 13-Apr-15 08:20, Bob Supnik wrote:
> Your original calculation is correct. There are 815 cylinders, 19
> heads, 20 sectors, and in the simulator, the sectors are 128 64b words
> (or 1024 bytes).
Yes - you can also look at them as 256 18-bit bytes packed into 32-bit
words on-disk, which is closer to how the RH11/UBA/Unibus see them.  The
resulting size on disk is identical either way.
> The the reason for the discrepancy is simple: the last five tracks
> haven't been written by software. SimH data files are only as long as
> the data written; the rest is assumed to be zero.
Yes
> On the PDP11, disk files for older disks usually get extended to full
> length by writing a "bad block" table at the end as part of
> initialization. The PDP10 didn't follow this practice. It used
> differently formatted disk packs, to cope with the 36b/32b word size
> difference.
This collection of facts, while correct, doesn't quite explain what's
going on.  I'll attempt to fill in the blanks.

The highest block written to an RPxx by a PDP-10 depends on a number of
variables; for example with Level D (TOPS-10), the placement of SAT
blocks as well as actual file data allocations.  SAT placement is
selectable when a structure is defined; beginning, middle, or end of the
disk.  Middle is the usual case, as it reduces average seek time for an
allocation. 

It's quite possible to have SimH PDP-10 RP06 containers with less that
810 cylinders  allocated.  As Bob wrote, unallocated space reads as
zeros.  So the 810 full cylinders that Rob saw is just a happy coincidence.

The PDP-11 & VAX, as Bob wrote, put the bad block table at the end of
the disk when the file structure is initialized, so writing the bad
block table forces allocation of the full disk size in SimH.

On the PDP-10 bad blocks are accounted for in the BAT blocks, which like
the HOM blocks are common to the formats used by TOPS-10 and TOPS-20. 
The BAT blocks are in low-numbered blocks (^D2 & ^D11, adjacent to the
HOM blocks).  Thus they don't contribute to the allocated size of a SimH
disk. 

As I previously wrote, the 36-bit OSs reserved a fixed number of
cylinders for diagnostic use.  For the RP06, it's 5.  My note included
the table for the other MASSBUS disk types supported by TOPS-10.  These
are not written as part of initializing the file system.

As it's unusual to run the diagnostics under SimH (either under the OS
or stand-alone), the SimH containers' highest tracks aren't written, and
so are usually not allocated in SimH containers.

Thus, one can have SimH disk container files that have allocated sized
anywhere from a few MB to the full size of the emulated disk.

The format difference between 16 and 18 bit disks is the number of bytes
per sector; 512 for PDP-11/VAX, 576 for the PDP-10.  This results in a
different number of sectors per track; 22 for PDP-11/VAX, 20 for the
PDP-10.  The number of cylinders doesn't vary.  The hardware packs the
data more densely than SimH in 18-bit mode.  The format is defined by
the media; with the real hardware, the sector size and sectors/track is
selectable (F22 in the offset register), and TOPS-10 provides the means
for accessing 16-bit formatted disks.  SimH doesn't support this.  In
theory, a given disk could have a mixture of 20 and 22 sector tracks,
but I'm not aware of any software (including diagnostics) that attempted
to support this as the details are very, very tricky.  Note that despite
being a PDP-11, RSX20-F wrote its FILES-11 ODS-1 structures on 18-bit
(20 sector) tracks.

As another bit of trivia, technically BAT (Badblock Allocation Table) is
the name of the in-memory structure that the monitor uses to keep track
of bad blocks.  BAF (Badblock allocation file) is the proper name of the
blocks on disk.  But, the magic number written in the blocks is sixbit
/BAT/, so everyone used the name "BAT blocks" everywhere except for the
Level D spec and some corners of the monitor...

For Rob's purposes, the full hardware size of the disk - 815 x 19 x 20
is the right geometry for his emulated disks.  22 sector mode is only of
interest if he plans to exchange data with someone who does a pdp-11 or
VAX FPGA :-)

How to pack the sectors is an implementation choice; FPGAs give more
flexibility than SimH had, although there are atomicity considerations. 

This communication may not represent my employer's views,
if any, on the matters discussed. 



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