> I noticed a place where I used R0 as a temp ... and was being bashed.
    > So I fixed it, and now the shell starts OK, but attempting to do any
    > command (e.g. "echo foo"), things hang

Well, I had 'fixed' it; it turned out my 'fix' had a bug. :-( (The code I had
to change for the /03 there was pushing the old PS, and that and the temp I
had to push got intermangled.)

Anyway, with that fixed, the /03 Mini-Unix works now. The old user command
binaries seem to work OK on the /03; not that I've tried the all, but the ones
I have tried (including the C compiler) all worked. They all should all work
(there's nothing in user code that's model-dependent). I have tweaked the
shell (to allow 'cd') and init (to get rid of the annoying long rights
message), but that's all.

The latest, greatest mch.s is uploaded:

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

Although a couple of files (bio.c, clock.c, slp.c, and tty.c) had minor
changes (to remove direct rerferences to the PS; they now call getps() and
putps() for that), and main.c has minor changes to work when there's no KW11
or switch register, really the only file with significant changes for the /03
is mch.s. It's the only one where the object code is model-dependent; all the
other changed ones use the same object code for all CPU models.

I'll put up a Web page with details, links to sources, etc, 'soon'.


A couple of other things.

Mini-Unix has removed 'raw' devices (not sure why, probably seemed un-needed),
so other disk drivers (e.g. the RL11 driver) aren't straight drop-ins. Minimal
tweaks needed, though; just remove the read and write routines, I think.

If there was a real use for 'raw' devices, they could probably be added back,
but physio() would have to be modified (simplified). Not sure if anything else
special would be needed; the process can't be swapped while raw I/O is
ongoing, and so on Mini-Unix no other process could run. Probably OK, but
needs to be checked.

I recommend that everyone trying to run Mini-Unix on a hardware /03 invest in
a KEF11 chip. (There are a few on eBait.) That way, you can leave the EIS
emulator out of the build, which will save some space, and allow more room for
device drivers. I added kernel printf() into the build, to help with
debugging, but it can be removed to save space.

You can change the system to use more room for the kernel (see the Mini-Unix
docs), but that involves re-linking _every single user command_, including the
shell and init. Not recommended.

      Noel