The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Re: LSX issues and musing
@ 2022-07-11 21:06 Noel Chiappa
  0 siblings, 0 replies; 21+ messages in thread
From: Noel Chiappa @ 2022-07-11 21:06 UTC (permalink / raw)
  To: gctersteeg, tuhs; +Cc: jnc

It would be really appreciated if people replying to messages like this would
take 10 minutes (or so - that's about how lonfg it took me to find the actual
answer to this person's question) to do some research, instead of just
replying off the top of their heads with whatever they happen to think they
know.

    > From: Gavin Tersteeg        
       	
    > I can't seem to get the kernel to actually link together once
    > everything is compiled. When the final "ld -X" is executed, I always
    > get the following errors:
    > "Undefined:
    > _end
    > _edata
    > _decmch"

The first two are automagically defined by the linker after a successful
read-through of the files+libraries, i.e. when then are no un-defined
symbols. Ignore them; they will go away when you fix the problem.

The real issue is the missing 'decmch'. That apparently comes from decfd.c,
which I assume is the DEC floppy disk driver. Depending on the setting of the
EIS conditional compilation flag (a different one for C files, from the
PDP-11 assembler files, please note - and I haven't worked out what its
definitiion means; whether if defined, it means the machine _does_ have the
EIS, or _does not_x), it will be called for.

'decmch' is in low.s (rather oddly; that usualy holds just interrupt vectors
and interrupt toeholds), conditionally assembled on:

	.if DEC
	.if EIS-1

The first line presumably adds it if there _is_ a DEC floppy disk, the second
I don't know _for sure_ the sense of (although I'm guessing that EIS=1 means
there _is_ an EIS chip, so this line says 'assemble if there it _not_ an EIS
chip').

Although you'd think that whatever calculation it is doing, it would need to
do if there's an EIS chip or not, so with an EIS chip it must calculate it
some other way; you'll have to read decfd.c and see how it works.

Note that you'll have to make sure the EIS flags (note plural) are set
to the same sense, when compiling the C and assembler files...


Let me send this off, and I'll reply to some other points in a
separate message.

	Noel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
@ 2022-08-05  4:35 Paul Ruizendaal via TUHS
  0 siblings, 0 replies; 21+ messages in thread
From: Paul Ruizendaal via TUHS @ 2022-08-05  4:35 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society


> Any ideas on why businesses didn’t pick up the H11 in 1980?
> 	[priced too high for hobbyists]
> 
> Wikipedia says:
> 
> 	1978: H11 US$1295 (kit) or US$1595 fully assembled ("4kword base system”) 
> 			display advert <http://www.decodesystems.com/heathkit-h11-ad-1.gif> $1295 kit + postage/freight, bare system, 8KB (4kword), 6 Q-bus slots free. ROM ?
> 
> 	1981: IBM 5150(PC) US$1,565 for "16 KB RAM, Color Graphics Adapter, and no disk drives.”
> 			( I only saw 5150’s with 2x 5.25” 360KB floppies included - otherwise, can’t run programs & store files)

Note that those are nominal prices. In terms of purchasing power USD 1595 in 1978 equated about USD 2200 in 1981 (https://www.in2013dollars.com/us/inflation/1978?endYear=1981&amount=1595).

Otherwise agree with your observation on packaged, off-the-shelf software being the main driver. In small business before the IBM PC, Visicalc drove Apple II uptake; Wordstar, C-Basic 2 and DBase drove CP/M uptake.

Would LSI-11 hardware with LSX, ed and nroff have been competitive in small business? The experiences of John Walker (of AutoCAD fame) suggests not:

https://www.fourmilab.ch/documents/marinchip/


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
@ 2022-08-03 15:17 Noel Chiappa
  0 siblings, 0 replies; 21+ messages in thread
From: Noel Chiappa @ 2022-08-03 15:17 UTC (permalink / raw)
  To: gctersteeg, tuhs; +Cc: jnc

    > Also, another problem with trying to 'push' LSX into a previously
    > un-handled operating regions (e.g. large disks, but there are likely
    > others) is that there are probably things that are un-tested in that
    > previously unused operating mode, and there may be un-found bugs that
    > you trip across.

'Speak of the devil, and hear the sound of his wings.'

    >> From: Gavin Tersteeg

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

    > I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and
    > alloc.c), but I couldn't quickly find the cause; it isn't obvious.

I don't know if the following is _the_ cause of the crashes, but another
problem (another aspect of the '100 free inodes cache' thing) swam up out of
my brain. If you look at V6's alloc$ifree(), it says:

	if(fp->s_ninode >= 100)
		return;
	fp->s_inode[fp->s_ninode++] = ino;

LSX's is missing the first two lines. So, if you try and free more than 100
inodes on LSX, the next line will march out of the s_inode array and smash
other fields in the in-core copy of the super-block.

Like I said, this is not certain to be the cause of those crashes; and it's
not really a 'bug' (as in the opening observation) - but the general sense of
that observation is right on target. LSX is really designed to operate only
on disks with less than 100 inodes, and tring to run it elsewhere is going to
run into issues.

How many similar limitations exist in other areas I don't know.


    > From: Heinz Lycklama <heinz@osta.com>

    > Remember that the LSX and Mini-UNIX systems were developed for two
    > different purposes.

Oh, that's understood - but this just re-states my observation, that LSX was
designed to operate in a certain environment, and trying to run it elsewhere
is just asking for problems.

	Noel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-08-03  4:32     ` steve jenkin
  2022-08-03  4:55       ` Ron Natalie
@ 2022-08-03  5:09       ` G. Branden Robinson
  1 sibling, 0 replies; 21+ messages in thread
From: G. Branden Robinson @ 2022-08-03  5:09 UTC (permalink / raw)
  To: steve jenkin; +Cc: Gavin Tersteeg, TUHS

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

At 2022-08-03T14:32:10+1000, steve jenkin wrote:
> Price didn’t win the market. IBM’s 5150 was never “cheapest” or
> technically “best” at any time - hence rapid rise of (variable
> quality) clones, built down to a price.
> 
> Wikipedia says:
> 
> 	1978: H11 US$1295 (kit) or US$1595 fully assembled ("4kword base system”)
> 			display advert
> 			<http://www.decodesystems.com/heathkit-h11-ad-1.gif>
> 			$1295 kit + postage/freight, bare system, 8KB
> 			(4kword), 6 Q-bus slots free. ROM ?
> 
> 	1981: IBM 5150(PC) US$1,565 for "16 KB RAM, Color Graphics
> 	Adapter, and no disk drives.”
> 			( I only saw 5150’s with 2x 5.25” 360KB floppies
> 			included - otherwise, can’t run programs & store
> 			files)

Yeah, you could.  You simply didn't store stuff to disks.

You used audio cassette tape.

https://en.wikipedia.org/wiki/IBM_cassette_tape

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-08-03  4:32     ` steve jenkin
@ 2022-08-03  4:55       ` Ron Natalie
  2022-08-03  5:09       ` G. Branden Robinson
  1 sibling, 0 replies; 21+ messages in thread
From: Ron Natalie @ 2022-08-03  4:55 UTC (permalink / raw)
  To: steve jenkin, Gavin Tersteeg; +Cc: TUHS

The H11 was made worse by the matching H9 terminal which was a real 
turkey.    Rather than having regular key caps, it just had lots of 
identical buttons which you stuck stickers to with the letters, etc..    
In addition, if you sent it lower case letters, it printed gibberish 
rather than just showing upper case versions of it.   You had to home 
lcase mode in stty worked properly.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-08-02 17:56   ` Gavin Tersteeg
@ 2022-08-03  4:32     ` steve jenkin
  2022-08-03  4:55       ` Ron Natalie
  2022-08-03  5:09       ` G. Branden Robinson
  0 siblings, 2 replies; 21+ messages in thread
From: steve jenkin @ 2022-08-03  4:32 UTC (permalink / raw)
  To: Gavin Tersteeg; +Cc: TUHS

> On 3 Aug 2022, at 03:56, Gavin Tersteeg <gctersteeg@gmail.com> wrote:
> 
>  My target system (A Heathkit H11) does have the full 56K of memory,

I wasn’t aware of the Heathkit H11 in 1980. 
Did work with someone circa 1984 that owned a DEC device, a VT71 or VT72, that had an LSI-11 + Q-Bus inside.

The H11 wasn’t that differently priced to the IBM PC 3 years later, at least for an entry system.

Any ideas on why businesses didn’t pick up the H11 in 1980?
	[priced too high for hobbyists]

Possibly: Marketing, ’support’, form-factor/physical size, peripherals - no display / keyboard on H11, serial terminal - or ’software’ availability?
Price didn’t win the market. IBM’s 5150 was never “cheapest” or technically “best” at any time - hence rapid rise of (variable quality) clones, built down to a price.

Gates, Allen & Ballmer understood business users wanted “Off the Shelf Software" from Independent Software Vendors (ISV’s).
For ISV's to target/support MS-DOS 1.0, Microsoft provided a mechanical translation tool to convert from CP/M executable to MS-DOS.

Wikipedia says:

	1978: H11 US$1295 (kit) or US$1595 fully assembled ("4kword base system”) 
			display advert <http://www.decodesystems.com/heathkit-h11-ad-1.gif> $1295 kit + postage/freight, bare system, 8KB (4kword), 6 Q-bus slots free. ROM ?

	1981: IBM 5150(PC) US$1,565 for "16 KB RAM, Color Graphics Adapter, and no disk drives.”
			( I only saw 5150’s with 2x 5.25” 360KB floppies included - otherwise, can’t run programs & store files)
			( we had someone buy an almost clone with 2x 8” floppies, @ 1.2MB each to run a database they had, 320/360K didn’t cut it )

--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-08-01  5:37 ` Heinz Lycklama
@ 2022-08-02 17:56   ` Gavin Tersteeg
  2022-08-03  4:32     ` steve jenkin
  0 siblings, 1 reply; 21+ messages in thread
From: Gavin Tersteeg @ 2022-08-02 17:56 UTC (permalink / raw)
  To: heinz; +Cc: tuhs, jnc

[-- Attachment #1: Type: text/plain, Size: 6919 bytes --]

I was heavily considering using Mini-UNIX for this project, but picked LSX
for a few reasons. The biggest reason is that Mini-UNIX has features that I
don't really need, and I figured it would be easier to add what I wanted to
LSX than remove what I didn't from Mini-UNIX. My target system (A Heathkit
H11) does have the full 56K of memory, but I would like to get as much user
space as possible. It will also be running on the equivalent of a RX02 disk
system, not a high speed spinning disk that Mini-UNIX seems to expect.
Regardless, if LSX proves to be too much of a hassle, I will probably just
switch to Mini-UNIX.

The inode allocation stuff seems to be what is causing the issues. When I
mount the filesystem on stock V6, create a file, and then remount it on
LSX, it (seems) to work again. Hopefully this code isn't too hard to add
back, but if need be I can live with the 100 file limit. Unless I decide to
try to get a hard drive hooked up, of course.

Right now I am working on getting the hardware up and running again. I am
hoping to bring all of this to VCFMW to show off, but since I have to go
back to college in a few weeks I have a lot of work ahead of me.

Thank you for the help,
Gavin

On Mon, Aug 1, 2022 at 12:37 AM Heinz Lycklama <heinz@osta.com> wrote:

> Remember that the LSX and Mini-UNIX systems were
> developed for two different purposes.
>      1. LSX had limited resources available to it and thus
>          some general-purpose features had to be removed.
>          LSX supported some new features for the support
>          of real-time systems and intelligent terminals. The
>          features included contiguous files and asynchronous
>          read/write capabilities.
>      2. Mini-UNIX was developed to run on PDP11/10 computers
>          without memory management support at the hardware level.
>          Larger main memory and faster larger disks were available.
>          It was designed to support up to four users at a time, and
>          thus needed to support the latest UNIX System features
>          without the additional features available on LSX.
>
> To answer the question below about kernel code to create
> contiguous - the only change in the kernel code was to
> recognize a contiguous file in the inode. The actual file
> had to be created by a system program to keep the
> kernel as small as possible.
>
> Heinz
>
> On 7/31/2022 12:57 PM, Noel Chiappa wrote:
> > {I was going to reply to an earlier message, but my CFS left me with
> > insufficient energy; I'll try and catch up on the points I was goibf to
> make
> > here.}
> >
> >      > From: Gavin Tersteeg
> >
> >      > This leaves me with about 1.9kb of space left in the kernel for
> >      > additional drivers
> >
> > I'm curious how much memory you have in your target system; it must not
> be a
> > lot, if you're targeting LSX.
> >
> > I ask because LSX has been somewhat 'lobotimized' (I don't mean that in a
> > negative way; it's just recognition that LSX has had a lot of corners
> > trimmed, to squeeze it down as much as possible), and some of those trims
> > behind some of the issues you're having (below).
> >
> > At the time the LSI-11 came out, semiconductor DRAM was just getting
> started,
> > so an LSI-11 with 8KB onboard and a 32KB DRAM card (or four 8KB MMV11
> core
> > memory cards :-), to produce the 40KB target for LSX systems, was then a
> > reasonable configuration. These days, one has to really search to find
> > anything smaller than 64KB...
> >
> > It might be easier to just run MINI-UNIX (which is much closer to V6, and
> > thus a known quantity), than add a lot of things back in to LSX to
> produce
> > what will effectively be MINI-UNIX; even if you have to buy a bit more
> QBUS
> > memory for the machine.
> >
> >
> >      > 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.
> >
> > And here you're seeing the 'lobotomizing' of LSX come into play. That
> '101'
> > made me suspicious, as the base V6 'caches' 100 free inodes in the
> > super-block; once those are used, it scans the ilist on disk to refill
> it.
> >
> > The code in alloc$ialloc in LSX is hard to understand (there are a lot of
> > #ifdef's), and it's very different from the V6 code, but I'm pretty sure
> it
> > doesn't refill the 'cache' after it uses the cached 100 free inodes. So,
> you
> > can have as many free inodes on a disk as you want, but LSX will never
> use
> > more than the first 100.
> >
> > (Note that the comment in the LSX source "up to 100 spare I nodes in the
> > super block. When this runs out, a linear search through the I list is
> > instituted to pick up 100 more." is inaccurate; it probably wasn't
> updated
> > after the code was changed. ISTR tis is true of a lot of the comments.)
> >
> > Use MINI-UNIX.
> >
> >     > 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.
> >
> > The V6 'mkfs' does not fill the free inode cache in the super-block. So,
> it's
> > empty when you start out. The LSX ialloc() says:
> >
> >       if(fp->s_ninode > 0) {
> >       ...
> >       }
> >       u.u_error = ENOSPC;
> >       return(NULL);
> >
> > which would produce what you're seeing.
> >
> > Also, another problem with trying to 'push' LSX into a previously
> un-handled
> > operating regions (e.g. large disks, but there are likely others) is that
> > there are probably things that are un-tested in that previously unused
> > operating mode, and there may be un-found bugs that you trip across.
> >
> > Use MINI-UNIX.
> >
> >      > 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.
> >
> > I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and
> alloc.c),
> > but I couldn't quickly find the cause; it isn't obvious. (When unlinking
> a
> > file, the blocks in the file have to be freed - that's inode 'ip' - and
> the
> > directory - inode 'pp' - has to be updated; so it's pretty complicated.)
> >
> > Use MINI-UNIX.
> >
> >
> >     > The information there about continuous files ... will be extremely
> >     > helpful if I ever try to make those work in the future.
> >
> > My recollection is that the LSX kernel doesn't have code to create
> contiguous
> > files; the LSX page at the CHWiki says "the paper describing LSX
> indicates
> > there were two separate programs, one to allocate space for such files,
> and
> > one to move a file into such an area, but they do not seem to be
> extant". If
> > you find them, could you let me know? Thanks.
> >
> >       Noel
>
>

[-- Attachment #2: Type: text/html, Size: 8234 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-07-31 19:57 Noel Chiappa
@ 2022-08-01  5:37 ` Heinz Lycklama
  2022-08-02 17:56   ` Gavin Tersteeg
  0 siblings, 1 reply; 21+ messages in thread
From: Heinz Lycklama @ 2022-08-01  5:37 UTC (permalink / raw)
  To: tuhs, gctersteeg, jnc

Remember that the LSX and Mini-UNIX systems were
developed for two different purposes.
     1. LSX had limited resources available to it and thus
         some general-purpose features had to be removed.
         LSX supported some new features for the support
         of real-time systems and intelligent terminals. The
         features included contiguous files and asynchronous
         read/write capabilities.
     2. Mini-UNIX was developed to run on PDP11/10 computers
         without memory management support at the hardware level.
         Larger main memory and faster larger disks were available.
         It was designed to support up to four users at a time, and
         thus needed to support the latest UNIX System features
         without the additional features available on LSX.

To answer the question below about kernel code to create
contiguous - the only change in the kernel code was to
recognize a contiguous file in the inode. The actual file
had to be created by a system program to keep the
kernel as small as possible.

Heinz

On 7/31/2022 12:57 PM, Noel Chiappa wrote:
> {I was going to reply to an earlier message, but my CFS left me with
> insufficient energy; I'll try and catch up on the points I was goibf to make
> here.}
>
>      > From: Gavin Tersteeg
>
>      > This leaves me with about 1.9kb of space left in the kernel for
>      > additional drivers
>
> I'm curious how much memory you have in your target system; it must not be a
> lot, if you're targeting LSX.
>
> I ask because LSX has been somewhat 'lobotimized' (I don't mean that in a
> negative way; it's just recognition that LSX has had a lot of corners
> trimmed, to squeeze it down as much as possible), and some of those trims
> behind some of the issues you're having (below).
>
> At the time the LSI-11 came out, semiconductor DRAM was just getting started,
> so an LSI-11 with 8KB onboard and a 32KB DRAM card (or four 8KB MMV11 core
> memory cards :-), to produce the 40KB target for LSX systems, was then a
> reasonable configuration. These days, one has to really search to find
> anything smaller than 64KB...
>
> It might be easier to just run MINI-UNIX (which is much closer to V6, and
> thus a known quantity), than add a lot of things back in to LSX to produce
> what will effectively be MINI-UNIX; even if you have to buy a bit more QBUS
> memory for the machine.
>
>
>      > 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.
>
> And here you're seeing the 'lobotomizing' of LSX come into play. That '101'
> made me suspicious, as the base V6 'caches' 100 free inodes in the
> super-block; once those are used, it scans the ilist on disk to refill it.
>
> The code in alloc$ialloc in LSX is hard to understand (there are a lot of
> #ifdef's), and it's very different from the V6 code, but I'm pretty sure it
> doesn't refill the 'cache' after it uses the cached 100 free inodes. So, you
> can have as many free inodes on a disk as you want, but LSX will never use
> more than the first 100.
>
> (Note that the comment in the LSX source "up to 100 spare I nodes in the
> super block. When this runs out, a linear search through the I list is
> instituted to pick up 100 more." is inaccurate; it probably wasn't updated
> after the code was changed. ISTR tis is true of a lot of the comments.)
>
> Use MINI-UNIX.
>
>     > 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.
>
> The V6 'mkfs' does not fill the free inode cache in the super-block. So, it's
> empty when you start out. The LSX ialloc() says:
>
> 	if(fp->s_ninode > 0) {
> 	...
> 	}
> 	u.u_error = ENOSPC;
> 	return(NULL);
>
> which would produce what you're seeing.
>
> Also, another problem with trying to 'push' LSX into a previously un-handled
> operating regions (e.g. large disks, but there are likely others) is that
> there are probably things that are un-tested in that previously unused
> operating mode, and there may be un-found bugs that you trip across.
>
> Use MINI-UNIX.
>
>      > 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.
>
> I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and alloc.c),
> but I couldn't quickly find the cause; it isn't obvious. (When unlinking a
> file, the blocks in the file have to be freed - that's inode 'ip' - and the
> directory - inode 'pp' - has to be updated; so it's pretty complicated.)
>
> Use MINI-UNIX.
>
>
>     > The information there about continuous files ... will be extremely
>     > helpful if I ever try to make those work in the future.
>
> My recollection is that the LSX kernel doesn't have code to create contiguous
> files; the LSX page at the CHWiki says "the paper describing LSX indicates
> there were two separate programs, one to allocate space for such files, and
> one to move a file into such an area, but they do not seem to be extant". If
> you find them, could you let me know? Thanks.
>
> 	Noel


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
@ 2022-07-31 19:57 Noel Chiappa
  2022-08-01  5:37 ` Heinz Lycklama
  0 siblings, 1 reply; 21+ messages in thread
From: Noel Chiappa @ 2022-07-31 19:57 UTC (permalink / raw)
  To: gctersteeg, tuhs; +Cc: jnc

{I was going to reply to an earlier message, but my CFS left me with
insufficient energy; I'll try and catch up on the points I was goibf to make
here.}

    > From: Gavin Tersteeg

    > This leaves me with about 1.9kb of space left in the kernel for
    > additional drivers

I'm curious how much memory you have in your target system; it must not be a
lot, if you're targeting LSX.

I ask because LSX has been somewhat 'lobotimized' (I don't mean that in a
negative way; it's just recognition that LSX has had a lot of corners
trimmed, to squeeze it down as much as possible), and some of those trims
behind some of the issues you're having (below).

At the time the LSI-11 came out, semiconductor DRAM was just getting started,
so an LSI-11 with 8KB onboard and a 32KB DRAM card (or four 8KB MMV11 core
memory cards :-), to produce the 40KB target for LSX systems, was then a
reasonable configuration. These days, one has to really search to find
anything smaller than 64KB...

It might be easier to just run MINI-UNIX (which is much closer to V6, and
thus a known quantity), than add a lot of things back in to LSX to produce
what will effectively be MINI-UNIX; even if you have to buy a bit more QBUS
memory for the machine.


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

And here you're seeing the 'lobotomizing' of LSX come into play. That '101'
made me suspicious, as the base V6 'caches' 100 free inodes in the
super-block; once those are used, it scans the ilist on disk to refill it.

The code in alloc$ialloc in LSX is hard to understand (there are a lot of
#ifdef's), and it's very different from the V6 code, but I'm pretty sure it
doesn't refill the 'cache' after it uses the cached 100 free inodes. So, you
can have as many free inodes on a disk as you want, but LSX will never use
more than the first 100.

(Note that the comment in the LSX source "up to 100 spare I nodes in the
super block. When this runs out, a linear search through the I list is
instituted to pick up 100 more." is inaccurate; it probably wasn't updated
after the code was changed. ISTR tis is true of a lot of the comments.)

Use MINI-UNIX.

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

The V6 'mkfs' does not fill the free inode cache in the super-block. So, it's
empty when you start out. The LSX ialloc() says:

	if(fp->s_ninode > 0) {
	...
	}
	u.u_error = ENOSPC;
	return(NULL);

which would produce what you're seeing.

Also, another problem with trying to 'push' LSX into a previously un-handled
operating regions (e.g. large disks, but there are likely others) is that
there are probably things that are un-tested in that previously unused
operating mode, and there may be un-found bugs that you trip across.

Use MINI-UNIX.

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

I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and alloc.c),
but I couldn't quickly find the cause; it isn't obvious. (When unlinking a
file, the blocks in the file have to be freed - that's inode 'ip' - and the
directory - inode 'pp' - has to be updated; so it's pretty complicated.)

Use MINI-UNIX.


   > The information there about continuous files ... will be extremely
   > helpful if I ever try to make those work in the future.

My recollection is that the LSX kernel doesn't have code to create contiguous
files; the LSX page at the CHWiki says "the paper describing LSX indicates
there were two separate programs, one to allocate space for such files, and
one to move a file into such an area, but they do not seem to be extant". If
you find them, could you let me know? Thanks.

	Noel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-07-27 16:24     ` Heinz Lycklama
@ 2022-07-30  4:39       ` Gavin Tersteeg
  0 siblings, 0 replies; 21+ messages in thread
From: Gavin Tersteeg @ 2022-07-30  4:39 UTC (permalink / raw)
  To: heinz; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 9082 bytes --]

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 <heinz@osta.com> 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 <gctersteeg@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@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
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 13266 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-07-27  8:02   ` Gavin Tersteeg
@ 2022-07-27 16:24     ` Heinz Lycklama
  2022-07-30  4:39       ` Gavin Tersteeg
  0 siblings, 1 reply; 21+ messages in thread
From: Heinz Lycklama @ 2022-07-27 16:24 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 7882 bytes --]

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 <gctersteeg@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@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
>

[-- Attachment #2: Type: text/html, Size: 11490 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-07-15  8:07 ` Gavin Tersteeg
@ 2022-07-27  8:02   ` Gavin Tersteeg
  2022-07-27 16:24     ` Heinz Lycklama
  0 siblings, 1 reply; 21+ messages in thread
From: Gavin Tersteeg @ 2022-07-27  8:02 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 5931 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6989 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-07-11 23:47 Noel Chiappa
@ 2022-07-15  8:07 ` Gavin Tersteeg
  2022-07-27  8:02   ` Gavin Tersteeg
  0 siblings, 1 reply; 21+ messages in thread
From: Gavin Tersteeg @ 2022-07-15  8:07 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 2935 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3492 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
@ 2022-07-11 23:47 Noel Chiappa
  2022-07-15  8:07 ` Gavin Tersteeg
  0 siblings, 1 reply; 21+ messages in thread
From: Noel Chiappa @ 2022-07-11 23:47 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > 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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
@ 2022-07-11 21:47 Paul Ruizendaal via TUHS
  0 siblings, 0 replies; 21+ messages in thread
From: Paul Ruizendaal via TUHS @ 2022-07-11 21:47 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

> If I can get this working, I have a long laundry list of modifications and
> experiments that I want to run with LSX, but as it stands, this is where I
> am stuck at.

Once upon a time there was a Soviet home computer that was based on the PDP-11, the BK0010:

https://en.wikipedia.org/wiki/Electronika_BK

(it is actually mostly a copy of the Terak 8510a -- https://en.wikipedia.org/wiki/Terak_8510/a )

The guy that found the surviving floppy with LSX source code (Leonid Broukhis) for the PDP-11 immediately ported it to the BK0010 and created a fair amount of infrastructure around it:

https://github.com/ignusius/bkunix

He used the 2.11BSD toolchain to create a cross-compiler. As that compiler had progressed significantly from the 5th Edition era compiler, the kernel became smaller and he could squeeze some stripped functionality back in. The repo says that the code there still works on a normal PDP-11.

I’ve never communicated with Leonid, but maybe Warren has contact details for him. Also, the person who created LSX unix (Heinz Lycklama) is reading this list -- but of course it has been 40+ years since he last touched the code.

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. At one point I added debugger support to my own port of LSX to a TI-990 with just floppies ... let’s just say, now I understand deeply why the original Unix debug interface was an improvement opportunity :^)



^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-07-11 21:24 Noel Chiappa
@ 2022-07-11 21:37 ` Gavin Tersteeg
  0 siblings, 0 replies; 21+ messages in thread
From: Gavin Tersteeg @ 2022-07-11 21:37 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 3675 bytes --]

A lot of it was me just learning how V6 works in general. Getting V6 to
boot on a simulated 11/23 was pretty easy (I had some issues getting it to
compile at first, but it worked after I got that sorted out). Adding the
RL02 and RX02 drivers was a tiny bit more difficult. I would say that the
most difficult part was writing a RX02 boot program, trying to fit that
into 512 bytes with interleave code took a few days.

You were right about the source of the issue. I incorrectly assumed that
the EIS flag was only set in header.lsx.s, but it is also set in param.h.
The default param.h has the EIS symbol define commented out, while
header.lsx.s has it uncommented. By uncommenting the define in param.h and
recompiling decfd.c, it allows the kernel to be successfully linked. The
current kernel that builds is too big to be used with a 16K kernel size,
but I think I just need to recompile everything with the new param.h, and
maybe adjust a few other parameters.

I will look into getting an EIS chip. I'm probably going to move up to the
20K kernel size regardless, as I need the extra memory for changes that I
want to make to the kernel. I am betting that the "0: Missing temp file"
thing is due to some sort of file I/O issue, so I'll read into the compiler
source to see what is generating it.

On Mon, Jul 11, 2022 at 4:24 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > From: Gavin Tersteeg
>
>     > I spent a lot of time getting UNIX V6 working on my PDP-11/23 system.
>     > It took a lot of tinkering with the kernel and drivers to make it
> work
>     > in the way I wanted to
>
> You must have made a lot of changes for it to take "a lot of tinkering".
> Bringing V6 up on the /23 has been done several times, and when I did
> it, it only took about 2 dozen lines of code in about 2 files. What all
> did you wind up changing?
>
>
>     > From my research, it seems like there were two different UNIX
> variants
>     > that could run on a system like this. These variants were LSX and
>     > MINI-UNIX. MINI-UNIX seems to require a decent mass-storage device
> like
>     > a RK05 and some porting to work on an 11/03, while LSX is designed to
>     > work on exactly the hardware specs that I have on hand.
>
> Bringing up MINI-UNIX on the /03 has been done at least twice; once
> historically (now lost, AFAIK), and again recently:
>
>     http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/Mini.html
>
> I'm not sure what you're basing the "MINI-UNIX seems to require a decent
> mass-storage device like a RK05" on - it should run as well on whatever
> you're running LSX on as LSX does.
>
> I haven't run LSX myself, but from what I've seen, the only significant
> difference between the two is that LSX will run with less main memory than
> MINI-UNIX (which really kind of needs 56KB; LSX you can probably get away
> with 40KB).That was a significant issue when the LSI-11 was originally
> released, but these days one has to really work to have a QBUS PDP-11 with
> less than 56KB.
>
>
>     > my EIS-less 11/03
>
> EIS chips can be found on eBait for not much money (I just bought a couple
> myself), and it's worth investing in one, so on can dispense with the
> emulator, which takes real memory for which a better use can be found.
>
>     > The first issue is that the C compiler will randomly spit out a "0:
>     > Missing temp file" when attempting to compile something. This is
>     > annoying, but circumventable by just running the same command over
> and
>     > over until it works.
>
> Schaeffer's Law (from Larry Niven): anything you don't understand
> might be dangerous. I'd track down why this is happening.
>
>         Noel
>

[-- Attachment #2: Type: text/html, Size: 4460 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
@ 2022-07-11 21:24 Noel Chiappa
  2022-07-11 21:37 ` Gavin Tersteeg
  0 siblings, 1 reply; 21+ messages in thread
From: Noel Chiappa @ 2022-07-11 21:24 UTC (permalink / raw)
  To: gctersteeg, tuhs; +Cc: jnc

    > From: Gavin Tersteeg        
       	
    > I spent a lot of time getting UNIX V6 working on my PDP-11/23 system.
    > It took a lot of tinkering with the kernel and drivers to make it work
    > in the way I wanted to

You must have made a lot of changes for it to take "a lot of tinkering".
Bringing V6 up on the /23 has been done several times, and when I did
it, it only took about 2 dozen lines of code in about 2 files. What all
did you wind up changing?


    > From my research, it seems like there were two different UNIX variants
    > that could run on a system like this. These variants were LSX and
    > MINI-UNIX. MINI-UNIX seems to require a decent mass-storage device like
    > a RK05 and some porting to work on an 11/03, while LSX is designed to
    > work on exactly the hardware specs that I have on hand.

Bringing up MINI-UNIX on the /03 has been done at least twice; once
historically (now lost, AFAIK), and again recently:

    http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/Mini.html

I'm not sure what you're basing the "MINI-UNIX seems to require a decent
mass-storage device like a RK05" on - it should run as well on whatever
you're running LSX on as LSX does.

I haven't run LSX myself, but from what I've seen, the only significant
difference between the two is that LSX will run with less main memory than
MINI-UNIX (which really kind of needs 56KB; LSX you can probably get away
with 40KB).That was a significant issue when the LSI-11 was originally
released, but these days one has to really work to have a QBUS PDP-11 with
less than 56KB.


    > my EIS-less 11/03

EIS chips can be found on eBait for not much money (I just bought a couple
myself), and it's worth investing in one, so on can dispense with the
emulator, which takes real memory for which a better use can be found.

    > The first issue is that the C compiler will randomly spit out a "0:
    > Missing temp file" when attempting to compile something. This is
    > annoying, but circumventable by just running the same command over and
    > over until it works.

Schaeffer's Law (from Larry Niven): anything you don't understand
might be dangerous. I'd track down why this is happening.

	Noel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-07-11 19:47 [TUHS] " Gavin Tersteeg
  2022-07-11 20:01 ` [TUHS] " Warner Losh
@ 2022-07-11 20:37 ` Phil Budne
  1 sibling, 0 replies; 21+ messages in thread
From: Phil Budne @ 2022-07-11 20:37 UTC (permalink / raw)
  To: tuhs, gctersteeg

A quick google for _decmch found:

https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/low.s

.....
.if DEC
.if EIS-1
.globl	_decmch

rxcs = 177170
rxdb = 177172

_decmch:
	mov	r2,-(sp)
	mov	$rxdb,r1
	mov	4(sp),r0
	asl	r0
	add	4(sp),r0
	clr	r2
.....


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-07-11 20:26   ` Clem Cole
@ 2022-07-11 20:30     ` Warner Losh
  0 siblings, 0 replies; 21+ messages in thread
From: Warner Losh @ 2022-07-11 20:30 UTC (permalink / raw)
  To: Clem Cole; +Cc: Gavin Tersteeg, The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

On Mon, Jul 11, 2022 at 2:27 PM Clem Cole <clemc@ccc.com> wrote:

> @Warner Losh <imp@bsdimp.com>
>
> On Mon, Jul 11, 2022 at 4:03 PM Warner Losh <imp@bsdimp.com> wrote:
>
>>
>> _end is the end of the text segment. _edata same for the data. You can
>> create these two by just creating a file that defines them as symbols = .
>> And global. And link that file last. Though crt is supposed to have that.
>>
> Hmmm -- I might have miss remembered this...  but I'm pretty sure the way
> ld(1) worked is that it supplied _edata, _etext, and _end automagically
> by ld(1) IIF, there are no other undefined symbols. Adding them into a file
> is probably not going to get what you want.
>

Oh right, _etext, _edata and _end are supposed to be linker creatures
(created by the linker), but I can't recall when the linker started doing
that...


>
>> _decmch is likely in m.s so maybe that's not included.  Iirc it should be
>> next to last...
>>
> My bet is this key to the whole issue he is having.  If Gavin can figures
> out what gives WRT _decmch, I bet it links.
>

That's the area I'd try first... But I'd expect both data and bss symbols
to be scattered in many of the other files though... It may be something as
simple as an empty .o file from those compiler runs that failed...


> @Gavin Tersteeg <+gctersteeg@gmail.com> -- I would trust Warner's memory
> more than mine since he tries to keep 2.9BSD alive,  but he knows I go back
> to V5 and the early/mid 70s; but bits in my memory have decayed over the
> years. Suggestion, take a quick peek in the sources to ld.c  and look for
> it hard coding the check for those three symbols.  They will look up as
> undefined originally, then latter get set to values only if there are no
> other UNDEFINED symbols.
>

 2.11BSD, but who's counting :)

Warner

> ᐧ
>

[-- Attachment #2: Type: text/html, Size: 4662 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-07-11 20:01 ` [TUHS] " Warner Losh
@ 2022-07-11 20:26   ` Clem Cole
  2022-07-11 20:30     ` Warner Losh
  0 siblings, 1 reply; 21+ messages in thread
From: Clem Cole @ 2022-07-11 20:26 UTC (permalink / raw)
  To: Warner Losh; +Cc: Gavin Tersteeg, The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

@Warner Losh <imp@bsdimp.com>

On Mon, Jul 11, 2022 at 4:03 PM Warner Losh <imp@bsdimp.com> wrote:

>
> _end is the end of the text segment. _edata same for the data. You can
> create these two by just creating a file that defines them as symbols = .
> And global. And link that file last. Though crt is supposed to have that.
>
Hmmm -- I might have miss remembered this...  but I'm pretty sure the way
ld(1) worked is that it supplied _edata, _etext, and _end automagically by
ld(1) IIF, there are no other undefined symbols. Adding them into a file is
probably not going to get what you want.

>
> _decmch is likely in m.s so maybe that's not included.  Iirc it should be
> next to last...
>
My bet is this key to the whole issue he is having.  If Gavin can figures
out what gives WRT _decmch, I bet it links.

@Gavin Tersteeg < gctersteeg@gmail.com> -- I would trust Warner's memory
more than mine since he tries to keep 2.9BSD alive,  but he knows I go back
to V5 and the early/mid 70s; but bits in my memory have decayed over the
years. Suggestion, take a quick peek in the sources to ld.c  and look for
it hard coding the check for those three symbols.  They will look up as
undefined originally, then latter get set to values only if there are no
other UNDEFINED symbols.

> ᐧ

[-- Attachment #2: Type: text/html, Size: 3512 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] Re: LSX issues and musing
  2022-07-11 19:47 [TUHS] " Gavin Tersteeg
@ 2022-07-11 20:01 ` Warner Losh
  2022-07-11 20:26   ` Clem Cole
  2022-07-11 20:37 ` Phil Budne
  1 sibling, 1 reply; 21+ messages in thread
From: Warner Losh @ 2022-07-11 20:01 UTC (permalink / raw)
  To: Gavin Tersteeg; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2821 bytes --]

On Mon, Jul 11, 2022, 1:48 PM Gavin Tersteeg <gctersteeg@gmail.com> wrote:

> Hello, and greetings!
>
> I guess as this is my first post here, I should give some u background on
> what I have been working on. Last summer I spent a lot of time getting UNIX
> V6 working on my PDP-11/23 system. It took a lot of tinkering with the
> kernel and drivers to make it work in the way I wanted to, but in the end I
> was left with a system that ran well enough to do some demonstrations at
> VCFMW.
>
> This year I want to do more stuff with 1970s era UNIX, but now with even
> more technical restrictions. I have had a Heathkit H-11 (consumer grade
> PDP-11/03) for a while now, and I have been looking for something
> interesting to do with it. From my research, it seems like there were two
> different UNIX variants that could run on a system like this. These
> variants were LSX and MINI-UNIX. MINI-UNIX seems to require a decent
> mass-storage device like a RK05 and some porting to work on an 11/03, while
> LSX is designed to work on exactly the hardware specs that I have on hand.
>
> So on to the actual issues I am having at the moment: I have put together
> a SIMH instance to get the ball rolling in building a kernel that will boot
> on my EIS-less 11/03, but I am having significant difficulty actually
> getting the kernel to build. The first issue is that the C compiler will
> randomly spit out a "0: Missing temp file" when attempting to compile
> something. This is annoying, but circumventable by just running the same
> command over and over until it works. The second issue, however, is much
> more of a road block for me. I can't seem to get the kernel to actually
> link together once everything is compiled. When the final "ld -X" is
> executed, I always get the following errors:
>
> "
> Undefined:
> _end
> _edata
> _decmch
> "
> (This is from the build script found in the "shlsx" file)
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/shlsx
>
> I am assuming that this is some sort of issue with the object file
> orderings, but I simply do not know enough about V6 ld to properly debug
> this issue. I am hoping that somebody here has already run into this issue,
> and knows what I am doing wrong.
>

_end is the end of the text segment. _edata same for the data. You can
create these two by just creating a file that defines them as symbols = .
And global. And link that file last. Though crt is supposed to have that.

_decmch is likely in m.s so maybe that's not included.  Iirc it should be
next to last...

You might already have files with these symbols... nm is your friend here...

Warner

If I can get this working, I have a long laundry list of modifications and
> experiments that I want to run with LSX, but as it stands, this is where I
> am stuck at.
>
> Thank you,
> Gavin
>

[-- Attachment #2: Type: text/html, Size: 3832 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2022-08-05  4:35 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-11 21:06 [TUHS] Re: LSX issues and musing Noel Chiappa
  -- strict thread matches above, loose matches on Subject: below --
2022-08-05  4:35 Paul Ruizendaal via TUHS
2022-08-03 15:17 Noel Chiappa
2022-07-31 19:57 Noel Chiappa
2022-08-01  5:37 ` Heinz Lycklama
2022-08-02 17:56   ` Gavin Tersteeg
2022-08-03  4:32     ` steve jenkin
2022-08-03  4:55       ` Ron Natalie
2022-08-03  5:09       ` G. Branden Robinson
2022-07-11 23:47 Noel Chiappa
2022-07-15  8:07 ` Gavin Tersteeg
2022-07-27  8:02   ` Gavin Tersteeg
2022-07-27 16:24     ` Heinz Lycklama
2022-07-30  4:39       ` Gavin Tersteeg
2022-07-11 21:47 Paul Ruizendaal via TUHS
2022-07-11 21:24 Noel Chiappa
2022-07-11 21:37 ` Gavin Tersteeg
2022-07-11 19:47 [TUHS] " Gavin Tersteeg
2022-07-11 20:01 ` [TUHS] " Warner Losh
2022-07-11 20:26   ` Clem Cole
2022-07-11 20:30     ` Warner Losh
2022-07-11 20:37 ` Phil Budne

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).