> >There is a bug in the svn sources on page e09-07, near the bottom.
> >The call to sleep should read:
> > jsr r0,sleep; 0:..
> >Note that there should be a colon, not a semi-colon after the 0.
> >Presumably, this code was never executed, else it would have
> >resulted in a halt.
> but what *does* that syntax do? 0:.. ?
The two-instruction sequence is:
movb tty+3(r1),0f / put clist id in sleep argument
jsr r0,sleep; 0:..
The "0:" on the second line is a label and it is referenced by the "0f"
in the first line. The first line is putting a value into the argument
being passed to the sleep subroutine. Self-modifying code.
The ".." assembles to a 0.
With the incorrect code, "0" assembled to a 0 and ".." assembled to
a 0, so there was one extra word of zeroes, and the return from the
sleep would have executed it (halt) instead of the "br 1b" on the
I downloaded the stuff from the svn, got it to build, then did a cmp -l
on the load file from my assembler vs. the one built from the svn tree.
There is a bug in the svn sources on page e09-07, near the bottom.
The call to sleep should read:
jsr r0,sleep; 0:..
Note that there should be a colon, not a semi-colon after the 0.
Presumably, this code was never executed, else it would have
resulted in a halt.
After I made that fix, a build from the svn tree is identical to that
from my assembler.
I thought I would quickly make a list of commands we have, commands that
are missing, and out-of-the-ordinary commands. Below, if a command has
no comment, it's a V1 command that we have. Notes follow. I have not tried
to list the missing /etc and /usr/... commands yet.
: V2 cmd, 0405 binary
as V2 binary
cc V2 binary
chball ? no idea
ds V2 binary
echo V2 cmd, 0405 binary
exit V2 cmd, 0405 binary
fc V2 binary
find V2 binary
goto V2 cmd, 0405 binary
if V2 cmd, 0405 binary
ld V2 binary
login V2 cmd, 0405 binary
maki V2 binary
nm V2 binary
size V2 binary
skip ? no idea
strip V2 binary
stty V2 cmd, 0405 binary
un V2 binary
as2 V2 binary
getty V2 cmd, 0405 binary
I have a quote from dmr somewhere (I can't find it), but to paraphrase:
early UNIX was under a constant state of development. We would tidy up
now and then, write a new manual, then get back to development.
The 1st Edition UNIX manual is dated November 3, 1971.
The 2nd Edition UNIX manual is dated June 12, 1972.
1st Edition (1e) only used 0405 a.out files. 2nd Edition (2e) only used
0407 a.out files. I would guess that the executables that we have from
the s2 tape are from a snapshot halfway between 1e and 2e, and at that
point in time the kernel could execute both varieties. This would explain
why some V2 commands are 0405 style, and some are 0407 style.
Despite the dates on the PDF commentary where we got the kernel source,
the kernel has to be around 1e, not much later. The kernel only knows
about 0405 a.out files, and is missing all of the system calls new to 2e:
hog, kill, makdir (renamed from 1e mkdir), smdate and sync.
So: kernel is around 1e, Nov 1971 or close; executables are somewhere
between 1e and 2e, but before June 1972 as we have 0405 and 0407 ones.
The tape I made earlier didnt properly preserve the permissions so
booting failed to exec /etc/init (had no exec bit set). I fixed
my tape builder to get the permissions from the old Readme file
and regenerated a tape..
The good news: login prompt!
I just built rf0 in the usual way, then rebuilt a warm kernel and
Here's the current status on how to use the files:
- svn to the latest version
- install v7 binaries somewhere (ie /tmp/v7)
- install apout somewhere (ie /tmp/apout2.3alpha2)
- update paths in tools/assemv7
- compile tools/ml.c into tools/ml
- build simh's pdp11 emulator using brad's patches at
install into tools/pdp11
- run ./tools/assemv7 to make files in build/*
- run ./simh.cfg to run the emulator
- type "go" to start it
- type "go" at the first halt to continue writing over your rf0 disk
- after waiting for a while, type control-e and then "det rf" and
- you should now have some data written over your rf0.dsk image.
- continue debugging the cold boot process. This should eventually
let us install a full root disk image from the kernel and a
tape construct with 1972_stuff s2 /bin and /etc files.
- get a working mkfs and use it to build and populate the rk03 disk
with the 1972_stuff s2 /usr files.
- continue debugging the kernel to boot the rf0 disk and mount the
rk03 disk on /usr.
I saw the thread about the assembler doing divide by 2 the wrong way.
I took a look at my assembler and it had a similar bug. I fixed my
assembler, then ran the code again.
It correctly writes the RF11 image (as best as I can tell), then reads
/etc/init into the user area and executes it. I left the TC11 disabled
on my run and it panics when /etc/init tries to read the tape.
To double-check, I ran the warm boot and it successfully gets into
the /etc/init user code as well, so I'm pretty confident the image
As far as I can tell, the source code I sent out this morning has no
problems. Most likely, you guys are fighting assembler and/or other
I'll cobble together a bootable RF11 image (assuming that there really
are no kernel problems) and send out a copy of that. Once everyone
has that, they should be able to continue generating tapes and RK03
images of other executables, etc. I can include a copy of the
assembler listing file for both warm and cold boots so that everyone
can have a reference while they are debugging.
I've also got the M792 boot (from the documentation) as well as an
untested bos.s. If those work, then the RF11 image I send out will
be pretty close to authentic. Otherwise, you will still need to load
the kernel into core with the "load" command.
I'm sending Brad a copy of a different OCR of the document that he
can use to check against the current one. The file also includes
various fixes to bugs in the original document.
Presumably, he'll incorporate anything differences into the svn.
I just did a 'grep' of some suspicious
character combinations and found the following:
e00-04:/ initialize i-nodes r1.,...,47. and wr1te the root device,
e04-01: bne 3f /Is1t zero now?
e08-05: bis $103,r3 / now rbn,for,un1t,1e
e04-03:1: / flle just opened
e05-04: cmp r1, ii / r1 = i-number of current flle
e03-01: jsr r0,rswap / read new process 1nto core
e04-04: cmp r1,$12 / is char a l1ne feed
e06-02: br ret / it 1n r1; 1f there 1s no problem with reader,
e06-02: inc *u.fofp / increment file offset to point to 'next' char
e08-03: br 1f / branch if block already 1n a I/O buffer
e08-03: bis $2000,(r5) / set read mu (bu: 100 1n 1/0 buffer)
e08-06: bit $173000,(r5) / lock+keep+active+outstand1ng
e11-07: cmp 0b,$1nbuf+256. / have we exceeded innut buffer size
e06-04: inc *u.fofp / increment f11e offset to point to next
e06-05: mov r2,i.size / yes, increase the f11e size to file offset +
e06-06: / be written to the f11e
e08-03:tstdeve: / check whether permanent error has occured on special
e03-02: / to end of stack gets written out) ~
e08-03: mov u.base,r2 / put users base in r2 ~
e11-01: cdpb B(r5),$'- / was this sh calleZd by init or loginx~
e03-02: cmp r2,$core / is u.break less than Score
As you can see, the errors are almost exclusively in
the comments. Someone with write access to the svn
repository could perhaps take care of that.
I just noticed that the 1972_stuff "as" program generates:
400 MOV #120000,SP
core = orig+40000 / specifies beginning of user's core
ecore = core+20000 / specifies end of user's core (4096 words)
. = orig+400
/ copy in transfer vectors
mov $ecore,sp / put pointer to score in the stack pointer
while the V7 assembler is generating the correct:
400: MOV #60000,SP
I have no idea why it is doing this. The 1972_stuff "nm" program
correctly lists ecore as 60000.
Use the 1972_stuff "as" at your own risk!
I wrote a utility for building a cold boot tape and included it in the
tools directory. Its not yet tested so its possible I got the format
wrong... its based on my reading of init at the end of u0.s.
It seems like the permissions in the s2.tar.gz file from the
1972_stuff reflect the original 1ed permission bits (at least the
low order bits do) so this makes restoring the original permissions
fairly easy. Unfortunately the tar doesn't preserve the original
uids. The included "Readme" does have the original uids, so its
possible to recreate the proper uids by hand. If you do so,
my mktape utility should write out the proper uid and mode values.
The use is straightforward:
/path/to/mktape.py bin/* etc/*
and you'll get a "tape" file out. I believe you just need the
stuf in bin and etc. The stuff from usr should probably go on
the rk03 disk after cold boot.