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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
