19 Nov
2017
19 Nov
'17
12:34 a.m.
From: Will Senn
So, I came across this tape:
...
I was curious what was on it
'od' is your friend!
If you look here:
http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#dumpf
there's a thing which is basically 'od' and 'dd' rolled in
together, which
allows you to dump any block you want in a variety of formats (ASCII, 16-bit
words in octal [very useful for PDP-11 binary], etc). I wrote it under CygWin,
for Windows, but it only uses the StdIO library, and similar programs (e.g. my
usassembler) written that way work fine under Losenux.
Try downloading it and compiling it - if it doesn't work, please let me know;
it'd be worth fixing it so it does work on Linux.
after some fiddling, I figured out that I could get a
boot prompt (is
that actually from the tape?)
The 0th block does seem to contain some PDP-11 binary - a bootstrap of some
sort. I'll look in more detail in a bit.
I was thinking this was a sixth edition install tape
of some sort, but
if it is, I'm not able to figure it out.
From what I can see, it's probably a tp-format
tape: the 1st block contains
some filenames which I can see in an ASCII dump of it:
speakez/sbrk.s
dcheck.c
df.c
intel/as80.c
intel/optab.8080
v7 and look at its content using tm or tp, but then I
realized that I
didn't have a device set up for TU56
You don't need to mount it on DECTape drive - it's just blocks. Mount it as
an RK05 image, or a magtape, or whatever.
When you received an unmarked tape back in the day,
how did you go about
figuring out what was on it?
Generally there would have been some prior communication, and the person
sending it would have told you what it was (e.g. '800 bpi tar', or whatever).
What advice would you give a future archivist to help
them quickly
classify bit copies of tapes :).
Like I said: "'od' is your friend!"!! :-)
Noel
19 Nov
19 Nov
12:37 a.m.
New subject: Determining what was on a tape back in the day
We commonly used “ar” to write DECtapes (TU58) back in the day. If the first block has a
list of filenames, I’m betting that’s what it is!
12:40 a.m.
New subject: Determining what was on a tape back in the day
And the other more likely option is the “tp” command. It too (unlike the later tar), put
the filenames at the beginning of the tape.
On Nov 18, 2017, at 1:37 PM, Ronald Natalie
<ron(a)ronnatalie.com> wrote:
We commonly used “ar” to write DECtapes (TU58) back in the day. If the first block has
a list of filenames, I’m betting that’s what it is!
3:51 a.m.
New subject: Determining what was on a tape back in the day
On Sat, 18 Nov 2017, Ronald Natalie wrote:
We commonly used “ar” to write DECtapes (TU58) back in
the day. If the
first block has a list of filenames, I’m betting that’s what it is!
Or ye olde "tp" format? 'Twas the precursor of "tar", and I
dimly recall
that it was wriiten for the Ducktapes (our old 11/40 had just about
everything except that).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
3:07 a.m.
New subject: Determining what was on a tape back in the day
On 11/18/17 12:34 PM, Noel Chiappa wrote:
I thought disk (RK05) and tape (magtape)
blocks were different...
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
If you look here:
http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#dumpf
Try downloading it and compiling it - if it doesn't work, please let me know;
it'd be worth fixing it so it does work on Linux.
Works fine. Thanks.
The 0th block does seem to contain some PDP-11 binary
- a bootstrap of some
sort. I'll look in more detail in a bit.
Cool. I don't quite no how to
investigate this other than to pore
through the pdp11/40 instruction manual.
From what I can see, it's probably a tp-format
tape: the 1st block contains
some filenames which I can see in an ASCII dump of it:
speakez/sbrk.s
...
Well lookit that. I see it now, too :)
v7 and look at
its content using tm or tp, but then I realized that I
didn't have a device set up for TU56
You don't need to mount it on DECTape drive - it's just blocks. Mount it as
an RK05 image, or a magtape, or whatever. 
4:53 a.m.
New subject: Determining what was on a tape back in the day
On Sat, Nov 18, 2017 at 4:07 PM, Will Senn <will.senn(a)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.
Clem
7:47 a.m.
New subject: Determining what was on a tape back in the day
On 11/18/17 4:53 PM, Clem Cole wrote:
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
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
2590
days inactive
2591
days old
6 comments
5 participants
participants (5)
-
Clem Cole -
Dave Horsfall -
jnc＠mercury.lcs.mit.edu -
Ronald Natalie -
Will Senn