Some answers to Warren's queries:
mknod(II) first shows up in the Fourth Edition; the manual entry is dated
8/5/73. (That having been typed in the US, presumably it means 5 Aug 1973.)
getgid(II) shows in the same manual, but with an older date: 3/15/72.
This is also the edition in which the documentation for stat(II) first
admits a group ID as well as a user ID.
Both my hazy memory (made worse by lack of sleep right now) and the clues
in the manual suggest that 3e/4e was the period when the system was rewritten
in C; e.g. 4e is the first to show C interfaces in section II, complete with
structs as well as pure byte-offset descriptions for objects like that filled
in by stat, though the structs are nameless, presumably because there were no
standard header files yet. Evidently the file system upheaval occurred in
the same period.
Reading the description of the 3e file system, I see it has been too long since
I've read it. A summary:
Blocks 0 and 1 are the super-block, consisting of
size of free-storage bitmap
the map itself
size of free-i-node map
the map itself
Block 2 begins the i-list; data blocks follow.
I-nodes 1-40 are reserved for special (device) files,
and don't appear in the map. I-node 41 is the root.
I-nodes have flags, a link count, a userid, a 16-bit
size, creation and modification times, and eight block
pointers. Flag bits inclode `allocated', `large file'
(the pointers are to indirect blocks), read and write
permissions for user and other, set-userid, a single
`executable' flag, a `directory' flag (if clear, regular
file).
BUGS
Two blocks are not enough to handle the i- and free-
storage maps for an RP02 disk pack, which contains
around 10 million words.
The 4e file system is more or less that in the more-familiar V6 system:
Block 0 reserved for boot block
Block 1 is the super-block: file-system and i-list sizes,
caches of free block and i-node numbers. The free-block
list is now the familiar chain of blocks list free block
numbers; the free-inode list is abolished because the
i-nodes all have `allocated' flags anyway.
Block 2 begins the i-list. I-node 1 is the root.
I-nodes differ from 3e in having a group ID,a 24-bit
size, access time instead of creation time; the `directory'
flag becomes a two-bit `file type' flag; group permissions
appear, there are three separate `executable' flags, and
set-group-ID appears.
No BUGS yet, perhaps because the code was new.
Notice how history repeats: 4e replaced the free-block bitmap with
a list, which made it simpler to cope with huge file systems but
harder to allocate blocks in a simpler order; sundry replacement
file systems in the early 1980s (Berkeley FFS, Weinberger's cheap
hacks in V8) restored the bitmap, because it's easier to pick a good
block when you can see all the blocks available, and because by then
computers had enough memory and disks were big enough that a large
bitmap wasn't a burden.
An anecdote may be (barely) relevant here. I remember once in the
late 1980s having a chat with Lee McMahon about group IDs, and how
they didn't seem to have done quite what people wanted (hence the
multiple-groups-per-process stuff in most current systems, and the
special semantics for the set-group-id flag on directories, and
various other features that have seemed to me never to quite hit
the mark). Lee told me that when Ken first put group IDs into the
system, he asked Ken what they were for. Ken allegedly shrugged
and said `I dunno.'
Norman Wilson
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA15137
for pups-liszt; Thu, 21 Jan 1999 03:49:52 +1100 (EST)
>From Mike Jenkins <mjenkins(a)carp.gbr.epa.gov> Thu Jan 21 02:49:27 1999
Received: from carp.gbr.epa.gov (carp.gbr.epa.gov [204.46.159.110])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id DAA15131
for <pups(a)minnie.cs.adfa.oz.au>; Thu, 21 Jan 1999 03:49:37 +1100 (EST)
Received: (from mjenkins@localhost)
by carp.gbr.epa.gov (8.8.8/8.8.8) id KAA08238;
Wed, 20 Jan 1999 10:49:27 -0600 (CST)
(envelope-from mjenkins)
Date: Wed, 20 Jan 1999 10:49:27 -0600 (CST)
From: Mike Jenkins <mjenkins(a)carp.gbr.epa.gov>
Message-Id: <199901201649.KAA08238(a)carp.gbr.epa.gov>
To: pups(a)minnie.cs.adfa.oz.au
Subject: Re: Old pic of ken and dmr
Cc: wkt(a)cs.adfa.oz.au
In-Reply-To: <199901200346.OAA06481(a)henry.cs.adfa.edu.au>
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> http://minnie.cs.adfa.edu.au/PUPS/Images/ken-and-den.jpg
There is a smaller (26K) gif version on the following page:
http://www.lucent.com/museum/1969unix.html
The URL for the gif is:
http://www.lucent.com/museum/images/1950/1969rt.gif
Mike
In article by Eric Fischer:
> Congratulations on getting the nsys kernel running! I have
> a couple of random comments on what you posted to the list:
>
> > Syscalls in `nsys' but not in V5:
> > ---------------------------------
> > 1, &quit, /* 26 = quit */
> > 1, &intr, /* 27 = intr */
> > 1, &cemt, /* 29 = cemt */
> > 1, &ilgins, /* 33 = ilgins */
> > 1, &fpe, /* 40 = fpe */
> >
> > These deliver signals QUIT, INTR, EMT, INS or FPE
> > to the pid in arg0. Any user can send these signals.
>
> I think this is backwards -- these system calls don't deliver
> signals, they trap them. That is, they're the predecessors
> of signal(), not kill().
Eric is quite correct, and I realised this after reading some comments
on the V2 kernel. The nsys kernel also has a sig() system call which
allows a process to trap an arbitrary signal. This is why the syscalls
above were removed: there was a more general system call available.
>
> > Syscalls in V5 but not in `nsys':
> > ---------------------------------
> > 0, &getpid, /* 20 = getpid */
> > 1, &smdate, /* 30 = smdate */
> > 0, &nice, /* 34 = nice */
> > 0, &pipe, /* 42 = pipe */ !!!
> > 4, &profil, /* 44 = prof */
>
> This part seems really weird. Since it has fpe() but not nice() and
> pipe(), that would have to mean it's somewhere intermediate between
> v2 and v3, at least if the details in Doug McIlroy's "Research Unix
> Reader" are all accurate. And I *really* don't understand why there
> would be space reserved in the system call table for nice and pipe
> but no implementations of the functions.
>
> The other weird part is that McIlroy says that smdate() was in v1
> through v3 but disappeared after that. I don't have the v5 kernel
> source at hand right now, so I can't check up on that, but it's
> strange that smdate should be missing here if this is an early v3.
>
> Actually, on further inspection this must be a *late* v3, since it
> has mknod(), getgid(), and setgid(), which aren't supposed to have
> shown up until v4. (No signal(), though, so it's not quite v4.)
> That's still very odd that pipes would be left out, unless this
> version was crunched to run in an especially small memory or something.
>
> And yet, v3 was supposed to have been released in February, 1973, and
> this is earlier than that, so what are any v4 features doing there at
> all? This just gets stranger and stranger...
> eric
I've had some chat with Dennis about this kernel, and how it fitted into
development. The summary is: Ken tried to rewrite the assembly version of
the kernel in B (or NB) in 1972, but gave up because structures didn't
exist. Once B -> NB -> C and got structures, they tried again. Apparently,
the `new' kernel (aka nsys) was developed in parallel with the `old'
assembly kernel during early to mid-1973. Then, Dennis says:
I'm pretty sure that we didn't adopt [the C version of the kernel]
as the standard "production" system until about September 1973.
It is very likely that the real "sys" was still in assembler.
Pipes were probably added first to [the sys] version, given the
evidence in "nsys."
Dennis also says:
During 1972, Ken finally puts pipes into Unix at McIlroy's urging.
which would explain why there is a reserved syscall in `nsys', but no
code as yet.
I can't explain the existence of the mknod(), getgid(), and setgid()
system calls. Norman and Bob Keys, I think one/both of you have got the
old manuals, can you look through them and find out when these syscalls
appeared?
Cheers all,
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA12788
for pups-liszt; Wed, 20 Jan 1999 14:45:43 +1100 (EST)
>From Warren Toomey <wkt(a)henry.cs.adfa.edu.au> Wed Jan 20 13:46:41 1999
Received: from henry.cs.adfa.edu.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id OAA12783
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 20 Jan 1999 14:45:35 +1100 (EST)
Received: (from wkt@localhost)
by henry.cs.adfa.edu.au (8.9.1/8.9.1) id OAA06481
for pups(a)minnie.cs.adfa.oz.au; Wed, 20 Jan 1999 14:46:41 +1100 (EST)
(envelope-from wkt)
From: Warren Toomey <wkt(a)henry.cs.adfa.edu.au>
Message-Id: <199901200346.OAA06481(a)henry.cs.adfa.edu.au>
Subject: Old pic of ken and dmr
To: pups(a)minnie.cs.adfa.oz.au (Unix Heritage Society)
Date: Wed, 20 Jan 1999 14:46:41 +1100 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
All,
Patrick Regan, from Bell Labs, has sent in a 2M jpg of
Ken and Dennis at the console of a PDP-11/20, around 1970. It's at:
http://minnie.cs.adfa.edu.au/PUPS/Images/ken-and-den.jpg
Ciao,
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id CAA14984
for pups-liszt; Thu, 21 Jan 1999 02:45:02 +1100 (EST)
Dear PUPS/TUHS members,
I have just uploaded James Lothian's /usr/src tarball. You can find it in the
Distributions/4bsd/thirdparty/UWisc4.3/James_Lothian_mods directory in the PUPS
archive.
Sincerely,
Michael Sokolov
Phone: 440-449-0299
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Dear PUPS/TUHS members,
I have just uploaded the distribution images for the University of Winconsin's
hacked 4.3BSD contributed by James Lothian. You can find them in the
Distributions/4bsd/thirdparty/UWisc4.3 directory in the PUPS archive.
I haven't uploaded James' own changed /usr/src yet, will probably do it later
at night.
Sincerely,
Michael Sokolov
Phone: 440-449-0299
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA06758
for pups-liszt; Tue, 19 Jan 1999 13:07:24 +1100 (EST)
>From Warren Toomey <wkt(a)henry.cs.adfa.edu.au> Tue Jan 19 12:08:22 1999
Received: from henry.cs.adfa.edu.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id NAA06753
for <pups(a)minnie.cs.adfa.oz.au>; Tue, 19 Jan 1999 13:07:17 +1100 (EST)
Received: (from wkt@localhost)
by henry.cs.adfa.edu.au (8.9.1/8.9.1) id NAA02324
for pups(a)minnie.cs.adfa.oz.au; Tue, 19 Jan 1999 13:08:22 +1100 (EST)
(envelope-from wkt)
From: Warren Toomey <wkt(a)henry.cs.adfa.edu.au>
Message-Id: <199901190208.NAA02324(a)henry.cs.adfa.edu.au>
Subject: Co-authors for Unix history paper?
To: pups(a)minnie.cs.adfa.oz.au (Unix Heritage Society)
Date: Tue, 19 Jan 1999 13:08:22 +1100 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Hi all,
I recently approached the IEEE Annals of Computing History journal
to see if they would be interested in a paper on our efforts to find and
preserve the old versions of Unix. They said yes, so I was wondering if
anybody might want to be co-author. This is what I suggested:
> I'd like to write an article which describes the efforts to find and
> preserve historical material which is related to UNIX. This includes
> finding tapes, reading them, decoding their formats etc.
>
> The article would also discuss the mechanisms available for running
> these old UNIX systems: by using old hardware (and the difficulties
> of maintaining such equipment), by using software emulators (and
> possibly a discussion of what they provide).
>
> In other words, the actual history of UNIX and its influence would not
> be covered, but the `archaeology' and preservation of artifacts from
> the early days of UNIX would be.
Given that there are people on the list who deal with old hardware, reading
ancient tapes, etc., I thought they might like to add some input to the
paper.
I think the paper size is limited to around 25-30 pages, and has be formal
in tone. If anybody has any suggestions as to what should go in (or even
wants to write a section), then I would welcome some email!
Cheers all,
Warren
P.S I'm giving a similar, but much more informal, paper at a local
conference next month. The paper is at:
http://minnie.cs.adfa.edu.au/Seminars/Saving_Unix/
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id TAA08164
for pups-liszt; Tue, 19 Jan 1999 19:33:12 +1100 (EST)
Dear PUPS/TUHS members,
I have just finished SCCS-reconstructing /usr/src/sys. Amazingly (and to CSRG's
credit) the history has been preserved very well, and I have SCCS-recostructed
almost every file in the kernel. There are only a few lost SCCS files. For the
list see:
http://minnie.cs.adfa.edu.au/Quasijarus/sccs.html
If you know anything about these files, please contact me ASAP!
Also when I SCCS-reconstructed the /usr/src/sys/tahoe* subdirs, I had to take a
step back. In the currently shipping release, 4.3BSD-Quasijarus0, these subdirs
are identical to the ones on the 4.3BSD-Tahoe+HCX-9 tape. However, in the
current master source tree they have been stepped back to the original
4.3BSD-Tahoe tape. For the explanation of this decision, see:
http://minnie.cs.adfa.edu.au/Quasijarus/arch.html
Sincerely,
Michael Sokolov
Cellular phone: 216-217-2579
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA22468
for pups-liszt; Fri, 15 Jan 1999 14:50:07 +1100 (EST)
>From Warren Toomey <wkt(a)henry.cs.adfa.edu.au> Fri Jan 15 13:51:04 1999
Received: from henry.cs.adfa.edu.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id OAA22456
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 15 Jan 1999 14:49:58 +1100 (EST)
Received: (from wkt@localhost)
by henry.cs.adfa.edu.au (8.9.1/8.9.1) id OAA21707
for pups(a)minnie.cs.adfa.oz.au; Fri, 15 Jan 1999 14:51:04 +1100 (EST)
(envelope-from wkt)
From: Warren Toomey <wkt(a)henry.cs.adfa.edu.au>
Message-Id: <199901150351.OAA21707(a)henry.cs.adfa.edu.au>
Subject: Success in Compiling Nsys Kernel
To: pups(a)minnie.cs.adfa.oz.au (Unix Heritage Society)
Date: Fri, 15 Jan 1999 14:51:04 +1100 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
All,
After several days of frustration and enlightenment, I have been
able to compile and boot the `nsys' kernel source code on top of a 5th
Edition RK05 root filesystem.
The `nsys' kernel code corresponds to a time around the 3rd Edition of UNIX,
i.e. Jan 1973. Dennis Ritchie donated this to the PUPS Archive a few days ago.
I have placed the modifications to `nsys', plus some documentation, in the
PUPS Archive in Distributions/research/Dennis_v3.
Cheers all,
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id QAA22804
for pups-liszt; Fri, 15 Jan 1999 16:19:14 +1100 (EST)
>From Warren Toomey <wkt(a)henry.cs.adfa.edu.au> Fri Jan 15 15:20:12 1999
Received: from henry.cs.adfa.edu.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id QAA22798
for <pups(a)minnie.cs.adfa.oz.au>; Fri, 15 Jan 1999 16:19:07 +1100 (EST)
Received: (from wkt@localhost)
by henry.cs.adfa.edu.au (8.9.1/8.9.1) id QAA22113
for pups(a)minnie.cs.adfa.oz.au; Fri, 15 Jan 1999 16:20:12 +1100 (EST)
(envelope-from wkt)
From: Warren Toomey <wkt(a)henry.cs.adfa.edu.au>
Message-Id: <199901150520.QAA22113(a)henry.cs.adfa.edu.au>
Subject: Re: Success in Compiling Nsys Kernel
In-Reply-To: <01be4045$e3b28080$f2681081(a)collinse-home.tyson.com> from Efton Collins at "Jan 14, 1999 11: 8:35 pm"
To: pups(a)minnie.cs.adfa.oz.au (Unix Heritage Society)
Date: Fri, 15 Jan 1999 16:20:12 +1100 (EST)
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
In article by Efton Collins:
> I wonder how long it has been since that version of the kernel ran? Could be
> 25 years. Surely that will now be the earliest bootable kernel bar none. It
> must give Ken and Dennis a smile.
>
> It is nice to see such interesting things continue to find their way into
> the archive. With the help of so many of the pioneers PUPS is fulfilling its
> charter very well indeed.
>
> E-
Hi Efton. I had been keeping Dennis informed of my progress, and a few
days ago he passed on some email from Bob Keys:
[Dennis wrote:]
Keys said (when I mentioned your tries)
> Ohhh, neato! Let us keep fingers crossed, knock on wood 3 times,
> cow-tow as appropriate, rub the rabbit's foot, throw salt before
> the sumo ring, .... and anything else?.....(:+}}....
Dennis then went on to suggest some debugging ideas, when I was stuck:
Astonishing. When booting it might be best to start
with an init that just does
open(something);
open(something);
write(1, "Hello\n", 6);
It might even be appropriate to try first with just abort();
to see if /etc/init can be read,
He must be out today, because I haven't got a reply back from my email
indicating success.
The `nsys' files were dated Jan 22, 1973. I definitely wanted to get the
kernel working by Jan 22, 1999 so that it was only 25 years ago, not 26!
I've also made some notes about the differences between `nsys' and V5,
attached below. Thanks for your encouraging email.
Cheers,
Warren
Differences in available syscalls between `nsys' and V5.
========================================================
Syscalls in `nsys' but not in V5:
---------------------------------
1, &quit, /* 26 = quit */
1, &intr, /* 27 = intr */
1, &cemt, /* 29 = cemt */
1, &ilgins, /* 33 = ilgins */
1, &fpe, /* 40 = fpe */
These deliver signals QUIT, INTR, EMT, INS or FPE
to the pid in arg0. Any user can send these signals.
0, &prproc /* 63 = special */
For each of the 50 entries in the proc array, if there is
a valid process entry there, print the array index and the
following fields from the proc structure:
p_stat, p_flag, p_pid, p_ppid,
p_addr, p_size, p_wchan, p_textp
Syscalls in V5 but not in `nsys':
---------------------------------
0, &getpid, /* 20 = getpid */
1, &smdate, /* 30 = smdate */
0, &nice, /* 34 = nice */
0, &pipe, /* 42 = pipe */ !!!
4, &profil, /* 44 = prof */
Other Differences
-----------------
/* 21 = mount */ has 2 arguments in `nsys', 3 in V5
/* 37 = kill */ has 0 arguments in `nsys', 1 in V5
Dear PUPS/TUHS members,
I have finally updated the Quasijarus Project WWW page so that now it's much
more useful. You can find it at:
http://minnie.cs.adfa.edu.au/Quasijarus/
Sincerely,
Michael Sokolov
Cellular phone: 216-217-2579
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Kirk McKusick <mckusick(a)McKusick.COM> wrote:
> I applaud your desire not to break old 4.2/4.3 machines.
> I would be very resistant to losing support for a popular
> machine like the 11/750. However, I think that losing support
> for the 11/730 would be acceptable.
You are not the first person I hear this from, and I wouldn't completely
disagree. However, it always pains me very much when a system really ought to
run on a machine and has all the necessary ingredients, but fails because of
some tiny nit. This is exactly the case here. The CPU is supported, the console
storage device is supported, all bootstrap scripts are already written, even
the IDC is supported, but the standalone programs refuse to load because of a
ucode botch!
Now, I did look more carefully, and the boot.730 program does fit into 12.5 KB
after all in 4.2 and 4.3 (copy.730 fits in 4.2 but not in 4.3, and format.730
doesn't fit even in 4.2). So I guess it would be possible after all to massage
up the Makefile and the ifdefing in the sources to make the 4.3-Quasijarus
standalone system build a small boot.730.
However, the objections to this approach are:
1. Instead of tidying up the standalone system, this would make it an even
worse mess.
2. In future Quasijarus releases I plan to retire the current standalone
drivers for U/Q and BI MSCP and make the standalone system call DEC's own
VMB for I/O from/to all MSCP devices, making it possible to support MSCP on
more than just U/Q and BI. However, this means that all big VAX users with
MSCP disks will now need a copy of DEC's VMB.EXE in addition to UNIX's
native boot code. It will also have to be a recent enough version, and I'm
sure as hell that the version that came with 11/730 is too old. A newer
version of VMB can be pulled out of almost any VMS or Ultrix distribution,
but the one I have seen was 40 KB long. Thus even if I manage to make a
boot.730 that fits within 12.5 KB, you would still need the 40 KB VMB.EXE if
your disk is RAxx (the most common type), and this obviously makes boot.730
squeezing an exercise in futility.
Resolution: I will pitch the *.730 programs and add a note to the documentation
that installation on a 730 requires a ucode upgrade that fixes this botch. If
someone asks me where to obtain one (or how to write one if it doesn't exist),
I'll redirect them to this list, as I have no idea. :-)
Sincerely,
Michael Sokolov
Cellular phone: 216-217-2579
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Dear PUPS/TUHS members,
I wonder if any of you has some input on this issue. As I'm preparing for
making my planned disk labeling improvements (making it possible to install the
system on a fresh unlabeled disk in a more or less straightforward way), I
first want to clean up some mess in the standalone system. One thing that
annoys me in there is that for every standalone program that's supposed to go
on the console media there are two versions built, a normal one and a "730"
one. The comments say that 11/730 has a microcode botch that prevents it from
loading programs larger than 12.5 KB, so supposedly all "730" standalone
programs must be smaller than that. However, right now all standalone programs
are around 30 KB, and the difference between the normal and "730" versions is
only about 3 KB, even though the "730" versions do have the MASSBUS and BI code
compiled out. Wondering if there is a way to make them smaller, I looked at
older versions, and guess what, even in 4.2 the "730" versions are a little bit
over the alleged 12.5 KB limit! That's right, 4.2BSD is the first release with
11/730 support, and its standalone programs are already over the alleged 11/730
microcode limit!
This raises quite a few questions. First of all, does the 11/730 microcode
really have this limitation, or is it just a hoax? If this limit does exist,
when exactly does it apply? The BSD distribution TU58 cassette always used the
full versions of the programs, not the "730" ones (the distribution cassette is
also used for 750s), and yet apparently 730s could be bootstrapped from it.
Maybe this limitation applies only to automatic bootstrap and not to manual
loading? And if this is indeed a microcode botch, are there any patches
available for it?
I would appreciate it if someone here can provide some answers to these
questions. I would really like to get rid of those "730" standalone programs,
but I can't do it if this would break 11/730 support. (It's my responsibility
as the 4.3BSD-* maintainer to only add features, but never break anything that
works in plain 4.3 or 4.2.)
Sincerely,
Michael Sokolov
Cellular phone: 216-217-2579
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id LAA13144
for pups-liszt; Wed, 13 Jan 1999 11:00:18 +1100 (EST)
>From Kirk McKusick <mckusick(a)mckusick.com> Wed Jan 13 06:18:13 1999
Received: from flamingo.McKusick.COM (root(a)flamingo.mckusick.com [209.31.233.178])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id LAA13139
for <pups(a)minnie.cs.adfa.edu.au>; Wed, 13 Jan 1999 11:00:10 +1100 (EST)
Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1])
by flamingo.McKusick.COM (8.8.5/8.8.5) with ESMTP id MAA10534;
Tue, 12 Jan 1999 12:18:13 -0800 (PST)
Message-Id: <199901122018.MAA10534(a)flamingo.McKusick.COM>
To: mxs46(a)k2.scl.cwru.edu (Michael Sokolov)
Subject: Re: 11/730 question
cc: pups(a)minnie.cs.adfa.edu.au
In-reply-to: Your message of "Tue, 12 Jan 1999 18:18:35 EST."
<199901122318.SAA04873(a)skybridge.scl.cwru.edu>
Date: Tue, 12 Jan 1999 12:18:13 -0800
From: Kirk McKusick <mckusick(a)mckusick.com>
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
I applaud your desire not to break old 4.2/4.3 machines.
I would be very resistant to losing support for a popular
machine like the 11/750. However, I think that losing support
for the 11/730 would be acceptable. It was a very feeble
processor (0.3 of a 780) and very few of them were ever sold.
We had only one at Berkeley (for porting purposes), and it was
so slow that we were not even able to pawn it off on the
undergrad CS organization when we were done with it.
Kirk
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id PAA13915
for pups-liszt; Wed, 13 Jan 1999 15:15:54 +1100 (EST)
G'day all...
I have a DEC-PRO/350.
I believe it is a PDP8.
Is there any way of confirming this?
Thanks.
Michael.
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA11300
for pups-liszt; Wed, 13 Jan 1999 01:27:45 +1100 (EST)
>From "emanuel stiebler" <emu(a)ecubics.com> Wed Jan 13 00:26:39 1999
Received: from biz1.mailsrvcs.net (biz1.gte.net [207.115.153.50])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id BAA11295
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 13 Jan 1999 01:27:36 +1100 (EST)
Received: from p2350 ([208.254.195.48]) by biz1.mailsrvcs.net
(Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-40549L5000S0)
with ESMTP id AAA22519; Tue, 12 Jan 1999 08:27:30 -0600
From: "emanuel stiebler" <emu(a)ecubics.com>
To: "BeLFrY" <belfry(a)nsw.bigpond.net.au>,
"\"\\\"PUPs\\\" PDP11 Unix Preservation group\"" <pups(a)minnie.cs.adfa.oz.au>
Subject: Re: Confirming machine hardware.
Date: Tue, 12 Jan 1999 07:26:39 -0700
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <19990112142726.AAA22519@p2350>
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Hi Michael,
----------
> From: BeLFrY <belfry(a)nsw.bigpond.net.au>
> To: "\"PUPs\" PDP11 Unix Preservation group" <pups(a)minnie.cs.adfa.oz.au>
> Subject: Confirming machine hardware.
> Date: Monday, January 11, 1999 11:34 PM
> I have a DEC-PRO/350.
which is nice ;-))
> I believe it is a PDP8.
> Is there any way of confirming this?
Sorry, there is no way to confirm this ;-)) (sorry, couldn't resist)
the nearest "brother" of the pro/350 would be the pdp11/23, pdp11//23+ or
pdp11/24, because the use the same CPU. (DCF11)
hope it helps,
emanuel
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA12405
for pups-liszt; Wed, 13 Jan 1999 06:43:32 +1100 (EST)
>From Johnny Billquist <bqt(a)Update.UU.SE> Wed Jan 13 05:43:04 1999
Received: from Zeke.Update.UU.SE (IDENT:2026@Zeke.Update.UU.SE [130.238.11.14])
by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id GAA12400
for <pups(a)minnie.cs.adfa.oz.au>; Wed, 13 Jan 1999 06:43:22 +1100 (EST)
Received: from localhost (bqt@localhost)
by Zeke.Update.UU.SE (8.8.8/8.8.8) with SMTP id UAA09742;
Tue, 12 Jan 1999 20:43:06 +0100
Date: Tue, 12 Jan 1999 20:43:04 +0100 (MET)
From: Johnny Billquist <bqt(a)Update.UU.SE>
To: BeLFrY <belfry(a)nsw.bigpond.net.au>
cc: "\"\\\"PUPs\\\" PDP11 Unix Preservation group\"" <pups(a)minnie.cs.adfa.oz.au>
Subject: Re: Confirming machine hardware.
In-Reply-To: <369AECFA.87A55C4(a)nsw.bigpond.net.au>
Message-ID: <Pine.VUL.3.93.990112204229.9487A-100000(a)Zeke.Update.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
On Tue, 12 Jan 1999, BeLFrY wrote:
> G'day all...
Hi there.
> I have a DEC-PRO/350.
>
> I believe it is a PDP8.
>
> Is there any way of confirming this?
No.
However I can confirm that it is a pdp-11.
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
In article by Lawrence Reinish:
> I am looking for several issues of 'EDU MAGAZINE' from mid-1975 to 1976.
> It was published by Digital Equipment Corporation. Any assistance would be
> greatly appreciated.
>
> Lawrence Reinish
Lawrence, I don't have any copies. I'll forward this on to some people
who might be able to help you.
Cheers,
Warren
