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:
cd /your/s2/directory
/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.
Tim Newsham
http://www.thenewsh.com/~newsham/
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
