I have just spent some time reconciling the differences between Doug's s1
fragment reconstruction and mine: we both had roughly the same # of errors,
and having the other's work was great. The repository has all the files in
src/cmd. I have not tried to assemble all of them yet, so any reports here
would be good. Remember, the C files will not compile with the existing
compiler.
Cheers,
Warren
A friend of mine has gotten an AT&T 3B2 running at the Vintage Telephone
Equipment Museum here in Seattle. A Teletype model 33 and a 37 can now
also connect (through a small step-by-step switch and then a #5 crossbar)
to the computer. Even if System V is not exactly classic UNIX, I hope
the configuration as a whole counts.
The 33 has local echo. The 37 has it too (but supposedly that's easier
to change). I've been experimenting with the correct stty settings, but
it's hard to get everything right. Mostly I've been experimenting with
the 33 since the 37 just started working yesterday.
Could some setting cause line feeds to intermittently not happen, so that
two lines are overprinted? I'm wondering if this is due to a mechanical
problem in the 33, or to line noise (which I know we are having) because
I can't see much pattern to when lines are being overprinted.
Are there any input settings that allow me to use LINE FEED and CAR RET
interchangeably as line terminators in canonical mode? I'm assuming they
won't affect the output settings, so that programs can print NL (which
becomes CRLF) or CR (which stays CR).
Is the terminal driver smart enough to print the LF character while the
CR is happening, so I can shorten the delay settings? That's only dealing
with output. Is the driver smart enough to change the timing when dealing
with input? (since the driver can't change the LF key into CRLF because
the LF is already happening when the driver sees it).
I have tabs expanded on output. Can I get the terminal driver to expand
them as input is being echoed?
And what controls echoing of login names? (besides /etc/gettydefs) We
want to turn that off for certain lines.
If you need more details, they will have to wait until Tuesday. Sorry.
And does anyone have any ideas about interesting ways to demonstrate the
features of the 37, 43, and 5610? I thought eqn might be smart enough
to use the half and reverse line feeds, and vertical tabs, of our 37.
Does any software know about the ribbon colors? What about software
to control tape readers and punches? We probably don't have the extra
32 printing characters that dmr's pages on early UNIX mention.
Thanks,
-- Derek
FYI I recovered 100% of the s1 src code fragments; I presume this
is of interest to y'all on this list, yes?
Actually I started to do so years ago, got distracted, and just started
again April 18, purely by coincidence, just days before this
list started -- quite a coincidence!
Then I went off trying to chase down the Multics source that
Ken and Dennis and Doug and Joe et al wrote, which eventually
lead me to discover the V1 source listing at bitsavers, and
googling *that* lead me to this (apparently stealth-mode) list.
(I have no gmail, btw, so I haven't requested to join, nor to svn.)
And reading the archived messages, wow, you guys got an amazing
amount done in a very short time! Congrats! (Boy am I glad I don't
have to do all that by myself after all...)
To give you an idea of what I got out of those frags, here's
the file listing of the result:
acct.s cc.c fed2.s
ar.s chmod.s fed3.s
as11.s chown.s form1.s
as12.s cmp.s form2.s
as13.s colon.s form3.s
as14.s cp.c form4.s
as15.s date.s form5.s
as16.s db1.s form6.s
as17.s db2.s fstrip.s
as18.s db3.s getty.s
as19.s db4.s glob.c
as21.s dc1.s goto.c
as22.s dc2.s if.c
as23.s dc3.s init.s
as24.s dc4.s ld1.s
as25.s dc5.s ld2.s
as26.s df.s ldx.s
as27.s dsw.s ln.s
as28.s dusg.s login.s
as29.s ed3.s ls.s
bas0.s exit.c unknown_frag64.c
bas1.s fc.c
cat.s fed1.s
(Warren's "Missing commands" missive in the list archive said "maki"
is present as a v2 binary, but don't forget that its *source* is present
also, in /usr/ken/maki.s and also /usr/sys/maki.s)
Note that ed1.s and ed2.s are missing. Their source code simply wasn't
in any of the fragments (which means, was not on the s1 disk image).
The "unknown_frag64.c" is almost certainly just a random useless C
program, not part of the actual Unix source (it doesn't look like
interesting code, and the indentation is random -- it's not written
in The One True Style).
Warren's frag68 and frag69 are not true fragments, so given all the above,
the reconstitution of s1 is complete (but needs double checking, e.g.
by people trying to assemble and run the source).
NOTE: I am not sure of precisely when s1 dates to, but many of these
source files use the "jsr r5, 0: <buffer>" calling convention that
requires writable code segments -- did that go away sharply with the
pdp11/20 to pdp11/45 move, or no?
Also note that these source files have both 0405 *and* 0407 types of
preludes, and that is also true of some of the binary disk blocks on
the s1 image that happen to contain executable commands (I've taken
only a brief look at the latter so far).
On the subject of the TEK graphics display, don't forget that good old
xterm(1) has a Tektronix 4014 mode! I don't remember how much variation
Tektronix had between different models (I may still have some manuals
somewhere, not sure), but conceivably that's a starting point.
P.S. Since doing the above, I've been working on a disassembler; it
works ok, and emits of course 'as'-syntax asm, and accepts a markup-
command file to allow e.g. introduction of human-chosen labels for octal
addresses -- and I'm nearly done
adding the ability to produce "1f" "1b" style branch labels -- I
created a bunch of bugs in the process of doing that.
When I get that settled down better, I intend to use it for very much the
same purpose that Warren was talking about in the list archives.
I also wrote a tap-format unarchiver from scratch to re-extract s2, but
unsurprisingly that was a wasted effort; Ken's extraction did in fact
recover everything in s2 that there is to recover. I should have known. :-)
P.P.S. While you're asking Ken and Dennis for more listings, ask them
for any "Unics" PDP 7 listings they may have, too! I suspect Ken even
has a Space Travel listing lying around, although I don't think he
has ever mentioned it over the decades.
P.P.P.S. The Computer History Museum is opening its exhibit of the
second Babbage engine replica tomorrow; I'm looking forward to it.
Doug Merritt
--
Professional Wild-eyed Visionary Member, Crusaders for a Better Tomorrow
The new boot stuff that James provided has more fs/usr files. How
do we want to organize this in the tree? Do we just mix it with the
fs2 bits? Do we enter it as part of the new bits?
Tim Newsham
http://www.thenewsh.com/~newsham/
I did a comparison of s2's /bin/sh and the sh.s we have (notes in
the notes file about this). There were a few changes, but they were
pretty similar. I added a patch in the patches directory that reflects
the changes and I verified that if you build with the patch you get
an identical binary (modulo the padding bytes that the assembler
fills in for ".." and ".even"). It's currently marked as an optional
patch and the sh.s build isn't being installed over /bin/sh in the
rf0.dsk image.
I think the sh.s listing itself might be defective in two ways:
- There's an rts missing at the end of the "error" function
- It doesn't check for the "*" character when looking for globbing.
The 1e man page does list "*" as one of the globbing characters,
so its likely that these three instructions (1 rts, 2 for comparison)
somehow got dropped from the commented jun72 listing. I'm torn between
adding them to the original "pages" sources as obvious mistakes or
just leaving it out and using a patch to fix it. Right now we don't
have a patch that adds just these two fixes. I guess if we did that and
made it a mandatory patch, we could use the sh we build from sh.s as
/bin/sh in the images.
I look forward to seeing what shell sources we might get from the s1
fragments recovery.
Tim Newsham
http://www.thenewsh.com/~newsham/
if you want to contribute, but don't have e.g. arcane knowledge of
PDP 11 assembly and such -- then let me suggest that it would be
interesting to find out more about these people listed in the 1973
"Study of Unix" documents (http://www.bitsavers.org/pdf/bellLabs/unix/)
that formed the basis of this reconstruction effort.
For starters, who was this "T. R. Bashkow" who called the
meeting? Some googling last week indicates to me that he has
an engineering award named after him, and that he does
not have a wikipedia entry.
B. A. Tague's name is prominent too, although I personally
do not recognize it. And similarly for the other memo
addressees.
Consider that any of these people might just happen to still
have source code listings, magnetic/DEC-tapes, paper tape, or even just
historical anecdotes to share, but perhaps no one ever asked
them.
Or their heirs, for any who have passed on.
In any case, it's getting kind of late in history; this may
be the last chance to track down even information about these
people who participated in this historic meeting, let alone
find them and ask them about ancient media.
P.S. The above thoughts apply to all other historic systems, of course,
not just those Unix-related.
I managed to find a RESISTORS-related historic document last week,
for instance. (Princeton-area early hobbyist computer group.)
Doug Merritt
--
Professional Wild-eyed Visionary Member, Crusaders for a Better Tomorrow
I just committed some changes that reorganize the build process a bit.
The Readme contains information about the change. Basically now you
just do a "make" at the top level. If you have a checked out tree
you might have to move your current "build" aside when you do an
update. Please let me know if anyone notices brokenness.
Warren, can you look over the Readme?
Tim Newsham
http://www.thenewsh.com/~newsham/
An early section of the jun72 document has some code for
"modifications to UNIX to accomodate the T4002A graphic console."
Is anyone familiar with this? If we could emulate this device
easily, it might be fun to enter this patch as an optional patch
to the system.
Tim Newsham
http://www.thenewsh.com/~newsham/