From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.senn@gmail.com (Will Senn) Date: Sat, 18 Nov 2017 19:47:25 -0600 Subject: [TUHS] Determining what was on a tape back in the day In-Reply-To: References: <20171118183451.CF48218C0F0@mercury.lcs.mit.edu> <367c50cf-8bee-e050-1c0c-0bd960621f37@gmail.com> Message-ID: <1551fcd0-8870-438c-aa0b-9694083be764@gmail.com> On 11/18/17 4:53 PM, Clem Cole wrote: > > > On Sat, Nov 18, 2017 at 4:07 PM, Will Senn > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: