On 6/24/2019 11:31 PM, Lars Brinkhoff wrote:
Hello,
Some of DEC's disks allow reading and writing the sector headers. ITS'
disk formatting program, SALV (the Salvager), uses this to make a new
file structure on a pack, and to verify its integrity.
This isn't fully supported by SIMH. The file PDP10/pdp10_rp.c has the
comment "23-Aug-01 RMS Added read/write header stubs for ITS", and the
stub is in "case FNC_WRITEH" in rp_svc. It's a no-op that just sets the
DONE flag.
What is supposed to happen is that SALV wants to write two header words
with geometry information and then the sector data with a particular bit
pattern. The verification phase reads back and checks the bit pattern.
Since those bits aren't written, the verification fails.
This isn't so bad since SALV offers to skip the verification. But now
this has come up again using Rich Cornwell's upcoming KA10 addition to
SIMH. The KA10 version of SALV does the same with an RP04 disk, but
does not have the option to skip the verification. SALV also writes
some information to the key fields in the headers, which is later read
back.
I'm wondering what your opinions are reagarding this? I see some options:
1. Do not change SIMH. Patch SALV to skip the verification. Obviously
this is quite quick and painless, but leaves me with a slightly
dissatisfied feeling. Some historical software isn't running properly.
2. Add header words to the disk image file. An incompatible change, but
should of course be optional.
3. Store header words out of band somehow. Last in the image file?
In another file?
I understand the case for making changes to SIMH is quite weak if
running SALV is the one and only use case. Are there any other programs
that reads or writes the headers?
I dealt this that issue a bit when I was writing the RP06 disk drive
controller and disk emulator for the KS10 FPGA: a number of the RP06
diagnostics fail because they attempt to read/write to the sector header.
One thought that should help: SIMH stores 36-bit data inside a 64-bit
data word. There is plenty of unused whitespace inside the existing disk
image. There is no reason for an incompatible change.
In the end, I just used a (volatile) RAM buffer to store the sector
header in the FPGA and that was good enough for the DSRPA diagnostic.
Obviously, the contents of the sector header is not portable between
disk types. In fact, the RP06 has a different sector header depending if
the disk is formatted for 16-bit (PDP11) or 18-bits (PDP10).
The other source of diagnostic failures involved the testing of the disk
drive's Error Correcting Code (ECC) hardware. Funny enough, I picked a
book (published by MIT Press in 1960) out of the trash at work a couple
of months ago that fully described the "Fire Code" ECC of these disk
drives. Maybe that will get revisited.
Rob Doyle
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
