Well, it has been almost 2 weeks since my last post on this thread. Since
there is so little information about LSX online, I might as well post all
that I have done / noticed.
First things first, the kernel building issue was as simple as I was
expecting. All of the build scripts are meant for an external V6 system,
and do not work on LSX itself. I forgot that the LSX linker defaults to
040000 instead of 0 which obviously broke my kernel. Setting the "-a" flag
on the linker and fixing config stuff in param.h, header.s, and mch.s was
all that was needed to make it work.
Next up was converting the userspace from 16K to 20K. I tried to use an
external compiler as little as possible and was mostly successful doing so.
"ed.c" needed to be broken up into 2 different files, but everything else
worked. The only thing that needed to be cross compiled was the C compiler
itself. As it turns out, the stock C compiler that LSX comes with does not
have enough "OSSIZ" in order to build the 2nd pass of the compiler.
Interestingly enough, compiling it with the full space only makes the 2nd
pass go up to 23K-ish size. It just barely fits in the userspace, but it
does work. I don't know why the original creators of the root image didn't
start with this.
Speaking of the C compiler, mounting the "cc.dsk" file from the archives on
LSX is a bad idea. Unlike every other image, it is formatted for 500 blocks
instead of 400. Trying to write to this filesystem will cause the swap
space to get overwritten, which is generally not a good thing.
After the kernel and userspace were working, I went ahead and started
making modifications to the kernel. The first goal involved re-adding the
RAW tty mode. Turns out, this was super simple and only took like 10
minutes of copying "if" statements. After that, my custom V6 screen editor
compiled and worked flawlessly.
Finally, tonight I was able to get a RK05 driver to work alongside the
default RX01 driver. This one was a little bit more of a challenge, as all
of the block device switch code has been ripped out of LSX. Device drivers
also work slightly differently, as some driver support functions are
removed and "buf.h" is set up to only use 8-bit dev IDs. After adding back
a simplified "bdevsw[]", some modifications to "bio.c", and a whole
lot of
tinkering I was able to get RK0 auto-mounted on "/mnt". Should make moving
lots of files *much* easier, plus it will facilitate my future plans for
the project.
I think my next goal is to add back the "mount" and "umount" syscalls.
I
got about 2200 bytes free of kernel space, so that should be more than
enough room to add those functions in. After that, i'll just need to write
a RX02 driver and make the jump over to real hardware. Of course, the
mystery swap bug still persists.
Thanks for reading,
Gavin
On Fri, Jul 15, 2022 at 3:07 AM Gavin Tersteeg <gctersteeg(a)gmail.com> wrote:
Well, I have spent a few more days tentatively messing
around with LSX,
and I have noticed a few things.
First off, the C compiler is not the only program to have occasional
issues. Sometimes the "mv" command also fails with the
oh-so-descriptive "?" error. By the looks of it, this error is caused by
something going wrong with a fork() and subsequent wait() syscall. That
recurring error in the C compiler is also caused by the 2nd pass of the C
compiler not being able to find a temporary file created by the 1st pass.
If the 1st pass was failing to run, then that would explain why the 2nd
pass isn't able to find that temporary file. This has me guessing that
there may be something wrong with fork() or exec(). Whenever it is, it
doesn't dumpster memory or blow up the filesystem. For all I know, it may
be an emulation issue too, but I have no way of testing it right now.
The current kernel I am building is under 16KB at the moment. My goal is
to be able to recreate the stock (semi?) functional kernel, and then do
modifications from there. This goal has not been reached, as this kernel
simply crashes on startup. It is either a HALT instruction or a stack issue
depending on if the kernel has been stripped or not. I bet I am building it
wrong again :/, it doesn't need to be reloc'd after the "ld -X" does
it?
Has anyone actually been able to get a system to build with the archived
LSX disks? I have poured over the config files many times, but I feel like
I am missing something painfully obvious...
On Mon, Jul 11, 2022 at 6:47 PM Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
From:
Paul Ruizendaal
Note that LSX only holds one process in core and
swaps other
processes
(NPROC = 3) out to floppy. It reportedly took
several hours for the
Terak to self-compile LSX from source.
If one is working in a simulator, and not a real hardware PDP-11, there's
a
'trick' one can use to make life a lot easier - for MINI-UNIX, at least;
I'll
comment on LSX below.
As I report in the MINI-UNIX Computer History Wiki article: "MINI-UNIX
uses
the same file system as V6; this allows MINI-UNIX packs to be 'mounted'
on V6
systems (either real, or simulated), which is very convenient for working
on
them." So just spin up a V6 in the simulator, mount the LSX/MINI-UNIX
pack,
and away you go. The V6 toolchain can be used to compile/link kernels; to
link user commands one will need to import the LSX/MINI-UNIX loader
(which,
since V6 is source compatible with LSX/MINI-UNIX, is trivial).
LSX is potentially more complex, as it supports _two different_ file
system
formats: the standard V6 one, and a 'contiguous' one which is very similar
to the V6 one (rdwri.c has no conditionals on CONTIG; not so alloc.c,
though), but is not fully compatible. So non-contiguous LSX file systems
can be mounted under V6, but not contiguous ones.
Noel