9 Dec
2015
9 Dec
'15
6:55 a.m.
Ok, I can make a few remarks about v6tar and ar and dd.
I've never been able to transfer any file larger than 64K to Unix V5 or V6.
Smaller than 64K seems to work fine. I'm using the same command on V5 and V6:
dd if=/dev/mt0 of=cont.a bs=1 count=90212
And I'll get:
24676+0 records in
24676+0 records out
Now, if we take 90212 and subtract 65536 we get 24676 bytes. So there
definitely seems to be some 64K limit here and I don't think it's just
a v6tar limitation.
I compiled the kernel with m45.s on V6 and mch.s on V5. I also don't
recall seeing any file on V5 or V6 larger than 65536 bytes, but it's
possible I've overlooked one.
My workaround solution was to simply keep tar files and archive files
under 64K but I would be interested to hear of a better solution.
Mark
On 12/9/15, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
From: Noel
Chiappa
the most likely is that 'v6tar' is
linked to be split I+D, and your
V6
emulation is on a machine that doesn't have
split I+D (e.g. an 11/40)
Now that I think about it, the linked systems that are part of the V6
distro
tape are all linked to run on an 11/40. They will boot and run OK on a more
powerful machine (/45 or /70), but they will act like they are on a /40 -
i.e. no split I+D support/use (user or kernel). So to get split I+D
support,
you need to build a new Unix binary, with m45.s instead of m40.s. If you
haven't done that, that's probably what the problem is.
Aside: V6 comes in two flavours: no split I+D at all, or split I+D in both
the kernel and user. For some reason that I can't recall, we actually
produced an 'm43.s', BITD at MIT, which ran the kernel in non-split-I-D,
but
supported split I-D for the users.
I wish I could remember why we did this - it couldn't have been to save
memory (the machine didn't have a great deal on it when this was done -
although I have this vague memory that that was why we did it), because
running split I+D in the kernel does not, I think, use any more physical
memory (provided you don't fiddle with the parameters like the number of
buffers) than running non-split. Or maybe it does?
One possible reason was that the odd layout of memory with split I+D in the
kernel made debugging kernel code harder (we were doing a lot of kernel
hacking to support early networking work); another was that we were just
being
conservative, didn't need to extra space in the kernel that I+D allowed,
and
so didn't want to run it.
Noel
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs