> I think before I try debugging it directly, I'll try one of the other
> Mini-Unix repositories; the one I've been using (from Bob Eager's site)
> may have some bit-rot.
Well, foo, the one from TUHS has the same symptom: random re-starts. Looks
like I'm going to have to actually debug this.
I guess the first step is to work out how the re-start is happening; I suspect
it's not a trap (I'll check, but I think Mini-Unix catches them all). My best
guess is a jump to 0 (somehow); if so, that should be easy to catch. Then the
next thing is to try and work out where/how/why that is happening.
Following a suggestion of Warner Losh, I think there's a good idea on how to
make progress, which is to mount the Mini-unix pack under V6 (running on a
simulator); that's rock-solid - and the V6 tool-chain can be used to build
Mini-Unix binaries.
And here I thought it was going to be easy to convert Mini-unix to run on
an -11/03. Well, it still might - if I can get Mini-Unix to run reliably!
Noel
David C. Brock posted on Twitter links to the Bell Labs January 1968
Organizational Directory scans. The Research, Communications Sciences
Division is available at
https://drive.google.com/file/d/171jywFyIDyyWUMX4jYl3Czblqe5VGX2q/view
In it the Computing Science Research Center appears on tab 13, page 15
(PDF page 6). Most of the names are very familiar to members of this
list; some are even posting here.
Diomidis - https://www.spinellis.gr
> It is definite, though, that Q22 memory won't work with an LSI-11/2
> (M7270) ... I'll try an LSI-11 (M7264) tomorrow, make sure it's the
> same; it and the LSI-11/2 are similar enough that it should, but it'd be
> good to confirm it.
Yes, it too won't work with Q22 memory (tried it, no go - ODT won't even start).
> Then back to trying to work out why Mini-Unix is so fragile for me.
I tried some changes in the simulator set-up, to see if that would fix my
issue; no luck.
It's quite problematic: if I boot Mini-Unix on a clean copy of the RK pack, cd
to /usr/sys/dev, cp kl.c to nkl.c, and 'cc -c nlk.c', Mini-Unix reliably
restarts (trashing the disk in the process). (If I omit the 'cp', I can 'cc -c
kl.c' 3 times, and Mini-Unix restarts on the third.) Something's seriously
wrong.
I think before I try debugging it directly, I'll try one of the other
Mini-Unix repositories; the one I've been using (from Bob Eager's site) may
have some bit-rot.
> From: Paul Riley <paul(a)rileyriot.com>
> I'm checking with Peter Schranz about whether or not his RLV12/RL02
> boards can run on the '03.
Dave Bridgham and I discussed whether the QSIC would work with an -11/03, and
that analysis should apply equally to the RLV12. Our conclusion was that it
should; here's our reasoning:
The device registers on the board should work fine on either Q18 or
Q22. That's because when going to the I/O page, the CPU asserts a special bus
line, BBS7 (that says 'this cycle is to the I/O page'). The device doesn't
look at the higher address lines when that's on, just BDAL00-12; so if the
LSI-11 is messing with some of BDAL181-21, it shouldn't matter.
For DMA cycles from the device to memory, since the CPU requires Q18 memory
to work, the device too should be able to read/write to Q18 memory. At least,
that's our theory.
I guess all this PDP-11 hardware detail isn't really on-topic for this list; I
should move it to Classic Computers, or something. Sorry all; it's
intermingled with early Unix stuff, and it was easier to keep it all in one
place.
Noel
> From: Paul Riley
> Can you clarify something for me regarding memory? I understand the
> bottom area of memory in a Unix system is for the Kernel and it's stuff,
> and that the top 8kB is set aside for device I/O
Well, technically, the top 8KB of _address space_, not of memory - it's mostly
used for device registers, etc. Here:
http://gunkies.org/wiki/Unix_V6_kernel_memory_layout
is a bit more detail on how the memory is laid out.
> The LSI-11 board has 4kW of RAM on it, and I have already a 16KW
> board. If I want to further expand the RAM, and say I buy another 16kW
> board, that makes an arithmetic sum of 32kW for the boards, making 36kW
> total. Can the 4kW of on-board RAM be disabled, and only the 32kW on
> the boards be used?
Yeah, if you look at LSI-11 documentation, there are jumpers that allow
configuration of the on-board memory. Depending on the etch revision; for my F
revision, jumper W11 (at the top, towards the handle edge, in the middle of
that edge; just below the W1/W2 jumper pair) should be out to disable the
on-board memory.
Or you could configure the two 32KB boards to be at 020000 and 0120000; there
will be 72KB of memory total on the QBUS, but the LSI-11 CPU (no memory
management) will only be able to 'see' the bottom 56KB.
> Is it ok for the installed RA mto overlap the 8kW at the high memory
> area?
Yeah, what the CPU sees as the I/O page (at 0160000-0177776 in its address
space) is actually at 0760000-0777776 on the QBUS (on a Q18 QBUS); the CPU
automagically translates the 0160000-0177776 addresses up. On a PDP-11
with memory management, the MMU has to be set up to do that. E.g. in V6,
in:
https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/sys/conf/m40.s
there is the following code:
/ initialize io segment
mov $IO,(r0)+
mov $77406,(r1)+ / rw 4k
to set the I/O page in kernel address space to point to the I/O page on the
bus.
Noel
> From: Pete Turnbull
> The SRUNL signal that was mentioned isn't likely to cause a problem
That was just a guess on my part as to the exact cause. It is definite,
though, that Q22 memory won't work with an LSI-11/2 (M7270); I just tried it.
I didn't touch any of the other boards; just swapped the LSI-11/2 for a
KDF11-A (M8186), everything worked fine; put the LSI-11/2 back, dead again.
I'll try an LSI-11 (M7264) tomorrow, make sure it's the same; it and the
LSI-11/2 are similar enough that it should, but it'd be good to confirm it.
Then back to trying to work out why Mini-Unix is so fragile for me. Has
anyone else ever worked with Mini-Unix, and if so, any tips?
Noel
In a brief discussion with a coworker today the question of formatting shell scripts came up.
I believed that in the past the preferred format (if there ever were any such thing) was
if [ test ]
then
statements
else
statements
fi
I can find nothing specific to back this up. More appropriate for COFF maybe would
be a discussion of what format is better
if [ test ]; then
statements
else
statements
fi
or the above.
No intention to start any kind of flame war about which is better, just want to see
if there is any historical option for one over the other.
David
if test; then
stuff
and
if test
then
stuff
are functionally equivalent. I wouldn't say one or the
other `is preferred.' I use the former because I think
it's a little more readable because more compact. But
it's really a matter of style, like whether you write
if (test) {
(multi-statement block)
or
if (test)
{
(multi-statement block)
I have a stronger opinion about those who use overly-
cryptic constructions like
test && {
shell commands
}
because it means exactly the same thing as
if test; then
shell commands
but is more obscure to read. But again it's a question
of style, not of dogma.
As an aside, I think one excuse that is sometimes used
for that sort of construct is when it's
test || {
commands
}
because Bourne's original shell had no not operator.
For a long time after shell functions appeared, I would
add this function to any of my shell scripts that needed
it:
not() {
if "$@"; then
return 1
else
return 0
}
so I could say
if not test; then
commands
fi
Modern Bourne-shell descendants have a built-in ! operator:
if ! test; then
commands
fi
I'm not keen on most of what has been stuffed into bash and
ksh and the like, but ! is a real improvement. I believe
POSIX mandates it, and I think they're right.
Norman Wilson
Toronto ON
> From: Paul Riley
> I also have a DEC 256KB board, but I doubt I could use it on the
> '03.
Yes, DEC 256KB boards are what's called Q22, and those don't seem to work with
LSI-11's; not even CPU ODT works. I just tried a 256KB MSV11-L with an LSI-11,
and it definitely doesn't work; the MSV11-P is definitely a Q22 board, and so
probably also won't work.
What the Q22 means is that early in the lifetime of the QBUS, it only had 18
address line - so-called Q18. (Technially the LII-11 used only 16 address lines,
so it's actually Q16.) DEC latter snarfed some of the 'unused' pins, and
made them QDAL18-21. So boards that use those pins for QDAL18-21 are 'Q22'
boards.
My theory on what the problem is is that the LSI-11 uses some of those pins
for other things - I think the 'run' light, IIRC. So that confuses Q22 memory.
If one tries to use one with an LSI-11, the machine is totally dead - not even
ODT. It doesn't do any harm, though; unplug the Q22 memory, and plug in a Q18
card like an MSV11-D, and it'll be fine.
If you need memory for the LSI-11, MSV11-D boards are pretty common on eBait,
for not much. They tend to be flaky, though; sometimes they come back to life
if you leave them sit for a bit after you plug them in.
> I believe the [memory] board is non-DEC.
Well, if it's Q22 it won't work either. Both that and the DEC board should
work in the /23, though. (If you have the part number on the memory chips, a
little arithmetic should give you the board size. 256K and up are generallly
Q22; if you have a manual for that card it might say.)
I'm still working with Mini-Unix; it's very fragile. When I got it running,
the first thing I tried to do was changle the line editing characters (since
my normal ones are burned into ROM). Alas, in stock V6, DEL is hard-wired to
be 'interrupt process', so I can't just 'stty [mumble]', I have to rebuild the
kernel to change that. Not a problem, necessarily - but I edited tty.h and
said 'cc -c tty.c', and it crashed and re-started - and roached the disk. So
I'm still trying to make progress. I might have mis-configured the simulator,
I'll see.
Noel
> Turing save us from 1-complement machines!
Users of Whirlwind II were warned about the quirks of -0.
We were not warned, though, about integer divide with remainder 0.
The result of dividing 6 by 3, for example, was binary 1.111111... -
a valid answer when carried to infinity. Unfortunately, the
"fractional" part was dropped.
Most people used Whirlwind for floating-point computation, and
blithely dismissed printed answers like 1.999999 as "roundoff
errors".
Doug
> So that confuses Q22 memory. If one tries to use one with an LSI-11,
> the machine is totally dead - not even ODT.
Oh, that's another LSI-11 'feature' (only discovered after someone sent in a
help request on CCalk for a dead LSI-11): if there's no working memory at 0,
ODT won't start/run. So if the Q22 memory is confused, the whole machine is dead.
Noel
> From: Paul Riley
> I have two RLV-12/RL02 emulator boards I had made from Peter Schranz's
> design (5volts.ch). They take an SD card
Ah, you're all set, then - doubly so, in fact. Not only do you have reliable
mass storage, but you should be able to put the Unix filesystem on an SD card,
to get the bits into the machine.
I'm not familiar with that board, but it sounds pretty good; QBUS<->SD. I
don't know how that board uses the SD card, in terms of where it keeps the
RL02 image, but if you can find that out, SD<->USB3 adaptors are cheap and
plentiful, and it shouldn't be too hard to load the disk image into it using
one of them. (For the QSIC, I found a 'dd' for Winsdoze and used that to write
the disk image onto the SD card.)
> I don't have any PROMs other than what would be on the '03 or '23+
> boards now.
Not a problem: if you hook up the -11's console to another computer, you
can download a bootstrap into it over the serial line, using the -11's ODT.
(There's a page here:
http://gunkies.org/wiki/Running_an_LSI-11_from_Unix_V6
which talks briefly about how to do that. Things like PDP11GUI can do it too,
I think.) I don't use an RK bootstrap in ROM to boot from the emulated RK11 on
the QSIC; I just load in a short RK bootstrap. I don't know of one lying
around for the RL11, but one would be trivial to whip up.
Speaking of booting, I have Mini-Uix booting under an -11/05 simulator
(Ersatz-11); I used the RK image from here:
http://www.tavi.co.uk/unixhistory/mini-unix/munixrks.zip
and it just started right up. So that's the big hurdle; been busy with other
stuff, but I'll work on getting it to boot on an '03 'soon'.
You probably want to do the same; having it running under a simulator will
make it easy to build new OS images, e.g. for a system with RL02's. Build the
new system, name it 'rlmx', copy the simulator disk image into the SD card,
and away you go.
Oh, I recently realized how to make a bit more room on an -11/03: most
DEC small QBUS memory cards allow you to use half the 'I/O page' for memory,
if you need it. I.e. instead of having 56KB of memory, and 8 KB of
address space for device registers (a lot more than is really needed), the
memory can be configured to be 60KB of memory.
It can be a bit of a hassle to use it; to have more room for the OS (for more
drivers, or disk buffers, or whatever), some pieces of Mini-Unix need to be
recompiled, to move up the address where user processes are loaded. Larger
user processes are the same thing; they aren't automatically enabled when
there's more memory, you have to change a config file, recompile some things,
and build a new system.
What kind of memory card(s) do you have for the -11/03?
Noel
When someone mentioned that they'd ported V6 to the 11/23, I recalled that
I did the same thing (well, V6 + the bits of AUSAM that I liked + the bits
of V7 that I could shoe-horn in), and went looking for the article that I
could've sworn I'd published, using "pdfgrep 23 AUUGN*" in my TUHS mirror.
And yes, I recall some hardware peculiarity which had to be worked around,
but I've forgotten the details (which is why I went looking).
I didn't find it (is there an index of articles anywhere?), but I did find
some peculiar typos, and I was wondering whether they were a result of
Google's (destructive) scanning, or were in the originals.
Here's a quick sample:
AUUGN-V04.5.pdf: tailored for smaller. PDP11s (such as the 11/23 or 11/34) in an
A period after "smaller".
AUUGN-V04.6.pdf: Unfortunately. the clever Code comes unstuck as the LSI-II/23 doesn't’t
The phrase "Unfortunately. the clever Code" looks wrong.
AUUGN-V04.6.pdf:LSI-II/23 was changing the value of r! if the V-bit gets set. It seemed
"r!" should be "r1" (a possible typo, as they are the same key)..
AUUGN-V04.6.pdf: bio23 (662 2668) Elec. Eng., UNSW,
This is a weirdie; "bio23" (one of my clients) was never a part of Elec
Eng (they were their own school), so I suspect a mistake here; it's
possible, however, that they were in the same building.
AUUGN-V04.6.pdf: PDP 11/23 + FPU. RK05, RL02, DRIIb
I believe that "DR11b" should be "DR11B".
AUUGN-V05.1.pdf: PDP 11/23 - System III (Ausam)., 256k, 2xR102, 16 lines
AUSAM under System III, on a mere 11/23? I very much doubt it... Also,
"R102" should probably be "RL02".
AUUGN-V05.1.pdf: PDP 11/23, Q bus + qniverter, RK05, Pertec dual RK05, DEC dual cassette,
I suspect that "qniverter" was a typo on the part of the author.
As a bit of a Unix historian it would be a shame if those AUUGN scans were
less than accurate; I no longer have my hard copies (lost in a house
move), so perhaps someone could check their copies?
Thanks.
-- Dave
> From: Warner Losh
> I'm pretty sure PDP-10 wasn't 1's compliment / was 2's compliment..
Just to confirm, I pulled out my PDP-10 Hardware Reference Manual; Vol I - CPU
(EK-10/20-HR-001), and it does indeed say (pg. 1-12): "The fixed-point
arithmetic instructions use 2's complement representations to do binary
arithmetic." Selah.
Noel
> From: John Cowan
> if you are not messing with the kernel or drivers, I find apout to be
> delightful.
Pretty much all of what little I do with V6 anymore is kernel hacking! :-)
Noel
> From: Paul Riley
> On my physical '03 I have twin Sykes floppy drives. I note that in the
> LSX archives there is a Sykes driver, so I can adapt that I guess.
Yes, here:
https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/sykfd.c
It looks like it should be a straight drop-in, to run it on Mini-Unix. Not
sure if your controller is the exact same model, though? Is there any
documentation on yours? (I haven't done any searching.)
If you want to boot from it, you'll need to write a bootstrap for it; I poked
around, but didn't see one. (Not sure how they booted machines with one, back
in the day; maybe it wasn't the only drive, and they booted off something
else.) You can probably modify the RX one:
https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/src/rxboot.shttps://www.tuhs.org/cgi-bin/utree.pl?file=LSX/src/rxboot2.s
Note that this is a 2-stage bootstrap, apparently as a result of the small
hardware block size on the RX.
And of course there's still the issue of 'how to get bits onto it'. Can
floppies for it be written on some other kind of machine? If so, someone on
the Classic Computers list:
http://www.classiccmp.org/mailman/listinfo/cctalk
may be able to help you write those, or an RL02 pack.
You should start by getting some experience building V6 OS loads (Mini-Unix
will be _very_ similar); use a simulator. I have a lengthy tutorial here:
http://www.chiappa.net/~jnc/tech/V6Unix.html
It's in terms of Ersatz-11, which I prefer because it has that nice DOS device,
which makes it easy to get files into the Unix (so I can use my normal editor on
the host machine). However, I gather most people prefer SIMH; there is a tutorial
here:
https://gunkies.org/wiki/Running_Unix_v6_in_SIMH
(I didn't write it; I know nothing of SIMH) for that option.
How do people using SIMH get files into a Unix running on one? Larry Allen
just wrote a PDP-11 simulator in Rust, and he's thinking about adding a
paper-tape reader (connectable to a file), so that if he installs the stock
V6 PTR driver, he can just do 'cat /dev/ptr > myfile'; sort of like how
VM/370 used the virtual card reader.
Noel
> From: Paul Ruizendaal
> I'd love to have a look at that and compare and contrast the
> approaches.
OK; the system is somewhat disorganized, and stuff is in directories here,
there and everywhere in it (much is in the home dirs of some of the people who
worked on some pieces), so it will take me a fair amount of work to curate it
all into an accessible form, but I have put _some_ of it up here:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/net/
If you want to slurp up the whole thing:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/net/net.tar
I should explain that the kernel only contains inbound de-multiplexing, and
not much else; the TCP is in the user process, allong with the
application. (Great for V6 on a small machine...) There is most of what
documentation I could find in the 'doc' folder.
There were at least two different TCP's in use on that system - maybe three. I
have currently only included one (gotta do some more work to get the rest; for
Server Telnet, and User/Server FTP), along with a couple of appplications
which use it: SMTP, Finger, and User Telnet.
The kernel code is mostly there, but there are some minor dribs and drabs of
changes/additions elsewhere in the kernetl which I'll have to sort out in the
future. The main thing that's not there is the Pronet driver; not very useful!
There's also an ICMP paemon (and 'ping'), IIRC, but that's something else I'll
have to find.
Any questions, or stuff you'd really like to see, let me know.
Noel
We've had three prospects respond (who knew???), so unless they all drop out, I think we're set.
-r
> A while back, there was some discussion of A/UX. We have an Apple Quadra which was able to boot and run A/UX a few decades ago. If someone wants to pay for shipping from the San Francisco Bay Area, this charming little machine could be theirs. Please respond off-list, to avoid annoying the neighbors...
>
> -r
>
> P.S. We're packing and moving, so a prompt response is critical.
A while back, there was some discussion of A/UX. We have an Apple Quadra which was able to boot and run A/UX a few decades ago. If someone wants to pay for shipping from the San Francisco Bay Area, this charming little machine could be theirs. Please respond off-list, to avoid annoying the neighbors...
-r
P.S. We're packing and moving, so a prompt response is critical.
> Would also be great if supported RL02 drives. ;)
_Support_ for RL02's will not be a problem (but there are probably some issues
- see below). I have an RL11 driver for V6, which will be easy to include in a
system build. There is also a RL V6 boostrap (which lives in block 0 - it
loads the OS from a V6 filesystem); how to load it off the RL pack on actual
hardware, I'm not sure; do you have some PROM device that has an RL bootstrap
in it?
Or do you have some other drive which is going to be your boot device? If not,
how are you going to get the bits onto an RL pack? This was a bit of an issue
for Fritz Muelller with his -11/45 (with an RK05 drive); he finally wound up
having to load it over a serial line, which took several hours. He used
something called PDP11GUI, and you're in luck, that does support RL02's.
Also, I'm not sure if you've had any experience with an old removable-pack
drive. If not, you have to be very careful with them; if you have a head
crash, the heads are now unobtainium, so a head crash will turn the drive into
junk. (Which is a big part of why Dave Bridgham and I are doing to QSIC RK11
emulator...) The packs need to be absolutely clean; a number of people have
experience with them, you should probably qget some lessons from them before trying
to use it.
> I'd imagine the V6 TTY driver would support boards with multiple serial
> ports. Guess that's what's needed for multi user access.
The TTY code in V6 consists of two levels of driver. The bottom layer is a
driver which is specific to the particular type of card one's using; DL-11,
DZ-11, etc. If the card supports multiple lines, that driver will too. Then
there's a layer above that, tty.c, which the low-level driver uses to interace
to the OS; the user talks to that. That layer is multi-line.
Noel
> From: John Foust
> Mark Riordan has a copy and some docs...
> http://www.60bits.net/msu/mycomp/terak/termedia.htm
Alas, the only thing online there is a list of which floppies he had, not any
actual content (other than one document). I've sent him an email (at the
address given on that site), we'll see if I get a reply. He might not have a
way to read those floppies...
If not, no biggie; in asking I more wanted to make sure I wasn't wasting my
time, I don't really need him to come through. Having done the /40->/23 move,
I'm sure the /05->/03 move won't present any major problems.
BTW, looking around for a copy of a document he mentioned, I found this:
http://www.tavi.co.uk/unixhistory/mini-unix.html
so between them and the stuff at TUHS, I think we have everything we'd need.
Noel
Hello,
Perhaps this has been discussed here before, but I
couldn't find a definitive answer as to the origin of
"Charlie Root".
https://www.geeklan.co.uk/?p=2457 includes links to
some of the /etc/passwd files from 4.1cBSD, 4.2BSD,
and 2.9BSD, where we see root changing from being "The
Man" to "Charlie &".
Speculations on the internet about Charlie Root the
baseball player are easy enough to find, but no
confirmation or official origin story.
So I thought I'd ask here: who can (authoritatively)
shed light on how we ended up with Charlie Root?
-Jan
I wrote:
>There was one for the Terak (an 11/03) in May 1979 but I've never found a copy.
I take it back... Mark Riordan has a copy and some docs...
http://www.60bits.net/msu/mycomp/terak/termedia.htm
- John
> If you want multiple users on an -11/03, Mini-Unix would be an option;
> zit doesn't support the -11/03 'out of the box', but looking at it, it
> shouldn't be too hard. (Heinz mentioned that it had been done before.)
On thinking about it, I might do the -11/03 port of Mini-Unix for the hack
value; it looks like it should be a quick project (a couple of hours, much of
which would be getting Mini-Unix set up; I'd use a simulator, my QBUS RK11
emulator is broken at the moment).
I think it should mostly just be some fairly straight-forward changes to
mch.s; I think all the C code would be fine. (Unless there's an 'PS->integ' or
something hiding somewhere.) Also a few odds and ends, like a software console
switch register (been there, done that).
That would make the full power of Mini-Unix available to people with -11/03's;
those are still fairly common, and reasonably cheap. (Unlike -11/05's.) It's a
considerably more capable system than LSX: e.g. the tty driver is the full V6
one, and supports an arbitrary number of devices.
So my question is: had anyone else already done this (I don't want to waste
time replicating already-done work)? Also, would anyone have a use for it if I
did it? If so, I'll put it up on a Web page when I'm done. (No, I _don't_ use
Guthub, and have zero interest in learning how. I'd rather spend my remaining
un-comitted neurons improving my ability to read feudal Japanese.)
Noel
Doug McIlroy:
To put it more strongly. this is not a legal C source file.
char *s = NULL;
But this is.
char *s = 0;
Clem Cole:
67)The macro NULL is defined in <stddef.h> (and other headers) as a null
pointer constant; see 7.19.
====
$ cat null.c
char *s = NULL;
$ cat zero.c
char *s = 0;
$
zero.c is a legal C program. null.c is not. Create
files exactly as shown and compile them if you don't
believe me.
Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
to null.c and it becomes legal, but I think that's Doug's
point: you need an include file.
Personally I prefer to use NULL instead of 0 when spelling
out a null pointer, because I think it's clearer:
if ((buf = malloc(SIZE)) == NULL)
error("dammit andrew");
though I am willing to omit it when there's no confusion
about = vs ==:
if (*p)
dammit(*p, "andrew");
But that's just a question of style, and Doug's is fine too.
The language does not require the compiler to pre-define
NULL or to recognize it as a keyword; you have to include
an appropriate standard header file.
Norman Wilson
Toronto ON (not 0N nor NULLN)