OK, I've got it to the point where is makes _a_ filesystem, and now I'm off
to bed. The image looks fine to me, but I thought I'd pass the source code
around in case someone spots an incorrect assumption that I've made, or a bug.
I have created an RK03 image using the V1 binaries off the s2 tape. I then
ran V1 check on the image; here is what it said:
# check rk.img
0 files
0 large
0 indirect
0 used
3420 free
Not exactly fantastic, but much better than when I gave check a random
file to digest :)
Good night!
Warren
P.S cc -o mkfs -Wall mkfs.c
Tim Newsham wrote:
>
>How can I get the modified simh?
Here's a diff against v36 and a tar of my working directory:
http://www.unlambda.com/download/pdp11/unix-jun72/KE.diffhttp://www.unlambda.com/download/pdp11/unix-jun72/simhv36-1-ke.tar.gz
>Also what configuration are you using? I have this so far:
>
> set tc enabled
> att tc tape.dt
> set rk3 enabled
> att rk3 rk0.dsk
> set rf enabled
> att rf rf0.dsk
> set cpu 11/20
> set cpu 32K
I'm using this:
set cpu 11/20
set hk disabled
set rha disabled
set tm disabled
set rx disabled
set rl disabled
set tq disabled
set rk3 enabled
att rk3 rk3.dsk
set tc enabled
set rf enabled
set ke enabled
set cpu 32K
load loadfile
d pc 400
set cpu history=1000
attach rf rf0.dsk
I forgot to include my a.out->loadfile conversion program. I'll check it
in to svn.
>Have you gotten far enough that it writes out the full primitive
>root on rf0 so that you can reboot and get init going?
No - it writes a bunch of blocks to rf0 but no directories.
The 'zero i list' appears to work, and the code to init i-node 41-47 runs
but nothing gets written. Or if it does the wrong thing gets written. not
sure why.
To debug I sprinkle "halt"'s in the code and then do "show cpu history"
to see what happened.
As a sanity check I also do 'e 0-40' and 'e 400-440' to make sure
location 34 (iot vector) is filled in and the code at 400 is correct (it
loads the sp with 60000).
I might turn on some RF debug to see exactly what gets written when.
-brad
All, I'm trying to write a PDP-11 disassembler for a.out files. I'm having
trouble dealing with jsrs. Take, for example, the code here:
http://minnie.tuhs.org/UnixTree/1972_stuff/s1/frag19.html
I can happily deal with the jsr pc,do type of jsr, but the ones
involving r5 have me stumped, e.g.:
jsr r5,questf; < nonexistent\n\0>; .even
It appears that data is being inserted into the executable directly
after the jsr instruction. How does the rts which returns from the jsr
know how much data to skip, and what is the involvement of r5 here?
Thanks,
Warren
Tim Newsham wrote:
>> I wonder... hmmm. if the V1 a.out header where 12 bytes long, then
>> everything would just automagically work.
>
>The 1ed man pages are online. I looked at them and it said that the
>header consists of 6 words, but that the text length included the
>header size. However, I had to skip the first 16 bytes of the
>text segment (including header) to line up the various labels in
>u0.s (.=orig+100, .=orig+200, etc..)
yes, I think 0405 and 0407 a.out's are different.
I believe the V7 headers are 16 bytes and the text section starts at zero.
(heh, memory management)
The v1 headers are 12 bytes and the text section starts at 014 (i.e. the
header is part of the text section and *it* begins at zero, not the code)
So, if we assemble with the v7 as we need to adjust things a bit.
-brad
I'm confused about the disk clearing code in u0.s:
...
/ zero i list
1:
dec r0 / r0=33.,...,1
dec r1
jsr r0,clear / zero block 'r1' on fixed head disk
tst r1
bgt 1b / if blocks 33,...,1 have all been zeroed, done.
...
I had to add the "dec r1" above to get it to work. Otherwise it loops
forever. Since 'clear' takes a block # in r1, I'm not sure it could
work as written...
anyone look at this?
If I add the "dec r1" it does write some sort of structure to the disk. I'm
not sure it's correct, but it wrote a bunch of blocks.
-brad
> I wonder... hmmm. if the V1 a.out header where 12 bytes long, then
> everything would just automagically work.
If you look at sysexec, you will see that the "magic number" for the
a.out header is 000405. That is an instruction that jumps over the
first 12 bytes.
James Markevitch
I made some more minor corrections; turns out the commands in e00-01
around "4;4" are wrong, those lines are needed or the IOT dispatch
vector ends up in the wrong place.
I suspect, in the end, most of the "hand written" corrections should
ignored.
Right now the svn runs and ends up in the idle loop. It dispatches the
first system call (sys exec). I'm not 100% sure but I think it works.
(still some missing pages but I don't think the code hits them yet)
Not sure why it stops in the idle loop; maybe missing hardware.
I had to add KE11A support to simh; I mostly copied the code from
apout.
I'll put a tar file on my web site with the modified simh source.
-brad
Has anything changed regarding read access
to the svn repository? My client answered
svn: PROPFIND request failed on '/svn/trunk'
svn: PROPFIND of '/svn/trunk': 502 Bad Gateway
(http://unix-jun72.googlecode.com)
when I wanted to do a regular 'svn update'
command.
Hellwig
> >Since this OCR is independent of the other work that has been done, a
> >diff should provide an opportunity to fix any errors in the comments
> >that would not have been caught by the assembler.
> >
> >Is there a place to upload this without a Google account? The assembler
> >listing is about 416K.
>
> If you email me a tar file (or zip) I can put it on my website. I can
> receive email up to about 10mb. If it's larger than that I can set up
> with an ftp account.
A compressed .tar.gz won't be very large. I can send it along when I get
home late this evening. It's got 100% of the kernel source pages, so
it should be able to fill in any holes.
> I'd also be happy to write a script to diff the files.
"diff -b" works fine, as does tkdiff :-).
James Markevitch
Guys, I'm writing a PDP-11 a.out disassember. I think it will be useful for
a couple of reasons:
- we will be able to convert the extant 1972 binaries back into some form
of source code. It won't be as good as the real thing, but it will be
better than the binary.
- we have some source code in fragmentary form on the s1 tape, see
http://minnie.tuhs.org/UnixTree/1972_stuff/. Some of the fragments
are identifiable, some are not. We might be able to use the
diassembled binaries to identify some of the fragments, and even
reconstruct a hybrid original/diassembled version of the source
for some of the 1972 applications.
Right now, here's what I've got: disassembly of the top of 1972 ls:
sys break: 00
mov $01,044260
mov sp,r5
mov (r5)+,043732
tst (r5)+
dec 043732
mov 043732,043734
bgt 040056
mov $042542,r5
mov (r5)+,r4
cmpb (r4)+,$055
bne 040174
dec 043734
and the top of the frag19 file:
sys break; end+512.
mov $1,obuf
mov sp,r5
mov (r5)+,count
tst (r5)+
dec count
mov count,ocount
bgt loop
mov $dotp,r5
loop:
mov (r5)+,r4
cmpb (r4)+,$'-
bne 1f
dec ocount
At the moment it's a 1-pass disassembler. I want to make it 2-pass: on the
first pass I will try to identify labels for branches, functions, strings and
variable locations (and given them arbitrary names); on the second pass
I'll print out the instructions with reference to the labels.
None of the binaries have symbol tables, unfortunately.
It's a start, anyway.
Warren
I got a chance to do some work on the UNIX V1 sources this evening. I
took the output of my OCR software and with a couple of hours of editing,
it successfully assembles with a MACRO11 assembler modified for "as" syntax,
with the only exception being that "fpsym" is undefined. It looks like
the floating point emulation code is missing.
Since this OCR is independent of the other work that has been done, a
diff should provide an opportunity to fix any errors in the comments
that would not have been caught by the assembler.
Is there a place to upload this without a Google account? The assembler
listing is about 416K.
I wrote much of the bootstrap code a few weeks ago, so it ought to be
straightforward to get this up and running under simulation.
James Markevitch
A while ago, I heard someone (I can't remember who) say that he had a
paper listing of (at least part of) PDP-7 Unix. How much is there in the
way of surviving listings of PDP-7 Unix (if any)? With all of the
discussion of OCRing the V1 Unix kernel listing, I was wondering if
something similar could be done with PDP-7 Unix if enough listings have
survived (which is sort of unlikely, but you never know).
> I have dug up another listing of the PDP-11 assembly languge
> version, which seems to about contemporary with the
> one you have. The files mostly bear a copyright date
> of 1972, but like other printouts from the time,
> the datestamps only give month and day, not year.
> They are generally from May. It is post 11/45,
> and has segmentation and floating-point support.
Very cool! (fpsym, presumably)
> I replied and asked if we could get either a scan copy of the "other listing",
> or if he could send a photocopy to Tim.
As usual, the key is a high resolution, high quality scan. There is a huge
difference between 300dpi and 400dpi/600dpi for this old stuff, since the
signal to noise ratio is much better with the better scans.
This sounds like a broken record, but there was a 1200 page listing were
the first 400 pages were at 300dpi and the remaining 800 pages were at
400dpi. When you zoomed in, the differences were astounding and the
OCR results reflected that (the person needed to do a lot of editing on
the first third of the document to get it to compile).
If someone can get me a hardcopy, I'll scan it at 600dpi, as I am sure
Al would, if Tim isn't set up to scan stuff like this.
James Markevitch
Guys, I got this message from Dennis.
Warren
----- Forwarded message from Dennis Ritchie -----
Subject: Re: Trying to restore 1972 UNIX
Date: Thu, 1 May 2008 00:55:35 -0400
About the assembler, I am pretty sure that it's substantially
the same as that on the 5th edition tape, so it's likely
that a modified version, without the syscall definitions,
could be produced.
I have dug up another listing of the PDP-11 assembly languge
version, which seems to about contemporary with the
one you have. The files mostly bear a copyright date
of 1972, but like other printouts from the time,
the datestamps only give month and day, not year.
They are generally from May. It is post 11/45,
and has segmentation and floating-point support.
Incidentally, it doesn't use any of the system call names
as such; 'read' is at sysread: and so on.
About assembling it, I'm pretty sure we just did
'as u?.s' and the a.out was ready. This was before
make, after all.
Dennis
----- End forwarded message -----
I replied and asked if we could get either a scan copy of the "other listing",
or if he could send a photocopy to Tim.
Cheers,
Warren
I went through all the errors on the code checked in so far and made
edits consistent (I hope :-) with the pdf.
I also added the missing KE11A addresses (memory mapped EAE).
The remaining errors seem to be only due to missing pages.
-brad
> Can you show me how you are running it? (and feel free to cc the list)
(I think its mentioned in an earlier post already). I copy the
files to my 7ed system (make a tar, put it on a tape image, and
attach it in simh, then tar x to get contents). Probably easier
if you're using apout and local filesystem... I'm using the following
script (in my tools but not checked in because I'm using nonstandard
conv2):
tools/rebuild
(cd rebuilt; gtar -O -cf ../u.tar u?.s)
./conv2 -o tape.tm u.tar
cp tape.tm ~/work/simh/unix-v7-4/run/
Anyway to assemble I run:
as - sys.s u0.s u1.s ux.s
btw, I noticed some unicode characters in the files you committed.
I havent' had a chance to spend time editing it yet.. The ocr
often uses unicode for things like "-".
> I think there is a binary format. I think I figured it out once and
> wrote something to turn an a.out into it. hmmm. I'll go digging.
a.out is so simple, it wouldnt be hard to reproduce if we had to.
> I checked in the missing pages from e3, e4 and e8. I have not tried
> to assemble them yet, however.
I noticed that. Thank you.
> -brad
Tim Newsham
http://www.thenewsh.com/~newsham/
> I can happily deal with the jsr pc,do type of jsr, but the ones
> involving r5 have me stumped, e.g.:
>
> jsr r5,questf; < nonexistent\n\0>; .even
I have encountered this type of construct a lot when doing disassemblers
over the years. My usual strategy for dealing with this is:
1. If it's quick and dirty and I am not running huge amounts of code,
then the disassembler allows the user to provide a list of "hints" to
it. The hints for this would describe the arguments to each subroutine.
For illustrative purposes, you might have a side file that contains
the following:
subr 002004 questf string
meaning that location 002004 is a subroutine names questf that expects
a null-terminated string as the argument. As an additional benefit,
you get a nice name for the subroutine that the disassembler can put
into the output.
And if a subroutine takes two 16-bit arguments, you might have:
subr 003436 mysub arg16 arg16
If the disassembler identifies each of the targets of the jsr
instructions, then you can usually do a quick look at the code to
see what it expects, then add to the side file, then re-run the
disassembler.
2. If you want to be less quick and dirty, you can have the disassembler
do a partial flow analysis of the code to figure out what is expected
for arguments. This is usually much more involved and you still often
need to add hints for cases where the '60s or '70s programmer did some
kind of "neat trick" when coding.
My philosophy on these is to use tools to get to the 95%+ level of
automation and provide hints to pick up the rest. Using strategy
number 1 above will probably get you a lot of success with a small
amount of coding in your disassembler.
James Markevitch
All, I've just created a mailing list for the people involved in the effort
to reconstruct the Unix kernel from the 1972 assembly listing. I thought
it would be good to keep the mundane details of the work separate from the
TUHS mailing list.
The new list is unix-jun72(a)tuhs.org
I've manually subscribed the e-mail addresses that seem to be interested
in the work. If you want to be removed from the new list, e-mail me. If
you want to subscribe to the list, you can go here to do that:
https://minnie.tuhs.org/mailman/listinfo/unix-jun72
Cheers,
Warren
Hi,
here is my 2p :
http://cyrillelefevre.free.fr/jun72/jun72.zip
which is an archive of automatically extracted tif images from the
original pdf file.
so, no need to print/scan any more...
Regards,
Cyrille Lefevre
--
mailto:Cyrille.Lefevre-lists@laposte.net
I am trying out apout using the "1972_stuff" binaries. When using
"as" to assemble "ux" (e10-01 through e10-02) it gives an error
"m 0024" (multiply-defined label) for the line:
mount: .=.+1024.
I assume this is because the assembler has predefined the "mount"
system call (I ran across this earlier when using my system call
table sys.s with ux with the v7 assembler).
We can work around this (ie. use the v7 assembler without the definition
for "mount"), but it worries me a little -- why does the listing
have such an obvious and large flaw? The symbol "mount" is used
in several places, so this isn't likely to be a small typo. I can't
think of a good explanation as to why this error would exist in the
listing other than possibly pointing to another assembler being used.
Tim Newsham
http://www.thenewsh.com/~newsham/
On Thu, Apr 24, 2008 at 10:53:30AM -0700, James A. Markevitch wrote:
> I have been referring to this as version "1.5" since the date is later
> than the first edition manual, but before the second edition manual.
> Does anyone know if it's truly V1 of the kernel, or something between
> V1 and V2?
The date on the first page of the memo (PDF) is September 1972. That puts
the memo after 2nd Edition (June 1972) and 3rd Edition (Feb 1973).
The s2 tape in the Unix Archive has binaries which are dated mainly in
1972, spread from January thru to December, so they should be
contemporaneous with the kernel in the PDF.
The 1st Edition manuals are on-line on Dennis Ritchie's web page at:
http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html
I have a photocopy of the 2nd Edition manuals from Norman Wilson; I will
scan them in as a bunch of tiffs. The 3rd Edition manuals are at
http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v3/v3man.t…
but they refer to the C version, so they may not be as useful here.
> Does anyone have utilities earlier than the "1972" stuff from TUHS?
No, the s1 and s2 tapes are the earliest machine readable files that
we have.
I'm assuming that some of you are keen to see it running. It's going to
take a lot of work, especially on the debugging side. The existing 1972
binaries are already executable using my Apout emulator, so that will
help in two ways: we can run the old assembler, and we can tell if a bug
was in a userland binary and not in the kernel.
If I get a chance, I should try to compare the 1e and 2e manuals, to
outline the kernel API differences, as this might help us to determine
which binaries we have that will run on the PDF kernel.
Cheers,
Warren
