> From: Will Senn
> I'm off to refreshing my pdp-11 assembly language skills...
A couple of things that might help:
- assemble mboot.s and 'od' the result, so when you see something that matches
in the dump of the 0th block, you can look back at the assembler source, to see
what the source looks like
- read the boot block into a PDP-11 debugger ('db' or 'cdb' on V6, 'adb' on
V7; I _think_ 'adb' was available on V7, if not, there are some BSD's that
have it) and use that to disassmble the code
> 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.
OK, I had a quick look, and it seems to be a modified version of mboot.s:
I had a look through the rest of the likely files in 'mdec', and I didn't find
a better match. I'm too lazy busy to do a complete dis-assembly, and work out
exactly how it's different, though..
A few observations:
000: 000407 000606 000000 000000 000000 000000 000000 000001
An a.out header, with the 0407 'magic' here performing its original intended
function - to branch past the header.
314: 105737 177560 002375
Some console I/O stuff - this two instruction loop waits for the input
ready bit to be set.
326: 042700 177600 020027 000101 103405 020027 000132 101002
More character processing - the first instruction clears the high bits of R0,
and the next two sets of two instructions compare the contents with two
characters (0101 and 0132), and branch.
444: 000207 005000 021027 000407 001004 016020
460: 000020 020006 103774 012746 137000 005007
This seems like the code that checks to see if the thing is an a.out file
(note the 'cmp *r0, $0407'), but the code is different from that code in
mboot.s; in that, the instruction before the 'clr r0' (at 0446 here) is a
'jsr', whereas in this it's an 'rts pc'. And the code after the 'cmp r0, sp'
and branch is different too. I love the '05007' - not very often you see
502: 012700 177350 012701 177342 012711 000003 105711
Clearly the code at 'taper:' (TC11 version).
So, I came across this tape:
I was curious what was on it, so I read the description at:
UNIX1 PURDUE UNIX TAPES
HARBA1 HARVARD BASIC TAPE 1
HARBA2 HARVARD BASIC TAPE 2
MEGTEK MEGATEK UNIX DRIVER
RAMTEK RAMTEK UNIX DRIVER
Cool, sounds interesting, so I downloaded the unix6.dta file and fired
up simh - after some fiddling, I figured out that I could get a boot
prompt (is that actually from the tape?) if I:
set cpu 11/40
set en tc
att tc0 unix6.dta
At that point, I was stuck - the usual tmrk, htrk, and the logical
corollary tcrk didn't do anything except return me to the boot prompt.
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. I thought I would load the tape
into 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 and even if I did, I didn't know
how to do a dir on a tape - yeah, I know, I will go read the manual(s)
In the meantime, my question for y'all is similar to my other recent
questions, and it goes like this:
When you received an unmarked tape back in the day, how did you go about
figuring out what was on it? What was your process (open the box, know
by looking at it that it was an x rather than a y, load it into the tape
reader and read some bytes off it and know that it was a z, use unix to
read the tape using tm, tp, tar, dd, cpio or what, and so on)? What
advice would you give a future archivist to help them quickly classify
bit copies of tapes :).
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
I don't think we had the Fourth Research Edition Unix Programmer's
Manual available in typeset form. I played a bit with the troff manual
pages on TUHS and managed to typeset it into PDF. You can find the PDF
document at https://dspinellis.github.io/unix-v4man/v4man.pdf.
I modernized the old shell scripts and corrected some minor markup
glitches through commits that are recorded on a GitHub repository:
https://github.com/dspinellis/unix-v4man. The process was surprisingly
smooth. The scripts for generating the table of contents and the
permuted index are based on the original ones. The few problems I
encountered in the troff source had to do with missing spaces after
requests, the ^F hyphenation character causing groff to complain, a
failure of groff to honor .li requests followed by a line starting with
a ., and two uses of a lowercase letter for specifying a font. I wrote
from scratch a script to typeset everything into one volume. I could
not find a shell script for typesetting the whole manual in any of the
Research Editions. I assume the process of running the typesetter was
so cumbersome, error prone, and time-consuming that it was manually
performed on a page-by-page basis. Correct me if I'm wrong here.
It can be hard to visualise what is on a tape when you have no idea
what is on there.
Attached is a simple tool I wrote "back then", shamlessly copying an
idea by Paul Scorer at Leeds Poly (My video systems lecturer).
It is called tm (tape mark).
> From: Arthur Krewat
> For anyone reading old tapes, I implore you to attempt to read data past
> the soft EOT ;)
The guy who read my tape does in fact do that; you'll notice my program has an
option for looking for data after the soft EOT.
> 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:
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:
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.
> From: Will Senn
> So, I came across this tape:
> I was curious what was on it
'od' is your friend!
If you look here:
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:
> 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!"!! :-)
Random memories, possibly wrong.
In 1977/78 I was at udel and had done a fair amount of work on unix but as
a lowly undergrad did not get to go to the Columbia Usenix meeting. Ed
Szurkowski of udel went. Ed was the grad student who did hardware design
for 11s for Autotote (another story) but also stood up a lot of the early
unix 11s at udel starting in 1976, starting with an 11/70. Mike Muus used
to come up and visit us at udel and Mike and Ed would try to ask questions
the other could not answer. Mike always had a funny story or two.
Ed later went to Bell Labs and I lost track of him.
The directions for the MTA were fairly clear: it listed a stop that you
under no circumstances should get off at, and if you did get off at, you
should not go up to the street, lest you never return. This was no joke.
Some places in NY were pretty hazardous in those days.
I *think* this was the meeting where Ken showed up with a bunch of
magtapes, and Ed claimed that, in Ken's word, they were "... found in the
This part I remember well: Ed returning with two magtapes and our desire to
upgrade. We at udel, like many places, had done lots of our own mods to the
kernel, which we wanted to keep. So we ran a diff between trees, and I
wrote a merge with TECO and ed which got it all put together. I later
realized this was a very early form of 'patch', as it used patterns, not
line numbers, to figure out how to paste things back together. I really got
to love regex in those years.
Except for one file: the tools just would not merge them. Ed later realized
there was one key difference that we had not noticed, a missing comment,
namely, the Western Electric copyright notice ...
I'm kinda sorry that our "udel Unix" is lost to the great /dev/null, it
would be interesting to see it now.