On 11/18/17 4:53 PM, Clem Cole wrote:
On Sat, Nov 18, 2017 at 4:07 PM, Will Senn <will.senn(a)gmail.com
<mailto:will.senn@gmail.com>> wrote:
I thought disk (RK05) and tape (magtape) blocks were different...
For simh they are, but not once UNIX sees them.
Physically 7/9-tapes were variable formatt
ed and could have multiple 'files' on them. UNIX reveals all of this
to user (as do most OSs), so you need put in the simh 'virtual' tape
format support for the size of the 'blocks' and all of the extra
things that the HW supports.
But after the simh 'mounts' the 'virtual tape file' on the host when
it reads the 'tape', simh strips the meta-data out and presents on the
blocks to the OS. Or on write, simh takes the raw blocks, adds the
simulated metadata and writes that to host file system as a 'virtual
tape file.'
In the old days disks physically could also be different formats.
But the 'controller' was used to format the disk. Each disk block
included metadata that the controller used. On DEC (and most other
systems of the day), the disk controller had some way to set this up,
usually with the diagnostic system. The OS saw the disk after
formatting (as we do now). The diagnostics would have decided how
big a block was etc... DEC standardized on 512 bytes per block.
simh could have taken the approach like disks, and then 'virtual
disks' would need the meta data; but could have supported all sorts of
file formats (like Apollo's and Xerox's). But the simulated disk
controller would then need to handle the meta data.
Since, most OSs just looked at disk as 'block streams' simh only needs
to provide for the OS to work properly, is map a UNIX file of bytes
into 512 byte blocks. This works for most OSs. As I said, it will
not work for Aegis or any of the Xerox systems which put some of what
the OS normally did in the microcode of the disk controller.
Thanks, Clem, this is very helpful information. I have a better sense
now of what's going on.
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF