The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: [TUHS] Determining what was on a tape back in the day
Date: Sun, 19 Nov 2017 12:49:19 -0500 (EST)	[thread overview]
Message-ID: <20171119174919.166D018C0F5@mercury.lcs.mit.edu> (raw)

    > From: Will Senn

    > I think I understand- the bytes that we have on hand are not device
    > faithful representations, but rather are failthful representations of
    > what is presented to the OS. That is, back in the day, a tape would be
    > stored in various formats as would disks, but unix would show these
    > devices as streams of bytes, and those are the streams of bytes are what
    > have been preserved.

Yes and no.

To start with, one needs to differentiate three different levels; i) what's
actually on the medium; ii) what the device controller presented to the CPU;
and iii) what the OS (Unix in this case) presented to the users.

With the exception of magtapes (which had some semantics available through
Unix for larger records, and file marks, the details of which escape me - but
try looking at the man page for 'dd' in V6 for a flavour of it), you're correct
about what Unix presented to the users.


As to what is preserved; for disks and DECtapes, I think you are broadly
correct. For magtapes, it depends.

E.g. SIMH apparently can consume files which _represent_ magtape contents (i,
above), and which include 'in band' (i.e. part of the byte stream in the file)
meta-data for things like file marks, etc. At least one of the people who
reads old media for a living, when asked to read an old tape, gives you back
one of these files with meta-data in it. Here:

  http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tools/rdsmt.c

is a program which reads one of those files and convert the contents to a file
containing just the data bytes. (I had a tape with a 'dd' save of a
file-system on it, and wanted just the file-system image, on which I deployed
a tool I wrote to grok 4.2 filesystems.)


Also, for disks, it should be remembered that i) and ii) were usually quite
different, as what was actually on the disk included thing like preambles,
headers, CRCs, etc, none of which the CPU usually could even see. (See here:

  http://gunkies.org/wiki/RX0x_floppy_drive#Low-level_format

for an example. Each physical drive type would have its own specific low-level
hardware format.) So what's preserved is just an image of what the CPU saw,
which is, for disks and DECtapes, generally the same as what was presented to
the user - i.e. a pile of bytes.

     Noel


             reply	other threads:[~2017-11-19 17:49 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-19 17:49 Noel Chiappa [this message]
2017-11-19 18:35 ` Arthur Krewat
  -- strict thread matches above, loose matches on Subject: below --
2017-11-20 19:42 Noel Chiappa
2017-11-20 17:00 Noel Chiappa
2017-11-20 16:01 Noel Chiappa
2017-11-20 17:37 ` Will Senn
2017-11-19 20:46 Steve Simon
2017-11-19 18:45 Noel Chiappa
2017-11-19 13:41 Noel Chiappa
2017-11-19 14:55 ` Clem cole
2017-11-19 21:00   ` William Corcoran
2017-11-19 21:19     ` Ron Natalie
2017-11-19 22:00       ` Dave Horsfall
2017-11-19 22:38         ` Lyndon Nerenberg
2017-11-19 22:40         ` Ronald Natalie
2017-11-19 23:41           ` Dave Horsfall
2017-11-20  1:02             ` Ronald Natalie
2017-11-20  1:18               ` Dave Horsfall
2017-11-20 18:12                 ` Random832
2017-11-20 23:22                   ` Dave Horsfall
2017-11-20 23:35                     ` William Pechter
2017-11-21  0:01                     ` Ron Natalie
2017-11-20 19:02   ` Paul Winalski
2017-11-19 14:55 ` Will Senn
2017-11-18 19:23 Noel Chiappa
2017-11-18 21:32 ` Will Senn
2017-11-18 21:49   ` Warren Toomey
2017-11-18 18:34 Noel Chiappa
2017-11-18 18:37 ` Ronald Natalie
2017-11-18 18:40   ` Ronald Natalie
2017-11-18 21:51   ` Dave Horsfall
2017-11-18 21:07 ` Will Senn
2017-11-18 22:53   ` Clem Cole
2017-11-19  1:47     ` Will Senn
2017-11-18 16:39 Will Senn
2017-11-18 18:57 ` Clem Cole
2017-11-18 20:03   ` Don Hopkins
2017-11-18 22:37     ` Dave Horsfall
2017-11-18 23:16       ` Don Hopkins
2017-11-18 23:35         ` Arthur Krewat
2017-11-19  0:35           ` Steve Nickolas
2017-11-19  0:42             ` Don Hopkins
2017-11-19  1:04               ` Clem cole
2017-11-19 16:20                 ` Arthur Krewat
2017-11-20  2:33         ` Lawrence Stewart
2017-11-18 21:26   ` Will Senn
2017-11-18 22:39     ` Clem Cole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171119174919.166D018C0F5@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).