From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29034 invoked from network); 30 Jul 2022 04:41:04 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 30 Jul 2022 04:41:04 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id A3681406E6; Sat, 30 Jul 2022 14:40:50 +1000 (AEST) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by minnie.tuhs.org (Postfix) with ESMTPS id 51546404ED for ; Sat, 30 Jul 2022 14:40:40 +1000 (AEST) Received: by mail-wr1-f49.google.com with SMTP id h8so8043887wrw.1 for ; Fri, 29 Jul 2022 21:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iBr4kyb0EoT6wjVYtma4NgWu14p9cK0JsbgemJwNCpw=; b=EVPKFIh8maDCXicIbod+aNf20qN33Fx4/bGx6r8WrmCzUgfS/VUi1PGFAVureybgzm KU/F1ywZ00uJWncRUIFGWIJEF2u7A8KYhzDhDK2QddAqjqKJ84Y4pU0XdNLOzJDweEDj uQWaeL0I5XBMzwkhyY51dyFP2BkuM6pyBQJPyQglUUbUV/6w25UJaxcnNgjtbN2Vax/h 3wjUusFJx2uV5KRkULnYNnMtK0tJmPlBfnLSwzpYnvdPd+5eckkyRnCTk9PsgxnjvaKw mMphPx/wZ2F4u9lrAJg4XmOKU/DuNSHvUOGnO0xLu302ABplEySyJzt+3LIGdb//IIUZ rIpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iBr4kyb0EoT6wjVYtma4NgWu14p9cK0JsbgemJwNCpw=; b=YPKAYkyrFSupfnATUTGr2F4FMEf5MOB4ih3qdTRnaErlF6vz8Dves3OgRj5CW7HAvr TXVACrwrwUCIBaHlAoHhUi8Mw2b32qjjut+GOlSJgN8BNy96H1ZcUZUBMubpNdanlmnj sgdyCBv8VVyB0b5XhjDYv6r4j9zhHS0pjAcj+hl4SHNIltOjX9R5fj56wmghNTH+EOo8 ZMo3FNQGwgbvITImza/dGgO+DWjuImcnXEvlxwC6OQMiJghOf66F14gpJ2oFIVLKPn5l ch7htE2IgS3GgzTxqRCBNWpATJ8FdrgNCpcSYNyyy2w+fqrDudUcDaORAo7nHw19XQFV xZAg== X-Gm-Message-State: ACgBeo1hkojDYuLqsglyh728XtuAnYMtCUqY7MeIRaH0Da+dPp0T6QNr Qj/0tntKjsie0BMKw7SQmO48Mtm51/B+oqn5a/cNnDLg X-Google-Smtp-Source: AA6agR55aBQUDSyT/+u5yoj6++wFsxjt19++JzyisDUOE+rV6605Pv1unrz3pJ8jKzh6WW58LzrS5e7tVa/78LeCDc0= X-Received: by 2002:a5d:64ec:0:b0:21e:9396:b0ff with SMTP id g12-20020a5d64ec000000b0021e9396b0ffmr4177785wri.411.1659155978308; Fri, 29 Jul 2022 21:39:38 -0700 (PDT) MIME-Version: 1.0 References: <20220711234729.2E9F418C096@mercury.lcs.mit.edu> <9293a145-bdd1-bd79-0977-6f825da56093@osta.com> In-Reply-To: <9293a145-bdd1-bd79-0977-6f825da56093@osta.com> From: Gavin Tersteeg Date: Fri, 29 Jul 2022 23:39:28 -0500 Message-ID: To: heinz@osta.com Content-Type: multipart/alternative; boundary="000000000000b6d21405e4fe5adc" Message-ID-Hash: AXLKSWEFTFL7227W67SR4EZF2PSXO56Y X-Message-ID-Hash: AXLKSWEFTFL7227W67SR4EZF2PSXO56Y X-MailFrom: gctersteeg@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: LSX issues and musing List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000b6d21405e4fe5adc Content-Type: text/plain; charset="UTF-8" Thank you for the documents. The information there about continuous files and the background process will be extremely helpful if I ever try to make those work in the future. Right now I have "mount" and "umount" successfully implemented (I think). This leaves me with about 1.9kb of space left in the kernel for additional drivers, which I am pretty happy with. I also implemented /etc/rc support in the LSX init program so I didn't have to manually mount everything each reboot. Unfortunately, my good luck ends here. In my attempt to create a single RK05 disk with all of the system and userspace source, I noticed that the LSX "mkfs" was hardcoded to create filesystems with 6 blocks of inodes. This maxed the number of files on a disk to 96, but even with the maximum circumvented LSX would only tolerate a maximum of 101 files. A fresh filesystem that was mkfs'd on stock V6 can be mounted on LSX, but any attempt to create files on it will fail. Interestingly enough, existing large V6 RK05 images can be mounted, read from, and written to. The only limitations on these pre existing images is that if enough files are deleted, the system will randomly crash. Obviously something is seriously wrong, but I can't seem to find out what it is. I do not have any of the special LSX filesystem options enabled on the kernel or mkfs. The good news is that the fork issue seems to be tied to hitting the backspace key. If backspace is hit during any line input, the next program that tries to use fork will fail. I haven't really looked into why as I am trying to figure out this mkfs stuff first. On Wed, Jul 27, 2022 at 11:25 AM Heinz Lycklama wrote: > Gavin, looks like you have figured most things out about LSX > and Mini-Unix (both of which I am the other of while at BTL). > There are some similarities between the two but LSX is more > complex because it supports some real-time features and > contiguous files. I was able to compile the operating system > source code for both running on themselves while at BTL. > > I'm not familiar with all of the work done by others since then, > but there is some original documentation for each of the > systems still available. LSX is documented in the BSTJ, and > there is a memo on MIni-UNIX online here: > 1. http://www.tavi.co.uk/unixhistory/mini-unix/Mini-UNIX_Memo.txt > [Explains mods made to programs. Much of this applies to LSX] > 2. https://www.tuhs.org/cgi-bin/utree.pl?file=Mini-Unix/usr/doc/new/ > 3. https://gunkies.org/wiki/MINI-UNIX > You can also find my original memo on Mini-UNIX [titled > TM-77-1352-1_The_MINI-UNIX_19770103.pdf] in this > online directory of my Technical Memos. > 4. > https://tuhs.pdp-11.org.ru/Documentation/TechReports/Heinz_Tech_Memos/ > The files in #4 also used to be online in https://tuhs.org/ > but I can't seem to find them at this time. > > Hope this is all helpful to you. > > Heinz > > On 7/27/2022 1:02 AM, Gavin Tersteeg wrote: > > 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 > 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 >> 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 >>> >> > --000000000000b6d21405e4fe5adc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the documents. The information there about c= ontinuous files and the background process will be extremely=C2=A0helpful i= f I ever try to make those work in the future.

Right now= I have "mount" and "umount" successfully implemented (= I think). This leaves me with about 1.9kb of space left in the kernel for a= dditional drivers, which I am pretty happy with. I also implemented=C2=A0/e= tc/rc support in the LSX init program so I didn't have to manually moun= t everything each reboot.=C2=A0

Unfortunately, my = good luck ends here. In my attempt to create a single RK05 disk with all of= the system and userspace source, I noticed that the LSX "mkfs" w= as hardcoded to create filesystems with 6 blocks of inodes. This maxed the = number of files on a disk to 96, but even with the maximum circumvented LSX= would only tolerate a maximum of 101 files. A fresh filesystem that was mk= fs'd on stock V6 can be mounted on LSX, but any attempt to create files= on it will fail. Interestingly enough, existing large V6 RK05 images can b= e mounted, read from, and written to. The only limitations on these pre exi= sting images is that if enough files are deleted, the system will randomly = crash. Obviously something is seriously wrong, but I can't seem to find= out what it is. I do not have any of the special LSX filesystem options en= abled on the kernel or mkfs.

The good news is that= the fork issue seems to be tied to hitting the backspace key. If backspace= is hit during any line input, the next program that tries to use fork will= fail. I haven't really looked into why as I am trying to figure out th= is mkfs stuff first.

On Wed, Jul 27, 2022 at 11:25 AM Heinz Lycklama &= lt;heinz@osta.com> wrote:
=20 =20 =20
Gavin, looks like you have figured most things out about LSX
and Mini-Unix (both of which I am the other of while at BTL).
There are some similarities between the two but LSX is more
complex because it supports some real-time features and
contiguous files. I was able to compile the operating system
source code for both running on themselves while at BTL.

I'm not familiar with all of the work done by others since then, but there is some original documentation for each of the
systems still available. LSX is documented in the BSTJ, and
there is a memo on MIni-UNIX online here:
=C2=A0=C2=A0=C2=A0 1. http://www.tavi.co.uk/unixhistory/mini-unix/Mini-UNIX= _Memo.txt
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 [Explains mods made to programs. = Much of this applies to LSX]
=C2=A0=C2=A0=C2=A0 2. https://www.tuhs.org/cgi-bin/utree.pl?file=3DMin= i-Unix/usr/doc/new/
=C2=A0=C2=A0=C2=A0 3. https://gunkies.org/wiki/MINI-UNIX
You can also find my original memo on Mini-UNIX [titled
TM-77-1352-1_The_MINI-UNIX_19770103.pdf] in this
online directory of my Technical Memos.
=C2=A0=C2=A0=C2=A0 4. https://tuhs.pdp-11.org.ru/Documentation/Tech= Reports/Heinz_Tech_Memos/
The files in #4 also used to be online in https://tuhs.org/
but I can't seem to find them at this time.

Hope this is all helpful to you.

Heinz

On 7/27/2022 1:02 AM, Gavin Tersteeg wrote:
=20
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 bro= ken 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=C2=A0"OSSIZ" in order to buil= d 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&#= 39;t start with this.

Speaking of the C compiler, mounting the "cc.dsk" fi= le from the archives on LSX is a bad idea. Unlike every other image, it is formatted for 500 blocks instead=C2=A0of 400. Trying to wri= te 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=C2=A0to the kernel. The first go= al 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=C2=A0differently, 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=C2=A0"bdevsw[]", some modifica= tions to "bio.c", and a whole lot of tinkering I was able to get= RK0 auto-mounted on "/mnt". Should make moving lots of file= s *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 kerne= l 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@gmail.com> wrote:
Well, I have spent a few more days=C2=A0tentativ= ely 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=C2=A0"?" 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=C2=A01st pass. If the 1st pass was failing to run, then that would explain why the 2nd pass isn't able to find=C2=A0that 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=C2=A0obvious...

On Mon, Jul 11, 2022 at 6:47 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
=C2=A0 =C2=A0= > From: Paul Ruizendaal

=C2=A0 =C2=A0 > Note that LSX only holds one process in co= re and swaps other processes
=C2=A0 =C2=A0 > (NPROC =3D 3) out to floppy. It reportedly= took several hours for the
=C2=A0 =C2=A0 > 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.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Noel

--000000000000b6d21405e4fe5adc--