The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [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-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-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-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, 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 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] LSX issues and musing
@ 2022-07-11 19:47 Gavin Tersteeg
  2022-07-11 20:01 ` [TUHS] " Warner Losh
  2022-07-11 20:37 ` Phil Budne
  0 siblings, 2 replies; 21+ messages in thread
From: Gavin Tersteeg @ 2022-07-11 19:47 UTC (permalink / raw)
  To: tuhs

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

Hello, and greetings!

I guess as this is my first post here, I should give some 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.

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: 2652 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-08-03 15:17 [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-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 21:06 Noel Chiappa
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).