/dev/makefile on the V7 distribution tape (or at least the
unpacked image I have that I believe to be same) says:
ht:
/etc/mknod mt0 b 7 64
/etc/mknod mt1 b 7 0
/etc/mknod rmt0 c 15 64
/etc/mknod rmt1 c 15 0
/etc/mknod nrmt0 c 15 192
/etc/mknod nrmt1 c 15 128
chmod go+w mt0 mt1 rmt0 rmt1 nrmt0 nrmt1
According to /usr/sys/dev/ht.c, the minor device
number was used as follows:
minor(dev) & 07 slave unit number
minor(dev) & 070 controller unit number
minor(dev) & 0100 tape …
[View More]density: set == 800 bpi, clear 1600
minor(dev) & 0200 no-rewind flag
It takes some digging in the source code (and the PDP-11
Peripherals Handbook) to understand all this numerology.
In most of the code, minor(dev) & 077 is just treated as
a unit number (fair enough). The use of 0200 appears only
as a magic number in htopen; that of 0100 only as a magic
number in htstart, and that only implied: the test is
not minor(dev) & 0100, but
unit = minor(bp->b_dev) & 0177;
if(unit > 077)
Not so bad when the whole driver is only 376 lines of code,
but it wouldn't have hurt to make it 400 lines if that
meant fewer magic numbers.
Anyway, what all this means is that /dev/*mt0 and /dev/*mt1
both actually meant slave 0 on TU16 controller 0, but mt0
was 800 bpi and mt1 1600 bpi. Hence, I would guess, tar's
default to mt1.
My first exposure to the insides of UNIX was in the High
Energy Physics group at Caltech. Some of our systems had
multiple tape drives and every drive supported multiple
densities, so we invented for ourselves a system like that
many other sites invented, with names like /dev/rmt3h to
mean the third tape drive at high density. (Hence the
USG naming scheme of /dev/rmt/3h and the like--not that
we taught it to them, just that many places had the same
idea.)
Our world wasn't nearly as exciting as that of our neighbors,
across the building and three floors down, in the Space
Radiation Laboratory. They had a huge room full of racks
of magtapes full of data from satellites, and many locally-
written tools for extracting the data so researchers could
work on it. The hardware was an 11/70 with eight tape drives,
and at any given time at least half the the drives would be
spinning. One of the drives was seven-track rather than
nine-track, because some of the satellite data had been
written in that format.
Fair disclosure: I had a vague memory that the `drive number'
in the device name had been recycled for other purposes,
but couldn't remember whether it was density or something
else. (I'm a little surprised none of the other old-timers
here remembered that, but maybe I worked with tapes more than
them.) But I had to dig into the source code for the details;
I didn't remember all that. And I did have to climb up to the
high shelf in my home office for a Peripherals Handbook to
understand the magic numbers being stuffed into registers!
Norman Wilson
Toronto ON
[View Less]
> I have no memory of why Ken used mt1 not mt0. Doug may know.
I don't know either. Come to think of it, I can't remember ever
using tar without option -f. Direct machine-to-machine trasfer,
e.g. by uucp, took a lot of business away from magtape soon
after tar was introduced. Incidentally, I think tar was written
by Chuck Haley or Greg Chesson, not Ken.
Doug
On 2015-12-12 07:16, William Pechter<pechter(a)gmail.com> wrote:
>
> Warren Toomey wrote:
>> >On Sat, Dec 12, 2015 at 03:54:16PM +1100, Peter Jeremy wrote:
>>> >>Also, I've seen suggestions that there's a 2.11BSD patch later than
>>> >>447 but I can't find anything "official" andwww.2bsd.com is either
>>> >>down or inaccessible from all the systems I have access to. Does
>>> >>anyone know if 448 or later were …
[View More]released? And given the issues with
>>> >>www.2bsd.com would someone be willing to mirror it (assuming we can
>>> >>got a copy of it)?
>> >[ Back to a real keyboard ]. Yes I'd be very happy to mirror 2bsd.com.
>> >Does anybody know what's happened to Steven Schultz?
>> >
>> >Cheers, Warren
>> >_______________________________________________
>> >TUHS mailing list
>> >TUHS(a)minnie.tuhs.org
>> >http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> Last patch is 447 from June 2012.
Uh. No. 447 is from December 31, 2008.
See /VERSION in the patch set, which holds the patch version and date
for the patch.
And I did an unofficial 448 in 2010, which I have tried to spread, and
which I suspect is the patch referred to above...
> I can get to the site just fine... pasted the patch below if it helps
> anyone.
> I haven't heard anything about him. Haven't worked at the same company
> since the early 1990's...
I used to talk with him a lot in the past, but have not been able to
raise him, and haven't seen anything from him in over 5 years... No idea
what he is up to nowadays...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
[View Less]
> From: Random832
> Interestingly, the SysIII sum.c program, which I assume yields the same
> result for this input, appears to go through the whole input
> accumulating the sum of all the bytes into a long, then adds the two
> halves of the long at the end rather than after every byte.
That's the same hack a lot of TCP/IP checksums routines used on machines with
longer words; add the words, then fold the result in the shorter length at the
end. The one I wrote …
[View More]for the 68K back in '84 did that.
> This suggests that the two programs would give different results for
> very large files that overflow a 32-bit value.
No, I don't think so, depending on the exact detals of the implementation. As
long as when folding the two halves together, you add any carry into the sum,
you get the same result as doing it into a 16-bit sum. (If my memory of how
this all works is correct - the neurons aren't what they used to be,
especially late in the day... :-)
> Also, if this sign extends, then its behavior on "negative" (high bit
> set) bytes is likely to be very different from the SysIII one, which
> uses getc.
I have this bit set that in C, 'char' is defined to be signed, and
furthermore that when you assign a shorter int to a longer one, the sign is
extended. So if one has a char holding '0200' octal (i.e. -128), assigning it
to a 16-bit int should result in the latter holding '0177600' (i.e. still
-128). So in fact I think they probably act the same.
Noel
[View Less]
> From: Will Senn
> I noticed that the sum utility from v6 reports a different checksum
> than it does using the sum utility from v7 for the same file.
> ... does anyone know what's going on here?
> Why is sum reporting different checksum's between v6 and v7?
The two use different algorithms to accumulate the sum (I have added comments
to the relevant portion of the V6 assembler one, to help understand it):
V6:
mov $buf,r2 / Pointer to buffer in R2
2: …
[View More]movb (r2)+,r4 / Get new byte into R4 (sign extends!)
add r4,r5 / Add to running sum
adc r5 / If overflow, add carry into low end of sum
sob r0,2b / If any bytes left, go around again
Read the description of MOVB in the PDP-11 Processor manual.
V7:
while ((c = getc(f)) != EOF) {
nbytes++;
if (sum&01)
sum = (sum>>1) + 0x8000;
else
sum >>= 1;
sum += c;
sum &= 0xFFFF;
}
I'm not clear on some of that, so I'll leave its exact workings as an
exercise, but I'm pretty sure it's not a equivalent algorithm (as in,
something that would produce the same results); it's certainly not
identical. (The right shift is basically a rotate, so it's not a straight sum,
it's more like the Fletcher checksum used by XNS, if anyone remembers that.)
Among the parts I don't get, for instance, sum is declared as 'unsigned',
presumably 16 bits, so the last line _should_ be a NOP!? Also, with 'c' being
implicitly declared as an 'int', does the assignment sign extend? I have this
vague memory that it does. And does the right shift if the low bit is one
really do what the code seems to indicate it does? I have this bit that ASR on
the PDP-11 copies the high bit, not shifts in a 0 (check the processor
manual). That is, of course, assuming that the compiler implements the '>>'
with an ASR, not a ROR followed by a clear of the high bit, or something.
Noel
[View Less]
Ok, it definitely sounds like the v6tar source is around somewhere so
if someone could point me in the right direction...
I've only seen the binary, and I can't remember where I got it.
Mark
All,
While working on the latest episode of my saga about moving files
between v6 and v7, I noticed that the sum utility from v6 reports a
different checksum than it does using the sum utility from v7 for the
same file. To confirm, I did the following on both systems:
# echo "Hello, World" > hi.txt
# cat hi.txt
Hello, World
Then on v6:
# sum hi.txt
1106 1
But on v7:
# sum hi.txt
37264 1
There is no man page for the utility on v6, and it's assembler. On v7,
there's a manpage and …
[View More]it's C:
man sum
...
Sum calculates and prints a 16-bit checksum for the named
file, and also prints the number of blocks in the file.
...
A few questions:
1. I'll eventually be able to read assembly and learn what the v6
utility is doing the hard way, but does anyone know what's going on here?
2. Why is sum reporting different checksum's between v6 and v7?
3. Do you know of an alternative to check that the bytes were
transferred exactly? I used od and then compared the text representation
of the bytes on the host using diff (other than differences in output
between v6 and v7 related to duplicate lines, it worked ok but is clunky).
Thanks,
Will
[View Less]
All,
In my exploration of v6, I followed the advice in "Setting up Unix -
Seventh Edition" and copied v6tar from v7 to v6. Life is good. However,
tar is using mt1 and it is hard coded into the source, tar.c:
char magtape[] = "/dev/mt1";
As the subject line suggested, I have two questions for those of you who
might know:
1. Why is it hard coded?
2. Why is it the second device and not the first?
Interestingly, it took me a little while to figure out it was doing this
because I …
[View More]didn't actually move files between v6 and v7 until today.
Before this my tests had been limited to separate tests on v6 and v7
along the lines of:
cd /wherever
tar c .
followed by
tar t
list of files
cd /elsewhere
tar x
files extracted and matching
What it was doing was writing to the non-existant /dev/mt1, which it
then created, tarring up stuff, and exiting. Then when I listed the
contents of the tarfile, or extracted the contents, it was successful.
But, when I went to move the tape between v6 and v7, the tape (mt0) was
blank, of course. It was at this point that I followed Noel's advice
and "Used the source", and figured out that it was hard-coded as you see
above.
Thanks,
Will
[View Less]
That's exactly right. ld performs the same task as LOAD did on BESYS,
except it builds the result in the file system rather than user
space. Over time it became clear that "linker" would be a better
term, but that didn't warrant canning the old name. Gresham's law
then came into play and saddled us with the ponderous and
misleading term, "link editor".
Doug
> My understanding, which predates my contact with Unix, is that the
> original toochains for single-job machines consisted of the …
[View More]assembler
> or compiler, the output of which was loaded directly into core with
> the loader. As things became more complicated (and slow), it made
> sense to store the memory image somewhere on drum, and then load that
> image directly when you wanted to run it. And that in some systems
> the name "loader" stuck, even though it no longer loaded. Something
> like the modern ISP use of the term "modem" to mean "router". But I
> don't have anything to back up this version; comments welcome.
[View Less]