From reed at reedmedia.net  Tue Dec  1 01:25:24 2015
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Mon, 30 Nov 2015 09:25:24 -0600 (CST)
Subject: [TUHS] Portable Pascal and a 1BSD question
In-Reply-To: <A731853E-E882-430B-B38C-7F092E135C81@gmail.com>
References: <A731853E-E882-430B-B38C-7F092E135C81@gmail.com>
Message-ID: <alpine.NEB.2.11.1511300922400.21917@t1.m.reedmedia.net>

On Sun, 29 Nov 2015, Will Senn wrote:

> In v2 no5 AUUGN Jun-Jul 1980, Andy Tanenbaum announced the 
> availability of a Portable Pascal Compiler for the then proposed ISO 
> standard. A tape was made for v6, v7, and non-unix platforms. Does 
> anyone know if there is a tape image around that has the distro?

Look for ug091377

http://ftp.math.utah.edu/pub/mirrors/minnie.tuhs.org/Applications/Usenix_77/

I don't know if is the same Pascal, but it is a few years older and is 
also from Tanenbaum and Vrije Universiteit.


From will.senn at gmail.com  Tue Dec  1 05:31:14 2015
From: will.senn at gmail.com (Will Senn)
Date: Mon, 30 Nov 2015 13:31:14 -0600
Subject: [TUHS] Portable Pascal and a 1BSD question
In-Reply-To: <alpine.NEB.2.11.1511300922400.21917@t1.m.reedmedia.net>
References: <A731853E-E882-430B-B38C-7F092E135C81@gmail.com>
 <alpine.NEB.2.11.1511300922400.21917@t1.m.reedmedia.net>
Message-ID: <565CA402.50608@gmail.com>

Thanks, Jeremy. I'll take a look and when I have progress to report, 
I'll let you know how it turns out.

- Will

On 11/30/15 9:25 AM, Jeremy C. Reed wrote:
> On Sun, 29 Nov 2015, Will Senn wrote:
>
>> In v2 no5 AUUGN Jun-Jul 1980, Andy Tanenbaum announced the
>> availability of a Portable Pascal Compiler for the then proposed ISO
>> standard. A tape was made for v6, v7, and non-unix platforms. Does
>> anyone know if there is a tape image around that has the distro?
> Look for ug091377
>
> http://ftp.math.utah.edu/pub/mirrors/minnie.tuhs.org/Applications/Usenix_77/
>
> I don't know if is the same Pascal, but it is a few years older and is
> also from Tanenbaum and Vrije Universiteit.



From random832 at fastmail.us  Wed Dec  2 07:48:32 2015
From: random832 at fastmail.us (Random832)
Date: Tue, 01 Dec 2015 16:48:32 -0500
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <20151130090637.GA16550@www.oztivo.net>
References: <mailman.3.1448845201.3730.tuhs@minnie.tuhs.org>
 <353E052F-541F-47C1-9ACF-587EB9EC6088@mcjones.org>
 <20151130090637.GA16550@www.oztivo.net>
Message-ID: <1449006512.3471492.455150041.226FD33C@webmail.messagingengine.com>

Anyone have any thoughts on a collaborative effort to hand-correct it
from the OCR output into a readable format?


From dave at horsfall.org  Wed Dec  2 08:29:33 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 2 Dec 2015 09:29:33 +1100 (EST)
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <1449006512.3471492.455150041.226FD33C@webmail.messagingengine.com>
References: <mailman.3.1448845201.3730.tuhs@minnie.tuhs.org>
 <353E052F-541F-47C1-9ACF-587EB9EC6088@mcjones.org>
 <20151130090637.GA16550@www.oztivo.net>
 <1449006512.3471492.455150041.226FD33C@webmail.messagingengine.com>
Message-ID: <alpine.BSF.2.11.1512020925310.27895@aneurin.horsfall.org>

On Tue, 1 Dec 2015, Random832 wrote:

> Anyone have any thoughts on a collaborative effort to hand-correct it 
> from the OCR output into a readable format?

Can someone point me to the URL for it, please?  I could be interested, as 
I'm a pedantic bugger.

And what format would you suggest?  I can do -ms and RTF, but I'm not 
familiar with LaTex etc.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From random832 at fastmail.us  Wed Dec  2 10:44:02 2015
From: random832 at fastmail.us (Random832)
Date: Tue, 01 Dec 2015 19:44:02 -0500
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <alpine.BSF.2.11.1512020925310.27895@aneurin.horsfall.org>
References: <mailman.3.1448845201.3730.tuhs@minnie.tuhs.org>
 <353E052F-541F-47C1-9ACF-587EB9EC6088@mcjones.org>
 <20151130090637.GA16550@www.oztivo.net>
 <1449006512.3471492.455150041.226FD33C@webmail.messagingengine.com>
 <alpine.BSF.2.11.1512020925310.27895@aneurin.horsfall.org>
Message-ID: <1449017042.505332.455285777.317E18FD@webmail.messagingengine.com>

On Tue, Dec 1, 2015, at 17:29, Dave Horsfall wrote:
> Can someone point me to the URL for it, please?  I could be
> interested, as  I'm a pedantic bugger.

http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/

The 2.5MB version is fine. I also went ahead and created a github
repository with what I have so far (a couple pages cleaned up, first
page has justification and hyphenation reapplied, and the rest just has
a few global search fixes and some things I spotted running it through
spell before I gave up on that approach).

https://github.com/Random832/McIlroy_v0/

> And what format would you suggest?  I can do -ms and RTF, but I'm not
> familiar with LaTex etc.

Well, just fixing up the text would be a start, maybe along with
some notation of what's underlined, subscripts, etc, so we can come
back to it.

It'd be period-appropriate to use roff, which might well be what he
originally wrote it in... or nroff might be more accessible for
modern users.


From ag4ve.us at gmail.com  Thu Dec  3 03:21:16 2015
From: ag4ve.us at gmail.com (shawn wilson)
Date: Wed, 2 Dec 2015 12:21:16 -0500
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <1449017042.505332.455285777.317E18FD@webmail.messagingengine.com>
References: <mailman.3.1448845201.3730.tuhs@minnie.tuhs.org>
 <353E052F-541F-47C1-9ACF-587EB9EC6088@mcjones.org>
 <20151130090637.GA16550@www.oztivo.net>
 <1449006512.3471492.455150041.226FD33C@webmail.messagingengine.com>
 <alpine.BSF.2.11.1512020925310.27895@aneurin.horsfall.org>
 <1449017042.505332.455285777.317E18FD@webmail.messagingengine.com>
Message-ID: <CAH_OBieeTqFpqV2EkOVVR1_0+Y2SHPYPd6-GRowwhoc2nrAV+w@mail.gmail.com>

On Dec 1, 2015 7:44 PM, "Random832" <random832 at fastmail.us> wrote:
>

> It'd be period-appropriate to use roff, which might well be what he
> originally wrote it in... or nroff might be more accessible for
> modern users.
>

Planning on making a man page out of it?

I would assume you'd want a format you could overlay an image of each page
on as the typeface and whatnot are cool to see.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151202/6a581ff9/attachment.html>

From random832 at fastmail.com  Thu Dec  3 04:32:05 2015
From: random832 at fastmail.com (Random832)
Date: Wed, 2 Dec 2015 18:32:05 +0000 (UTC)
Subject: [TUHS] Scan of "Edition 0" manual
References: <mailman.3.1448845201.3730.tuhs@minnie.tuhs.org>
 <353E052F-541F-47C1-9ACF-587EB9EC6088@mcjones.org>
 <20151130090637.GA16550@www.oztivo.net>
 <1449006512.3471492.455150041.226FD33C@webmail.messagingengine.com>
 <alpine.BSF.2.11.1512020925310.27895@aneurin.horsfall.org>
 <1449017042.505332.455285777.317E18FD@webmail.messagingengine.com>
 <CAH_OBieeTqFpqV2EkOVVR1_0+Y2SHPYPd6-GRowwhoc2nrAV+w@mail.gmail.com>
Message-ID: <n3ndf5$42d$1@ger.gmane.org>

On 2015-12-02, shawn wilson wrote:
> I would assume you'd want a format you could overlay an image of each page
> on as the typeface and whatnot are cool to see.

One thing that might be worth doing is seeing if we can "perfectly"
replicate the output and actually use it instead of the OCR
results as the invisible text layer of the PDF.



From will.senn at gmail.com  Thu Dec  3 07:37:42 2015
From: will.senn at gmail.com (Will Senn)
Date: Wed, 2 Dec 2015 15:37:42 -0600
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
Message-ID: <565F64A6.9080103@gmail.com>

All,

I am studying Unix v6 using SimH and I am documenting the process, as I 
go, as part of my own learning process. I have much to learn about Unix, 
Unix v6 in particular, the PDP architecture and its relationship with 
v6, and SimH's emulation of the PDP, so, I am taking notes... I thought 
that I would share the notes in raw form as occasional blog posts in the 
hope that the knowledge that I work to obtain, might be made available 
and useful to others. I also believe that these forms of communication, 
as insignificant as they may seem individually are part of helping to 
preserve the knowledge of our computing history, in the aggregate. Here 
is a link to the first post, a run at an installation walk-through:

http://decuser.blogspot.com/2015/11/installing-and-using-research-unix.html

I am open to feedback and criticism, but please keep in mind that I am a 
relative newbie to v6 and PDP land, some of my assumptions are 
probably/undoubtedly wrong, but definitely fixable :).

Regards,

Will


From wkt at tuhs.org  Thu Dec  3 10:20:42 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 3 Dec 2015 11:20:42 +1100
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <565F64A6.9080103@gmail.com>
References: <565F64A6.9080103@gmail.com>
Message-ID: <20151203002042.GA7042@www.oztivo.net>

On Wed, Dec 02, 2015 at 03:37:42PM -0600, Will Senn wrote:
> I am studying Unix v6 using SimH and I am documenting the process,
> http://decuser.blogspot.com/2015/11/installing-and-using-research-unix.html

That's a great writeup Will. The only comment I have is a pedantic one:
can you write "pdp" as "PDP-11"?

Otherwise, it's highly readable, explain why you did things the whay you
did, and someone else should be able to read your notes and reproduce your
work.

What do you plan to do next?

Cheers, Warren


From will.senn at gmail.com  Thu Dec  3 12:37:14 2015
From: will.senn at gmail.com (Will Senn)
Date: Wed, 2 Dec 2015 20:37:14 -0600
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <20151203002042.GA7042@www.oztivo.net>
References: <565F64A6.9080103@gmail.com> <20151203002042.GA7042@www.oztivo.net>
Message-ID: <565FAADA.3040401@gmail.com>

Warren,

Thanks for the comment. I appreciate your feedback and will make 
appropriate changes.

Next? I have been reading Lyons and it has taken me some time to develop 
enough background knowledge to make sense of his notes. A surface read 
of the notes will give a novice reader some idea of the major 
architectural components of the system, but a deeper read will require 
the reader to have knowledge beyond what is required of most modern 
software developers (PDP-11 architecture, assembly language, and UNIX 
are prerequisite). It will also require access to a lab where the ideas 
covered can be experimented with. A modern reader might be intrigued 
from a historical perspective, but may not be compelled to go to the 
trouble of learning enough about the past to recreate it or even see the 
its relevance to the present or future.

Access in 2015 to a working UNIX v6 environment on a PDP-11 ala 1975 is 
as unlikely as it sounds. However, using SimH to simulate a functional 
PDP-11, with peripherals, a UNIX v6 tape image from 1975, and the 
documentation from that period, which, thanks to TUHS is now accessible, 
it becomes possible to establish a laboratory from which to experiment. 
The resulting environment is not only historically interesting, but 
technically interesting, as well.

Many of the interesting bits about our current systems, even seemingly 
unexplainable things like magic numbers, have their genesis and rational 
in this early system. The v6 kernel weighs in at around 10k lines of 
code with a limited set of peripherals and yet it packs in features that 
were either unavailable in larger more established systems or may have 
been present in some form, but were orders of magnitude more lines of 
code and attendant complexity. It was and remains an amazing operating 
system and worthy of contemporary study.

So, I was thinking that next up, I would write up notes to help the 
modern reader engage with v6 more easily in order to follow works like 
Lyons. Right now, I am working on notes related to using the v6 assembly 
and c languages to produce working code. While this may seem trivial to 
folks who are expert, or who have worked in the actual environments, it 
is not really so trivial for me or for other folks brought up on more 
modern computing platforms and I would like to both understand the 
workflows and to document them for others.

Regards,

Will



> On Wed, Dec 02, 2015 at 03:37:42PM -0600, Will Senn wrote:
>> I am studying Unix v6 using SimH and I am documenting the process,
>> http://decuser.blogspot.com/2015/11/installing-and-using-research-unix.html
> That's a great writeup Will. The only comment I have is a pedantic one:
> can you write "pdp" as "PDP-11"?
>
> Otherwise, it's highly readable, explain why you did things the whay you
> did, and someone else should be able to read your notes and reproduce your
> work.
>
> What do you plan to do next?
>
> Cheers, Warren



From dave at horsfall.org  Thu Dec  3 14:11:54 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 3 Dec 2015 15:11:54 +1100 (EST)
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <565FAADA.3040401@gmail.com>
References: <565F64A6.9080103@gmail.com>
 <20151203002042.GA7042@www.oztivo.net> <565FAADA.3040401@gmail.com>
Message-ID: <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>

On Wed, 2 Dec 2015, Will Senn wrote:

> Next? I have been reading Lyons [...]

Lions.  The name is Lions.  He was one of my CompSci lecturers.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From will.senn at gmail.com  Thu Dec  3 14:18:11 2015
From: will.senn at gmail.com (Will Senn)
Date: Wed, 2 Dec 2015 22:18:11 -0600
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
References: <565F64A6.9080103@gmail.com>
 <20151203002042.GA7042@www.oztivo.net> <565FAADA.3040401@gmail.com>
 <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
Message-ID: <565FC283.20704@gmail.com>

Dave,

Thanks for catching this. I have no idea where I got Lyons from. Sheesh, 
I have his book right here on the table... I will make appropriate edits.

Regards,

Will


On 12/2/15 10:11 PM, Dave Horsfall wrote:
> On Wed, 2 Dec 2015, Will Senn wrote:
>
>> Next? I have been reading Lyons [...]
> Lions.  The name is Lions.  He was one of my CompSci lecturers.
>



From peter at rulingia.com  Thu Dec  3 16:06:18 2015
From: peter at rulingia.com (Peter Jeremy)
Date: Thu, 3 Dec 2015 17:06:18 +1100
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <565FC283.20704@gmail.com>
References: <565F64A6.9080103@gmail.com> <20151203002042.GA7042@www.oztivo.net>
 <565FAADA.3040401@gmail.com>
 <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
 <565FC283.20704@gmail.com>
Message-ID: <20151203060503.GB93851@server.rulingia.com>

On 2015-Dec-02 22:18:11 -0600, Will Senn <will.senn at gmail.com> wrote:
>Thanks for catching this. I have no idea where I got Lyons from.

Well, at least one "Lyons" has a proud place in computer history - have
a read of https://en.wikipedia.org/wiki/LEO_(computer)

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151203/89ca19c5/attachment.sig>

From peter at rulingia.com  Thu Dec  3 16:05:03 2015
From: peter at rulingia.com (Peter Jeremy)
Date: Thu, 3 Dec 2015 17:05:03 +1100
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <565FC283.20704@gmail.com>
References: <565F64A6.9080103@gmail.com> <20151203002042.GA7042@www.oztivo.net>
 <565FAADA.3040401@gmail.com>
 <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
 <565FC283.20704@gmail.com>
Message-ID: <20151203060503.GB93851@server.rulingia.com>

On 2015-Dec-02 22:18:11 -0600, Will Senn <will.senn at gmail.com> wrote:
>Thanks for catching this. I have no idea where I got Lyons from.

Well, at least one "Lyons" has a proud place in computer history - have
a read of https://en.wikipedia.org/wiki/LEO_(computer)

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151203/89ca19c5/attachment-0001.sig>

From cowan at mercury.ccil.org  Thu Dec  3 22:59:26 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Thu, 3 Dec 2015 07:59:26 -0500
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <20151203060503.GB93851@server.rulingia.com>
References: <565F64A6.9080103@gmail.com> <20151203002042.GA7042@www.oztivo.net>
 <565FAADA.3040401@gmail.com>
 <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
 <565FC283.20704@gmail.com>
 <20151203060503.GB93851@server.rulingia.com>
Message-ID: <20151203125926.GD22112@mercury.ccil.org>

Peter Jeremy scripsit:

> Well, at least one "Lyons" has a proud place in computer history - have
> a read of https://en.wikipedia.org/wiki/LEO_(computer)

Joseph Nathaniel Lyons himself had nothing to do with the computer, of course.
But then again, Emack and Bolio had nothng to do with the ice-cream store,
either.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Time alone is real
  the rest imaginary
like a quaternion       --phma


From jnc at mercury.lcs.mit.edu  Fri Dec  4 01:42:00 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  3 Dec 2015 10:42:00 -0500 (EST)
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
	using SimH and a healthy dose of documentation
Message-ID: <20151203154200.7F88B18C086@mercury.lcs.mit.edu>

    > From: Will Senn <will.senn at gmail.com>

    > a deeper read will require the reader to have knowledge beyond what is
    > required of most modern software developers (PDP-11 architecture,
    > assembly language, and UNIX are prerequisite).

Well, for pretty much any _operating system_ (as opposed to applications),
one will need to know something about the details of the machine it is
intended to run on; depending on which part of the OS one is looking at, it
will be more or less. E.g. switching processes probably requires a fair
amount, since one needs to know about internal CPU registers, etc; whereas
working on the file system, one probably doesn't need to know very much about
the machine.

    > It will also require access to a lab where the ideas covered can be
    > experimented with. 

Actually, Lions/V6 was used in operating systems courses using simulated
machines; one at MIT, 6.828 "Operating Systems Engineering":

  https://pdos.csail.mit.edu/6.828/

used it for a while before the students started complaining about being
forced to learn an obsolete machine. They thereupon wrote a V6 clone for the
x86 architecture, 'XV6' (see the top of that page), which is apparently now
used for similar courses at quite a few other universities.

    > The v6 kernel ... packs in features that were either unavailable in
    > larger more established systems or may have been present in some form,
    > but were orders of magnitude more lines of code and attendant
    > complexity. It was and remains an amazing operating system and worthy
    > of contemporary study.

I don't think you will find too many people here who disagree! ;-)

    > So, I was thinking that next up, I would write up notes to help the
    > modern reader engage with v6 more easily in order to follow works like
    > Lyons.

Check around online to see what exists, first; there has been stuff written
since Lions! ;-)

	Noel


From jnc at mercury.lcs.mit.edu  Fri Dec  4 01:21:50 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  3 Dec 2015 10:21:50 -0500 (EST)
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
	using SimH and a healthy dose of documentation
Message-ID: <20151203152150.C571C18C084@mercury.lcs.mit.edu>

    > From: Will Senn <will.senn at gmail.com>

    > I am studying Unix v6 using SimH and I am documenting the process

I did a very similar exercise using the Ersatz11 simulator; I have a lot
of stuff about the process here:

  http://www.chiappa.net/~jnc/tech/V6Unix.html
  
It contains a number of items that you might find useful, e.g.: "V6 as
distributed is strictly a 20th Century operating system. Literally. You can't
set the date to anytime in the 21st century, for two reasons. First, the
'date' command only take a 2-digit year number. Second, even if you fix that,
the ctime() library routine has a bug in it that makes it stop working in the
closing months of 1999."

    > the PDP architecture

Technically, a PDP-11 - there were a number of different PDP architectures:

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

is a decent listing of them; several (PDP-8, PDP-10, etc) were very popular
and successful.


A few things I noted in your first post:

    > I am using the Ken Wellsch tape because it boots and is stated to be
    > identical to Dennis Ritchie's tape other than being bootable and having
    > a different timestamp on root. 

The only differences I could discover between the two are that in the Wellsch
versions i) a Western Electric rights notice (which prints on booting) has
been added to ken/main.c, and the Unix bootable images; and ii) the RK pack
images do have, as you noted, the bootstrap in block 0.

    > Note: sh is critically important, don't muck it up :). The issue is
    > that if you do, there really isn't an easy way to recover. 

One should _never_ install a new shell version as '/bin/sh' until it has been
run and tested for a while (for the exact reason you mention). Happily, in
Unix, as far as the OS is concerned, the command interpreter is just another
program, so it's trivial to name a new binary of the shell 'nsh' or
something, and run that for a while to make sure it's working OK, before
installing it as '/bin/sh'.

    > a special file (whatever that is)

Special files are UNIXisms for 'devices'. _All_ devices in Unix appear as
'special files' in the file system, usually (but not necessarily) in /dev -
that location is a convention, not a requirment of the OS.

	Noel


From random832 at fastmail.com  Fri Dec  4 03:27:47 2015
From: random832 at fastmail.com (Random832)
Date: Thu, 3 Dec 2015 17:27:47 +0000 (UTC)
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
References: <20151203152150.C571C18C084@mercury.lcs.mit.edu>
Message-ID: <n3pu2j$27r$1@ger.gmane.org>

On 2015-12-03, Noel Chiappa wrote:
> I did a very similar exercise using the Ersatz11 simulator; I have a lot
> of stuff about the process here:
>
>   http://www.chiappa.net/~jnc/tech/V6Unix.html
>   
> It contains a number of items that you might find useful, e.g.: "V6 as
> distributed is strictly a 20th Century operating system. Literally. You can't
> set the date to anytime in the 21st century, for two reasons. First, the
> 'date' command only take a 2-digit year number. Second, even if you fix that,
> the ctime() library routine has a bug in it that makes it stop working in the
> closing months of 1999."

I don't think your fix to the date command is accurate. The description says:

>  The 'date' command has been extended to support 2- and 4-digit year
>  numbers (to be upwardly compatible, the 2-digit ones assume 19xx).

But the code says:
>	if ((y < 0) || (yh < 0)) {
>		time(nt);
>		y = localtime(nt)[5];
>		y =+ 1900;
>	}
>	  else
>		y = yh + y;

To match your description it should be
	if ((y < 0) && (yh < 0)) {
		time(nt);
		y = localtime(nt)[5];
	} else if(y < 0) {
		/* yh = two digit year */
		y = 1900 + yh;
	} else
		y = yh + y;

Though I'd be inclined to add "if (y < 1970) y =+ 100;" to bring it in line
with modern systems' 1970-2069 range for two-digit years.

Of course, _any_ ancient unix system (and a fair few modern ones) can't
represent dates past 2038. We've only got 23 years left before attempts to
bring up old systems will need some trickery (maybe set the year to 28 or 56
years before the present... that trick, with increasing windows, will work
until 2100 isn't a leap year)

On the other hand, treating it as an "unsigned" value will last about as long
and is a bit less of a hack. But as you note, doing this sort of thing in V6 C
isn't trivial.



From will.senn at gmail.com  Fri Dec  4 04:46:47 2015
From: will.senn at gmail.com (Will Senn)
Date: Thu, 3 Dec 2015 12:46:47 -0600
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <20151203152150.C571C18C084@mercury.lcs.mit.edu>
References: <20151203152150.C571C18C084@mercury.lcs.mit.edu>
Message-ID: <56608E17.5@gmail.com>

Noel,

Thank you for writing and responding to my writeup. I have replied 
inline, below:

On 12/3/15 9:21 AM, Noel Chiappa wrote:
>      > From: Will Senn <will.senn at gmail.com>
>
>      > I am studying Unix v6 using SimH and I am documenting the process
>
> I did a very similar exercise using the Ersatz11 simulator; I have a lot
> of stuff about the process here:
>
>    http://www.chiappa.net/~jnc/tech/V6Unix.html
>    
Thanks for reminding me about your work. I had scanned it briefly when I 
was first starting down this road, but wrote it off because I wasn't 
using the Ersatz11 simulator. With the background I have now, it should 
be translate into my current frame and be useful. I haven't tried 
tackling the time problem yet, but I will keep your document in mind 
along with Wolfgang's fixes for ctime:

     http://www.tuhs.org/Archive/PDP-11/Bug_Fixes/V6enb/

>
>      > the PDP architecture
>
> Technically, a PDP-11 ...
Oops. I will be more careful in how I refer to the PDP-11 from now on.
> The only differences I could discover between the two are that in the Wellsch
> versions i) a Western Electric rights notice (which prints on booting) has
> been added to ken/main.c, and the Unix bootable images; and ii) the RK pack
> images do have, as you noted, the bootstrap in block 0.
Thanks for this. I will update my note appropriately.
>      > Note: sh is critically important, don't muck it up :). The issue is
>      > that if you do, there really isn't an easy way to recover.
>
> One should _never_ install a new shell version as '/bin/sh' until it has been
> run and tested for a while (for the exact reason you mention). Happily, in
> Unix, as far as the OS is concerned, the command interpreter is just another
> program, so it's trivial to name a new binary of the shell 'nsh' or
> something, and run that for a while to make sure it's working OK, before
> installing it as '/bin/sh'.
This is a duh moment for me. I will change the note to reflect testing 
first, then copy over.
>
>      > a special file (whatever that is)
>
> Special files are UNIXisms for 'devices'. _All_ devices in Unix appear as
> 'special files' in the file system, usually (but not necessarily) in /dev -
> that location is a convention, not a requirment of the OS.
>
I have since learned a lot more about this and will update the note.

Regards,

Will



From will.senn at gmail.com  Fri Dec  4 04:54:38 2015
From: will.senn at gmail.com (Will Senn)
Date: Thu, 3 Dec 2015 12:54:38 -0600
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <20151203154200.7F88B18C086@mercury.lcs.mit.edu>
References: <20151203154200.7F88B18C086@mercury.lcs.mit.edu>
Message-ID: <56608FEE.7080407@gmail.com>

Noel,

Comments below:

On 12/3/15 9:42 AM, Noel Chiappa wrote:
> Actually, Lions/V6 was used in operating systems courses using simulated
> machines; one at MIT, 6.828 "Operating Systems Engineering":
>
>    https://pdos.csail.mit.edu/6.828/

I knew about xv6, but didn't realize they had used v6 previously. 
Interesting. I can imagine how students might complain about it in a 
college setting. Thankfully, I'm not trying to teach it in one of my 
courses, at least not yet! :). I am just blogging about it for those who 
might be interested.
> Check around online to see what exists, first; there has been stuff written
> since Lions! ;-)
>
In your view, what are some of the best recent works?

Thanks,

Will



From grog at lemis.com  Fri Dec  4 10:52:05 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Fri, 4 Dec 2015 11:52:05 +1100
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <20151203154200.7F88B18C086@mercury.lcs.mit.edu>
References: <20151203154200.7F88B18C086@mercury.lcs.mit.edu>
Message-ID: <20151204005205.GH19002@eureka.lemis.com>

On Thursday,  3 December 2015 at 10:42:00 -0500, Noel Chiappa wrote:

> E.g. switching processes probably requires a fair amount, since one
> needs to know about internal CPU registers, etc;

And there you missed your cue :-) From swtch() in sys/ken/slp.c:

	/*
	 * If the new process paused because it was
	 * swapped out, set the stack level to the last call
	 * to savu(u_ssav).  This means that the return
	 * which is executed immediately after the call to aretu
	 * actually returns from the last routine which did
	 * the savu.
	 *
	 * You are not expected to understand this.
	 */

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151204/e161bfd3/attachment.sig>

From will.senn at gmail.com  Fri Dec  4 15:02:01 2015
From: will.senn at gmail.com (Will Senn)
Date: Thu, 3 Dec 2015 23:02:01 -0600
Subject: [TUHS] Installing a large set of files into v6 from a modern host
Message-ID: <56611E49.8090003@gmail.com>

All,

I am trying to figure out how to get parts of 1BSD added into a pristine 
v6 install, but the question I have relates to moving more than a 
handful of files from a host system into v6, which lacks several 
capabilities that are taken for granted from v7 onward (tar, unzip, and 
so on).

For background, in looking at the 1bsd tarball, exploded out, I saw that 
ex was available on the tape in a binary form that is suitable for a 
PDP-11/40 and I thought it would make life easier in v6 to have ex. So, 
I used dd to move the a.outNOID  file onto a file, which can be used as 
a raw RK image and then off the RK image loaded in the PDP-11 into the 
v6 system as the executable file ex, and that worked. I was able to run 
ex (well, sort of, I get the colon prompt anyway... I haven't figured 
out how it actually works yet). Yeeha! Having had success of a sort with 
a single executable from the 1BSD tape, I would like to see if other 
parts of 1BSD will work in the environment and if I can properly install 
those parts.

Individually moving files using dd is tedious in the extreme (there are 
many files in the tarball). I know there has to be a better way. Since 
v6 doesn't have tar, or unzip,  it doesn't seem likely that using dd to 
move the tarball into v6 will be help matters. But, if there was a way 
to dd a subdirectory and its contents onto an RK image and get them off 
again into a useable v6 file system, that would work.

My question for the group is based on the preceding discussion and the 
following assumption:

1. given a tarball such as 1bsd.tar.gz from the TUHS archive located at:
/PDP-11/Distributions/ucb

2. with a running SimH PDP-11/40 instance
with a virtual TU10 magtape
with a virtual TU56 dectape
with a virtual RK05 hard drive

3. running v6 as the operating system

What is an efficient method of moving the files of the 1bsd 
distribution, or any other set of files and directories, into the v6 
operating environment?

Here are some approaches that seem reasonable, but that I haven't been 
able to figure out, if you know better, please do tell:
1. a utility on the host that is capable of copying a directory and its 
contents, recursively, onto a blank magtape/dectape/rk image that is 
then readable in the v6 environment
2. a tar and unzip binary for v6 that is capable of dealing with the 
tarball (but isn't the tarball going to exceed the max file size anyway, 
if so this won't work)
3. an alternative archiver that runs on FreeBSD or Mac OS X, that can 
create a single file archive from a subdirectory's contents on the host 
(the resultant file would need to be extractable on v6, and if file size 
is too limited, won't work either).
4. some kind of directory transfer utility that works over telnet that 
can be executed from a FreeBSD or Mac OS X host and that can be executed 
on the v6 system as well.
5. a utility capable of creating an empty magtape/dectape/rk image and 
another capable of making a filesystem on the image and another of 
populating the image (analogous to fdisk rkimage; mkfs rkimage; rkcopy 
dir rkimage)

If I am asking the wrong questions, or thinking badly, I would 
appreciate a steer in the right direction.

Regards,

Will




From random832 at fastmail.com  Fri Dec  4 15:14:58 2015
From: random832 at fastmail.com (Random832)
Date: Fri, 4 Dec 2015 05:14:58 +0000 (UTC)
Subject: [TUHS] Installing a large set of files into v6 from a modern
	host
References: <56611E49.8090003@gmail.com>
Message-ID: <n3r7gi$5p7$1@ger.gmane.org>

On 2015-12-04, Will Senn wrote:
> 2. a tar and unzip binary for v6 that is capable of dealing with the 
> tarball

http://mercury.lcs.mit.edu/~jnc/tech/ImprovingV6.html has tar.

You'll want to use --format=v7 to create the tar on the host computer.

> (but isn't the tarball going to exceed the max file size anyway, 
> if so this won't work)

You'd be using the tape device directly, not a file.



From random832 at fastmail.com  Fri Dec  4 15:27:03 2015
From: random832 at fastmail.com (Random832)
Date: Fri, 4 Dec 2015 05:27:03 +0000 (UTC)
Subject: [TUHS] Installing a large set of files into v6 from a modern
	host
References: <56611E49.8090003@gmail.com>
Message-ID: <n3r877$g1r$1@ger.gmane.org>

A couple more options occurred to me after I posted.

On 2015-12-04, Will Senn wrote:
> 1. a utility on the host that is capable of copying a directory and its 
> contents, recursively, onto a blank magtape/dectape/rk image that is 
> then readable in the v6 environment

Maybe run tp in apout? Actually, V7 through 4.4BSD has a tp that is
written in C. Maybe see if you can get it to compile on a modern system.

> 4. some kind of directory transfer utility that works over telnet that 
> can be executed from a FreeBSD or Mac OS X host and that can be executed 
> on the v6 system as well.

Well, you could try to make one using rcp as a starting point.

Or send a shar to the terminal to be executed by an interactive shell.
(I make no claims about how well typical shar archivers work with the v6
shell and utilities; you might have to write one.)

> 5. a utility capable of creating an empty magtape/dectape/rk image and 
> another capable of making a filesystem on the image and another of 
> populating the image (analogous to fdisk rkimage; mkfs rkimage; rkcopy 
> dir rkimage)

AncientFS is read-only, but adding write capability might be an
interesting project.

http://osxbook.com/software/ancientfs/
http://osxbook.com/blog/2008/12/22/ancientfs-on-linux-and-freebsd/



From dave at horsfall.org  Fri Dec  4 16:22:09 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 4 Dec 2015 17:22:09 +1100 (EST)
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <20151203060503.GB93851@server.rulingia.com>
References: <565F64A6.9080103@gmail.com>
 <20151203002042.GA7042@www.oztivo.net> <565FAADA.3040401@gmail.com>
 <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
 <565FC283.20704@gmail.com> <20151203060503.GB93851@server.rulingia.com>
Message-ID: <alpine.BSF.2.11.1512041714400.27895@aneurin.horsfall.org>

On Thu, 3 Dec 2015, Peter Jeremy wrote:

> >Thanks for catching this. I have no idea where I got Lyons from.
> 
> Well, at least one "Lyons" has a proud place in computer history - have 
> a read of https://en.wikipedia.org/wiki/LEO_(computer)

Wow!  Mercury tanks...  I have a fascination for olde computers.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From grog at lemis.com  Fri Dec  4 16:38:19 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Fri, 4 Dec 2015 17:38:19 +1100
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <alpine.BSF.2.11.1512041714400.27895@aneurin.horsfall.org>
References: <565F64A6.9080103@gmail.com> <20151203002042.GA7042@www.oztivo.net>
 <565FAADA.3040401@gmail.com>
 <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
 <565FC283.20704@gmail.com>
 <20151203060503.GB93851@server.rulingia.com>
 <alpine.BSF.2.11.1512041714400.27895@aneurin.horsfall.org>
Message-ID: <20151204063819.GC58889@eureka.lemis.com>

On Friday,  4 December 2015 at 17:22:09 +1100, Dave Horsfall wrote:
> On Thu, 3 Dec 2015, Peter Jeremy wrote:
>
>>> Thanks for catching this. I have no idea where I got Lyons from.
>>
>> Well, at least one "Lyons" has a proud place in computer history - have
>> a read of https://en.wikipedia.org/wiki/LEO_(computer)
>
> Wow!  Mercury tanks...  I have a fascination for olde computers.

Take a look at CSIRAC in the Melbourne museum, the oldest computer in
the world.  It's worth it, even if they don't have it running.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151204/066bd8e7/attachment.sig>

From peter at rulingia.com  Fri Dec  4 22:41:23 2015
From: peter at rulingia.com (Peter Jeremy)
Date: Fri, 4 Dec 2015 23:41:23 +1100
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <alpine.BSF.2.11.1512041714400.27895@aneurin.horsfall.org>
References: <565F64A6.9080103@gmail.com> <20151203002042.GA7042@www.oztivo.net>
 <565FAADA.3040401@gmail.com>
 <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
 <565FC283.20704@gmail.com>
 <20151203060503.GB93851@server.rulingia.com>
 <alpine.BSF.2.11.1512041714400.27895@aneurin.horsfall.org>
Message-ID: <20151204124123.GA16681@server.rulingia.com>

On 2015-Dec-04 17:22:09 +1100, Dave Horsfall <dave at horsfall.org> wrote:
>On Thu, 3 Dec 2015, Peter Jeremy wrote:
>
>> >Thanks for catching this. I have no idea where I got Lyons from.
>> 
>> Well, at least one "Lyons" has a proud place in computer history - have 
>> a read of https://en.wikipedia.org/wiki/LEO_(computer)
>
>Wow!  Mercury tanks...  I have a fascination for olde computers.

Well, whilst I've replaced the 'U' in this mailing list with a 'C'...
LEO-1 was basically a commercialised EDSAC.  And there's an EDSAC
Replica Project - http://www.tnmoc.org/special-projects/edsac  I
saw a fascinating talk by one of the Project members.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151204/3420afaf/attachment.sig>

From clemc at ccc.com  Fri Dec  4 23:51:32 2015
From: clemc at ccc.com (Clem Cole)
Date: Fri, 4 Dec 2015 08:51:32 -0500
Subject: [TUHS] Installing a large set of files into v6 from a modern
	host
Message-ID: <CAC20D2Nuh+VnYu6U4yoa4aB54wG8gkeHZBafdhqMgL70v_F3nA@mail.gmail.com>

​below​

On Fri, Dec 4, 2015 at 12:02 AM, Will Senn <will.senn at gmail.com> wrote:

> 1. a utility on the host that is capable of copying a directory and its
> contents, recursively, onto a blank magtape/dectape/rk image that is then
> readable in the v6 environment
>
​Right - you want a common archive format between the two systems that talk
to the tape device.
You can either create your own or better take on the old ones that exist.



> 2. a tar and unzip binary for v6 that is capable of dealing with the
> tarball (but isn't the tarball going to exceed the max file size anyway, if
> so this won't work)
>

I think you have a many to chose from off the top of my head I can think of
each with different advantages (more in a minute):

   - tar
   - cpio
   - ​tp/stp
   - ar (new format)

You seem to also want a compression tool, but you might try compressing on
the modern system - but there are solution here also.

   - pack/unpack was the old v5/v6 compression tool - I've forgotten where
   it was sourced check the first USENIX tape in 77
   - porting a modern zip/gzip/bzip




> 3. an alternative archiver that runs on FreeBSD or Mac OS X, that can
> create a single file archive from a subdirectory's contents on the host
> (the resultant file would need to be extractable on v6, and if file size is
> too limited, won't work either).
>
​That is a lot of work and unless this is going to be a very long term
thing, I'm not so sure it's worth it.    Basically you want a virtual FS on
the v6 system and the simulator.    If you are going to do this alot, then
its worth it.   Think the VFS that vmware and like offer.​



> 4. some kind of directory transfer utility that works over telnet that can
> be executed from a FreeBSD or Mac OS X host and that can be executed on the
> v6 system as well.
>
​the original unix kermit will compile using ​the v6 compiler (maybe the
v5) compiler.   You have to dig in the archives, but you want a version
from Columbia circa 1977 and you be fine.   The latest version will use
things in the language first described in the white book - aka Typersetter
C (Dennis was wrote the book starting with v6, but's not published until
v7).   If you a later compiler running on v6 you'll be fine.



> 5. a utility capable of creating an empty magtape/dectape/rk image and
> another capable of making a filesystem on the image and another of
> populating the image (analogous to fdisk rkimage; mkfs rkimage; rkcopy dir
> rkimage)
>
You could move the file system creation tools and set of a virtual v6 FS.
It's a lot of work and unless this is going to be a very long term thing,
I'm not so sure it's worth it.


​As for the archivers which in the short term is likely to be your best bet:


   1. tar - there a couple of versions of tar for v6 including binaries.
   I personally would start there.
   2. cpio was written for PWB 1.0 which is v6 kernel based.  That binary
   should run.  But IIRC correctly the original cpio was only binary headers
   (the -c/ascii headers was added later).   So you'll need to be careful on
   the modern computer and make sure you set the switches so that he created
   the proper endian/byte swapping -- ness in the header
   3. tp/stp - on the original USENIX tape is a "super tp" that replaced
   the original one.   The binary should run as is.  The code for it is
   pre-K&R so compiling it with a modern compiler will be a little bit of
   work.   Also, IIRC the "directory" which is on the front of the tape is
   binary, so you'll need to make sure you write everything in PDP-11 format.
   4. ar - was updated by the community.   Eventually, V7 took the "new ar"
   from original USENIX tape.  Again that binary should just run fine.
   Although I don't think its directory is recursive so it may fail that
   requirement for you


Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151204/36dba19f/attachment.html>

From cowan at mercury.ccil.org  Sat Dec  5 00:52:18 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Fri, 4 Dec 2015 09:52:18 -0500
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <20151204063819.GC58889@eureka.lemis.com>
References: <565F64A6.9080103@gmail.com> <20151203002042.GA7042@www.oztivo.net>
 <565FAADA.3040401@gmail.com>
 <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
 <565FC283.20704@gmail.com>
 <20151203060503.GB93851@server.rulingia.com>
 <alpine.BSF.2.11.1512041714400.27895@aneurin.horsfall.org>
 <20151204063819.GC58889@eureka.lemis.com>
Message-ID: <20151204145218.GC24075@mercury.ccil.org>

Greg 'groggy' Lehey scripsit:

> Take a look at CSIRAC in the Melbourne museum, the oldest computer in
> the world.  It's worth it, even if they don't have it running.

Well, there's the Antikythera mechanism.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand.  --Gerald Holton


From ron at ronnatalie.com  Sat Dec  5 04:17:58 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 4 Dec 2015 13:17:58 -0500
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
	using SimH and a healthy dose of documentation
In-Reply-To: <20151204145218.GC24075@mercury.ccil.org>
References: <565F64A6.9080103@gmail.com>
 <20151203002042.GA7042@www.oztivo.net> <565FAADA.3040401@gmail.com>
 <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
 <565FC283.20704@gmail.com> <20151203060503.GB93851@server.rulingia.com>
 <alpine.BSF.2.11.1512041714400.27895@aneurin.horsfall.org>
 <20151204063819.GC58889@eureka.lemis.com>
 <20151204145218.GC24075@mercury.ccil.org>
Message-ID: <1F998DC4-275F-4DE1-81F2-CC19BE714A7A@ronnatalie.com>

I guess you’re going to have to qualify that.   It’s the oldest “surviving” (though it’s unclear what that means to a computer not running) STORED PROGRAM machine.

The ENIAC, which by some standards is the first programmable digital computer still exists at the Smithsonian.  Some of my coworkers there were on the team that took it down from BRL to the Smithsonian and actually tested it as operational when it was handed over to the museum.   I don’t think it’s ever been powered on since.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151204/759ce450/attachment.bin>

From gregg.drwho8 at gmail.com  Sat Dec  5 04:33:15 2015
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Fri, 4 Dec 2015 13:33:15 -0500
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <1F998DC4-275F-4DE1-81F2-CC19BE714A7A@ronnatalie.com>
References: <565F64A6.9080103@gmail.com> <20151203002042.GA7042@www.oztivo.net>
 <565FAADA.3040401@gmail.com>
 <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
 <565FC283.20704@gmail.com> <20151203060503.GB93851@server.rulingia.com>
 <alpine.BSF.2.11.1512041714400.27895@aneurin.horsfall.org>
 <20151204063819.GC58889@eureka.lemis.com>
 <20151204145218.GC24075@mercury.ccil.org>
 <1F998DC4-275F-4DE1-81F2-CC19BE714A7A@ronnatalie.com>
Message-ID: <CAC5iaNEwmgbAMaw9bgXqb-dLSkpYWbR7pU+Kha-aRH7Nfg_+ew@mail.gmail.com>

Hello!
We are also forgetting the contraption that Turing built. Of course
sadly at the end it was destroyed. Why? I don't know. But it has since
been rebuilt.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Fri, Dec 4, 2015 at 1:17 PM, Ronald Natalie <ron at ronnatalie.com> wrote:
> I guess you’re going to have to qualify that.   It’s the oldest “surviving” (though it’s unclear what that means to a computer not running) STORED PROGRAM machine.
>
> The ENIAC, which by some standards is the first programmable digital computer still exists at the Smithsonian.  Some of my coworkers there were on the team that took it down from BRL to the Smithsonian and actually tested it as operational when it was handed over to the museum.   I don’t think it’s ever been powered on since.
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>


From szigiszabolcs at gmail.com  Sat Dec  5 05:13:30 2015
From: szigiszabolcs at gmail.com (SZIGETI Szabolcs)
Date: Fri, 4 Dec 2015 20:13:30 +0100
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <CAKt831GfmmKQ75TRy1tCmmbnx4CGLmjy12zns6-c+_oJB+h2dA@mail.gmail.com>
References: <565F64A6.9080103@gmail.com> <20151203002042.GA7042@www.oztivo.net>
 <565FAADA.3040401@gmail.com>
 <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
 <565FC283.20704@gmail.com>
 <20151203060503.GB93851@server.rulingia.com>
 <alpine.BSF.2.11.1512041714400.27895@aneurin.horsfall.org>
 <20151204063819.GC58889@eureka.lemis.com>
 <20151204145218.GC24075@mercury.ccil.org>
 <CAKt831GfmmKQ75TRy1tCmmbnx4CGLmjy12zns6-c+_oJB+h2dA@mail.gmail.com>
Message-ID: <CAKt831G+0yEjXaR+GS7o7ynoGpa_ROEavCSiNAtiXVGrUES6Xw@mail.gmail.com>

Hi,

Don't forget the Zuse machines, which were later proven to be Turing
complete. It is certainly fascinating to see handling binary floating point
numbers in a purely mechanical device (check it out if you happen to be in
Berlin). Later machines were electromechanical and electronics.

Regards,
Szabolcs

>
> 2015.12.04. 15:52 ezt írta ("John Cowan" <cowan at mercury.ccil.org>):
>>
>> Greg 'groggy' Lehey scripsit:
>>
>> > Take a look at CSIRAC in the Melbourne museum, the oldest computer in
>> > the world.  It's worth it, even if they don't have it running.
>>
>> Well, there's the Antikythera mechanism.
>>
>> --
>> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
>> In the sciences, we are now uniquely privileged to sit side by side
>> with the giants on whose shoulders we stand.  --Gerald Holton
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151204/09bd5677/attachment.html>

From treese at acm.org  Sat Dec  5 07:33:35 2015
From: treese at acm.org (Win Treese)
Date: Fri, 4 Dec 2015 16:33:35 -0500
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
	using SimH and a healthy dose of documentation
In-Reply-To: <20151204005205.GH19002@eureka.lemis.com>
References: <20151203154200.7F88B18C086@mercury.lcs.mit.edu>
 <20151204005205.GH19002@eureka.lemis.com>
Message-ID: <A8E07E64-D8F2-435F-884B-3D8380840674@acm.org>


> On Dec 3, 2015, at 7:52 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> 	/* […]
> 	 * You are not expected to understand this.
> 	 */

Some of you may have been around for this USENIX
happening (or may even have been involved)!

Dennis was there wearing a "You are not expected to
understand this" T-shirt. A USENIX novice went up to
him and said "Oh, I can tell you about that." He started
going on about what the code is supposed to be doing.

Dennis stood there politely, not saying anything.

Finally, a USENIX old hand decided to rescue him.
"Come on, Dennis, we're heading off to dinner."

The novice looked down at Dennis’s nametag and
turned red.

Dennis said, "That's what we thought at first, but we
were wrong.”

 - Win



From cowan at mercury.ccil.org  Sat Dec  5 08:00:41 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Fri, 4 Dec 2015 17:00:41 -0500
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <A8E07E64-D8F2-435F-884B-3D8380840674@acm.org>
References: <20151203154200.7F88B18C086@mercury.lcs.mit.edu>
 <20151204005205.GH19002@eureka.lemis.com>
 <A8E07E64-D8F2-435F-884B-3D8380840674@acm.org>
Message-ID: <20151204220039.GF24075@mercury.ccil.org>

Win Treese scripsit:

> Dennis was there wearing a "You are not expected to
> understand this" T-shirt. A USENIX novice went up to
> him and said "Oh, I can tell you about that." He started
> going on about what the code is supposed to be doing.

Which shows that it's not only women who are the objects of mansplaining.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
The whole of Gaul is quartered into three halves.
        --Julius Caesar


From grog at lemis.com  Sat Dec  5 08:36:18 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sat, 5 Dec 2015 09:36:18 +1100
Subject: [TUHS] Some notes on running UNIX v6 in 2015,
 using SimH and a healthy dose of documentation
In-Reply-To: <1F998DC4-275F-4DE1-81F2-CC19BE714A7A@ronnatalie.com>
References: <565F64A6.9080103@gmail.com> <20151203002042.GA7042@www.oztivo.net>
 <565FAADA.3040401@gmail.com>
 <alpine.BSF.2.11.1512031453580.27895@aneurin.horsfall.org>
 <565FC283.20704@gmail.com>
 <20151203060503.GB93851@server.rulingia.com>
 <alpine.BSF.2.11.1512041714400.27895@aneurin.horsfall.org>
 <20151204063819.GC58889@eureka.lemis.com>
 <20151204145218.GC24075@mercury.ccil.org>
 <1F998DC4-275F-4DE1-81F2-CC19BE714A7A@ronnatalie.com>
Message-ID: <20151204223618.GA91061@eureka.lemis.com>

On Friday,  4 December 2015 at 13:17:58 -0500, Ronald Natalie wrote:
>
> I guess you???re going to have to qualify that.  It???s the oldest
> ???surviving??? (though it???s unclear what that means to a computer
> not running) STORED PROGRAM machine.

Guilty as charged.

> The ENIAC, which by some standards is the first programmable digital
> computer still exists at the Smithsonian.  Some of my coworkers there
> were on the team that took it down from BRL to the Smithsonian and
> actually tested it as operational when it was handed over to the
> museum.  I don???t think it???s ever been powered on since.

My understanding, which is borne out by the Wikipedia article, is that
only parts of ENIAC are on display at the Smithsonian.  It lists a
number of other places with parts.

But then there's yet another computer, the Zuse Z4 at the Deutsches
Museum in München.  Again from Wikipedia, it was built between 1942
and 1945, and thus predates ENIAC.  It seems that it's complete, but
of course it's not electronic.  So until proof of the contrary, CSIRAC
is the oldest surviving complete electronic computer.

Do I need more adjectives?

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151205/68702d65/attachment.sig>

From will.senn at gmail.com  Sun Dec  6 03:03:12 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 5 Dec 2015 11:03:12 -0600
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
Message-ID: <566318D0.6080709@gmail.com>

In exploring v6, I have found some uses for having a running v7 instance...

When I try to install the RP bootblock during the installation procedure 
for installing Version 7 Unix following the original documentation:
ftp://ftp.uvsq.fr/pub/tuhs/PDP-11/Documentation/v7_setup.html

I am unable to boot from the RP06 disk that I installed into the boot 
block onto via:
dd if=/usr/mdec/hpuboot of=/dev/rp0 count=1

No error, it just hangs. I compared hpuboot to the bootblock at it 
matches byte for byte. I also compared it to the hpuboot file in Henry 
Spencer's tape image (I am using Keith Bostic's tape) and it matches 
that as well.

I am asking this list because I thought y'all might know if there was a 
problem with:

1) the hpuboot binary on the tapes
2) v7 using RP06
3) something else helpful :) (maybe it's not supposed to be loaded to 
byte 0 on the disk image, although that's how it works with v6?)

I am aware that the system can be booted from tape, but that seems hokey 
(obviously it works, since that's how the installation process works in 
the first place, but I think it is reasonable to expect to be able to 
boot from the RP06). Interestingly, there are and RL02 and RK05 v7 
images that boot from disk available, but not RP.

I will ask on the SimH list, if y'all don't think it's appropriately 
directed.

Thoughts?

Thanks,

Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151205/d0babc98/attachment.html>

From clemc at ccc.com  Sun Dec  6 03:26:36 2015
From: clemc at ccc.com (Clem Cole)
Date: Sat, 5 Dec 2015 12:26:36 -0500
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <566318D0.6080709@gmail.com>
References: <566318D0.6080709@gmail.com>
Message-ID: <CAC20D2Meu++_Hv-YAxPs1wTgSz3ns-Du0ZFo68jEqsrQ=_WO=Q@mail.gmail.com>

On Sat, Dec 5, 2015 at 12:03 PM, Will Senn <will.senn at gmail.com> wrote:

> I am unable to boot from the RP06 disk that I installed into the boot
> block onto via:
> dd if=/usr/mdec/hpuboot of=/dev/rp0 count=1
>
​Doing this from memory as couple of issues:

1.) do an ls -l of /dev/*rp*  you need to use the raw (character) driver
not the blocked driver
2.) I believe the hp/rp driver is partitioned.   Make sure you use the
proper partition.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151205/55f79aee/attachment.html>

From will.senn at gmail.com  Sun Dec  6 03:44:47 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 5 Dec 2015 11:44:47 -0600
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <CAC20D2Meu++_Hv-YAxPs1wTgSz3ns-Du0ZFo68jEqsrQ=_WO=Q@mail.gmail.com>
References: <566318D0.6080709@gmail.com>
 <CAC20D2Meu++_Hv-YAxPs1wTgSz3ns-Du0ZFo68jEqsrQ=_WO=Q@mail.gmail.com>
Message-ID: <5663228F.1070307@gmail.com>



On 12/5/15 11:26 AM, Clem Cole wrote:
>
> On Sat, Dec 5, 2015 at 12:03 PM, Will Senn <will.senn at gmail.com 
> <mailto:will.senn at gmail.com>> wrote:
>
>     I am unable to boot from the RP06 disk that I installed into the
>     boot block onto via:
>     dd if=/usr/mdec/hpuboot of=/dev/rp0 count=1
>
> ​Doing this from memory as couple of issues:
>
> 1.) do an ls -l of /dev/*rp*  you need to use the raw (character) 
> driver not the blocked driver
> 2.) I believe the hp/rp driver is partitioned.   Make sure you use the 
> proper partition.​
>
>
Clem,

I tried it with the raw device and partition 0. Here are the devices and 
my approach:

# ls /dev/*rp*
/dev/rp0
/dev/rp3
/dev/rrp0
/dev/rrp3

# /etc/mount /dev/rp3 /usr
# dd if=/usr/mdec/hpuboot of=/dev/rrp0 count=1 conv=sync
0+1 records in
1+0 records out
or
# dd if=/usr/mdec/hpuboot of=/dev/rrp0 count=1
0+1 records in
0+1 records out

# sync
# sync
# sync
CTRL-E

Simulation stopped, PC: 002306 (MOV (SP)+,177776)
sim> q
Goodbye

TERRA:bostic-v7 wsenn$ pdp11 nboot.ini

PDP-11 simulator V4.0-0 Beta        git commit id: 0f43551d

Disabling XQ

Hangs either way!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151205/d104372b/attachment.html>

From hellwig.geisse at mni.thm.de  Sun Dec  6 03:53:25 2015
From: hellwig.geisse at mni.thm.de (Hellwig Geisse)
Date: Sat, 05 Dec 2015 18:53:25 +0100
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <566318D0.6080709@gmail.com>
References: <566318D0.6080709@gmail.com>
Message-ID: <1449338005.9737.64.camel@papa2>

Will,

when I brought up UNIX V7 on simh ~10 years ago, I used
Keith Bostic's tape, a simulated PDP11/45, an RP04 disk and
a TU10 tape drive. With this configuration it worked exactly
as described in 'Setting Up Unix'. IIRC, other configurations
had problems, although I never investigated this further.

You can find my package and a HOWTO here:
http://homepages.thm.de/~hg53/pdp11-unix

One note of caution: I did not try to build the whole thing
on a modern 64-bit system; it may well refuse to run. I will
try to bring it up on my 64-bit Linux box and then report
back here, if you are interested.

Hellwig



From will.senn at gmail.com  Sun Dec  6 04:01:29 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 5 Dec 2015 12:01:29 -0600
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <1449338005.9737.64.camel@papa2>
References: <566318D0.6080709@gmail.com> <1449338005.9737.64.camel@papa2>
Message-ID: <56632679.8060300@gmail.com>


On 12/5/15 11:53 AM, Hellwig Geisse wrote:
> Will,
>
> when I brought up UNIX V7 on simh ~10 years ago, I used
> Keith Bostic's tape, a simulated PDP11/45, an RP04 disk and
> a TU10 tape drive. With this configuration it worked exactly
> as described in 'Setting Up Unix'. IIRC, other configurations
> had problems, although I never investigated this further.
>
> You can find my package and a HOWTO here:
> http://homepages.thm.de/~hg53/pdp11-unix
>
> One note of caution: I did not try to build the whole thing
> on a modern 64-bit system; it may well refuse to run. I will
> try to bring it up on my 64-bit Linux box and then report
> back here, if you are interested.
>
> Hellwig
>
Hellwig,

Much thanks for the explanation and link. I will try your instructions 
and see if they still work. Your notes are exceptionally clear, I expect 
if I follow them things, will work as expected. I'll let you know.

Thanks,

Will


From will.senn at gmail.com  Sun Dec  6 04:39:36 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 5 Dec 2015 12:39:36 -0600
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <56632679.8060300@gmail.com>
References: <566318D0.6080709@gmail.com> <1449338005.9737.64.camel@papa2>
 <56632679.8060300@gmail.com>
Message-ID: <56632F68.9050001@gmail.com>

Problem solved - see below.

On 12/5/15 12:01 PM, Will Senn wrote:
>
> On 12/5/15 11:53 AM, Hellwig Geisse wrote:
>> Will,
>>
>> One note of caution: I did not try to build the whole thing
>> on a modern 64-bit system; it may well refuse to run. I will
>> try to bring it up on my 64-bit Linux box and then report
>> back here, if you are interested.
>>
>> Hellwig
>>
> Hellwig,
>
> Much thanks for the explanation and link. I will try your instructions 
> and see if they still work. Your notes are exceptionally clear, I 
> expect if I follow them things, will work as expected. I'll let you know.
>
> Thanks,
>
> Will
Well, you were right, sim didn't want to build 64 bit. However, I 
already had a working sim, so I simply used the existing pdp11 binary 
and your instructions. They worked!

In the process, I figured out that the original approach that I used 
worked as well. The issue wasn't with the RP disk, it was with the 
singular lack of a Boot prompt '@'. There isn't one. After the simulator 
prints 'Disabling XQ', the boot loader is just sitting there waiting for 
the user to type 'boot', at which point the loader will print 'Boot' and 
the ':' prompt will appear, allowing the kernel to be specified:

pdp11 tboot.ini
PDP-11 simulator V4.0-0 Beta        git commit id: 0f43551d
Disabling XQ
boot
Boot
: hp(0,0)unix
mem = 2020544
#

Thanks Hellwig and thanks Cole!

Regards,

Will



From hellwig.geisse at mni.thm.de  Sun Dec  6 04:53:07 2015
From: hellwig.geisse at mni.thm.de (Hellwig Geisse)
Date: Sat, 05 Dec 2015 19:53:07 +0100
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <56632F68.9050001@gmail.com>
References: <566318D0.6080709@gmail.com> <1449338005.9737.64.camel@papa2>
 <56632679.8060300@gmail.com> <56632F68.9050001@gmail.com>
Message-ID: <1449341587.9737.75.camel@papa2>

On Sa, 2015-12-05 at 12:39 -0600, Will Senn wrote:
> Well, you were right, sim didn't want to build 64 bit. However, I 
> already had a working sim, so I simply used the existing pdp11 binary 
> and your instructions. They worked!

I also tried it, but on my system simh compiles (there are a few
warnings which isn't nice, but all of them harmless) and it runs
without errors, as far as I can see.

> Thanks Hellwig and thanks Cole!

You're welcome - thanks for trying!

Hellwig



From will.senn at gmail.com  Sun Dec  6 05:46:19 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 5 Dec 2015 13:46:19 -0600
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <1449341587.9737.75.camel@papa2>
References: <566318D0.6080709@gmail.com> <1449338005.9737.64.camel@papa2>
 <56632679.8060300@gmail.com> <56632F68.9050001@gmail.com>
 <1449341587.9737.75.camel@papa2>
Message-ID: <56633F0B.607@gmail.com>



On 12/5/15 12:53 PM, Hellwig Geisse wrote:
> On Sa, 2015-12-05 at 12:39 -0600, Will Senn wrote:
>> Well, you were right, sim didn't want to build 64 bit. However, I
>> already had a working sim, so I simply used the existing pdp11 binary
>> and your instructions. They worked!
> I also tried it, but on my system simh compiles (there are a few
> warnings which isn't nice, but all of them harmless) and it runs
> without errors, as far as I can see.
>
Hellwig,

I only tried in on my Macbook with El Capitan, but I just confirmed that 
it works fine on FreeBSD 10.2 with the warnings as you describe.

Thanks,

Will


From clemc at ccc.com  Sun Dec  6 05:47:41 2015
From: clemc at ccc.com (Clem Cole)
Date: Sat, 5 Dec 2015 14:47:41 -0500
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <5663228F.1070307@gmail.com>
References: <566318D0.6080709@gmail.com>
 <CAC20D2Meu++_Hv-YAxPs1wTgSz3ns-Du0ZFo68jEqsrQ=_WO=Q@mail.gmail.com>
 <5663228F.1070307@gmail.com>
Message-ID: <CAC20D2M1_KCpYdtPGcrb92kpxVt=t6S23JzM+MCijF6vhWKfAw@mail.gmail.com>

Ah I gather you are running on rp0 (ie it's mounted as root).

Do the dd from the standalone system or boot from an rk05

On Sat, Dec 5, 2015 at 12:44 PM, Will Senn <will.senn at gmail.com> wrote:

>
>
> On 12/5/15 11:26 AM, Clem Cole wrote:
>
>
> On Sat, Dec 5, 2015 at 12:03 PM, Will Senn <will.senn at gmail.com> wrote:
>
>> I am unable to boot from the RP06 disk that I installed into the boot
>> block onto via:
>> dd if=/usr/mdec/hpuboot of=/dev/rp0 count=1
>>
> ​Doing this from memory as couple of issues:
>
> 1.) do an ls -l of /dev/*rp*  you need to use the raw (character) driver
> not the blocked driver
> 2.) I believe the hp/rp driver is partitioned.   Make sure you use the
> proper partition.​
>
>
> Clem,
>
> I tried it with the raw device and partition 0. Here are the devices and
> my approach:
>
> # ls /dev/*rp*
> /dev/rp0
> /dev/rp3
> /dev/rrp0
> /dev/rrp3
>
> # /etc/mount /dev/rp3 /usr
> # dd if=/usr/mdec/hpuboot of=/dev/rrp0 count=1 conv=sync
> 0+1 records in
> 1+0 records out
> or
> # dd if=/usr/mdec/hpuboot of=/dev/rrp0 count=1
> 0+1 records in
> 0+1 records out
>
> # sync
> # sync
> # sync
> CTRL-E
>
> Simulation stopped, PC: 002306 (MOV (SP)+,177776)
> sim> q
> Goodbye
>
> TERRA:bostic-v7 wsenn$ pdp11 nboot.ini
>
> PDP-11 simulator V4.0-0 Beta        git commit id: 0f43551d
>
> Disabling XQ
>
> Hangs either way!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151205/38c1a965/attachment.html>

From clemc at ccc.com  Sun Dec  6 05:53:11 2015
From: clemc at ccc.com (Clem Cole)
Date: Sat, 5 Dec 2015 14:53:11 -0500
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <CAC20D2M1_KCpYdtPGcrb92kpxVt=t6S23JzM+MCijF6vhWKfAw@mail.gmail.com>
References: <566318D0.6080709@gmail.com>
 <CAC20D2Meu++_Hv-YAxPs1wTgSz3ns-Du0ZFo68jEqsrQ=_WO=Q@mail.gmail.com>
 <5663228F.1070307@gmail.com>
 <CAC20D2M1_KCpYdtPGcrb92kpxVt=t6S23JzM+MCijF6vhWKfAw@mail.gmail.com>
Message-ID: <CAC20D2Pr=5D8Y+8n1kiaG-T0sfTdAMxQPdPc4DoWSvDbAfVQ=g@mail.gmail.com>

You are most welcome -- BTW:  the first name is Clement, my last is Cole
and my friends call me Clem.

One thing to remember... when woring with older versions of UNIX its not a
good idea to be modify in the a partition that is live.   Later versions
were better about keeping the buffering system of your way.

Ken wrote the standalone tools for V7 so you do those sort of low level
things from it.

Best wishes.

Clem

On Sat, Dec 5, 2015 at 2:47 PM, Clem Cole <clemc at ccc.com> wrote:

> Ah I gather you are running on rp0 (ie it's mounted as root).
>
> Do the dd from the standalone system or boot from an rk05
>
> On Sat, Dec 5, 2015 at 12:44 PM, Will Senn <will.senn at gmail.com> wrote:
>
>>
>>
>> On 12/5/15 11:26 AM, Clem Cole wrote:
>>
>>
>> On Sat, Dec 5, 2015 at 12:03 PM, Will Senn <will.senn at gmail.com> wrote:
>>
>>> I am unable to boot from the RP06 disk that I installed into the boot
>>> block onto via:
>>> dd if=/usr/mdec/hpuboot of=/dev/rp0 count=1
>>>
>> ​Doing this from memory as couple of issues:
>>
>> 1.) do an ls -l of /dev/*rp*  you need to use the raw (character) driver
>> not the blocked driver
>> 2.) I believe the hp/rp driver is partitioned.   Make sure you use the
>> proper partition.​
>>
>>
>> Clem,
>>
>> I tried it with the raw device and partition 0. Here are the devices and
>> my approach:
>>
>> # ls /dev/*rp*
>> /dev/rp0
>> /dev/rp3
>> /dev/rrp0
>> /dev/rrp3
>>
>> # /etc/mount /dev/rp3 /usr
>> # dd if=/usr/mdec/hpuboot of=/dev/rrp0 count=1 conv=sync
>> 0+1 records in
>> 1+0 records out
>> or
>> # dd if=/usr/mdec/hpuboot of=/dev/rrp0 count=1
>> 0+1 records in
>> 0+1 records out
>>
>> # sync
>> # sync
>> # sync
>> CTRL-E
>>
>> Simulation stopped, PC: 002306 (MOV (SP)+,177776)
>> sim> q
>> Goodbye
>>
>> TERRA:bostic-v7 wsenn$ pdp11 nboot.ini
>>
>> PDP-11 simulator V4.0-0 Beta        git commit id: 0f43551d
>>
>> Disabling XQ
>>
>> Hangs either way!
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151205/1e05d6cf/attachment.html>

From ron at ronnatalie.com  Sun Dec  6 05:59:25 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sat, 5 Dec 2015 14:59:25 -0500
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <CAC20D2Pr=5D8Y+8n1kiaG-T0sfTdAMxQPdPc4DoWSvDbAfVQ=g@mail.gmail.com>
References: <566318D0.6080709@gmail.com>
 <CAC20D2Meu++_Hv-YAxPs1wTgSz3ns-Du0ZFo68jEqsrQ=_WO=Q@mail.gmail.com>
 <5663228F.1070307@gmail.com>
 <CAC20D2M1_KCpYdtPGcrb92kpxVt=t6S23JzM+MCijF6vhWKfAw@mail.gmail.com>
 <CAC20D2Pr=5D8Y+8n1kiaG-T0sfTdAMxQPdPc4DoWSvDbAfVQ=g@mail.gmail.com>
Message-ID: <17100D40-195A-4A0D-9B2D-A10778FDA9C0@ronnatalie.com>


> On Dec 5, 2015, at 2:53 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> You are most welcome -- BTW:  the first name is Clement, my last is Cole and my friends call me Clem.

Uh, Clem is right out?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151205/cbb6cc57/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151205/cbb6cc57/attachment.bin>

From will.senn at gmail.com  Sun Dec  6 06:08:47 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 5 Dec 2015 14:08:47 -0600
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <CAC20D2Pr=5D8Y+8n1kiaG-T0sfTdAMxQPdPc4DoWSvDbAfVQ=g@mail.gmail.com>
References: <566318D0.6080709@gmail.com>
 <CAC20D2Meu++_Hv-YAxPs1wTgSz3ns-Du0ZFo68jEqsrQ=_WO=Q@mail.gmail.com>
 <5663228F.1070307@gmail.com>
 <CAC20D2M1_KCpYdtPGcrb92kpxVt=t6S23JzM+MCijF6vhWKfAw@mail.gmail.com>
 <CAC20D2Pr=5D8Y+8n1kiaG-T0sfTdAMxQPdPc4DoWSvDbAfVQ=g@mail.gmail.com>
Message-ID: <5663444F.9070705@gmail.com>

Thanks for the clarification and information. I will keep these things 
in mind.

Regards,

Will

On 12/5/15 1:53 PM, Clem Cole wrote:
> You are most welcome -- BTW:  the first name is Clement, my last is 
> Cole and my friends call me Clem.
>
> One thing to remember... when woring with older versions of UNIX its 
> not a good idea to be modify in the a partition that is live. Later 
> versions were better about keeping the buffering system of your way.
>
> Ken wrote the standalone tools for V7 so you do those sort of low 
> level things from it.
>
> Best wishes.
>
> Clem
>
> On Sat, Dec 5, 2015 at 2:47 PM, Clem Cole <clemc at ccc.com 
> <mailto:clemc at ccc.com>> wrote:
>
>     Ah I gather you are running on rp0 (ie it's mounted as root).
>
>     Do the dd from the standalone system or boot from an rk05
>
>     On Sat, Dec 5, 2015 at 12:44 PM, Will Senn <will.senn at gmail.com
>     <mailto:will.senn at gmail.com>> wrote:
>
>
>
>         On 12/5/15 11:26 AM, Clem Cole wrote:
>>
>>         On Sat, Dec 5, 2015 at 12:03 PM, Will Senn
>>         <will.senn at gmail.com <mailto:will.senn at gmail.com>> wrote:
>>
>>             I am unable to boot from the RP06 disk that I installed
>>             into the boot block onto via:
>>             dd if=/usr/mdec/hpuboot of=/dev/rp0 count=1
>>
>>         ​ Doing this from memory as couple of issues:
>>
>>         1.) do an ls -l of /dev/*rp*  you need to use the raw
>>         (character) driver not the blocked driver
>>         2.) I believe the hp/rp driver is partitioned.   Make sure
>>         you use the proper partition.​
>>
>>
>         Clem,
>
>         I tried it with the raw device and partition 0. Here are the
>         devices and my approach:
>
>         # ls /dev/*rp*
>         /dev/rp0
>         /dev/rp3
>         /dev/rrp0
>         /dev/rrp3
>
>         # /etc/mount /dev/rp3 /usr
>         # dd if=/usr/mdec/hpuboot of=/dev/rrp0 count=1 conv=sync
>         0+1 records in
>         1+0 records out
>         or
>         # dd if=/usr/mdec/hpuboot of=/dev/rrp0 count=1
>         0+1 records in
>         0+1 records out
>
>         # sync
>         # sync
>         # sync
>         CTRL-E
>
>         Simulation stopped, PC: 002306 (MOV (SP)+,177776)
>         sim> q
>         Goodbye
>
>         TERRA:bostic-v7 wsenn$ pdp11 nboot.ini
>
>         PDP-11 simulator V4.0-0 Beta        git commit id: 0f43551d
>
>         Disabling XQ
>
>         Hangs either way!
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151205/aaf4910f/attachment.html>

From will.senn at gmail.com  Sun Dec  6 06:11:22 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 5 Dec 2015 14:11:22 -0600
Subject: [TUHS] Adding an RP06 disk to a running V7 instance
Message-ID: <566344EA.7010401@gmail.com>

I have set up v7 following [1] and I would like to better understand the 
process of adding a disk to the environment. Here is what I know:

The system has one RP06 with two partitions rp0 and rp3 which correspond 
to the two block devices rp0, rp3, and the two character devices rrp0, 
and rrp3. The special files look like so:
brw-r--r-- 1 root    6,  0 Dec 31 19:05 /dev/rp0
brw-r--r-- 1 root    6,  7 Dec 31 19:04 /dev/rp3
crw-r--r-- 1 root   14,  0 Dec 31 19:01 /dev/rrp0
crw-r--r-- 1 root   14,  7 Dec 31 19:01 /dev/rrp3

This meshes with the device classes switches in c.c:

The block device switch:
struct  bdevsw  bdevsw[] =
{
...
         nulldev, nulldev, hpstrategy, &hptab,   /* hp = 6 */
...
}

The character device switch:
struct  cdevsw  cdevsw[] =
{
...
         nulldev, nulldev, hpread, hpwrite, nodev, nulldev, 0,   /* hp = 
14 */
...
}

I would like to add another RP disk to the environment. After I attach 
an RP04/05/06 to the system, what should I use as the major/minor device 
numbers? To put it differently, it doesn't seem correct to me to use 6,1 
for the block device or 14,1 for the character device on the new drive 
as it's a completely different disk from rp0 and rp3 which are just 
partitions on the first drive and have 6,0, 6,7, and 14,0, 14,7. If each 
RP can have 8 partitions and there can be 8 drives, what is the correct 
major, minor numbers to use with v7 for multiple devices?

c.c only lists one vector each for the hp device (one block vector where 
hp = 6, and one char vector where hp = 15).

Thanks,

Will


[1] Haley, C. B. & Ritchie, D. M. (1979). Setting Up Unix – Seventh 
Edition (pp. 497-505) in UNIX programmer's manual, Vol. 2, Revised and 
Expanded Version. Bell Laboratories: NY.



From cowan at mercury.ccil.org  Sun Dec  6 06:12:56 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Sat, 5 Dec 2015 15:12:56 -0500
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <56632F68.9050001@gmail.com>
References: <566318D0.6080709@gmail.com> <1449338005.9737.64.camel@papa2>
 <56632679.8060300@gmail.com> <56632F68.9050001@gmail.com>
Message-ID: <20151205201254.GD2383@mercury.ccil.org>

Will Senn scripsit:

> Well, you were right, sim didn't want to build 64 bit. However, I
> already had a working sim, so I simply used the existing pdp11
> binary and your instructions. They worked!

I simply wrap gcc in this script:

#!/bin/sh
exec /usr/bin/gcc -m32 "$@"

to solve problems like this.  I keep it in ~/bin named gcc32 and
then rename it to gcc when I need to compile 32-bit-specific code.
It's much better than trying to whack on the Makefile.  I wish I could
use a similar hack to get bas/bs running directly on Linux: they seem
to assume 16-bitness, and segfault quickly.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
I don't know half of you half as well as I should like, and I like less
than half of you half as well as you deserve.  --Bilbo


From ron at ronnatalie.com  Sun Dec  6 06:17:56 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sat, 5 Dec 2015 15:17:56 -0500
Subject: [TUHS] Adding an RP06 disk to a running V7 instance
In-Reply-To: <566344EA.7010401@gmail.com>
References: <566344EA.7010401@gmail.com>
Message-ID: <63EEF957-00FD-4C1A-A290-70A4FDC4DA81@ronnatalie.com>

You want to add another drive?   The lower 3 bites selects the partition, the upper bits (shfited right 3) are the drive number.
The second disk (to match your first) would use 6,8 and 6,15 and 14,8 and 14,15 respectively.

> On Dec 5, 2015, at 3:11 PM, Will Senn <will.senn at gmail.com> wrote:
> 
> 
> I would like to add another RP disk to the environment. After I attach an RP04/05/06 to the system, what should I use as the major/minor device numbers? To put it differently, it doesn't seem correct to me to use 6,1 for the block device or 14,1 for the character device on the new drive as it's a completely different disk from rp0 and rp3 which are just partitions on the first drive and have 6,0, 6,7, and 14,0, 14,7. If each RP can have 8 partitions and there can be 8 drives, what is the correct major, minor numbers to use with v7 for multiple devices?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151205/84379840/attachment.bin>

From clemc at ccc.com  Sun Dec  6 06:47:06 2015
From: clemc at ccc.com (Clem cole)
Date: Sat, 5 Dec 2015 15:47:06 -0500
Subject: [TUHS] boot block in v7 bootable on rp06 in simh
In-Reply-To: <17100D40-195A-4A0D-9B2D-A10778FDA9C0@ronnatalie.com>
References: <566318D0.6080709@gmail.com>
 <CAC20D2Meu++_Hv-YAxPs1wTgSz3ns-Du0ZFo68jEqsrQ=_WO=Q@mail.gmail.com>
 <5663228F.1070307@gmail.com>
 <CAC20D2M1_KCpYdtPGcrb92kpxVt=t6S23JzM+MCijF6vhWKfAw@mail.gmail.com>
 <CAC20D2Pr=5D8Y+8n1kiaG-T0sfTdAMxQPdPc4DoWSvDbAfVQ=g@mail.gmail.com>
 <17100D40-195A-4A0D-9B2D-A10778FDA9C0@ronnatalie.com>
Message-ID: <D9935A9E-08CE-47AA-A763-3BD510FF46DE@ccc.com>

Ah Clem😉

Sent from my iPhone

> On Dec 5, 2015, at 2:59 PM, Ronald Natalie <ron at ronnatalie.com> wrote:
> 
> 
>> On Dec 5, 2015, at 2:53 PM, Clem Cole <clemc at ccc.com> wrote:
>> 
>> You are most welcome -- BTW:  the first name is Clement, my last is Cole and my friends call me Clem.
> 
> Uh, Clem is right out?
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151205/07e39716/attachment.html>

From will.senn at gmail.com  Sun Dec  6 08:33:31 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 5 Dec 2015 16:33:31 -0600
Subject: [TUHS] Adding an RP06 disk to a running V7 instance
In-Reply-To: <63EEF957-00FD-4C1A-A290-70A4FDC4DA81@ronnatalie.com>
References: <566344EA.7010401@gmail.com>
 <63EEF957-00FD-4C1A-A290-70A4FDC4DA81@ronnatalie.com>
Message-ID: <5663663B.5030400@gmail.com>


The v7 manual suggests running /usr mounted on a separate drive from /. 
I am trying to follow this advice, but I am getting a read error on the 
newly added disk.

I read hp(4). According to this man page, hp partitions each device into 
8 partitions of different sizes and lengths (given in cylinders of 418 
512-byte blocks). Here are the partitions from the man page, where disk 
refers to pseudodisks on each drive (are these partitions?):

disk start length
0 0 23
1 23 21
2 0 0
3 0 0
4 44 386
5 430 385
6 44 367
7 44 771

It would appear that:
partitions 0, 1 and 7 combined account for the entire contiguous disk, 
cylinders 0-815, and has the largest single partition (partition 7) of 
any of the schemes. This seems like the default scheme and during a 
default setup accounts for rp0 on partition 0 and rp3 on partition 7.
partitions 0, 1 and 6 combined only account for cylinders 0-411.
partitions 0, 1, 4, and 5 combined, but with more slices than the first 
scheme, also account for the entire disk cylinders 0-815.
partitions 2 and 3 don't seem to be useable.

Given the above constraints, it seems like the first partition scheme 
that includes partition 7 would also be a good choice to use for an 
additional drive.

I kept this in mind and added an additional RP06 to the PDP11/45 
simulation. At boot, I tried two different approaches to handling the 
new drive, both had the same problem ultimately. The first was to simply 
ignore it until after booting into unix and then creating the special 
files as Ronald describes and then running mkfs:

/etc/mknod rp3 b 6 8
/etc/mknod rrp3 c 14 15
chmod go-w rp3 rrp3

/etc/mkfs /dev/rp3 322278
isize = 10328
m/n = 3 500

I don't see any errors, but the isize is different than it is during the 
default install onto the first drive.

The second was to use tm(0,3) (is this mkfs or something like it?) like 
I did for the first drive:
tm(0,3)
file sys size: 5000
file system: hp(1,0)
isize = 1600
m/n = 3 500

then after creating the same special files as above, mkfs works the same 
way it did on the default setup on drive 0:
/etc/mkfs /dev/rp3 322278
isize = 65496
m/n = 3 500

Still no errors, but when I try to check the filesystem with icheck, or 
restore a filesystem from tape to the drive, I get the following error:
read error 9736

full result:
icheck /dev/rp3
/dev/rp3:
read error 9736
files      2 (r=1,d=1,b=0,c=0)
used       1 (i=0,ii=0,iii=0,d=1)
free    1389
missing312699

What does it look like I am doing wrong?

Thanks,

Will

On 12/5/15 2:17 PM, Ronald Natalie wrote:
> You want to add another drive?   The lower 3 bites selects the partition, the upper bits (shfited right 3) are the drive number.
> The second disk (to match your first) would use 6,8 and 6,15 and 14,8 and 14,15 respectively.
>
>> On Dec 5, 2015, at 3:11 PM, Will Senn <will.senn at gmail.com> wrote:
>>
>>
>> I would like to add another RP disk to the environment. After I attach an RP04/05/06 to the system, what should I use as the major/minor device numbers? To put it differently, it doesn't seem correct to me to use 6,1 for the block device or 14,1 for the character device on the new drive as it's a completely different disk from rp0 and rp3 which are just partitions on the first drive and have 6,0, 6,7, and 14,0, 14,7. If each RP can have 8 partitions and there can be 8 drives, what is the correct major, minor numbers to use with v7 for multiple devices?
>



From stewart at serissa.com  Sun Dec  6 08:48:41 2015
From: stewart at serissa.com (Lawrence Stewart)
Date: Sat, 5 Dec 2015 17:48:41 -0500
Subject: [TUHS] Adding an RP06 disk to a running V7 instance
In-Reply-To: <5663663B.5030400@gmail.com>
References: <566344EA.7010401@gmail.com>
 <63EEF957-00FD-4C1A-A290-70A4FDC4DA81@ronnatalie.com>
 <5663663B.5030400@gmail.com>
Message-ID: <86631035-517A-4C4B-B75F-236B3E125AC7@serissa.com>

The reason for the advice to run root and usr on separate drives is so you don’t have to seek back and forth
between the two partitions if they are on the same drive.  That reason doesn’t apply to simulators, since the
drives are just files anyway.

But it looks to me like you have the wrong minor device numbers for the block device

If you want partition 7 of the second drive youwant
mknod rp3 b 6 15
not b 6 8

minor device 8 would be partition 0 of the second drive, minor 9 is partition 1 of the second drive, etc.

-L

> On 2015, Dec 5, at 5:33 PM, Will Senn <will.senn at gmail.com> wrote:
> 
> 
> The v7 manual suggests running /usr mounted on a separate drive from /. I am trying to follow this advice, but I am getting a read error on the newly added disk.
> 
> I read hp(4). According to this man page, hp partitions each device into 8 partitions of different sizes and lengths (given in cylinders of 418 512-byte blocks). Here are the partitions from the man page, where disk refers to pseudodisks on each drive (are these partitions?):
> 
> disk start length
> 0 0 23
> 1 23 21
> 2 0 0
> 3 0 0
> 4 44 386
> 5 430 385
> 6 44 367
> 7 44 771
> 
> It would appear that:
> partitions 0, 1 and 7 combined account for the entire contiguous disk, cylinders 0-815, and has the largest single partition (partition 7) of any of the schemes. This seems like the default scheme and during a default setup accounts for rp0 on partition 0 and rp3 on partition 7.
> partitions 0, 1 and 6 combined only account for cylinders 0-411.
> partitions 0, 1, 4, and 5 combined, but with more slices than the first scheme, also account for the entire disk cylinders 0-815.
> partitions 2 and 3 don't seem to be useable.
> 
> Given the above constraints, it seems like the first partition scheme that includes partition 7 would also be a good choice to use for an additional drive.
> 
> I kept this in mind and added an additional RP06 to the PDP11/45 simulation. At boot, I tried two different approaches to handling the new drive, both had the same problem ultimately. The first was to simply ignore it until after booting into unix and then creating the special files as Ronald describes and then running mkfs:
> 
> /etc/mknod rp3 b 6 8
> /etc/mknod rrp3 c 14 15
> chmod go-w rp3 rrp3
> 
> /etc/mkfs /dev/rp3 322278
> isize = 10328
> m/n = 3 500
> 
> I don't see any errors, but the isize is different than it is during the default install onto the first drive.
> 
> The second was to use tm(0,3) (is this mkfs or something like it?) like I did for the first drive:
> tm(0,3)
> file sys size: 5000
> file system: hp(1,0)
> isize = 1600
> m/n = 3 500
> 
> then after creating the same special files as above, mkfs works the same way it did on the default setup on drive 0:
> /etc/mkfs /dev/rp3 322278
> isize = 65496
> m/n = 3 500
> 
> Still no errors, but when I try to check the filesystem with icheck, or restore a filesystem from tape to the drive, I get the following error:
> read error 9736
> 
> full result:
> icheck /dev/rp3
> /dev/rp3:
> read error 9736
> files      2 (r=1,d=1,b=0,c=0)
> used       1 (i=0,ii=0,iii=0,d=1)
> free    1389
> missing312699
> 
> What does it look like I am doing wrong?
> 
> Thanks,
> 
> Will
> 
> On 12/5/15 2:17 PM, Ronald Natalie wrote:
>> You want to add another drive?   The lower 3 bites selects the partition, the upper bits (shfited right 3) are the drive number.
>> The second disk (to match your first) would use 6,8 and 6,15 and 14,8 and 14,15 respectively.
>> 
>>> On Dec 5, 2015, at 3:11 PM, Will Senn <will.senn at gmail.com> wrote:
>>> 
>>> 
>>> I would like to add another RP disk to the environment. After I attach an RP04/05/06 to the system, what should I use as the major/minor device numbers? To put it differently, it doesn't seem correct to me to use 6,1 for the block device or 14,1 for the character device on the new drive as it's a completely different disk from rp0 and rp3 which are just partitions on the first drive and have 6,0, 6,7, and 14,0, 14,7. If each RP can have 8 partitions and there can be 8 drives, what is the correct major, minor numbers to use with v7 for multiple devices?
>> 
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs



From will.senn at gmail.com  Sun Dec  6 09:04:03 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 5 Dec 2015 17:04:03 -0600
Subject: [TUHS] Adding an RP06 disk to a running V7 instance
In-Reply-To: <86631035-517A-4C4B-B75F-236B3E125AC7@serissa.com>
References: <566344EA.7010401@gmail.com>
 <63EEF957-00FD-4C1A-A290-70A4FDC4DA81@ronnatalie.com>
 <5663663B.5030400@gmail.com>
 <86631035-517A-4C4B-B75F-236B3E125AC7@serissa.com>
Message-ID: <56636D63.70303@gmail.com>

Lawrence,

Thanks for the note. Moving /usr to another drive served as both an 
exercise for me to understand how it works and for me to follow the 
advice. Good to know the advice is less applicable to the sim. You were 
correct about the math, duh, 1111 is 15, not 8 :). All good now.

Thanks,

Will

On 12/5/15 4:48 PM, Lawrence Stewart wrote:
> The reason for the advice to run root and usr on separate drives is so you don’t have to seek back and forth
> between the two partitions if they are on the same drive.  That reason doesn’t apply to simulators, since the
> drives are just files anyway.
>
> But it looks to me like you have the wrong minor device numbers for the block device
>
> If you want partition 7 of the second drive youwant
> mknod rp3 b 6 15
> not b 6 8
>
> minor device 8 would be partition 0 of the second drive, minor 9 is partition 1 of the second drive, etc.
>
> -L
>
>> On 2015, Dec 5, at 5:33 PM, Will Senn <will.senn at gmail.com> wrote:
>>
>>
>> The v7 manual suggests running /usr mounted on a separate drive from /. I am trying to follow this advice, but I am getting a read error on the newly added disk.
>>
>> I read hp(4). According to this man page, hp partitions each device into 8 partitions of different sizes and lengths (given in cylinders of 418 512-byte blocks). Here are the partitions from the man page, where disk refers to pseudodisks on each drive (are these partitions?):
>>
>> disk start length
>> 0 0 23
>> 1 23 21
>> 2 0 0
>> 3 0 0
>> 4 44 386
>> 5 430 385
>> 6 44 367
>> 7 44 771
>>
>> It would appear that:
>> partitions 0, 1 and 7 combined account for the entire contiguous disk, cylinders 0-815, and has the largest single partition (partition 7) of any of the schemes. This seems like the default scheme and during a default setup accounts for rp0 on partition 0 and rp3 on partition 7.
>> partitions 0, 1 and 6 combined only account for cylinders 0-411.
>> partitions 0, 1, 4, and 5 combined, but with more slices than the first scheme, also account for the entire disk cylinders 0-815.
>> partitions 2 and 3 don't seem to be useable.
>>
>> Given the above constraints, it seems like the first partition scheme that includes partition 7 would also be a good choice to use for an additional drive.
>>
>> I kept this in mind and added an additional RP06 to the PDP11/45 simulation. At boot, I tried two different approaches to handling the new drive, both had the same problem ultimately. The first was to simply ignore it until after booting into unix and then creating the special files as Ronald describes and then running mkfs:
>>
>> /etc/mknod rp3 b 6 8
>> /etc/mknod rrp3 c 14 15
>> chmod go-w rp3 rrp3
>>
>> /etc/mkfs /dev/rp3 322278
>> isize = 10328
>> m/n = 3 500
>>
>> I don't see any errors, but the isize is different than it is during the default install onto the first drive.
>>
>> The second was to use tm(0,3) (is this mkfs or something like it?) like I did for the first drive:
>> tm(0,3)
>> file sys size: 5000
>> file system: hp(1,0)
>> isize = 1600
>> m/n = 3 500
>>
>> then after creating the same special files as above, mkfs works the same way it did on the default setup on drive 0:
>> /etc/mkfs /dev/rp3 322278
>> isize = 65496
>> m/n = 3 500
>>
>> Still no errors, but when I try to check the filesystem with icheck, or restore a filesystem from tape to the drive, I get the following error:
>> read error 9736
>>
>> full result:
>> icheck /dev/rp3
>> /dev/rp3:
>> read error 9736
>> files      2 (r=1,d=1,b=0,c=0)
>> used       1 (i=0,ii=0,iii=0,d=1)
>> free    1389
>> missing312699
>>
>> What does it look like I am doing wrong?
>>
>> Thanks,
>>
>> Will
>>
>> On 12/5/15 2:17 PM, Ronald Natalie wrote:
>>> You want to add another drive?   The lower 3 bites selects the partition, the upper bits (shfited right 3) are the drive number.
>>> The second disk (to match your first) would use 6,8 and 6,15 and 14,8 and 14,15 respectively.
>>>
>>>> On Dec 5, 2015, at 3:11 PM, Will Senn <will.senn at gmail.com> wrote:
>>>>
>>>>
>>>> I would like to add another RP disk to the environment. After I attach an RP04/05/06 to the system, what should I use as the major/minor device numbers? To put it differently, it doesn't seem correct to me to use 6,1 for the block device or 14,1 for the character device on the new drive as it's a completely different disk from rp0 and rp3 which are just partitions on the first drive and have 6,0, 6,7, and 14,0, 14,7. If each RP can have 8 partitions and there can be 8 drives, what is the correct major, minor numbers to use with v7 for multiple devices?
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs



From hellwig.geisse at mni.thm.de  Sun Dec  6 09:12:37 2015
From: hellwig.geisse at mni.thm.de (Hellwig Geisse)
Date: Sun, 06 Dec 2015 00:12:37 +0100
Subject: [TUHS] Adding an RP06 disk to a running V7 instance
In-Reply-To: <5663663B.5030400@gmail.com>
References: <566344EA.7010401@gmail.com>
 <63EEF957-00FD-4C1A-A290-70A4FDC4DA81@ronnatalie.com>
 <5663663B.5030400@gmail.com>
Message-ID: <1449357157.9737.80.camel@papa2>

On Sa, 2015-12-05 at 16:33 -0600, Will Senn wrote:
> The second was to use tm(0,3) (is this mkfs or something like it?)

If you run 'strings f2', you get:

File 1:
        2 copies of magtape bootstrap (2 blocks total)
        The standalone bootstrap
File 2:
        A file to console copy program
File 3:
        This file
File 4:
        The program mkfs
File 5:
        The program restor
File 6:
        A dump of rp0
File 7:
        A dump of rp3

The numbering starts at 0 of course, so that tm(0,3)
is indeed a standalone mkfs.

Hellwig



From will.senn at gmail.com  Sun Dec  6 09:28:11 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 5 Dec 2015 17:28:11 -0600
Subject: [TUHS] Adding an RP06 disk to a running V7 instance
In-Reply-To: <1449357157.9737.80.camel@papa2>
References: <566344EA.7010401@gmail.com>
 <63EEF957-00FD-4C1A-A290-70A4FDC4DA81@ronnatalie.com>
 <5663663B.5030400@gmail.com> <1449357157.9737.80.camel@papa2>
Message-ID: <5663730B.7050103@gmail.com>

On 12/5/15 5:12 PM, Hellwig Geisse wrote:
> On Sa, 2015-12-05 at 16:33 -0600, Will Senn wrote:
>> The second was to use tm(0,3) (is this mkfs or something like it?)
> If you run 'strings f2', you get:
>
> File 1:
>          2 copies of magtape bootstrap (2 blocks total)
>          The standalone bootstrap
> ...
> The numbering starts at 0 of course, so that tm(0,3)
> is indeed a standalone mkfs.
>
>
This may be obvious to you, but to me it's flat out amazing. Thanks for 
giving me your insight. I never would have thought to use strings on the 
tape segments, but it is so incredibly helpful.

Regards,

Will


From will.senn at gmail.com  Tue Dec  8 07:07:06 2015
From: will.senn at gmail.com (Will Senn)
Date: Mon, 7 Dec 2015 15:07:06 -0600
Subject: [TUHS] Installing and Using Research Unix Version 7 in SimH
 PDP-11/45 Emulator
Message-ID: <5665F4FA.5060709@gmail.com>

All,

In the same vein as my prior note, I have made a note available on the 
process of getting up and running on Unix Seventh Edition in a SimH 
PDP-11 environment. The text is located at:

http://decuser.blogspot.com/2015/12/installing-and-using-research-unix.html

I welcome comments, suggestions, and even criticisms.

While I have learned a lot since my last blog entry (many thanks to 
Hellwig Geisse, Nelson Beebe, Noel Chiappa, Clement Cole and several 
others), I am still learning about these environments. I originally 
invested time in getting v7 running so that I could more easily work 
with v6, after having gone there, I believe that it was time very well 
spent. I know a lot more about special devices, tape formats, and so on 
than I did before as a result of taking the fork in the road.

Thanks for everyone's help.

Oh, and by the way, there appears to be quite a bit of active interest 
in this topic - the blog post has been viewed several thousand times 
since I posted it, two weeks ago.

Kind regards,

Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151207/84979806/attachment.html>

From jacob.ritorto at gmail.com  Wed Dec  9 00:37:57 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Tue, 8 Dec 2015 09:37:57 -0500
Subject: [TUHS] Installing and Using Research Unix Version 7 in SimH
 PDP-11/45 Emulator
In-Reply-To: <5665F4FA.5060709@gmail.com>
References: <5665F4FA.5060709@gmail.com>
Message-ID: <CAHYQbfAo0bzgrSfL1HNnV5oTjBwHTaDKQQ9Ssvnxr_qdB2zaPw@mail.gmail.com>

Nice work, Will.  This reminds me that I'd like to try 2.11BSD on an 11/45
with an Able Enable/34 board.  Wonder how tough it'd be to write emulation
for this board in simh.

On Mon, Dec 7, 2015 at 4:07 PM, Will Senn <will.senn at gmail.com> wrote:

> All,
>
> In the same vein as my prior note, I have made a note available on the
> process of getting up and running on Unix Seventh Edition in a SimH PDP-11
> environment. The text is located at:
>
> http://decuser.blogspot.com/2015/12/installing-and-using-research-unix.html
>
> I welcome comments, suggestions, and even criticisms.
>
> While I have learned a lot since my last blog entry (many thanks to
> Hellwig Geisse, Nelson Beebe, Noel Chiappa, Clement Cole and several
> others), I am still learning about these environments. I originally
> invested time in getting v7 running so that I could more easily work with
> v6, after having gone there, I believe that it was time very well spent. I
> know a lot more about special devices, tape formats, and so on than I did
> before as a result of taking the fork in the road.
>
> Thanks for everyone's help.
>
> Oh, and by the way, there appears to be quite a bit of active interest in
> this topic - the blog post has been viewed several thousand times since I
> posted it, two weeks ago.
>
> Kind regards,
>
> Will
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151208/a7a6fcd8/attachment.html>

From dave at horsfall.org  Wed Dec  9 03:34:47 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 9 Dec 2015 04:34:47 +1100 (EST)
Subject: [TUHS] Happy birthday, Grace Hopper!
Message-ID: <alpine.BSF.2.11.1512090429090.27895@aneurin.horsfall.org>

OK, slightly OT...

Rear Admiral Grace ("Amazing") Hopper PhD was given unto us in 1906.  She 
was famous for coining the term "debugging", whereby a moth was removed 
from a relay contact in a *real* computer[*].

However, she must be condemned for giving us COBOL; yes, I know that vile 
language, but I carefully leave it off my CV, as it seemed to be designed 
for suits (Business Studies of course, but nothing technical) to spy upon 
their programmers.

[*]
Defined, of course, where you could open a door and step inside it; I 
actually did that once.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From doug at cs.dartmouth.edu  Wed Dec  9 04:20:12 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 08 Dec 2015 13:20:12 -0500
Subject: [TUHS] Scan of "Edition 0" manual
Message-ID: <201512081820.tB8IKCLQ144717@tahoe.cs.Dartmouth.EDU>

> It might not be so much a set of macros as just using a
> subset of raw groff.

Yes, there were no macros back then. If you format the
document using raw groff, the odds are that you will be
speaking the same roff that Dennis did.

>  Doug having been there, might know/remember the actually lineage.

Aside from some fuzziness about who wrote what and in what 
language, here's what happened:

To port Jerry Saltzer's Runoff (presumably written in MAD)
to Multics, either Dennis or Bob Morris or both together
reimplemented it (presumably in PL/I). To coexist with
Saltzer's version on CTSS, the new program needed a 
distinct name, hence roff.

The early Multics PL/I compiler was far from a production
tool. Justifiably, the Bell Labs comp center didn't
support it. To get roff into general use at the Labs,
I undertook yet another implementation in BCPL. I added
functionality (number registers, three-part headings, etc)
and kept the new name. Molly Wagner added hyphenation.
Eventually, I added macros that were usable either as
commands or (when parameterless) embedded in text.

Almost as soon as Unix was up on the PDP-11 one of Ken, Dennis
or Ossanna reimplemented a pre-macro version of roff (presumably
in assembler or B). I'm quite sure roff never ran on the PDP-7.

Ossana had a grander plan and undertook nroff. When he learned
of the availability of the Graphic Systems CAT phototypesetter,
he promptly generalized nroff to handle it. Joe replaced the
CAT's paper tape reader with a direct wire to the computer.
It all worked swimmingly--nothing like the travails when the
CAT was replaced by the more capable Merganthaler Linotron.

An interesting question of priority is whether nroff or
BCPL roff was first to have a macro capability. Though
I don't remember for sure, the fact that BCPL roff unified
registers, macros, strings and diversions suggests that
I abstracted from nroff facilities.

Doug


From charles.unix.pro at gmail.com  Wed Dec  9 04:47:57 2015
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Tue, 8 Dec 2015 10:47:57 -0800
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <201512081820.tB8IKCLQ144717@tahoe.cs.Dartmouth.EDU>
References: <201512081820.tB8IKCLQ144717@tahoe.cs.Dartmouth.EDU>
Message-ID: <CANV78LR90kY0z7WiGSP20RwsZNF4zsRRTfD+vCyF_Y-_rhRRmw@mail.gmail.com>

On Tue, Dec 8, 2015 at 10:20 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> > It might not be so much a set of macros as just using a
> > subset of raw groff.
>
> Yes, there were no macros back then. If you format the
> document using raw groff, the odds are that you will be
> speaking the same roff that Dennis did.
>
> >  Doug having been there, might know/remember the actually lineage.
>
> Aside from some fuzziness about who wrote what and in what
> language, here's what happened:
>
> To port Jerry Saltzer's Runoff (presumably written in MAD)
> to Multics, either Dennis or Bob Morris or both together
> reimplemented it (presumably in PL/I). To coexist with
> Saltzer's version on CTSS, the new program needed a
> distinct name, hence roff.
>
> The early Multics PL/I compiler was far from a production
> tool. Justifiably, the Bell Labs comp center didn't
> support it. To get roff into general use at the Labs,
> I undertook yet another implementation in BCPL. I added
> functionality (number registers, three-part headings, etc)
> and kept the new name. Molly Wagner added hyphenation.
> Eventually, I added macros that were usable either as
> commands or (when parameterless) embedded in text.
>
>
>From Multics 12.5:

runoff_mr1.bcpl

//                  Roff for MULTICS
//
//  The first ROFF for Multics was written in March, 1969, by
//  Doug McIlroy of Bell Labs.  Art Evans made extensive
//  modifications to it in May and June, 1969, adding many
//  comments and making various changes.
//  Footnoting added by Dennis Capps in 1970.
//  Maintained by Harwell Thrasher in 1971.
//  Many new features added and bugs fixed by R Mabee in 1971-1972.
//  RUNOFF and BCPL were brought over to the 6180 Multics (from 645) in May
of 1973 by R F Mabee.


The string 'macro" does not appear in the Multics runoff source.




> An interesting question of priority is whether nroff or
> BCPL roff was first to have a macro capability. Though
> I don't remember for sure, the fact that BCPL roff unified
> registers, macros, strings and diversions suggests that
> I abstracted from nroff facilities.
>
> Doug
>

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151208/76f002b6/attachment.html>

From rochkind at basepath.com  Wed Dec  9 04:57:05 2015
From: rochkind at basepath.com (Marc Rochkind)
Date: Tue, 8 Dec 2015 11:57:05 -0700
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <201512081820.tB8IKCLQ144717@tahoe.cs.Dartmouth.EDU>
References: <201512081820.tB8IKCLQ144717@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAOkr1zW5HN9Lroqeu4ymJPzodEXC+0Z+0+Ef7FJ-J4QarHyX9Q@mail.gmail.com>

Nelson--

Well, maybe CP/M and MS-DOS were less powerful, but you're forgetting that
they had the benefit of 10 years or so of additional evolution. ;-)

--Marc

On Tue, Dec 8, 2015 at 11:20 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> > It might not be so much a set of macros as just using a
> > subset of raw groff.
>
> Yes, there were no macros back then. If you format the
> document using raw groff, the odds are that you will be
> speaking the same roff that Dennis did.
>
> >  Doug having been there, might know/remember the actually lineage.
>
> Aside from some fuzziness about who wrote what and in what
> language, here's what happened:
>
> To port Jerry Saltzer's Runoff (presumably written in MAD)
> to Multics, either Dennis or Bob Morris or both together
> reimplemented it (presumably in PL/I). To coexist with
> Saltzer's version on CTSS, the new program needed a
> distinct name, hence roff.
>
> The early Multics PL/I compiler was far from a production
> tool. Justifiably, the Bell Labs comp center didn't
> support it. To get roff into general use at the Labs,
> I undertook yet another implementation in BCPL. I added
> functionality (number registers, three-part headings, etc)
> and kept the new name. Molly Wagner added hyphenation.
> Eventually, I added macros that were usable either as
> commands or (when parameterless) embedded in text.
>
> Almost as soon as Unix was up on the PDP-11 one of Ken, Dennis
> or Ossanna reimplemented a pre-macro version of roff (presumably
> in assembler or B). I'm quite sure roff never ran on the PDP-7.
>
> Ossana had a grander plan and undertook nroff. When he learned
> of the availability of the Graphic Systems CAT phototypesetter,
> he promptly generalized nroff to handle it. Joe replaced the
> CAT's paper tape reader with a direct wire to the computer.
> It all worked swimmingly--nothing like the travails when the
> CAT was replaced by the more capable Merganthaler Linotron.
>
> An interesting question of priority is whether nroff or
> BCPL roff was first to have a macro capability. Though
> I don't remember for sure, the fact that BCPL roff unified
> registers, macros, strings and diversions suggests that
> I abstracted from nroff facilities.
>
> Doug
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151208/b0648abc/attachment.html>

From cowan at mercury.ccil.org  Wed Dec  9 05:06:32 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Tue, 8 Dec 2015 14:06:32 -0500
Subject: [TUHS] Happy birthday, Grace Hopper!
In-Reply-To: <alpine.BSF.2.11.1512090429090.27895@aneurin.horsfall.org>
References: <alpine.BSF.2.11.1512090429090.27895@aneurin.horsfall.org>
Message-ID: <20151208190632.GA8733@mercury.ccil.org>

Dave Horsfall scripsit:

> Rear Admiral Grace ("Amazing") Hopper PhD was given unto us in 1906.  She 
> was famous for coining the term "debugging", whereby a moth was removed 
> from a relay contact in a *real* computer[*].

Well, no.  The moth incident happened in 1947, and the OED lists the word
"debugging" as first appearing in print in 1945 in a British journal.
Hopper may or may not have known that: certainly she was consciously
punning on the existing word "bug", which went right back to Edison's
laboratory and first appeared in print (per the OED) in 1889.

> However, she must be condemned for giving us COBOL; yes, I know that vile 
> language, 

I know it too, and there is nothing blameworthy about it.  We wouldn't get
far nowadays without records, and they first appeared in Cobol (or rather
its direct ancestor Flow-Matic) in 1959, more than a decade before any
other programming language had them.  Longer, if you accept that PL/I
would not have taken the shape it did if Cobol had not existed.  Yes,
Cobol is clunky and archaic; lots of people think Lisp is archaic too.
But it met a need at a particular time, and very successfully so.

The pseudo-readability was meant, at least by Hopper herself, to help
customers rather than managers understand the code.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Big as a house, much bigger than a house, it looked to [Sam], a grey-clad
moving hill.  Fear and wonder, maybe, enlarged him in the hobbit's eyes,
but the Mumak of Harad was indeed a beast of vast bulk, and the like of him
does not walk now in Middle-earth; his kin that live still in latter days are
but memories of his girth and his majesty.  --"Of Herbs and Stewed Rabbit"


From cowan at mercury.ccil.org  Wed Dec  9 05:16:06 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Tue, 8 Dec 2015 14:16:06 -0500
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <201512081820.tB8IKCLQ144717@tahoe.cs.Dartmouth.EDU>
References: <201512081820.tB8IKCLQ144717@tahoe.cs.Dartmouth.EDU>
Message-ID: <20151208191605.GC8733@mercury.ccil.org>

Doug McIlroy scripsit:

> To port Jerry Saltzer's Runoff (presumably written in MAD)

Also the ancestor, by the way, of the various DEC runoff programs; I used
them a bit back in the day on the PDP-8 and -11.  Checking, I now see
that PDP-8 runoff was not a CUSP, but someone else's reimplementation
of RUNOFF-10, probably distributed by DECUS.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
But the next day there came no dawn, and the Grey Company passed on
into the darkness of the Storm of Mordor and were lost to mortal sight;
but the Dead followed them.          --"The Passing of the Grey Company"


From grog at lemis.com  Wed Dec  9 09:09:55 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 9 Dec 2015 10:09:55 +1100
Subject: [TUHS] Happy birthday, Grace Hopper!
In-Reply-To: <alpine.BSF.2.11.1512090429090.27895@aneurin.horsfall.org>
References: <alpine.BSF.2.11.1512090429090.27895@aneurin.horsfall.org>
Message-ID: <20151208230955.GA84775@eureka.lemis.com>

On Wednesday,  9 December 2015 at  4:34:47 +1100, Dave Horsfall wrote:
>
> However, she must be condemned for giving us COBOL; yes, I know that
> vile language, but I carefully leave it off my CV, as it seemed to
> be designed for suits (Business Studies of course, but nothing
> technical) to spy upon their programmers.

And you for giving me bad dreams?  As it happens, round the time you
posted this message, I had a dream of a 180 page printout of a COBOL
program, completely without comments.  The first time COBOL has
haunted me in decades.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/8958fc6d/attachment.sig>

From will.senn at gmail.com  Wed Dec  9 13:33:54 2015
From: will.senn at gmail.com (Will Senn)
Date: Tue, 8 Dec 2015 21:33:54 -0600
Subject: [TUHS] v6tar from v7 on v6, too large?
Message-ID: <5667A122.3040303@gmail.com>

All,

According to "Setting Up Unix - Seventh Edition", by Haley and Ritchie:

The best way to convert file systems from 6th edition (V6) to 7th 
edition (V7) format is to use tar(1). However, a special version of tar 
must be prepared to run on V6.

The document goes on to describe a reasonable method to make v6tar on v7 
and copy the binary over to the v6 system. I successfully built the 
v6tar binary, which will execute in the v7 environment. I then moved it 
over to the v6 system and did a byte compare on the file using od to 
dump the octal bytes and then comparing them to the v7 version. The 
match was perfect.

The problem is this, when I attempt to execute the v6tar binary on the 
v6 system (it works in v7) it errors out:
v6tar
v6tar: too large

on the v7 system, it works:
v6tar
tar: usage  tar -{txru}[cvfblm] [tapefile] [blocksize] file1 file2...

I don't think the binary is too large, is is only 18148 bytes.
ls -l v6tar
-rwxrwxrwx  1 root    18148 Oct 10 14:09 v6tar

Help. First, what does too large mean? Second, does this sound familiar 
to anyone? etc.

Thanks,

Will


From dave at horsfall.org  Wed Dec  9 13:53:45 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 9 Dec 2015 14:53:45 +1100 (EST)
Subject: [TUHS] Happy birthday, Grace Hopper!
In-Reply-To: <71714F0D-2AB9-45D5-8A97-AFCE9E34E323@icloud.com>
References: <alpine.BSF.2.11.1512090429090.27895@aneurin.horsfall.org>
 <71714F0D-2AB9-45D5-8A97-AFCE9E34E323@icloud.com>
Message-ID: <alpine.BSF.2.11.1512090950150.27895@aneurin.horsfall.org>

On Tue, 8 Dec 2015, Brantley Coile wrote:

> We were indeed lucky that admiral hooper was with us. I know people who 
> still cherish their "nano" seconds.

Ah yes, the 1ft piece of wire...  Got a photo of it?

> By the way, she wouldn't have said she coined the term "debugging". That 
> is at least as old as Thomas Edison. She said she was the first to a 
> actually find a real bug!

For those who may be new around here:

https://en.wikipedia.org/wiki/Grace_Hopper#/media/File:H96566k.jpg

Yes, that is a real bug, found inside a real computer.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From jnc at mercury.lcs.mit.edu  Wed Dec  9 14:53:57 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue,  8 Dec 2015 23:53:57 -0500 (EST)
Subject: [TUHS] v6tar from v7 on v6, too large?
Message-ID: <20151209045357.8573718C0C5@mercury.lcs.mit.edu>

    > From: Will Senn <will.senn at gmail.com>

    > The problem is this, when I attempt to execute the v6tar binary on the 
    > v6 system (it works in v7) it errors out:
    > v6tar
    > v6tar: too large

That's an error message from the shell; the exec() call on the command
('v6tar') is returning an ENOMEM error. Looking in the kernel, that comes from
estabur() in main.c; there are a number of potential causes, but the most
likely is that 'v6tar' is linked to be split I+D, and your V6 emulation is on
a machine that doesn't have split I+D (e.g. an 11/40). If that's not it,
please dump the a.out header of 'v6tar', so we can work out what's causing the
ENOMEM.

	Noel


From jnc at mercury.lcs.mit.edu  Wed Dec  9 15:17:20 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  9 Dec 2015 00:17:20 -0500 (EST)
Subject: [TUHS] v6tar from v7 on v6, too large?
Message-ID: <20151209051720.4C6D218C0C5@mercury.lcs.mit.edu>

    > From: Noel Chiappa

    > the most likely is that 'v6tar' is linked to be split I+D, and your V6
    > emulation is on a machine that doesn't have split I+D (e.g. an 11/40)

Now that I think about it, the linked systems that are part of the V6 distro
tape are all linked to run on an 11/40. They will boot and run OK on a more
powerful machine (/45 or /70), but they will act like they are on a /40 -
i.e. no split I+D support/use (user or kernel). So to get split I+D support,
you need to build a new Unix binary, with m45.s instead of m40.s. If you
haven't done that, that's probably what the problem is.


Aside: V6 comes in two flavours: no split I+D at all, or split I+D in both
the kernel and user. For some reason that I can't recall, we actually
produced an 'm43.s', BITD at MIT, which ran the kernel in non-split-I-D, but
supported split I-D for the users.

I wish I could remember why we did this - it couldn't have been to save
memory (the machine didn't have a great deal on it when this was done -
although I have this vague memory that that was why we did it), because
running split I+D in the kernel does not, I think, use any more physical
memory (provided you don't fiddle with the parameters like the number of
buffers) than running non-split. Or maybe it does?

One possible reason was that the odd layout of memory with split I+D in the
kernel made debugging kernel code harder (we were doing a lot of kernel
hacking to support early networking work); another was that we were just being
conservative, didn't need to extra space in the kernel that I+D allowed, and
so didn't want to run it.

	Noel


From cubexyz at gmail.com  Wed Dec  9 15:55:22 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Wed, 9 Dec 2015 00:55:22 -0500
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151209051720.4C6D218C0C5@mercury.lcs.mit.edu>
References: <20151209051720.4C6D218C0C5@mercury.lcs.mit.edu>
Message-ID: <CADxT5N7=yrhOMK=S9wRZKLB_nx1eZOsMM1gBTFJKGYF8grXFvQ@mail.gmail.com>

Ok, I can make a few remarks about v6tar and ar and dd.

I've never been able to transfer any file larger than 64K to Unix V5 or V6.
Smaller than 64K seems to work fine. I'm using the same command on V5 and V6:

dd if=/dev/mt0 of=cont.a bs=1 count=90212

And I'll get:

24676+0 records in
24676+0 records out

Now, if we take 90212 and subtract 65536 we get 24676 bytes. So there
definitely seems to be some 64K limit here and I don't think it's just
a v6tar limitation.

I compiled the kernel with m45.s on V6 and mch.s on V5. I also don't
recall seeing any file on V5 or V6 larger than 65536 bytes, but it's
possible I've overlooked one.

My workaround solution was to simply keep tar files and archive files
under 64K but I would be interested to hear of a better solution.

Mark


On 12/9/15, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Noel Chiappa
>
>     > the most likely is that 'v6tar' is linked to be split I+D, and your
> V6
>     > emulation is on a machine that doesn't have split I+D (e.g. an 11/40)
>
> Now that I think about it, the linked systems that are part of the V6
> distro
> tape are all linked to run on an 11/40. They will boot and run OK on a more
> powerful machine (/45 or /70), but they will act like they are on a /40 -
> i.e. no split I+D support/use (user or kernel). So to get split I+D
> support,
> you need to build a new Unix binary, with m45.s instead of m40.s. If you
> haven't done that, that's probably what the problem is.
>
>
> Aside: V6 comes in two flavours: no split I+D at all, or split I+D in both
> the kernel and user. For some reason that I can't recall, we actually
> produced an 'm43.s', BITD at MIT, which ran the kernel in non-split-I-D,
> but
> supported split I-D for the users.
>
> I wish I could remember why we did this - it couldn't have been to save
> memory (the machine didn't have a great deal on it when this was done -
> although I have this vague memory that that was why we did it), because
> running split I+D in the kernel does not, I think, use any more physical
> memory (provided you don't fiddle with the parameters like the number of
> buffers) than running non-split. Or maybe it does?
>
> One possible reason was that the odd layout of memory with split I+D in the
> kernel made debugging kernel code harder (we were doing a lot of kernel
> hacking to support early networking work); another was that we were just
> being
> conservative, didn't need to extra space in the kernel that I+D allowed,
> and
> so didn't want to run it.
>
> 	Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>


From wkt at tuhs.org  Wed Dec  9 18:25:40 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 9 Dec 2015 19:25:40 +1100
Subject: [TUHS] TUHS Mail Server: upcoming change
Message-ID: <20151209082540.GA4670@www.oztivo.net>

All, in the next few days I'm migrating minnie.tuhs.org from one VM to
another, so as to upgrade the OS and clean out the system. I think I've
got the mail subsystem up and running, but as usual there may be bugs.

I'll send out another message when the system is cut over. If things
don't seem to be right, e-mail me at:

	wkt at tuhs.org, or
	warren.toomey at tafe.qld.edu.au    if the tuhs.org one fails.

Cheers all, Warren


From ron at ronnatalie.com  Wed Dec  9 21:31:39 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Wed, 9 Dec 2015 06:31:39 -0500
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151209051720.4C6D218C0C5@mercury.lcs.mit.edu>
References: <20151209051720.4C6D218C0C5@mercury.lcs.mit.edu>
Message-ID: <D2CF2258-4B5B-42B9-A1D4-5E82737E61AC@ronnatalie.com>

> 
> Aside: V6 comes in two flavours: no split I+D at all, or split I+D in both
> the kernel and user. For some reason that I can't recall, we actually
> produced an 'm43.s', BITD at MIT, which ran the kernel in non-split-I-D, but
> supported split I-D for the users.

I’m pretty sure the V6 kernel didn’t run in split I/D.   It supported three user a.out formats:   407 (mixed I&D in one instructions space),
410 (mixed I&D but with the instructions in write protected segments), and 411 (split I&D).

It wasn’t too involved of a change to make a split I/D kernel.    Mike Muuss and his crew at JHU did it.   We spent more time getting the bootstrap to work than anything else I recall.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/e4f44d30/attachment.bin>

From jnc at mercury.lcs.mit.edu  Wed Dec  9 23:30:27 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  9 Dec 2015 08:30:27 -0500 (EST)
Subject: [TUHS] v6tar from v7 on v6, too large?
Message-ID: <20151209133027.DCD0D18C0C7@mercury.lcs.mit.edu>

    > From: Ronald Natalie

    > I'm pretty sure the V6 kernel didn't run in split I/D.

Nope. From 'SETTING UP UNIX - Sixth Edition':

  "Another difference is that in 11/45 and 11/70 systems the instruction and
  data spaces are separated inside UNIX itself."

And if you don't believe that, check out:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s

the source! ;-)


    > It wasn't too involved of a change to make a split I/D kernel.
    > Mike Muuss and his crew at JHU did it.

Maybe you're remembering the process on a pre-V6 system?

    > We spent more time getting the bootstrap to work than anything else I
    > recall.

It's possible you're remembering that, as distributed, V6 didn't support load
images where the text+initialized-data was larger than 24KW-delta; it would
have been pretty eaay to up that to 28KW-delta (change a parameter in the
bootstrap source, and re-assemble), but after that, the V6 bootstrap would
have had to have been extensively re-worked.

And there were _also_ a variety of issues with handling maximal large images
in the startup code. Once operating, the kernel has segments KI1-KI7 available
the hold the system's code; however, it's not clear that all of KI1-7 are
really usable, since the system can't 'see' enough code while in the code
relocation phase in the startup to fill them all. E.g. during code relocation,
KI7 is ripped off to hold a pointer to I/O space (since KD7 is set to point to
low memory just after the memory that KD6 points to).

These might have been issues in systems which were ARPANET-connected (i.e.
ran NCP), as that added a very large amount of code to the kernel.

	Noel


From jnc at mercury.lcs.mit.edu  Thu Dec 10 00:24:13 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  9 Dec 2015 09:24:13 -0500 (EST)
Subject: [TUHS] v6tar from v7 on v6, too large?
Message-ID: <20151209142413.3CA2918C0C7@mercury.lcs.mit.edu>

    > From: Mark Longridge

    > I've never been able to transfer any file larger than 64K to Unix V5 or
    > V6.

Huh?

  # hrd /windows/desktop/TheMachineStops.htm Mach.htm
  Xfer complete: 155+38
  # l Mach.htm
   154 -rw-rw-r--  1 root    78251 Oct 25 12:13 Mach.htm
  #

'more' shows that the contents are all there, and fine. ('hrd' is a command
in my V6 under Ersatz11 that reads an arbitrary file off the host file
system. Guess I need to set the date on the system!)

V6 definitely supports fairly large files; see the code in bmap() in subr.c,
which shows that the basic structure on disk can describe files of 7*256
(1792) + 256*256 (65536) blocks, or 67328 blocks total (34MB).

(In reality, of course, a file can't reach that limit; first, a disk
partition in V6 is limited to 64K blocks, but from that one has to deduct
blocks for the ilist, etc; further, the argument to bmap() is an int, which
limits the 'block number in file' to 16 bits, and in fact the code returns an
error if the high bit in the 'block number in file' is set.)


    > I also don't recall seeing any file on V5 or V6 larger than 65536
    > bytes

I don't think there is one; the largest are just less than 64KB. I don't
think this is deliberate, other than in the sense that they didn't put any
huge files in the distro so it would fit on a couple of RK packs.


    > dd if=/dev/mt0 of=cont.a bs=1 count=90212
    > ..
    > 24676+0 records in
    > 24676+0 records out
    > Now, if we take 90212 and subtract 65536 we get 24676 bytes. So there
    > definitely seems to be some 64K limit here

Probably 'count' is an 'int' in dd, i.e. limited to 16 bits. No longs in V6 C
(as distributed, although later versions of the C compiler for V6 do support
longs - see my 'bringing up Unix' pages).

	Noel


From will.senn at gmail.com  Thu Dec 10 00:38:23 2015
From: will.senn at gmail.com (Will Senn)
Date: Wed, 9 Dec 2015 08:38:23 -0600
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151209045357.8573718C0C5@mercury.lcs.mit.edu>
References: <20151209045357.8573718C0C5@mercury.lcs.mit.edu>
Message-ID: <56683CDF.10609@gmail.com>

On 12/8/15 10:53 PM, Noel Chiappa wrote:
>      > From: Will Senn <will.senn at gmail.com>
>
>      > The problem is this, when I attempt to execute the v6tar binary on the
>      > v6 system (it works in v7) it errors out:
>      > v6tar
>      > v6tar: too large
>
> That's an error message from the shell; the exec() call on the command
> ('v6tar') is returning an ENOMEM error. Looking in the kernel, that comes from
> estabur() in main.c; there are a number of potential causes, but the most
> likely is that 'v6tar' is linked to be split I+D, and your V6 emulation is on
> a machine that doesn't have split I+D (e.g. an 11/40). If that's not it,
> please dump the a.out header of 'v6tar', so we can work out what's causing the
> ENOMEM.
>
> 	Noel
That was it. Thanks for supplying the logic trail you followed as well! 
I "upgraded" to a 11/70 w/2M of RAM and FPP by passing the appropriate 
SimH commands and then I folllowed the instructions in Setting up Unix 
Sixth Edition to use the m45.s assist and voila, v6tar works. Thank you.

Now, when you say dump the a.out header, how do you do that?

Thanks,

Will


From ron at ronnatalie.com  Thu Dec 10 00:43:21 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Wed, 9 Dec 2015 09:43:21 -0500
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151209133027.DCD0D18C0C7@mercury.lcs.mit.edu>
References: <20151209133027.DCD0D18C0C7@mercury.lcs.mit.edu>
Message-ID: <16B69FCC-56D2-4902-BCA2-B9A4F286960C@ronnatalie.com>

I now see our disconnect Noel.   Yes the V6 kernel runs in split I and D mode, but it doesn’t end up supporting any more data.   I.e. the kernel is still a 407 (or 410) file.   _etext/_edata/_end are still referencing the same 64K space.   What we did (among others) was to allow the system to boot up from a split I/D image that could be a full 65K of text and a substantial additional amount of initialized data (and bss).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/c6c9f5bf/attachment.bin>

From jnc at mercury.lcs.mit.edu  Thu Dec 10 00:56:47 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  9 Dec 2015 09:56:47 -0500 (EST)
Subject: [TUHS] v6tar from v7 on v6, too large?
Message-ID: <20151209145647.C388C18C0C7@mercury.lcs.mit.edu>

    > From: Will Senn

    > Thanks for supplying the logic trail you followed as well!

"Use the source, Luke!" This is particularly true on V6, where it's assumed
that recourse to the source (which is always at hand - long before RMS and
'Free Software', mind) will be an early step.

    > when you say dump the a.out header, how do you do that?

On vanilla V6? Hmm. On a system with 'more' (hint, hint ;-), I'd just do 'od
{file} | more', and stop it after the first page. Without 'more', I'd probably
send the 'od' output to a file, and use 'ed' to look at the first couple of
lines.

Back in the day, of course, on a (slow) printing terminal, one could have just
said 'od', and aborted it after the first couple of lines. These days, with
video terminals, 'more' is kind of really necessary. Grab the one off my V6
Unix site, it's V6-ready (should be a compile-and-go).

	Noel


From clemc at ccc.com  Thu Dec 10 00:56:19 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 9 Dec 2015 09:56:19 -0500
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <56683CDF.10609@gmail.com>
References: <20151209045357.8573718C0C5@mercury.lcs.mit.edu>
 <56683CDF.10609@gmail.com>
Message-ID: <CAC20D2PdNDRQ17whxxd5GEqaiG6px-NM58Q6xe4g7khzMsx+dw@mail.gmail.com>

dd if=v6tar bs=128 count=1 | od

check the man page on the a.out format.

BTW:  I would relink v6tar to be a "407" header so it will run anywhere.
That said, there are a number of copies of v6tar "in the wild" - my memory
is that it's on a late 1970's, very early 1980s USENIX tape.



On Wed, Dec 9, 2015 at 9:38 AM, Will Senn <will.senn at gmail.com> wrote:

> On 12/8/15 10:53 PM, Noel Chiappa wrote:
>
>>      > From: Will Senn <will.senn at gmail.com>
>>
>>      > The problem is this, when I attempt to execute the v6tar binary on
>> the
>>      > v6 system (it works in v7) it errors out:
>>      > v6tar
>>      > v6tar: too large
>>
>> That's an error message from the shell; the exec() call on the command
>> ('v6tar') is returning an ENOMEM error. Looking in the kernel, that comes
>> from
>> estabur() in main.c; there are a number of potential causes, but the most
>> likely is that 'v6tar' is linked to be split I+D, and your V6 emulation
>> is on
>> a machine that doesn't have split I+D (e.g. an 11/40). If that's not it,
>> please dump the a.out header of 'v6tar', so we can work out what's
>> causing the
>> ENOMEM.
>>
>>         Noel
>>
> That was it. Thanks for supplying the logic trail you followed as well! I
> "upgraded" to a 11/70 w/2M of RAM and FPP by passing the appropriate SimH
> commands and then I folllowed the instructions in Setting up Unix Sixth
> Edition to use the m45.s assist and voila, v6tar works. Thank you.
>
> Now, when you say dump the a.out header, how do you do that?
>
> Thanks,
>
> Will
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/3ea32ab9/attachment.html>

From hellwig.geisse at mni.thm.de  Thu Dec 10 00:59:53 2015
From: hellwig.geisse at mni.thm.de (Hellwig Geisse)
Date: Wed, 09 Dec 2015 15:59:53 +0100
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <56683CDF.10609@gmail.com>
References: <20151209045357.8573718C0C5@mercury.lcs.mit.edu>
 <56683CDF.10609@gmail.com>
Message-ID: <1449673193.12912.49.camel@papa2>

On Mi, 2015-12-09 at 08:38 -0600, Will Senn wrote:
> Now, when you say dump the a.out header, how do you do that?

Apply OD(1) to the executable. You can then inspect the
exec header, especially the magic number, in order to
investigate the startup of the program.

Hellwig



From clemc at ccc.com  Thu Dec 10 01:07:26 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 9 Dec 2015 10:07:26 -0500
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <CAC20D2PdNDRQ17whxxd5GEqaiG6px-NM58Q6xe4g7khzMsx+dw@mail.gmail.com>
References: <20151209045357.8573718C0C5@mercury.lcs.mit.edu>
 <56683CDF.10609@gmail.com>
 <CAC20D2PdNDRQ17whxxd5GEqaiG6px-NM58Q6xe4g7khzMsx+dw@mail.gmail.com>
Message-ID: <CAC20D2NVH_O6myB0NeYehenazHMFTHY5A+PAqngRpLMjBA4dVA@mail.gmail.com>

On Wed, Dec 9, 2015 at 9:56 AM, Clem Cole <clemc at ccc.com> wrote:

> check the man page on the a.out format.


​Note to folks on the list - please don't give away the answer...

Will

A small piece of homework for the student -- look at 407 the magic number
for the a.out file ​and see if you can explain why Ken picked that value.
Hint it is particular to the PDP-11 architecture and is not portable to
other systems, although most other systems that UNIX was "ported" too
continued to used the a.out format kept the magic numbers as 407/411 etc.,
although I know of some ports (like mine own for Magix - the Tek Magnolia
system of the late 1970s) that changed the magic number to be correct for
that architecture.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/f98239b5/attachment.html>

From will.senn at gmail.com  Thu Dec 10 02:29:22 2015
From: will.senn at gmail.com (Will Senn)
Date: Wed, 9 Dec 2015 10:29:22 -0600
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <CAC20D2NVH_O6myB0NeYehenazHMFTHY5A+PAqngRpLMjBA4dVA@mail.gmail.com>
References: <20151209045357.8573718C0C5@mercury.lcs.mit.edu>
 <56683CDF.10609@gmail.com>
 <CAC20D2PdNDRQ17whxxd5GEqaiG6px-NM58Q6xe4g7khzMsx+dw@mail.gmail.com>
 <CAC20D2NVH_O6myB0NeYehenazHMFTHY5A+PAqngRpLMjBA4dVA@mail.gmail.com>
Message-ID: <566856E2.7010009@gmail.com>

On 12/9/15 9:07 AM, Clem Cole wrote:
>
> On Wed, Dec 9, 2015 at 9:56 AM, Clem Cole <clemc at ccc.com 
> <mailto:clemc at ccc.com>> wrote:
>
>     check the man page on the a.out format.
>
>
> ​Note to folks on the list - please don't give away the answer...
>
> Will
>
> A small piece of homework for the student -- look at 407 the magic 
> number for the a.out file ​and see if you can explain why Ken picked 
> that value.  Hint it is particular to the PDP-11 architecture and is 
> not portable to other systems, although most other systems that UNIX 
> was "ported" too continued to used the a.out format kept the magic 
> numbers as 407/411 etc., although I know of some ports (like mine own 
> for Magix - the Tek Magnolia system of the late 1970s) that changed 
> the magic number to be correct for that architecture.
>
> Clem
>
Clem,

Nice!

In full disclosure, I read about magic numbers being PDP architecture 
related somewhere in the recent past, but I didn't really understand the 
connection. So, when you mentioned it, rather than google it and spoil 
the fun, I took the hint and thought a bit about it in the context of 
our discussion. As it turns out, according to my now handy-dandy 
PDP11/40 processor handbook, the 18 bits holding the word 000407 which 
appears as the first word of most of my v6 binaries, 000 000 100 000 
111b, the magic number represents the BR instruction base where the last 
8 bits is an offset added to the PC after it has read the word. So, the 
PDP loads the object, reads the first word, determines it is a branch 
instruction:

BR PC+7

and jumps forward to start reading the 9th word of the program. Why the 
9th word? According to man 5 a.out, the a.out header always contains 8 
words.

So, given a binary, like write:
dd if=write bs=128 count=1|od
1+0 records in
1+0 records out
0000000 000407 001176 000032 000150 000000 000000 000000 000001
0000020 022627 000002 001412 003006 012700 000001 104404 000657
...

The analysis that follows in light of the information discovered so far 
would be:
word 1 at 0000000 000407 Magic Number (BR PC+7)
word 2 at 0000002 001176 Size of the program text segment (638 bytes)
word 3 at 0000004 000032 Size of the initialized data segment (26 bytes)
word 4 at 0000006 000150 Size of the uninitialized data segment (104 bytes)
word 5 at 0000010 000000 Size of the symbol table (stripped in this case)
word 6 at 0000012 000000 The entry location 0 at present
word 7 at 0000014 000000 Unused
word 8 at 0000016 000001 Relocation bit suppression flag (I think this 
means the file contains absolute memory references)
word 9 at 0000020 022627 The target of the first branch, contains 
instructions to MOV (R6)+,(R7)+ (I think)...

According to man 5 a.out on v7, the different magic numbers represent 
normal, read-only text, separate I&D, and overlay:
     #define A_MAGIC1 0407       /* normal */
     #define A_MAGIC2 0410       /* read-only text */
     #define A_MAGIC3 0411       /* separated I&D */
     #define A_MAGIC4 0405       /* overlay */

This means that branches are to 9th, 10th, 11th and 7th words, 
respectively. It'll be a while before I really understand what the 
ramifications are.

Oh and by the way, jumping between octal and decimal is weird, but 
convenient once you get the hang of it - 512 is 1000, which is nifty and 
makes finding buffer boundaries in an octal dump easy :).

Thanks,

Will

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/10392878/attachment.html>

From will.senn at gmail.com  Thu Dec 10 02:37:46 2015
From: will.senn at gmail.com (Will Senn)
Date: Wed, 9 Dec 2015 10:37:46 -0600
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151209145647.C388C18C0C7@mercury.lcs.mit.edu>
References: <20151209145647.C388C18C0C7@mercury.lcs.mit.edu>
Message-ID: <566858DA.5010505@gmail.com>

On 12/9/15 8:56 AM, Noel Chiappa wrote:
>      > From: Will Senn
>
>      > Thanks for supplying the logic trail you followed as well!
>
> "Use the source, Luke!" This is particularly true on V6, where it's assumed
> that recourse to the source (which is always at hand - long before RMS and
> 'Free Software', mind) will be an early step.
>
>      > when you say dump the a.out header, how do you do that?
>
> On vanilla V6? Hmm. On a system with 'more' (hint, hint ;-), I'd just do 'od
> {file} | more', and stop it after the first page. Without 'more', I'd probably
> send the 'od' output to a file, and use 'ed' to look at the first couple of
> lines.
>
> Back in the day, of course, on a (slow) printing terminal, one could have just
> said 'od', and aborted it after the first couple of lines. These days, with
> video terminals, 'more' is kind of really necessary. Grab the one off my V6
> Unix site, it's V6-ready (should be a compile-and-go).
>
> 	Noel
Noel,

This is great help. I'll get more or less going and see where I wind up.

Thanks,

Will




From jnc at mercury.lcs.mit.edu  Thu Dec 10 03:50:24 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  9 Dec 2015 12:50:24 -0500 (EST)
Subject: [TUHS] v6tar from v7 on v6, too large?
Message-ID: <20151209175024.5180118C0C7@mercury.lcs.mit.edu>

    > From: Will Senn

    > my now handy-dandy PDP11/40 processor handbook

That's good for the instruction set, but for the memory management hardware,
etc you'll really want one of the {/44, /45, /70, /73, etc} group, since only
those models support split I+D.

    > the 18 bits holding the word 000407

You mean '16 bits', right? :-)

    > This means that branches are to 9th, 10th, 11th and 7th words,
    > respectively. It'll be a while before I really understand what the
    > ramifications are.

Only the '407' is functional. (IIRC, in early UNIX versions, the OS didn't
strip the header on loading a new program into memory, so the 407 was actually
executed.)  The others are just magic numbers, inspired by the '407' - the
code always starts at byte 020 in the file.

    > Oh and by the way, jumping between octal and decimal is weird, but
    > convenient once you get the hang of it - 512 is 1000, which is nifty
    > and makes finding buffer boundaries in an octal dump easy :).

The _real_ reason octal is optimal for PDP-11 is that when looking at core,
most instructions are more easily understood in octal, because the PDP-11 has
8 registers (3 bits), and 3 bits worth of mode modifier, and the fields are
aligned to show up in octal.

I.e. in the double-op instruction '0awxyz', the 'a' octit gives the opcode,
'w' is the mode for the first operand, 'x' is the register for the first
operand, and 'y' and 'z' similarly for the second operand. So '12700' is
'MOV (PC)+, R0' - AKA 'MOV #bbb, R0', where 'bbb' is the contents of the word
after the '12700'.

	Noel


From will.senn at gmail.com  Thu Dec 10 03:55:06 2015
From: will.senn at gmail.com (Will Senn)
Date: Wed, 9 Dec 2015 11:55:06 -0600
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151209045357.8573718C0C5@mercury.lcs.mit.edu>
References: <20151209045357.8573718C0C5@mercury.lcs.mit.edu>
Message-ID: <56686AFA.1080205@gmail.com>



On 12/8/15 10:53 PM, Noel Chiappa wrote:
>      > From: Will Senn <will.senn at gmail.com>
>
>      > The problem is this, when I attempt to execute the v6tar binary on the
>      > v6 system (it works in v7) it errors out:
>      > v6tar
>      > v6tar: too large
>
> That's an error message from the shell; the exec() call on the command
> ('v6tar') is returning an ENOMEM error. Looking in the kernel, that comes from
> estabur() in main.c; there are a number of potential causes, but the most
> likely is that 'v6tar' is linked to be split I+D, and your V6 emulation is on
> a machine that doesn't have split I+D (e.g. an 11/40). If that's not it,
> please dump the a.out header of 'v6tar', so we can work out what's causing the
> ENOMEM.
>
> 	Noel
Noel,

I followed the thread you provided and I appreciate the direction. 
estabur(who thought these names up, I know 8 characters is limiting, but 
c'mon) is indeed the culprit:
         if(sep) {
                 if(cputype == 40)
                         goto err;

I'm gathering (read still investigating) that the 411 header is read by 
a loader and the call to estabur is made with a value for sep indicating 
that it is a split I+D binary, then the cputype is checked and sure 
enough, it's a PDP-11/40 and the error is generated.

Thanks,

Will


From will.senn at gmail.com  Thu Dec 10 04:06:04 2015
From: will.senn at gmail.com (Will Senn)
Date: Wed, 9 Dec 2015 12:06:04 -0600
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151209175024.5180118C0C7@mercury.lcs.mit.edu>
References: <20151209175024.5180118C0C7@mercury.lcs.mit.edu>
Message-ID: <56686D8C.30705@gmail.com>

Noel,

Comments below:

On 12/9/15 11:50 AM, Noel Chiappa wrote:
>      > From: Will Senn
>
>      > my now handy-dandy PDP11/40 processor handbook
>
> That's good for the instruction set, but for the memory management hardware,
> etc you'll really want one of the {/44, /45, /70, /73, etc} group, since only
> those models support split I+D.
I have the pdf for the /70, but I just ordered a new paper copy on 
Amazon, call me old fashioned :).
>
>      > the 18 bits holding the word 000407
>
> You mean '16 bits', right? :-)
Yes you are correct, 5 octal digits, only 16 bits used for instructions.

>      > This means that branches are to 9th, 10th, 11th and 7th words,
>      > respectively. It'll be a while before I really understand what the
>      > ramifications are.
>
> Only the '407' is functional. (IIRC, in early UNIX versions, the OS didn't
> strip the header on loading a new program into memory, so the 407 was actually
> executed.)  The others are just magic numbers, inspired by the '407' - the
> code always starts at byte 020 in the file.
OK. This is up as my next investigation and it will be guided by 
Lions'... figuring out exactly how programs get loaded in v6 and 
secondarily v7.

Thanks,

Will


From dave at horsfall.org  Thu Dec 10 06:41:37 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 10 Dec 2015 07:41:37 +1100 (EST)
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151209133027.DCD0D18C0C7@mercury.lcs.mit.edu>
References: <20151209133027.DCD0D18C0C7@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.11.1512100731030.41965@aneurin.horsfall.org>

On Wed, 9 Dec 2015, Noel Chiappa wrote:

> Nope. From 'SETTING UP UNIX - Sixth Edition':
> 
>   "Another difference is that in 11/45 and 11/70 systems the instruction and
>   data spaces are separated inside UNIX itself."
> 
> And if you don't believe that, check out:
> 
>   http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s

Blimey, but that takes my 60yo+ brain cells back a bit...  I love those
PDP-11 instructions, such as "blos" and "sob" :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From dave at horsfall.org  Thu Dec 10 07:42:22 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 10 Dec 2015 08:42:22 +1100 (EST)
Subject: [TUHS] Of Ossanna and Lovelace
Message-ID: <alpine.BSF.2.11.1512100839260.41965@aneurin.horsfall.org>

J.F. Ossanna (jfo) was born in 1928; he helped give us Unix, and developed 
the ROFF series (which I still use).

And Ada Lovelace, the world's first computer programmer, was coded in 1815.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From jnc at mercury.lcs.mit.edu  Thu Dec 10 08:01:26 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  9 Dec 2015 17:01:26 -0500 (EST)
Subject: [TUHS] v6tar from v7 on v6, too large?
Message-ID: <20151209220126.7FF7818C0C9@mercury.lcs.mit.edu>

    > Yes the V6 kernel runs in split I and D mode, but it doesn't end up
    > supporting any more data.  I.e. the kernel is still a 407 (or 410) file.
    > _etext/_edata/_end are still referencing the same 64K space.

Err, actually, not really.

The thing is that to build the split-I/D kernel, one sets the linker to
produce an output file which still contains the relocation bits. That is then
post-processed by 'sysfix', which does wierd magic (moves the text up to
020000, in terms of address space; and puts the data _below_ the text, in the
actual output file). So while the files concerned may have a '407' in their
header, they definitely aren't what one normally finds in a linked 407 or 410
file.

In particular, data addresses start at 0, and can run up to 0140000 (i.e. up
to 56KB), while text addreses start at 020000 and can run up to 0160000. So,
_etext/_edata/_end are not, in fact, in the same 64K space. And the total of
data (initialized and un-initialized) together with the text can be much
larger than 64KB - up to 112KB (modor so.

	Noel


From jnc at mercury.lcs.mit.edu  Thu Dec 10 08:16:24 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  9 Dec 2015 17:16:24 -0500 (EST)
Subject: [TUHS] v6tar from v7 on v6, too large?
Message-ID: <20151209221624.B27CC18C0C9@mercury.lcs.mit.edu>

    > estabur (who thought these names up, I know 8 characters is limiting,
    > but c'mon)

'establish user mode registers'

    > the 411 header is read by a loader

Actually, it's read by the exec() system call (in sys1.c).

	Noel


From clemc at ccc.com  Thu Dec 10 08:31:00 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 9 Dec 2015 17:31:00 -0500
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151209221624.B27CC18C0C9@mercury.lcs.mit.edu>
References: <20151209221624.B27CC18C0C9@mercury.lcs.mit.edu>
Message-ID: <CAC20D2NcjcA_7NmnuEU-97BrWW3EeDOi51nHzfFr0YZFkG5jPQ@mail.gmail.com>

On Wed, Dec 9, 2015 at 5:16 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>
>
> Actually, it's read by the exec() system call (in sys1.c).
>
>
​To be fair UNIX was the naming sinner here IMO.  Unix's ld command is the
"link editor", and exec(2) is the "program loader" in the pure OS/academic
naming sense.  I never asked Dennis or Ken why those names were not used.
I suspect like creat(2) it made sense at the time and then by the time the
functions leveled out, it was embedded too deep the change it.

​BTW:  the DEC (vms) link editor runs on Ultrix (PDP-11 and Vaxen).  The
binarie​s are part of the Fortran kit.  I'm not sure if it will run on V7
but it might work on BSD 2.x.  It's author sits a few feet from me these
days.   When DEC finally went to support DEC standard Fortran on UNIX it
was just easier to make the VMS link know how to output an a.out (and macho
files) and the end, then it was to try to add the features they needed for
Fortran to ld and a.out.

It's interesting hearing from Paul his issues over the years between, Unix,
NT, Apple etc., a.out, COFF, and other formats.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/559b62b8/attachment.html>

From cowan at mercury.ccil.org  Thu Dec 10 08:47:51 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Wed, 9 Dec 2015 17:47:51 -0500
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <CAC20D2NcjcA_7NmnuEU-97BrWW3EeDOi51nHzfFr0YZFkG5jPQ@mail.gmail.com>
References: <20151209221624.B27CC18C0C9@mercury.lcs.mit.edu>
 <CAC20D2NcjcA_7NmnuEU-97BrWW3EeDOi51nHzfFr0YZFkG5jPQ@mail.gmail.com>
Message-ID: <20151209224751.GC20697@mercury.ccil.org>

Clem Cole scripsit:

> ​To be fair UNIX was the naming sinner here IMO.  Unix's ld command is the
> "link editor", 

I thought "ld" stood for Link eDitor.  :-)

> I never asked Dennis or Ken why those names were not used.

FWIW, DEC transitioned from "loader" to "link editor".  On OS/8 there
were four linkers, one for each compiler:  ABSLDR, LOAD, LOADER,
and LINK.  LINK was for the macro assembler, the last one published.
I don't remember the story on the various PDP-11 DEC OSes; by VMS days
it was exclusively LINK.  The ABSLDR actually did loading rather than
linking (it was "absolute" in the sense that it did no relocation, so
if parts of your program overwrote other parts, that was your problem).
When it terminated, the executable program was in core (the ABSLDR's
last act was to arrange for the executable to overwrite it) where you
could save it or start it up as you were so minded.

-- 
"Well, I'm back."  --Sam        John Cowan <cowan at ccil.org>


From usotsuki at buric.co  Thu Dec 10 09:39:06 2015
From: usotsuki at buric.co (Steve Nickolas)
Date: Thu, 10 Dec 2015 00:39:06 +0100 (CET)
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151209224751.GC20697@mercury.ccil.org>
References: <20151209221624.B27CC18C0C9@mercury.lcs.mit.edu>
 <CAC20D2NcjcA_7NmnuEU-97BrWW3EeDOi51nHzfFr0YZFkG5jPQ@mail.gmail.com>
 <20151209224751.GC20697@mercury.ccil.org>
Message-ID: <alpine.BSF.2.02.1512100037320.52915@frieza.hoshinet.org>

On Wed, 9 Dec 2015, John Cowan wrote:

> Clem Cole scripsit:
>
>> ​To be fair UNIX was the naming sinner here IMO.  Unix's ld command is the
>> "link editor", 
>
> I thought "ld" stood for Link eDitor.  :-)

I thought it stood for "load", as that nomenclature is used on other OSes 
(I think CP/M maybe?)

>> I never asked Dennis or Ken why those names were not used.
>
> FWIW, DEC transitioned from "loader" to "link editor".  On OS/8 there
> were four linkers, one for each compiler:  ABSLDR, LOAD, LOADER,
> and LINK.  LINK was for the macro assembler, the last one published.

...so yeah. CP/M got a lot of its terminology from DEC.

> I don't remember the story on the various PDP-11 DEC OSes; by VMS days
> it was exclusively LINK.  The ABSLDR actually did loading rather than
> linking (it was "absolute" in the sense that it did no relocation, so
> if parts of your program overwrote other parts, that was your problem).
> When it terminated, the executable program was in core (the ABSLDR's
> last act was to arrange for the executable to overwrite it) where you
> could save it or start it up as you were so minded.

-uso.

From clemc at ccc.com  Thu Dec 10 10:23:07 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 9 Dec 2015 19:23:07 -0500
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151209224751.GC20697@mercury.ccil.org>
References: <20151209221624.B27CC18C0C9@mercury.lcs.mit.edu>
 <CAC20D2NcjcA_7NmnuEU-97BrWW3EeDOi51nHzfFr0YZFkG5jPQ@mail.gmail.com>
 <20151209224751.GC20697@mercury.ccil.org>
Message-ID: <CAC20D2OEOowXDZ3t8WWwPe72bmUkzBjc13Ctk1sMj4kjnAEC_Q@mail.gmail.com>

On Wed, Dec 9, 2015 at 5:47 PM, John Cowan <cowan at mercury.ccil.org> wrote:

> I thought "ld" stood for Link eDitor.  :-)
>
​I have never heard that justification.   It's always been talked about as
the "loader" communications I had with different folks including Dennis.
In the early/mid '70s the person that introduced me to Unix (tjk) always
called it the loader.​   Ted was (like many of us in those days) coming
from either IBM's TSS or MTS, and influenced by IBM's terminology as well
as DECs.



> On OS/8 there
> ​ ​
> were four linkers, one for each compiler:  ABSLDR, LOAD, LOADER,
> and LINK.  LINK was for the macro assembler, the last one published.
>
​I used TSS/8 and I've forgotten what is was called there, never used
OS/8.  In TOPS and Tenex land it was called a linker, as it was on TSS and
MTS.




> I don't remember the story on the various PDP-11 DEC OSes;
>
​RT-11, DOS-11 and RSX all called it a linker.​




> by VMS days
> ​ ​
> it was exclusively LINK.
>
​As the author of VMS's link and later versions, I'll try to ask Paul
tomorrow what he knows/remembers.  In my presence, he has b*tched about
Unix calling it a 'loader.​

​'

Clem

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/0fcdd1f3/attachment.html>

From clemc at ccc.com  Thu Dec 10 10:24:24 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 9 Dec 2015 19:24:24 -0500
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <alpine.BSF.2.02.1512100037320.52915@frieza.hoshinet.org>
References: <20151209221624.B27CC18C0C9@mercury.lcs.mit.edu>
 <CAC20D2NcjcA_7NmnuEU-97BrWW3EeDOi51nHzfFr0YZFkG5jPQ@mail.gmail.com>
 <20151209224751.GC20697@mercury.ccil.org>
 <alpine.BSF.2.02.1512100037320.52915@frieza.hoshinet.org>
Message-ID: <CAC20D2PpqeDHo9aXtZ4hAgrERMG57qr2bX1Y0pLypcPqdx_dmA@mail.gmail.com>

On Wed, Dec 9, 2015 at 6:39 PM, Steve Nickolas <usotsuki at buric.co> wrote:

> ...so yeah. CP/M got a lot of its terminology from DEC.


​More specifically, RT-11 which is what it was emulating.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151209/879c4307/attachment.html>

From wkt at tuhs.org  Thu Dec 10 11:25:45 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 10 Dec 2015 11:25:45 +1000
Subject: [TUHS] New TUHS server is up
Message-ID: <20151210012545.GA27768@minnie.tuhs.org>

OK, the new server for minnie is up: 45.79.103.53. Fingers crossed I've got
the mail system working :-)

Cheers, Warren


From wkt at tuhs.org  Thu Dec 10 11:41:11 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 10 Dec 2015 11:41:11 +1000
Subject: [TUHS] Server is changed
Message-ID: <20151210014111.GA28608@minnie.tuhs.org>

All, the server for minnie is changed to 45.79.103.53. Hopefully the
mailing list software is working.

Cheers, Warren


From cowan at mercury.ccil.org  Thu Dec 10 11:19:09 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Wed, 9 Dec 2015 20:19:09 -0500
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <CAC20D2OEOowXDZ3t8WWwPe72bmUkzBjc13Ctk1sMj4kjnAEC_Q@mail.gmail.com>
References: <20151209221624.B27CC18C0C9@mercury.lcs.mit.edu>
 <CAC20D2NcjcA_7NmnuEU-97BrWW3EeDOi51nHzfFr0YZFkG5jPQ@mail.gmail.com>
 <20151209224751.GC20697@mercury.ccil.org>
 <CAC20D2OEOowXDZ3t8WWwPe72bmUkzBjc13Ctk1sMj4kjnAEC_Q@mail.gmail.com>
Message-ID: <20151210011909.GA20023@mercury.ccil.org>

Clem Cole scripsit:

> > I thought "ld" stood for Link eDitor.  :-)
> >
> ​I have never heard that justification.   

That's because I made it up this very day, hence the smiley.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Overhead, without any fuss, the stars were going out.
        --Arthur C. Clarke, "The Nine Billion Names of God"


From grog at lemis.com  Thu Dec 10 11:08:18 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 10 Dec 2015 12:08:18 +1100
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <CAC20D2OEOowXDZ3t8WWwPe72bmUkzBjc13Ctk1sMj4kjnAEC_Q@mail.gmail.com>
References: <20151209221624.B27CC18C0C9@mercury.lcs.mit.edu>
 <CAC20D2NcjcA_7NmnuEU-97BrWW3EeDOi51nHzfFr0YZFkG5jPQ@mail.gmail.com>
 <20151209224751.GC20697@mercury.ccil.org>
 <CAC20D2OEOowXDZ3t8WWwPe72bmUkzBjc13Ctk1sMj4kjnAEC_Q@mail.gmail.com>
Message-ID: <20151210010818.GE84775@eureka.lemis.com>

On Wednesday,  9 December 2015 at 19:23:07 -0500, Clem Cole wrote:
> On Wed, Dec 9, 2015 at 5:47 PM, John Cowan <cowan at mercury.ccil.org> wrote:
>
>> I thought "ld" stood for Link eDitor.  :-)
>>
> ???I have never heard that justification.   It's always been talked about as
> the "loader" communications I had with different folks including Dennis.
> In the early/mid '70s the person that introduced me to Unix (tjk) always
> called it the loader.???   Ted was (like many of us in those days) coming
> from either IBM's TSS or MTS, and influenced by IBM's terminology as well
> as DECs.

My understanding, which predates my contact with Unix, is that the
original toochains for single-job machines consisted of the assembler
or compiler, the output of which was loaded directly into core with
the loader.  As things became more complicated (and slow), it made
sense to store the memory image somewhere on drum, and then load that
image directly when you wanted to run it.  And that in some systems
the name "loader" stuck, even though it no longer loaded.  Something
like the modern ISP use of the term "modem" to mean "router".  But I
don't have anything to back up this version; comments welcome.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151210/fbd67b21/attachment.sig>

From jnc at mercury.lcs.mit.edu  Thu Dec 10 14:50:36 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  9 Dec 2015 23:50:36 -0500 (EST)
Subject: [TUHS] v6tar from v7 on v6, too large?
Message-ID: <20151210045036.6AAD318C074@mercury.lcs.mit.edu>

    > From: Dave Horsfall

    > I love those PDP-11 instructions, such as "blos" and "sob" :-)

Yes, but alas, there is no 'jump [on] no carry' instruction! (Yes, yes, I
know about BCC! :-) Although I guess the x86 has one...

	Noel


From jacob.ritorto at gmail.com  Thu Dec 10 19:42:27 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Thu, 10 Dec 2015 04:42:27 -0500
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151210010818.GE84775@eureka.lemis.com>
References: <20151209221624.B27CC18C0C9@mercury.lcs.mit.edu>
 <CAC20D2NcjcA_7NmnuEU-97BrWW3EeDOi51nHzfFr0YZFkG5jPQ@mail.gmail.com>
 <20151209224751.GC20697@mercury.ccil.org>
 <CAC20D2OEOowXDZ3t8WWwPe72bmUkzBjc13Ctk1sMj4kjnAEC_Q@mail.gmail.com>
 <20151210010818.GE84775@eureka.lemis.com>
Message-ID: <CAHYQbfB7O+sd96uqHBgEYo64sQhOsgyhq=5Js-opvzeHFvs21A@mail.gmail.com>

This is easily the greatest thread on this list in years.  LOVE!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151210/3db34e9d/attachment.html>

From lehmann at ans-netz.de  Thu Dec 10 20:06:08 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Thu, 10 Dec 2015 11:06:08 +0100
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151209224751.GC20697@mercury.ccil.org>
References: <20151209221624.B27CC18C0C9@mercury.lcs.mit.edu>
 <CAC20D2NcjcA_7NmnuEU-97BrWW3EeDOi51nHzfFr0YZFkG5jPQ@mail.gmail.com>
 <20151209224751.GC20697@mercury.ccil.org>
Message-ID: <20151210110608.Horde.vcTCqa9o3FI8EyFam_urkzp@avocado.salatschuessel.net>


John Cowan <cowan at mercury.ccil.org> wrote:

> Clem Cole scripsit:
>
>> ​To be fair UNIX was the naming sinner here IMO.  Unix's ld command is the
>> "link editor",
>
> I thought "ld" stood for Link eDitor.  :-)

You are completely wrong! It is the load mnemonic for Z8/Z80/Z8000 Assembler
to load the operand into the destination

    ld r1,r2

;)

Oliver


From lbickley at bickleywest.com  Thu Dec 10 15:01:39 2015
From: lbickley at bickleywest.com (Lyle Bickley)
Date: Wed, 9 Dec 2015 21:01:39 -0800
Subject: [TUHS] Server is changed
In-Reply-To: <20151210014111.GA28608@minnie.tuhs.org>
References: <20151210014111.GA28608@minnie.tuhs.org>
Message-ID: <20151209210139.200841d1@asrock.bcwi.net>

Hi Warren,

On Thu, 10 Dec 2015 11:41:11 +1000
Warren Toomey <wkt at tuhs.org> wrote:

> All, the server for minnie is changed to 45.79.103.53. Hopefully the
> mailing list software is working.

I posted a previous message to the list - and haven't seen it (yet)...

Lyle


> 
> Cheers, Warren
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs



-- 
73      AF6WS
Bickley Consulting West Inc.
http://bickleywest.com

"Black holes are where God is dividing by zero"


From lbickley at bickleywest.com  Thu Dec 10 14:58:37 2015
From: lbickley at bickleywest.com (Lyle Bickley)
Date: Wed, 9 Dec 2015 20:58:37 -0800
Subject: [TUHS] Server is changed
In-Reply-To: <20151210014111.GA28608@minnie.tuhs.org>
References: <20151210014111.GA28608@minnie.tuhs.org>
Message-ID: <20151209205837.15226a8d@asrock.bcwi.net>

On Thu, 10 Dec 2015 11:41:11 +1000
Warren Toomey <wkt at tuhs.org> wrote:

> All, the server for minnie is changed to 45.79.103.53. Hopefully the
> mailing list software is working.

Looks good...

Lyle

-- 
73      AF6WS
Bickley Consulting West Inc.
http://bickleywest.com

"Black holes are where God is dividing by zero"


From will.senn at gmail.com  Fri Dec 11 05:50:13 2015
From: will.senn at gmail.com (Will Senn)
Date: Thu, 10 Dec 2015 13:50:13 -0600
Subject: [TUHS] v6tar from v7 on v6, too large?
In-Reply-To: <20151210110608.Horde.vcTCqa9o3FI8EyFam_urkzp@avocado.salatschuessel.net>
References: <20151209221624.B27CC18C0C9@mercury.lcs.mit.edu>
 <CAC20D2NcjcA_7NmnuEU-97BrWW3EeDOi51nHzfFr0YZFkG5jPQ@mail.gmail.com>
 <20151209224751.GC20697@mercury.ccil.org>
 <20151210110608.Horde.vcTCqa9o3FI8EyFam_urkzp@avocado.salatschuessel.net>
Message-ID: <5669D775.9010900@gmail.com>

On 12/10/15 4:06 AM, Oliver Lehmann wrote:
>
> John Cowan <cowan at mercury.ccil.org> wrote:
>
>> Clem Cole scripsit:
>>
>>> ​To be fair UNIX was the naming sinner here IMO.  Unix's ld command 
>>> is the
>>> "link editor",
>>
>> I thought "ld" stood for Link eDitor.  :-)
>
> You are completely wrong! It is the load mnemonic for Z8/Z80/Z8000 
> Assembler
> to load the operand into the destination
>
>    ld r1,r2
>
> ;)
>
> Oliver

As a newb who doesn't know any better than what it seems they do, in 
keeping with the original minimalism:
"as" should have been "me" for mnemonic encoder
"ld" should have been "la" for link and assemble
and some obscure function in /usr/sys/ken/sys1.c or maybe even 
/usr/sys/dmr/sys1.c, because one guy's folder is as good as the next, 
should have been called pldr(), for program loader, which would have 
been the program 'loader'.

-Will


From doug at cs.dartmouth.edu  Fri Dec 11 07:08:47 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 10 Dec 2015 16:08:47 -0500
Subject: [TUHS] ld (was v6tar from v7 on v6, too large?)
Message-ID: <201512102108.tBAL8ljr025838@mail.cs.Dartmouth.EDU>

That's exactly right. ld performs the same task as LOAD did on BESYS,
except it builds the result in the file system rather than user
space. Over time it became clear that "linker" would be a better
term, but that didn't warrant canning the old name. Gresham's law
then came into play and saddled us with the ponderous and
misleading term, "link editor".

Doug

> My understanding, which predates my contact with Unix, is that the
> original toochains for single-job machines consisted of the assembler
> or compiler, the output of which was loaded directly into core with
> the loader.  As things became more complicated (and slow), it made
> sense to store the memory image somewhere on drum, and then load that
> image directly when you wanted to run it.  And that in some systems
> the name "loader" stuck, even though it no longer loaded.  Something
> like the modern ISP use of the term "modem" to mean "router".  But I
> don't have anything to back up this version; comments welcome.


From rochkind at basepath.com  Fri Dec 11 08:28:12 2015
From: rochkind at basepath.com (Marc Rochkind)
Date: Thu, 10 Dec 2015 15:28:12 -0700
Subject: [TUHS] ld (was v6tar from v7 on v6, too large?)
In-Reply-To: <201512102108.tBAL8ljr025838@mail.cs.Dartmouth.EDU>
References: <201512102108.tBAL8ljr025838@mail.cs.Dartmouth.EDU>
Message-ID: <CAOkr1zUcbt2UgF37R3fd-kdQq2uDG8aMONAx2L6aoGLp=tS3rQ@mail.gmail.com>

After a while, I shortened this in my mind to something like "the UNIX
linker is called ld." No problem with that, but a few times I
absent-mindedly typed "ln" for "linker", which generally produced very
strange results.

--Marc

On Thu, Dec 10, 2015 at 2:08 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> That's exactly right. ld performs the same task as LOAD did on BESYS,
> except it builds the result in the file system rather than user
> space. Over time it became clear that "linker" would be a better
> term, but that didn't warrant canning the old name. Gresham's law
> then came into play and saddled us with the ponderous and
> misleading term, "link editor".
>
> Doug
>
> > My understanding, which predates my contact with Unix, is that the
> > original toochains for single-job machines consisted of the assembler
> > or compiler, the output of which was loaded directly into core with
> > the loader.  As things became more complicated (and slow), it made
> > sense to store the memory image somewhere on drum, and then load that
> > image directly when you wanted to run it.  And that in some systems
> > the name "loader" stuck, even though it no longer loaded.  Something
> > like the modern ISP use of the term "modem" to mean "router".  But I
> > don't have anything to back up this version; comments welcome.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151210/6fb16f10/attachment.html>

From will.senn at gmail.com  Sat Dec 12 08:27:28 2015
From: will.senn at gmail.com (Will Senn)
Date: Fri, 11 Dec 2015 16:27:28 -0600
Subject: [TUHS] why does tar have the tape device hard coded into it and why
 is it mt1 instead of mt0
Message-ID: <566B4DD0.6070700@gmail.com>

All,

In my exploration of v6, I followed the advice in "Setting up Unix - 
Seventh Edition" and copied v6tar from v7 to v6. Life is good. However, 
tar is using mt1 and it is hard coded into the source, tar.c:
char    magtape[]       = "/dev/mt1";

As the subject line suggested, I have two questions for those of you who 
might know:

1. Why is it hard coded?
2. Why is it the second device and not the first?

Interestingly, it took me a little while to figure out it was doing this 
because I didn't actually move files between v6 and v7 until today. 
Before this my tests had been limited to separate tests on v6 and v7 
along the lines of:

cd /wherever
tar c .
followed by
tar t
list of files
cd /elsewhere
tar x
files extracted and matching

What it was doing was writing to the non-existant /dev/mt1, which it 
then created, tarring up stuff, and exiting. Then when I listed the 
contents of the tarfile, or extracted the contents, it was successful. 
But, when I went to move the tape between v6 and v7, the tape (mt0) was 
blank, of course. It was at this point that I followed  Noel's advice 
and "Used the source", and figured out that it was hard-coded as you see 
above.

Thanks,

Will


From clemc at ccc.com  Sat Dec 12 08:31:48 2015
From: clemc at ccc.com (Clem Cole)
Date: Fri, 11 Dec 2015 17:31:48 -0500
Subject: [TUHS] why does tar have the tape device hard coded into it and
 why is it mt1 instead of mt0
In-Reply-To: <566B4DD0.6070700@gmail.com>
References: <566B4DD0.6070700@gmail.com>
Message-ID: <CAC20D2Mw1DyJq0v-YOZOe2CaG=Kx0=6TWBth+bNz1n29myL58Q@mail.gmail.com>

First, the device # should be usable from the command line, i.e.  tar cv0
foo

As for mt, it was written for the tape device and in those days most of us
had at least one 9-track device.    I have no memory of why Ken used mt1
not mt0.   Doug may know.

On Fri, Dec 11, 2015 at 5:27 PM, Will Senn <will.senn at gmail.com> wrote:

> All,
>
> In my exploration of v6, I followed the advice in "Setting up Unix -
> Seventh Edition" and copied v6tar from v7 to v6. Life is good. However, tar
> is using mt1 and it is hard coded into the source, tar.c:
> char    magtape[]       = "/dev/mt1";
>
> As the subject line suggested, I have two questions for those of you who
> might know:
>
> 1. Why is it hard coded?
> 2. Why is it the second device and not the first?
>
> Interestingly, it took me a little while to figure out it was doing this
> because I didn't actually move files between v6 and v7 until today. Before
> this my tests had been limited to separate tests on v6 and v7 along the
> lines of:
>
> cd /wherever
> tar c .
> followed by
> tar t
> list of files
> cd /elsewhere
> tar x
> files extracted and matching
>
> What it was doing was writing to the non-existant /dev/mt1, which it then
> created, tarring up stuff, and exiting. Then when I listed the contents of
> the tarfile, or extracted the contents, it was successful. But, when I went
> to move the tape between v6 and v7, the tape (mt0) was blank, of course. It
> was at this point that I followed  Noel's advice and "Used the source", and
> figured out that it was hard-coded as you see above.
>
> Thanks,
>
> Will
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151211/8384cbce/attachment.html>

From will.senn at gmail.com  Sat Dec 12 08:52:07 2015
From: will.senn at gmail.com (Will Senn)
Date: Fri, 11 Dec 2015 16:52:07 -0600
Subject: [TUHS] why does tar have the tape device hard coded into it and
 why is it mt1 instead of mt0
In-Reply-To: <CAC20D2Mw1DyJq0v-YOZOe2CaG=Kx0=6TWBth+bNz1n29myL58Q@mail.gmail.com>
References: <566B4DD0.6070700@gmail.com>
 <CAC20D2Mw1DyJq0v-YOZOe2CaG=Kx0=6TWBth+bNz1n29myL58Q@mail.gmail.com>
Message-ID: <566B5397.1060100@gmail.com>



On 12/11/15 4:31 PM, Clem Cole wrote:
> First, the device # should be usable from the command line, i.e.  tar 
> cv0 foo
>
> As for mt, it was written for the tape device and in those days most 
> of us had at least one 9-track device.    I have no memory of why Ken 
> used mt1 not mt0.   Doug may know.
>
Clem,

Thanks, that'll teach me to read the man pages more carefully even when 
the command is familiar in its modern form. Your tip about the device 
number caused me to check. Sure enough, it's in the documentation :). I 
am so impressed with the durability of the original documentation. These 
were written some 40+ years ago, and they're still amazingly useable by 
folks like me who have only worked with OSes created since the 1990's 
(of course, not entirely without help).

man tar
...
0,...,7   This modifier selects the drive on which the tape
                is mounted.  The default is 1.
...

-will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151211/7e21278c/attachment.html>

From cowan at mercury.ccil.org  Sat Dec 12 09:13:55 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Fri, 11 Dec 2015 18:13:55 -0500
Subject: [TUHS] why does tar have the tape device hard coded into it and
 why is it mt1 instead of mt0
In-Reply-To: <566B5397.1060100@gmail.com>
References: <566B4DD0.6070700@gmail.com>
 <CAC20D2Mw1DyJq0v-YOZOe2CaG=Kx0=6TWBth+bNz1n29myL58Q@mail.gmail.com>
 <566B5397.1060100@gmail.com>
Message-ID: <20151211231355.GH30075@mercury.ccil.org>

Will Senn scripsit:

> Thanks, that'll teach me to read the man pages more carefully even
> when the command is familiar in its modern form. 

Note that if -f is not given, modern tars still default to the tape
drive, /dev/st0 on Linux or /dev/sa0 on *BSD.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Barry thirteen gules and argent on a canton azure fifty mullets of five
points of the second,  six, five, six, five, six, five, six, five, and six.
        --blazoning the U.S. flag


From will.senn at gmail.com  Sat Dec 12 10:03:51 2015
From: will.senn at gmail.com (Will Senn)
Date: Fri, 11 Dec 2015 18:03:51 -0600
Subject: [TUHS] why is sum reporting different checksum's between v6 and v7
Message-ID: <566B6467.5060703@gmail.com>

All,

While working on the latest episode of my saga about moving files 
between v6 and v7, I noticed that the sum utility from v6 reports a 
different checksum than it does using the sum utility from v7 for the 
same file. To confirm, I did the following on both systems:

# echo "Hello, World" > hi.txt
# cat hi.txt
Hello, World

Then on v6:
# sum hi.txt
1106 1

But on v7:
# sum hi.txt
37264     1

There is no man page for the utility on v6, and it's assembler. On v7, 
there's a manpage and it's C:
man sum
...
Sum calculates and prints a 16-bit checksum for the named
      file, and also prints the number of blocks in the file.
...

A few questions:
1. I'll eventually be able to read assembly and learn what the v6 
utility is doing the hard way, but does anyone know what's going on here?
2. Why is sum reporting different checksum's between v6 and v7?
3. Do you know of an alternative to check that the bytes were 
transferred exactly? I used od and then compared the text representation 
of the bytes  on the host using diff (other than differences in output 
between v6 and v7 related to duplicate lines, it worked ok but is clunky).

Thanks,

Will


From clemc at ccc.com  Sat Dec 12 10:10:07 2015
From: clemc at ccc.com (Clem cole)
Date: Fri, 11 Dec 2015 19:10:07 -0500
Subject: [TUHS] why is sum reporting different checksum's between v6 and
	v7
In-Reply-To: <566B6467.5060703@gmail.com>
References: <566B6467.5060703@gmail.com>
Message-ID: <44F5C6AC-AAD2-45F3-AD53-E510E3744F16@ccc.com>

A thought. Try recompiling v7 sum on v6.  It's simple enough that the compiler differences should be easy to tease out. 

Sent from my iPhone

> On Dec 11, 2015, at 7:03 PM, Will Senn <will.senn at gmail.com> wrote:
> 
> All,
> 
> While working on the latest episode of my saga about moving files between v6 and v7, I noticed that the sum utility from v6 reports a different checksum than it does using the sum utility from v7 for the same file. To confirm, I did the following on both systems:
> 
> # echo "Hello, World" > hi.txt
> # cat hi.txt
> Hello, World
> 
> Then on v6:
> # sum hi.txt
> 1106 1
> 
> But on v7:
> # sum hi.txt
> 37264     1
> 
> There is no man page for the utility on v6, and it's assembler. On v7, there's a manpage and it's C:
> man sum
> ...
> Sum calculates and prints a 16-bit checksum for the named
>     file, and also prints the number of blocks in the file.
> ...
> 
> A few questions:
> 1. I'll eventually be able to read assembly and learn what the v6 utility is doing the hard way, but does anyone know what's going on here?
> 2. Why is sum reporting different checksum's between v6 and v7?
> 3. Do you know of an alternative to check that the bytes were transferred exactly? I used od and then compared the text representation of the bytes  on the host using diff (other than differences in output between v6 and v7 related to duplicate lines, it worked ok but is clunky).
> 
> Thanks,
> 
> Will
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs


From cubexyz at gmail.com  Sat Dec 12 10:35:00 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Fri, 11 Dec 2015 19:35:00 -0500
Subject: [TUHS] where is the v6tar source?
Message-ID: <CADxT5N4mkX_8NnEk0Ctcve+4MM3CLgwZi30NzO_nGBfosFrBCw@mail.gmail.com>

Ok, it definitely sounds like the v6tar source is around somewhere so
if someone could point me in the right direction...

I've only seen the binary, and I can't remember where I got it.

Mark


From random832 at fastmail.com  Sat Dec 12 10:26:55 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 12 Dec 2015 00:26:55 +0000 (UTC)
Subject: [TUHS] why does tar have the tape device hard coded into it and
 why is it mt1 instead of mt0
References: <566B4DD0.6070700@gmail.com>
 <CAC20D2Mw1DyJq0v-YOZOe2CaG=Kx0=6TWBth+bNz1n29myL58Q@mail.gmail.com>
 <566B5397.1060100@gmail.com> <20151211231355.GH30075@mercury.ccil.org>
Message-ID: <n4fpkf$f6v$1@ger.gmane.org>

On 2015-12-11, John Cowan <cowan at mercury.ccil.org> wrote:
> Will Senn scripsit:
>
>> Thanks, that'll teach me to read the man pages more carefully even
>> when the command is familiar in its modern form. 
>
> Note that if -f is not given, modern tars still default to the tape
> drive, /dev/st0 on Linux or /dev/sa0 on *BSD.

That depends on the tar. A lot these days default to stdin (or
stdout as appropriate to the operation). Many don't even support
the "drive number" option. OSX knows nothing of the options, and
Ubuntu's GNU tar says:

tar: Options '-[0-7][lmh]' not supported by *this* tar

GNU tar has the capability, but it's apparently not a very
well-used feature, since the ./configure script it ships with
has a bug in a sed command meant to convert e.g. "/dev/st0" to
"/dev/st" [prefix for 0-7 to be appended to].

Star switched in 1982, according to the author. And in any case
even when POSIX did define tar, it only said the default was
"system-dependent".

The only one I could find that keeps this alive is bsdtar
(libarchive) which apparently will even use something called
\\.\tape0 if compiled for Windows. But it doesn't actually
support the 0-7 options.

Well, that and OpenSolaris tar. Which apparently gets devices
_and_ blocking factors corresponding to arguments 0-7 from
/etc/default/tar:

> archive0=/dev/rmt/0		20	0
> archive1=/dev/rmt/0n		20	0
> archive2=/dev/rmt/1		20	0
> archive3=/dev/rmt/1n		20	0
> archive4=/dev/rmt/0		126	0
> archive5=/dev/rmt/0n		126	0
> archive6=/dev/rmt/1		126	0
> archive7=/dev/rmt/1n		126	0

(The third argument is a size parameter; you're supposed to use
it if you define one of the devices to be a floppy drive.)



From random832 at fastmail.com  Sat Dec 12 10:38:03 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 12 Dec 2015 00:38:03 +0000 (UTC)
Subject: [TUHS] why is sum reporting different checksum's between v6 and
	v7
References: <566B6467.5060703@gmail.com>
Message-ID: <n4fq9a$ogr$1@ger.gmane.org>

On 2015-12-12, Will Senn wrote:
> # echo "Hello, World" > hi.txt
> # cat hi.txt
> Hello, World
>
> Then on v6:
> # sum hi.txt
> 1106 1
>
> But on v7:
> # sum hi.txt
> 37264     1

Interestingly, I can get both results on OSX:

% echo "Hello, World" | cksum -o 1
37264 1
% echo "Hello, World" | cksum -o 2
1106 1

Or Ubuntu:
% echo "Hello, World" | sum -r
37264     1
% echo "Hello, World" | sum -s
1106 1

Both of these define the one you got in v7 as a "BSD" algorithm.
So it looks like v7's new algorithm didn't make it into USG
Unix, rather it uses the same one as v6. (According to the OSX
manpage, System V eventually grew a "-r" option to use the newer
algorithm).

The second number is the size in blocks, which is 512 for the
"System V" algorithm and 1024 bytes for modern implementations
of the "BSD" algorithm, *but* BUFSIZ (512) for v7.



From random832 at fastmail.com  Sat Dec 12 10:42:45 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 12 Dec 2015 00:42:45 +0000 (UTC)
Subject: [TUHS] where is the v6tar source?
References: <CADxT5N4mkX_8NnEk0Ctcve+4MM3CLgwZi30NzO_nGBfosFrBCw@mail.gmail.com>
Message-ID: <n4fqi4$ogr$2@ger.gmane.org>

On 2015-12-12, Mark Longridge  wrote:
> Ok, it definitely sounds like the v6tar source is around somewhere so
> if someone could point me in the right direction...
>
> I've only seen the binary, and I can't remember where I got it.

It's part of v7. It's not really an independent artifact,
though.  It's v7's tar.c linked against a compatibility library,
all compiled with v7's compiler.

See:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/v6
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/tar/makefile



From jnc at mercury.lcs.mit.edu  Sat Dec 12 10:30:57 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 11 Dec 2015 19:30:57 -0500 (EST)
Subject: [TUHS] why is sum reporting different checksum's between v6 and
	v7
Message-ID: <20151212003057.75C5B18C0CB@mercury.lcs.mit.edu>

    > From: Will Senn

    > I noticed that the sum utility from v6 reports a different checksum
    > than it does using the sum utility from v7 for the same file.
    > ... does anyone know what's going on here?
    > Why is sum reporting different checksum's between v6 and v7?

The two use different algorithms to accumulate the sum (I have added comments
to the relevant portion of the V6 assembler one, to help understand it):

V6:
	mov	$buf,r2		/ Pointer to buffer in R2
    2:	movb	(r2)+,r4	/ Get new byte into R4 (sign extends!)
	add	r4,r5		/ Add to running sum
	adc	r5		/ If overflow, add carry into low end of sum
	sob	r0,2b		/ If any bytes left, go around again

Read the description of MOVB in the PDP-11 Processor manual.

V7:
	while ((c = getc(f)) != EOF) {
		nbytes++;
		if (sum&01)
			sum = (sum>>1) + 0x8000;
		else
			sum >>= 1;
		sum += c;
		sum &= 0xFFFF;
		}

I'm not clear on some of that, so I'll leave its exact workings as an
exercise, but I'm pretty sure it's not a equivalent algorithm (as in,
something that would produce the same results); it's certainly not
identical. (The right shift is basically a rotate, so it's not a straight sum,
it's more like the Fletcher checksum used by XNS, if anyone remembers that.)

Among the parts I don't get, for instance, sum is declared as 'unsigned',
presumably 16 bits, so the last line _should_ be a NOP!? Also, with 'c' being
implicitly declared as an 'int', does the assignment sign extend? I have this
vague memory that it does. And does the right shift if the low bit is one
really do what the code seems to indicate it does? I have this bit that ASR on
the PDP-11 copies the high bit, not shifts in a 0 (check the processor
manual).  That is, of course, assuming that the compiler implements the '>>'
with an ASR, not a ROR followed by a clear of the high bit, or something.
  
	Noel


From random832 at fastmail.com  Sat Dec 12 11:07:19 2015
From: random832 at fastmail.com (Random832)
Date: Fri, 11 Dec 2015 20:07:19 -0500
Subject: [TUHS] why is sum reporting different checksum's between v6 and
	v7
References: <20151212003057.75C5B18C0CB@mercury.lcs.mit.edu>
Message-ID: <m28u5079vc.fsf@fastmail.com>

Noel Chiappa writes:
> The two use different algorithms to accumulate the sum (I have added comments
> to the relevant portion of the V6 assembler one, to help understand it):
>
> V6:
> 	mov	$buf,r2		/ Pointer to buffer in R2
>     2:	movb	(r2)+,r4	/ Get new byte into R4 (sign extends!)
> 	add	r4,r5		/ Add to running sum
> 	adc	r5		/ If overflow, add carry into low end of sum
> 	sob	r0,2b		/ If any bytes left, go around again

Interestingly, the SysIII sum.c program, which I assume yields the same
result for this input, appears to go through the whole input
accumulating the sum of all the bytes into a long, then adds the two
halves of the long at the end rather than after every byte. This
suggests that the two programs would give different results for very
large files that overflow a 32-bit value. Of course, that's (16843010
bytes if all of them are 255) well beyond the size of file you're likely
to encounter on a v6 system.

Also, if this sign extends, then its behavior on "negative" (high bit
set) bytes is likely to be very different from the SysIII one, which
uses getc.

Can someone who has V6 up test what the checksum of a file consisting of
a single byte with the high bit set? On the "modern" implementations it
is the same as the value of the byte [e.g. 255] in both algorithms.



From jnc at mercury.lcs.mit.edu  Sat Dec 12 11:22:57 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 11 Dec 2015 20:22:57 -0500 (EST)
Subject: [TUHS] why is sum reporting different checksum's between v6 and
	v7
Message-ID: <20151212012257.3740418C0AA@mercury.lcs.mit.edu>

    > From: Random832

    > Interestingly, the SysIII sum.c program, which I assume yields the same
    > result for this input, appears to go through the whole input
    > accumulating the sum of all the bytes into a long, then adds the two
    > halves of the long at the end rather than after every byte.

That's the same hack a lot of TCP/IP checksums routines used on machines with
longer words; add the words, then fold the result in the shorter length at the
end. The one I wrote for the 68K back in '84 did that.

    > This suggests that the two programs would give different results for
    > very large files that overflow a 32-bit value.

No, I don't think so, depending on the exact detals of the implementation. As
long as when folding the two halves together, you add any carry into the sum,
you get the same result as doing it into a 16-bit sum. (If my memory of how
this all works is correct - the neurons aren't what they used to be,
especially late in the day... :-)

    > Also, if this sign extends, then its behavior on "negative" (high bit
    > set) bytes is likely to be very different from the SysIII one, which
    > uses getc.

I have this bit set that in C, 'char' is defined to be signed, and
furthermore that when you assign a shorter int to a longer one, the sign is
extended. So if one has a char holding '0200' octal (i.e. -128), assigning it
to a 16-bit int should result in the latter holding '0177600' (i.e. still
-128). So in fact I think they probably act the same.

	Noel


From random832 at fastmail.com  Sat Dec 12 11:46:28 2015
From: random832 at fastmail.com (Random832)
Date: Fri, 11 Dec 2015 20:46:28 -0500
Subject: [TUHS] why is sum reporting different checksum's between v6 and
	v7
References: <20151212012257.3740418C0AA@mercury.lcs.mit.edu>
Message-ID: <m2r3is5thn.fsf@fastmail.com>

Noel Chiappa writes:
> No, I don't think so, depending on the exact detals of the implementation. As
> long as when folding the two halves together, you add any carry into the sum,
> you get the same result as doing it into a 16-bit sum.

The issue I was suggesting comes if you've lost carry bits
_before_ folding the two halves together, when you were working
in 32-bit arithmetic.

> (If my memory of how
> this all works is correct - the neurons aren't what they used to be,
> especially late in the day... :-)
>
>     > Also, if this sign extends, then its behavior on "negative" (high bit
>     > set) bytes is likely to be very different from the SysIII one, which
>     > uses getc.
>
> I have this bit set that in C, 'char' is defined to be signed

The SysIII sum.c file uses getc and stores the result in an int,
not a char.

I *think* the definition of getc returns positive values the
same as modern systems do, despite the manpage's caution to
check feof because EOF is a "valid integer value":

#define	getc(p)		(--(p)->_cnt>=0? *(p)->_ptr++&0377:_filbuf(p))

_filbuf also has & 0377 in the relevant place.

If getc returns negative values for high-bit characters, on the
other hand, then they would sign-extend to 32 bits when the long
math is done, still yielding different results.



From cowan at mercury.ccil.org  Sat Dec 12 11:50:04 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Fri, 11 Dec 2015 20:50:04 -0500
Subject: [TUHS] why is sum reporting different checksum's between v6 and
 v7
In-Reply-To: <20151212012257.3740418C0AA@mercury.lcs.mit.edu>
References: <20151212012257.3740418C0AA@mercury.lcs.mit.edu>
Message-ID: <20151212015004.GA15143@mercury.ccil.org>

Noel Chiappa scripsit:

> I have this bit set that in C, 'char' is defined to be signed, 

If you mean in PDP-11 C, you're right, char is signed precisely because
MOVB sign extends.  In C in general, char's signedness is undefined.
Similarly the signedness of a bitfield is undefined, which means that
the portable range of a 1-bit field is just 0, though there is another
value that might be +1 or -1.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Eric Raymond is the Margaret Mead of the Open Source movement.
          --Bruce Perens, a long time ago


From doug at cs.dartmouth.edu  Sat Dec 12 12:09:03 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 11 Dec 2015 21:09:03 -0500
Subject: [TUHS] why does tar have the tape device hard coded into it and
 why is it mt1 instead of mt0
Message-ID: <201512120209.tBC2930f007838@coolidge.cs.Dartmouth.EDU>


> I have no memory of why Ken used mt1 not mt0.   Doug may know.

I don't know either. Come to think of it, I can't remember ever
using tar without option -f. Direct machine-to-machine trasfer,
e.g. by uucp, took a lot of business away from magtape soon
after tar was introduced. Incidentally, I think tar was written
by Chuck Haley or Greg Chesson, not Ken.

Doug


From peter at rulingia.com  Sat Dec 12 14:54:16 2015
From: peter at rulingia.com (Peter Jeremy)
Date: Sat, 12 Dec 2015 15:54:16 +1100
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
Message-ID: <20151212045416.GB5686@server.rulingia.com>

Some time ago, someone posted an early Unix image that I recall
running.  I know it was pre-groups but don't recall anything else and
I can't find either the images or mailing list references either
locally or on tuhs.org.  Does anyone recall the details.

Also, I've seen suggestions that there's a 2.11BSD patch later than
447 but I can't find anything "official" and www.2bsd.com is either
down or inaccessible from all the systems I have access to.  Does
anyone know if 448 or later were released?  And given the issues with
www.2bsd.com would someone be willing to mirror it (assuming we can
got a copy of it)?

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151212/ee19d017/attachment.sig>

From wkt at tuhs.org  Sat Dec 12 15:30:59 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 12 Dec 2015 15:30:59 +1000
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <20151212045416.GB5686@server.rulingia.com>
References: <20151212045416.GB5686@server.rulingia.com>
Message-ID: <721CCD91-F2D5-4D22-8D54-EE939112902A@tuhs.org>

We got the 1st Edition kernel up a while back and it had no groups. Look for unix-jun72 on Github.

Cheers, Warren

On 12 December 2015 2:54:16 pm AEST, Peter Jeremy <peter at rulingia.com> wrote:
>Some time ago, someone posted an early Unix image that I recall
>running.  I know it was pre-groups but don't recall anything else and
>I can't find either the images or mailing list references either
>locally or on tuhs.org.  Does anyone recall the details.
>
>Also, I've seen suggestions that there's a 2.11BSD patch later than
>447 but I can't find anything "official" and www.2bsd.com is either
>down or inaccessible from all the systems I have access to.  Does
>anyone know if 448 or later were released?  And given the issues with
>www.2bsd.com would someone be willing to mirror it (assuming we can
>got a copy of it)?
>
>-- 
>Peter Jeremy
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>TUHS mailing list
>TUHS at minnie.tuhs.org
>http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151212/560bcc39/attachment.html>

From wkt at tuhs.org  Sat Dec 12 15:33:57 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 12 Dec 2015 15:33:57 +1000
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <20151212045416.GB5686@server.rulingia.com>
References: <20151212045416.GB5686@server.rulingia.com>
Message-ID: <20151212053357.GA21648@minnie.tuhs.org>

On Sat, Dec 12, 2015 at 03:54:16PM +1100, Peter Jeremy wrote:
> Also, I've seen suggestions that there's a 2.11BSD patch later than
> 447 but I can't find anything "official" and www.2bsd.com is either
> down or inaccessible from all the systems I have access to.  Does
> anyone know if 448 or later were released?  And given the issues with
> www.2bsd.com would someone be willing to mirror it (assuming we can
> got a copy of it)?

[ Back to a real keyboard ]. Yes I'd be very happy to mirror 2bsd.com.
Does anybody know what's happened to Steven Schultz?

Cheers, Warren


From pechter at gmail.com  Sat Dec 12 16:01:10 2015
From: pechter at gmail.com (William Pechter)
Date: Sat, 12 Dec 2015 01:01:10 -0500
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <20151212053357.GA21648@minnie.tuhs.org>
References: <20151212045416.GB5686@server.rulingia.com>
 <20151212053357.GA21648@minnie.tuhs.org>
Message-ID: <566BB826.2010304@gmail.com>

Warren Toomey wrote:
> On Sat, Dec 12, 2015 at 03:54:16PM +1100, Peter Jeremy wrote:
>> Also, I've seen suggestions that there's a 2.11BSD patch later than
>> 447 but I can't find anything "official" and www.2bsd.com is either
>> down or inaccessible from all the systems I have access to.  Does
>> anyone know if 448 or later were released?  And given the issues with
>> www.2bsd.com would someone be willing to mirror it (assuming we can
>> got a copy of it)?
> [ Back to a real keyboard ]. Yes I'd be very happy to mirror 2bsd.com.
> Does anybody know what's happened to Steven Schultz?
>
> Cheers, Warren
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
Last patch is 447 from June 2012.

I can get to the site just fine... pasted the patch below if it helps 
anyone.
I haven't heard anything about him.  Haven't worked at the same company 
since the early 1990's...


Bill

Received: by 10.68.220.230 with SMTP id pz6mr12885595pbc.3.1339950326173;
         Sun, 17 Jun 2012 09:25:26 -0700 (PDT)
Path: l9ni61647pbj.0!nntp.google.com!news2.google.com!goblin3!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!newsfeed.Update.UU.SE!news.Update.UU.SE!not-for-mail
From: Johnny Billquist <b... at softjar.se>
Newsgroups: vmsnet.pdp-11,alt.sys.pdp11
Subject: 2BSD patches...
Date: Sun, 17 Jun 2012 18:25:24 +0200
Organization: Update Computer Club
Message-ID: <jrl0dk$et3$1 at Iltempo.Update.UU.SE>
NNTP-Posting-Host: 178-83-31-172.dynamic.hispeed.ch
Mime-Version: 1.0
X-Trace: Iltempo.Update.UU.SE 1339950325 15267 178.83.31.172 (17 Jun 2012 16:25:25 GMT)
X-Complaints-To: newsm... at Update.UU.SE
NNTP-Posting-Date: Sun, 17 Jun 2012 16:25:25 +0000 (UTC)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
Content-Type: multipart/mixed;
  boundary="------------000004000801020107010201"

--------------000004000801020107010201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi. Here is a set of patches to 2BSD, which fixes a number of problems.
Terribly sorry that I don't present it in the same nice format that
Steven M. Schultz does, but I'll try an explain what this is briefly.

I've named this patch set path #448, as the last known patches to me are
#447. Apply this patch set after you brought it up to version 447...

Fixes in here:

====

1. Use of non-DEC MSCP controllers improved. Some parts of 2BSD have
been updated to work with (for example) CMD controllers, but not all
parts were. This set of patches makes it possible to boot and run with
the CDU-720, for example, which did not work before.

2. Boot program now automatically boots unless manual intervention on
console. This looks pretty similar to NetBSD on VAX for example, where a
countdown is presented at boot time, and the system continues with an
automatic boot unless aborted. Previously, 2BSD would not autoboot from
cold start because the reboot-flag was not present at power up.

3. Console terminal made 8-bit clean. On a real PDP-11, the boot
monitors are 8-bit clean. However, 2BSD previously ran with 7E on the
console, and there was no way to avoid this for system output. This
patch makes it all 8-bit clean.

4. The libc resolver code used /etc/hosts if no resolved was available,
but if one was, it never used the /etc/hosts. This created a peculiar
effect, especially at bootup, since the resolver couldn't be contacted
before the network was up, but /etc/hosts were not used, since a correct
/etc/resolv.conf existed. The order is not possible to select. It will
first try using the resolver, but if that fails, it now falls back to
trying /etc/hosts

5. At system build time, the newvers.sh tries to figure out various bits
and pieces to put into the built file to tell when the kernel was built,
where and by who. This parsing could fail in various ways because of how
the date command works with time zones. Fixed by changing how it figures
out the information and pass it around.

6. The mandoc macros had a Y2K bug, or rather a 2010 bug, in that the
Y2K bug fix actually only fixed years 2000-2009, and it broke again in
2010. This patch does a proper fix to the Y2K problem. Also fixed a
spelling error.

====

As usual, the code might not be pretty, but I've atleast been running it
myself on several machines for close to two years now, and believe these
are all workable, and important patches.
Download to your machine.
At the root of the file system run:
$ patch -p0 < patchfile

after this, rebuild the kernel and the boot image. Install the new
kernel, the new boot, and then rebuild all of userland.

If you have any questions, feel free to send me an email.

This patch set will bring your system up to patch version 448.

      Johnny



-- 
Johnny Billquist                  || "I'm on a bus
                                    ||  on a psychedelic trip
email: b... at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol



*** VERSION.orig	Sun Jun 17 17:02:22 2012
--- VERSION	Thu Apr  1 14:17:48 2010
***************
*** 1,5 ****
! Current Patch Level: 447
! Date: December 31, 2008
   
   2.11 BSD
   ============
--- 1,5 ----
! Current Patch Level: 448
! Date: January 5, 2010
   
   2.11 BSD
   ============
***************
*** 62,88 ****
   	112 South Lakeview Canyon Road
   	Thousand Oaks CA 91359
   	sms at wlv.iipo.gtegsc.com
-
- 	Below is the original VERSION file distributed with 2.10.1BSD
- -----------------------------------------------------------------------
- NOTE --
- 	This is the second release of 2.10BSD; most of the changes
- 	are part of the addition of supervisor space networking in
- 	the kernel, although there are other changes.
-
- 	To give some idea of the dates involved, distribution of
- 	2.10BSD by the USENIX Assoc. started in fall of 1987.
- 	Distribution of this source started in January of 1989.
-
- Keith Bostic
- Casey Leedom
- Cyrus Rahman
- Steven Schultz
- 	Steven M. Schultz
- 	Contel Federal Systems
- 	31717 La Tienda Drive
- 	Westlake Village CA 91359
- 	sms at wlv.imsd.contel.com
   
   	Below is the original VERSION file distributed with 2.10.1BSD
   -----------------------------------------------------------------------
--- 62,67 ----
*** usr/src/sys/pdpstand/boot.c.old	Wed Aug 19 00:22:03 2009
--- usr/src/sys/pdpstand/boot.c	Wed Aug 19 02:46:18 2009
***************
*** 172,178 ****
   	 * this is an automatic reboot, otherwise do it the hard way.
   	 */
   	if (checkword != ~bootopts)
! 		bootopts = RB_SINGLE | RB_ASKNAME;
   	j = -1;
   	do {
   		if (bootopts & RB_ASKNAME) {
--- 172,189 ----
   	 * this is an automatic reboot, otherwise do it the hard way.
   	 */
   	if (checkword != ~bootopts)
! 		bootopts = 0;
!
! 	printf("Press <CR> to boot, or any other key to abort:  ");
! 	for (i=5; i>=0; i--) {
! 		printf("\b%d", i);
! 		j = getchar2(50);
! 		if (j != -1) {
! 			if (j != '\n') bootopts = RB_ASKNAME;
! 			break;
! 		}
! 	}
! 	printf("\n");
   	j = -1;
   	do {
   		if (bootopts & RB_ASKNAME) {
*** usr/src/sys/pdp/cons.c.old	Wed Aug 19 00:25:03 2009
--- usr/src/sys/pdp/cons.c	Tue Aug 18 18:09:57 2009
***************
*** 164,170 ****
   	if (tp->t_flags & (RAW|LITOUT))
   		addr->dlxbuf = c&0xff;
   	else
! 		addr->dlxbuf = c | (partab[c] & 0200);
   	tp->t_state |= TS_BUSY;
   out:
   	splx(s);
--- 164,170 ----
   	if (tp->t_flags & (RAW|LITOUT))
   		addr->dlxbuf = c&0xff;
   	else
! 		addr->dlxbuf = c&0xff; /* | (partab[c] & 0200); /bqt */
   	tp->t_state |= TS_BUSY;
   out:
   	splx(s);
*** usr/src/lib/libc/net/named/gethnamadr.c.orig	Sun Feb 28 03:59:41 2010
--- usr/src/lib/libc/net/named/gethnamadr.c	Thu Apr  1 04:25:45 2010
***************
*** 8,13 ****
--- 8,20 ----
    * may not be used to endorse or promote products derived from this
    * software without specific prior written permission. This software
    * is provided ``as is'' without express or implied warranty.
+  *
+  * 2010-04-01	Johnny Billquist
+  *
+  * Changed code so that /etc/hosts are consulted even if named is
+  * used. This means that if name resolution fails, it will fall back
+  * to using /etc/hosts. Previously it just failed in this case. (But it
+  * did consult /etc/hosts if no named.conf existed.)
    */
   
   #if defined(LIBC_SCCS) && !defined(lint)
***************
*** 227,236 ****
--- 234,247 ----
   		if (_res.options & RES_DEBUG)
   			printf("res_search failed\n");
   #endif
+ #ifdef BQT
   		if (errno == ECONNREFUSED)
+ #endif
   			return (_gethtbyname(name));
+ #ifdef BQT
   		else
   			return ((struct hostent *) NULL);
+ #endif
   	}
   	return (getanswer(&buf, n, 0));
   }
***************
*** 259,269 ****
   		if (_res.options & RES_DEBUG)
   			printf("res_query failed\n");
   #endif
   		if (errno == ECONNREFUSED)
   			hp = _gethtbyaddr(addr, len, type);
! 		return ((struct hostent *) NULL);
! 	}
! 	hp = getanswer(&buf, n, 1);
   	if (hp == NULL)
   		return ((struct hostent *) NULL);
   	hp->h_addrtype = type;
--- 270,285 ----
   		if (_res.options & RES_DEBUG)
   			printf("res_query failed\n");
   #endif
+ #ifdef BQT
   		if (errno == ECONNREFUSED)
+ #endif
   			hp = _gethtbyaddr(addr, len, type);
! #ifdef BQT
! 		else
! 			return ((struct hostent *) NULL);
! #endif
! 	} else
! 		hp = getanswer(&buf, n, 1);
   	if (hp == NULL)
   		return ((struct hostent *) NULL);
   	hp->h_addrtype = type;
*** usr/src/sys/conf/newvers.sh.old	Tue Aug 18 17:50:09 2009
--- usr/src/sys/conf/newvers.sh	Tue Aug 18 17:32:57 2009
***************
*** 8,17 ****
   #
   if [ ! -r version ]; then echo 0 > version; fi
   touch version
! echo `cat version` ${USER-root} `pwd` `date` `hostname` | \
   awk ' {
! 	version = $1 + 1; user = $2; host = $10; dir = $3; \
! 	date = $4 " " $5 " " $6 " " $7 " " $8 " " $9;
   }\
   END {
   	printf "char version[] = \"2.11 BSD UNIX #%d: %s\\n", \
--- 8,17 ----
   #
   if [ ! -r version ]; then echo 0 > version; fi
   touch version
! echo `cat version` ${USER-root} `pwd` `hostname` `date` | \
   awk ' {
! 	version = $1 + 1; user = $2; host = $4; dir = $3; \
! 	date = $5 " " $6 " " $7 " " $8 " " $9 " " $10 " " $11;
   }\
   END {
   	printf "char version[] = \"2.11 BSD UNIX #%d: %s\\n", \
*** usr/src/sys/pdpstand/prf.c.old	Tue Aug 18 15:45:40 2009
--- usr/src/sys/pdpstand/prf.c	Wed Aug 19 02:45:36 2009
***************
*** 9,14 ****
--- 9,15 ----
   #include "../machine/cons.h"
   
   #define	KLADDR	((struct dldevice *)0177560)
+ #define LKS ((int *)0177546)
   
   #define	CTRL(x)	('x' & 037)
   
***************
*** 116,121 ****
--- 117,146 ----
   	KLADDR->dlrcsr = DL_RE;
   	while ((KLADDR->dlrcsr & DL_RDONE) == 0)
   		continue;
+ 	c = KLADDR->dlrbuf & 0177;
+ 	if (c=='\r')
+ 		c = '\n';
+ 	return(c);
+ }
+
+ getchar2(t)
+ 	int t;
+ {
+ 	register c;
+ 	int clks, olks;
+
+ 	KLADDR->dlrcsr = DL_RE;
+ 	*LKS = 0;
+ 	clks = 0x80;
+ 	while ((KLADDR->dlrcsr & DL_RDONE) == 0) {
+ 		olks = clks;
+ 		clks = *LKS;
+ 		if (~olks & clks & 0x80) {
+ 			*LKS = 0;
+ 			if ((--t) == 0) return (-1);
+ 		}
+ 		continue;
+ 	}
   	c = KLADDR->dlrbuf & 0177;
   	if (c=='\r')
   		c = '\n';
*** usr/src/sys/conf/boot/raboot.s.old	Mon Aug 17 21:41:34 2009
--- usr/src/sys/conf/boot/raboot.s	Mon Aug 17 22:44:12 2009
***************
*** 1,5 ****
--- 1,9 ----
   /*
    *	SCCS id	@(#)raboot.s	2.0 (2.11BSD)	4/13/91
+  *
+  * Code corrected as per the other primitive mscp drivers
+  * to handles other mscp controllers than DECs.
+  * /bqt - 20090817
    */
   #include "localopts.h"
   
***************
*** 59,65 ****
   
   MSCPSIZE =	64.	/ One MSCP command packet is 64bytes long (need 2)
   
! RASEMAP	=	140000	/ RA controller owner semaphore
   
   RAERR =		100000	/ error bit
   RASTEP1 =	04000	/ step1 has started
--- 63,69 ----
   
   MSCPSIZE =	64.	/ One MSCP command packet is 64bytes long (need 2)
   
! RASEMAP	=	100000	/ RA controller owner semaphore
   
   RAERR =		100000	/ error bit
   RASTEP1 =	04000	/ step1 has started
***************
*** 153,170 ****
   	mov	$RASEMAP,*$ra+RARSPH	/ set mscp semaphores
   	mov	$RASEMAP,*$ra+RACMDH
   	mov	*_bootcsr,r0		/ tap controllers shoulder
! 	mov	$ra+RACMDI,r0
   1:
   	tst	(r0)
! 	beq	1b			/ Wait till command read
! 	clr	(r0)+			/ Tell controller we saw it, ok.
   2:
   	tst	(r0)
! 	beq	2b			/ Wait till response written
   	clr	(r0)			/ Tell controller we got it
   	rts	pc
   
! icons:	RAERR
   	ra+RARING
   	0
   	RAGO
--- 157,176 ----
   	mov	$RASEMAP,*$ra+RARSPH	/ set mscp semaphores
   	mov	$RASEMAP,*$ra+RACMDH
   	mov	*_bootcsr,r0		/ tap controllers shoulder
! 	mov	$ra+RACMDH,r0
   1:
   	tst	(r0)
! 	bmi	1b			/ Wait till command read
! 	mov	$ra+RARSPH,r0
   2:
   	tst	(r0)
! 	bmi	2b			/ Wait till response written
! 	mov	$ra+RACMDI,r0
! 	clr	(r0)+			/ Tell controller we saw it, ok.
   	clr	(r0)			/ Tell controller we got it
   	rts	pc
   
! icons:	RAERR + 033
   	ra+RARING
   	0
   	RAGO
*** usr/src/share/tmac/tmac.an.new.old	Wed Aug 12 09:43:23 2009
--- usr/src/share/tmac/tmac.an.new	Sun Aug 22 03:30:46 2010
***************
*** 20,28 ****
   .if "\nm"10" .ds ]m November
   .if "\nm"11" .ds ]m December
   '	# set the date
! .nr )y \n(yr-100
! .ie \n(yr<100 .ds ]Y \n(yr
! .el .ds ]Y 0\n()y
   '
   .nr )Y \n(yr+1900
   .if n \{.nr m \nm+1
--- 20,28 ----
   .if "\nm"10" .ds ]m November
   .if "\nm"11" .ds ]m December
   '	# set the date
! .nr )y \n(yr%100
! .ie \n()y<10 .ds ]Y 0\n()y
! .el .ds ]Y \n()y
   '
   .nr )Y \n(yr+1900
   .if n \{.nr m \nm+1
***************
*** 53,59 ****
   .de UC
   .if t \{\
   .	ds ]W 3rd Berkeley Distribution
! .	if "\\$1"2" .ds ]W 2rd Berkeley Distribution
   .	if "\\$1"3" .ds ]W 3rd Berkeley Distribution
   .	if "\\$1"4" .ds ]W 4th Berkeley Distribution
   .	if "\\$1"5" .ds ]W 4.2 Berkeley Distribution
--- 53,59 ----
   .de UC
   .if t \{\
   .	ds ]W 3rd Berkeley Distribution
! .	if "\\$1"2" .ds ]W 2nd Berkeley Distribution
   .	if "\\$1"3" .ds ]W 3rd Berkeley Distribution
   .	if "\\$1"4" .ds ]W 4th Berkeley Distribution
   .	if "\\$1"5" .ds ]W 4.2 Berkeley Distribution


-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/



From random832 at fastmail.com  Sat Dec 12 16:16:32 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 12 Dec 2015 01:16:32 -0500
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
References: <20151212045416.GB5686@server.rulingia.com>
 <20151212053357.GA21648@minnie.tuhs.org> <566BB826.2010304@gmail.com>
Message-ID: <m237v819a7.fsf@fastmail.com>

William Pechter <pechter at gmail.com>
writes:

> Warren Toomey wrote:
>> On Sat, Dec 12, 2015 at 03:54:16PM +1100, Peter Jeremy wrote:
>>> Also, I've seen suggestions that there's a 2.11BSD patch later than
>>> 447 but I can't find anything "official" and www.2bsd.com is either
>>> down or inaccessible from all the systems I have access to.  Does
>>> anyone know if 448 or later were released?  And given the issues with
>>> www.2bsd.com would someone be willing to mirror it (assuming we can
>>> got a copy of it)?
>> [ Back to a real keyboard ]. Yes I'd be very happy to mirror 2bsd.com.
>> Does anybody know what's happened to Steven Schultz?
>>
>> Cheers, Warren
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> Last patch is 447 from June 2012.

In the FTP directory I see a 448 file:

Received: by 10.68.220.230 with SMTP id pz6mr12885595pbc.3.1339950326173;
        Sun, 17 Jun 2012 09:25:26 -0700 (PDT)
Path: l9ni61647pbj.0!nntp.google.com!news2.google.com!goblin3!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!newsfeed.Update.UU.SE!news.Update.UU.SE!not-for-mail
From: Johnny Billquist <b... at softjar.se>
Newsgroups: vmsnet.pdp-11,alt.sys.pdp11
Subject: 2BSD patches...
Date: Sun, 17 Jun 2012 18:25:24 +0200
Organization: Update Computer Club
Message-ID: <jrl0dk$et3$1 at Iltempo.Update.UU.SE>
NNTP-Posting-Host: 178-83-31-172.dynamic.hispeed.ch
Mime-Version: 1.0
X-Trace: Iltempo.Update.UU.SE 1339950325 15267 178.83.31.172 (17 Jun 2012 16:25:25 GMT)
X-Complaints-To: newsm... at Update.UU.SE
NNTP-Posting-Date: Sun, 17 Jun 2012 16:25:25 +0000 (UTC)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
Content-Type: multipart/mixed;
 boundary="------------000004000801020107010201"

--------------000004000801020107010201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi. Here is a set of patches to 2BSD, which fixes a number of problems.
Terribly sorry that I don't present it in the same nice format that 
Steven M. Schultz does, but I'll try an explain what this is briefly.

I've named this patch set path #448, as the last known patches to me are 
#447. Apply this patch set after you brought it up to version 447...

Fixes in here:

====

1. Use of non-DEC MSCP controllers improved. Some parts of 2BSD have 
been updated to work with (for example) CMD controllers, but not all 
parts were. This set of patches makes it possible to boot and run with 
the CDU-720, for example, which did not work before.

2. Boot program now automatically boots unless manual intervention on 
console. This looks pretty similar to NetBSD on VAX for example, where a 
countdown is presented at boot time, and the system continues with an 
automatic boot unless aborted. Previously, 2BSD would not autoboot from 
cold start because the reboot-flag was not present at power up.

3. Console terminal made 8-bit clean. On a real PDP-11, the boot 
monitors are 8-bit clean. However, 2BSD previously ran with 7E on the 
console, and there was no way to avoid this for system output. This 
patch makes it all 8-bit clean.

4. The libc resolver code used /etc/hosts if no resolved was available, 
but if one was, it never used the /etc/hosts. This created a peculiar 
effect, especially at bootup, since the resolver couldn't be contacted 
before the network was up, but /etc/hosts were not used, since a correct 
/etc/resolv.conf existed. The order is not possible to select. It will 
first try using the resolver, but if that fails, it now falls back to 
trying /etc/hosts

5. At system build time, the newvers.sh tries to figure out various bits 
and pieces to put into the built file to tell when the kernel was built, 
where and by who. This parsing could fail in various ways because of how 
the date command works with time zones. Fixed by changing how it figures 
out the information and pass it around.

6. The mandoc macros had a Y2K bug, or rather a 2010 bug, in that the 
Y2K bug fix actually only fixed years 2000-2009, and it broke again in 
2010. This patch does a proper fix to the Y2K problem. Also fixed a 
spelling error.

====

As usual, the code might not be pretty, but I've atleast been running it 
myself on several machines for close to two years now, and believe these 
are all workable, and important patches.
Download to your machine.
At the root of the file system run:
$ patch -p0 < patchfile

after this, rebuild the kernel and the boot image. Install the new 
kernel, the new boot, and then rebuild all of userland.

If you have any questions, feel free to send me an email.

This patch set will bring your system up to patch version 448.

     Johnny



> -- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: b... at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol



*** VERSION.orig	Sun Jun 17 17:02:22 2012
--- VERSION	Thu Apr  1 14:17:48 2010
***************
*** 1,5 ****
! Current Patch Level: 447
! Date: December 31, 2008
  
  2.11 BSD
  ============
--- 1,5 ----
! Current Patch Level: 448
! Date: January 5, 2010
  
  2.11 BSD
  ============
***************
*** 62,88 ****
  	112 South Lakeview Canyon Road
  	Thousand Oaks CA 91359
  	sms at wlv.iipo.gtegsc.com
- 
- 	Below is the original VERSION file distributed with 2.10.1BSD
- -----------------------------------------------------------------------
- NOTE --
- 	This is the second release of 2.10BSD; most of the changes
- 	are part of the addition of supervisor space networking in
- 	the kernel, although there are other changes.
- 
- 	To give some idea of the dates involved, distribution of
- 	2.10BSD by the USENIX Assoc. started in fall of 1987.
- 	Distribution of this source started in January of 1989.
- 
- Keith Bostic
- Casey Leedom
- Cyrus Rahman
- Steven Schultz
- 	Steven M. Schultz
- 	Contel Federal Systems
- 	31717 La Tienda Drive
- 	Westlake Village CA 91359
- 	sms at wlv.imsd.contel.com
  
  	Below is the original VERSION file distributed with 2.10.1BSD
  -----------------------------------------------------------------------
--- 62,67 ----
*** usr/src/sys/pdpstand/boot.c.old	Wed Aug 19 00:22:03 2009
--- usr/src/sys/pdpstand/boot.c	Wed Aug 19 02:46:18 2009
***************
*** 172,178 ****
  	 * this is an automatic reboot, otherwise do it the hard way.
  	 */
  	if (checkword != ~bootopts)
! 		bootopts = RB_SINGLE | RB_ASKNAME;
  	j = -1;
  	do {
  		if (bootopts & RB_ASKNAME) {
--- 172,189 ----
  	 * this is an automatic reboot, otherwise do it the hard way.
  	 */
  	if (checkword != ~bootopts)
! 		bootopts = 0;
! 
! 	printf("Press <CR> to boot, or any other key to abort:  ");
! 	for (i=5; i>=0; i--) {
! 		printf("\b%d", i);
! 		j = getchar2(50);
! 		if (j != -1) {
! 			if (j != '\n') bootopts = RB_ASKNAME;
! 			break;
! 		}
! 	}
! 	printf("\n");
  	j = -1;
  	do {
  		if (bootopts & RB_ASKNAME) {
*** usr/src/sys/pdp/cons.c.old	Wed Aug 19 00:25:03 2009
--- usr/src/sys/pdp/cons.c	Tue Aug 18 18:09:57 2009
***************
*** 164,170 ****
  	if (tp->t_flags & (RAW|LITOUT))
  		addr->dlxbuf = c&0xff;
  	else
! 		addr->dlxbuf = c | (partab[c] & 0200);
  	tp->t_state |= TS_BUSY;
  out:
  	splx(s);
--- 164,170 ----
  	if (tp->t_flags & (RAW|LITOUT))
  		addr->dlxbuf = c&0xff;
  	else
! 		addr->dlxbuf = c&0xff; /* | (partab[c] & 0200); /bqt */
  	tp->t_state |= TS_BUSY;
  out:
  	splx(s);
*** usr/src/lib/libc/net/named/gethnamadr.c.orig	Sun Feb 28 03:59:41 2010
--- usr/src/lib/libc/net/named/gethnamadr.c	Thu Apr  1 04:25:45 2010
***************
*** 8,13 ****
--- 8,20 ----
   * may not be used to endorse or promote products derived from this
   * software without specific prior written permission. This software
   * is provided ``as is'' without express or implied warranty.
+  *
+  * 2010-04-01	Johnny Billquist
+  *
+  * Changed code so that /etc/hosts are consulted even if named is
+  * used. This means that if name resolution fails, it will fall back
+  * to using /etc/hosts. Previously it just failed in this case. (But it
+  * did consult /etc/hosts if no named.conf existed.)
   */
  
  #if defined(LIBC_SCCS) && !defined(lint)
***************
*** 227,236 ****
--- 234,247 ----
  		if (_res.options & RES_DEBUG)
  			printf("res_search failed\n");
  #endif
+ #ifdef BQT
  		if (errno == ECONNREFUSED)
+ #endif
  			return (_gethtbyname(name));
+ #ifdef BQT
  		else
  			return ((struct hostent *) NULL);
+ #endif
  	}
  	return (getanswer(&buf, n, 0));
  }
***************
*** 259,269 ****
  		if (_res.options & RES_DEBUG)
  			printf("res_query failed\n");
  #endif
  		if (errno == ECONNREFUSED)
  			hp = _gethtbyaddr(addr, len, type);
! 		return ((struct hostent *) NULL);
! 	}
! 	hp = getanswer(&buf, n, 1);
  	if (hp == NULL)
  		return ((struct hostent *) NULL);
  	hp->h_addrtype = type;
--- 270,285 ----
  		if (_res.options & RES_DEBUG)
  			printf("res_query failed\n");
  #endif
+ #ifdef BQT
  		if (errno == ECONNREFUSED)
+ #endif
  			hp = _gethtbyaddr(addr, len, type);
! #ifdef BQT
! 		else
! 			return ((struct hostent *) NULL);
! #endif
! 	} else
! 		hp = getanswer(&buf, n, 1);
  	if (hp == NULL)
  		return ((struct hostent *) NULL);
  	hp->h_addrtype = type;
*** usr/src/sys/conf/newvers.sh.old	Tue Aug 18 17:50:09 2009
--- usr/src/sys/conf/newvers.sh	Tue Aug 18 17:32:57 2009
***************
*** 8,17 ****
  #
  if [ ! -r version ]; then echo 0 > version; fi
  touch version
! echo `cat version` ${USER-root} `pwd` `date` `hostname` | \
  awk ' {
! 	version = $1 + 1; user = $2; host = $10; dir = $3; \
! 	date = $4 " " $5 " " $6 " " $7 " " $8 " " $9;
  }\
  END {
  	printf "char version[] = \"2.11 BSD UNIX #%d: %s\\n", \
--- 8,17 ----
  #
  if [ ! -r version ]; then echo 0 > version; fi
  touch version
! echo `cat version` ${USER-root} `pwd` `hostname` `date` | \
  awk ' {
! 	version = $1 + 1; user = $2; host = $4; dir = $3; \
! 	date = $5 " " $6 " " $7 " " $8 " " $9 " " $10 " " $11;
  }\
  END {
  	printf "char version[] = \"2.11 BSD UNIX #%d: %s\\n", \
*** usr/src/sys/pdpstand/prf.c.old	Tue Aug 18 15:45:40 2009
--- usr/src/sys/pdpstand/prf.c	Wed Aug 19 02:45:36 2009
***************
*** 9,14 ****
--- 9,15 ----
  #include "../machine/cons.h"
  
  #define	KLADDR	((struct dldevice *)0177560)
+ #define LKS ((int *)0177546)
  
  #define	CTRL(x)	('x' & 037)
  
***************
*** 116,121 ****
--- 117,146 ----
  	KLADDR->dlrcsr = DL_RE;
  	while ((KLADDR->dlrcsr & DL_RDONE) == 0)
  		continue;
+ 	c = KLADDR->dlrbuf & 0177;
+ 	if (c=='\r')
+ 		c = '\n';
+ 	return(c);
+ }
+ 
+ getchar2(t)
+ 	int t;
+ {
+ 	register c;
+ 	int clks, olks;
+ 
+ 	KLADDR->dlrcsr = DL_RE;
+ 	*LKS = 0;
+ 	clks = 0x80;
+ 	while ((KLADDR->dlrcsr & DL_RDONE) == 0) {
+ 		olks = clks;
+ 		clks = *LKS;
+ 		if (~olks & clks & 0x80) {
+ 			*LKS = 0;
+ 			if ((--t) == 0) return (-1);
+ 		}
+ 		continue;
+ 	}
  	c = KLADDR->dlrbuf & 0177;
  	if (c=='\r')
  		c = '\n';
*** usr/src/sys/conf/boot/raboot.s.old	Mon Aug 17 21:41:34 2009
--- usr/src/sys/conf/boot/raboot.s	Mon Aug 17 22:44:12 2009
***************
*** 1,5 ****
--- 1,9 ----
  /*
   *	SCCS id	@(#)raboot.s	2.0 (2.11BSD)	4/13/91
+  *
+  * Code corrected as per the other primitive mscp drivers
+  * to handles other mscp controllers than DECs.
+  * /bqt - 20090817
   */
  #include "localopts.h"
  
***************
*** 59,65 ****
  
  MSCPSIZE =	64.	/ One MSCP command packet is 64bytes long (need 2)
  
! RASEMAP	=	140000	/ RA controller owner semaphore
  
  RAERR =		100000	/ error bit 
  RASTEP1 =	04000	/ step1 has started
--- 63,69 ----
  
  MSCPSIZE =	64.	/ One MSCP command packet is 64bytes long (need 2)
  
! RASEMAP	=	100000	/ RA controller owner semaphore
  
  RAERR =		100000	/ error bit 
  RASTEP1 =	04000	/ step1 has started
***************
*** 153,170 ****
  	mov	$RASEMAP,*$ra+RARSPH	/ set mscp semaphores
  	mov	$RASEMAP,*$ra+RACMDH
  	mov	*_bootcsr,r0		/ tap controllers shoulder
! 	mov	$ra+RACMDI,r0
  1:
  	tst	(r0)
! 	beq	1b			/ Wait till command read
! 	clr	(r0)+			/ Tell controller we saw it, ok.
  2:
  	tst	(r0)
! 	beq	2b			/ Wait till response written
  	clr	(r0)			/ Tell controller we got it
  	rts	pc
  
! icons:	RAERR
  	ra+RARING
  	0
  	RAGO
--- 157,176 ----
  	mov	$RASEMAP,*$ra+RARSPH	/ set mscp semaphores
  	mov	$RASEMAP,*$ra+RACMDH
  	mov	*_bootcsr,r0		/ tap controllers shoulder
! 	mov	$ra+RACMDH,r0
  1:
  	tst	(r0)
! 	bmi	1b			/ Wait till command read
! 	mov	$ra+RARSPH,r0
  2:
  	tst	(r0)
! 	bmi	2b			/ Wait till response written
! 	mov	$ra+RACMDI,r0
! 	clr	(r0)+			/ Tell controller we saw it, ok.
  	clr	(r0)			/ Tell controller we got it
  	rts	pc
  
! icons:	RAERR + 033
  	ra+RARING
  	0
  	RAGO
*** usr/src/share/tmac/tmac.an.new.old	Wed Aug 12 09:43:23 2009
--- usr/src/share/tmac/tmac.an.new	Sun Aug 22 03:30:46 2010
***************
*** 20,28 ****
  .if "\nm"10" .ds ]m November
  .if "\nm"11" .ds ]m December
  '	# set the date
! .nr )y \n(yr-100
! .ie \n(yr<100 .ds ]Y \n(yr
! .el .ds ]Y 0\n()y
  '
  .nr )Y \n(yr+1900
  .if n \{.nr m \nm+1
--- 20,28 ----
  .if "\nm"10" .ds ]m November
  .if "\nm"11" .ds ]m December
  '	# set the date
! .nr )y \n(yr%100
! .ie \n()y<10 .ds ]Y 0\n()y
! .el .ds ]Y \n()y
  '
  .nr )Y \n(yr+1900
  .if n \{.nr m \nm+1
***************
*** 53,59 ****
  .de UC
  .if t \{\
  .	ds ]W 3rd Berkeley Distribution
! .	if "\\$1"2" .ds ]W 2rd Berkeley Distribution
  .	if "\\$1"3" .ds ]W 3rd Berkeley Distribution
  .	if "\\$1"4" .ds ]W 4th Berkeley Distribution
  .	if "\\$1"5" .ds ]W 4.2 Berkeley Distribution
--- 53,59 ----
  .de UC
  .if t \{\
  .	ds ]W 3rd Berkeley Distribution
! .	if "\\$1"2" .ds ]W 2nd Berkeley Distribution
  .	if "\\$1"3" .ds ]W 3rd Berkeley Distribution
  .	if "\\$1"4" .ds ]W 4th Berkeley Distribution
  .	if "\\$1"5" .ds ]W 4.2 Berkeley Distribution



From random832 at fastmail.com  Sat Dec 12 16:17:36 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 12 Dec 2015 01:17:36 -0500
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
References: <20151212045416.GB5686@server.rulingia.com>
 <20151212053357.GA21648@minnie.tuhs.org> <566BB826.2010304@gmail.com>
Message-ID: <m2y4d0yyv3.fsf@fastmail.com>

William Pechter <pechter at gmail.com>
writes:

> Warren Toomey wrote:
> Last patch is 447 from June 2012.

Oops, I just posted the same patch again, since I only saw this and
didn't see that the one you had actually posted was #448. Sorry for the
wasted space.



From random832 at fastmail.com  Sat Dec 12 16:25:43 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 12 Dec 2015 01:25:43 -0500
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
References: <20151212045416.GB5686@server.rulingia.com>
 <721CCD91-F2D5-4D22-8D54-EE939112902A@tuhs.org>
Message-ID: <m2poycyyhk.fsf@fastmail.com>

Warren Toomey writes:
> We got the 1st Edition kernel up a while back and it had no groups.
> Look for unix-jun72 on Github.

Did anyone else ever try getting the v2/v3 kernel (i.e. the two
images on s1-bits, which I was able to determine is an init tape
as described in V3/man/man8/bproc.8) running? I remember getting
it working for myself in single-user mode, but ran out of space
trying to extract s2-bits (presumably the matching /bin-/etc-
/lib tape), couldn't figure out how to make or mount a second
filesystem (or if it was possible at all), and there didn't seem
to be any interest here at the time, and now I can't remember
what I did to get as far as I did.

I think it's the oldest extant binary distribution the archive
has.



From cowan at mercury.ccil.org  Sat Dec 12 15:44:04 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Sat, 12 Dec 2015 00:44:04 -0500
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <20151212045416.GB5686@server.rulingia.com>
References: <20151212045416.GB5686@server.rulingia.com>
Message-ID: <20151212054404.GB15143@mercury.ccil.org>

Peter Jeremy scripsit:

> Also, I've seen suggestions that there's a 2.11BSD patch later than
> 447 but I can't find anything "official" and www.2bsd.com is either
> down or inaccessible from all the systems I have access to.  Does
> anyone know if 448 or later were released?  And given the issues with
> www.2bsd.com would someone be willing to mirror it (assuming we can
> got a copy of it)?

Looking at the Internet Archive's copy of 2bsd.com led me to
<ftp://ftp.wx.gd-ais.com/pub/2.11BSD>, which indeed has patch 448 in it,
dated 2012-07-15 (my grandson's fourth birthday, by a meaningless coinkydink).
It contains 6 sub-patches.  Mirroring the whole FTP site would be a Good Thing.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
The Imperials are decadent, 300 pound free-range chickens (except they have
teeth, arms instead of wings, and dinosaurlike tails).  --Elyse Grasso


From wkt at tuhs.org  Sat Dec 12 16:33:17 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 12 Dec 2015 16:33:17 +1000
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <m2poycyyhk.fsf@fastmail.com>
References: <20151212045416.GB5686@server.rulingia.com>
 <721CCD91-F2D5-4D22-8D54-EE939112902A@tuhs.org>
 <m2poycyyhk.fsf@fastmail.com>
Message-ID: <20151212063317.GA5670@minnie.tuhs.org>

On Sat, Dec 12, 2015 at 01:25:43AM -0500, Random832 wrote:
> Warren Toomey writes:
> > We got the 1st Edition kernel up a while back and it had no groups.
> > Look for unix-jun72 on Github.
> 
> Did anyone else ever try getting the v2/v3 kernel (i.e. the two
> images on s1-bits, which I was able to determine is an init tape
> as described in V3/man/man8/bproc.8) running? I remember getting
> it working for myself in single-user mode, but ran out of space
> trying to extract s2-bits (presumably the matching /bin-/etc-
> /lib tape), couldn't figure out how to make or mount a second
> filesystem (or if it was possible at all), and there didn't seem
> to be any interest here at the time, and now I can't remember
> what I did to get as far as I did.

We used the binaries on the s2-bits tape as the binaries for the
v1 kernel. We had to tweak things a bit so that we could run the
first C compilers.

It's all bundled up at https://github.com/DoctorWkt/unix-jun72

Cheers, Warren


From wkt at tuhs.org  Sat Dec 12 16:38:27 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 12 Dec 2015 16:38:27 +1000
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <566BB826.2010304@gmail.com>
References: <20151212045416.GB5686@server.rulingia.com>
 <20151212053357.GA21648@minnie.tuhs.org>
 <566BB826.2010304@gmail.com>
Message-ID: <20151212063827.GA5920@minnie.tuhs.org>

On Sat, Dec 12, 2015 at 01:01:10AM -0500, William Pechter wrote:
> I can get to the site just fine... pasted the patch below if it helps
> anyone.

I can't get to [ftp|www|moe].2bsd.com, it seems to connect but then
waits for about 30 seconds and then dies.

If someone else can mirror the site, I'd be happy to host the mirror
on www.tuhs.org.

Cheers, Warren


From jacob.ritorto at gmail.com  Sat Dec 12 17:11:35 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Sat, 12 Dec 2015 02:11:35 -0500
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <20151212063827.GA5920@minnie.tuhs.org>
References: <20151212045416.GB5686@server.rulingia.com>
 <20151212053357.GA21648@minnie.tuhs.org>
 <566BB826.2010304@gmail.com>
 <20151212063827.GA5920@minnie.tuhs.org>
Message-ID: <CAHYQbfDoTcnAvistfs_6CcOPSucdh3JzZXF8veFuubzuZXzN8w@mail.gmail.com>

Steven's been setting his firewall rather aggressively lately, it seems.  I
contacted him about it last year and he happily allowed my IP.  If you
don't have his address handy, you're welcome to contact me off-list..

regards,
jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151212/5b767894/attachment.html>

From peter at rulingia.com  Sat Dec 12 17:26:13 2015
From: peter at rulingia.com (Peter Jeremy)
Date: Sat, 12 Dec 2015 18:26:13 +1100
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <721CCD91-F2D5-4D22-8D54-EE939112902A@tuhs.org>
References: <20151212045416.GB5686@server.rulingia.com>
 <721CCD91-F2D5-4D22-8D54-EE939112902A@tuhs.org>
Message-ID: <20151212072613.GC5686@server.rulingia.com>

On 2015-Dec-12 15:30:59 +1000, Warren Toomey <wkt at tuhs.org> wrote:
>We got the 1st Edition kernel up a while back and it had no groups. Look for unix-jun72 on Github.

Thanks.  For anyone else trying to build it from DoctorWkt/unix-jun72, the
attached fix is important.

-- 
Peter Jeremy
-------------- next part --------------
diff --git a/build/Makefile b/build/Makefile
index 7b23f41..c761596 100644
--- a/build/Makefile
+++ b/build/Makefile
@@ -122,6 +122,7 @@ root usr protofs : $(ALLSRCS) init.0405 sh.0405
 	@cp $(KSRCS) usr/sys
 	@cp init.0405 root/etc/init
 	@cp sh.0405 root/bin/sh
+	@mkdir -p root/usr
 	@touch protofs
 
 # build filesystem images
@@ -143,8 +144,9 @@ tape : protofs
 
 install : rf0.dsk rk0.dsk
 	@echo Installing...
+	@mkdir -p ../images
 	@cp rf0.dsk rk0.dsk ../boot/m792low.load ../images
-	
+
 # clean intermediate files
 clean :
 	rm -f $(CLEANSRCS) cleansrc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151212/7d4166f3/attachment.sig>

From wkt at tuhs.org  Sat Dec 12 18:20:45 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 12 Dec 2015 18:20:45 +1000
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <20151212072613.GC5686@server.rulingia.com>
References: <20151212045416.GB5686@server.rulingia.com>
 <721CCD91-F2D5-4D22-8D54-EE939112902A@tuhs.org>
 <20151212072613.GC5686@server.rulingia.com>
Message-ID: <20151212082045.GA10167@minnie.tuhs.org>

On Sat, Dec 12, 2015 at 06:26:13PM +1100, Peter Jeremy wrote:
> Thanks.  For anyone else trying to build it from DoctorWkt/unix-jun72, the
> attached fix is important.

Thanks Peter. I'll update the git respository soon.
	Warren


From random832 at fastmail.com  Sat Dec 12 18:28:48 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 12 Dec 2015 03:28:48 -0500
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
References: <20151212045416.GB5686@server.rulingia.com>
 <721CCD91-F2D5-4D22-8D54-EE939112902A@tuhs.org>
 <m2poycyyhk.fsf@fastmail.com> <20151212063317.GA5670@minnie.tuhs.org>
Message-ID: <m2d1uc83zz.fsf@fastmail.com>

Warren Toomey writes:
> We used the binaries on the s2-bits tape as the binaries for the
> v1 kernel. We had to tweak things a bit so that we could run the
> first C compilers.

I'm talking about the s1-bits tape, though. It contains two
binary kernels (the warm/cold ones described in the manpages),
as raw data in the sections that aren't mentioned in the Readme
file. (i.e. the first 50176 bytes).

I figured this out by analyzing the file and noticing it
contained copies of /etc/init, getty, /bin/chmod, date, login,
mkdir, sh, tap, and ls, which is similar to the lists of
programs mentioned in:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/man/man7/boot.7
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V3/man/man8/bproc.8

I worked out that the rest of the structure also matched, though
I think the sizes were different.



From bqt at update.uu.se  Sat Dec 12 21:31:41 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Sat, 12 Dec 2015 12:31:41 +0100
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <mailman.1.1449901013.3292.tuhs@minnie.tuhs.org>
References: <mailman.1.1449901013.3292.tuhs@minnie.tuhs.org>
Message-ID: <566C059D.5000302@update.uu.se>

On 2015-12-12 07:16, William Pechter<pechter at gmail.com> wrote:
>
> Warren Toomey wrote:
>> >On Sat, Dec 12, 2015 at 03:54:16PM +1100, Peter Jeremy wrote:
>>> >>Also, I've seen suggestions that there's a 2.11BSD patch later than
>>> >>447 but I can't find anything "official" andwww.2bsd.com  is either
>>> >>down or inaccessible from all the systems I have access to.  Does
>>> >>anyone know if 448 or later were released?  And given the issues with
>>> >>www.2bsd.com  would someone be willing to mirror it (assuming we can
>>> >>got a copy of it)?
>> >[ Back to a real keyboard ]. Yes I'd be very happy to mirror 2bsd.com.
>> >Does anybody know what's happened to Steven Schultz?
>> >
>> >Cheers, Warren
>> >_______________________________________________
>> >TUHS mailing list
>> >TUHS at minnie.tuhs.org
>> >http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> Last patch is 447 from June 2012.

Uh. No. 447 is from December 31, 2008.
See /VERSION in the patch set, which holds the patch version and date 
for the patch.

And I did an unofficial 448 in 2010, which I have tried to spread, and 
which I suspect is the patch referred to above...

> I can get to the site just fine... pasted the patch below if it helps
> anyone.
> I haven't heard anything about him.  Haven't worked at the same company
> since the early 1990's...

I used to talk with him a lot in the past, but have not been able to 
raise him, and haven't seen anything from him in over 5 years... No idea 
what he is up to nowadays...

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From bqt at update.uu.se  Sat Dec 12 21:25:00 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Sat, 12 Dec 2015 12:25:00 +0100
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <mailman.17.1449898266.27456.tuhs@minnie.tuhs.org>
References: <mailman.17.1449898266.27456.tuhs@minnie.tuhs.org>
Message-ID: <566C040C.6040705@update.uu.se>

On 2015-12-12 06:31, Peter Jeremy<peter at rulingia.com> wrote:
> Also, I've seen suggestions that there's a 2.11BSD patch later than
> 447 but I can't find anything "official" andwww.2bsd.com  is either
> down or inaccessible from all the systems I have access to.  Does
> anyone know if 448 or later were released?  And given the issues with
> www.2bsd.com  would someone be willing to mirror it (assuming we can
> got a copy of it)?

Yes, I did 448. Various bits and pieces that were fixed there, but 
unfortunately I haven't managed to reach Steve to get it officially 
sanctioned.

I've passed it out a few times, but there is no canonical place for it.

You can find it at ftp://ftp.update.uu.se/pub/pdp11/2.11bsd/

Feel free to pass that information around.

Things fixed in there:
. Added a timeout to boot prompt for automatic boot
. Made console 8-bit clean
. Changed gethnamadr to fall back to /etc/hosts if dns fails.
. Fixed kernel build process to get version and date properly into kernel.
. Fixed raboot to work on non-DEC mscp controllers
. Fixed tmac macro to work correctly after 2009.
. Fixed a couple of documentation errors.


Essentially small issues that bothered me as I was running on an 11/84 
with a CMD controller a few years ago. A system on which I also booted 
other OSes, which is why the 8-bit clean issue also bothered me.
(Also was really surprised at the ugly Y2K fix someone had done with 
tmac, which failed again in 2010).

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From doug at cs.dartmouth.edu  Sun Dec 13 03:17:48 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 12 Dec 2015 12:17:48 -0500
Subject: [TUHS] TUHS] why does tar have the tape device hard coded into
 it and why is it mt1 instead of mt0
Message-ID: <201512121717.tBCHHm5W064050@tahoe.cs.Dartmouth.EDU>

Forget that I said, "I think that tar was written by Chuck Haley or Greg Chesson".
Ken confirms that he wrote it, for dectape.

Doug


From mah at mhorton.net  Sun Dec 13 04:54:24 2015
From: mah at mhorton.net (Mary Ann Horton)
Date: Sat, 12 Dec 2015 10:54:24 -0800
Subject: [TUHS] why does tar have the tape device hard coded into it and
 why is it mt1 instead of mt0
In-Reply-To: <201512120209.tBC2930f007838@coolidge.cs.Dartmouth.EDU>
References: <201512120209.tBC2930f007838@coolidge.cs.Dartmouth.EDU>
Message-ID: <566C6D60.40205@mhorton.net>

Yeah, I just can't imagine using tar with the f option.  Even back in 
the day when I was writing 9 track magtapes with tar, it would be 
something like
     tar cvfb /dev/rmt0 10 .
to get tape blocks bigger than 512 bytes.  But we never had dectapes and 
I think they did their own blocking.

     Mary Ann

On 12/11/2015 06:09 PM, Doug McIlroy wrote:
>> I have no memory of why Ken used mt1 not mt0.   Doug may know.
> I don't know either. Come to think of it, I can't remember ever
> using tar without option -f. Direct machine-to-machine trasfer,
> e.g. by uucp, took a lot of business away from magtape soon
> after tar was introduced. Incidentally, I think tar was written
> by Chuck Haley or Greg Chesson, not Ken.
>
> Doug
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs



From aps at ieee.org  Sun Dec 13 05:58:06 2015
From: aps at ieee.org (Armando Stettner)
Date: Sat, 12 Dec 2015 11:58:06 -0800
Subject: [TUHS] why does tar have the tape device hard coded into it and
	why is it mt1 instead of mt0
In-Reply-To: <566C6D60.40205@mhorton.net>
References: <201512120209.tBC2930f007838@coolidge.cs.Dartmouth.EDU>
 <566C6D60.40205@mhorton.net>
Message-ID: <5C9EF0B4-EE0C-4C08-9CB0-9D00D1488D2C@ieee.org>

I recall using the -f option with the - for direction to/from  to move large hierarchies around and preserve metadata including creation/modify dats, owner/group, etc.

Sent from my iPad

> On Dec 12, 2015, at 10:54, Mary Ann Horton <mah at mhorton.net> wrote:
> 
> Yeah, I just can't imagine using tar with the f option.  Even back in the day when I was writing 9 track magtapes with tar, it would be something like
>    tar cvfb /dev/rmt0 10 .
> to get tape blocks bigger than 512 bytes.  But we never had dectapes and I think they did their own blocking.
> 
>    Mary Ann
> 
> On 12/11/2015 06:09 PM, Doug McIlroy wrote:
>>> I have no memory of why Ken used mt1 not mt0.   Doug may know.
>> I don't know either. Come to think of it, I can't remember ever
>> using tar without option -f. Direct machine-to-machine trasfer,
>> e.g. by uucp, took a lot of business away from magtape soon
>> after tar was introduced. Incidentally, I think tar was written
>> by Chuck Haley or Greg Chesson, not Ken.
>> 
>> Doug
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> 


From clemc at ccc.com  Sun Dec 13 06:13:33 2015
From: clemc at ccc.com (Clem Cole)
Date: Sat, 12 Dec 2015 15:13:33 -0500
Subject: [TUHS] why does tar have the tape device hard coded into it and
 why is it mt1 instead of mt0
In-Reply-To: <566C6D60.40205@mhorton.net>
References: <201512120209.tBC2930f007838@coolidge.cs.Dartmouth.EDU>
 <566C6D60.40205@mhorton.net>
Message-ID: <CAC20D2PexoEe=zuCYZm9Xi_ttLbATzm0XUiaCuY2migPd0FgBw@mail.gmail.com>

Interesting  memories ... IIRC: workstations were really what caused /dev/*mt*
to stop being a standard name, so not screwing it down and using the -f
option made sense. But for a long time, since it was less typing on the 11s
and Vaxen, I would do:
           tar cvb0 20 mumble...
However, once we moved to the world of networking, the -f option became
important to me.
*i.e. *   tar cvf - mumble | rmt hosts ...

Also, the DEC drives had better buffering.  Large buffers became really
important with streaming versions of 9-track and of course for the later
QIC tapes.  So blocking became even more important and I quit doing that
function with tar itself and started to pipe tar through dd to do the
blocking to get really large blocks (like 256K or 1M).   Also, tools
appeared like "double dd" (aka ddd(1)) program that originally used a two
processes and pipe to coordinates the writes so that we could stream a
Cipher drive on a 10Mhz 68K (Masscomp box).

[Note to Will - you might to google for the original ddd or talk to me
offline, I bet I have it somewhere.  Its an interesting program to analyze
if you really want to get some insight on what you could do with UNIX even
on a "slow" computer by today's standards and without a lot of today's
fancy API's].


tjt rewrote dump(1) on RTU to use AST's and may have hacked dd too (I've
lost that version I fear).  In the mid, 80's I rewrote ddd to use threads
once kernel support for threading became available and I still use that
version today when I mess with tapes (which I do less and less, but have
been known to do when trying to recover old tapes).

Clem

On Sat, Dec 12, 2015 at 1:54 PM, Mary Ann Horton <mah at mhorton.net> wrote:

> Yeah, I just can't imagine using tar with the f option.  Even back in the
> day when I was writing 9 track magtapes with tar, it would be something like
>     tar cvfb /dev/rmt0 10 .
> to get tape blocks bigger than 512 bytes.  But we never had dectapes and I
> think they did their own blocking.
>
>     Mary Ann
>
>
> On 12/11/2015 06:09 PM, Doug McIlroy wrote:
>
>> I have no memory of why Ken used mt1 not mt0.   Doug may know.
>>>
>> I don't know either. Come to think of it, I can't remember ever
>> using tar without option -f. Direct machine-to-machine trasfer,
>> e.g. by uucp, took a lot of business away from magtape soon
>> after tar was introduced. Incidentally, I think tar was written
>> by Chuck Haley or Greg Chesson, not Ken.
>>
>> Doug
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
>>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151212/8d2eebff/attachment.html>

From dds at aueb.gr  Sun Dec 13 06:17:13 2015
From: dds at aueb.gr (Diomidis Spinellis)
Date: Sat, 12 Dec 2015 22:17:13 +0200
Subject: [TUHS] why does tar have the tape device hard coded into it and
 why is it mt1 instead of mt0
In-Reply-To: <201512121717.tBCHHm5W064050@tahoe.cs.Dartmouth.EDU>
References: <201512121717.tBCHHm5W064050@tahoe.cs.Dartmouth.EDU>
Message-ID: <566C80C9.2000300@aueb.gr>

Interesting! Chuck Haley is also listed as the author of tar in "Life
with Unix" p. 31 (Libes and Resler, Prentice Hall,  1989).  I wonder
where that piece of misinformation came from and what other errors are
in the book.

Anyway, I corrected tar's authorship in the Unix history Git repo
https://github.com/dspinellis/unix-history-make/commit/d4d153afaa1b0e27deb678db40d7e3879d1a4e3d

Diomidis

On 12/12/2015 19:17, Doug McIlroy wrote:
> Forget that I said, "I think that tar was written by Chuck Haley or Greg Chesson".
> Ken confirms that he wrote it, for dectape.
> 
> Doug
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
> 



From cowan at mercury.ccil.org  Sun Dec 13 06:57:27 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Sat, 12 Dec 2015 15:57:27 -0500
Subject: [TUHS] why does tar have the tape device hard coded into it and
 why is it mt1 instead of mt0
In-Reply-To: <566C6D60.40205@mhorton.net>
References: <201512120209.tBC2930f007838@coolidge.cs.Dartmouth.EDU>
 <566C6D60.40205@mhorton.net>
Message-ID: <20151212205727.GE15143@mercury.ccil.org>

Mary Ann Horton scripsit:

> But we never had dectapes and I think they did their own blocking.

Indeed.  A DECtape (aka microtape) was logically speaking a floppy disk
sliced into cylinders and then concatenated.  As a result it was possible
to rewrite any block without affecting later blocks, something not true
of conventional ("macro") tape.

My first system, a PDP-8/M, used a single DECtape drive as its system
"disk"; the second system, a PDP-8/A, used an 8-inch floppy.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Don't be so humble.  You're not that great.
        --Golda Meir


From will.senn at gmail.com  Sun Dec 13 07:53:54 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 12 Dec 2015 15:53:54 -0600
Subject: [TUHS] tar on v6 not creating directories on v6
Message-ID: <566C9772.9040508@gmail.com>

All,

I'm stuck trying to determine what is going on with v6tar on v6. It 
seems to work ok for files, but gets confused with subdirectories. I set 
up a test folder structure:

t/dmr/vs.c
t/dmr/vt.c
t/ken/prf.c

then I created a tarball
tar cvf t.tar t

then I tried to extract the tarball. It made a mess:
# tar xvf t.tar

Tar: blocksize = 17
y ?
tar: t/ken/prf.c - cannot create
y ?
y ?
tar: t/dmr/vs.c - cannot create
y ?
y ?
tar: t/dmr/vt.c - cannot create

That was ugly and all of it was output. What exactly did I wind up with?:
# ls -l
total 19
drwxrwxrwx  2 root       32 Oct 10 12:54 y
-rw-rw-rw-  1 root     8704 Oct 10 12:54 t.tar

Ugh. Probably don't need the y directory...
# rmdir y
y ?
# ls y
y not found

Wow! It appears that I am unable to delete the y directory or list it by 
name. That can't be good. Any ideas of how to remove this directory are 
welcome.

Not to be deterred by one small failure, I copied the same tarball over 
to v7 on the off chance that maybe v6tar isn't really for v6, but more 
for moving files(and directories) over to v7 as Haley and Ritchie 
describe, and lo and behold tar on v7 is able to extract both files and 
directories from the same tarball without any trouble:

# tar xvf t.tar
Tar: blocksize = 17
x t/ken/prf.c, 2301 bytes, 5 tape blocks
x t/dmr/vs.c, 1543 bytes, 4 tape blocks
x t/dmr/vt.c, 834 bytes, 2 tape blocks

# ls -l
total 18
drwxrwxr-x 4 root       64 Dec 31 19:27 t
-rw-rw-r-- 1 root     8704 Dec 31 19:27 t.tar

# ls t
dmr
ken

# ls t/dmr
vs.c
vt.c

# ls t/ken
prf.c

Interesting. After looking at the tar source, the question marks in the 
output appear to be coming from somewhere outside of tar (perhaps mkdir 
or chown?). Also, the "cannot create" message comes from the following 
snippet of the tar source, which looks reasonable:
...
if ((ofile = creat(dblock.dbuf.name, stbuf.st_mode & 07777)) < 0) {
                         fprintf(stderr, "tar: %s - cannot create\n", 
dblock.dbuf.name);
...

I think this error is simply an effect related to the failure to create 
the necessary directories properly. The code to do that looks pretty 
straightforward:
checkdir(name)
register char *name;
{
         register char *cp;
         int i;
         for (cp = name; *cp; cp++) {
                 if (*cp == '/') {
                         *cp = '\0';
                         if (access(name, 01) < 0) {
                                 if (fork() == 0) {
                                         execl("/bin/mkdir", "mkdir", 
name, 0);
                                         execl("/usr/bin/mkdir", 
"mkdir", name, 0);
                                         fprintf(stderr, "tar: cannot 
find mkdir!\n");
                                         done(0);
                                 }
                                 while (wait(&i) >= 0);
                                 chown(name, stbuf.st_uid, stbuf.st_gid);
                         }
                         *cp = '/';
                 }
         }
}

I speculate that chown is causing the "?" to be displayed. Is it safe 
enough for me to add printf statements around this code to see what's 
going on, or is there a better approach?

Thanks,

Will



From peter at rulingia.com  Sun Dec 13 08:23:58 2015
From: peter at rulingia.com (Peter Jeremy)
Date: Sun, 13 Dec 2015 09:23:58 +1100
Subject: [TUHS] tar on v6 not creating directories on v6
In-Reply-To: <566C9772.9040508@gmail.com>
References: <566C9772.9040508@gmail.com>
Message-ID: <20151212222358.GD5686@server.rulingia.com>

On 2015-Dec-12 15:53:54 -0600, Will Senn <will.senn at gmail.com> wrote:
>That was ugly and all of it was output. What exactly did I wind up with?:
># ls -l
>total 19
>drwxrwxrwx  2 root       32 Oct 10 12:54 y
>-rw-rw-rw-  1 root     8704 Oct 10 12:54 t.tar
>
>Ugh. Probably don't need the y directory...
># rmdir y
>y ?
># ls y
>y not found

Presumably, it's not 'y' but has some non-printable characters in it.
You could try "od -c ." to see what the entry actually is, or move
t.tar out of the way and "rm -r" remove the next level up.

>I think this error is simply an effect related to the failure to create 
>the necessary directories properly.

If you run "mkdir foo" from the shell, does it work properly?  That will
let you split between the problem being in tar and the problem being in
mkdir.  Adding some printf()s to checkdir() seems a reasonable step.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151213/50e0a081/attachment.sig>

From lyndon at orthanc.ca  Sun Dec 13 08:44:35 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sat, 12 Dec 2015 14:44:35 -0800
Subject: [TUHS] why does tar have the tape device hard coded into it and
	why is it mt1 instead of mt0
In-Reply-To: <CAC20D2PexoEe=zuCYZm9Xi_ttLbATzm0XUiaCuY2migPd0FgBw@mail.gmail.com>
References: <201512120209.tBC2930f007838@coolidge.cs.Dartmouth.EDU>
 <566C6D60.40205@mhorton.net>
 <CAC20D2PexoEe=zuCYZm9Xi_ttLbATzm0XUiaCuY2migPd0FgBw@mail.gmail.com>
Message-ID: <22F1828F-F9D6-4AEA-850F-E14FF919B114@orthanc.ca>


On Dec 12, 2015, at 12:13 PM, Clem Cole <clemc at ccc.com> wrote:

> tjt rewrote dump(1) on RTU to use AST's and may have hacked dd too (I've lost that version I fear).  In the mid, 80's I rewrote ddd to use threads once kernel support for threading became available and I still use that version today when I mess with tapes (which I do less and less, but have been known to do when trying to recover old tapes).

Anyone recall when pump came into play?  What that a Plan9 thing?, or did it originate in Research UNIX.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151212/ac1e027e/attachment.sig>

From will.senn at gmail.com  Sun Dec 13 09:10:11 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 12 Dec 2015 17:10:11 -0600
Subject: [TUHS] tar on v6 not creating directories on v6
In-Reply-To: <20151212222358.GD5686@server.rulingia.com>
References: <566C9772.9040508@gmail.com>
 <20151212222358.GD5686@server.rulingia.com>
Message-ID: <566CA953.3020207@gmail.com>



On 12/12/15 4:23 PM, Peter Jeremy wrote:
> On 2015-Dec-12 15:53:54 -0600, Will Senn <will.senn at gmail.com> wrote:
>> That was ugly and all of it was output. What exactly did I wind up with?:
>> # ls -l
>> total 19
>> drwxrwxrwx  2 root       32 Oct 10 12:54 y
>> -rw-rw-rw-  1 root     8704 Oct 10 12:54 t.tar
>>
>> Ugh. Probably don't need the y directory...
>> # rmdir y
>> y ?
>> # ls y
>> y not found
> Presumably, it's not 'y' but has some non-printable characters in it.
> You could try "od -c ." to see what the entry actually is, or move
> t.tar out of the way and "rm -r" remove the next level up.
>
It looks like you are correct about it not being 'y':

# od -c .
0000000  I \?  . \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000020 \? \0  .  . \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000040  K \?  t  .  t  a  r \0 \0 \0 \0 \0 \0 \0 \0 \0
0000060  N \? \? \? \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000100


I moved t.tar out and then tried rm -r, it complained (t is the parent):
# rm -r t
No match

I don't think rm -r will delete directories, but only the files in the 
directory.

>> I think this error is simply an effect related to the failure to create
>> the necessary directories properly.
> If you run "mkdir foo" from the shell, does it work properly?  That will
> let you split between the problem being in tar and the problem being in
> mkdir.  Adding some printf()s to checkdir() seems a reasonable step.
>
Yes, mkdir foo works. I'll add the print statements.

Thanks,

will



From norman at oclsc.org  Sun Dec 13 11:41:48 2015
From: norman at oclsc.org (Norman Wilson)
Date: Sat, 12 Dec 2015 20:41:48 -0500 (EST)
Subject: [TUHS] why does tar have the tape device hard coded into it and
 why is it mt1 instead of mt0
Message-ID: <20151213014148.5BBF5440AE@lignose.oclsc.org>

/dev/makefile on the V7 distribution tape (or at least the
unpacked image I have that I believe to be same) says:

ht:
	/etc/mknod mt0 b 7 64
	/etc/mknod mt1 b 7 0
	/etc/mknod rmt0 c 15 64
	/etc/mknod rmt1 c 15 0
	/etc/mknod nrmt0 c 15 192
	/etc/mknod nrmt1 c 15 128
	chmod go+w mt0 mt1 rmt0 rmt1 nrmt0 nrmt1

According to /usr/sys/dev/ht.c, the minor device
number was used as follows:

minor(dev) & 07		slave unit number
minor(dev) & 070	controller unit number
minor(dev) & 0100	tape density: set == 800 bpi, clear 1600
minor(dev) & 0200	no-rewind flag

It takes some digging in the source code (and the PDP-11
Peripherals Handbook) to understand all this numerology.
In most of the code, minor(dev) & 077 is just treated as
a unit number (fair enough).  The use of 0200 appears only
as a magic number in htopen; that of 0100 only as a magic
number in htstart, and that only implied: the test is
not minor(dev) & 0100, but
	unit = minor(bp->b_dev) & 0177;
	if(unit > 077)

Not so bad when the whole driver is only 376 lines of code,
but it wouldn't have hurt to make it 400 lines if that
meant fewer magic numbers.

Anyway, what all this means is that /dev/*mt0 and /dev/*mt1
both actually meant slave 0 on TU16 controller 0, but mt0
was 800 bpi and mt1 1600 bpi.  Hence, I would guess, tar's
default to mt1.

My first exposure to the insides of UNIX was in the High
Energy Physics group at Caltech.  Some of our systems had
multiple tape drives and every drive supported multiple
densities, so we invented for ourselves a system like that
many other sites invented, with names like /dev/rmt3h to
mean the third tape drive at high density.  (Hence the
USG naming scheme of /dev/rmt/3h and the like--not that
we taught it to them, just that many places had the same
idea.)

Our world wasn't nearly as exciting as that of our neighbors,
across the building and three floors down, in the Space
Radiation Laboratory.  They had a huge room full of racks
of magtapes full of data from satellites, and many locally-
written tools for extracting the data so researchers could
work on it.  The hardware was an 11/70 with eight tape drives,
and at any given time at least half the the drives would be
spinning.  One of the drives was seven-track rather than
nine-track, because some of the satellite data had been
written in that format.

Fair disclosure: I had a vague memory that the `drive number'
in the device name had been recycled for other purposes,
but couldn't remember whether it was density or something
else.  (I'm a little surprised none of the other old-timers
here remembered that, but maybe I worked with tapes more than
them.)  But I had to dig into the source code for the details;
I didn't remember all that.  And I did have to climb up to the
high shelf in my home office for a Peripherals Handbook to
understand the magic numbers being stuffed into registers!

Norman Wilson
Toronto ON


From lyndon at orthanc.ca  Sun Dec 13 13:04:17 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sat, 12 Dec 2015 19:04:17 -0800
Subject: [TUHS] why does tar have the tape device hard coded into it and
	why is it mt1 instead of mt0
In-Reply-To: <20151213014148.5BBF5440AE@lignose.oclsc.org>
References: <20151213014148.5BBF5440AE@lignose.oclsc.org>
Message-ID: <0FC2A9FB-6078-48E3-8B4D-79F607A9B775@orthanc.ca>


On Dec 12, 2015, at 5:41 PM, Norman Wilson <norman at oclsc.org> wrote:

> Anyway, what all this means is that /dev/*mt0 and /dev/*mt1
> both actually meant slave 0 on TU16 controller 0, but mt0
> was 800 bpi and mt1 1600 bpi.  Hence, I would guess, tar's
> default to mt1.

At Athabasca University we had an SI9000 (if I remember the model number correctly) tape drive (vacuum column, no less!) hanging off the 785.  This was a triple-density 800/1600/6250 drive, and I forget what the controller was we had it connected to.  Installing new versions of Ultrix was always fun, because the I/O register that set the density didn't agree with what Ultrix expected the device to do.  We always had to do a little dance on the console to interrupt the installer, manually poke the correct value into a register on the tape controller to set the proper drive density, then continue the installer.  That was my first experience with having to directly frob the hardware on big iron.

Come to think of it, the first program I ever wrote that poked into a live running kernel was something I hacked together to work around a bug in the CTIX QIC tape driver.  If you had a process with the tape device open while the tape was rewinding (deliberately or implicitly) and sent it an interrupt, the process would hang forever.  This got annoying enough that I wrote a little hack that would go in and clear the busy bit in the device table entry, which was enough to let the holding process return from the system call it was stuck in.

Tape drives were magical beasts.  Mostly from the dark side ...

--lyndon

(Don't get me started about trying to get enough I/O throughput out of a 3B2 to make the 9track stream :-P)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151212/c0e4f3fa/attachment.sig>

From will.senn at gmail.com  Sun Dec 13 14:50:54 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 12 Dec 2015 22:50:54 -0600
Subject: [TUHS] tar on v6 not creating directories on v6
In-Reply-To: <20151212222358.GD5686@server.rulingia.com>
References: <566C9772.9040508@gmail.com>
 <20151212222358.GD5686@server.rulingia.com>
Message-ID: <566CF92E.9000708@gmail.com>



On 12/12/15 4:23 PM, Peter Jeremy wrote:
> Presumably, it's not 'y' but has some non-printable characters in it. 
> You could try "od -c ." to see what the entry actually is, or move 
> t.tar out of the way and "rm -r" remove the next level up.
Saved by the source (of rm, then glob):

Solution:

cd into directory containing y (thankfully not a directory with other 
files):

/etc/glob rmdir "*"

:) Yay, another small victory.

-- Will


From wkt at tuhs.org  Mon Dec 14 10:34:25 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 14 Dec 2015 10:34:25 +1000
Subject: [TUHS] TUHS Mail Archive is now searchable
Message-ID: <20151214003425.GA31555@minnie.tuhs.org>

All, I've finally set up a search system for the mailing list.
It's at http://minnie.tuhs.org/cgi-bin/mailman/tuhs.cgi
and it's also hyperlinked on the main list page at
http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs

I've not yet set up a cron job to keep it updated, and yes the
interface is ugly but it works.

Cheers, Warren


From wkt at tuhs.org  Mon Dec 14 19:51:15 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 14 Dec 2015 19:51:15 +1000
Subject: [TUHS] 2.11BSD mirror
Message-ID: <20151214095115.GA16979@minnie.tuhs.org>

Hi all, I've been in contact with Steven Schultz and I've set up a
mirror of his 2.11BSD patches at:

http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/2.11BSD/Patches/

I have no "git fu", but it would be nice to have a Git repository
with all the sources fully patched. Oh, and new boot tapes :-)
I should ask Santa for it.

Cheers, Warren


From lars at nocrew.org  Mon Dec 14 20:30:40 2015
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 14 Dec 2015 11:30:40 +0100
Subject: [TUHS] 2.11BSD mirror
In-Reply-To: <20151214095115.GA16979@minnie.tuhs.org> (Warren Toomey's message
 of "Mon, 14 Dec 2015 19:51:15 +1000")
References: <20151214095115.GA16979@minnie.tuhs.org>
Message-ID: <86vb81cofj.fsf@vps34351.public.cloudvps.com>

> Hi all, I've been in contact with Steven Schultz and I've set up a
> mirror of his 2.11BSD patches
>
> I have no "git fu", but it would be nice to have a Git repository
> with all the sources fully patched. Oh, and new boot tapes :-)
> I should ask Santa for it.

I was kinda planning to retrofit all 2BSD releases and the 2.11 patch
series into a git repository.  But I only got as far as collecting the
some of the inputs:

https://github.com/larsbrinkhoff/2bsd

Pull requests are welcome!  In particular, are there more releases
between 2BSD and 2.8BSD?

(WARNING: this repository WILL be mercilessly force pushed.)


From wkt at tuhs.org  Mon Dec 14 21:01:25 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 14 Dec 2015 21:01:25 +1000
Subject: [TUHS] 2.11BSD mirror
In-Reply-To: <86vb81cofj.fsf@vps34351.public.cloudvps.com>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
Message-ID: <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>

2.79BSD here: http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/

I think I've asked before: why did the numbering go from 2BSD to 2.79BSD?

Cheers, Warren

On 14 December 2015 8:30:40 pm AEST, Lars Brinkhoff <lars at nocrew.org> wrote:
>> Hi all, I've been in contact with Steven Schultz and I've set up a
>> mirror of his 2.11BSD patches
>>
>> I have no "git fu", but it would be nice to have a Git repository
>> with all the sources fully patched. Oh, and new boot tapes :-)
>> I should ask Santa for it.
>
>I was kinda planning to retrofit all 2BSD releases and the 2.11 patch
>series into a git repository.  But I only got as far as collecting the
>some of the inputs:
>
>https://github.com/larsbrinkhoff/2bsd
>
>Pull requests are welcome!  In particular, are there more releases
>between 2BSD and 2.8BSD?
>
>(WARNING: this repository WILL be mercilessly force pushed.)

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151214/bf698d55/attachment.html>

From dave at horsfall.org  Tue Dec 15 06:44:49 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 15 Dec 2015 07:44:49 +1100 (EST)
Subject: [TUHS] Broken TUHS mirror: li1202-53.members.linode.com
Message-ID: <alpine.BSF.2.11.1512150738510.860@aneurin.horsfall.org>

Could whoever runs this broken mirror please fix the damned mailer so that 
it handles my RFC-compliant banner?  I do not appreciate retries every 
five seconds or so, because Dovecot cannot seem to handle a multi-line 
SMTP banner (a great spam defence); I have since firewalled the IP address 
of 45.79.103.53 out of self-defence.

Thank you.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From dugo at xs4all.nl  Wed Dec 16 10:02:19 2015
From: dugo at xs4all.nl (Jacob Goense)
Date: Wed, 16 Dec 2015 01:02:19 +0100
Subject: [TUHS] 2.11BSD mirror
In-Reply-To: <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
Message-ID: <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>

On 2015-12-14 12:01, Warren Toomey wrote:
> 2.79BSD here: http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/

Is there a pristine copy of 2.11BSD as well? The archived one is at 
patch 431.


From wkt at tuhs.org  Wed Dec 16 10:19:25 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 16 Dec 2015 10:19:25 +1000
Subject: [TUHS] 2.11BSD mirror
In-Reply-To: <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
Message-ID: <20151216001925.GA27707@minnie.tuhs.org>

On Wed, Dec 16, 2015 at 01:02:19AM +0100, Jacob Goense wrote:
> On 2015-12-14 12:01, Warren Toomey wrote:
> >2.79BSD here: http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/
> 
> Is there a pristine copy of 2.11BSD as well? The archived one is at patch
> 431.

By pristine, do you mean a bootable tape with all the patches applied?
There isn't one. But it would be nice if someone made such a tape!

Cheers, Warren


From dugo at xs4all.nl  Wed Dec 16 10:37:53 2015
From: dugo at xs4all.nl (Jacob Goense)
Date: Wed, 16 Dec 2015 01:37:53 +0100
Subject: [TUHS] 2.11BSD mirror
In-Reply-To: <20151216001925.GA27707@minnie.tuhs.org>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151216001925.GA27707@minnie.tuhs.org>
Message-ID: <3a391c1135a3944e714bf41e356122b3@xs4all.nl>

On 2015-12-16 01:19, Warren Toomey wrote:
> On Wed, Dec 16, 2015 at 01:02:19AM +0100, Jacob Goense wrote:
>> On 2015-12-14 12:01, Warren Toomey wrote:
>> >2.79BSD here: http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/
>> 
>> Is there a pristine copy of 2.11BSD as well? The archived one is at 
>> patch
>> 431.
> 
> By pristine, do you mean a bootable tape with all the patches applied?
> There isn't one. But it would be nice if someone made such a tape!

I actually mean one with none of the patches. What fun is a git repo if
only the last 17 patch sets are in it?


From arnold at skeeve.com  Wed Dec 16 14:37:14 2015
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 15 Dec 2015 21:37:14 -0700
Subject: [TUHS] 2.11BSD mirror
In-Reply-To: <3a391c1135a3944e714bf41e356122b3@xs4all.nl>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151216001925.GA27707@minnie.tuhs.org>
 <3a391c1135a3944e714bf41e356122b3@xs4all.nl>
Message-ID: <201512160437.tBG4bE0E018124@freefriends.org>

Jacob Goense <dugo at xs4all.nl> wrote:

> On 2015-12-16 01:19, Warren Toomey wrote:
> > On Wed, Dec 16, 2015 at 01:02:19AM +0100, Jacob Goense wrote:
> >> On 2015-12-14 12:01, Warren Toomey wrote:
> >> >2.79BSD here: http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/
> >> 
> >> Is there a pristine copy of 2.11BSD as well? The archived one is at 
> >> patch
> >> 431.
> > 
> > By pristine, do you mean a bootable tape with all the patches applied?
> > There isn't one. But it would be nice if someone made such a tape!
>
> I actually mean one with none of the patches. What fun is a git repo if
> only the last 17 patch sets are in it?

You could always use patch -R to reverse the patches to get back to
the original. (Yes, I'm joking.)

Arnold


From dave at horsfall.org  Thu Dec 17 04:45:38 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 17 Dec 2015 05:45:38 +1100 (EST)
Subject: [TUHS] Testing, testing..
Message-ID: <alpine.BSF.2.11.1512170541490.860@aneurin.horsfall.org>

1 2 3...  Is this mic on?  Tap tap...

Seriously, my anti-spam defences were having an issue with this list for a 
while, so let's see whether it comes back.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From milov at cs.uwlax.edu  Thu Dec 17 05:00:31 2015
From: milov at cs.uwlax.edu (Milo Velimirovic)
Date: Wed, 16 Dec 2015 13:00:31 -0600
Subject: [TUHS] Testing, testing..
In-Reply-To: <alpine.BSF.2.11.1512170541490.860@aneurin.horsfall.org>
References: <alpine.BSF.2.11.1512170541490.860@aneurin.horsfall.org>
Message-ID: <56666241-BCDE-4691-ADFF-0D6556AE565D@cs.uwlax.edu>

Trey turning it up to 11.

> On Dec 16, 2015, at 12:45 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> 1 2 3...  Is this mic on?  Tap tap...
> 
> Seriously, my anti-spam defences were having an issue with this list for a 
> while, so let's see whether it comes back.
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs



From dave at horsfall.org  Thu Dec 17 06:01:42 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 17 Dec 2015 07:01:42 +1100 (EST)
Subject: [TUHS] Testing, testing..
In-Reply-To: <20151216185347.GE9977@mcvoy.com>
References: <alpine.BSF.2.11.1512170541490.860@aneurin.horsfall.org>
 <20151216185347.GE9977@mcvoy.com>
Message-ID: <alpine.BSF.2.11.1512170651510.860@aneurin.horsfall.org>

> I got it.

Ta muchly!  All seems OK now, after TUHS moved to a new ISP (linode, 
which, ahem, is known for hosting spammers).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From tih at hamartun.priv.no  Thu Dec 17 07:56:53 2015
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Wed, 16 Dec 2015 22:56:53 +0100
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <20151212054404.GB15143@mercury.ccil.org> (John Cowan's message
 of "Sat, 12 Dec 2015 00:44:04 -0500")
References: <20151212045416.GB5686@server.rulingia.com>
 <20151212054404.GB15143@mercury.ccil.org>
Message-ID: <m2egem6ore.fsf@athene.hamartun.priv.no>

John Cowan <cowan at mercury.ccil.org> writes:

> Looking at the Internet Archive's copy of 2bsd.com led me to
> <ftp://ftp.wx.gd-ais.com/pub/2.11BSD>, which indeed has patch 448 in it,

That's not an official patch.  It's a collection of improvements by
Johnny Billquist.  I'm running with a couple of them on my 2.11BSD
installations, but disagree with a couple of the others (I don't want
the automatic boot, and I do console byte length and parity slightly
differently) -- and I have a few mods of my own as well, of course.

It's great that Johnny published his changes, but they should really be
stored as six suggested improvements, and not in a way that makes them
look as if they're yet another patch kit from Steven.

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble


From dave at horsfall.org  Thu Dec 17 15:12:14 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 17 Dec 2015 16:12:14 +1100 (EST)
Subject: [TUHS] OT: Happy birthday, Ken Iverson!
Message-ID: <alpine.BSF.2.11.1512171609190.860@aneurin.horsfall.org>

Ken Iverson was born in 1920; he is (in)famous for inventing APL.  And if 
you haven't used APL\360 on a dumb Kleinschmidt[*] terminal, you didn't 
miss anything.

[*]
And that's the first time I've seen a spell-checker suggest that it be 
replaced with "Consummated".

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From gregg.drwho8 at gmail.com  Thu Dec 17 15:26:59 2015
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Thu, 17 Dec 2015 00:26:59 -0500
Subject: [TUHS] OT: Happy birthday, Ken Iverson!
In-Reply-To: <alpine.BSF.2.11.1512171609190.860@aneurin.horsfall.org>
References: <alpine.BSF.2.11.1512171609190.860@aneurin.horsfall.org>
Message-ID: <CAC5iaNEKOgPjGkN0d5rYXE_FuEco3opYdRJ61gCpdTYnQy98-g@mail.gmail.com>

Hello!
And Dave his annoying language is my age........
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Thu, Dec 17, 2015 at 12:12 AM, Dave Horsfall <dave at horsfall.org> wrote:
> Ken Iverson was born in 1920; he is (in)famous for inventing APL.  And if
> you haven't used APL\360 on a dumb Kleinschmidt[*] terminal, you didn't
> miss anything.
>
> [*]
> And that's the first time I've seen a spell-checker suggest that it be
> replaced with "Consummated".
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs


From cubexyz at gmail.com  Fri Dec 18 01:13:37 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Thu, 17 Dec 2015 10:13:37 -0500
Subject: [TUHS] ed.c on Unix v5
Message-ID: <CADxT5N7R7OTvwSEXh0VTg0e9wx9W8tWdcQSnZUGamiAge3h7Qw@mail.gmail.com>

Ok, not sure if anyone will want to do this but I've just compiled
ed.c from Unix v6 on Unix v5.

It's not much bigger than the assembled ed, with 1314 lines of C code
the compiled executable is only 6518 bytes vs 4292 for the original. I
was looking at the source code and didn't see anything that the v5 cc
couldn't handle. I trimmed the source a bit, there's a function at the
end called getpid()  which is commented out.

The comment says:

/* Get process ID routine if system call is unavailable. */

but my version of v5 does have that system call so it's all good.

It's been run a few times and it seems to work just fine. It may even
have a few more features than the v5 ed, I'm not sure yet :)

Mark


From tih at hamartun.priv.no  Fri Dec 18 01:40:39 2015
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Thu, 17 Dec 2015 16:40:39 +0100
Subject: [TUHS] Pre-v6 images and 2.11BSD patches
In-Reply-To: <566C040C.6040705@update.uu.se> (Johnny Billquist's message of
 "Sat, 12 Dec 2015 12:25:00 +0100")
References: <mailman.17.1449898266.27456.tuhs@minnie.tuhs.org>
 <566C040C.6040705@update.uu.se>
Message-ID: <m2fuz1w0aw.fsf@athene.hamartun.priv.no>

Johnny Billquist <bqt at update.uu.se> writes:

> Yes, I did 448. Various bits and pieces that were fixed there, but
> unfortunately I haven't managed to reach Steve to get it officially
> sanctioned.

I've tried to reach him from time to time, as well.  Hope he's OK.

> . Made console 8-bit clean

I did that somewhat differently, when I started running 2.11BSD with a
console terminal that got multiplexed between different systems.  Here's
my version, which allows you to change parity on the console:

*** usr/src/sys/pdp/cons.c.ORIG	Sun May 11 11:21:01 1997
--- usr/src/sys/pdp/cons.c	Tue Dec  2 17:59:27 2014
***************
*** 62,68 ****
  	if ((tp->t_state&TS_ISOPEN) == 0) {
  		ttychars(tp);
  		tp->t_state = TS_ISOPEN|TS_CARR_ON;
! 		tp->t_flags = EVENP|ECHO|XTABS|CRMOD;
  	}
  	if (tp->t_state&TS_XCLUDE && u.u_uid != 0)
  		return (EBUSY);
--- 62,68 ----
  	if ((tp->t_state&TS_ISOPEN) == 0) {
  		ttychars(tp);
  		tp->t_state = TS_ISOPEN|TS_CARR_ON;
! 		tp->t_flags = ANYP|ECHO|XTABS|CRMOD;
  	}
  	if (tp->t_state&TS_XCLUDE && u.u_uid != 0)
  		return (EBUSY);
***************
*** 163,170 ****
  	c = getc(&tp->t_outq);
  	if (tp->t_flags & (RAW|LITOUT))
  		addr->dlxbuf = c&0xff;
! 	else
  		addr->dlxbuf = c | (partab[c] & 0200);
  	tp->t_state |= TS_BUSY;
  out:
  	splx(s);
--- 163,174 ----
  	c = getc(&tp->t_outq);
  	if (tp->t_flags & (RAW|LITOUT))
  		addr->dlxbuf = c&0xff;
! 	else if ((tp->t_flags & (EVENP | ODDP)) == EVENP)
  		addr->dlxbuf = c | (partab[c] & 0200);
+ 	else if ((tp->t_flags & (EVENP | ODDP)) == ODDP)
+ 		addr->dlxbuf = c | ((partab[c] & 0200) ^ 0200);
+ 	else
+ 		addr->dlxbuf = c;
  	tp->t_state |= TS_BUSY;
  out:
  	splx(s);


-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble


From wkt at tuhs.org  Fri Dec 18 08:43:17 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 18 Dec 2015 08:43:17 +1000
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
Message-ID: <20151217224317.GA29449@minnie.tuhs.org>

On Wed, Dec 16, 2015 at 01:02:19AM +0100, Jacob Goense wrote:
> Is there a pristine copy of 2.11BSD as well? The archived one is at patch
> 431.

I heard from Steven Schultz. He says that there was never a version
control repository for 2.11BSD, so yes someone would have to patch -R
to get back to the pristine version with no patches.

I'm still trying to work out if I'm foolish/stubborn enough to try
doing it myself :-)

Cheers, Warren


From imp at bsdimp.com  Fri Dec 18 08:45:57 2015
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 17 Dec 2015 15:45:57 -0700
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <20151217224317.GA29449@minnie.tuhs.org>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
Message-ID: <CANCZdfp0whyVSe1CNaLVV1KAJkWkFEdvtH24j5Nz9wWz8MRJ_A@mail.gmail.com>

Is there a directory of 431 patches somewhere? :)

I'm guessing the answer is no, but I thought I'd ask the obvious question.

Warner


On Thu, Dec 17, 2015 at 3:43 PM, Warren Toomey <wkt at tuhs.org> wrote:

> On Wed, Dec 16, 2015 at 01:02:19AM +0100, Jacob Goense wrote:
> > Is there a pristine copy of 2.11BSD as well? The archived one is at patch
> > 431.
>
> I heard from Steven Schultz. He says that there was never a version
> control repository for 2.11BSD, so yes someone would have to patch -R
> to get back to the pristine version with no patches.
>
> I'm still trying to work out if I'm foolish/stubborn enough to try
> doing it myself :-)
>
> Cheers, Warren
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151217/f1f4951e/attachment.html>

From mah at mhorton.net  Fri Dec 18 10:34:08 2015
From: mah at mhorton.net (Mary Ann Horton)
Date: Thu, 17 Dec 2015 16:34:08 -0800
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <20151217224317.GA29449@minnie.tuhs.org>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
Message-ID: <56735480.8010206@mhorton.net>

I sent out the 2.11 tapes at one point.  We just shipped out whatever we 
had in the latest package build.  No version control. So I wouldn't call 
them patches, more like new subversions.

So the question might be, does anyone have a really old 2.11 tape? It 
would have to be from around 1980.  I did not save a 2.11 in my collection.

On 12/17/2015 02:43 PM, Warren Toomey wrote:
> On Wed, Dec 16, 2015 at 01:02:19AM +0100, Jacob Goense wrote:
>> Is there a pristine copy of 2.11BSD as well? The archived one is at patch
>> 431.
> I heard from Steven Schultz. He says that there was never a version
> control repository for 2.11BSD, so yes someone would have to patch -R
> to get back to the pristine version with no patches.
>
> I'm still trying to work out if I'm foolish/stubborn enough to try
> doing it myself :-)
>
> Cheers, Warren
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs



From random832 at fastmail.com  Fri Dec 18 12:49:35 2015
From: random832 at fastmail.com (Random832)
Date: Thu, 17 Dec 2015 21:49:35 -0500
Subject: [TUHS] Pristine version of 2.11BSD
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <CANCZdfp0whyVSe1CNaLVV1KAJkWkFEdvtH24j5Nz9wWz8MRJ_A@mail.gmail.com>
Message-ID: <m21tak5v40.fsf@fastmail.com>

Warner Losh  writes:
> Is there a directory of 431 patches somewhere? :)

They all seem to be there on the FTP. I *think* they're all context
diffs, too, so reversing should be possible.



From tih at hamartun.priv.no  Fri Dec 18 21:04:59 2015
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Fri, 18 Dec 2015 12:04:59 +0100
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <20151217224317.GA29449@minnie.tuhs.org> (Warren Toomey's message
 of "Fri, 18 Dec 2015 08:43:17 +1000")
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
Message-ID: <m2egeknhk4.fsf@athene.hamartun.priv.no>

Warren Toomey <wkt at tuhs.org> writes:

> I heard from Steven Schultz. He says that there was never a version
> control repository for 2.11BSD, so yes someone would have to patch -R
> to get back to the pristine version with no patches.

That's not going to be easy.  Some of the patch level transitions
involve removing old source files.  Of course, if one is lucky, the
files that got removed along the way will turn out to have been created
at some earlier transition...  Quite the puzzle to figure out, anyway.

Going the other way, one might start with a 2.10 source kit.  Of course,
it is known that the initial 2.11 was 2.10 plus a lost set of changes,
but with luck, it might turn out that the files that cannot be traced
backward from current 2.11 can, in fact, be traced forward from 2.10
using 2.11 patches.

So working backward, while regenerating individual removed or
overwritten files by patching them forward from 2.10, *might* succeed.

I'm almost tempted to bring the necessary data when we go to our
mountain cabin for New Year's...  :)

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble


From tih at hamartun.priv.no  Fri Dec 18 23:27:19 2015
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Fri, 18 Dec 2015 14:27:19 +0100
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <20151217224317.GA29449@minnie.tuhs.org> (Warren Toomey's message
 of "Fri, 18 Dec 2015 08:43:17 +1000")
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
Message-ID: <m2d1u3nayw.fsf@athene.hamartun.priv.no>

Warren Toomey <wkt at tuhs.org> writes:

> On Wed, Dec 16, 2015 at 01:02:19AM +0100, Jacob Goense wrote:
>> Is there a pristine copy of 2.11BSD as well? The archived one is at patch
>> 431.

Incidentally, I have a kit from Steven here that's at patch level 195.
That's more than half way back, if one were to start 'patch -R'-ing.

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble


From tih at hamartun.priv.no  Fri Dec 18 23:50:11 2015
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Fri, 18 Dec 2015 14:50:11 +0100
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <m2d1u3nayw.fsf@athene.hamartun.priv.no> (Tom Ivar Helbekkmo's
 message of "Fri, 18 Dec 2015 14:27:19 +0100")
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2d1u3nayw.fsf@athene.hamartun.priv.no>
Message-ID: <m2a8p7kgrw.fsf@athene.hamartun.priv.no>

Tom Ivar Helbekkmo <tih at hamartun.priv.no> writes:

> Incidentally, I have a kit from Steven here that's at patch level 195.
> That's more than half way back, if one were to start 'patch -R'-ing.

...and the requests for it have already started flowing in.  :)
It's at https://www.hamartun.priv.no/tih/2.11BSD-pl195.tar

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble


From reed at reedmedia.net  Sat Dec 19 00:02:48 2015
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Fri, 18 Dec 2015 08:02:48 -0600 (CST)
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <56735480.8010206@mhorton.net>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <56735480.8010206@mhorton.net>
Message-ID: <alpine.NEB.2.11.1512180756520.562@t1.m.reedmedia.net>

Maybe USENIX has archives?  They handled the orders for Bostic and 
Leedom's 2.10 and 2.10.1, and Schultz's 2.11BSD release (of July 1987, 
March 1989, and January 1991).


From wkt at tuhs.org  Sat Dec 19 08:31:38 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 19 Dec 2015 08:31:38 +1000
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <alpine.NEB.2.11.1512180756520.562@t1.m.reedmedia.net>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <56735480.8010206@mhorton.net>
 <alpine.NEB.2.11.1512180756520.562@t1.m.reedmedia.net>
Message-ID: <20151218223138.GA27510@minnie.tuhs.org>

On Fri, Dec 18, 2015 at 08:02:48AM -0600, Jeremy C. Reed wrote:
> Maybe USENIX has archives?  They handled the orders for Bostic and 
> Leedom's 2.10 and 2.10.1, and Schultz's 2.11BSD release (of July 1987, 
> March 1989, and January 1991).

I've just added Tom Ivar Helbekkmo's version of 2.11BSD into the Unix Archive
at http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/2.11BSD-pl195.tar

If someone can find an earlier version then I'd also be happy to add it
to the collection.

Cheers & thanks Tom, Warren


From dave at horsfall.org  Sat Dec 19 12:27:11 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 19 Dec 2015 13:27:11 +1100 (EST)
Subject: [TUHS] ed.c on Unix v5
In-Reply-To: <CADxT5N7R7OTvwSEXh0VTg0e9wx9W8tWdcQSnZUGamiAge3h7Qw@mail.gmail.com>
References: <CADxT5N7R7OTvwSEXh0VTg0e9wx9W8tWdcQSnZUGamiAge3h7Qw@mail.gmail.com>
Message-ID: <alpine.BSF.2.11.1512191321060.54277@aneurin.horsfall.org>

On Thu, 17 Dec 2015, Mark Longridge wrote:

> It's not much bigger than the assembled ed, with 1314 lines of C code 
> the compiled executable is only 6518 bytes vs 4292 for the original. I 
> was looking at the source code and didn't see anything that the v5 cc 
> couldn't handle. I trimmed the source a bit, there's a function at the 
> end called getpid()  which is commented out.

If your V5 has getpid(), then it's a...  strange version...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From cubexyz at gmail.com  Sat Dec 19 18:34:52 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Sat, 19 Dec 2015 03:34:52 -0500
Subject: [TUHS] ed.c on Unix v5
In-Reply-To: <alpine.BSF.2.11.1512191321060.54277@aneurin.horsfall.org>
References: <CADxT5N7R7OTvwSEXh0VTg0e9wx9W8tWdcQSnZUGamiAge3h7Qw@mail.gmail.com>
 <alpine.BSF.2.11.1512191321060.54277@aneurin.horsfall.org>
Message-ID: <CADxT5N4HL7PgqGSRo_EDRD1crGSdSG5KthLR1CHXZ7w01eXs-Q@mail.gmail.com>

>> I trimmed the source a bit, there's a function at the
>> end called getpid()  which is commented out.

> If your V5 has getpid(), then it's a...  strange version...

I went back to the original uv5swre.zip file which was what I started
with and had another look to be sure.

It's not listed on tuhs under v5 but if one looks at /lib/libc.a via
'ar t getpid.o' you can see the object file getpid.o

There's no other trace of getpid in v5 as it's not in the v5 manual
and there's no getpid.s in the disk image. I'm not sure if having
getpid in v5 is anomalous or not, perhaps you or someone else can
actually remember as I'm a johnny-come-lately to the party.  There's
even some commands mentioned in the v4 manual that don't exist in the
v5 disk image.

It's possible that there's another Unix v5 that really doesn't have
it, perhaps an older one.

Mark





On 12/18/15, Dave Horsfall <dave at horsfall.org> wrote:
> On Thu, 17 Dec 2015, Mark Longridge wrote:
>
>> It's not much bigger than the assembled ed, with 1314 lines of C code
>> the compiled executable is only 6518 bytes vs 4292 for the original. I
>> was looking at the source code and didn't see anything that the v5 cc
>> couldn't handle. I trimmed the source a bit, there's a function at the
>> end called getpid()  which is commented out.
>
> If your V5 has getpid(), then it's a...  strange version...
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>


From jnc at mercury.lcs.mit.edu  Sat Dec 19 22:12:20 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 19 Dec 2015 07:12:20 -0500 (EST)
Subject: [TUHS] ed.c on Unix v5
Message-ID: <20151219121220.EC3A718C0A3@mercury.lcs.mit.edu>

    > From: Mark Longridge <cubexyz at gmail.com>

    > if one looks at /lib/libc.a via 'ar t getpid.o' you can see the object
    > file getpid.o

Library, schlibrary! The important question is 'is it in the kernel source'?
(Although now that I think about it, if the library routine tries to use a
non-existent system call, it should return an error. It would be interested
to disassemble the library routine, and see what it thinks it is doing.)

   Noel


From cubexyz at gmail.com  Sat Dec 19 22:40:48 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Sat, 19 Dec 2015 07:40:48 -0500
Subject: [TUHS] ed.c on Unix v5
In-Reply-To: <20151219121220.EC3A718C0A3@mercury.lcs.mit.edu>
References: <20151219121220.EC3A718C0A3@mercury.lcs.mit.edu>
Message-ID: <CADxT5N5iGFBdmfZtt5TeYN+xM1bKKAFUCALmEEP37VH-2h2qZg@mail.gmail.com>

> Library, schlibrary! The important question is 'is it in the kernel source'?
> (Although now that I think about it, if the library routine tries to use a
> non-existent system call, it should return an error. It would be interested
> to disassemble the library routine, and see what it thinks it is doing.)
>
>   Noel

It does appear to be there:

looking in V5/usr/sys/ken/sys4.c starting at line 79:

getpid()
{
        u.u_ar0[R0] = u.u_procp->p_pid;
}

But looking at V4/nsys/ken/sys4.c it's not there. Not too sure about
reversing getpid.o, but maybe possible with db?

Mark


On 12/19/15, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Mark Longridge <cubexyz at gmail.com>
>
>     > if one looks at /lib/libc.a via 'ar t getpid.o' you can see the
> object
>     > file getpid.o
>
> Library, schlibrary! The important question is 'is it in the kernel
> source'?
> (Although now that I think about it, if the library routine tries to use a
> non-existent system call, it should return an error. It would be interested
> to disassemble the library routine, and see what it thinks it is doing.)
>
>    Noel
>


From jnc at mercury.lcs.mit.edu  Sat Dec 19 23:27:52 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 19 Dec 2015 08:27:52 -0500 (EST)
Subject: [TUHS] v6tar from v7 on v6, too large?
Message-ID: <20151219132752.E11C018C0A2@mercury.lcs.mit.edu>

So, speaking of system calls that are missing in earlier versions of Unix,
that tickled a memory:

    > From: Will Senn

    > ... a special version of tar must be prepared to run on V6.
    > The document goes on to describe a reasonable method to make v6tar on
    > v7 and copy the binary over to the v6 system.

When I got tar running on my V6, I didn't know about this, and I took
a V7 tar and got it running myself, see here:

  http://mercury.lcs.mit.edu/~jnc/tech/ImprovingV6.html#tar
  
One thing I found out while doing that is that tar uses the 'utime' system
call on V7 to set the file date, but i) V6 doesn't have utime() (although it
has smdate(), albeit commented out in the standard distro), and ii) on now
looking in src/cmd/tar and src/libc/v6 in the V7 distro, I don't see a
replacement version of utime().

As near as I can make out, 'v6tar' must be using the standard V7 version of
utime(), which I assume turns into a call to nosys() on V6 (returns an error);
tar doesn't check the return value, so the call fails (silently). So v6tar
won't correctly set the file date when moving a file _to_ V6.

	Noel


From jnc at mercury.lcs.mit.edu  Sat Dec 19 23:56:03 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 19 Dec 2015 08:56:03 -0500 (EST)
Subject: [TUHS] ed.c on Unix v5
Message-ID: <20151219135603.5A06918C0A2@mercury.lcs.mit.edu>

    > From: Mark Longridge

    > Not too sure about reversing getpid.o, but maybe possible with db?

Well, me, I'd just use 'od' - but then again, I have ucode for disassembling
PDP-11 octal! :-) (OK, OK, so a lot of the less common instructions I have
to look up! :-)

But, seriously, yeah, 'db' is probably the way to go.

FWIW, it's possible to get 'adb' running under V6 without much (any?) work,
too. Although maybe it needs the 'phototypesetter' C compiler? I'd have to
check...

There's also a 'cdb' running around (I found a copy on the 'Shoppa disks'),
which is basically 'db' but augmented with a few useful commands - maybe stack
backtrace, I don't recall the details, the documentation in on my V6, and I
don't feel like spinning it up just to look for that.

	Noel


From tih at hamartun.priv.no  Sun Dec 20 00:16:31 2015
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Sat, 19 Dec 2015 15:16:31 +0100
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <m2egeknhk4.fsf@athene.hamartun.priv.no> (Tom Ivar Helbekkmo's
 message of "Fri, 18 Dec 2015 12:04:59 +0100")
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2egeknhk4.fsf@athene.hamartun.priv.no>
Message-ID: <m260zua5hc.fsf@athene.hamartun.priv.no>

I wrote:

> So working backward, while regenerating individual removed or
> overwritten files by patching them forward from 2.10, *might* succeed.

For what it's worth, I've begun.  So far, I've worked backward from
patchlevel 195 to 177.  I've had to patch files forward from 2.10.1 a
couple of times, and that's gone without a hitch.

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble


From random832 at fastmail.com  Sun Dec 20 00:57:32 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 19 Dec 2015 09:57:32 -0500
Subject: [TUHS] ed.c on Unix v5
References: <CADxT5N7R7OTvwSEXh0VTg0e9wx9W8tWdcQSnZUGamiAge3h7Qw@mail.gmail.com>
 <alpine.BSF.2.11.1512191321060.54277@aneurin.horsfall.org>
 <CADxT5N4HL7PgqGSRo_EDRD1crGSdSG5KthLR1CHXZ7w01eXs-Q@mail.gmail.com>
Message-ID: <m2si2y4hb7.fsf@fastmail.com>

Mark Longridge <cubexyz at gmail.com> writes:

>>> I trimmed the source a bit, there's a function at the
>>> end called getpid()  which is commented out.
>
>> If your V5 has getpid(), then it's a...  strange version...
>
> I went back to the original uv5swre.zip file which was what I started
> with and had another look to be sure.
>
> It's not listed on tuhs under v5 but if one looks at /lib/libc.a via
> 'ar t getpid.o' you can see the object file getpid.o

Plus, you know, the syscall itself.
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/sys4.c
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/sysent.c

There are four (well, five with ctime) objects in libc.a with no
matching source file in /usr/source/s4: alloc, getpid, ladd, and
snstat.  Also, mon and qsort have assembly versions in s3 and C
versions in s4, and ctime is in s3 despite the fact that almost
every other libc file is in s4.

jnc at mercury.lcs.mit.edu (Noel Chiappa)
writes:

>     > From: Mark Longridge <cubexyz at gmail.com>
>
>     > if one looks at /lib/libc.a via 'ar t getpid.o' you can see the object
>     > file getpid.o
>
> Library, schlibrary! The important question is 'is it in the kernel source'?
> (Although now that I think about it, if the library routine tries to use a
> non-existent system call, it should return an error. It would be interested
> to disassemble the library routine, and see what it thinks it is doing.)

getpid.o consists of two instructions: sys getpid; rts pc. So it
unconditionally returns whatever the syscall puts in r0.

Non-existent syscalls map to nosys, which sets u_error to 100
(so, in principle, it will return 100, but), which causes the
process to be sent a signal SIGSYS.



From jnc at mercury.lcs.mit.edu  Sun Dec 20 01:10:38 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 19 Dec 2015 10:10:38 -0500 (EST)
Subject: [TUHS] ed.c on Unix v5
Message-ID: <20151219151038.77D7A18C0A3@mercury.lcs.mit.edu>

    > From: Random832

    > Non-existent syscalls map to nosys, which sets u_error to 100 ... which
    > causes the process to be sent a signal SIGSYS.

Oh, right, I'd forgotten that.

So, getting back to v6tar, I'll bet that if you try and use it to _read_ a TAR
file file under V6 (i.e. write files into the V6 filesystem), it will bomb out
(because of the call to utime).

     Noel


From random832 at fastmail.com  Sun Dec 20 01:22:12 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 19 Dec 2015 10:22:12 -0500
Subject: [TUHS] ed.c on Unix v5
References: <20151219151038.77D7A18C0A3@mercury.lcs.mit.edu>
Message-ID: <m2a8p64g63.fsf@fastmail.com>

Noel Chiappa writes:
> So, getting back to v6tar, I'll bet that if you try and use it
> to _read_ a TAR file file under V6 (i.e. write files into the
> V6 filesystem), it will bomb out (because of the call to
> utime).

Not quite. On a stock V6 kernel, system call 30 (smdate/utime)
maps to nullsys rather than nosys.



From jnc at mercury.lcs.mit.edu  Sun Dec 20 01:47:17 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 19 Dec 2015 10:47:17 -0500 (EST)
Subject: [TUHS] ed.c on Unix v5
Message-ID: <20151219154717.753AF18C0A8@mercury.lcs.mit.edu>

    > From: Random832

    > Not quite. On a stock V6 kernel, system call 30 (smdate/utime) maps to
    > nullsys rather than nosys.

Oh, right. (Hadn't checked the number, assumed they used a new one for utime.)

	Noel


From cowan at mercury.ccil.org  Sun Dec 20 02:18:06 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Sat, 19 Dec 2015 11:18:06 -0500
Subject: [TUHS] ed.c on Unix v5
In-Reply-To: <CADxT5N4HL7PgqGSRo_EDRD1crGSdSG5KthLR1CHXZ7w01eXs-Q@mail.gmail.com>
References: <CADxT5N7R7OTvwSEXh0VTg0e9wx9W8tWdcQSnZUGamiAge3h7Qw@mail.gmail.com>
 <alpine.BSF.2.11.1512191321060.54277@aneurin.horsfall.org>
 <CADxT5N4HL7PgqGSRo_EDRD1crGSdSG5KthLR1CHXZ7w01eXs-Q@mail.gmail.com>
Message-ID: <20151219161806.GA14625@mercury.ccil.org>

Mark Longridge scripsit:

> There's no other trace of getpid in v5 as it's not in the v5 manual
> and there's no getpid.s in the disk image. I'm not sure if having
> getpid in v5 is anomalous or not, perhaps you or someone else can
> actually remember as I'm a johnny-come-lately to the party.  There's
> even some commands mentioned in the v4 manual that don't exist in the
> v5 disk image.

The manuals were versioned, but the tapes were not: each tape represents
a snapshot of the research system on that particular day, so what you find
there isn't closely correlated with any manual version.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Long-short-short, long-short-short / Dactyls in dimeter,
Verse form with choriambs / (Masculine rhyme):
One sentence (two stanzas) / Hexasyllabically
Challenges poets who / Don't have the time.     --robison who's at texas dot net


From clennox at cosmic.com  Sun Dec 20 03:02:43 2015
From: clennox at cosmic.com (Craig Lennox)
Date: Sat, 19 Dec 2015 12:02:43 -0500
Subject: [TUHS] ed.c on Unix v5
In-Reply-To: <20151219161806.GA14625@mercury.ccil.org>
References: <CADxT5N7R7OTvwSEXh0VTg0e9wx9W8tWdcQSnZUGamiAge3h7Qw@mail.gmail.com>
 <alpine.BSF.2.11.1512191321060.54277@aneurin.horsfall.org>
 <CADxT5N4HL7PgqGSRo_EDRD1crGSdSG5KthLR1CHXZ7w01eXs-Q@mail.gmail.com>
 <20151219161806.GA14625@mercury.ccil.org>
Message-ID: <692F9BAD-C0F8-451E-98E9-D2289F61887A@cosmic.com>



On Dec 19, 2015, at 11:18, John Cowan <cowan at mercury.ccil.org> wrote:
> The manuals were versioned, but the tapes were not: each tape represents
> a snapshot of the research system on that particular day, 

Can we at least tell which day?

Craig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151219/422a4516/attachment.html>

From rochkind at basepath.com  Sun Dec 20 04:36:26 2015
From: rochkind at basepath.com (Marc Rochkind)
Date: Sat, 19 Dec 2015 11:36:26 -0700
Subject: [TUHS] ed.c on Unix v5
In-Reply-To: <20151219161806.GA14625@mercury.ccil.org>
References: <CADxT5N7R7OTvwSEXh0VTg0e9wx9W8tWdcQSnZUGamiAge3h7Qw@mail.gmail.com>
 <alpine.BSF.2.11.1512191321060.54277@aneurin.horsfall.org>
 <CADxT5N4HL7PgqGSRo_EDRD1crGSdSG5KthLR1CHXZ7w01eXs-Q@mail.gmail.com>
 <20151219161806.GA14625@mercury.ccil.org>
Message-ID: <CAOkr1zWBT8tbRH8pD5STdSyEoX=Qo7X3Vi=UrT9J_NRBR8V9gA@mail.gmail.com>

Right. Obviously Doug can supply the details, but I recall that around 1972
or so Dick Haight used to go over from Piscataway to Murray Hill to get a
new system, and there would be some sort of indication about whether it was
a good day or a bad day to make a tape.

--Marc

On Sat, Dec 19, 2015 at 9:18 AM, John Cowan <cowan at mercury.ccil.org> wrote:

> Mark Longridge scripsit:
>
> > There's no other trace of getpid in v5 as it's not in the v5 manual
> > and there's no getpid.s in the disk image. I'm not sure if having
> > getpid in v5 is anomalous or not, perhaps you or someone else can
> > actually remember as I'm a johnny-come-lately to the party.  There's
> > even some commands mentioned in the v4 manual that don't exist in the
> > v5 disk image.
>
> The manuals were versioned, but the tapes were not: each tape represents
> a snapshot of the research system on that particular day, so what you find
> there isn't closely correlated with any manual version.
>
> --
> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> Long-short-short, long-short-short / Dactyls in dimeter,
> Verse form with choriambs / (Masculine rhyme):
> One sentence (two stanzas) / Hexasyllabically
> Challenges poets who / Don't have the time.     --robison who's at texas
> dot net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151219/5832b5b4/attachment.html>

From random832 at fastmail.com  Sun Dec 20 06:05:50 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 19 Dec 2015 15:05:50 -0500
Subject: [TUHS] ed.c on Unix v5
References: <CADxT5N7R7OTvwSEXh0VTg0e9wx9W8tWdcQSnZUGamiAge3h7Qw@mail.gmail.com>
 <alpine.BSF.2.11.1512191321060.54277@aneurin.horsfall.org>
 <CADxT5N4HL7PgqGSRo_EDRD1crGSdSG5KthLR1CHXZ7w01eXs-Q@mail.gmail.com>
 <20151219161806.GA14625@mercury.ccil.org>
 <692F9BAD-C0F8-451E-98E9-D2289F61887A@cosmic.com>
Message-ID: <m2lh8qxkyp.fsf@fastmail.com>

Craig Lennox <clennox at cosmic.com> writes:
> Can we at least tell which day?
>
> Craig

Assuming the clocks were set correctly, then to the extent it's
relevant, it'd be the latest timestamp. In Dennis_V5, that is the
kernel (and specifically conf.c, low.s, and mch.s as the most
recently modified source files), on Mar 21 1975.

The next newest files are dump, restor, and (kernel source) rkf.s
and nami.c... but there's no associated object file or change to
lib2.  The latest objects in lib1 and lib2 (and therefore
presumably the kernel) are:

lib1: sysent.o and sys4.o (Nov 21 1974) / maybe this change is getpid?
lib2: kl.o (Dec 2 1974)



From tih at hamartun.priv.no  Sun Dec 20 08:44:13 2015
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Sat, 19 Dec 2015 23:44:13 +0100
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <m260zua5hc.fsf@athene.hamartun.priv.no> (Tom Ivar Helbekkmo's
 message of "Sat, 19 Dec 2015 15:16:31 +0100")
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2egeknhk4.fsf@athene.hamartun.priv.no>
 <m260zua5hc.fsf@athene.hamartun.priv.no>
Message-ID: <m2si2y3vpe.fsf@athene.hamartun.priv.no>

I wrote:

> For what it's worth, I've begun.  So far, I've worked backward from
> patchlevel 195 to 177.  I've had to patch files forward from 2.10.1 a
> couple of times, and that's gone without a hitch.

Ran into trouble with patch 141.  The /usr/src/bin/ld.c file from 2.10.1
is too old; patches from between that and the initial 2.11 are missing,
and the file gets deleted and replaced at a later level of 2.11 patches,
breaking the history.  Patch 141 uncovers the problem.

I can make the patches work, of course - but it means that for much of
the resulting 2.11 history, /usr/src/bin/ld.c will be wrong.

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble


From jacob.ritorto at gmail.com  Sun Dec 20 09:55:41 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Sat, 19 Dec 2015 18:55:41 -0500
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <m2si2y3vpe.fsf@athene.hamartun.priv.no>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2egeknhk4.fsf@athene.hamartun.priv.no>
 <m260zua5hc.fsf@athene.hamartun.priv.no>
 <m2si2y3vpe.fsf@athene.hamartun.priv.no>
Message-ID: <CAHYQbfAGPRB5WW7qUcChQuDp=LNVk+72b__AU=ObTStemc3Zqw@mail.gmail.com>

My $0.02:  Stop at exactly where you know it's still completely clean and
document well (i.e. this email copied into a README somewhere with the
distro) what's blocking you.  If you proceed with force, it maligns the
goal, here, which was stated as "pristine."  Many, many thanks for the push
this far, however!

--jake


On Sat, Dec 19, 2015 at 5:44 PM, Tom Ivar Helbekkmo <tih at hamartun.priv.no>
wrote:

> I wrote:
>
> > For what it's worth, I've begun.  So far, I've worked backward from
> > patchlevel 195 to 177.  I've had to patch files forward from 2.10.1 a
> > couple of times, and that's gone without a hitch.
>
> Ran into trouble with patch 141.  The /usr/src/bin/ld.c file from 2.10.1
> is too old; patches from between that and the initial 2.11 are missing,
> and the file gets deleted and replaced at a later level of 2.11 patches,
> breaking the history.  Patch 141 uncovers the problem.
>
> I can make the patches work, of course - but it means that for much of
> the resulting 2.11 history, /usr/src/bin/ld.c will be wrong.
>
> -tih
> --
> Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151219/46b0b44a/attachment.html>

From random832 at fastmail.com  Sun Dec 20 12:41:23 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 19 Dec 2015 21:41:23 -0500
Subject: [TUHS] Pristine version of 2.11BSD
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2egeknhk4.fsf@athene.hamartun.priv.no>
 <m260zua5hc.fsf@athene.hamartun.priv.no>
 <m2si2y3vpe.fsf@athene.hamartun.priv.no>
 <CAHYQbfAGPRB5WW7qUcChQuDp=LNVk+72b__AU=ObTStemc3Zqw@mail.gmail.com>
Message-ID: <m260ztzvsc.fsf@fastmail.com>

Jacob Ritorto writes:
> My $0.02: Stop at exactly where you know it's still completely clean
> and document well (i.e. this email copied into a README somewhere with
> the distro) what's blocking you. If you proceed with force, it maligns
> the goal, here, which was stated as "pristine." Many, many thanks for
> the push this far, however!

Maybe that's one goal, but a pristine copy could just as well be a means
to a different end - e.g. being able to do a "git annotate" on any file
to see what changes were made when.



From jacob.ritorto at gmail.com  Sun Dec 20 22:12:29 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Sun, 20 Dec 2015 07:12:29 -0500
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <m260ztzvsc.fsf@fastmail.com>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2egeknhk4.fsf@athene.hamartun.priv.no>
 <m260zua5hc.fsf@athene.hamartun.priv.no>
 <m2si2y3vpe.fsf@athene.hamartun.priv.no>
 <CAHYQbfAGPRB5WW7qUcChQuDp=LNVk+72b__AU=ObTStemc3Zqw@mail.gmail.com>
 <m260ztzvsc.fsf@fastmail.com>
Message-ID: <CAHYQbfAcAGdHQc=opP51WRD9WmKPbA-qO7TQAdeGPQRgUcjfiA@mail.gmail.com>

On Sat, Dec 19, 2015 at 9:41 PM, Random832 <random832 at fastmail.com> wrote:
>
> Maybe that's one goal, but a pristine copy could just as well be a means
> to a different end - e.g. being able to do a "git annotate" on any file
> to see what changes were made when.
>

Good point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151220/0b06c9c5/attachment.html>

From dugo at xs4all.nl  Mon Dec 21 07:37:54 2015
From: dugo at xs4all.nl (Jacob Goense)
Date: Sun, 20 Dec 2015 22:37:54 +0100
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <m2si2y3vpe.fsf@athene.hamartun.priv.no>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2egeknhk4.fsf@athene.hamartun.priv.no>
 <m260zua5hc.fsf@athene.hamartun.priv.no>
 <m2si2y3vpe.fsf@athene.hamartun.priv.no>
Message-ID: <989f5535948b1e318c6fbf9c7c6cc181@xs4all.nl>

On 2015-12-19 23:44, Tom Ivar Helbekkmo wrote:
> Ran into trouble with patch 141.  The /usr/src/bin/ld.c file from 
> 2.10.1
> is too old; patches from between that and the initial 2.11 are missing,
> and the file gets deleted and replaced at a later level of 2.11 
> patches,
> breaking the history.  Patch 141 uncovers the problem.

Grepping through the utzoo USENET archive I found one patch that might
help piecing this together. Post at http://oldbsd.org/c.b.2bsd.167.txt


From tih at hamartun.priv.no  Mon Dec 21 19:19:45 2015
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Mon, 21 Dec 2015 10:19:45 +0100
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <989f5535948b1e318c6fbf9c7c6cc181@xs4all.nl> (Jacob Goense's
 message of "Sun, 20 Dec 2015 22:37:54 +0100")
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2egeknhk4.fsf@athene.hamartun.priv.no>
 <m260zua5hc.fsf@athene.hamartun.priv.no>
 <m2si2y3vpe.fsf@athene.hamartun.priv.no>
 <989f5535948b1e318c6fbf9c7c6cc181@xs4all.nl>
Message-ID: <m260zsupji.fsf@athene.hamartun.priv.no>

Jacob Goense <dugo at xs4all.nl> writes:

> Grepping through the utzoo USENET archive I found one patch that might
> help piecing this together. Post at http://oldbsd.org/c.b.2bsd.167.txt

I found that one in Google's archive of comp.bugs.2bsd, too -- but
there's a least one ld.c patch still missing, from November 1990.

I just heard from Steven Schultz, who is surprised that we don't have
the original 2.11 distribution in the archive.  Steven says:

> 	I was certain that a base 2.11 is in the TUHS archive.   There was a
> 	tapeset sent down under and I recall someone working on a way to 
> 	simulate a tape drive over a serial line so 2.11 could be loaded.

Does this ring a bell, anyone?

-tih
-- 
Elections cannot be allowed to change anything.  --Dr. Wolfgang Schäuble


From dugo at xs4all.nl  Tue Dec 22 00:06:21 2015
From: dugo at xs4all.nl (Jacob Goense)
Date: Mon, 21 Dec 2015 15:06:21 +0100
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <m260zsupji.fsf@athene.hamartun.priv.no>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2egeknhk4.fsf@athene.hamartun.priv.no>
 <m260zua5hc.fsf@athene.hamartun.priv.no>
 <m2si2y3vpe.fsf@athene.hamartun.priv.no>
 <989f5535948b1e318c6fbf9c7c6cc181@xs4all.nl>
 <m260zsupji.fsf@athene.hamartun.priv.no>
Message-ID: <a5fab516ec719d3573c45079958e1eff@xs4all.nl>

On 2015-12-21 10:19, Tom Ivar Helbekkmo wrote:
> I just heard from Steven Schultz, who is surprised that we don't have
> the original 2.11 distribution in the archive.  Steven says:
> 
>> 	I was certain that a base 2.11 is in the TUHS archive.   There was a
>> 	tapeset sent down under and I recall someone working on a way to
>> 	simulate a tape drive over a serial line so 2.11 could be loaded.
> 
> Does this ring a bell, anyone?

 From the PUPS mailing list archives:

===== cut =====
 Received: from dolphin by minnie.cs.adfa.oz.au (8.6.8/8.3) with SMTP id 
 JAA00214; Tue, 21 Nov 1995 09:19:40 +1100
 Received: by dolphin (5.x/SMI-SVR4)
	id AA13088; Tue, 21 Nov 1995 09:19:42 +1100
 From: wkt at dolphin.cs.adfa.oz.au (Warren Toomey)
 Message-Id: <9511202219.AA13088 at dolphin>
 Subject: Re: mknod device numbers
 To: Milo.Velimirovic at uwlax.edu
 Date: Tue, 21 Nov 1995 09:19:41 +1100 (EST)
 Cc: oldunix at minnie.cs.adfa.oz.au
 In-Reply-To: <9511151722.AA02396 at fingers.acs.uwlax.edu> from "Milo 
 Velimirovic 31 Wing 785-8030" at Nov 15, 95 11:22:22 am
 X-Mailer: ELM [version 2.4 PL23]
 Content-Type: text

In atricle by Milo Velimirovic 31 Wing 785-8030:
> 
> BTW, is there anywhere one can get a "legal license" to run V6, V7, 
> 2.XBSD on
> my pdp11/34's and 11/44?

Nobody, not even Dennis Ritchie, knows how to get a license for any of 
these.
Hopefully, when the Unix source finishes its current migration to SCO 
and HP,
we can ask them for an answer.

P.S Back from holidays, the machine minnie.cs.adfa.oz.au died (out of 
swap)
on Saturday, and I've just rebooted her, so the mailing list is back up.
I've also moved 2.11BSD into the ftp archive on henry.cs.adfa.oz.au. 
Thanks
to Steven Schultz for the copy.

Cheers,
	Warren
===== cut =====



From peter at rulingia.com  Tue Dec 22 05:05:02 2015
From: peter at rulingia.com (Peter Jeremy)
Date: Tue, 22 Dec 2015 06:05:02 +1100
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <a5fab516ec719d3573c45079958e1eff@xs4all.nl>
References: <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2egeknhk4.fsf@athene.hamartun.priv.no>
 <m260zua5hc.fsf@athene.hamartun.priv.no>
 <m2si2y3vpe.fsf@athene.hamartun.priv.no>
 <989f5535948b1e318c6fbf9c7c6cc181@xs4all.nl>
 <m260zsupji.fsf@athene.hamartun.priv.no>
 <a5fab516ec719d3573c45079958e1eff@xs4all.nl>
Message-ID: <20151221190502.GC67307@server.rulingia.com>

On 2015-Dec-21 15:06:21 +0100, Jacob Goense <dugo at xs4all.nl> wrote:
>On 2015-12-21 10:19, Tom Ivar Helbekkmo wrote:
>> I just heard from Steven Schultz, who is surprised that we don't have
>> the original 2.11 distribution in the archive.  Steven says:
>> 
>>> 	I was certain that a base 2.11 is in the TUHS archive.   There was a
>>> 	tapeset sent down under and I recall someone working on a way to
>>> 	simulate a tape drive over a serial line so 2.11 could be loaded.
>> 
>> Does this ring a bell, anyone?
>
> From the PUPS mailing list archives:
> From: wkt at dolphin.cs.adfa.oz.au (Warren Toomey)
>Date: Tue, 21 Nov 1995 09:19:41 +1100 (EST)
...
>I've also moved 2.11BSD into the ftp archive on henry.cs.adfa.oz.au. 

There are several copies of 2.11BSD in the TUHS archives, the oldest appears
to be http://www.tuhs.org/Archive/PDP-11/Boot_Images/2.11_on_rl02/ but
it's at patch level 303.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151222/9408b222/attachment.sig>

From dugo at xs4all.nl  Tue Dec 22 08:30:48 2015
From: dugo at xs4all.nl (Jacob Goense)
Date: Mon, 21 Dec 2015 23:30:48 +0100
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <20151221190502.GC67307@server.rulingia.com>
References: <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2egeknhk4.fsf@athene.hamartun.priv.no>
 <m260zua5hc.fsf@athene.hamartun.priv.no>
 <m2si2y3vpe.fsf@athene.hamartun.priv.no>
 <989f5535948b1e318c6fbf9c7c6cc181@xs4all.nl>
 <m260zsupji.fsf@athene.hamartun.priv.no>
 <a5fab516ec719d3573c45079958e1eff@xs4all.nl>
 <20151221190502.GC67307@server.rulingia.com>
Message-ID: <6aed342543e03173571d464a65d9ccb3@xs4all.nl>

On 2015-12-21 20:05, Peter Jeremy wrote:
> On 2015-Dec-21 15:06:21 +0100, Jacob Goense <dugo at xs4all.nl> wrote:
>> On 2015-12-21 10:19, Tom Ivar Helbekkmo wrote:
>>> I just heard from Steven Schultz, who is surprised that we don't have
>>> the original 2.11 distribution in the archive.  Steven says:
>>> 
>>>> 	I was certain that a base 2.11 is in the TUHS archive.   There was 
>>>> a
>>>> 	tapeset sent down under and I recall someone working on a way to
>>>> 	simulate a tape drive over a serial line so 2.11 could be loaded.
>>> 
>>> Does this ring a bell, anyone?
>> 
>> From the PUPS mailing list archives:
>> From: wkt at dolphin.cs.adfa.oz.au (Warren Toomey)
>> Date: Tue, 21 Nov 1995 09:19:41 +1100 (EST)
> ...
>> I've also moved 2.11BSD into the ftp archive on henry.cs.adfa.oz.au.
> 
> There are several copies of 2.11BSD in the TUHS archives, the oldest 
> appears
> to be http://www.tuhs.org/Archive/PDP-11/Boot_Images/2.11_on_rl02/ but
> it's at patch level 303.

There was at least one older set in the archives.

http://minnie.tuhs.org/PUPS/archive_details.html mentions:

     2.11BSD
     -------

     This is a complete distribution of 2.11BSD up to patch level 277, 
sent in
     by Steven Schultz. The distribution includes the tape bootstrappers.

Patch 277 was from around Oct 28 1995, which closely matches Warren's 
post.

A late 1992 USENET post from Schultz regarding corrupt files in the
base 2.11BSD master tapes doesn't give me the idea they were real 
keepers.
Post at http://oldbsd.org/c.b.2bsd.10ccd2.txt


From wkt at tuhs.org  Tue Dec 22 10:44:59 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 22 Dec 2015 10:44:59 +1000
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <6aed342543e03173571d464a65d9ccb3@xs4all.nl>
References: <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2egeknhk4.fsf@athene.hamartun.priv.no>
 <m260zua5hc.fsf@athene.hamartun.priv.no>
 <m2si2y3vpe.fsf@athene.hamartun.priv.no>
 <989f5535948b1e318c6fbf9c7c6cc181@xs4all.nl>
 <m260zsupji.fsf@athene.hamartun.priv.no>
 <a5fab516ec719d3573c45079958e1eff@xs4all.nl>
 <20151221190502.GC67307@server.rulingia.com>
 <6aed342543e03173571d464a65d9ccb3@xs4all.nl>
Message-ID: <20151222004459.GA22037@minnie.tuhs.org>

On Mon, Dec 21, 2015 at 11:30:48PM +0100, Jacob Goense wrote:
> http://minnie.tuhs.org/PUPS/archive_details.html mentions:
>     2.11BSD
>     This is a complete distribution of 2.11BSD up to patch level 277

I found it on my old backups. I've put it back into the Unix Archive at:

http://www.tuhs.org/Archive/PDP-11/Distributions/ucb/2.11BSD_patch277/

Thanks Jacob for digging up the old details.

Cheers, Warren


From dave at horsfall.org  Wed Dec 23 07:12:33 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 23 Dec 2015 08:12:33 +1100 (EST)
Subject: [TUHS] Pristine version of 2.11BSD
In-Reply-To: <a5fab516ec719d3573c45079958e1eff@xs4all.nl>
References: <20151214095115.GA16979@minnie.tuhs.org>
 <86vb81cofj.fsf@vps34351.public.cloudvps.com>
 <1839042C-5DC4-4B9B-B9F7-C9F47B2BACA2@tuhs.org>
 <0ed060b15f8e284a3008a38f0f58f44f@xs4all.nl>
 <20151217224317.GA29449@minnie.tuhs.org>
 <m2egeknhk4.fsf@athene.hamartun.priv.no>
 <m260zua5hc.fsf@athene.hamartun.priv.no>
 <m2si2y3vpe.fsf@athene.hamartun.priv.no>
 <989f5535948b1e318c6fbf9c7c6cc181@xs4all.nl>
 <m260zsupji.fsf@athene.hamartun.priv.no>
 <a5fab516ec719d3573c45079958e1eff@xs4all.nl>
Message-ID: <alpine.BSF.2.11.1512230802390.69817@aneurin.horsfall.org>

On Mon, 21 Dec 2015, Jacob Goense wrote:

> > Does this ring a bell, anyone?
> 
> From the PUPS mailing list archives:
> 
> ===== cut =====
> Received: from dolphin by minnie.cs.adfa.oz.au (8.6.8/8.3) with SMTP id
> JAA00214; Tue, 21 Nov 1995 09:19:40 +1100

Blimey, but that goes back a bit...

(For the young'uns here, PUPS (PDP Users Preservation Society) predates TUHS.)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From doug at cs.dartmouth.edu  Wed Dec 23 10:27:20 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 22 Dec 2015 19:27:20 -0500
Subject: [TUHS] etymology of cron
Message-ID: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>

I had never doubted that "cron" was a contraction of "chrono-".
Wikipedia, however, offered several folk acronyms on a par
with it. Brian asked Ken, who confirmed,

"cron comes from the prefix (greek?) for time.
it should have been chron, but i never could spell."

I edited Wikipedia to expunge the nonsense. Amusingly that
makes the article less "verifiable" because there had been
literature citations for the nonsense, but there is none
for the fact.

Doug


From grog at lemis.com  Wed Dec 23 10:40:44 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 23 Dec 2015 11:40:44 +1100
Subject: [TUHS] etymology of cron
In-Reply-To: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
References: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
Message-ID: <20151223004044.GG14449@eureka.lemis.com>

On Tuesday, 22 December 2015 at 19:27:20 -0500, Doug McIlroy wrote:
> I had never doubted that "cron" was a contraction of "chrono-".
> Wikipedia, however, offered several folk acronyms on a par
> with it. Brian asked Ken, who confirmed,
>
> "cron comes from the prefix (greek?) for time.
> it should have been chron, but i never could spell."
>
> I edited Wikipedia to expunge the nonsense. Amusingly that makes the
> article less "verifiable" because there had been literature
> citations for the nonsense, but there is none for the fact.

And sadly it has been reverted because it doens't meet Wikipedia
"Reliable Sources" :-(

Can we get ken to post the information here?  Then we would have a
reference for the change.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151223/fda44b39/attachment.sig>

From wkt at tuhs.org  Wed Dec 23 10:46:21 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 23 Dec 2015 10:46:21 +1000
Subject: [TUHS] etymology of cron
In-Reply-To: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
References: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
Message-ID: <20151223004621.GA25017@minnie.tuhs.org>

On Tue, Dec 22, 2015 at 07:27:20PM -0500, Doug McIlroy wrote:
> Brian asked Ken, who confirmed,
> 
> "cron comes from the prefix (greek?) for time.
> it should have been chron, but i never could spell."

Doug, perhaps you could post a sanitised version of the e-mail
here (e-mail addresses removed), so it goes into the list
archive, hence it is visible on the web, hence it can be referred
to as a link in Wikipedia?

Your original e-mail is:
http://minnie.tuhs.org/pipermail/tuhs/2015-December/004741.html

Cheers, Warren


From cowan at mercury.ccil.org  Wed Dec 23 11:11:54 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Tue, 22 Dec 2015 20:11:54 -0500
Subject: [TUHS] etymology of cron
In-Reply-To: <20151223004044.GG14449@eureka.lemis.com>
References: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
 <20151223004044.GG14449@eureka.lemis.com>
Message-ID: <20151223011154.GA9303@mercury.ccil.org>

Greg 'groggy' Lehey scripsit:

> Can we get ken to post the information here?  Then we would have a
> reference for the change.

Internet-only source and a primary source at that.  There's nothing you
can do at this point.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
   There was an old man                Said with a laugh, "I
     From Peru, whose lim'ricks all      Cut them in half, the pay is
       Look'd like haiku.  He              Much better for two."
                                             --Emmet O'Brien


From norman at oclsc.org  Wed Dec 23 11:44:07 2015
From: norman at oclsc.org (Norman Wilson)
Date: Tue, 22 Dec 2015 20:44:07 -0500 (EST)
Subject: [TUHS] etymology of cron
Message-ID: <20151223014407.07322440AE@lignose.oclsc.org>

Perhaps Wikipedia would be satisfied if we could get
Ken to write a letter to some current published journal,
saying that he's the one who named cron, he's heard
people are interested in how it got that name, here's
how.  We could then cite that as a reference.

On the other hand, this may be an example of the
degree to which one should trust Wikipedia.  The
`command run on notice' acronym claim is backed up
by an article from the AUUG (Hi Warren!) Proceedings,
1994, in which the first reference to cron gives
that explanation with no further reference.

If that's the quality of reference they accept, there
is simply no reason to take anything they publish
as gospel.  Sorry.

Norman Wilson
Toronto ON

Proud that no one has yet made a spurious Wikipedia
page asserting the etymology of my personal domain
name.


From grog at lemis.com  Wed Dec 23 11:59:08 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 23 Dec 2015 12:59:08 +1100
Subject: [TUHS] etymology of cron
In-Reply-To: <20151223011154.GA9303@mercury.ccil.org>
References: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
 <20151223004044.GG14449@eureka.lemis.com>
 <20151223011154.GA9303@mercury.ccil.org>
Message-ID: <20151223015908.GH14449@eureka.lemis.com>

On Tuesday, 22 December 2015 at 20:11:54 -0500, John Cowan wrote:
> Greg 'groggy' Lehey scripsit:
>
>> Can we get ken to post the information here?  Then we would have a
>> reference for the change.
>
> Internet-only source and a primary source at that.  There's nothing
> you can do at this point.

There are plenty of other examples of sources from the web.  I suspect
that if Doug had revealed his identity in the commit, it might not
have been backed out.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151223/de0c1bb5/attachment.sig>

From d235j.1 at gmail.com  Wed Dec 23 12:01:24 2015
From: d235j.1 at gmail.com (David Ryskalczyk)
Date: Tue, 22 Dec 2015 21:01:24 -0500
Subject: [TUHS] etymology of cron
In-Reply-To: <20151223015908.GH14449@eureka.lemis.com>
References: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
 <20151223004044.GG14449@eureka.lemis.com>
 <20151223011154.GA9303@mercury.ccil.org>
 <20151223015908.GH14449@eureka.lemis.com>
Message-ID: <C18AFE0B-406F-4E0D-9201-87E2D245FCC7@gmail.com>

An email to this list from ken, or quoting his email here, probably would help, as
that could be cited. Additionally this should be mentioned on the talk page — it
seems rather known that the acronyms may not be all that accurate.

David

> On Dec 22, 2015, at 8:59 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> 
> On Tuesday, 22 December 2015 at 20:11:54 -0500, John Cowan wrote:
>> Greg 'groggy' Lehey scripsit:
>> 
>>> Can we get ken to post the information here?  Then we would have a
>>> reference for the change.
>> 
>> Internet-only source and a primary source at that.  There's nothing
>> you can do at this point.
> 
> There are plenty of other examples of sources from the web.  I suspect
> that if Doug had revealed his identity in the commit, it might not
> have been backed out.
> 
> Greg
> --
> Sent from my desktop computer.
> Finger grog at FreeBSD.org for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft MUA reports
> problems, please read http://tinyurl.com/broken-mua



From lyndon at orthanc.ca  Wed Dec 23 12:07:31 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 22 Dec 2015 18:07:31 -0800
Subject: [TUHS] etymology of cron
In-Reply-To: <20151223014407.07322440AE@lignose.oclsc.org>
References: <20151223014407.07322440AE@lignose.oclsc.org>
Message-ID: <96737DFE-1BAE-45B8-BE15-5E88D898465B@orthanc.ca>


On Dec 22, 2015, at 5:44 PM, Norman Wilson <norman at oclsc.org> wrote:

> If that's the quality of reference they accept, there
> is simply no reason to take anything they publish
> as gospel.  Sorry.

And you are just figuring this out now ;-)  (Yes. Rhetorical. I know!)

I see they finally fixed the bits in the 'Ethernet' entry explaining the reason for the 1518 byte maximum length of an Ethernet frame.  How many Wikipedia authors even know how to *spell* 'vampire tap'?

For even more giggles, search on something like 'what is the reason for the minimum size of an Ethernet frame'.  When I'm bored, I do.  Who can't be impressed by gems like this?:

> Why is a minimum ethernet frame size necessary?
> 
> Answers
> 
>  Best Answer:  By defining the minimum ethernet frame size, you ensure that all necessary information is being transferred at each transmission. The minimum frame size breaks down like this:
> 
> Size is 64 bytes.
> Destination Address (6 bytes)
> Source Address (6 bytes)
> Frame Type (2 bytes)
> Data (46 bytes)
> CRC Checksum (4 bytes)
> 
> 46 bytes must be transmitted at a minumum, with additional pad bytes added to meet frame requirements.
> Source(s):
> 10 years in the IT industry

Who needs Dave Chapelle when you have answers.yahoo.com?!?

--lyndon

P.S.  yahoo.com - the people bringing you DMARC.  Coincidence? I think not!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151222/6a3d0c67/attachment.sig>

From grog at lemis.com  Wed Dec 23 12:14:08 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 23 Dec 2015 13:14:08 +1100
Subject: [TUHS] etymology of cron
In-Reply-To: <C18AFE0B-406F-4E0D-9201-87E2D245FCC7@gmail.com>
References: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
 <20151223004044.GG14449@eureka.lemis.com>
 <20151223011154.GA9303@mercury.ccil.org>
 <20151223015908.GH14449@eureka.lemis.com>
 <C18AFE0B-406F-4E0D-9201-87E2D245FCC7@gmail.com>
Message-ID: <20151223021408.GI14449@eureka.lemis.com>

On Tuesday, 22 December 2015 at 21:01:24 -0500, David Ryskalczyk wrote:

> An email to this list from ken, or quoting his email here, probably
> would help, as that could be cited. Additionally this should be
> mentioned on the talk page ??? it seems rather known that the
> acronyms may not be all that accurate.

I've updated the talk page pointing out what happened.  Pending input
from Doug, I'd suggest that quoting his email alone would be
sufficient.  If the person who backed it out had known who committed
the change, he might not have been so hasty.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151223/b2b20606/attachment.sig>

From milov at cs.uwlax.edu  Wed Dec 23 12:19:11 2015
From: milov at cs.uwlax.edu (Milo Velimirovic)
Date: Tue, 22 Dec 2015 20:19:11 -0600
Subject: [TUHS] etymology of cron
In-Reply-To: <96737DFE-1BAE-45B8-BE15-5E88D898465B@orthanc.ca>
References: <20151223014407.07322440AE@lignose.oclsc.org>
 <96737DFE-1BAE-45B8-BE15-5E88D898465B@orthanc.ca>
Message-ID: <A6A882FF-4BEB-41C0-93F0-FCEEE1363509@cs.uwlax.edu>


> On Dec 22, 2015, at 8:07 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> 
> 
> On Dec 22, 2015, at 5:44 PM, Norman Wilson <norman at oclsc.org> wrote:
> 
>> If that's the quality of reference they accept, there
>> is simply no reason to take anything they publish
>> as gospel.  Sorry.
> 
> And you are just figuring this out now ;-)  (Yes. Rhetorical. I know!)
> 
> I see they finally fixed the bits in the 'Ethernet' entry explaining the reason for the 1518 byte maximum length of an Ethernet frame.  How many Wikipedia authors even know how to *spell* 'vampire tap'?
> 
> For even more giggles, search on something like 'what is the reason for the minimum size of an Ethernet frame'.  When I'm bored, I do.  Who can't be impressed by gems like this?:

Entertainment for you network guys and gals:

https://www.youtube.com/watch?v=SXmv8quf_xM <https://www.youtube.com/watch?v=SXmv8quf_xM>


 - M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151222/628b9e67/attachment.html>

From lyndon at orthanc.ca  Wed Dec 23 12:27:32 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 22 Dec 2015 18:27:32 -0800
Subject: [TUHS] etymology of cron
In-Reply-To: <A6A882FF-4BEB-41C0-93F0-FCEEE1363509@cs.uwlax.edu>
References: <20151223014407.07322440AE@lignose.oclsc.org>
 <96737DFE-1BAE-45B8-BE15-5E88D898465B@orthanc.ca>
 <A6A882FF-4BEB-41C0-93F0-FCEEE1363509@cs.uwlax.edu>
Message-ID: <2D97F623-1430-457C-B105-E93A0589B9F6@orthanc.ca>


On Dec 22, 2015, at 6:19 PM, Milo Velimirovic <milov at cs.uwlax.edu> wrote:

> Entertainment for you network guys and gals:
> 
> https://www.youtube.com/watch?v=SXmv8quf_xM

Don't laugh.  These days he is the head of Intellectual Property Enforcement for Sony.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151222/9c899435/attachment.sig>

From jason-tuhs at shalott.net  Wed Dec 23 12:32:02 2015
From: jason-tuhs at shalott.net (jason-tuhs at shalott.net)
Date: Tue, 22 Dec 2015 18:32:02 -0800 (PST)
Subject: [TUHS] etymology of cron
In-Reply-To: <20151223021408.GI14449@eureka.lemis.com>
References: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
 <20151223004044.GG14449@eureka.lemis.com>
 <20151223011154.GA9303@mercury.ccil.org>
 <20151223015908.GH14449@eureka.lemis.com>
 <C18AFE0B-406F-4E0D-9201-87E2D245FCC7@gmail.com>
 <20151223021408.GI14449@eureka.lemis.com>
Message-ID: <alpine.LRH.2.20.1512221826520.8927@waffle.shalott.net>


> If the person who backed it out had known who committed the change, he 
> might not have been so hasty.

Unfortunately, that's not how Wikipedia works.

See, for example, this story about an author who was told he "was not a 
credible source" regarding the basis of his own writings -- not because 
there was any doubt about his identity, but because Wikipedia "require[s] 
secondary sources."

http://www.newyorker.com/books/page-turner/an-open-letter-to-wikipedia


  -Jason



From lyndon at orthanc.ca  Wed Dec 23 12:44:46 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Tue, 22 Dec 2015 18:44:46 -0800
Subject: [TUHS] etymology of cron
In-Reply-To: <alpine.LRH.2.20.1512221826520.8927@waffle.shalott.net>
References: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
 <20151223004044.GG14449@eureka.lemis.com>
 <20151223011154.GA9303@mercury.ccil.org>
 <20151223015908.GH14449@eureka.lemis.com>
 <C18AFE0B-406F-4E0D-9201-87E2D245FCC7@gmail.com>
 <20151223021408.GI14449@eureka.lemis.com>
 <alpine.LRH.2.20.1512221826520.8927@waffle.shalott.net>
Message-ID: <FD285D50-598D-453D-9D3B-569E8BA78F9F@orthanc.ca>


On Dec 22, 2015, at 6:32 PM, jason-tuhs at shalott.net wrote:

> Unfortunately, that's not how Wikipedia works.

And that's why Wikipedia is an entertainment venue.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151222/e1b57eff/attachment.sig>

From grog at lemis.com  Wed Dec 23 12:36:39 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 23 Dec 2015 13:36:39 +1100
Subject: [TUHS] etymology of cron
In-Reply-To: <2D97F623-1430-457C-B105-E93A0589B9F6@orthanc.ca>
References: <20151223014407.07322440AE@lignose.oclsc.org>
 <96737DFE-1BAE-45B8-BE15-5E88D898465B@orthanc.ca>
 <A6A882FF-4BEB-41C0-93F0-FCEEE1363509@cs.uwlax.edu>
 <2D97F623-1430-457C-B105-E93A0589B9F6@orthanc.ca>
Message-ID: <20151223023639.GJ14449@eureka.lemis.com>

On Tuesday, 22 December 2015 at 18:27:32 -0800, Lyndon Nerenberg wrote:
>
> On Dec 22, 2015, at 6:19 PM, Milo Velimirovic <milov at cs.uwlax.edu> wrote:
>
>> Entertainment for you network guys and gals:
>>
>> https://www.youtube.com/watch?v=SXmv8quf_xM
>
> Don't laugh.  These days he is the head of Intellectual Property
> Enforcement for Sony.

Somehow that reminds me of SCO's âproofâ of IBM's intellectual
property violation.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151223/2c6ed730/attachment.sig>

From cowan at mercury.ccil.org  Wed Dec 23 12:59:21 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Tue, 22 Dec 2015 21:59:21 -0500
Subject: [TUHS] etymology of cron
In-Reply-To: <alpine.LRH.2.20.1512221826520.8927@waffle.shalott.net>
References: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
 <20151223004044.GG14449@eureka.lemis.com>
 <20151223011154.GA9303@mercury.ccil.org>
 <20151223015908.GH14449@eureka.lemis.com>
 <C18AFE0B-406F-4E0D-9201-87E2D245FCC7@gmail.com>
 <20151223021408.GI14449@eureka.lemis.com>
 <alpine.LRH.2.20.1512221826520.8927@waffle.shalott.net>
Message-ID: <20151223025921.GB9303@mercury.ccil.org>

jason-tuhs at shalott.net scripsit:

> See, for example, this story about an author who was told he "was
> not a credible source" regarding the basis of his own writings --

Indeed.  John "Lisp" McCarthy definitely couldn't remember the order
and timing of his work on Lisp without reference to his documents.
Or rather he did remember, but his memories were wrong.  Primary sources
have to be used with care and caution, and while they are not outright
forbidden on Wikipedia, they are not trivial to use.

Wikipedia is by nature a *summary of the published literature*.  If you
want to get some folklore, like what "cron" stands for, into Wikipedia,
then publish a folklore article in a journal, book, or similar reputable
publication.  Random uncontrolled mailing lists simply do not count.

> http://www.newyorker.com/books/page-turner/an-open-letter-to-wikipedia

    The poet may of course have some critical ability of his own, and
    so be able to talk about his own work. But the Dante who writes a
    commentary on the first canto of the Paradiso is merely one more
    of Dante's critics. What he says has a peculiar interest, but
    not a peculiar authority. It is generally accepted that a critic
    is a better judge of the value of a poem than its creator, but
    there is still a lingering notion that it is somehow ridiculous
    to regard the critic as the final judge of its meaning, even
    though in practice it is clear that he must be. The reason
    for this is an inability to distinguish literature from the
    descriptive or assertive writing which derives from the active
    will and the conscious mind, and which is primarily concerned to
    "say" something.

        --Northrop Frye, _Anatomy of Criticism_
-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
If I read "upcoming" in [the newspaper] once more, I will be downcoming
and somebody will be outgoing.


From random832 at fastmail.com  Wed Dec 23 14:05:57 2015
From: random832 at fastmail.com (Random832)
Date: Tue, 22 Dec 2015 23:05:57 -0500
Subject: [TUHS] etymology of cron
In-Reply-To: <20151223025921.GB9303@mercury.ccil.org>
References: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
 <20151223004044.GG14449@eureka.lemis.com>
 <20151223011154.GA9303@mercury.ccil.org>
 <20151223015908.GH14449@eureka.lemis.com>
 <C18AFE0B-406F-4E0D-9201-87E2D245FCC7@gmail.com>
 <20151223021408.GI14449@eureka.lemis.com>
 <alpine.LRH.2.20.1512221826520.8927@waffle.shalott.net>
 <20151223025921.GB9303@mercury.ccil.org>
Message-ID: <1450843557.2182645.474607945.01DCBBC4@webmail.messagingengine.com>

On Tue, Dec 22, 2015, at 21:59, John Cowan wrote:
> Wikipedia is by nature a *summary of the published literature*.  If you
> want to get some folklore, like what "cron" stands for, into Wikipedia,
> then publish a folklore article in a journal, book, or similar reputable
> publication.  Random uncontrolled mailing lists simply do not count.

The problem is this backronym is the sort of nonsense that attaches to
_all_ computer commands that are not an English word (and a fair few
that are), and that should heavily weigh against the use of people's
willingness to uncritically repeat them in print as a "reliable source".

It may be reasonable, in Wikipedia's role as a "summary of the published
literature", to say something like "some people have suggested" that it
may be an acronym, and to list the sources there, but certainly _not_ to
assert that it was actually intended as one without a source actually
traceable to someone in a position to know.


From cowan at mercury.ccil.org  Wed Dec 23 14:27:02 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Tue, 22 Dec 2015 23:27:02 -0500
Subject: [TUHS] etymology of cron
In-Reply-To: <1450843557.2182645.474607945.01DCBBC4@webmail.messagingengine.com>
References: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
 <20151223004044.GG14449@eureka.lemis.com>
 <20151223011154.GA9303@mercury.ccil.org>
 <20151223015908.GH14449@eureka.lemis.com>
 <C18AFE0B-406F-4E0D-9201-87E2D245FCC7@gmail.com>
 <20151223021408.GI14449@eureka.lemis.com>
 <alpine.LRH.2.20.1512221826520.8927@waffle.shalott.net>
 <20151223025921.GB9303@mercury.ccil.org>
 <1450843557.2182645.474607945.01DCBBC4@webmail.messagingengine.com>
Message-ID: <20151223042701.GC9303@mercury.ccil.org>

Random832 scripsit:

> It may be reasonable, in Wikipedia's role as a "summary of the published
> literature", to say something like "some people have suggested" that it
> may be an acronym, and to list the sources there, but certainly _not_ to
> assert that it was actually intended as one without a source actually
> traceable to someone in a position to know.

Well, as of now it says:

    The origin of the name cron is unclear;[2] it has been suggested
    that it comes from the Greek word for time, χρόνος
    chronos,[3] or that it is an acronym for "Command Run On
    Notice"[4] or for "Commands Run Over Night".[2][discuss]

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Mark Twain on Cecil Rhodes: I admire him, I freely admit it,
and when his time comes I shall buy a piece of the rope for a keepsake.


From lm at mcvoy.com  Wed Dec 23 14:53:41 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 22 Dec 2015 20:53:41 -0800
Subject: [TUHS] etymology of cron
In-Reply-To: <20151223014407.07322440AE@lignose.oclsc.org>
References: <20151223014407.07322440AE@lignose.oclsc.org>
Message-ID: <20151223045341.GC1873@mcvoy.com>

As a guy who has donated money to Wikipedia this whole thread makes
me not want to donate again.  Just me being grumpy.

On Tue, Dec 22, 2015 at 08:44:07PM -0500, Norman Wilson wrote:
> Perhaps Wikipedia would be satisfied if we could get
> Ken to write a letter to some current published journal,
> saying that he's the one who named cron, he's heard
> people are interested in how it got that name, here's
> how.  We could then cite that as a reference.
> 
> On the other hand, this may be an example of the
> degree to which one should trust Wikipedia.  The
> `command run on notice' acronym claim is backed up
> by an article from the AUUG (Hi Warren!) Proceedings,
> 1994, in which the first reference to cron gives
> that explanation with no further reference.
> 
> If that's the quality of reference they accept, there
> is simply no reason to take anything they publish
> as gospel.  Sorry.
> 
> Norman Wilson
> Toronto ON
> 
> Proud that no one has yet made a spurious Wikipedia
> page asserting the etymology of my personal domain
> name.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From will.senn at gmail.com  Wed Dec 23 16:13:50 2015
From: will.senn at gmail.com (Will Senn)
Date: Wed, 23 Dec 2015 00:13:50 -0600
Subject: [TUHS] Does anybody recall how the TU10 bootstrap code actually
	operates?
Message-ID: <567A3B9E.4000401@gmail.com>

All,

I am in the process of gaining a deeper understanding of PDP-11 machine 
instructions and how the bootstrap loader and its cousins function. As 
part of that process, I am analyzing the code. I am concurrently working 
through the DEC bootstrap loader and the bootstrap loader that is 
described in the v6 documentation. The DEC bootstrap loader, while 
fascinating and elegant, is relatively straightforward, given its 
enormous range and the fact that it is self-modifying. I wrote up my 
preliminary notes here:

http://decuser.blogspot.com/2015/12/analysis-of-pdp-11-bootloader-code.html

The code that is in the v6 documentation on the other hand is not 
yielding easily to reasonable interpretation and I was hoping y'all 
might be able to shed some light on how it works.

The following is the TU10 (TM11) bootstrap code from "Setting Up Unix - 
Sixth Edition":
TU10
012700
172526
010040
012740
060003
000777

The author's notes around the code are:
The tape should move and the CPU loop. (The TU10 code is not the DEC 
bulk ROM for tape; it reads block 0, not block 1.)
Halt and restart the CPU at 0. The tape should rewind. The console 
should type ‘=’.

Of course, following the instructions results in a successful outcome, 
but understanding what is happening is difficult given that this is a 
virtual environment and no discernible tape movement can be detected.

My attempt at interpretation is along the following lines, I 
manufactured the dissasembly based on my reading of the PDP-11/40 
handbook and the machine codes:

012700  MOV #172526, R0 ; moves the TM11 Current Memory Address Register 
(MTCMA) address into R0
172526                                  ; the immediate operand
010040  MOV R0,-(R0)        ; moves the contents of R0, 172526, into 
memory location 172524, the TM11 Byte Record Counter (MTBRC)
012740  MOV #60003,-(R0); moves 60003 into memory location 172522, the 
TM11 Command Register (MTC)
060003                                   ; immediate data
000777  HALT

This seems like gobbledegook to me. It moves the MTCMA (Magtape Current 
Memory Address) into R0, then it moves the MTCMA into the MTBRC (Magtape 
Byte Record Count), then it moves 60003 into the MTC (Magtape control 
register), which causes a read operation with 800BPI 9 Channel density. 
172526 is -5252 in 2's complement.

Am I misinterpreting the byte codes or is this some idiosyncratic way to 
get the Magnetic tape to rewind or something (the TM11 has a control 
function to rewind, so it seems unlikely that this is the case, but I'm 
mystified)?

I single stepped through the code in the simulator, and the TM11 
registers appear to be pretty unobservable (examining these three 
registers always displays 0's, but if I change from referencing the TM11 
registers to another area of memory, say 100500 I see the values I would 
expect to see as they are being moved from the registers into memory).

Thanks,

Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151223/6f3fefdc/attachment.html>

From dave at horsfall.org  Wed Dec 23 16:47:38 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 23 Dec 2015 17:47:38 +1100 (EST)
Subject: [TUHS] etymology of cron
In-Reply-To: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
References: <201512230027.tBN0RK7A009917@tahoe.cs.Dartmouth.EDU>
Message-ID: <alpine.BSF.2.11.1512231741250.69817@aneurin.horsfall.org>

On Tue, 22 Dec 2015, Doug McIlroy wrote:

> "cron comes from the prefix (greek?) for time. it should have been 
> chron, but i never could spell."

Yep, from the Greek god of time, Chronos.

> I edited Wikipedia to expunge the nonsense. Amusingly that makes the 
> article less "verifiable" because there had been literature citations 
> for the nonsense, but there is none for the fact.

Does anyone actually believe Wikipedia these days?  Any fool can update 
it, and they do...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From jnc at mercury.lcs.mit.edu  Wed Dec 23 16:59:57 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 23 Dec 2015 01:59:57 -0500 (EST)
Subject: [TUHS] Does anybody recall how the TU10 bootstrap code actually
	operates?
Message-ID: <20151223065957.5ED5718C095@mercury.lcs.mit.edu>

    > From: Will Senn

    > 000777  HALT

That's actually "BR ."; the difference is important, since the CPU (IIRC)
doesn't honour DMA requests when it is halted, and DMA needs to be working for
the controller to read that first block (a secondary tape bootstrap) into
memory.

    > This seems like gobbledegook to me.

:-)

    > It moves the MTCMA (Magtape Current Memory Address) into R0, then it
    > moves the MTCMA into the MTBRC (Magtape Byte Record Count)

"The address of the MTCMA into", etc. Looking quickly at the programming spec
for the TM11 controllers, it wants a negative of the byte count to transfer in
this register; the address of the MTCMA just happens to also be a large enough
negative number to be usable as the (negative) size of the transfer request.
(The first record is probably shorter than that, but that doesn't matter.)

Note that this code could probably also have been written:

    MOV #172524, R0
    MOV R0, at R0

and been equally functional.

    > then it moves 60003 into the MTC (Magtape control register), which
    > causes a read operation with 800BPI 9 Channel density.

I'm too lazy to look at the programming spec for the details, but that sounds
right.

    > Am I misinterpreting the byte codes or is this some idiosyncratic way to
    > get the Magnetic tape to rewind or something (the TM11 has a control
    > function to rewind, so it seems unlikely that this is the case

No, it's just the shortest possible program to read the first block off the
tape.

It depends on i) the operator having manually set the tape to the right point
(the start of the tape), so that it's the first block that gets read, and ii)
the fact that the reset performed by hitting the 'Start' key on the CPU clears
the TM11 registers, including the Current Memory Address register, so the
block that's read is read into memory location zero.

Hence the direction to 'once the tape has stopped moving, re-start the CPU at
0'.

	Noel


From norman at oclsc.org  Wed Dec 23 23:30:36 2015
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 23 Dec 2015 08:30:36 -0500 (EST)
Subject: [TUHS] etymology of cron
Message-ID: <20151223133036.BFF25440AE@lignose.oclsc.org>

Larry McVoy:

  As a guy who has donated money to Wikipedia this whole thread makes
  me not want to donate again.  Just me being grumpy.

====

Me too.

Perhaps we should start our own online encyclopedia.
In the Ken tradition we could call it pedi.
(pdia sounds better, but pdia.org is already taken.)

Norman Wilson
Toronto ON


From norman at oclsc.org  Wed Dec 23 23:36:03 2015
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 23 Dec 2015 08:36:03 -0500 (EST)
Subject: [TUHS] etymology of cron
Message-ID: <20151223133603.B1BFE440AE@lignose.oclsc.org>

John Cowan:

  Wikipedia is by nature a *summary of the published literature*.  If you
  want to get some folklore, like what "cron" stands for, into Wikipedia,
  then publish a folklore article in a journal, book, or similar reputable
  publication.  Random uncontrolled mailing lists simply do not count.

======

That sounds fair enough on the surface.

But if you follow the references cited to support the cron
acronyms, you find that random unsupported assertions in
conference papers do count.  That's not a lot better.

I'd like to see a published, citable reference for the
true origin of `cron'.  Even better, better published
material for a lot of the charming minutiae of the early
days of UNIX.  (Anyone feel up to interviewing Doug and
Ken and Brian and whoever else is left, and writing it up
for publication in ;login:?)

But I'd be satisfied if we could somehow stamp out the
use of spurious references to support spurious claims.
If I had the time and energy I'd look into how to challenge
the cron acronyms on those grounds.  Any volunteers?

Norman Wilson
Toronto ON


From clemc at ccc.com  Wed Dec 23 23:45:13 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 23 Dec 2015 08:45:13 -0500
Subject: [TUHS] etymology of cron
In-Reply-To: <20151223045341.GC1873@mcvoy.com>
References: <20151223014407.07322440AE@lignose.oclsc.org>
 <20151223045341.GC1873@mcvoy.com>
Message-ID: <CAC20D2MpS8x7VYywmAwx-FGaicSPeTEGcvBBhAaqA1iAB8w78w@mail.gmail.com>

ditto and +1

On Tue, Dec 22, 2015 at 11:53 PM, Larry McVoy <lm at mcvoy.com> wrote:

> As a guy who has donated money to Wikipedia this whole thread makes
> me not want to donate again.  Just me being grumpy.
>
> On Tue, Dec 22, 2015 at 08:44:07PM -0500, Norman Wilson wrote:
> > Perhaps Wikipedia would be satisfied if we could get
> > Ken to write a letter to some current published journal,
> > saying that he's the one who named cron, he's heard
> > people are interested in how it got that name, here's
> > how.  We could then cite that as a reference.
> >
> > On the other hand, this may be an example of the
> > degree to which one should trust Wikipedia.  The
> > `command run on notice' acronym claim is backed up
> > by an article from the AUUG (Hi Warren!) Proceedings,
> > 1994, in which the first reference to cron gives
> > that explanation with no further reference.
> >
> > If that's the quality of reference they accept, there
> > is simply no reason to take anything they publish
> > as gospel.  Sorry.
> >
> > Norman Wilson
> > Toronto ON
> >
> > Proud that no one has yet made a spurious Wikipedia
> > page asserting the etymology of my personal domain
> > name.
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151223/988ba980/attachment.html>

From clemc at ccc.com  Wed Dec 23 23:53:41 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 23 Dec 2015 08:53:41 -0500
Subject: [TUHS] etymology of cron
In-Reply-To: <20151223133603.B1BFE440AE@lignose.oclsc.org>
References: <20151223133603.B1BFE440AE@lignose.oclsc.org>
Message-ID: <CAC20D2N=06vZ0+Q3-VP224Le-Fpj1KNB7=k3hv6p1sNU5bFOcA@mail.gmail.com>

On Wed, Dec 23, 2015 at 8:36 AM, Norman Wilson <norman at oclsc.org> wrote:

> I'd like to see a published, citable reference for the
> true origin of `cron'.  Even better, better published
> material for a lot of the charming minutiae of the early
> days of UNIX.  (Anyone feel up to interviewing Doug and
> Ken and Brian and whoever else is left, and writing it up
> for publication in ;login:?)
>

​I just sent Rik a note and asked him to make it so.

Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151223/625a96bf/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu Dec 24 00:38:02 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 23 Dec 2015 09:38:02 -0500 (EST)
Subject: [TUHS] etymology of cron
Message-ID: <20151223143802.4FD6018C096@mercury.lcs.mit.edu>

    On Dec 22, 2015, at 5:44 PM, Norman Wilson <norman at oclsc.org> wrote:

    > If that's the quality of reference they accept, there is simply no
    > reason to take anything they publish as gospel.

You're mistaking Wikipedia for an information source you can rely on. It's
not. It's more akin to an attempt to prove that an infinite number of
monkeys, with an infinite number of typewriters, and an infinite amount of
time, can produce a reliable encyclopaedia.

(Yes, yes, spare me the surveys that show that Wikipedia's error rates aren't
that bad, when compared with other encyclopaedias, etc.)

Don't get me wrong, Wikipedia is quite useful as a place for an
_introduction_ to any topic, but anyone who really wants to _reliably_ know
anything about a topic needs to look at the references, not the articles.

There was an attempt to do a Wikipedia-like online encyclopaedia that one
could rely on - Citizendium - but alas it doesn't seem to have taken off (or
hadn't when I got distracted from working on it).

And I know whereof I speak; those who wish to be amused may want to read:

  http://en.wikipedia.org/wiki/User:Jnc/Astronomer_vs_Amateur

And apologies for continuing the off-topic (this group certainly can't fix
Wikipedia, people have been complaining about this problem for many years
now), but some buttons, you just have to respond when they are pushed...

	Noel


From will.senn at gmail.com  Thu Dec 24 01:03:13 2015
From: will.senn at gmail.com (Will Senn)
Date: Wed, 23 Dec 2015 09:03:13 -0600
Subject: [TUHS] Does anybody recall how the TU10 bootstrap code actually
 operates?
In-Reply-To: <20151223065957.5ED5718C095@mercury.lcs.mit.edu>
References: <20151223065957.5ED5718C095@mercury.lcs.mit.edu>
Message-ID: <567AB7B1.2050907@gmail.com>

Noel,

Comments inline. This has got to be the most helpful mailing list ever. 
Thank you for responding so carefully.

On 12/23/15 12:59 AM, Noel Chiappa wrote:
>      > From: Will Senn
>
>      > 000777  HALT
>
> That's actually "BR ."; the difference is important, since the CPU (IIRC)
> doesn't honour DMA requests when it is halted, and DMA needs to be working for
> the controller to read that first block (a secondary tape bootstrap) into
> memory.

This one, I worked through in my dreams :). I woke up this morning with 
the full-fledged thought, 000777 isn't halt, it's a branch to the new PC 
+ (2 * offset,  377) - I have been reading the PDP-11/40 handbook, much 
too much :):

0004 BR to PC+2 + (2* Offset of the next six bits, 377)
  3   7   7 - offset in octal
11 111 111 - binary equivalent
00 000 000 - 1's complement
00 000 001 - 2's complement
----------
         -1

So: BR, PC+2 +( 2 * - 1), or .+2-2, or BR . as you say.

>      > This seems like gobbledegook to me.
>
> :-)
>
>      > It moves the MTCMA (Magtape Current Memory Address) into R0, then it
>      > moves the MTCMA into the MTBRC (Magtape Byte Record Count)
>
> "The address of the MTCMA into", etc. Looking quickly at the programming spec
> for the TM11 controllers, it wants a negative of the byte count to transfer in
> this register; the address of the MTCMA just happens to also be a large enough
> negative number to be usable as the (negative) size of the transfer request.
> (The first record is probably shorter than that, but that doesn't matter.)
>
> Note that this code could probably also have been written:
>
>      MOV #172524, R0
>      MOV R0, at R0
>
> and been equally functional.
>
>      > then it moves 60003 into the MTC (Magtape control register), which
>      > causes a read operation with 800BPI 9 Channel density.
>
> I'm too lazy to look at the programming spec for the details, but that sounds
> right.
>
>      > Am I misinterpreting the byte codes or is this some idiosyncratic way to
>      > get the Magnetic tape to rewind or something (the TM11 has a control
>      > function to rewind, so it seems unlikely that this is the case
>
> No, it's just the shortest possible program to read the first block off the
> tape.
Actually, after reflecting on your comments and walking through it 
again, this is really elegant code. The guys who thought this up were 
amazing.  Using the MTCMA is brilliant, as you said, it's a big enough 
negative value to cause the entire block to be read, but it's also the 
value that is used to obtain the destination for that byte count through 
it's decrement and further, to obtain the destination for the command to 
read the data after it's second decrement.
> It depends on i) the operator having manually set the tape to the right point
> (the start of the tape), so that it's the first block that gets read, and ii)
> the fact that the reset performed by hitting the 'Start' key on the CPU clears
> the TM11 registers, including the Current Memory Address register, so the
> block that's read is read into memory location zero.
>
> Hence the direction to 'once the tape has stopped moving, re-start the CPU at
> 0'.
>
> 	Noel
In order to test this and armed with my newfound knowledge, I fired up 
SimH and attached the v6 distribution tape and set it locked for read 
only. I examined memory from 0-100, which was empty. I then deposited 
the bootstrap and ran it. It hung, allowing the NPR. I then stopped the 
CPU with CTRL-E and examined the memory starting at location 0, voila, a 
407 program starting at byte 0. My understanding at this point is that 
the program never touches MTCMA (other than to use it for the byte count 
and decrements) so it is initially 0 based on how SimH works and the 
program simply reads the first block into memory in location 0 and hangs 
until the simulator is suspended.

The next step in the install is to g 0, which runs a program that prints 
the = prompt to which tmrk is a reasonable response. I gather the 407 
program is some kind of minimalist shell that includes tmrk as one of 
its commands.

Thanks again for your help.

Will





From cowan at mercury.ccil.org  Thu Dec 24 01:58:52 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Wed, 23 Dec 2015 10:58:52 -0500
Subject: [TUHS] Does anybody recall how the TU10 bootstrap code actually
 operates?
In-Reply-To: <567AB7B1.2050907@gmail.com>
References: <20151223065957.5ED5718C095@mercury.lcs.mit.edu>
 <567AB7B1.2050907@gmail.com>
Message-ID: <20151223155852.GA6677@mercury.ccil.org>

Will Senn scripsit:

> Actually, after reflecting on your comments and walking through it
> again, this is really elegant code. The guys who thought this up
> were amazing.  

As usual, they were standing on the shoulders of giants.  The OS/8
bootstrap (on the PDP-8) for the RK8E disk controller was even more
elegant, only two instructions long and requiring no further operator
actions but "clear" and "start".  The first instruction simply read
the current block into the current memory address, which because of
the "clear" read block 0 into memory location 0; the second was also
a branch-to-self.

But the real cleverness was that the bootstrap was placed at locations
30 and 31.  As the disk block was read in by DMA, location 30 was
overwritten with the "skip if disk is ready" instruction and location
31 with "branch to previous location".  So first the CPU was idling in
a one-instruction infinite loop, then in a two-instruction loop as long
as the block was still loading, and finally would continue executing at
location 32 when the disk bootstrap was fully loaded.  The code there
loaded the full device driver for the RK8E into reserved memory at
07600-07777 and jumped to the code within it that loaded the Keyboard
Monitor (the shell) at location 0 and jumped into it.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
A rose by any other name may smell as sweet, but if you called it
an onion you'd get cooks very confused.          --RMS


From cowan at mercury.ccil.org  Thu Dec 24 02:04:36 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Wed, 23 Dec 2015 11:04:36 -0500
Subject: [TUHS] etymology of cron
In-Reply-To: <20151223133603.B1BFE440AE@lignose.oclsc.org>
References: <20151223133603.B1BFE440AE@lignose.oclsc.org>
Message-ID: <20151223160436.GB6677@mercury.ccil.org>

Norman Wilson scripsit:

> But if you follow the references cited to support the cron acronyms, you
> find that random unsupported assertions in conference papers do count.
> That's not a lot better.

Well, of course there are conferences and there are conferences.  The
only conference I've ever had a paper published at, Balisage, is as
peer-reviewed as any journal.  (And it is gold open access and doesn't
charge for pages -- the storage costs are absorbed as conference overhead.)

> I'd like to see a published, citable reference for the true origin
> of `cron'.  Even better, better published material for a lot of the
> charming minutiae of the early days of UNIX.  (Anyone feel up to
> interviewing Doug and Ken and Brian and whoever else is left, and
> writing it up for publication in ;login:?)

It can't be just raw oral history, though, or it's a primary source again.
People's memories *are* fallible.  It's got to to be legitimate historical
research.

> But I'd be satisfied if we could somehow stamp out the use of spurious
> references to support spurious claims.

I suppose you could get the original author(s) to print a retraction.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
If [Tim Berners-Lee] has seen farther than others,
        it is because he is standing on a stack of dwarves.  --Mike Champion


From bqt at update.uu.se  Thu Dec 24 03:09:56 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Wed, 23 Dec 2015 18:09:56 +0100
Subject: [TUHS] etymology of cron
In-Reply-To: <mailman.20.1450886678.3292.tuhs@minnie.tuhs.org>
References: <mailman.20.1450886678.3292.tuhs@minnie.tuhs.org>
Message-ID: <567AD564.1030003@update.uu.se>

On 2015-12-23 17:04, norman at oclsc.org  (Norman Wilson) wrote:
> John Cowan:
>
>    Wikipedia is by nature a*summary of the published literature*.  If you
>    want to get some folklore, like what "cron" stands for, into Wikipedia,
>    then publish a folklore article in a journal, book, or similar reputable
>    publication.  Random uncontrolled mailing lists simply do not count.
>
> ======
>
> That sounds fair enough on the surface.
>
> But if you follow the references cited to support the cron
> acronyms, you find that random unsupported assertions in
> conference papers do count.  That's not a lot better.

I've had similar experiences with Wikipedia in the past. At one point I 
was trying to get the PDP-11 article corrected, as it said that the 
PDP-11 was an architecture that disappeared in the 80s (paraphrasing). I 
pointed out that the last *new* PDP-11 model from DEC itself was 
released in 1990, and that others are still making new PDP-11 CPUs.

My corrections were reverted, and I was asked for citations. I went 
through a silly loop of requests for sources for my claims, while there 
seems to have been no demand for citation for the original claims, more 
than the "knowledge" of someone. It wasn't until I dug up the system 
manuals and documentation from DEC about the PDP-11/93 and PDP-11/94 
(which have actual time of original publishing date printed) that my 
claims were (somewhat) accepted.

I've also had numerous fights about the Wikipedia articles about virtual 
memory, where the original authors on the article clearly had not 
understood the difference between virtual memory and demand paged 
memory. The articles are better today, but when I last looked, they 
still had some details wrong in there. And getting anything corrected is 
hell, as any silly statement that is already in is almost regarded as 
gospel, and anything you try to correct is questioned to hell and back 
before anyone will accept it. (Hey, according to Wikipedia, a PDP-11 do 
not have virtual memory... I wonder what it has then. Fake memory? 
Although, the article might now actually accept that a PDP-11 do have 
virtual memory, although no OS I know of implements demand paging, but 
that could be done as well, if anyone wanted to.)

Nowadays, I use Wikipedia to find information, but just take everything 
in there with a large grain of salt when it comes to details. There are 
just too many ignorant people who are writing stuff, and who seem to get 
anything accepted, and too much hassle to get anything corrected when 
you actually knows the subject.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From norman at oclsc.org  Thu Dec 24 03:19:50 2015
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 23 Dec 2015 12:19:50 -0500
Subject: [TUHS] etymology of cron
Message-ID: <1450891193.26287.for-standards-violators@oclsc.org>

John Cowan:

  Well, of course there are conferences and there are conferences.  The
  only conference I've ever had a paper published at, Balisage, is as
  peer-reviewed as any journal.  (And it is gold open access and doesn't
  charge for pages -- the storage costs are absorbed as conference overhead.)

====

Have you actually looked up the cited reference?

The trouble is not that it's a conference paper.  The trouble is
that that the `authority' being cited is just a random assertion,
not backed up.

It's as if I mentioned your name in a paper about something else,
remarked in passing and without any citation of my own that you have
a wooden leg, and Wikipedia accepted that as proof of your prosthesis.

Norman Wilson
Toronto ON
(Four limbs and eight eyes, thank you very much)


From jnc at mercury.lcs.mit.edu  Thu Dec 24 04:02:48 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 23 Dec 2015 13:02:48 -0500 (EST)
Subject: [TUHS] Does anybody recall how the TU10 bootstrap code actually
	operates?
Message-ID: <20151223180248.CB9C018C092@mercury.lcs.mit.edu>

    > Thank you for responding so carefully.

The devil is in the details...

    > I have been reading the PDP-11/40 handbook, much too much :)

I'm not sure that's possible! :-)

Yes, yes, I know, the architecture is deader than a doornail for serious use,
but I liken it to sailing vessels: nobody uses them for serious cargo haul any
more, but they are still much beloved (and for good reasons, IMO).

The PDP-11 is an incredibly elegant architecture, perhaps the best ever (IMO),
which remains one of the very best examples ever of how to get 30 pounds into
the proverbial ten-pount sack - like early UNIX (more below).

    > this is really elegant code. The guys who thought this up were amazing.

Nah, it's just a clever hack (small-scale).  What is really, almost
un-approachably, brilliant about early UNIX is the amount of functionality
they got into such a small machine.

It's hard to really appreciate, now, the impact UNIX had when it first
appeared on the scene: just as it's impossible for people who didn't
themselves actually experience the pre-Internet world to _really_ appreciate
what it was like (even turning off all one's computers for a day only
approximates it). I think only people who lived with prior 'small computer
OS's' could really grasp what a giant leap it was, compared to what came
before.

I remember first being shown it in circa 1975 or so, and just being utterly
blown away: the ability to trivially add arbitrary commands, I/O redirection,
invisibly mountable sections of the directory tree - the list just goes on and
on. Heck, it was better than all but a few 'big machine' OS's!

    > Thanks again for your help.

Eh, de nada.

	Noel


From lm at mcvoy.com  Thu Dec 24 04:06:02 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 23 Dec 2015 10:06:02 -0800
Subject: [TUHS] Does anybody recall how the TU10 bootstrap code actually
 operates?
In-Reply-To: <20151223180248.CB9C018C092@mercury.lcs.mit.edu>
References: <20151223180248.CB9C018C092@mercury.lcs.mit.edu>
Message-ID: <20151223180602.GB566@mcvoy.com>

On Wed, Dec 23, 2015 at 01:02:48PM -0500, Noel Chiappa wrote:
> Yes, yes, I know, the architecture is deader than a doornail for serious use,
> but I liken it to sailing vessels: nobody uses them for serious cargo haul any
> more, but they are still much beloved (and for good reasons, IMO).
> 
> The PDP-11 is an incredibly elegant architecture, perhaps the best ever (IMO),
> which remains one of the very best examples ever of how to get 30 pounds into
> the proverbial ten-pount sack - like early UNIX (more below).

Amen.


From cowan at mercury.ccil.org  Thu Dec 24 04:58:57 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Wed, 23 Dec 2015 13:58:57 -0500
Subject: [TUHS] etymology of cron
In-Reply-To: <20151223143802.4FD6018C096@mercury.lcs.mit.edu>
References: <20151223143802.4FD6018C096@mercury.lcs.mit.edu>
Message-ID: <20151223185857.GA21711@mercury.ccil.org>

Noel Chiappa scripsit:

> You're mistaking Wikipedia for an information source you can rely on. It's
> not. 

There are no such information sources.  People forget; researchers make
mistakes; mathematical proofs have bugs.  The only alternative to eventualism
is infallible dogmatism.

> Don't get me wrong, Wikipedia is quite useful as a place for an
> _introduction_ to any topic, but anyone who really wants to _reliably_ know
> anything about a topic needs to look at the references, not the articles.

But in the case to hand, it's precisely the references that are at fault.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
        "You need a change: try Canada"  "You need a change: try China"
                --fortune cookies opened by a couple that I know


From cowan at mercury.ccil.org  Thu Dec 24 05:04:29 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Wed, 23 Dec 2015 14:04:29 -0500
Subject: [TUHS] etymology of cron
In-Reply-To: <1450891193.26287.for-standards-violators@oclsc.org>
References: <1450891193.26287.for-standards-violators@oclsc.org>
Message-ID: <20151223190428.GB21711@mercury.ccil.org>

Norman Wilson scripsit:

> The trouble is not that it's a conference paper.  The trouble is
> that that the `authority' being cited is just a random assertion,
> not backed up.

Okay then.  There are fields in which conference papers have zero authority,
and those in which they have a great deal, that's all, so mentioning that
the source for the bad information was a conference paper was, as the
lawyers say, more prejudicial than probative.

> It's as if I mentioned your name in a paper about something else,
> remarked in passing and without any citation of my own that you have
> a wooden leg, and Wikipedia accepted that as proof of your prosthesis.

Got it.

> Norman Wilson
> Toronto ON
> (Four limbs and eight eyes, thank you very much)

Hexapodia is the key insight.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Income tax, if I may be pardoned for saying so, is a tax on income.
                --Lord Macnaghten (1901)


From szigiszabolcs at gmail.com  Thu Dec 24 05:41:22 2015
From: szigiszabolcs at gmail.com (SZIGETI Szabolcs)
Date: Wed, 23 Dec 2015 20:41:22 +0100
Subject: [TUHS] etymology of cron
In-Reply-To: <1450891193.26287.for-standards-violators@oclsc.org>
References: <1450891193.26287.for-standards-violators@oclsc.org>
Message-ID: <CAKt831GkBj5oyfx_eBt50bXydz=8et_7hXDzaZ3aKYRZp_dMRw@mail.gmail.com>

I think we need the obligatory xkcd reference here: https://xkcd.com/978/

Szabolcs

2015-12-23 18:19 GMT+01:00 Norman Wilson <norman at oclsc.org>:

>
> Have you actually looked up the cited reference?
>


> Norman Wilson
> Toronto ON
> (Four limbs and eight eyes, thank you very much)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151223/522d17f9/attachment.html>

From clemc at ccc.com  Thu Dec 24 06:29:55 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 23 Dec 2015 15:29:55 -0500
Subject: [TUHS] Does anybody recall how the TU10 bootstrap code actually
	operates?
In-Reply-To: <20151223180602.GB566@mcvoy.com>
References: <20151223180248.CB9C018C092@mercury.lcs.mit.edu>
 <20151223180602.GB566@mcvoy.com>
Message-ID: <CAC20D2Oc9Dgng8Si+_7ivjoAo2Snhw=6g5=Hn4FBYOeMEabZ+w@mail.gmail.com>

+1

On Wed, Dec 23, 2015 at 1:06 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Wed, Dec 23, 2015 at 01:02:48PM -0500, Noel Chiappa wrote:
> > Yes, yes, I know, the architecture is deader than a doornail for serious
> use,
> > but I liken it to sailing vessels: nobody uses them for serious cargo
> haul any
> > more, but they are still much beloved (and for good reasons, IMO).
> >
> > The PDP-11 is an incredibly elegant architecture, perhaps the best ever
> (IMO),
> > which remains one of the very best examples ever of how to get 30 pounds
> into
> > the proverbial ten-pount sack - like early UNIX (more below).
>
> Amen.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151223/92072906/attachment.html>

From grog at lemis.com  Thu Dec 24 09:49:39 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 24 Dec 2015 10:49:39 +1100
Subject: [TUHS] etymology of cron
In-Reply-To: <20151223160436.GB6677@mercury.ccil.org>
 <20151223133603.B1BFE440AE@lignose.oclsc.org>
Message-ID: <20151223234939.GL14449@eureka.lemis.com>

On Wednesday, 23 December 2015 at 11:04:36 -0500, John Cowan wrote:
> Norman Wilson scripsit:
>
>> But I'd be satisfied if we could somehow stamp out the use of spurious
>> references to support spurious claims.

It occurs to me that there's a difference between stamping out the use
and stamping out the reference.  True story (at some level of truth):

  In the late 18th century a member of a European exploratory mission
  in Australia sees a strange animal jumping around.  He turns to the
  aboriginal guard assigned to him and says "What's that animal?".
  Guard answers: "kangaroo" ("I don't understand what you're saying").

  I've always taken this one to be a joke, but the Oxford English
  Dictionary picks it up and says:

    The common assertion that it really means 'I don't understand'
    (the supposed reply of the local to his questioner) seems to be of
    recent origin and lacks confirmation. (See Morris Austral English
    s.v.)

  And maybe this is the correct way to handle those references.
  Mention them and observe that they lack any substantiation.

> I suppose you could get the original author(s) to print a retraction.

I've been trying to find Phil Diacono, of whom you wouldn't expect
many falso positives, but in fact there are two or three in Melbourne
alone, none of whom seem to be the right one.

In the meantime, help has come from an unlikely direction.  As far as
I can tell, it's nobody on this list, but there's no account behind
the commit, just the IP address 2601:647:4001:bc00:c48d:fc08:b94c:dec2

It refers to an article by Kah Seng Tay at
https://www.quora.com/What-is-the-etymology-of-cron , which appears
undated (date "Wed"), but which goes into more detail and includes a
copy of a message from Brian with essentially the same content as the
one he sent to Doug.  I've updated the page to note lack of
substatiation in the alternative references.

We're not done yet.  Tedickey has once again tagged the entry with
WP:RS.  So a published document would still be a good idea.

wkt: is it time for an informal "Proceedings of TUHS"?

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151224/db6b908d/attachment.sig>

From clemc at ccc.com  Fri Dec 25 01:01:25 2015
From: clemc at ccc.com (Clem Cole)
Date: Thu, 24 Dec 2015 10:01:25 -0500
Subject: [TUHS] etymology of cron
In-Reply-To: <CAC20D2N=06vZ0+Q3-VP224Le-Fpj1KNB7=k3hv6p1sNU5bFOcA@mail.gmail.com>
References: <20151223133603.B1BFE440AE@lignose.oclsc.org>
 <CAC20D2N=06vZ0+Q3-VP224Le-Fpj1KNB7=k3hv6p1sNU5bFOcA@mail.gmail.com>
Message-ID: <CAC20D2PFt5+fs3ULTEdnUfDHPkfUirYEPDZumdzYG5BP6fM2Ow@mail.gmail.com>

It seem to me to be sad statement that it takes this kind of work to get
the truth out, but it looks like my informal role as "Emeritus President"
of USENIX may pay a small dividend.

Rik Farrow, the current USENIX Board and I had a round of email yesterday.
It turns out a number of members of the USENIX Board have also has similar
or in one case worse experiences, with the Wikipedia folks -- so folks were
more than happy to see if they can help make it right.

Rik in his role as the editor of ;login is going to try work with Doug and
to get something "published" into the next edition which should satisfy the
Wikipedia folks.   There is a minor issue is that Rik is technically past
the deadline but due to the holiday, there are a few days of grace that the
workers putting the issue together have said they will thankfully try to
handle.

So maybe we can have get this fixed shortly.

Clem

On Wed, Dec 23, 2015 at 8:53 AM, Clem Cole <clemc at ccc.com> wrote:

>
> On Wed, Dec 23, 2015 at 8:36 AM, Norman Wilson <norman at oclsc.org> wrote:
>
>> I'd like to see a published, citable reference for the
>> true origin of `cron'.  Even better, better published
>> material for a lot of the charming minutiae of the early
>> days of UNIX.  (Anyone feel up to interviewing Doug and
>> Ken and Brian and whoever else is left, and writing it up
>> for publication in ;login:?)
>>
>
> ​I just sent Rik a note and asked him to make it so.
>
> Clem​
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151224/c6be4e28/attachment.html>

From cowan at mercury.ccil.org  Fri Dec 25 01:17:53 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Thu, 24 Dec 2015 10:17:53 -0500
Subject: [TUHS] etymology of cron
In-Reply-To: <CAC20D2PFt5+fs3ULTEdnUfDHPkfUirYEPDZumdzYG5BP6fM2Ow@mail.gmail.com>
References: <20151223133603.B1BFE440AE@lignose.oclsc.org>
 <CAC20D2N=06vZ0+Q3-VP224Le-Fpj1KNB7=k3hv6p1sNU5bFOcA@mail.gmail.com>
 <CAC20D2PFt5+fs3ULTEdnUfDHPkfUirYEPDZumdzYG5BP6fM2Ow@mail.gmail.com>
Message-ID: <20151224151753.GA11034@mercury.ccil.org>

Clem Cole scripsit:

> Rik in his role as the editor of ;login is going to try work with Doug and
> to get something "published" into the next edition which should satisfy the
> Wikipedia folks.   There is a minor issue is that Rik is technically past
> the deadline but due to the holiday, there are a few days of grace that the
> workers putting the issue together have said they will thankfully try to
> handle.
> 
> So maybe we can have get this fixed shortly.

I don't think so.  Is ;login: a peer-reviewed journal?  It doesn't look
like it to me.  Still, the current state says:

    The origin of the name cron is from the Greek word for
    time, χρόνος (chronos), according to its author Ken
    Thompson[2][better source needed]. Others have suggested that the
    name comes from the Greek God Chronos[3] or that it is an acronym
    for "Command Run On Notice"[4] or "Commands Run Over Night",[5]
    but the references lack substantiation.

Even if someone is still grumbling on the talk page, that doesn't
substantially misrepresent anything that I can see.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
        Is it not written, "That which is written, is written"?


From ron at ronnatalie.com  Fri Dec 25 08:33:26 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Thu, 24 Dec 2015 17:33:26 -0500
Subject: [TUHS] Does anybody recall how the TU10 bootstrap code actually
	operates?
In-Reply-To: <20151223065957.5ED5718C095@mercury.lcs.mit.edu>
References: <20151223065957.5ED5718C095@mercury.lcs.mit.edu>
Message-ID: <F72C7A01-F1FC-4BE5-B0E2-FF84149DF099@ronnatalie.com>

Noel is correct.   The code sticks a number that’s big enough in the byte record count register and then does a  command which is
800 bpi 9 track READ and GO.   The code makes use of the fact that after a bus reset the memory address register is zero.

As long as you stick a number in the BRC that is bigger than the the record size on the tape (and not bigger than the available memory on your system),
it will work.

777 is indeed BR .

It loads the first (assuming the tape is rewound) record into memory at location zero.
You then start the processor at zero to load that bootstrap program which does the rest of the magic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151224/33147fcd/attachment.bin>

From grog at lemis.com  Fri Dec 25 09:05:06 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Fri, 25 Dec 2015 10:05:06 +1100
Subject: [TUHS] etymology of cron
In-Reply-To: <20151224151753.GA11034@mercury.ccil.org>
References: <20151223133603.B1BFE440AE@lignose.oclsc.org>
 <CAC20D2N=06vZ0+Q3-VP224Le-Fpj1KNB7=k3hv6p1sNU5bFOcA@mail.gmail.com>
 <CAC20D2PFt5+fs3ULTEdnUfDHPkfUirYEPDZumdzYG5BP6fM2Ow@mail.gmail.com>
 <20151224151753.GA11034@mercury.ccil.org>
Message-ID: <20151224230506.GM14449@eureka.lemis.com>

On Thursday, 24 December 2015 at 10:17:53 -0500, John Cowan wrote:
> Clem Cole scripsit:
>
>> Rik in his role as the editor of ;login is going to try work with Doug and
>> to get something "published" into the next edition which should satisfy the
>> Wikipedia folks.   There is a minor issue is that Rik is technically past
>> the deadline but due to the holiday, there are a few days of grace that the
>> workers putting the issue together have said they will thankfully try to
>> handle.
>>
>> So maybe we can have get this fixed shortly.
>
> I don't think so.  Is ;login: a peer-reviewed journal?  It doesn't
> look like it to me.

One of the original references was from the proceedings of an AUUG
conference.  From personal experience I can confirm that the level of
review for the conferences fell far short of what USENIX did.

> Still, the current state says:
>
>     The origin of the name cron is from the Greek word for
>     time, ???????????? (chronos), according to its author Ken
>     Thompson[2][better source needed]. Others have suggested that the
>     name comes from the Greek God Chronos[3] or that it is an acronym
>     for "Command Run On Notice"[4] or "Commands Run Over Night",[5]
>     but the references lack substantiation.
>
> Even if someone is still grumbling on the talk page, that doesn't
> substantially misrepresent anything that I can see.

Yes, that last sentence was my update.  As I mentioned in an earlier
message, I think that it's appropriate that it should stay, if only to
stop people making the claim again in a more forceful manner.

But it would be nice to be able to remove the [better source needed].
It seems that there's only one person objecting to the changes.  I've
asked him on the talk page what he really wants.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151225/3eaf095c/attachment.sig>

From scj at yaccman.com  Fri Dec 25 10:52:33 2015
From: scj at yaccman.com (scj at yaccman.com)
Date: Thu, 24 Dec 2015 16:52:33 -0800
Subject: [TUHS] etymology of cron
In-Reply-To: <20151224230506.GM14449@eureka.lemis.com>
References: <20151223133603.B1BFE440AE@lignose.oclsc.org>
 <CAC20D2N=06vZ0+Q3-VP224Le-Fpj1KNB7=k3hv6p1sNU5bFOcA@mail.gmail.com>
 <CAC20D2PFt5+fs3ULTEdnUfDHPkfUirYEPDZumdzYG5BP6fM2Ow@mail.gmail.com>
 <20151224151753.GA11034@mercury.ccil.org>
 <20151224230506.GM14449@eureka.lemis.com>
Message-ID: <563cf28905c1795afe24eb45fc0cfe49.squirrel@webmail.yaccman.com>

This has been a somewhat bizarre and troubling thread, all in all.

Would anybody want to discuss the origin of 'ls'?   Or 'at'?

Steve

PS: (that was NOT a serious suggestion!)



> On Thursday, 24 December 2015 at 10:17:53 -0500, John Cowan wrote:
>> Clem Cole scripsit:
>>
>>> Rik in his role as the editor of ;login is going to try work with Doug
>>> and
>>> to get something "published" into the next edition which should satisfy
>>> the
>>> Wikipedia folks.   There is a minor issue is that Rik is technically
>>> past
>>> the deadline but due to the holiday, there are a few days of grace that
>>> the
>>> workers putting the issue together have said they will thankfully try
>>> to
>>> handle.
>>>
>>> So maybe we can have get this fixed shortly.
>>
>> I don't think so.  Is ;login: a peer-reviewed journal?  It doesn't
>> look like it to me.
>
> One of the original references was from the proceedings of an AUUG
> conference.  From personal experience I can confirm that the level of
> review for the conferences fell far short of what USENIX did.
>
>> Still, the current state says:
>>
>>     The origin of the name cron is from the Greek word for
>>     time, ???????????? (chronos), according to its author Ken
>>     Thompson[2][better source needed]. Others have suggested that the
>>     name comes from the Greek God Chronos[3] or that it is an acronym
>>     for "Command Run On Notice"[4] or "Commands Run Over Night",[5]
>>     but the references lack substantiation.
>>
>> Even if someone is still grumbling on the talk page, that doesn't
>> substantially misrepresent anything that I can see.
>
> Yes, that last sentence was my update.  As I mentioned in an earlier
> message, I think that it's appropriate that it should stay, if only to
> stop people making the claim again in a more forceful manner.
>
> But it would be nice to be able to remove the [better source needed].
> It seems that there's only one person objecting to the changes.  I've
> asked him on the talk page what he really wants.
>
> Greg
> --
> Sent from my desktop computer.
> Finger grog at FreeBSD.org for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft MUA reports
> problems, please read http://tinyurl.com/broken-mua
>




From lm at mcvoy.com  Fri Dec 25 11:05:48 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 24 Dec 2015 17:05:48 -0800
Subject: [TUHS] etymology of cron
In-Reply-To: <563cf28905c1795afe24eb45fc0cfe49.squirrel@webmail.yaccman.com>
References: <20151223133603.B1BFE440AE@lignose.oclsc.org>
 <CAC20D2N=06vZ0+Q3-VP224Le-Fpj1KNB7=k3hv6p1sNU5bFOcA@mail.gmail.com>
 <CAC20D2PFt5+fs3ULTEdnUfDHPkfUirYEPDZumdzYG5BP6fM2Ow@mail.gmail.com>
 <20151224151753.GA11034@mercury.ccil.org>
 <20151224230506.GM14449@eureka.lemis.com>
 <563cf28905c1795afe24eb45fc0cfe49.squirrel@webmail.yaccman.com>
Message-ID: <20151225010548.GE28750@mcvoy.com>

What's troubling is wikipedia, I didn't realize they were that much of a pain.

On Thu, Dec 24, 2015 at 04:52:33PM -0800, scj at yaccman.com wrote:
> This has been a somewhat bizarre and troubling thread, all in all.
> 
> Would anybody want to discuss the origin of 'ls'?   Or 'at'?
> 
> Steve
> 
> PS: (that was NOT a serious suggestion!)
> 
> 
> 
> > On Thursday, 24 December 2015 at 10:17:53 -0500, John Cowan wrote:
> >> Clem Cole scripsit:
> >>
> >>> Rik in his role as the editor of ;login is going to try work with Doug
> >>> and
> >>> to get something "published" into the next edition which should satisfy
> >>> the
> >>> Wikipedia folks.   There is a minor issue is that Rik is technically
> >>> past
> >>> the deadline but due to the holiday, there are a few days of grace that
> >>> the
> >>> workers putting the issue together have said they will thankfully try
> >>> to
> >>> handle.
> >>>
> >>> So maybe we can have get this fixed shortly.
> >>
> >> I don't think so.  Is ;login: a peer-reviewed journal?  It doesn't
> >> look like it to me.
> >
> > One of the original references was from the proceedings of an AUUG
> > conference.  From personal experience I can confirm that the level of
> > review for the conferences fell far short of what USENIX did.
> >
> >> Still, the current state says:
> >>
> >>     The origin of the name cron is from the Greek word for
> >>     time, ???????????? (chronos), according to its author Ken
> >>     Thompson[2][better source needed]. Others have suggested that the
> >>     name comes from the Greek God Chronos[3] or that it is an acronym
> >>     for "Command Run On Notice"[4] or "Commands Run Over Night",[5]
> >>     but the references lack substantiation.
> >>
> >> Even if someone is still grumbling on the talk page, that doesn't
> >> substantially misrepresent anything that I can see.
> >
> > Yes, that last sentence was my update.  As I mentioned in an earlier
> > message, I think that it's appropriate that it should stay, if only to
> > stop people making the claim again in a more forceful manner.
> >
> > But it would be nice to be able to remove the [better source needed].
> > It seems that there's only one person objecting to the changes.  I've
> > asked him on the talk page what he really wants.
> >
> > Greg
> > --
> > Sent from my desktop computer.
> > Finger grog at FreeBSD.org for PGP public key.
> > See complete headers for address and phone numbers.
> > This message is digitally signed.  If your Microsoft MUA reports
> > problems, please read http://tinyurl.com/broken-mua
> >
> 

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From grog at lemis.com  Fri Dec 25 12:07:57 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Fri, 25 Dec 2015 13:07:57 +1100
Subject: [TUHS] etymology of cron
In-Reply-To: <20151225010548.GE28750@mcvoy.com>
References: <20151223133603.B1BFE440AE@lignose.oclsc.org>
 <CAC20D2N=06vZ0+Q3-VP224Le-Fpj1KNB7=k3hv6p1sNU5bFOcA@mail.gmail.com>
 <CAC20D2PFt5+fs3ULTEdnUfDHPkfUirYEPDZumdzYG5BP6fM2Ow@mail.gmail.com>
 <20151224151753.GA11034@mercury.ccil.org>
 <20151224230506.GM14449@eureka.lemis.com>
 <563cf28905c1795afe24eb45fc0cfe49.squirrel@webmail.yaccman.com>
 <20151225010548.GE28750@mcvoy.com>
Message-ID: <20151225020757.GN14449@eureka.lemis.com>

[sequence recovered]

On Thursday, 24 December 2015 at 17:05:48 -0800, Larry McVoy wrote:
> On Thu, Dec 24, 2015 at 04:52:33PM -0800, scj at yaccman.com wrote:
>> This has been a somewhat bizarre and troubling thread, all in all.
>>
>> Would anybody want to discuss the origin of 'ls'?   Or 'at'?
>
> What's troubling is wikipedia, I didn't realize they were that much
> of a pain.

Normally they aren't.  I think it's this one editor.  On trawling
through the pages, there's this policy:
https://en.wikipedia.org/wiki/Wikipedia:Ignore_all_rules
That seems to apply here.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151225/2d97aade/attachment.sig>

From dave at horsfall.org  Fri Dec 25 12:28:55 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 25 Dec 2015 13:28:55 +1100 (EST)
Subject: [TUHS] etymology of cron
In-Reply-To: <20151225020757.GN14449@eureka.lemis.com>
References: <20151223133603.B1BFE440AE@lignose.oclsc.org>
 <CAC20D2N=06vZ0+Q3-VP224Le-Fpj1KNB7=k3hv6p1sNU5bFOcA@mail.gmail.com>
 <CAC20D2PFt5+fs3ULTEdnUfDHPkfUirYEPDZumdzYG5BP6fM2Ow@mail.gmail.com>
 <20151224151753.GA11034@mercury.ccil.org>
 <20151224230506.GM14449@eureka.lemis.com>
 <563cf28905c1795afe24eb45fc0cfe49.squirrel@webmail.yaccman.com>
 <20151225010548.GE28750@mcvoy.com> <20151225020757.GN14449@eureka.lemis.com>
Message-ID: <alpine.BSF.2.11.1512251326270.27165@aneurin.horsfall.org>

On Fri, 25 Dec 2015, Greg 'groggy' Lehey wrote:

> > What's troubling is wikipedia, I didn't realize they were that much of 
> > a pain.
> 
> Normally they aren't.  I think it's this one editor.  On trawling
> through the pages, there's this policy:
> https://en.wikipedia.org/wiki/Wikipedia:Ignore_all_rules
> That seems to apply here.

Suddenly, much is explained...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From scj at yaccman.com  Fri Dec 25 04:09:33 2015
From: scj at yaccman.com (scj at yaccman.com)
Date: Thu, 24 Dec 2015 10:09:33 -0800
Subject: [TUHS] =?utf-8?q?=28no_subject=29?=
Message-ID: <025d5034cf67e9406a3f0c41912a5015.squirrel@webmail.yaccman.com>

Actually, I could easily see Usenix doing this kind of thing on a regular
basis.  Add my vote as another ex president...



From scj at yaccman.com  Fri Dec 25 04:09:33 2015
From: scj at yaccman.com (scj at yaccman.com)
Date: Thu, 24 Dec 2015 10:09:33 -0800
Subject: [TUHS] =?utf-8?q?=28no_subject=29?=
Message-ID: <ddb9ed1bc67a3b1d105fe0560f32a2dd.squirrel@webmail.yaccman.com>

Actually, I could easily see Usenix doing this kind of thing on a regular
basis.  Add my vote as another ex president...



From rochkind at basepath.com  Sat Dec 26 02:21:55 2015
From: rochkind at basepath.com (Marc Rochkind)
Date: Fri, 25 Dec 2015 09:21:55 -0700
Subject: [TUHS] etymology of cron
In-Reply-To: <563cf28905c1795afe24eb45fc0cfe49.squirrel@webmail.yaccman.com>
References: <20151223133603.B1BFE440AE@lignose.oclsc.org>
 <CAC20D2N=06vZ0+Q3-VP224Le-Fpj1KNB7=k3hv6p1sNU5bFOcA@mail.gmail.com>
 <CAC20D2PFt5+fs3ULTEdnUfDHPkfUirYEPDZumdzYG5BP6fM2Ow@mail.gmail.com>
 <20151224151753.GA11034@mercury.ccil.org>
 <20151224230506.GM14449@eureka.lemis.com>
 <563cf28905c1795afe24eb45fc0cfe49.squirrel@webmail.yaccman.com>
Message-ID: <CAOkr1zWwRJMps=o+ZiZEXOBHXe8pOWKjXYU5RMnotANKftTe3A@mail.gmail.com>

Got into this thread very late.

Some of the posts seem to assume that Wikipedia has some sort editing
oversight. I think of it as a collection of people. Somebody said that a
better source was needed, but that's just his or her opinion. It doesn't
mean that Wikipedia as an organization has rejected or dismissed the text
in question.

Anyway, I edited the article to reflect what I always knew and what
apparently Ken has actually confirmed. The acronym is ridiculous. One might
as well say that "cat" stands for "communicate as text" or that "ls" stands
for "label status". ;-)

Someone may back out my change, true, but then I can just put it in again.
I've been involved in these back-and-forths before, and in the past they
usually settled down after a while.

We'll see what happens.

--Marc

On Thu, Dec 24, 2015 at 5:52 PM, <scj at yaccman.com> wrote:

> This has been a somewhat bizarre and troubling thread, all in all.
>
> Would anybody want to discuss the origin of 'ls'?   Or 'at'?
>
> Steve
>
> PS: (that was NOT a serious suggestion!)
>
>
>
> > On Thursday, 24 December 2015 at 10:17:53 -0500, John Cowan wrote:
> >> Clem Cole scripsit:
> >>
> >>> Rik in his role as the editor of ;login is going to try work with Doug
> >>> and
> >>> to get something "published" into the next edition which should satisfy
> >>> the
> >>> Wikipedia folks.   There is a minor issue is that Rik is technically
> >>> past
> >>> the deadline but due to the holiday, there are a few days of grace that
> >>> the
> >>> workers putting the issue together have said they will thankfully try
> >>> to
> >>> handle.
> >>>
> >>> So maybe we can have get this fixed shortly.
> >>
> >> I don't think so.  Is ;login: a peer-reviewed journal?  It doesn't
> >> look like it to me.
> >
> > One of the original references was from the proceedings of an AUUG
> > conference.  From personal experience I can confirm that the level of
> > review for the conferences fell far short of what USENIX did.
> >
> >> Still, the current state says:
> >>
> >>     The origin of the name cron is from the Greek word for
> >>     time, ???????????? (chronos), according to its author Ken
> >>     Thompson[2][better source needed]. Others have suggested that the
> >>     name comes from the Greek God Chronos[3] or that it is an acronym
> >>     for "Command Run On Notice"[4] or "Commands Run Over Night",[5]
> >>     but the references lack substantiation.
> >>
> >> Even if someone is still grumbling on the talk page, that doesn't
> >> substantially misrepresent anything that I can see.
> >
> > Yes, that last sentence was my update.  As I mentioned in an earlier
> > message, I think that it's appropriate that it should stay, if only to
> > stop people making the claim again in a more forceful manner.
> >
> > But it would be nice to be able to remove the [better source needed].
> > It seems that there's only one person objecting to the changes.  I've
> > asked him on the talk page what he really wants.
> >
> > Greg
> > --
> > Sent from my desktop computer.
> > Finger grog at FreeBSD.org for PGP public key.
> > See complete headers for address and phone numbers.
> > This message is digitally signed.  If your Microsoft MUA reports
> > problems, please read http://tinyurl.com/broken-mua
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151225/83f67f82/attachment.html>

From david at kdbarto.org  Sat Dec 26 04:41:54 2015
From: david at kdbarto.org (David)
Date: Fri, 25 Dec 2015 10:41:54 -0800
Subject: [TUHS] etymology of cron
In-Reply-To: <mailman.1.1451005554.3365.tuhs@minnie.tuhs.org>
References: <mailman.1.1451005554.3365.tuhs@minnie.tuhs.org>
Message-ID: <D2360769-F089-4AA9-8826-617ACE550FBC@kdbarto.org>

It has been updated again:

 The origin of the name cron is from the Greek word for time, χρόνος (chronos).[2][3] (Ken Thompson, author of cron, has confirmed this in a private communication with Brian Kernighan.)

So it would appear that if enough people bang on enough keyboards on the Wikipedia site, things can change.

	David



From rochkind at basepath.com  Sat Dec 26 06:46:17 2015
From: rochkind at basepath.com (Marc Rochkind)
Date: Fri, 25 Dec 2015 13:46:17 -0700
Subject: [TUHS] etymology of cron
In-Reply-To: <D2360769-F089-4AA9-8826-617ACE550FBC@kdbarto.org>
References: <mailman.1.1451005554.3365.tuhs@minnie.tuhs.org>
 <D2360769-F089-4AA9-8826-617ACE550FBC@kdbarto.org>
Message-ID: <CAOkr1zX_WhZiLdQaKcn0SGyZdBrR5k7aX1mWsG3MdTgvw8Qndw@mail.gmail.com>

that 2nd ref is mine, too.

marc

On Friday, December 25, 2015, David <david at kdbarto.org> wrote:

> It has been updated again:
>
>  The origin of the name cron is from the Greek word for time, χρόνος
> (chronos).[2][3] (Ken Thompson, author of cron, has confirmed this in a
> private communication with Brian Kernighan.)
>
> So it would appear that if enough people bang on enough keyboards on the
> Wikipedia site, things can change.
>
>         David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151225/c1637431/attachment.html>

From grog at lemis.com  Sat Dec 26 08:22:34 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sat, 26 Dec 2015 09:22:34 +1100
Subject: [TUHS] etymology of cron
In-Reply-To: <D2360769-F089-4AA9-8826-617ACE550FBC@kdbarto.org>
References: <mailman.1.1451005554.3365.tuhs@minnie.tuhs.org>
 <D2360769-F089-4AA9-8826-617ACE550FBC@kdbarto.org>
Message-ID: <20151225222234.GP14449@eureka.lemis.com>

On Friday, 25 December 2015 at 10:41:54 -0800, David wrote:
> It has been updated again:
>
>  The origin of the name cron is from the Greek word for time,
> ???????????? (chronos).[2][3] (Ken Thompson, author of cron, has
> confirmed this in a private communication with Brian Kernighan.)

Yes, but you've removed the reference to the incorrect expansions.  As
I noted at some length earlier in this thread, that's not appropriate.
It ignores the fact that people have made these claims, it removes the
comment that they're unsubstantiated, and it prepares the field for
somebody else to make the claim again, with possibly even more bizarre
expmanations.  I won't back it out yet, because I can see further
changes coming from other directions.  Once again this Tedickey
character has been very active.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151226/727ed644/attachment.sig>

From wkt at tuhs.org  Sat Dec 26 09:29:58 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 26 Dec 2015 09:29:58 +1000
Subject: [TUHS] Mirror of Mike Mahoney's oral history of Unix
Message-ID: <20151225232958.GA1535@minnie.tuhs.org>

All, Doug McIlroy sent me an e-mail about the late Mike Mahoney's project
to create an oral history of Unix. His documents are at
http://www.princeton.edu/~hos/Mahoney/unixhistory

I've taken the liberty to mirror them into the Unix Archive and they are
now also at http://minnie.tuhs.org/Archive/Documentation/OralHistory/

Cheers, Warren


From wkt at tuhs.org  Sat Dec 26 11:02:53 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 26 Dec 2015 11:02:53 +1000
Subject: [TUHS] Etymology of shell
Message-ID: <0E1925B8-CF22-4A75-AE7D-039E78BB081B@tuhs.org>

So what is the etymology of "shell", then? I see that Multics has a shell. Was the CTSS user interface also called a shell?

Cheers, Warren
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151226/76c871bd/attachment.html>

From wkt at tuhs.org  Sat Dec 26 11:09:00 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 26 Dec 2015 11:09:00 +1000
Subject: [TUHS] Etymology of "shell"?
Message-ID: <20151226010900.GA8191@minnie.tuhs.org>

So what is the etymology of the word "shell"? I see that Multics has a shell.
What the user interface in CTSS also called a shell?

Cheers, Warren


From grog at lemis.com  Sat Dec 26 11:50:29 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sat, 26 Dec 2015 12:50:29 +1100
Subject: [TUHS] Etymology of "shell"?
In-Reply-To: <20151226010900.GA8191@minnie.tuhs.org>
References: <20151226010900.GA8191@minnie.tuhs.org>
Message-ID: <20151226015029.GQ14449@eureka.lemis.com>

On Saturday, 26 December 2015 at 11:09:00 +1000, Warren Toomey wrote:
> So what is the etymology of the word "shell"? I see that Multics has a shell.
> What the user interface in CTSS also called a shell?

As so frequently, the Oxford English Dictionary has surprisingly good
coverage.  This is a draft addition after 33 other main meaning
groups:

   b. In some operating systems (originally Multics and Unix): a
      program that translates commands keyed by the user into commands
      that the operating system can act on, thereby providing a
      high-level interface with the user. Also (more fully shell
      window): a window in which such commands can be invoked.

  1974 Communications Assoc. Computing Machinery 17 371/1 For most
       users, communication with unix is carried on with the aid of a
       program called the Shell. The Shell is a command line
       interpreter.

That's the earliest dated reference, but the mention of Multics
matches what you said.

I've also taken a look through the sources of CTSS, and the only
mention of SHELL there was as a local variable of a function that
might be called FLSRTN (not sure I'm reading the aseembler output
correctly).  That suggests that the name wasn't used for the command
interpreter.  In the file com2 (which is a listing) I see things like:

1       .MAIN - MAIN CONTROL FOR COMMAND ABBREVIATION AND CHAINING PROG.         05/12/69 1512.1 PAGE 3
                           READ AND ASSEMBLE COMMAND LINE FROM CLS OR INPUT BUFFER.

That sounds like it could be the command interpreter, but there's no
documentation, and it's easy to misinterpret these things.

I've sent mail to Tom Van Vleck, who will be able to shed more light
on this.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151226/c48204d2/attachment.sig>

From cowan at mercury.ccil.org  Sat Dec 26 12:44:08 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Fri, 25 Dec 2015 21:44:08 -0500
Subject: [TUHS] Etymology of shell
In-Reply-To: <0E1925B8-CF22-4A75-AE7D-039E78BB081B@tuhs.org>
References: <0E1925B8-CF22-4A75-AE7D-039E78BB081B@tuhs.org>
Message-ID: <20151226024408.GD10352@mercury.ccil.org>

Warren Toomey scripsit:

> So what is the etymology of "shell", then? I see that Multics has a
> shell. Was the CTSS user interface also called a shell?

I can't speak to CTSS, but my understanding is that the Multics shell was
a shell in the same sense as an expert-system shell: that is, a fixed
piece of code into which other code was loaded in order to customize
it to do something.  Rather than starting another process, the Multics
shell mapped the executable program the user requested into its own
space, as is done with shared libraries today, and then jumped into it.
The equivalent of exit() simply jumped back to the shell code.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
The present impossibility of giving a scientific explanation is no proof
that there is no scientific explanation. The unexplained is not to be
identified with the unexplainable, and the strange and extraordinary
nature of a fact is not a justification for attributing it to powers
above nature.  --The Catholic Encyclopedia, s.v. "telepathy" (1913)


From jnc at mercury.lcs.mit.edu  Sat Dec 26 12:50:58 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 25 Dec 2015 21:50:58 -0500 (EST)
Subject: [TUHS] Etymology of shell
Message-ID: <20151226025058.EF9F018C095@mercury.lcs.mit.edu>

    > From: John Cowan

    > Rather than starting another process, the Multics shell mapped the
    > executable program the user requested into its own space .. then jumped
    > into it. The equivalent of exit() simply jumped back to the shell code.

This is from memory, so apply the proverbial grain, but ISTR that the
original concept for the Multics shell was just like that for Unix - i.e.
each command would be a separte child process. This was given up when Multics
processes turned out to be so computationally expensive, and they went to
commands being subroutines that were dynamically linked in (very easy with
Multics, where dynamic linking was a fundamental system capability) and
called from the shell.

	Noel


From doug at cs.dartmouth.edu  Sat Dec 26 14:49:04 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 25 Dec 2015 23:49:04 -0500
Subject: [TUHS] =?utf-8?q?=28no_subject=29?=
Message-ID: <201512260449.tBQ4n4xx093734@tahoe.cs.Dartmouth.EDU>



From doug at cs.dartmouth.edu  Sat Dec 26 14:51:25 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 25 Dec 2015 23:51:25 -0500
Subject: [TUHS] =?utf-8?q?=28no_subject=29?=
Message-ID: <201512260451.tBQ4pPRH093745@tahoe.cs.Dartmouth.EDU>



From wkt at tuhs.org  Sun Dec 27 00:09:03 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 27 Dec 2015 00:09:03 +1000
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <20151128232413.GA24191@www.oztivo.net>
References: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>
 <20151128232413.GA24191@www.oztivo.net>
Message-ID: <20151226140903.GA19847@minnie.tuhs.org>

On Sun, Nov 29, 2015 at 10:24:13AM +1100, Warren Toomey wrote:
> > Among the papers of the late Bob Morris I have found a
> > Unix manual that I don't remember at all--a draft by
> > Dennis Ritchie, in the style of (but not designated as)
> > a technical report with numbered sections and subsections.
> 
> Doug has kindly made available a scan of this document.

I've just spent the evening OCR'ing it with tesseract and then hand cleaning
the output. A plain text (no formatting) version is now at:

http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/UnixEditionZero.txt

Doug, page A7 is missing. Could you e-mail in a scan of that page?

I am still amazed at how eloquent and succinct Dennis was at writing.
This document is an amazing introduction to the ideas and features of
Unix. It's a pity they didn't take this to SOSP in 1971!

Cheers, Warren


From will.senn at gmail.com  Sun Dec 27 04:34:15 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 26 Dec 2015 12:34:15 -0600
Subject: [TUHS] v6 RK05 bootloader question
Message-ID: <567EDDA7.1000104@gmail.com>

All,

I'm trying to understand the RK bootloader code that is found in 
"Setting up Unix - Sixth Edition". My question is related to RKBA, RK's 
bus address buffer. Is the bus address the same as memory address? If 
so, the code makes sense, if not, I appreciate y'alls help.

Here's what I have so far:

RK05

01 012700       MOV 177414,R0  ; Move RKDB into R0
02 177414                      ; RKDB Address
03 005040       CLR -(R0)      ; Decrement R0 and clear the contents of RKDA
04 005040       CLR -(R0)      ; Decrement R0 and clear the contents of RKBA
05 010040       MOV R0,-(R0)   ; Move the contents of R0(RKBA) into 
decremented R0(RKWC)
06 012740       MOV 5,-(R0)    ; Decrement R0 and move 5 into RKCS
07 000005                      ; Read and go
08 105710 WAIT: TSTB (R0)      ; Test the lower byte of RKCS
09 002376       BGE WAIT       ; When bit 7 becomes 1, the read is done
10 005007       CLR PC         ; Set PC 000000, the start of the bytes read

RKDB - RK data buffer register
This register is a general data register and it only used by the code 
above to initialize R0 so that subsequent RK addresses can be found by 
simply decrementing R0.

RKDA - RK disk address register
This register determines the starting disk address of the read operation 
and is cleared by the code.

RKBA - RK current bus address register
This register contains the bus address to or from which data will be 
transferred. Is this the same as memory address?

RKWC - RK word count register
Two's complement of the number of words to be transferred.

RKCS - RK control status register
This is the register that controls the device and provides the device 
status to the program

Lines 1-2
The execution of the boot loader code moves the address of RKDB into R0 
to initialize the register so that it can be used to obtain the other RK 
buffer addresses as they are needed.

Line 3
The RKDA buffer is cleared, setting the disk address to 0.

Line 4
The RKBA buffer is cleared, setting the bus address to 0.

Line 5
The value in R0 is transferred into the RKWC buffer. RKBA or 177410, the 
value in R0, is a convenient number to use for the read operation 
because it is big enough to cause the program to read in a block of 
data. The number is in two's complement and represents -370. This tells 
the disk controller that 370 words (540 bytes) will be transferred.

Lines 6-7
The value 5 is placed into RKCS, this value represents a read operation 
and go.

Lines 8-9
The lower byte of RKCS is tested and when it is greater than or equal to 
zero (not negative), it loops, waiting until the value is negative, that 
is until bit 7 becomes 1, which indicates Control Ready (RDY) and done.

Line 10
  PC is set to 00000 and execution of the bytes read from the disk 
begins at location 00000.




From ron at ronnatalie.com  Sun Dec 27 05:15:01 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sat, 26 Dec 2015 14:15:01 -0500
Subject: [TUHS] v6 RK05 bootloader question
In-Reply-To: <567EDDA7.1000104@gmail.com>
References: <567EDDA7.1000104@gmail.com>
Message-ID: <259CE72F-72FA-4A57-B950-16205251810A@ronnatalie.com>

Yeah, some of the code is a bit non-obvious because the author of this snippet was trying to get the minimum number of instructions that
have to be keyed in with the front panel switches to make things go.

Yep, as far as the UNIBUS is concerned the bus addresses could be memory or control registers for some peripheral.

Your analysis is correct.  Note this one jumps to zero when ready as opposed to the tape boot you posted before which just loops forever
expecting you to notice the tape has finished moving and wants you to load 0 and start.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151226/1a1cb534/attachment.bin>

From ron at ronnatalie.com  Sun Dec 27 05:26:50 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sat, 26 Dec 2015 14:26:50 -0500
Subject: [TUHS] v6 RK05 bootloader question
In-Reply-To: <567EDDA7.1000104@gmail.com>
References: <567EDDA7.1000104@gmail.com>
Message-ID: <6820785F-DF76-4989-80BA-9F6006D6CD66@ronnatalie.com>

Note that all this “boot loading” stuff was only necessary if you didn’t already have a boot rom board (the common one for the early PDPs had a bunch of diodes you clipped).   Ours was set to boot RK Drive 0 so even after we got a larger drive (80MB seemed like an infinite amount of storage after dealing with 2.4M) we left a disk with the bootstrap in RK0.

I can’t remember the boot address on that machine, but the boot for the 11/70 I used for years at BRL is still ingrained in my memory:  7765000 (while it isn’t exactly right, I used the Glenn Miller PENNSYLVANIA-6-5000 as a memory aid).   Long after we gave up using PDP-11’s for UNIX machines, I recycled them all into internet routers using my own (“Little Operating System” LOS).   We had started with Noel’s MIT gateway but he was exiled at the time to the Bahamas or something and we decided it was easier starting over with the magnitude of changes we needed to make.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151226/1576e5ae/attachment.bin>

From will.senn at gmail.com  Sun Dec 27 06:34:50 2015
From: will.senn at gmail.com (Will Senn)
Date: Sat, 26 Dec 2015 14:34:50 -0600
Subject: [TUHS] v6 RK05 bootloader question
In-Reply-To: <6820785F-DF76-4989-80BA-9F6006D6CD66@ronnatalie.com>
References: <567EDDA7.1000104@gmail.com>
 <6820785F-DF76-4989-80BA-9F6006D6CD66@ronnatalie.com>
Message-ID: <567EF9EA.1090806@gmail.com>



On 12/26/15 1:26 PM, Ronald Natalie wrote:
> Note that all this “boot loading” stuff was only necessary if you didn’t already have a boot rom board (the common one for the early PDPs had a bunch of diodes you clipped).   Ours was set to boot RK Drive 0 so even after we got a larger drive (80MB seemed like an infinite amount of storage after dealing with 2.4M) we left a disk with the bootstrap in RK0.
>
> I can’t remember the boot address on that machine, but the boot for the 11/70 I used for years at BRL is still ingrained in my memory:  7765000 (while it isn’t exactly right, I used the Glenn Miller PENNSYLVANIA-6-5000 as a memory aid).   Long after we gave up using PDP-11’s for UNIX machines, I recycled them all into internet routers using my own (“Little Operating System” LOS).   We had started with Noel’s MIT gateway but he was exiled at the time to the Bahamas or something and we decided it was easier starting over with the magnitude of changes we needed to make.
>
Thanks for the reply. SimH has built in boot ROM code for the RK 
controller and other devices as well. So, the boot loader code isn't 
really necessary, but I like to understand the things I am reading and 
the boot loader code is presented in the set up instructions, so I 
wanted to understand them before I moved on to other areas.

I appreciate the historical perspective. Glenn Miller, that's fun.

Regards,

Will


From lm at mcvoy.com  Sun Dec 27 14:30:42 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 26 Dec 2015 20:30:42 -0800
Subject: [TUHS] Unix on a game boy
Message-ID: <20151227043042.GF31614@mcvoy.com>

I must be the only guy here who browses reddit (or I missed someone
else posting this).

This dude ported 5th edition to a game boy.  I'll admit my non coolness
by saying I don't know what a game boy is but I'm guessing it's some
video game thingy.

http://www.kernelthread.com/publications/gbaunix/


From lm at mcvoy.com  Sun Dec 27 14:37:00 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 26 Dec 2015 20:37:00 -0800
Subject: [TUHS] Unix on a game boy
In-Reply-To: <20151227043042.GF31614@mcvoy.com>
References: <20151227043042.GF31614@mcvoy.com>
Message-ID: <20151227043700.GA26873@mcvoy.com>

So I just saw the title and posted, now I'm reading it, this guy is
pretty cool, he seems to know a lot.  I would vote for inviting him
to this list.

On Sat, Dec 26, 2015 at 08:30:42PM -0800, Larry McVoy wrote:
> I must be the only guy here who browses reddit (or I missed someone
> else posting this).
> 
> This dude ported 5th edition to a game boy.  I'll admit my non coolness
> by saying I don't know what a game boy is but I'm guessing it's some
> video game thingy.
> 
> http://www.kernelthread.com/publications/gbaunix/

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From dave at horsfall.org  Sun Dec 27 14:40:38 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 27 Dec 2015 15:40:38 +1100 (EST)
Subject: [TUHS] Unix on a game boy
In-Reply-To: <20151227043042.GF31614@mcvoy.com>
References: <20151227043042.GF31614@mcvoy.com>
Message-ID: <alpine.BSF.2.11.1512271533540.27165@aneurin.horsfall.org>

On Sat, 26 Dec 2015, Larry McVoy wrote:

> This dude ported 5th edition to a game boy.  I'll admit my non coolness 
> by saying I don't know what a game boy is but I'm guessing it's some 
> video game thingy.

Pretty much, yeah, along with PS/2 (and/or whatever).  I'm surprised that 
they chose Ed5, as Penguin/OS is normally the choice for weird devices.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From usotsuki at buric.co  Sun Dec 27 16:34:49 2015
From: usotsuki at buric.co (Steve Nickolas)
Date: Sun, 27 Dec 2015 07:34:49 +0100 (CET)
Subject: [TUHS] Unix on a game boy
In-Reply-To: <alpine.BSF.2.11.1512271533540.27165@aneurin.horsfall.org>
References: <20151227043042.GF31614@mcvoy.com>
 <alpine.BSF.2.11.1512271533540.27165@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.02.1512270733220.40710@frieza.hoshinet.org>

On Sun, 27 Dec 2015, Dave Horsfall wrote:

> On Sat, 26 Dec 2015, Larry McVoy wrote:
>
>> This dude ported 5th edition to a game boy.  I'll admit my non coolness
>> by saying I don't know what a game boy is but I'm guessing it's some
>> video game thingy.
>
> Pretty much, yeah, along with PS/2 (and/or whatever).  I'm surprised that
> they chose Ed5, as Penguin/OS is normally the choice for weird devices.

Well, if it's what I remember, it's a Game Boy Advance, which has an ARM 
CPU along with the nerfed Z80 of the original Game Boy.  Bit more 
Unix-friendly than an actual Game Boy. ;)

Though, the DS, which was its successor, does have a Linux port.

-uso.


From dave at horsfall.org  Sun Dec 27 21:23:01 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 27 Dec 2015 22:23:01 +1100 (EST)
Subject: [TUHS] Unix on a game boy
In-Reply-To: <alpine.BSF.2.02.1512270733220.40710@frieza.hoshinet.org>
References: <20151227043042.GF31614@mcvoy.com>
 <alpine.BSF.2.11.1512271533540.27165@aneurin.horsfall.org>
 <alpine.BSF.2.02.1512270733220.40710@frieza.hoshinet.org>
Message-ID: <alpine.BSF.2.11.1512272218190.27165@aneurin.horsfall.org>

On Sun, 27 Dec 2015, Steve Nickolas wrote:

> Well, if it's what I remember, it's a Game Boy Advance, which has an ARM 
> CPU along with the nerfed Z80 of the original Game Boy.  Bit more 
> Unix-friendly than an actual Game Boy. ;)
> 
> Though, the DS, which was its successor, does have a Linux port.

All the same, I'd probably go for either NetBSD or DragonFly.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From cowan at mercury.ccil.org  Mon Dec 28 03:51:32 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Sun, 27 Dec 2015 12:51:32 -0500
Subject: [TUHS] Unix on a game boy
In-Reply-To: <alpine.BSF.2.11.1512272218190.27165@aneurin.horsfall.org>
References: <20151227043042.GF31614@mcvoy.com>
 <alpine.BSF.2.11.1512271533540.27165@aneurin.horsfall.org>
 <alpine.BSF.2.02.1512270733220.40710@frieza.hoshinet.org>
 <alpine.BSF.2.11.1512272218190.27165@aneurin.horsfall.org>
Message-ID: <20151227175132.GA29293@mercury.ccil.org>

Dave Horsfall scripsit:
>
> On Sun, 27 Dec 2015, Steve Nickolas wrote:
> 
> > Well, if it's what I remember, it's a Game Boy Advance, which has an ARM 
> > CPU along with the nerfed Z80 of the original Game Boy.  Bit more 
> > Unix-friendly than an actual Game Boy. ;)

Just so.

> All the same, I'd probably go for either NetBSD or DragonFly.

The constraints are pretty tight.  The GBA has 32K of on-chip RAM and 256K
of off-chip RAM.  Cartridges have 32M of ROM, so the system disk is stored
in ROM with a shadow overlay in RAM.  In any case there is no keyboard
or other character input device: all it can do is run a preprogrammed
set of commands in the shell.  So running an ancyent Unixe on SIMH makes
a lot of sense, since the device can never be anything practical.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Assent may be registered by a signature, a handshake, or a click of a computer
mouse transmitted across the invisible ether of the Internet. Formality
is not a requisite; any sign, symbol or action, or even willful inaction,
as long as it is unequivocally referable to the promise, may create a contract.
       --Specht v. Netscape


From dave at horsfall.org  Mon Dec 28 05:23:50 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 28 Dec 2015 06:23:50 +1100 (EST)
Subject: [TUHS] Happy birthday, Jon von Neumann!
Message-ID: <alpine.BSF.2.11.1512280609550.27165@aneurin.horsfall.org>

Jon von Neumann was born in 1903; without him, we probably wouldn't have 
had computers at all (but we could've had a Wintel version, I suppose, 
wherein everything is controlled by BB).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From norman at oclsc.org  Mon Dec 28 06:01:56 2015
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 27 Dec 2015 15:01:56 -0500
Subject: [TUHS]  Happy birthday, Jon von Neumann!
Message-ID: <1451246520.14109.for-standards-violators@oclsc.org>

Dave Horsfall:

  Jon von Neumann was born in 1903; without him, we probably wouldn't have 
  had computers at all (but we could've had a Wintel version, I suppose, 
  wherein everything is controlled by BB).

====

On this day in Australia, but not yet in North America or Europe.

Or, as Warren would probably prefer, it was 2015 in England, but still only
1903 in Australia.  Such was the great difference in time twixt these two
great nations.

Australia, Australia, we love you from the heart,
the liver, the kidneys, and the giblets,
and every other part!

Norman Wilson
Toronto ON


From norman at oclsc.org  Mon Dec 28 06:02:09 2015
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 27 Dec 2015 15:02:09 -0500
Subject: [TUHS]  Unix on a game boy
Message-ID: <1451246533.14191.for-standards-violators@oclsc.org>

The real question: has anyone connected an RK05 to
a Game Boy?

Norman Wilson
Toronto ON
(Know what both of those are, have ever used only one)


From norman at oclsc.org  Mon Dec 28 06:32:12 2015
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 27 Dec 2015 15:32:12 -0500
Subject: [TUHS] v6 RK05 bootloader question
Message-ID: <1451248336.14973.for-standards-violators@oclsc.org>

Something of a tangent:

In my early days with UNIX, one of the systems I helped look
after was an 11/45.  Normally we booted it from an SMD disk
with a third-party RP-compatible contorller, for which we
had a boot ROM.  Occasionally, however, we wanted to boot it
from RK05, usually to run diagnostics, occasionally for some
emergency reason (like the root file system being utterly
scrambled, or the time we ran that system, with UNIX, on a
single RK05 pack, for several days so our secretaries could
keep doing their troff work while the people who had broken
our air-conditioning system got it fixed--all other systems
in our small machine room had to stay shut down).

There was no boot ROM for the RK05, but it didn't matter:
one just did the following from the front-panel switches:

1.  Halt/Enable to Halt
2.  System reset (also sends a reset to the UNIBUS)
3.  Load address 777404
4.  Deposit 5.
(watch lights blink for a second or so)
5.  Load address 0
6.  Halt/Enable to Enable
7.  Continue

777404 is the RK11's command register.  5 is a read command.
Resetting the system reset the RK11, which cleared all the
registers; in particular the word count, bus address, and
disk address registers.  So when the 5 was deposited (including
the bit 01, the GO bit), the RK11 would read from address 0 on
the disk to address 0 in physical memory, then increment the
word-count register, and keep doing so until the word count
was zero after the increment.  Or, in higher-level terms, read
the first 65536 words of the disk into the first 65536 words
of memory.

Then starting at address 0 would start executing whatever code
was at the beginning of memory (read from the beginning of the
disk).

Only the first 256 words (512 bytes) of the disk was really
needed, of course, but it was harmless, faster, and easier to
remember if one just left the word-count at its initial zero,
so that is what we did.

The boot ROM for the SMD disk had a certain charm as well.
It was a quad-high UNIBUS card with a 16x16 array of diodes,
representing 16 words of memory.  I forget whether one inserted
or removed a diode to make a bit one rather than zero.

It's too bad people don't get to do this sort of low-level stuff
these days; it gives one rather a good feel for what a bootstrap
does when one issues the command(s) oneself, or physically
programs the boot ROM.

Norman Wilson
Toronto ON


From khm at sciops.net  Mon Dec 28 06:36:24 2015
From: khm at sciops.net (Kurt H Maier)
Date: Sun, 27 Dec 2015 15:36:24 -0500
Subject: [TUHS] Happy birthday, Jon von Neumann!
In-Reply-To: <alpine.BSF.2.11.1512280609550.27165@aneurin.horsfall.org>
References: <alpine.BSF.2.11.1512280609550.27165@aneurin.horsfall.org>
Message-ID: <20151227203624.GI37664@wopr.sciops.net>

On Mon, Dec 28, 2015 at 06:23:50AM +1100, Dave Horsfall wrote:
> Jon von Neumann was born in 1903; without him, we probably wouldn't have 
> had computers at all (but we could've had a Wintel version, I suppose, 
> wherein everything is controlled by BB).

Sure we would have had computers.  We just wouldn't have had privilege
escalations based on stack smashes.  That guy ruined the ENIAC!

khm


From crossd at gmail.com  Mon Dec 28 11:35:58 2015
From: crossd at gmail.com (Dan Cross)
Date: Sun, 27 Dec 2015 20:35:58 -0500
Subject: [TUHS] Unix on a game boy
In-Reply-To: <alpine.BSF.2.11.1512271533540.27165@aneurin.horsfall.org>
References: <20151227043042.GF31614@mcvoy.com>
 <alpine.BSF.2.11.1512271533540.27165@aneurin.horsfall.org>
Message-ID: <CAEoi9W5170GUenf8A-QX6joJ59Gjqvc_dgBjXfozxPXk3sVSnA@mail.gmail.com>

To be fair, it's not so much a port of 5th Edition to the game boy, but
rather a port of a stripped down older version of SIMH's PDP-11 emulator
that is running a PDP 5th ed. It's still a great hack, of course....

On Sat, Dec 26, 2015 at 11:40 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sat, 26 Dec 2015, Larry McVoy wrote:
>
> > This dude ported 5th edition to a game boy.  I'll admit my non coolness
> > by saying I don't know what a game boy is but I'm guessing it's some
> > video game thingy.
>
> Pretty much, yeah, along with PS/2 (and/or whatever).  I'm surprised that
> they chose Ed5, as Penguin/OS is normally the choice for weird devices.
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151227/3e51c0ed/attachment.html>

From peter at rulingia.com  Mon Dec 28 17:48:30 2015
From: peter at rulingia.com (Peter Jeremy)
Date: Mon, 28 Dec 2015 18:48:30 +1100
Subject: [TUHS] Happy birthday, Jon von Neumann!
In-Reply-To: <alpine.BSF.2.11.1512280609550.27165@aneurin.horsfall.org>
References: <alpine.BSF.2.11.1512280609550.27165@aneurin.horsfall.org>
Message-ID: <20151228074830.GA64282@server.rulingia.com>

On 2015-Dec-28 06:23:50 +1100, Dave Horsfall <dave at horsfall.org> wrote:
>Jon von Neumann was born in 1903; without him, we probably wouldn't have 
>had computers at all

There were computers before von Neumann - mostly female.

Without the von Neumann architechure, an entire class of exploits
wouldn't exist.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151228/48e47518/attachment.sig>

From brad at anduin.eldar.org  Tue Dec 29 03:58:39 2015
From: brad at anduin.eldar.org (Brad Spencer)
Date: Mon, 28 Dec 2015 12:58:39 -0500 (EST)
Subject: [TUHS] Unix on a game boy
In-Reply-To: <alpine.BSF.2.11.1512271533540.27165@aneurin.horsfall.org>
 (message from Dave Horsfall on Sun, 27 Dec 2015 15:40:38 +1100 (EST))
References: <20151227043042.GF31614@mcvoy.com>
 <alpine.BSF.2.11.1512271533540.27165@aneurin.horsfall.org>
Message-ID: <201512281758.tBSHwdIC004558@anduin.eldar.org>


   On Sat, 26 Dec 2015, Larry McVoy wrote:

   > This dude ported 5th edition to a game boy.  I'll admit my non coolness 
   > by saying I don't know what a game boy is but I'm guessing it's some 
   > video game thingy.

   Pretty much, yeah, along with PS/2 (and/or whatever).  I'm surprised that 
   they chose Ed5, as Penguin/OS is normally the choice for weird devices.

   -- 
   Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."



It is running V5 in SIMH on the Gameboy.  Pretty nifty, however, the ARM
processor varient does not have a memory manager, so I suspect that it had
to be something simpler then one of the modern systems.  This wasn't a
bare iron port.

If you go to the page, he does not one of the early BSD systems running in
SIMH on it too.




-- 
Brad Spencer - brad at anduin.eldar.org - KC8VKS
http://anduin.eldar.org  - & -  http://anduin.ipv6.eldar.org [IPv6 only]


From will.senn at gmail.com  Tue Dec 29 09:24:58 2015
From: will.senn at gmail.com (Will Senn)
Date: Mon, 28 Dec 2015 17:24:58 -0600
Subject: [TUHS] Unix Sixth Edition Boot Loader Analyses
Message-ID: <5681C4CA.3040908@gmail.com>

All,

I just finished some compact analyses on the boot loaders that are 
presented in "Setting up Unix - Sixth Edition" by Thompson and Ritchie. 
They are in followup to the more detailed analysis of the Tape Bootstrap 
Loader that I mentioned previously and the entry is posted here:
http://decuser.blogspot.com/2015/12/pdp-11-bootstrap-loaders-some-analysis.html

What was most interesting about the analyses and programs was how 
related they were. At the end of the day, once I understood how the 
first one worked, the other two were pretty simple and required only 
minor tweaks in the coding to achieve their results.

I am moving on now that I have a pretty good idea of how these bits of 
code work and will be starting to program in Macro-11 for a few weeks to 
get a handle on things before I return to the deep dive into the source 
code of v6 that I temporarily put on hold so I could actually make sense 
of the Assembly bits.

I really appreciate everyone's help, tips, suggestions and even critiques.

Thanks,

Will


From luvisi at gmail.com  Tue Dec 29 10:05:15 2015
From: luvisi at gmail.com (Andru Luvisi)
Date: Mon, 28 Dec 2015 16:05:15 -0800
Subject: [TUHS] Happy birthday, Jon von Neumann!
In-Reply-To: <alpine.BSF.2.11.1512280609550.27165@aneurin.horsfall.org>
References: <alpine.BSF.2.11.1512280609550.27165@aneurin.horsfall.org>
Message-ID: <CAObyg6bQxVD3bXgS0nCb_Nb_qwHh+_MBsbP9vUtSAsd81MU8aA@mail.gmail.com>

On January 29, 1944 J. Presper Eckert wrote a memo explaining how
information could be stored on spinning disks, using one large memory to
hold intermediate results, lookup tables, and program information.  This
was several months before von Neumann joined the project.  See A History of
Computing in the Twentieth Century (1980).

von Neumann did a good job of writing up the idea, but it would have
happened without him.

Andru

On Sun, Dec 27, 2015 at 11:23 AM, Dave Horsfall <dave at horsfall.org> wrote:

> Jon von Neumann was born in 1903; without him, we probably wouldn't have
> had computers at all (but we could've had a Wintel version, I suppose,
> wherein everything is controlled by BB).
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151228/c23fee8c/attachment.html>

From grog at lemis.com  Tue Dec 29 11:07:37 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 29 Dec 2015 12:07:37 +1100
Subject: [TUHS] Happy birthday, Jon von Neumann!
In-Reply-To: <CAObyg6bQxVD3bXgS0nCb_Nb_qwHh+_MBsbP9vUtSAsd81MU8aA@mail.gmail.com>
References: <alpine.BSF.2.11.1512280609550.27165@aneurin.horsfall.org>
 <CAObyg6bQxVD3bXgS0nCb_Nb_qwHh+_MBsbP9vUtSAsd81MU8aA@mail.gmail.com>
Message-ID: <20151229010737.GO14449@eureka.lemis.com>

On Monday, 28 December 2015 at 16:05:15 -0800, Andru Luvisi wrote:
> On Sun, Dec 27, 2015 at 11:23 AM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> Jon von Neumann was born in 1903; without him, we probably wouldn't have
>> had computers at all (but we could've had a Wintel version, I suppose,
>> wherein everything is controlled by BB).
>
> On January 29, 1944 J. Presper Eckert wrote a memo explaining how
> information could be stored on spinning disks, using one large memory to
> hold intermediate results, lookup tables, and program information.  This
> was several months before von Neumann joined the project.  See A History of
> Computing in the Twentieth Century (1980).

If anybody's interested, there's an online version of this memo at
http://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index/k-8-pdf/k-8-u2775-Mauchly-letter-plus.pdf ,
not the first document on that page.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151229/acdc8243/attachment.sig>

From grog at lemis.com  Tue Dec 29 11:21:20 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 29 Dec 2015 12:21:20 +1100
Subject: [TUHS] CTSS user interface?=
In-Reply-To: <FDD64393-35C2-4730-AB03-33E0DCCEC351@multicians.org>
References: <20151226014434.7C7911D786E@niwun.pair.com>
 <FDD64393-35C2-4730-AB03-33E0DCCEC351@multicians.org>
Message-ID: <20151229012120.GA5811@eureka.lemis.com>

I got this a couple of days ago and thought I had sent it on, but
apparently not.  Here goes.

Greg

On Saturday, 26 December 2015 at 11:12:59 -0500, Tom Van Vleck wrote:
> Short answer to your question is "depends on what you mean by shell."
> Answer for Unix heads is http://multicians.org/shell.html where Louis Pouzin says he made up the name
> for Multics.  We never called the CTSS command processor a shell.
>
> When I used CTSS in 1963, command processing was in (wired) code in A-core.
> A simple program tokenized input lines, looked up the token in A-core tables, and either ran an
> A-core routine or loaded a command file, passing the rest of the arguments as a string array.
> To add a command, you had to recompile CTSS.  Look at the module COMC in the source.
>
> This command language is documented in the "candy stripe" CTSS manual.
> http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide.pdf
>
> About 1964 or 65, COMC was changed to not list the disk loaded commands; if the table
> lookup failed, COMC looked for a disk file in a system directory, and ran it if it was found.
> System maintainers could add a command by copying a file into the directory.
> Command files were in core image format, already loaded and linked.  Conventional practice
> was to make them small and to expand the core image for things like I/O buffers at execution start.
>
> Some disk-loaded commands were listed in COMC and flagged as "privileged" so that they could
> call special supervisor entries to get the supervisor to do things forbidden to regular programs.
> the LOGIN command was an example: it could read the password file, forbidden to regular users,
> and could patch the A-core table of logged in users.
>
> Louis wrote a disk loaded program called RUNCOM that read command lines from a file, substituted
> arguments into the command, and requested the supervisor to run them, and then return control
> to RUNCOM.  This is a shell-like function.
>
> Noel Morris and I wrote an author-maintained unprivileged B-core CTSS program in 1965 called
> . SAVED that was also shell-like.  It read lines from the terminal, tokenized them, expanded
> abbreviations and iterations, and ran sequences of commands, and then resumed itself.  It had other
> features such as inter-user text messages. It allowed power CTSS users to extend the
> system-provided command set with their own set of SAVED files, all treated uniformly.
>
> Noel and I also added a facility to CTSS that allowed the system to run batch jobs.  The user
> submitted a RUNCOM file to a queue for later processing, much like Unix CRON.
>
> Revised command processing, RUNCOM, and . SAVED are documented in the second edition CTSS manual.
> http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf
>
> Multics had a program known as the shell, which went through a long series of evolutions.
> Users could replace their command shell. A program called the listener read command lines
> and fed them to the shell, which tokenized the command lines and found and called individual commands.
> The argument-substituting run-from-a-file mode of operation of RUNCOM was done by the exec_com command.
> All of these Multics features and design were familiar to Ken and Dennis when they worked on Multics.
>
> You say you have been looking at the CTSS source.  You know you can run a simulated
> 7094 running a simulated CTSS, right?  http://www.cozx.com/~dpitts/ibm7090.html
>
> regards, tom

--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151229/e5c51d39/attachment.sig>

From cowan at mercury.ccil.org  Tue Dec 29 11:35:19 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 28 Dec 2015 20:35:19 -0500
Subject: [TUHS] CTSS user interface?=
In-Reply-To: <20151229012120.GA5811@eureka.lemis.com>
References: <20151226014434.7C7911D786E@niwun.pair.com>
 <FDD64393-35C2-4730-AB03-33E0DCCEC351@multicians.org>
 <20151229012120.GA5811@eureka.lemis.com>
Message-ID: <20151229013519.GA20275@mercury.ccil.org>

Greg 'groggy' Lehey scripsit:

> > Louis wrote a disk loaded program called RUNCOM that read command
> > lines from a file,

Hence, presumably, the .foorc files of Unix and the rc shell.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
I suggest you solicit aid of my followers or learn the difficult art
of mud-breathing.  --Great-Souled Sam


From grog at lemis.com  Tue Dec 29 13:51:33 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 29 Dec 2015 14:51:33 +1100
Subject: [TUHS] CTSS user interface?=
In-Reply-To: <20151229013519.GA20275@mercury.ccil.org>
References: <20151226014434.7C7911D786E@niwun.pair.com>
 <FDD64393-35C2-4730-AB03-33E0DCCEC351@multicians.org>
 <20151229012120.GA5811@eureka.lemis.com>
 <20151229013519.GA20275@mercury.ccil.org>
Message-ID: <20151229035133.GP14449@eureka.lemis.com>

On Monday, 28 December 2015 at 20:35:19 -0500, John Cowan wrote:
> Greg 'groggy' Lehey scripsit:
>
>>> Louis wrote a disk loaded program called RUNCOM that read command
>>> lines from a file,
>
> Hence, presumably, the .foorc files of Unix and the rc shell.

Indeed.  I didn't think of that, but you woke some reminiscence.  And
how about that, there's a Wikipedia page,
https://en.wikipedia.org/wiki/Run_commands

Clearly TEDickey hasn't found this page yet.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151229/0ca0311f/attachment.sig>

From tim.newsham at gmail.com  Tue Dec 29 14:05:09 2015
From: tim.newsham at gmail.com (Tim Newsham)
Date: Mon, 28 Dec 2015 18:05:09 -1000
Subject: [TUHS] v8 / v9 / v10
Message-ID: <CAGSRWbizB_A9uS2zkGUMX0L8dhtq-dCJXA0QQJkEGyhvNTTvnw@mail.gmail.com>

It's been a while since I checked..  have v8, v9 and v10
made it out into the public yet?

-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151228/f73abcba/attachment.html>

From cowan at mercury.ccil.org  Tue Dec 29 14:48:48 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 28 Dec 2015 23:48:48 -0500
Subject: [TUHS] v8 / v9 / v10
In-Reply-To: <CAGSRWbizB_A9uS2zkGUMX0L8dhtq-dCJXA0QQJkEGyhvNTTvnw@mail.gmail.com>
References: <CAGSRWbizB_A9uS2zkGUMX0L8dhtq-dCJXA0QQJkEGyhvNTTvnw@mail.gmail.com>
Message-ID: <20151229044845.GB20275@mercury.ccil.org>

Tim Newsham scripsit:

> It's been a while since I checked..  have v8, v9 and v10
> made it out into the public yet?

No, they never have, and the rights are hopelessly snarled FWIU.
There's only one person I know of who has a copy of v10 running outside
the workplace; that person is on this list.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
While staying with the Asonu, I met a man from the Candensian plane,
which is very much like ours, only more of it consists of Toronto.
        --Ursula K. Le Guin, Changing Planes


From doug at cs.dartmouth.edu  Tue Dec 29 16:38:26 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 29 Dec 2015 01:38:26 -0500
Subject: [TUHS] Subject: Re:  CTSS user interface
Message-ID: <201512290638.tBT6cQXs002161@coolidge.cs.Dartmouth.EDU>

> > Louis wrote a disk loaded program called RUNCOM that read command
> > lines from a file,

> Hence, presumably, the .foorc files of Unix and the rc shell.

Yes, rc files were named for runcom, but did not adhere to runcom's
curious limit of 6 commands.

Doug


From will.senn at gmail.com  Wed Dec 30 06:55:39 2015
From: will.senn at gmail.com (Will Senn)
Date: Tue, 29 Dec 2015 14:55:39 -0600
Subject: [TUHS] v6 RK05 bootloader question
In-Reply-To: <1451248336.14973.for-standards-violators@oclsc.org>
References: <1451248336.14973.for-standards-violators@oclsc.org>
Message-ID: <F20F2025-0234-4FC9-B953-24D85349606B@gmail.com>

All,

I am preparing to open a SimH ticket around hand entered boot loaders along the lines of the one described by Norman below. Currently, the simulator doesn't allow the console operator to perform this type of boot. Although, it should be theoretically possible to follow the steps as given with the expected result, the simulator just doesn't work exactly like the console. I have this example and can theorize others, but if y'all know of some you actually used to boot your PDP-11 machine from tape/disk/etc,  I will happily include them in my request. It is possible/likely that the SimH pdp-11 simulator can be modified to support this process.

Thanks,

Will

Sent from my iPhone

> On Dec 27, 2015, at 2:32 PM, Norman Wilson <norman at oclsc.org> wrote:
> 
> Something of a tangent:
> 
> In my early days with UNIX, one of the systems I helped look
> after was an 11/45.  Normally we booted it from an SMD disk
> with a third-party RP-compatible contorller, for which we
> had a boot ROM.  Occasionally, however, we wanted to boot it
> from RK05, usually to run diagnostics, occasionally for some
> emergency reason (like the root file system being utterly
> scrambled, or the time we ran that system, with UNIX, on a
> single RK05 pack, for several days so our secretaries could
> keep doing their troff work while the people who had broken
> our air-conditioning system got it fixed--all other systems
> in our small machine room had to stay shut down).
> 
> There was no boot ROM for the RK05, but it didn't matter:
> one just did the following from the front-panel switches:
> 
> 1.  Halt/Enable to Halt
> 2.  System reset (also sends a reset to the UNIBUS)
> 3.  Load address 777404
> 4.  Deposit 5.
> (watch lights blink for a second or so)
> 5.  Load address 0
> 6.  Halt/Enable to Enable
> 7.  Continue
> 
> 777404 is the RK11's command register.  5 is a read command.
> Resetting the system reset the RK11, which cleared all the
> registers; in particular the word count, bus address, and
> disk address registers.  So when the 5 was deposited (including
> the bit 01, the GO bit), the RK11 would read from address 0 on
> the disk to address 0 in physical memory, then increment the
> word-count register, and keep doing so until the word count
> was zero after the increment.  Or, in higher-level terms, read
> the first 65536 words of the disk into the first 65536 words
> of memory.
> 
> Then starting at address 0 would start executing whatever code
> was at the beginning of memory (read from the beginning of the
> disk).
> 
> Only the first 256 words (512 bytes) of the disk was really
> needed, of course, but it was harmless, faster, and easier to
> remember if one just left the word-count at its initial zero,
> so that is what we did.
> 
> The boot ROM for the SMD disk had a certain charm as well.
> It was a quad-high UNIBUS card with a 16x16 array of diodes,
> representing 16 words of memory.  I forget whether one inserted
> or removed a diode to make a bit one rather than zero.
> 
> It's too bad people don't get to do this sort of low-level stuff
> these days; it gives one rather a good feel for what a bootstrap
> does when one issues the command(s) oneself, or physically
> programs the boot ROM.
> 
> Norman Wilson
> Toronto ON


From ron at ronnatalie.com  Wed Dec 30 07:37:35 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 29 Dec 2015 16:37:35 -0500
Subject: [TUHS] v6 RK05 bootloader question
In-Reply-To: <F20F2025-0234-4FC9-B953-24D85349606B@gmail.com>
References: <1451248336.14973.for-standards-violators@oclsc.org>
 <F20F2025-0234-4FC9-B953-24D85349606B@gmail.com>
Message-ID: <E8BFE5AF-D16C-4528-947B-4F7838A13397@ronnatalie.com>

Yep, I suspect the simulator “console” doesn’t let you deposit directly into the simulated unibus csrs.


I bet there’s some more stuff they get wrong.   Not everything on the PDP-11’s is actually documented.   I bet I can’t lock up the system by loading up the address space in user mode with SPL instructions either :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151229/555322ba/attachment.bin>

From wkt at tuhs.org  Wed Dec 30 11:37:49 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 30 Dec 2015 11:37:49 +1000
Subject: [TUHS] A Wiki for Unix
Message-ID: <20151230013749.GA15802@minnie.tuhs.org>

I decided that, given that we have a few years until the 50th anniversary,
that I would set up a wiki for Unix in a similar vein to the Multicians one.

So I've made a start at http://wiki.tuhs.org (if/when the A record propagates).

I'd love to get some other people to help out, but I'll keep adding stuff
and we will see how it goes. Any good anecdotes about Unix are most welcome!

If you want to get edit status, register and then e-mail me so I can
manually mark you as having edit status.

Cheers, Warren


From helbig at mailbox.org  Wed Dec 30 17:14:50 2015
From: helbig at mailbox.org (Wolfgang Helbig)
Date: Wed, 30 Dec 2015 08:14:50 +0100
Subject: [TUHS] v6 RK05 bootloader question
In-Reply-To: <F20F2025-0234-4FC9-B953-24D85349606B@gmail.com>
References: <1451248336.14973.for-standards-violators@oclsc.org>
 <F20F2025-0234-4FC9-B953-24D85349606B@gmail.com>
Message-ID: <685C2CB4-B23B-4A9C-833D-EE27B37B7ECF@mailbox.org>

What went wrong with simh? It worked fine with examples that I entered. Find working “simh”-Programs at
	http://wwwlehre.dhbw-stuttgart.de/~helbig/os/pdp11/progs/

They might help to narrow in the problem.

Greetings,
Wolfgang

From will.senn at gmail.com  Wed Dec 30 17:29:51 2015
From: will.senn at gmail.com (Will Senn)
Date: Wed, 30 Dec 2015 01:29:51 -0600
Subject: [TUHS] v6 RK05 bootloader question
In-Reply-To: <685C2CB4-B23B-4A9C-833D-EE27B37B7ECF@mailbox.org>
References: <1451248336.14973.for-standards-violators@oclsc.org>
 <F20F2025-0234-4FC9-B953-24D85349606B@gmail.com>
 <685C2CB4-B23B-4A9C-833D-EE27B37B7ECF@mailbox.org>
Message-ID: <568387EF.6010407@gmail.com>



On 12/30/15 1:14 AM, Wolfgang Helbig wrote:
> What went wrong with simh? It worked fine with examples that I entered. Find working “simh”-Programs at
> 	http://wwwlehre.dhbw-stuttgart.de/~helbig/os/pdp11/progs/
>
> They might help to narrow in the problem.
>
> Greetings,
> Wolfgang
Wolfgang,

Nothing is wrong with SimH's handling of the machine code programs that 
I know of. It is when you try to modify the device registers directly 
using deposit to effect the boot loading that the simulator doesn't 
operate as would a real PDP-11. For example, Norman Wilson's example:

1.  Halt/Enable to Halt
2.  System reset (also sends a reset to the UNIBUS)
3.  Load address 777404
4.  Deposit 5.
(watch lights blink for a second or so)
5.  Load address 0
6.  Halt/Enable to Enable
7.  Continue

This doesn't work in SimH. I asked Mark Pizzolato about why, and he suggested the following:

The reason is that on real hardware, when an I/O activity
is initiated via some register probing, the device will then perform the commanded
activity in parallel to the simulator's execution of instructions.  A device driver will
either wait for an interrupt to know when to proceed or it will read some device
status register periodically or in a tight loop to determine completion.  With hand
entered boot code, the goal is to minimize typing of boot code and since
operations will complete (from a human perspective) as soon as the user is done
typing, instructions which wait for I/O completion are not provided as  part of the
hand typed boot code.

Simh devices don't actually operate in parallel with the CPU.  The concept of
parallel operation is simulated by the devices performing their activities in
between the execution of simulated instructions.  The simh framework has
the ability to allow a device simulation to schedule its activation in between
some future number of instructions executed.  This allows programs in the
simulated system to see that some time has elapsed from when a device
operation is initiated to when it completes.  A hand entered bootstrap program
without any loops to wait for completion status generally won't execute
enough instructions to allow the desired operation to actually complete

Which makes sense, but doesn't sound like a brick wall. Yes, the console 
method leverages side effects, granted, but the console method worked on 
a real PDP, just not on the simulator. It will with some 
modifications... To be honest, I really liked the idea of making 
Norman's method work in SimH because it's fun and feels historic, and if 
I can provide other similar examples along with some supporting text, 
the modification can probably be made. Then I can write another blog 
entry for posterity that's a little more fun and a little less 
technical, well that depends on the reader's perspective, but certainly 
light on technical details :).

Thanks,

Will






From wkt at tuhs.org  Wed Dec 30 19:27:30 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 30 Dec 2015 19:27:30 +1000
Subject: [TUHS] References for Unix Papers/Publications?
Message-ID: <20151230092730.GA9325@minnie.tuhs.org>

Someone off-list today asked about an annotated list of Unix papers which
might be good to add to the new wiki.

I've just uploaded my own short list of Unix papers, in BibTeX format, on
the wiki at:
http://wiki.tuhs.org/lib/exe/fetch.php?media=publications:wkt_reflist.bib

If you have your own list of references in whatever format, could you
upload them into the wiki also?

Once you have registered and have write permissions, go to:
Media manager -> publications -> Upload. Select your file and upload.

The dokuwiki can deal with references in BibTeX format, I just don't know how
to do it yet. Once I do, I'll decorate links to papers with a reference.

Cheers & thanks, Warren

P.S I just uploaded some of the BSTJ papers into
http://www.tuhs.org/Archive/Documentation/Papers/BSTJ/


From will.senn at gmail.com  Wed Dec 30 23:28:33 2015
From: will.senn at gmail.com (Will Senn)
Date: Wed, 30 Dec 2015 07:28:33 -0600
Subject: [TUHS] References for Unix Papers/Publications?
In-Reply-To: <20151230092730.GA9325@minnie.tuhs.org>
References: <20151230092730.GA9325@minnie.tuhs.org>
Message-ID: <5683DC01.1070606@gmail.com>



On 12/30/15 3:27 AM, Warren Toomey wrote:
> Someone off-list today asked about an annotated list of Unix papers which
> might be good to add to the new wiki.
>
> I've just uploaded my own short list of Unix papers, in BibTeX format, on
> the wiki at:
> http://wiki.tuhs.org/lib/exe/fetch.php?media=publications:wkt_reflist.bib
>
> If you have your own list of references in whatever format, could you
> upload them into the wiki also?
>
> Once you have registered and have write permissions, go to:
> Media manager -> publications -> Upload. Select your file and upload.
>
> The dokuwiki can deal with references in BibTeX format, I just don't know how
> to do it yet. Once I do, I'll decorate links to papers with a reference.
>
> Cheers & thanks, Warren
>
> P.S I just uploaded some of the BSTJ papers into
> http://www.tuhs.org/Archive/Documentation/Papers/BSTJ/
Warren,

Nelson Beebe's massive UNIX bibliography is exhaustive. Perhaps linking 
to it would help folks looking for a definitive list:

http://ftp.math.utah.edu/pub/tex/bib/unix.bib

The site also has practically every UNIX related Journal's up to date 
BIBTEX entries.

That said, it's not where one would look for a selection of titles with 
annotations and I don't know if it's accessible by author, though I 
expect it probably is.

You probably can't imagine the hours that I spent hunting down the BSTJ 
papers in pdf form, thanks for adding them into the site!

Will





From khm at sciops.net  Wed Dec 30 23:40:39 2015
From: khm at sciops.net (Kurt H Maier)
Date: Wed, 30 Dec 2015 08:40:39 -0500
Subject: [TUHS] References for Unix Papers/Publications?
In-Reply-To: <20151230092730.GA9325@minnie.tuhs.org>
References: <20151230092730.GA9325@minnie.tuhs.org>
Message-ID: <20151230134039.GC50885@wopr.sciops.net>

On Wed, Dec 30, 2015 at 07:27:30PM +1000, Warren Toomey wrote:
> Someone off-list today asked about an annotated list of Unix papers which
> might be good to add to the new wiki.

There is a good selection of unix papers available at
http://doc.cat-v.org/unix/ as well.

khm


From fair-tuhs at netbsd.org  Thu Dec 31 04:06:57 2015
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Wed, 30 Dec 2015 10:06:57 -0800
Subject: [TUHS] v6 RK05 bootloader question
In-Reply-To: <568387EF.6010407@gmail.com>
References: <685C2CB4-B23B-4A9C-833D-EE27B37B7ECF@mailbox.org>
Message-ID: <22302.1451498817@cesium.clock.org>

Related minicomputer booting story:

I cut my computing teeth on the PDP-11's competitor, the Data General NOVA minicomputer. Edson de Castro supposedly proposed the architecture to Ken Olson, and when Ken said "no", Edson left DEC and founded DG - much as we've seen companies in Silicon Valley beget each other when some smart engineers get annoyed with their bosses. Fairchild begat Intel and AMD, Cisco begat Juniper, et alia.

Rather than memory-mapped I/O, the NOVA had I/O instructions, and six bits of device codes. Every interrupt handler I saw for the NOVA ended in the same self-modifying code sequence: if your OS doesn't handle the device that has interrupted, put the device code into an interrupt dismiss instruction in the next location, fall into it to shut the device up, and return from interrupt.

Booting the NOVA (provided you knew the device code of the device you wanted to boot from) was simplicity itself:

Power everything up.

Mount the media (disk, tape) including any positioning as required

Put I/O device online (frequently an explicit act involving a switch)

Set the CPU front panel switches to the 6-bit device code

Hit in order the momentary contact switches: STOP, RESET, START

The CPU would read the device code from the front panel switches, read the first record (of arbitrary size) from the device into RAM starting at location 0, and set the program counter (PC) to zero and begin execution of whatever was read in from the I/O device.

Disks had a primary booter in the first 512 bytes (so, 256 16-bit instructions & data) which would read in the rest of whatever OS you were booting. Necessarily, that booter needed to know where to load the OS from on disk.

Since "page zero" of the NOVA (the first 256 words of RAM) was a critical resource (direct reference from anywhere else in RAM rather than using space-expensive indirect addressing, plus, there were some autoincrement and autodecrement locations - reading them caused the stored value to change - handy for counters and pointers), the booter usually got overwritten.

Booting an OS from tape was easier because of the arbitrary record size: you could fit a whole tape OS into a single record and start running immediately - no intermediate boot code required. OTOH, tape OSes were really slow when all their files were on very slow tape drives (if you were lucky, you had vacuum column tape drives - faster for positioning).

Life got lots easier when PROMs got big & cheap enough for on-board firmware like IEEE 1275 (OpenBoot/Open Firmware, a formalization of Sun's forth-based firmware).

So far as I know, Unix (DG/UX) didn't come to DG until the Eclipse MV ("Eagle") 32-bit computer of literary fame.

	ancient history,

	Erik <fair at netbsd.org>


From cowan at mercury.ccil.org  Thu Dec 31 04:33:31 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Wed, 30 Dec 2015 13:33:31 -0500
Subject: [TUHS] v6 RK05 bootloader question
In-Reply-To: <22302.1451498817@cesium.clock.org>
References: <685C2CB4-B23B-4A9C-833D-EE27B37B7ECF@mailbox.org>
 <22302.1451498817@cesium.clock.org>
Message-ID: <20151230183331.GA448@mercury.ccil.org>

Erik E. Fair scripsit:

> Rather than memory-mapped I/O, the NOVA had I/O instructions, and
> six bits of device codes. 

Same as the PDP-8, in fact.  But all my PDP-8 work was with OS/8,
which runs with interrupts off: you can turn them on in userland if your
program wants to use them, but you have to shut them off before invoking
any system services.  So I know little of these sixties sitcoms of
which you speak.

> Since "page zero" of the NOVA (the first 256 words of RAM) was a
> critical resource (direct reference from anywhere else in RAM rather
> than using space-expensive indirect addressing, plus, there were some
> autoincrement and autodecrement locations - reading them caused the
> stored value to change - handy for counters and pointers), 

All exactly like the PDP-8.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
You are a child of the universe no less than the trees and all other acyclic
graphs; you have a right to be here.  --DeXiderata by Sean McGrath


From wkt at tuhs.org  Thu Dec 31 12:52:16 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 31 Dec 2015 12:52:16 +1000
Subject: [TUHS] List(s) of Unix Web Sites?
Message-ID: <20151231025215.GA900@minnie.tuhs.org>

Hi all, thanks for the wiki suggestions so far.

Does anybody have any lists of good Unix websites that I can add in to
the wiki at http://wiki.tuhs.org/doku.php?id=publications:websites

Also, any suggestions on how to organise the page, as I can see we will
end up with hundreds of links!

Cheers, Warren


From helbig at mailbox.org  Thu Dec 31 18:06:33 2015
From: helbig at mailbox.org (Wolfgang Helbig)
Date: Thu, 31 Dec 2015 09:06:33 +0100
Subject: [TUHS] v6 RK05 bootloader question
In-Reply-To: <568387EF.6010407@gmail.com>
References: <1451248336.14973.for-standards-violators@oclsc.org>
 <F20F2025-0234-4FC9-B953-24D85349606B@gmail.com>
 <685C2CB4-B23B-4A9C-833D-EE27B37B7ECF@mailbox.org>
 <568387EF.6010407@gmail.com>
Message-ID: <0E0FF1D5-DFAC-4798-8AC3-DC0172080141@mailbox.org>

Hallo Will,

Ah, I understand:
The HALT instruction of the real PDP11 only stops the CPU whereas simulator also stops simulating the devices.

By the way, I modified simh 2.6:
The simulated clock ticks at real 60 Hz.
The simulater waits a little bit in each cycle. This saves the real CPU from overheating and slows down
the execution to a more realistic level.
I can attach terminals, this gives you a more realistc multi user experience.

Greetings,
Wolfgang




From jnc at mercury.lcs.mit.edu  Thu Dec 31 23:45:23 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 31 Dec 2015 08:45:23 -0500 (EST)
Subject: [TUHS] v6 RK05 bootloader question
Message-ID: <20151231134523.33F9318C0D5@mercury.lcs.mit.edu>

    > From: Wolfgang Helbig

    > The HALT instruction of the real PDP11 only stops the CPU 

I have this bit set that on at least some models of the real machine, when
the CPU is halted, it does not do DMA grants? If so, on such machines, the
trick of depositing in the device registers directly would not work; the
device could not do the bus cycles to do the transfer to memory. Anyone know
for sure which models do service DMA requests while halted?

	Noel


