[TUHS] Determining what was on a tape back in the day

[Will Senn]

On 11/18/17 4:53 PM, Clem Cole wrote:
>
>
> On Sat, Nov 18, 2017 at 4:07 PM, Will Senn <will.senn at gmail.com 
> <mailto:will.senn at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/13ded55a/attachment.html>