Now that we have 0407 kernel support, I'll have a go at getting one of the
early C compilers to work. Could I suggest that we make a src/ directory
in svn, which will hold any source code that produces V1/V2 executables?
I'll make a directory for the C compiler. We can also add in working fragments
from the s2 tape into a cmd/ directory. The layout echoes the V7 tree:
/usr/src/cmd/ # Single file sourcefiles
/usr/src/cmd/as/ # Assembler
/usr/src/cmd/c/ # C compiler
/usr/src/libc/ # C library
/usr/sys/sys/ # Kernel source
Which of course implies that we might need to rename rebuilt/ to sys/ :-)
After e-mailing a reply about 6 times today and it going to the original
poster, instead of the mailing list where I wanted it to go, I have
decided to change the behaviour of the unix-jun72(a)tuhs.org list. Replies
will now go back to the list, not the poster.
It's an arbitrary decision; if you disklike it, let me know. If most
of you prefer it the other way, I'll switch it back!
I reorganized the build process slightly. Hopefully this won't affect
anyone and everything will keep working as before. I basically
took the 'sed' hacks out of assemv7 and made the "rebuild" script do
the patching with proper patch files instead. There is now a patches
directory with all of the patches we are using and comments on what
they do and why.
All, my mkfs.c $Revision: 1.17 $, $Date: 2008/05/04 14:20:12 $ now produces
mountable filesystem images, and it's now checked into the svn repository.
The problem was that the size of a directory is not the size of the blocks
allocated to it, but is in fact the number of bytes of the in-use directory
entries. For example, / was being allocated 1 block == 512 bytes. But 512
is not its size (as it would be in later UNIXes); in fact if / has entries
41 sdrwr- 7 root 70 Jan 1 00:00:00 .
41 sdrwr- 7 root 70 Jan 1 00:00:00 ..
43 sdrwr- 2 root 570 Jan 1 00:00:00 bin
42 sdrwr- 2 root 250 Jan 1 00:00:00 dev
99 sdrwr- 2 root 100 Jan 1 00:00:00 etc
108 sdrwr- 2 root 70 Jan 1 00:00:00 tmp
114 sdrwr- 2 root 20 Jan 1 00:00:00 usr
then its size is 7 entries * 10 bytes each = 70 bytes.
Importantly, this also means that we can now make bootable root filesystems
without having to do a cold UNIX:
% tools/mkfs /usr/local/src/V1 rf0.dsk rf # Make the / disk
% tools/mkfs /usr/local/src/V1 rk0.dsk rk # Make the /usr disk, same stuff
PDP-11 simulator V3.7-3
RF: buffering file in memory
TC0: 16b format, buffering file in memory
/dev/rk0# ls -l /usr/tmp
112 sxrwrw 1 root 156 Jan 1 00:00:00 a.out
110 sxrwrw 1 root 1664 Jan 1 00:00:00 etma
113 sxrwrw 1 root 6 Jan 1 00:00:00 hello
109 sxrwrw 1 root 26 Jan 1 00:00:00 ttmp
111 sxrwrw 1 root 142 Jan 1 00:00:00 utmp
806+4602 # Number of free blocks on / and /usr
I added /usr/tmp/hello just to verify that I was getting files that
were not on the cold UNIX tape.
> > The controller is an RK11.
> > The disk drives are RK02, RK03, RK05.
> > The RK02 is a 1.2MB drive (256B per sector).
> > The RK03 is a 2.4MB drive (512B per sector).
> > The RK05 is a 2.4MB drive (512B per sector).
> There was also a RK05F which used a fixed platter (in the same
> plastic enclosure as the removables if I remember correctly). That was
> double capacity, around 5MB.
Yes, the RK05J is the removable one, as described above. The RK05F is
the fixed version that doubles the density. However, to the system, it
appears as two separate drives, not as a single 5MB drive. I am not
sure how the data were interleaved between the two "logical drives"
which is important when scheduling seeks on the logical drives.
I've just checked in my latest tools/mkfs.c into the svn repository. Could
a few people eyeball it and look for errors. Even better, if you can eyeball
the working rf0.dsk image and compare it to an image made by my mkfs.c.
At present, I can make an rk0.dsk image with mkfs. I can run up a warm kernel
and try to mount the rk0 image as /usr, with my /tmp/a.out. But when I try
to chdir /usr, I get a Bad directory message.
So something is screwy with the rk0.dsk that my mkfs.c is making.
P.S typescript of warm boot:
# check # check indicates rk0.dsk is OK
# /tmp/a.out # I try to mount it
/dev/rk0# chdir /usr # but the chdir fails
# du /usr # du /usr shows no results
# df /usr # and df shows it is empty
# df # but df shows the free space on RF/RK
> Confusingly, the 1e manual for /dev/rk0 says its an RK03. I'll have to go
> read the DEC manuals, but I would guess that the RK11 drive and interface is
> the same, but the RK03 and RK05 removable disk packs were of different
> storage capacity.
The controller is an RK11.
The disk drives are RK02, RK03, RK05.
The RK02 is a 1.2MB drive (256B per sector).
The RK03 is a 2.4MB drive (512B per sector).
The RK05 is a 2.4MB drive (512B per sector).
The media for the RK03 and RK05 are compatible (IBM 2315). The drives
look different from each other, but I don't think the system can tell
I looked through init briefly and the version from s2.tar.gz is
slightly different than the one in the pdf printout. In the printout
/dev/rk0 is mounted on /usr at boot time. In the s2 version the
string "/usr" is still present, but the call to mount is gone
and so is the "/dev/rk0" string.
The init source is fairly short and shouldn't be too hard to type
in or get from ocr. Has anyone yet worked through the details of
using the V7 compiler to make 0405 binaries? Also has anyone
successfully used a populated /usr on rk0 yet?
I wrote this:
exit = 1.
mount = 21.
sys mount; rk0; usr
And tried to assemble it with /bin/as, but it's a 407 exec and it didn't
work (core dump, created odd files)
So, I built it with apout & as like this:
apout /backup/raid2/pdp11/v7/bin/as ./mount.s
# reconsruct v1 0405 a.out header
echo -e '\005' >mount
dd if=a.out of=mount bs=1 skip=1 seek=1 count=11
dd if=a.out of=mount bs=1 skip=16 seek=12
And it runs, but nothing happens. I have not debugged it much. Wish we
had a working v1 as.
On Sat, May 03, 2008 at 08:16:19AM -0400, Brad Parker wrote:
> The simh setup was wrong; you need to use
> set rk0 enabled
> attach rk0 rk3.dsk
> Once I did that I could check the image I made with your program. I have
> not mounted it yet, however. It checks fine.
> Tim - where did you get the files you used to make your tape image? Can
> you tar up that directory and check it in? I can't find init anywhere.
> I must be confused.
On the s2 tape in /etc/init.