[Unix-jun72] more corrections

[Unix-jun72] more corrections

[James A. Markevitch]

> 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

[Unix-jun72] more corrections

[Brad Parker]

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.diff
http://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

[Unix-jun72] more corrections

[Tim Newsham]

> Tim, I think the as we have from the s2 tape is a V2 assembler, as it has
> an 0407 header, not an 0405 header.

Yah, that makes sense.  I guess this means that the system we
rebuild won't be capable of building itself unless we somehow
find an old as or srcs.

> Given that we know the assembler has predefined symbols, which means
> renaming $mount, I think we might as well take the path where we modify
> the source code so that it can be built with the tools we have, which is
> your option 2) above. And of course, document the changes.

The approach I'm taking currently is to use the 1972_stuff "as" (v2)
using apout and some sed magic so that the original sources are
undisturbed.  The code is in the svn as tools/assem.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/

[Unix-jun72] more corrections

[Warren Toomey]

On Thu, May 01, 2008 at 08:34:10AM -1000, Tim Newsham wrote:
> > I adjusted my tools/dumpaout.py appropriately and tested with the 1ed
> > assembler.  If you sed all the files to s/mount/xmount/ it builds just
> > fine with 1ed "as" and the a.out header is indeed 6 bytes long and
> > is included in the text segment...  Everything is lining up..
> 
> ugh, I was wrong.. it was not lining up!  The 1ed "as" is also
> using a 16-byte header.  This together with the "mount" issue is
> making me think they used a different assembler for these sources.

Tim, I think the as we have from the s2 tape is a V2 assembler, as it has
an 0407 header, not an 0405 header.
 
> .... so... we may have to either 1) alter the way as works, or 2)
> remove those comment characters in the vector table...

Patching the V2 as binary to work like V1 is going to be hard. I even though
about modifying the V7 as to output 0405 headers, but again hard.

Given that we know the assembler has predefined symbols, which means
renaming $mount, I think we might as well take the path where we modify
the source code so that it can be built with the tools we have, which is
your option 2) above. And of course, document the changes.

Cheers,
	Warren

[Unix-jun72] more corrections

[John Cowan]

Brad Parker scripsit:

> 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)

Note that the whole point of the magic number being what it is, is
that it's a PDP-11 unconditional branch instruction to skip the rest of
the header.  That way the a.out file could be loaded header and all and
just started at its beginning by jumping into it.

-- 
Samuel Johnson on playing the violin:           John Cowan
"Difficult do you call it, Sir?                 cowan at ccil.org
 I wish it were impossible."                    http://www.ccil.org/~cowan

[Unix-jun72] more corrections

[Tim Newsham]

> I adjusted my tools/dumpaout.py appropriately and tested with the 1ed
> assembler.  If you sed all the files to s/mount/xmount/ it builds just
> fine with 1ed "as" and the a.out header is indeed 6 bytes long and
> is included in the text segment...  Everything is lining up..

ugh, I was wrong.. it was not lining up!  The 1ed "as" is also
using a 16-byte header.  This together with the "mount" issue is
making me think they used a different assembler for these sources.

.... so... we may have to either 1) alter the way as works, or 2)
remove those comment characters in the vector table...

I apologize for the earlier incorrect information and the flood of
emails..

Tim Newsham
http://www.thenewsh.com/~newsham/

[Unix-jun72] more corrections

[Tim Newsham]

> I adjusted my tools/dumpaout.py appropriately and tested with the 1ed
> assembler.  If you sed all the files to s/mount/xmount/ it builds just
> fine with 1ed "as" and the a.out header is indeed 6 bytes long and
> is included in the text segment...  Everything is lining up..

added tools/assem which builds using the 1ed "as".

Tim Newsham
http://www.thenewsh.com/~newsham/

[Unix-jun72] more corrections

[Tim Newsham]

> Ahh, that makes sense.  So if we build with the 1ed "as" then those
> first few lines should be commented out since they will be occupied
> by the a.out header.  Ahh!  yess, it makes sense, e00-02 has
> a section at orig+400 "copy in transfer fectors" where those
> vectors are overwritten during startup.
>
> We really should try building with the 1ed assembler.  I think a simple
> sed s/mount/xmount/ over the whole sources will probably fix the mount
> label issue.

I adjusted my tools/dumpaout.py appropriately and tested with the 1ed
assembler.  If you sed all the files to s/mount/xmount/ it builds just
fine with 1ed "as" and the a.out header is indeed 6 bytes long and
is included in the text segment...  Everything is lining up..

So, I think those comment characters belong in the u0 sources, although
will have to be removed when compiling with a more recent assembler.

Tim Newsham
http://www.thenewsh.com/~newsham/

[Unix-jun72] more corrections

[Tim Newsham]

On Thu, 1 May 2008, Brad Parker wrote:
> 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.

Ahh, that makes sense.  So if we build with the 1ed "as" then those
first few lines should be commented out since they will be occupied
by the a.out header.  Ahh!  yess, it makes sense, e00-02 has
a section at orig+400 "copy in transfer fectors" where those
vectors are overwritten during startup.

We really should try building with the 1ed assembler.  I think a simple 
sed s/mount/xmount/ over the whole sources will probably fix the mount 
label issue.

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/

[Unix-jun72] more corrections

[Brad Parker]

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

[Unix-jun72] more corrections

[Brad Parker]

Tim Newsham wrote:
>> 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.
>
>Hmm.. those "/" comment characters are definitely not hand written
>in.  There are hand written comments that state what address things
>should land at.  I'm a bit confused how this could happen with
>those comment characters in place, though, so removing them does
>sound like its the right thing to do.

now you've convinced me it's not :-)

I wonder... hmmm.  if the V1 a.out header where 12 bytes long, then
everything would just automagically work.

The v7 a.out header is 16 bytes long; but could the v1 a.out header
have been 12 bytes long?

-brad

[Unix-jun72] more corrections

[Brad Parker]

Tim Newsham wrote:
>> 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.
>
>I'm suspecting the opposite.. I went through all of the comments in
>notes.txt about hand written corrections and read through the code to
>see if they make sense or not and it seems like all of the corrections
>did make sense in the code and the original code that they replaced
>did not.  I updated the code to reflect this and added comments to
>the notes file.

Ok, I may well be confused.

Before I took the comments the IOT vector was zero.  After I removed
them the IOT vector (34) was correct.

Perhaps the code wants to be loaded at 014 instead of 0.
I put the comments back in - I'll try changing where I load.

>btw, there are still a bunch of unresolved symbols in the low address
>vector tables..

I thought only fpsym was undefined in those vectors.

>> I had to add KE11A support to simh;  I mostly copied the code from
>> apout.
>
>This discussion of hardware is making me wonder -- does this nail down
>the hardware?  The 1ed manuals mention tht they ran on a 24kbyte
>pdp 11/20, but that they were eying an 11/45.  My reading of the code
>was making me lean towards the original 11/20 configuration, but it
>sounds like some of these features might be present in the 11/40 or
>11/45?

I sure looks like they used an 11/20 with a KE11A board.

>speaking of modifying simh, we may have to map one of the similar
>serial devices in at the dc11 address to support ttys.  simh doesn't
>support the DC-11, but when I asked on the simh mailing list someone
>mentioned that one of the existing devices is very similar with
>less support for modem control lines.

I can do that.  Are there docs on the DC-11?

-brad

[Unix-jun72] more corrections

[Al Kossow]

Tim Newsham wrote:

> This discussion of hardware is making me wonder -- does this nail down
> the hardware?  The 1ed manuals mention tht they ran on a 24kbyte
> pdp 11/20, but that they were eying an 11/45.  My reading of the code
> was making me lean towards the original 11/20 configuration, but it
> sounds like some of these features might be present in the 11/40 or
> 11/45?

Use of EAE is HIGHLY unlikely on anything after the 11/20.
There was a better solution (EIS) for the 11/40 and forward.

The note for the Jan 73 talk mentions they were still working on writing
the 11/45 version, which puts the release well after the code you're working
with.

Still looking for EAE docs. May have to scan an 11/20 handbook to get it.

[Unix-jun72] more corrections

[Tim Newsham]

> 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.

Hmm.. those "/" comment characters are definitely not hand written
in.  There are hand written comments that state what address things
should land at.  I'm a bit confused how this could happen with
those comment characters in place, though, so removing them does
sound like its the right thing to do.  By the way, you removed the
leading comment characters but did not add comment characters
after the entry but before the text comments that follow them.
ie: "4;4   init by copy" should be "4;4 / init by copy".

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/

[Unix-jun72] more corrections

[Tim Newsham]

> 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.

I'm suspecting the opposite.. I went through all of the comments in
notes.txt about hand written corrections and read through the code to
see if they make sense or not and it seems like all of the corrections
did make sense in the code and the original code that they replaced
did not.  I updated the code to reflect this and added comments to
the notes file.

btw, there are still a bunch of unresolved symbols in the low address
vector tables.. I took a look at the assembly memory dump last night
(and also committed code in tools to convert the a.out to a bunch
of simh deposit commands).

> I had to add KE11A support to simh;  I mostly copied the code from
> apout.

This discussion of hardware is making me wonder -- does this nail down
the hardware?  The 1ed manuals mention tht they ran on a 24kbyte
pdp 11/20, but that they were eying an 11/45.  My reading of the code
was making me lean towards the original 11/20 configuration, but it
sounds like some of these features might be present in the 11/40 or
11/45?

> I'll put a tar file on my web site with the modified simh source.

speaking of modifying simh, we may have to map one of the similar
serial devices in at the dc11 address to support ttys.  simh doesn't
support the DC-11, but when I asked on the simh mailing list someone
mentioned that one of the existing devices is very similar with
less support for modem control lines.

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/

[Unix-jun72] more corrections

[Brad Parker]

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