From clemc at ccc.com  Wed Oct  1 00:32:57 2014
From: clemc at ccc.com (Clem Cole)
Date: Tue, 30 Sep 2014 10:32:57 -0400
Subject: [TUHS] TMG and B
In-Reply-To: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu>
References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu>
Message-ID: <CAC20D2P4UqDOiYU5RKcXmAaDrQWrsgLWxPCE2Dv6f078R+Xi8g@mail.gmail.com>

​amen​

On Tue, Sep 30, 2014 at 9:52 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> I said something to the effect of 'clearly I've lived
> through a second golden age, and only now am I understanding that'.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140930/94bd35c5/attachment.html>

From dave at horsfall.org  Wed Oct  1 03:44:37 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 1 Oct 2014 03:44:37 +1000 (EST)
Subject: [TUHS] TMG and B
In-Reply-To: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu>
References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.00.1410010342250.84871@aneurin.horsfall.org>

On Tue, 30 Sep 2014, Noel Chiappa wrote:

> And of course the networking work soon sucked me in completely. In that 
> message to Jerry, I said something to the effect of 'clearly I've lived 
> through a second golden age, and only now am I understanding that'.

Please, people; keep these stories up!

TUHS == The Unix Historical Society (ignore my own name for it; I'm in Oz).

-- Dave


From cowan at mercury.ccil.org  Wed Oct  1 06:08:21 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Tue, 30 Sep 2014 16:08:21 -0400
Subject: [TUHS] TMG and B
In-Reply-To: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu>
References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu>
Message-ID: <20140930200821.GN22934@mercury.ccil.org>

Noel Chiappa scripsit:

> And of course the networking work soon sucked me in completely. In that
> message to Jerry, I said something to the effect of 'clearly I've lived
> through a second golden age, and only now am I understanding that'.

"What is the Golden Age of science fiction?"

"Twelve."

  --Peter Graham

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
The experiences of the past show that there has always been a discrepancy
between plans and performance.        --Emperor Hirohito, August 1945


From spedraja at gmail.com  Wed Oct  1 07:07:51 2014
From: spedraja at gmail.com (SPC)
Date: Tue, 30 Sep 2014 23:07:51 +0200
Subject: [TUHS] TMG and B
In-Reply-To: <20140930200821.GN22934@mercury.ccil.org>
References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu>
 <20140930200821.GN22934@mercury.ccil.org>
Message-ID: <CACytpF99yQ40T8rLVV8=GOvpHDbeLmPkzN+9Y9-nWJ0W63QxEg@mail.gmail.com>

A beautiful discussión. Thanks everybody.

Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations
​
-- 
*Sergio Pedraja*
-- 
mobile: +34-699-996568
twitter: @sergio_pedraja | skype: Sergio Pedraja
--
http://plus.google.com/u/0/101292256663392735405
http://www.linkedin.com/in/sergiopedraja
http://www.quora.com/Sergio-Pedraja
http://spedraja.wordpress.com
https://www.xing.com/profile/Sergio_Pedraja <http://spedraja.wordpress.com/>
-----
No crea todo lo que ve, ni crea que está viéndolo todo


2014-09-30 22:08 GMT+02:00 John Cowan <cowan at mercury.ccil.org>:

> Noel Chiappa scripsit:
>
> > And of course the networking work soon sucked me in completely. In that
> > message to Jerry, I said something to the effect of 'clearly I've lived
> > through a second golden age, and only now am I understanding that'.
>
> "What is the Golden Age of science fiction?"
>
> "Twelve."
>
>   --Peter Graham
>
> --
> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> The experiences of the past show that there has always been a discrepancy
> between plans and performance.        --Emperor Hirohito, August 1945
> _______________________________________________
> 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/20140930/87e0ccf5/attachment.html>

From dave at horsfall.org  Wed Oct  1 07:15:46 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 1 Oct 2014 07:15:46 +1000 (EST)
Subject: [TUHS] TMG and B
In-Reply-To: <CACytpF99yQ40T8rLVV8=GOvpHDbeLmPkzN+9Y9-nWJ0W63QxEg@mail.gmail.com>
References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu>
 <20140930200821.GN22934@mercury.ccil.org>
 <CACytpF99yQ40T8rLVV8=GOvpHDbeLmPkzN+9Y9-nWJ0W63QxEg@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1410010712040.86851@aneurin.horsfall.org>

On Tue, 30 Sep 2014, SPC wrote:

> A beautiful discussión. Thanks everybody.

The best bit (which I've saved somewhere) is that needing a PL/I compiler 
*for* TMG, they wrote such a compiler *in* TMG...

Talk about boot-strapping...

-- Dave

From dave at horsfall.org  Wed Oct  1 07:26:18 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 1 Oct 2014 07:26:18 +1000 (EST)
Subject: [TUHS] TMG and B
In-Reply-To: <alpine.BSF.2.00.1410010342250.84871@aneurin.horsfall.org>
References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu>
 <alpine.BSF.2.00.1410010342250.84871@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.00.1410010724430.86851@aneurin.horsfall.org>

Speaking of TMG, is there an implementation for FreeBSD/Mac/Linux?  Or do 
I have to find a CDC/PDP-7 emulator first? :-)

-- Dave


From random832 at fastmail.us  Wed Oct  1 08:13:39 2014
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Tue, 30 Sep 2014 18:13:39 -0400
Subject: [TUHS] Fwd: [tz] Time, Clock, and Calendar Programming In C,
	by Eric S. Raymond
Message-ID: <1412115219.3741374.173656693.20224E67@webmail.messagingengine.com>

Eric S. Raymond has written an article about the history of the time.h
functions at http://www.catb.org/esr/time-programming/

>From his blog post announcing it (http://esr.ibiblio.org/?p=6311):

> The C/UNIX library support for time and calendar programming is a nasty mess of historical contingency. I have grown tired of having to re-learn its quirks every time I’ve had to deal with it, so I’m doing something about that.
> 
> Announcing Time, Clock, and Calendar Programming In C, a document which attempts to chart the historical clutter (so you can ignore it once you know why it’s there) and explain the mysteries.
> 
> What I’ve released is an 0.9 beta version. My hope is that it will rapidly attract some thoroughgoing reviews so I can release a 1.0 in a week or so. More than that, I would welcome a subject matter expert as a collaborator.

When I saw it I thought it might be generally interesting to people who
subscribe to this list.


From cubexyz at gmail.com  Wed Oct  1 08:52:01 2014
From: cubexyz at gmail.com (Mark Longridge)
Date: Tue, 30 Sep 2014 18:52:01 -0400
Subject: [TUHS] TMG and B
In-Reply-To: <alpine.BSF.2.00.1410010724430.86851@aneurin.horsfall.org>
References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu>
 <alpine.BSF.2.00.1410010342250.84871@aneurin.horsfall.org>
 <alpine.BSF.2.00.1410010724430.86851@aneurin.horsfall.org>
Message-ID: <CADxT5N5arMD_ac+DffR52ioiry3ztODKVgau9xkfwfB9Pi2qsA@mail.gmail.com>

>Speaking of TMG, is there an implementation for FreeBSD/Mac/Linux?  Or do
> I have to find a CDC/PDP-7 emulator first? :-)
>
>-- Dave

TMG is mentioned in the v3 manual:

/sys/tmg/tmgl.o -- the compiler-compiler

There's no files for it for v5 but it is in v6 and it seems to
disappear after that.
On TUHS V6/usr/source/tmg/tmgl.t would seem to be a source file.

I did manage to get something running for pdp-7 on simh and got to the
GA prompt.
Didn't get it to do much beyond printing "CAB DECSYS7 COPY   15 JUNE 1966"

Mark


Mark





On 9/30/14, Dave Horsfall <dave at horsfall.org> wrote:
> Speaking of TMG, is there an implementation for FreeBSD/Mac/Linux?  Or do
> I have to find a CDC/PDP-7 emulator first? :-)
>
> -- Dave
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>


From doug at cs.dartmouth.edu  Wed Oct  1 23:53:37 2014
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 01 Oct 2014 09:53:37 -0400
Subject: [TUHS] TMG and B
Message-ID: <201410011353.s91DrbjT000929@coolidge.cs.dartmouth.edu>

TMG was in v2-v6, sometimes in man1 and sometimes in man6.
I have an apparently complete source listing. The year is
uncertain. (Back then date headings from pr didn't mention the year!)
The accompanying manual, though, is dated 1972. There is also, besides
the TMGL definition of TMGL, a TMGL definition of pig Latin as a
simple test case.

None of this is useful, though, without a PDP-11 binary for tmg--
the usual chicken-and-egg problem with a full-blown compiler written
in its own language.

Doug

> >Speaking of TMG, is there an implementation for FreeBSD/Mac/Linux?  Or do
> > I have to find a CDC/PDP-7 emulator first? :-)
> >
> >-- Dave
> 
> TMG is mentioned in the v3 manual:
> 
> /sys/tmg/tmgl.o -- the compiler-compiler
> 
> There's no files for it for v5 but it is in v6 and it seems to
> disappear after that.
> On TUHS V6/usr/source/tmg/tmgl.t would seem to be a source file.
> 
> I did manage to get something running for pdp-7 on simh and got to the
> GA prompt.
> Didn't get it to do much beyond printing "CAB DECSYS7 COPY   15 JUNE 1966"
> 
> Mark


From jnc at mercury.lcs.mit.edu  Thu Oct  2 00:04:23 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed,  1 Oct 2014 10:04:23 -0400 (EDT)
Subject: [TUHS] TMG and B
Message-ID: <20141001140423.D047418C10D@mercury.lcs.mit.edu>

    > From: Doug McIlroy <doug at cs.dartmouth.edu>

    > None of this is useful, though, without a PDP-11 binary for tmg

There seems to be be binary for TMG on the V6 distribution.

	Noel


From dave at horsfall.org  Thu Oct  2 06:23:14 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 2 Oct 2014 06:23:14 +1000 (EST)
Subject: [TUHS] TMG and B
In-Reply-To: <201410011353.s91DrbjT000929@coolidge.cs.dartmouth.edu>
References: <201410011353.s91DrbjT000929@coolidge.cs.dartmouth.edu>
Message-ID: <alpine.BSF.2.00.1410020615000.86851@aneurin.horsfall.org>

On Wed, 1 Oct 2014, Doug McIlroy wrote:

> None of this is useful, though, without a PDP-11 binary for tmg-- the 
> usual chicken-and-egg problem with a full-blown compiler written in its 
> own language.

Hmmm...  I haven't used YACC for many years (not since my CompSci days, 
when I was considering a Pascal->C translator for my thesis; I had 
threatened to write it in SNOBOL) so if a suitable rainy day comes along 
(and I can get the manpage etc) I might give it a stab.

-- Dave


From dave at horsfall.org  Thu Oct  2 06:33:18 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 2 Oct 2014 06:33:18 +1000 (EST)
Subject: [TUHS] TMG and B
In-Reply-To: <CADxT5N5arMD_ac+DffR52ioiry3ztODKVgau9xkfwfB9Pi2qsA@mail.gmail.com>
References: <20140930135228.4147A18C0FB@mercury.lcs.mit.edu>
 <alpine.BSF.2.00.1410010342250.84871@aneurin.horsfall.org>
 <alpine.BSF.2.00.1410010724430.86851@aneurin.horsfall.org>
 <CADxT5N5arMD_ac+DffR52ioiry3ztODKVgau9xkfwfB9Pi2qsA@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1410020631120.86851@aneurin.horsfall.org>

On Tue, 30 Sep 2014, Mark Longridge wrote:

> On TUHS V6/usr/source/tmg/tmgl.t would seem to be a source file.

Hmmm...  It *almost* makes sense, to someone who has never seen TMG 
before.

-- Dave


From wkt at tuhs.org  Thu Oct  2 21:46:26 2014
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 2 Oct 2014 21:46:26 +1000
Subject: [TUHS] made up errno contest, at an early USENIX
In-Reply-To: <201409271919.s8RJJwPx019024@skeeve.com>
References: <201409271919.s8RJJwPx019024@skeeve.com>
Message-ID: <20141002114626.GA548@www.oztivo.net>

On Sat, Sep 27, 2014 at 10:19:58PM +0300, Aharon Robbins wrote:
> This is really gonna stretch the memories. (I may have even asked about
> it on this list before.)
> At one of the earlier USENIX conferences that I attended, maybe in
> Atlanta, there was a contest to make up humorous new errno values.

I'm back from a trip to Cania Gorge in Queensland Australia where there is
next to no phone reception.

When I scanned in the old AUUG newsletters, I told the photocopier to also
do OCR. This means that I can do this to the scanned files:

for i in *.pdf
do j=`echo $i | sed 's/pdf/txt/'`
   echo $j
   pdftotext $i
   grep ENO $j
   rm $j
done

Yet another reason why Unix is so much better :-) Here are the results
which will help Arnold out with his question.

Cheers, Warren

http://minnie.tuhs.org/Archive/Documentation/AUUGN/

AUUGN-V07.23.txt
ENOTOBACCO
ENOHORSE
ENONSEQUITUR

AUUGN-V07.45.txt
ENOINSTRUCTIONSET
ENOSTD
ENOP
ENOTON UNIX
ENOVAX
ENOFOOT
ENOCOFFEE
ENOLICENCE
ENOLICENSE
ENOTUNIX
ENOMONEYNOFUN
ENOTFOUND
ENOALCHOHOL
ENOJOY
ENOBAR
ENOTOBACCO

AUUGN-V08.34.txt
ENOTABACCO, read on an empty pipe?
ENOGOOD
ENOWARP
ENOTHEAVY
ENOUGH
ENOTONHORSE
ENOPHONEBOOK
ENOCONTEST
ENOARMSCONTROL
ENOSTRADAMUS
ENOAIR
ENOARMSCONTROL
ENOBOZOS
ENOCH
ENOCHICKEN
ENOCONTEST
ENOCORN
ENOCURRENT
ENODICE
ENOENO
ENOENO
ENOERROR
ENOFLUID
ENOGOOD
ENOGREYHOUND
ENOH20
ENOHOPE
ENOKISS
ENOKNOW
ENOMAAM
ENOMULTIHOP
ENON
ENONCOGNISCENT
ENONO
ENOONE
ENOPAPER
ENOPHONEBOOK
ENORMOUS
ENOSALT
ENOSAUSAGE
ENOSELECTRIC
ENOSTRADAMUS
ENOTATE
ENOTCOMPLETE
ENOTHEAVY
ENOTME
ENOTMYFAULT
ENOTONHORSE
ENOUGH
ENOUGH
ENOUGH
ENOUGH
ENOUNIX
ENOV1CE
ENOWARP
ENOWA.Y

AUUGN-V09.6.txt
ENOTUNIX
ENOTOBACCO




From arnold at skeeve.com  Thu Oct  2 22:12:21 2014
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 02 Oct 2014 06:12:21 -0600
Subject: [TUHS] made up errno contest, at an early USENIX
In-Reply-To: <20141002114626.GA548@www.oztivo.net>
References: <201409271919.s8RJJwPx019024@skeeve.com>
 <20141002114626.GA548@www.oztivo.net>
Message-ID: <201410021212.s92CCL1L015109@freefriends.org>

Hi Warren.

Really cool.

Can you grep for EMRED?  (Doesn't match ENO).

Thanks!

Arnold

Warren Toomey <wkt at tuhs.org> wrote:

> On Sat, Sep 27, 2014 at 10:19:58PM +0300, Aharon Robbins wrote:
> > This is really gonna stretch the memories. (I may have even asked about
> > it on this list before.)
> > At one of the earlier USENIX conferences that I attended, maybe in
> > Atlanta, there was a contest to make up humorous new errno values.
>
> I'm back from a trip to Cania Gorge in Queensland Australia where there is
> next to no phone reception.
>
> When I scanned in the old AUUG newsletters, I told the photocopier to also
> do OCR. This means that I can do this to the scanned files:
>
> for i in *.pdf
> do j=`echo $i | sed 's/pdf/txt/'`
>    echo $j
>    pdftotext $i
>    grep ENO $j
>    rm $j
> done
>
> Yet another reason why Unix is so much better :-) Here are the results
> which will help Arnold out with his question.
>
> Cheers, Warren
>
> http://minnie.tuhs.org/Archive/Documentation/AUUGN/
>
> ...


From norman at oclsc.org  Thu Oct  2 23:00:34 2014
From: norman at oclsc.org (Norman Wilson)
Date: Thu,  2 Oct 2014 09:00:34 -0400 (EDT)
Subject: [TUHS] made up errno contest, at an early USENIX
Message-ID: <20141002130034.2DDA71DE38C@lignose.oclsc.org>

arnold at skeeve.com:

  Can you grep for EMRED?  (Doesn't match ENO).

====

Why not grep for E[A-Z][A-Z]*?

Norman Wilson
Toronto ON


From dwalker at doomd.net  Fri Oct  3 00:52:25 2014
From: dwalker at doomd.net (Derrik Walker v2.0)
Date: Thu, 02 Oct 2014 10:52:25 -0400
Subject: [TUHS] made up errno contest, at an early USENIX
In-Reply-To: <20141002114626.GA548@www.oztivo.net>
References: <201409271919.s8RJJwPx019024@skeeve.com>
 <20141002114626.GA548@www.oztivo.net>
Message-ID: <542D66A9.9050903@doomd.net>

On 10/2/14, 7:46, Warren Toomey wrote:
> Yet another reason why Unix is so much better :-)
UNIX is just better than just about anything when you have real work to 
get done.

For example, we have a popular web log analyzer program ( that shall 
remain nameless ), that apparently is not very capable, because they 
frequently ask me to make custom reports.  Naturally I use the UNIX 
tools available to that I know how to use ... And so I keep threatening 
to just re-write that application in AWK.

- Derrik




From wkt at tuhs.org  Fri Oct  3 08:19:06 2014
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 3 Oct 2014 08:19:06 +1000
Subject: [TUHS] made up errno contest, at an early USENIX
In-Reply-To: <201410021212.s92CCL1L015109@freefriends.org>
References: <201409271919.s8RJJwPx019024@skeeve.com>
 <20141002114626.GA548@www.oztivo.net>
 <201410021212.s92CCL1L015109@freefriends.org>
Message-ID: <20141002221906.GA7379@www.oztivo.net>

On Thu, Oct 02, 2014 at 06:12:21AM -0600, arnold at skeeve.com wrote:
> Hi Warren.
> Really cool.
> Can you grep for EMRED?  (Doesn't match ENO).

Results are: AUUGN-V07.23 and AUUGN-V08.34 which are in
http://minnie.tuhs.org/Archive/Documentation/AUUGN/

Cheers, Warren


From wkt at tuhs.org  Fri Oct  3 12:45:14 2014
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 3 Oct 2014 12:45:14 +1000
Subject: [TUHS] Unisoft V7 68k sources (reviving a Codata machine)
Message-ID: <20141003024514.GA16961@www.oztivo.net>

I just received a new TUHS subscription request along with
an interesting query. Can anybody help Michael with his problem?

Cheers, Warren

----- Forwarded message from "Engel, Michael" -----
Dear Warren,

Could you please subscribe me to the TUHS mailing list?

I haven't worked with old Unix systems for quite some time, but I was appointed as a 
Senior Lecturer at Leeds Beckett University (UK) two months ago and - to my big 
surprise - I found an old Unix machine collecting dust in a corner..

The machine is a Codata 300, a Multibus-based system using a licensed clone of the
original Sun 100U CPU board and a number of additional Multibus controllers. The
machine seems to be complete, including two 8" SMD disks and a Cipher 9-track
tape drive, we also seem to have a set of replacement boards and the CPU board
manual (including schematics and code snippets explaining how to access the onboard
devices - some Codata documentation can also be found on bitkeeper).

We haven't tried to power up the machine yet (and, built around 1983, it certainly needs 
a close examination of the power supply and capacitors). From information on the net,
this machine runs a Unisoft port of 7th Edition Unix - similar to the Sun 1 machines and 
probably a Whitesmiths C compiler (there's a Whitesmiths license badge attached to the 
case). Definitely a very interesting and probably quite rare machine and we would like
to revive it (and, if things go well, create a FPGA reimplementation of the system in
the context of a student design project).

Now, I would love to know more details about the implementation of 7th Edition Unix on 
the 68000 and the use of the custom MMU built out of fast SRAM and TTL logic. 
I do not think that source code to any of the various 68k 7th Edition ports produced by 
Unisoft is available somewhere - do you know of a possible source?

Alternatively, do you think it would be worthwhile asking Unisoft for the source code or
do you know if anyone has tried this already? According to the Unisoft history web page 
(http://www.unisoft.com/history.html), they still seem to know that they were porting Unix 
30 years ago...

The only remotely related source code I could find in my archives is the A/UX 0.7 source 
(SVR2, if I'm not mistaken), which probably already required a 68020 with 68851 MMU.

Best regards,
     Michael Engel
----- End forwarded message -----


From wkt at tuhs.org  Fri Oct  3 13:36:32 2014
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 3 Oct 2014 13:36:32 +1000
Subject: [TUHS] 2.9bsd on 11/45 restoration
Message-ID: <20141003033632.GD18537@www.oztivo.net>

Also, I had this e-mail sent to me from Jacob who is a long-time TUHS
person. Again, he has questions I don't know the answers to. Anybody?

Cheers, Warren
----- Forwarded message from Jacob Ritorto -----

   Greetings Warren,
   Â  It's been decades since we last corresponded and I'm delighted to
   see that you're still active in the pdp11 unix community!Â  I've found
   some free time and have been kicking around the idea of repairing
   the11/45 I scored some years ago (11/45 system number 273 from Stanford
   University) and installing 2.9bsd on it.Â  You helped me out years ago
   when I had an 11/34 and I managed to do it back then, so I have some
   hope this time around too, though there are some more serious hurdles
   now.Â  Glad to see that a lot of the license trolling finally appears
   to be settled and we can have unfettered access to all the good stuff!
   Â
   Â  Any pointers to who
   has parts and troubleshooting knowledge would be a big help.
   Â  Softwarewise, I was also thinking I'd like to get my Fuji160 disks
   working on the machine.Â  Has work like this been done already, or
   would you have pointers as to how to go about it?
   Â Â Also, has anyone written a miniature httpd for any of the ancient
   bsds?
   thanks
   jake
----- End forwarded message -----


From arnold at skeeve.com  Fri Oct  3 19:24:02 2014
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 03 Oct 2014 03:24:02 -0600
Subject: [TUHS] made up errno contest, at an early USENIX
In-Reply-To: <20141002221906.GA7379@www.oztivo.net>
References: <201409271919.s8RJJwPx019024@skeeve.com>
 <20141002114626.GA548@www.oztivo.net>
 <201410021212.s92CCL1L015109@freefriends.org>
 <20141002221906.GA7379@www.oztivo.net>
Message-ID: <201410030924.s939O2Rl027337@freefriends.org>

Warren Toomey <wkt at tuhs.org> wrote:

> On Thu, Oct 02, 2014 at 06:12:21AM -0600, arnold at skeeve.com wrote:
> > Hi Warren.
> > Really cool.
> > Can you grep for EMRED?  (Doesn't match ENO).
>
> Results are: AUUGN-V07.23 and AUUGN-V08.34 which are in
> http://minnie.tuhs.org/Archive/Documentation/AUUGN/
>
> Cheers, Warren

Much thanks!

Arnold


From steve at quintile.net  Sat Oct  4 05:03:15 2014
From: steve at quintile.net (Steve Simon)
Date: Fri, 3 Oct 2014 20:03:15 +0100
Subject: [TUHS] Unisoft V7 68k sources (reviving a Codata machine)
Message-ID: <94465b124eb0b546811ba9c04caf37d2@quintile.net>

> The machine is a Codata 300

Wow.

I went to Leeds Poly (as it was then) in the mid 1980s.

There where two Codatas in the electronics dept., one in its
original plastic case and one 19inch rackmount - built as a
IEEE 488 controller; I assume what you have is one of those.

The former machine was loaded with Whitesmiths cross compilers
and I learnt z80 assembly language on it ☺

It ran V7 indeed, and was a friend of the Interdata/Perkin Elmer 
3210, the  main electronics teaching machine. If it is this
machine then it should have the V7 source from the 3210 (Xelos
as it was called) and the source for the drivers for the
codata (which we gained by "accident").

I may be able to remember some other snippets - contat me 
off-list with specific questions. I can give you the names
of the lecturers who would know most about it but I guess they
are now retired (though they may still be Headingly somwhere).

(fondly remembers Leeds).

-Steve


From M.Engel at leedsbeckett.ac.uk  Sat Oct  4 06:23:46 2014
From: M.Engel at leedsbeckett.ac.uk (Engel, Michael)
Date: Fri, 3 Oct 2014 20:23:46 +0000
Subject: [TUHS] Unisoft V7 68k sources (reviving a Codata machine)
In-Reply-To: <94465b124eb0b546811ba9c04caf37d2@quintile.net>
References: <94465b124eb0b546811ba9c04caf37d2@quintile.net>
Message-ID: <3C89F8B8-AE41-426B-80EF-1438FCCEAA7F@leedsmet.ac.uk>


Hi Steve, 

whow, what a small world!

On 03 Oct 2014, at 20:03, Steve Simon <steve at quintile.net> wrote:

>> The machine is a Codata 300
> 
> Wow.
> 
> I went to Leeds Poly (as it was then) in the mid 1980s.
> 
> There where two Codatas in the electronics dept., one in its
> original plastic case and one 19inch rackmount - built as a
> IEEE 488 controller; I assume what you have is one of those.

The machines were a bit cannibalised over the last decades,
we actually have the boards from both machines, one of them
build into the 19" rack machine. The machine survived the 
closing down of the electronics department, now we're busy
building everything up again... 

> The former machine was loaded with Whitesmiths cross compilers
> and I learnt z80 assembly language on it ☺

There's still a Whitesmiths logo attached to the case - this is what
the machine looks like today: http://multicores.org/Codata.jpg
A 5.25" ST412 disk, two 8" SMD disks and a Cypher 9 track tape
are also still there.

> It ran V7 indeed, and was a friend of the Interdata/Perkin Elmer 
> 3210, the  main electronics teaching machine. If it is this
> machine then it should have the V7 source from the 3210 (Xelos
> as it was called) and the source for the drivers for the
> codata (which we gained by "accident").

Whow, let's keep our fingers crossed that the disks still work...
I haven't tried powering the machine up so far. Unfortunately,
the Interdata no longer exists (what a pity), but the first thing
I will do when the machine is running is to run a full backup. 
Luckily, the Codata has a 5.25" floppy drive, since I no longer 
have easy access to a 9-track SCSI drive (and the last time 
I set up UUCP is far too long ago...).

> I may be able to remember some other snippets - contat me 
> off-list with specific questions. I can give you the names
> of the lecturers who would know most about it but I guess they
> are now retired (though they may still be Headingly somwhere).

Actually, quite a number of the people are still here. More off-list.

> (fondly remembers Leeds).

I only came to Leeds about two months ago - and so far, it's really
great here!

Best wishes,
    Michael


From fair at netbsd.org  Fri Oct  3 14:02:31 2014
From: fair at netbsd.org (Erik Fair)
Date: Thu, 2 Oct 2014 21:02:31 -0700
Subject: [TUHS] Unisoft V7 68k sources (reviving a Codata machine)
In-Reply-To: <20141003024514.GA16961@www.oztivo.net>
References: <20141003024514.GA16961@www.oztivo.net>
Message-ID: <EFE26D04-7AC7-409F-80E4-ADE9970CEFFC@netbsd.org>

I recently sent the following message to port-m68k at netbsd.org that relates to that period in time:



Begin forwarded message:

> From: Erik Fair <fair at netbsd.org>
> Subject: DUAL Systems documentation
> Date: February 22, 2014 at 02:12:17 PST
> To: port-m68k at netbsd.org
> 
> For those of you of a historical or digital archeological bent: while googling for something else, I came across this URL:
> 
> http://www.hartetechnologies.com/manuals/DUAL/
> 
> which contains PDFs of a few manuals & a price list from DUAL Systems of Berkeley, CA. DUAL produced the very first mc68000-based UNIX system (V7 UNIX on the S-100 (IEEE-696) bus), starting in November of 1981. I worked there as a UNIX systems programmer (kernel hacker) as my first job out of U.C. Berkeley from March 1983 to May 1985.
> 
> Of particular interest to this group: the CPU/MMU board manual. Please note: the mc68000 could not demand-page (i.e. no virtual memory) because the CPU did not save enough state from a memory access fault to restart the faulted instruction, so UNIX was a swapping OS (whole process in RAM, whole process out to swap area on disk if not enough RAM is available for whatever else needed to run).
> 
> Motorola corrected the fault state save in the mc68010, which provided the ability to make a proper VM system ... except for the mc68451 MMU (yes, a discrete MMU chip, in a package every bit as big as the CPU) which had only 32 descriptor registers (translation table entries). Motorola's theory was that if you wanted more (as one might for a lots of smaller-sized pages), add more MMU chips to your CPU board. Unfortunately, that doesn't fly on a board size as small as allowed by the S-100 standard. They were working on a proper paged MMU (PMMU) chip to go along with the mc68020 (the first fully 32-bit (address & data) 68k family CPU), but it was very, very late (DUAL was moving onto VMEbus from S-100 for the mc68020).
> 
> An aside, before Motorola shipped the mc68010, I saw another solution to the faulted-instruction state save problem from MassComp: their CPU board had two mc68k CPUs on it, one running a cycle behind the other, so a page fault would stop them both, the missing page could be paged in (I think they designed their own MMU; long since forgotten), and then execution resumed on the second, following CPU which hadn't taken the memory-access fault. Throw hardware at the problem ...
> 
> 	faulting my way down memory lane,
> 
> 	Erik <fair at netbsd.org>
> 	formerly {ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair


UniSoft Systems was started by Jeff Schriebman at the behest of Dual to port V7 UNIX to Dual’s system; they were just a few blocks away from Dual in west Berkeley, on 6th Street, if memory serves.

CoData was one of Dual’s competitors - I usually saw their gear at vendor shows (e.g. when /usr/group held its vendor show co-located with USENIX conferences). One of the problems at the time that bedeviled UniSoft was that every 68k-based Unix box had its own unique MMU because Motorola’s offerings in that space (as noted above) were … lacking. So UniSoft had to redo the kernel MMU code for every strange and wonderful MMU that each hardware vendor came up with. Pixel, Plexus, Fortune, Codata, Apple (yes, UniSoft did a port of Unix to the Lisa and the awful 5MB “profile” drive on a parallel port (!!)), ...

I have at least two old Dual boxes in my garage that I keep for sentimental reasons, but I have no idea what’s on those disks, or if they’ll even spin up after so long. They’re ST-506/419 interface 5.25 inch “winchester” drives; a forerunner of a sort of the IBM PC’s IDE. I wrote the drivers for the Morrow Designs (“ThinkerToys”) S-100 controller as my first project for Dual in March/April 1983.

Previously, Dual was using 8-inch Memorex hard drives controlled by a CompuPro (nee “Godbout Electronics”) controller whose interface standard I don’t recall. I’ll have to see if they can be fired up again, and see what’s on the hard drives. Dual was very particular about using big, heavy linear power supplies in its systems as a matter of reliability, over the (to their mind) squirrelly switching power supplies that many of our competitors were using.

The other way to go to get Unix going on that old Codata box would be a port of NetBSD/m68k - it supports a wide array of mc68k systems:

	http://www.netbsd.org/ports/#ports-by-cpu

The trick would be writing the MMU code, and a booter that would work with whatever firmware Codata used back in the day. I had to work on Dual’s boot firmware from time to time, and I recall it being fairly simple (“find /unix and see if it’s a.out, load, and jump”), and usually the trick is to make a secondary booter that the system firmware will load (in whatever executable format the firmware will recognize) to then parse a modern ELF kernel from FFSv2.

NetBSD continues to support a whole lot of pretty old hardware - we believe in portability.

	Erik <fair at netbsd.org>



From random832 at fastmail.us  Sat Oct  4 18:06:08 2014
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Sat, 04 Oct 2014 04:06:08 -0400
Subject: [TUHS] 2.9bsd on 11/45 restoration
In-Reply-To: <20141003033632.GD18537@www.oztivo.net>
References: <20141003033632.GD18537@www.oztivo.net>
Message-ID: <1412409968.4044604.175047129.718DCCD3@webmail.messagingengine.com>

On Thu, Oct 2, 2014, at 23:36, Warren Toomey wrote:
> Also, I had this e-mail sent to me from Jacob who is a long-time TUHS
> person. Again, he has questions I don't know the answers to. Anybody?
> 
> Cheers, Warren
> ----- Forwarded message from Jacob Ritorto -----
> 
...
>    Â Â Also, has anyone written a miniature httpd for any of the ancient
>    bsds?

Seeing this question, I figured "it can't be that hard", and managed to
get tinyhttpd  http://tinyhttpd.sourceforge.net/ to compile on 2.11BSD.
Mostly just required K&R-ification, though I also had to fix some bugs
in the way it uses buffers to get it to work at all. Normal GET requests
work; The whole CGI thing I disabled because I couldn't get it to work
reliably even on modern linux.

Not actually tested, though - I couldn't get simh to emulate a network
device.


From jnc at mercury.lcs.mit.edu  Sat Oct  4 22:19:01 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat,  4 Oct 2014 08:19:01 -0400 (EDT)
Subject: [TUHS] 2.9bsd on 11/45 restoration
Message-ID: <20141004121901.B3F4718C0AE@mercury.lcs.mit.edu>

    > From: Warren Toomey <wkt at tuhs.org>

    >> have been kicking around the idea of repairing the11/45 I scored some
    >> years ago (11/45 system number 273 from Stanford University)
    >> ..
    >> Any pointers to who has parts and troubleshooting knowledge would be a
    >> big help.

Anyone seriously working on bringing old hardware back to life needs to get
in touch with the Classic Computer Talk list:

    http://www.classiccmp.org/mailman/listinfo/cctalk

A wealth of experience and knowledge on every conceivable topic involved in
old hardware is available there, and people are very helpful.

	Noel


From jnc at mercury.lcs.mit.edu  Sat Oct  4 22:31:06 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat,  4 Oct 2014 08:31:06 -0400 (EDT)
Subject: [TUHS] RL02 drives available
Message-ID: <20141004123106.6B08718C0AE@mercury.lcs.mit.edu>

Some guy on eBay has a flock of RL02 drives available (in New York, USA) for a
pretty reasonable price:

  http://www.ebay.com/itm/261288230510

I just bought a flock of them, and they are in very good condition. They were
only recently withdrawn from service (at the FAA, so they were professionally
maintained up until they went), and were properly prepared for moving (heads
immobilized, _and_ the motor was locked down - very rare to see that last
step, as is involves finding the right machine screws - or having saved them).

They are late-production ones, too (looked, but couldn't find a date) - they
have the anti-RFI/EMI 'finger' strips (the kind that make a pressure-loaded
contact with the incoming connector shell), which I personally had never seen
on any RL0x drives.

Alas, they have no packs or terminators available, nor cables or slides (any
more :-). But other than that, recommended.

     Noel


From dave at horsfall.org  Sun Oct  5 06:26:40 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 5 Oct 2014 07:26:40 +1100 (EST)
Subject: [TUHS] 2.9bsd on 11/45 restoration
In-Reply-To: <20141004121901.B3F4718C0AE@mercury.lcs.mit.edu>
References: <20141004121901.B3F4718C0AE@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.00.1410050725230.86851@aneurin.horsfall.org>

On Sat, 4 Oct 2014, Noel Chiappa wrote:

> Anyone seriously working on bringing old hardware back to life needs to 
> get in touch with the Classic Computer Talk list:

Is John Dodson on this list?  He has an 11/70 in his house.

-- Dave


From dave at horsfall.org  Sun Oct  5 06:36:44 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 5 Oct 2014 07:36:44 +1100 (EST)
Subject: [TUHS] RL02 drives available
In-Reply-To: <20141004123106.6B08718C0AE@mercury.lcs.mit.edu>
References: <20141004123106.6B08718C0AE@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.00.1410050726510.86851@aneurin.horsfall.org>

On Sat, 4 Oct 2014, Noel Chiappa wrote:

> They are late-production ones, too (looked, but couldn't find a date) - 
> they have the anti-RFI/EMI 'finger' strips (the kind that make a 
> pressure-loaded contact with the incoming connector shell), which I 
> personally had never seen on any RL0x drives.

Ex-FAA?  Airport radar?  Those puppies are *powerful*.

ObReminisce: Back in the 70s-80s, the University of NSW put its new 
computer centre on the top floor of a 14-floor building (they were afraid 
of student riots at the time[*]), within clear view of Sydney Airport; the 
windows were lined with mesh, and you could hear them *click* every time 
the radar swung around.

[*]

Ah yes, the top floor.  The other reason was fear of flooding.  One day, 
the air conditioning sprang a major leak, and this corrosive green liquid 
ended up all over the brand spanking new high-speed CDC card reader...

-- Dave


From random832 at fastmail.us  Sun Oct  5 13:26:53 2014
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Sat, 04 Oct 2014 23:26:53 -0400
Subject: [TUHS] 2.9bsd on 11/45 restoration
In-Reply-To: <CAHYQbfBaPwsA0ps3FS9LKdeLKSjYCxTrYtPc5Ct4AV0Sgs1S0w@mail.gmail.com>
References: <20141003033632.GD18537@www.oztivo.net>
 <1412409968.4044604.175047129.718DCCD3@webmail.messagingengine.com>
 <CAHYQbfBaPwsA0ps3FS9LKdeLKSjYCxTrYtPc5Ct4AV0Sgs1S0w@mail.gmail.com>
Message-ID: <1412479613.72555.175236101.7727764C@webmail.messagingengine.com>

On Sat, Oct 4, 2014, at 12:37, Jacob Ritorto wrote:
> nice.  may i see your difffs?
> 
> On Sat, Oct 4, 2014 at 4:06 AM, <random832 at fastmail.us> wrote:
> >
> > Seeing this question, I figured "it can't be that hard", and managed to
> > get tinyhttpd  http://tinyhttpd.sourceforge.net/ to compile on 2.11BSD.
> > Mostly just required K&R-ification, though I also had to fix some bugs
> > in the way it uses buffers to get it to work at all. Normal GET requests
> > work; The whole CGI thing I disabled because I couldn't get it to work
> > reliably even on modern linux.
> >
> > Not actually tested, though - I couldn't get simh to emulate a network
> > device.


Sure.

Security note: the httpd itself doesn't appear to do anything about e.g.
".." in pathnames, and I didn't do anything about that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tinyhttpd.diff
Type: application/octet-stream
Size: 12009 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141004/536f69a2/attachment.obj>

From random832 at fastmail.us  Mon Oct  6 05:49:28 2014
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Sun, 05 Oct 2014 15:49:28 -0400
Subject: [TUHS] 2.9bsd on 11/45 restoration
In-Reply-To: <1412538525.277114.175397473.12347280@webmail.messagingengine.com>
References: <20141003033632.GD18537@www.oztivo.net>
 <1412409968.4044604.175047129.718DCCD3@webmail.messagingengine.com>
 <CAHYQbfBaPwsA0ps3FS9LKdeLKSjYCxTrYtPc5Ct4AV0Sgs1S0w@mail.gmail.com>
 <1412479613.72555.175236101.7727764C@webmail.messagingengine.com>
 <CAHYQbfC3t-5ukH-xM1QL5nq21DiC2z3i5bcPWcmgoQK4TZDkbA@mail.gmail.com>
 <1412538525.277114.175397473.12347280@webmail.messagingengine.com>
Message-ID: <1412538568.277182.175397609.016E5931@webmail.messagingengine.com>

On Sun, Oct 5, 2014, at 13:47, Jacob Ritorto wrote:
> awesome, man, thanks.  If I fork tinyhttpd on github, mind if I use 'em?
> I'll attribute to you of course  If ok, any license preference?  I
> usually
> use MIT..

tinyhttpd itself is not mine and appears to be under the GPL.


From bqt at update.uu.se  Mon Oct  6 07:01:43 2014
From: bqt at update.uu.se (Johnny Billquist)
Date: Sun, 05 Oct 2014 23:01:43 +0200
Subject: [TUHS] 2.9bsd on 11/45 restoration
In-Reply-To: <mailman.1.1412470802.24227.tuhs@minnie.tuhs.org>
References: <mailman.1.1412470802.24227.tuhs@minnie.tuhs.org>
Message-ID: <5431B1B7.1040303@update.uu.se>

On 2014-10-05 03:00, Dave Horsfall<dave at horsfall.org> wrote:
>
> On Sat, 4 Oct 2014, Noel Chiappa wrote:
>
>> >Anyone seriously working on bringing old hardware back to life needs to
>> >get in touch with the Classic Computer Talk list:
> Is John Dodson on this list?  He has an 11/70 in his house.

No idea. I occasionally scan cctalk, but most of the time don't bother. 
Too much noise and irrelevant or ignorant posts. However, unfortunately 
I don't have any better suggestions where to go if you are trying to 
restore old hardware and don't have enough knowledge.

And yes, I keep lots of different PDP-8, PDP-11 and VAXen running, 
including 11/70 systems.

	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 downing.nick at gmail.com  Mon Oct  6 07:46:12 2014
From: downing.nick at gmail.com (Nick Downing)
Date: Mon, 6 Oct 2014 08:46:12 +1100
Subject: [TUHS] 2.9bsd on 11/45 restoration
In-Reply-To: <5431B1B7.1040303@update.uu.se>
References: <mailman.1.1412470802.24227.tuhs@minnie.tuhs.org>
 <5431B1B7.1040303@update.uu.se>
Message-ID: <CAH1jEzYWGhX6duL8dJsxONR-GfNZG2jhMk7fDjs6c8jE1yonRA@mail.gmail.com>

I had an 11/70 service manual as an ebook at one stage, it had full
schematics etc, you also have access to various simulators to help you
understand the programming interface so i can't see what other info you
would need for your restoration, maybe you'd need help jerry rigging some
setup to get an initial tape written to get u started?

If you have any questions about the schematics or electrical
troubleshooting I'm happy to help although I have never owned a physical
pdp11... concepts are the same as any more modern system.

cheers, Nick
On 06/10/2014 8:08 AM, "Johnny Billquist" <bqt at update.uu.se> wrote:

> On 2014-10-05 03:00, Dave Horsfall<dave at horsfall.org> wrote:
>
>>
>> On Sat, 4 Oct 2014, Noel Chiappa wrote:
>>
>>  >Anyone seriously working on bringing old hardware back to life needs to
>>> >get in touch with the Classic Computer Talk list:
>>>
>> Is John Dodson on this list?  He has an 11/70 in his house.
>>
>
> No idea. I occasionally scan cctalk, but most of the time don't bother.
> Too much noise and irrelevant or ignorant posts. However, unfortunately I
> don't have any better suggestions where to go if you are trying to restore
> old hardware and don't have enough knowledge.
>
> And yes, I keep lots of different PDP-8, PDP-11 and VAXen running,
> including 11/70 systems.
>
>         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
> _______________________________________________
> 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/20141006/61a55a5d/attachment.html>

From bqt at update.uu.se  Mon Oct  6 08:49:10 2014
From: bqt at update.uu.se (Johnny Billquist)
Date: Mon, 06 Oct 2014 00:49:10 +0200
Subject: [TUHS] 2.9bsd on 11/45 restoration
In-Reply-To: <CAH1jEzYWGhX6duL8dJsxONR-GfNZG2jhMk7fDjs6c8jE1yonRA@mail.gmail.com>
References: <mailman.1.1412470802.24227.tuhs@minnie.tuhs.org>	<5431B1B7.1040303@update.uu.se>
 <CAH1jEzYWGhX6duL8dJsxONR-GfNZG2jhMk7fDjs6c8jE1yonRA@mail.gmail.com>
Message-ID: <5431CAE6.9000703@update.uu.se>

The 11/70 service manual is all good, but it's definitely not enough.
Ideally, you should have access to the full drawings, the service manual 
for the CPU, the service manual for the memory subsystem, I seem to 
remember that the FP11 has its own service manual, and I think the 
massbus interface also has its own documentation set.
Also, the memory system consists of both the Unibus map, the cache and 
memory bus system, and they you have separate documentation for the 
memory boxes (either MJ11 or MK11 box).

I don't know how much documentation have been scanned, and I haven't 
really checked. Since I still have access to all the documentation on 
paper I usually use that.

I don't even remember all the manuals and drawings that exist.

	Johnny

On 2014-10-05 23:46, Nick Downing wrote:
> I had an 11/70 service manual as an ebook at one stage, it had full
> schematics etc, you also have access to various simulators to help you
> understand the programming interface so i can't see what other info you
> would need for your restoration, maybe you'd need help jerry rigging
> some setup to get an initial tape written to get u started?
>
> If you have any questions about the schematics or electrical
> troubleshooting I'm happy to help although I have never owned a physical
> pdp11... concepts are the same as any more modern system.
>
> cheers, Nick
>
> On 06/10/2014 8:08 AM, "Johnny Billquist" <bqt at update.uu.se
> <mailto:bqt at update.uu.se>> wrote:
>
>     On 2014-10-05 03:00, Dave Horsfall<dave at horsfall.org
>     <mailto:dave at horsfall.org>> wrote:
>
>
>         On Sat, 4 Oct 2014, Noel Chiappa wrote:
>
>              >Anyone seriously working on bringing old hardware back to
>             life needs to
>              >get in touch with the Classic Computer Talk list:
>
>         Is John Dodson on this list?  He has an 11/70 in his house.
>
>
>     No idea. I occasionally scan cctalk, but most of the time don't
>     bother. Too much noise and irrelevant or ignorant posts. However,
>     unfortunately I don't have any better suggestions where to go if you
>     are trying to restore old hardware and don't have enough knowledge.
>
>     And yes, I keep lots of different PDP-8, PDP-11 and VAXen running,
>     including 11/70 systems.
>
>              Johnny
>
>     --
>     Johnny Billquist                  || "I'm on a bus
>                                        ||  on a psychedelic trip
>     email: bqt at softjar.se <mailto:bqt at softjar.se>             ||
>     Reading murder books
>     pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>     _________________________________________________
>     TUHS mailing list
>     TUHS at minnie.tuhs.org <mailto:TUHS at minnie.tuhs.org>
>     https://minnie.tuhs.org/__mailman/listinfo/tuhs
>     <https://minnie.tuhs.org/mailman/listinfo/tuhs>
>


-- 
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  Mon Oct  6 11:36:39 2014
From: norman at oclsc.org (Norman Wilson)
Date: Sun,  5 Oct 2014 21:36:39 -0400 (EDT)
Subject: [TUHS] 2.9bsd on 11/45 restoration
Message-ID: <20141006013639.560F11DE38B@lignose.oclsc.org>

  The 11/70 service manual is all good, but it's definitely not enough.
  Ideally, you should have access to the full drawings, the service manual 
  for the CPU, the service manual for the memory subsystem, I seem to 
  remember that the FP11 has its own service manual, and I think the 
  massbus interface also has its own documentation set.
  Also, the memory system consists of both the Unibus map, the cache and 
  memory bus system, and they you have separate documentation for the 
  memory boxes (either MJ11 or MK11 box).

It might be worth while to contact the Living Computer Museum.
I forget whether they have an 11/70 running or just an 11/45,
but I do know that they collect all the documentation they can
get for old computers--I saw the room where they store it.
Whenever they need to use it, or there's some other need to
access it, they try to make time to scan it, so the precious
copy can stay in the archive room.

Since their goal is to have ancient computers actually
running, they are certainly interested in having all the
documents (even if you can't get the wood, as Warren might
remark at this point), including full engineering drawings.

It's also a neat place to visit if you have some free time in
Seattle.  I'm disappointed to have figured out that, although
I'll be in Seattle for a conference in about a month, I won't
be able to visit LCM while they're open unless I skip some
conference sessions ... or unless I can convince them to open
up specially.  Anyone else on this list planning to attend
LISA and interested in visiting a museum of old running
computers?

Norman Wilson
Toronto ON


From peter at rulingia.com  Tue Oct  7 18:54:18 2014
From: peter at rulingia.com (Peter Jeremy)
Date: Tue, 7 Oct 2014 19:54:18 +1100
Subject: [TUHS] 2.9bsd on 11/45 restoration
In-Reply-To: <20141003033632.GD18537@www.oztivo.net>
References: <20141003033632.GD18537@www.oztivo.net>
Message-ID: <20141007085418.GB15122@server.rulingia.com>

On 2014-Oct-03 13:36:32 +1000, Warren Toomey <wkt at tuhs.org> wrote:
>----- Forwarded message from Jacob Ritorto -----
>   Â Â Also, has anyone written a miniature httpd for any of the ancient
>   bsds?

You probably won't get much smaller than hibachi
(http://ioccc.org/2004/hibachi.tar.gz).

Disclaimer: I haven't actually tried building it on an old Unix.

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

From bqt at update.uu.se  Wed Oct  8 04:15:44 2014
From: bqt at update.uu.se (Johnny Billquist)
Date: Tue, 07 Oct 2014 20:15:44 +0200
Subject: [TUHS] 2.9bsd on 11/45 restoration
In-Reply-To: <mailman.1.1412643601.13349.tuhs@minnie.tuhs.org>
References: <mailman.1.1412643601.13349.tuhs@minnie.tuhs.org>
Message-ID: <54342DD0.6060904@update.uu.se>

On 2014-10-07 03:00, norman at oclsc.org (Norman Wilson) wrote:

>
>    The 11/70 service manual is all good, but it's definitely not enough.
>    Ideally, you should have access to the full drawings, the service manual
>    for the CPU, the service manual for the memory subsystem, I seem to
>    remember that the FP11 has its own service manual, and I think the
>    massbus interface also has its own documentation set.
>    Also, the memory system consists of both the Unibus map, the cache and
>    memory bus system, and they you have separate documentation for the
>    memory boxes (either MJ11 or MK11 box).
>
> It might be worth while to contact the Living Computer Museum.
> I forget whether they have an 11/70 running or just an 11/45,
> but I do know that they collect all the documentation they can
> get for old computers--I saw the room where they store it.
> Whenever they need to use it, or there's some other need to
> access it, they try to make time to scan it, so the precious
> copy can stay in the archive room.

LCM have atleast one 11/70 running. Although they are not really doing 
anything fun on it. I hope to maybe help them with that next time I'm 
there. I can't remember seeing any 11/45 running, but I'm pretty sure 
there are some in their storage if nothing else...

I'm not going to try dragging a lot of documentation from Sweden to 
Seattle, though (I'm not even in Sweden myself lots of the time). On the 
other hand, I know they have plenty of documentation, so I would hope 
they (and/or CHM) already have most of it.

> Since their goal is to have ancient computers actually
> running, they are certainly interested in having all the
> documents (even if you can't get the wood, as Warren might
> remark at this point), including full engineering drawings.
>
> It's also a neat place to visit if you have some free time in
> Seattle.  I'm disappointed to have figured out that, although
> I'll be in Seattle for a conference in about a month, I won't
> be able to visit LCM while they're open unless I skip some
> conference sessions ... or unless I can convince them to open
> up specially.  Anyone else on this list planning to attend
> LISA and interested in visiting a museum of old running
> computers?

I know of the place, and have known Rich Alderson for a long time.
It is a fun place, and I could see myself working there, if I just had 
the right offer. Don't expect that to happen, though...

I'll be there for different reasons in about a month from now. But my 
weekends are free... :-)

	Johnny



From M.Engel at leedsbeckett.ac.uk  Sat Oct 11 03:26:58 2014
From: M.Engel at leedsbeckett.ac.uk (Engel, Michael)
Date: Fri, 10 Oct 2014 17:26:58 +0000
Subject: [TUHS] Codata restoration - day 1
Message-ID: <B2E15B59-0249-468F-A4CF-CB1D099F0006@leedsbeckett.ac.uk>


Hi,

after carefully examining the power supply and checking the generated
voltages, we were convinced that this wouldn't kill our Multibus boards.
Maybe some of you are interested in our progress, so I though I would
send you an update.

After reconnecting the Multibus backplane, we started the system with
only a CPU board and a memory board. On one of our CPU boards
the smaller (P2) Multibus connector is masked with tape, I'll have to dig 
deeper to find out what is deactivated by this…

One of our two CPU boards is currently non functional (the one without
the masking take, this doesn't say a thing on the console UART, will bring 
in the scope in Monday to check for details). The other one brings up the
monitor startup message and prompt on a connected serial terminal 
(emulator) - however, we are unable to get any characters echoed back.
The serial cable is working, we tried all sorts of handshake configurations.
If we get any characters back (the system is running at 9600 baud, I tried
all combinations of 7/8 bit, none/even/odd/mark/space parity and 1/2 stop
bits), these are garbled and contain mostly "1" bits (0xfc, 0xfe, 0xff or 
similar).

The UART itself seems to work (exchanged it with the one from the non
working board - same result), so now I suspect the AM26LS32 RS423
driver to be the culprit.

I uploaded some pictures to 
http://s1372.photobucket.com/user/michaelengel/library/Codata?sort=3&page=1
- there you can see that this machine is far from being in any sort of 
original condition. Nevertheless, it's great to see it come alive again!

Btw., current versions of MAME/MESS include a rudimentary Codata
simulator. This doesn't do very much so far, but it can successfully run 
the firmware ROM code (picture also uploaded to photobucket).

Best wishes,
    Michael



From dave at horsfall.org  Sat Oct 11 04:00:07 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 11 Oct 2014 05:00:07 +1100 (EST)
Subject: [TUHS] Codata restoration - day 1
In-Reply-To: <B2E15B59-0249-468F-A4CF-CB1D099F0006@leedsbeckett.ac.uk>
References: <B2E15B59-0249-468F-A4CF-CB1D099F0006@leedsbeckett.ac.uk>
Message-ID: <alpine.BSF.2.00.1410110450370.31844@aneurin.horsfall.org>

On Fri, 10 Oct 2014, Engel, Michael wrote:

> After carefully examining the power supply and checking the generated 
> voltages, we were convinced that this wouldn't kill our Multibus boards. 
> Maybe some of you are interested in our progress, so I though I would 
> send you an update.

Yes please!  I long for the days when it was possible to understand the 
entire kernel source...

> After reconnecting the Multibus backplane, we started the system with 
> only a CPU board and a memory board. On one of our CPU boards the 
> smaller (P2) Multibus connector is masked with tape, I'll have to dig 
> deeper to find out what is deactivated by this…

The P2 bus is designated as "private" i.e. do whatever you want with it 
with your proprietary hardware.  I don't think the "standard" CPU board 
even looks at it.

> One of our two CPU boards is currently non functional (the one without 
> the masking take, this doesn't say a thing on the console UART, will 
> bring in the scope in Monday to check for details). The other one brings 
> up the monitor startup message and prompt on a connected serial terminal 
> (emulator) - however, we are unable to get any characters echoed back. 
> The serial cable is working, we tried all sorts of handshake 
> configurations. If we get any characters back (the system is running at 
> 9600 baud, I tried all combinations of 7/8 bit, none/even/odd/mark/space 
> parity and 1/2 stop bits), these are garbled and contain mostly "1" bits 
> (0xfc, 0xfe, 0xff or similar).

Have you tried speeds other than 9600?  They look to me like framing 
errors.

-- Dave

From M.Engel at leedsbeckett.ac.uk  Sat Oct 11 05:21:52 2014
From: M.Engel at leedsbeckett.ac.uk (Engel, Michael)
Date: Fri, 10 Oct 2014 19:21:52 +0000
Subject: [TUHS] Codata restoration - day 1
In-Reply-To: <alpine.BSF.2.00.1410110450370.31844@aneurin.horsfall.org>
References: <B2E15B59-0249-468F-A4CF-CB1D099F0006@leedsbeckett.ac.uk>
 <alpine.BSF.2.00.1410110450370.31844@aneurin.horsfall.org>
Message-ID: <6EFBDEDF-67F2-4519-97BB-34087757EA09@leedsmet.ac.uk>


On 10 Oct 2014, at 19:00, Dave Horsfall <dave at horsfall.org> wrote:

> On Fri, 10 Oct 2014, Engel, Michael wrote:
> 
>> After carefully examining the power supply and checking the generated 
>> voltages, we were convinced that this wouldn't kill our Multibus boards. 
>> Maybe some of you are interested in our progress, so I though I would 
>> send you an update.
> 
> Yes please!  I long for the days when it was possible to understand the 
> entire kernel source...

Thanks, Dave! Unfortunately, I haven't heard back from Unisoft so far, 
but I have tried something else last night. A few months ago, ragge
(of NetBSD/VAX and pcc fame) added a 68k backend to (modern) 
pcc. With this, I was able to (cross-)compile more than half of the files of 
the PDP11 v7 kernel without changes (but the compiler still seems to have
some problems, I'll try to generate a useful error report over the weekend).

So, a new 7th Edition Unix port to Sun 100U-derived boards seems to
be possible, perhaps also incorporating pieces from System III or early
BSDs. Another alternative would be a port of RetroBSD, the 2.11 BSD
port which currently runs on the PIC32 MIPS microcontroller cores in
just 128kB RAM. One of these systems will also be the basis for my
upcoming operating systems course :-).

Nevertheless, I will first try to get the existing installation to work, maybe
there are some interesting sources on the disks (and we have also found
a number of 1600bpi 9-track backup tapes and 5.25" backup floppies...).

>> After reconnecting the Multibus backplane, we started the system with 
>> only a CPU board and a memory board. On one of our CPU boards the 
>> smaller (P2) Multibus connector is masked with tape, I'll have to dig 
>> deeper to find out what is deactivated by this…
> 
> The P2 bus is designated as "private" i.e. do whatever you want with it 
> with your proprietary hardware.  I don't think the "standard" CPU board 
> even looks at it.

That's what I also thought. Do you know if there were systems which used
P2 to connect to memory boards?

[...]
>> The serial cable is working, we tried all sorts of handshake 
>> configurations. If we get any characters back (the system is running at 
>> 9600 baud, I tried all combinations of 7/8 bit, none/even/odd/mark/space 
>> parity and 1/2 stop bits), these are garbled and contain mostly "1" bits 
>> (0xfc, 0xfe, 0xff or similar).
> 
> Have you tried speeds other than 9600?  They look to me like framing 
> errors.

The terminal emulator (screen and minicom behave identically) receives 
the output from the console perfectly - otherwise, I would have also 
suspected an incorrect baudrate. And different baudrates for RX and TX
would be highly unusual (I have only seen these in German BTX dialup
systems in the 1980s, which used 1200/75 baud modems).

Luckily, the driver chip for the UART RX line is an AM26LS32. While
this chip is no longer available, I can get an AM26LS32A here at Farnell
(which is just around the corner from my house :-)). Does anyone know
the difference between the 26LS32 and the 26LS32A? I only found a
page at TI that didn't list specific differences...

-- Michael




From dave at horsfall.org  Sat Oct 11 05:55:10 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 11 Oct 2014 06:55:10 +1100 (EST)
Subject: [TUHS] Codata restoration - day 1
In-Reply-To: <6EFBDEDF-67F2-4519-97BB-34087757EA09@leedsmet.ac.uk>
References: <B2E15B59-0249-468F-A4CF-CB1D099F0006@leedsbeckett.ac.uk>
 <alpine.BSF.2.00.1410110450370.31844@aneurin.horsfall.org>
 <6EFBDEDF-67F2-4519-97BB-34087757EA09@leedsmet.ac.uk>
Message-ID: <alpine.BSF.2.00.1410110630110.31844@aneurin.horsfall.org>

On Fri, 10 Oct 2014, Engel, Michael wrote:

> > The P2 bus is designated as "private" i.e. do whatever you want with 
> > it with your proprietary hardware.  I don't think the "standard" CPU 
> > board even looks at it.
> 
> That's what I also thought. Do you know if there were systems which used 
> P2 to connect to memory boards?

I think (and this is going back to the early 80s) that some WICAT models 
did.  I've used the 150, 160, and 200, but never saw a 220.  The smaller 
models were Multibus, and the 200 on had something loosely based on it and 
was unofficially referred to as the Pussy-bus.  The P2 bus on those small 
ones was used for something that I've long since forgotten; there was a 
project in the Lionel Singer Group (Aussie agent for WICAT) to use 
standard Multibus cards in them until we discovered upon reading the 
circuits (we had circuit diagrams in those days!) that WICAT had hijacked 
the P2 bus, possibly for extended memory, possibly for its weird ICI board 
(8-port serial board + disk, as I vaguely recall), possibly something 
else.

I was glad to see the end of the WICATs, because their attempt at System 
III was woeful; I had to do pre-sales demos, *knowing* that the damned 
thing would crash on me, and got very good at excuses.  "Sorry guys, we've 
been having a bit of trouble with this new controller, but we're told 
it'll be fixed Real Soon Now(tm)" when I knew that it was the poxy OS at 
fault.  How do you explain to the customer that the OS itself is 
fundamentally rat-shit?

I am desperately trying to forget the exact details, but it involved 
someone telling Lionel Singer himself that his half-arsed idea was just 
that...

> [...]
> >> The serial cable is working, we tried all sorts of handshake 
> >> configurations. If we get any characters back (the system is running 
> >> at 9600 baud, I tried all combinations of 7/8 bit, 
> >> none/even/odd/mark/space parity and 1/2 stop bits), these are garbled 
> >> and contain mostly "1" bits (0xfc, 0xfe, 0xff or similar).
> > 
> > Have you tried speeds other than 9600?  They look to me like framing 
> > errors.
> 
> The terminal emulator (screen and minicom behave identically) receives 
> the output from the console perfectly - otherwise, I would have also 
> suspected an incorrect baudrate. And different baudrates for RX and TX 
> would be highly unusual (I have only seen these in German BTX dialup 
> systems in the 1980s, which used 1200/75 baud modems).

1200/75?  That was popular in Australia, on a scheme called Viatel, which 
thankfully died off when ISPs began to rise up (until then it was either 
FidoNet or the Phone Company's Viatel) and implement 1200/1200.

> Luckily, the driver chip for the UART RX line is an AM26LS32. While this 
> chip is no longer available, I can get an AM26LS32A here at Farnell 
> (which is just around the corner from my house :-)). Does anyone know 
> the difference between the 26LS32 and the 26LS32A? I only found a page 
> at TI that didn't list specific differences...

Offhand no, but Farknell (as they're known in Australia - say it out loud) 
ought to know, as they're pretty clued up.

-- Dave


From rosenfeld at grumpf.hope-2000.org  Sat Oct 11 06:13:03 2014
From: rosenfeld at grumpf.hope-2000.org (Hans Rosenfeld)
Date: Fri, 10 Oct 2014 22:13:03 +0200
Subject: [TUHS] Codata restoration - day 1
In-Reply-To: <B2E15B59-0249-468F-A4CF-CB1D099F0006@leedsbeckett.ac.uk>
References: <B2E15B59-0249-468F-A4CF-CB1D099F0006@leedsbeckett.ac.uk>
Message-ID: <20141010201303.GF25824@grumpf.hope-2000.org>

Hi Michael,

On Fri, Oct 10, 2014 at 05:26:58PM +0000, Engel, Michael wrote:
> The serial cable is working, we tried all sorts of handshake configurations.
> If we get any characters back (the system is running at 9600 baud, I tried
> all combinations of 7/8 bit, none/even/odd/mark/space parity and 1/2 stop
> bits), these are garbled and contain mostly "1" bits (0xfc, 0xfe, 0xff or 
> similar).
> 
> The UART itself seems to work (exchanged it with the one from the non
> working board - same result), so now I suspect the AM26LS32 RS423
> driver to be the culprit.

I've had that a few times with PDP11s and VAXen from the 80s. The line
receivers suddenly died, showing exactly the symptoms you describe.
Those were different chips (ua96XX), but the concept is the same.
Replacing them with newer chips from the same family worked without
problems.


Hans


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown


From imp at bsdimp.com  Sat Oct 11 06:37:04 2014
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 10 Oct 2014 14:37:04 -0600
Subject: [TUHS] Codata restoration - day 1
In-Reply-To: <20141010201303.GF25824@grumpf.hope-2000.org>
References: <B2E15B59-0249-468F-A4CF-CB1D099F0006@leedsbeckett.ac.uk>
 <20141010201303.GF25824@grumpf.hope-2000.org>
Message-ID: <2FE72B5A-E2ED-4EEC-A872-17D075BA83DC@bsdimp.com>

These days, you can buy 5.0V or 3.3V to USB adapters in the hobbyist or robotics section of many computer stores. I’ve used them to trouble shoot blown driver chips to verify they really were toast. Be careful of the voltage levels, though, since many 3.3V products can’t tolerate 5.0V…

Warner


On Oct 10, 2014, at 2:13 PM, Hans Rosenfeld <rosenfeld at grumpf.hope-2000.org> wrote:

> Hi Michael,
> 
> On Fri, Oct 10, 2014 at 05:26:58PM +0000, Engel, Michael wrote:
>> The serial cable is working, we tried all sorts of handshake configurations.
>> If we get any characters back (the system is running at 9600 baud, I tried
>> all combinations of 7/8 bit, none/even/odd/mark/space parity and 1/2 stop
>> bits), these are garbled and contain mostly "1" bits (0xfc, 0xfe, 0xff or 
>> similar).
>> 
>> The UART itself seems to work (exchanged it with the one from the non
>> working board - same result), so now I suspect the AM26LS32 RS423
>> driver to be the culprit.
> 
> I've had that a few times with PDP11s and VAXen from the 80s. The line
> receivers suddenly died, showing exactly the symptoms you describe.
> Those were different chips (ua96XX), but the concept is the same.
> Replacing them with newer chips from the same family worked without
> problems.
> 
> 
> Hans
> 
> 
> -- 
> %SYSTEM-F-ANARCHISM, The operating system has been overthrown
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141010/d3ecb218/attachment.sig>

From clemc at ccc.com  Sun Oct 12 07:48:13 2014
From: clemc at ccc.com (Clem Cole)
Date: Sat, 11 Oct 2014 17:48:13 -0400
Subject: [TUHS] Codata restoration - day 1
In-Reply-To: <6EFBDEDF-67F2-4519-97BB-34087757EA09@leedsmet.ac.uk>
References: <B2E15B59-0249-468F-A4CF-CB1D099F0006@leedsbeckett.ac.uk>
 <alpine.BSF.2.00.1410110450370.31844@aneurin.horsfall.org>
 <6EFBDEDF-67F2-4519-97BB-34087757EA09@leedsmet.ac.uk>
Message-ID: <CAC20D2MuFwPO-NLKo_UTM9_PHJeNzS7jx_n5JNMdehJ3t6PWJw@mail.gmail.com>

below

On Fri, Oct 10, 2014 at 3:21 PM, Engel, Michael <M.Engel at leedsbeckett.ac.uk>
wrote:

>
>
> That's what I also thought. Do you know if there were systems which used
> P2 to connect to memory boards?
>
​Pretty much everyone that was successfull - Masscomp, Apollo, etc...   And
they are all different.​




>
>
> Luckily, the driver chip for the UART RX line is an AM26LS32. While
> this chip is no longer available, I can get an AM26LS32A here at Farnell
> (which is just around the corner from my house :-)). Does anyone know
> the difference between the 26LS32 and the 26LS32A? I only found a
> page at TI that didn't list specific differences...


​Hmm...
I looked in my old AMD books, and I unfortunately do not have an AM26xxx
anything in there.
the difference between the MC1489/SN75189 and MC1489A/
SN75189
 is input hysteresis on the receiver side.  I wonder if AMD did the same
when they created the 26L32​

​ to compete with Moto and TI (in those days the 1488/1489 system was king
until MAX shows up on the scene with a single 5v device).

So, I'll give you the text from Page 5-42 of the Moto Interface book on the
1489/1489A:

*The MC1489 input has typical turn-on voltage of 1.25 volts and turn off of
1.0 volt for an input hysteresis of 250mv. ​ The MC1489A has a typical turn
on a 1.95 volts and turn off of .8 volts for typically 1.15 volts of
hysteresis.*


I suspect the A version will work fine, usually the differences was things
like this where they made the part better in real world applications (250mv
of hysteresis for a device that was supposed to be able to handle swing
between +30/-30 volts is tiny).

Best of luck.

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

From luca.nini at yahoo.it  Sun Oct 12 18:59:52 2014
From: luca.nini at yahoo.it (luca.nini)
Date: Sun, 12 Oct 2014 10:59:52 +0200
Subject: [TUHS] ISPS
Message-ID: <lxjjt015oijbfusds9u0op34.1413104392543@email.android.com>

Back in the 80s in my University days  I was  using ISPS (Instruction  Set  Processor  Simulator if  I remember  correctly ) a software tool To simulate CPU.  It ran on a Vax  with  BSD 4.2. I have been  unable  to find any reference to It on the Internet . Do someone on this list  know anything offerte this software ? 

Thanks 
Luca 

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

From clemc at ccc.com  Mon Oct 13 04:26:54 2014
From: clemc at ccc.com (Clem Cole)
Date: Sun, 12 Oct 2014 14:26:54 -0400
Subject: [TUHS] ISPS
In-Reply-To: <lxjjt015oijbfusds9u0op34.1413104392543@email.android.com>
References: <lxjjt015oijbfusds9u0op34.1413104392543@email.android.com>
Message-ID: <4627ED3F-8667-460F-8C61-5FA08A9565BE@ccc.com>

sure   I helped to write the original version in Vax serial #1 in bliss with Dan Klien. it's predesessor was ISPL and written for the PDP 10 the Unix rewrite in C (and lisp) was The late Ted Kowalski's PhD 

the system lives today as VHDL 

I'll see if I can dig up a copy in my archives and give it to Warren or bit savers 


> On Oct 12, 2014, at 4:59 AM, luca.nini <luca.nini at yahoo.it> wrote:
> 
> Back in the 80s in my University days  I was  using ISPS (Instruction  Set  Processor  Simulator if  I remember  correctly ) a software tool To simulate CPU.  It ran on a Vax  with  BSD 4.2. I have been  unable  to find any reference to It on the Internet . Do someone on this list  know anything offerte this software ? 
> 
> Thanks 
> Luca 
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From fair at netbsd.org  Mon Oct 13 04:18:12 2014
From: fair at netbsd.org (Erik Fair)
Date: Sun, 12 Oct 2014 11:18:12 -0700
Subject: [TUHS] Codata restoration - day 1
In-Reply-To: <alpine.BSF.2.00.1410110630110.31844@aneurin.horsfall.org>
References: <B2E15B59-0249-468F-A4CF-CB1D099F0006@leedsbeckett.ac.uk>
 <alpine.BSF.2.00.1410110450370.31844@aneurin.horsfall.org>
 <6EFBDEDF-67F2-4519-97BB-34087757EA09@leedsmet.ac.uk>
 <alpine.BSF.2.00.1410110630110.31844@aneurin.horsfall.org>
Message-ID: <6CD9CF81-CE94-45DA-873E-AC1D79B1B7A1@netbsd.org>


On Oct 10, 2014, at 12:55, Dave Horsfall <dave at horsfall.org> wrote:

> I was glad to see the end of the WICATs, because their attempt at System 
> III was woeful; I had to do pre-sales demos, *knowing* that the damned 
> thing would crash on me, and got very good at excuses.  "Sorry guys, we've 
> been having a bit of trouble with this new controller, but we're told 
> it'll be fixed Real Soon Now(tm)" when I knew that it was the poxy OS at 
> fault.  How do you explain to the customer that the OS itself is 
> fundamentally rat-shit?

At Dual Systems, we never shipped AT&T USG System III to our customers, other than a few alphas/betas - it was such a disaster, we spent a year fixing show-stopper bugs in it. By the time we got System III into what we considered "shippable/supportable" shape, System V was out, so we started work on that. Our customers had to jump from v7 to System V, but they were spared System III.

System V was pretty awful too, but it was "industry standard" and we had to put up with that idiocy from AT&T USG. I daily retreated back to the much more pleasant use of BSD UNIX systems at UCB that I still had access to.

	Erik <fair at netbsd.org>



From cubexyz at gmail.com  Mon Oct 13 10:57:14 2014
From: cubexyz at gmail.com (Mark Longridge)
Date: Sun, 12 Oct 2014 20:57:14 -0400
Subject: [TUHS] Getting Unix v5 to talk
Message-ID: <CADxT5N7UC98qKNf8jsV+mPsg=obN9tJ09vRR92rvzKs2MBRWVg@mail.gmail.com>

Thanks to the efforts of Jonathan Gevaryahu I have managed
to get the Unix v5 speak utility to compile and execute.
All this was done using the simh emulator emulating a
PDP-11/70.

Jonathan managed extract enough of speak.c to reconstruct it
to the point it could be compiled with v5 cc. I believe it
was necessary to look at speak.o to accomplish this.

Jonathan also states that there are more interesting things
that could possibly be recovered from v6doc.tar.gz

One can look at speak.c source here:

http://www.maxhost.org/other/speak.c

Now had we have speak compiled we can go a bit further:

cat speak.v - | speak -v null
  generates speak.m from ascii file speak.v

speak speak.m
 computer
 !p         (prints out phonetics for working word)
 which outputs:
 ,k,a0,m,p,E2,U1,t,er,-1
 ctrl-d exits

Looking at speak.c we can see that it opens /dev/vs.
Fortunately we have the file /usr/sys/dmr/vs.c to look at
so this could be compiled into the kernel although I haven't
done this as yet.

speak.c looks like Unix v5 era code. My understanding is that
Unix v5 appeared in June 1974 and the comments say 'Copyright 1974'
so it seems plausible.

I'm intrigued by the possibility of getting Unix v5 to talk.

Mark


From jnc at mercury.lcs.mit.edu  Mon Oct 13 12:14:19 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 12 Oct 2014 22:14:19 -0400 (EDT)
Subject: [TUHS] Getting Unix v5 to talk
Message-ID: <20141013021419.B1A3918C0AB@mercury.lcs.mit.edu>

    > From: Mark Longridge

    > Fortunately we have the file /usr/sys/dmr/vs.c to look at so this could
    > be compiled into the kernel although I haven't done this as yet.

The vs.c seems to be a Votrax speech synthesizer hooked up to a DC11
interface. Do any of the simulators support the DC11? If not, adding the
driver won't do you much good.

	Noel

PS: I seem to recall the DSSR group on the 4th floor at LCS actually had one
of these, back in the day. The sound quality was pretty marginal, as I recall!


From clemc at ccc.com  Tue Oct 14 02:29:52 2014
From: clemc at ccc.com (Clem Cole)
Date: Mon, 13 Oct 2014 12:29:52 -0400
Subject: [TUHS] ISPS
In-Reply-To: <4627ED3F-8667-460F-8C61-5FA08A9565BE@ccc.com>
References: <lxjjt015oijbfusds9u0op34.1413104392543@email.android.com>
 <4627ED3F-8667-460F-8C61-5FA08A9565BE@ccc.com>
Message-ID: <CAC20D2Px9fz==KO3TWTe07iYNDCokYn-stwaz0O23C3w5tmYVA@mail.gmail.com>

Checkout:

http://repository.cmu.edu/cgi/viewcontent.cgi?article=3407&context=compsci

On Sun, Oct 12, 2014 at 2:26 PM, Clem Cole <clemc at ccc.com> wrote:

> sure   I helped to write the original version in Vax serial #1 in bliss
> with Dan Klien. it's predesessor was ISPL and written for the PDP 10 the
> Unix rewrite in C (and lisp) was The late Ted Kowalski's PhD
>
> the system lives today as VHDL
>
> I'll see if I can dig up a copy in my archives and give it to Warren or
> bit savers
>
>
> > On Oct 12, 2014, at 4:59 AM, luca.nini <luca.nini at yahoo.it> wrote:
> >
> > Back in the 80s in my University days  I was  using ISPS (Instruction
> Set  Processor  Simulator if  I remember  correctly ) a software tool To
> simulate CPU.  It ran on a Vax  with  BSD 4.2. I have been  unable  to find
> any reference to It on the Internet . Do someone on this list  know
> anything offerte this software ?
> >
> > Thanks
> > Luca
> >
> > _______________________________________________
> > 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/20141013/844db394/attachment.html>

From luca.nini at yahoo.it  Wed Oct 15 06:09:12 2014
From: luca.nini at yahoo.it (Luca Nini)
Date: Tue, 14 Oct 2014 21:09:12 +0100
Subject: [TUHS] ISPS
In-Reply-To: <CAC20D2Px9fz==KO3TWTe07iYNDCokYn-stwaz0O23C3w5tmYVA@mail.gmail.com>
References: <lxjjt015oijbfusds9u0op34.1413104392543@email.android.com>
 <4627ED3F-8667-460F-8C61-5FA08A9565BE@ccc.com>
 <CAC20D2Px9fz==KO3TWTe07iYNDCokYn-stwaz0O23C3w5tmYVA@mail.gmail.com>
Message-ID: <1413317352.94154.YahooMailNeo@web172702.mail.ir2.yahoo.com>

Thank yiou Clem.  I remember this paper... 


Luca



________________________________
 Da: Clem Cole <clemc at ccc.com>
A: luca.nini <luca.nini at yahoo.it> 
Cc: "tuhs at tuhs.org" <tuhs at tuhs.org> 
Inviato: Lunedì 13 Ottobre 2014 18:29
Oggetto: Re: [TUHS] ISPS
 


Checkout:

http://repository.cmu.edu/cgi/viewcontent.cgi?article=3407&context=compsci





On Sun, Oct 12, 2014 at 2:26 PM, Clem Cole <clemc at ccc.com> wrote:

sure   I helped to write the original version in Vax serial #1 in bliss with Dan Klien. it's predesessor was ISPL and written for the PDP 10 the Unix rewrite in C (and lisp) was The late Ted Kowalski's PhD
>
>the system lives today as VHDL
>
>I'll see if I can dig up a copy in my archives and give it to Warren or bit savers
>
>
>
>> On Oct 12, 2014, at 4:59 AM, luca.nini <luca.nini at yahoo.it> wrote:
>>
>> Back in the 80s in my University days  I was  using ISPS (Instruction  Set  Processor  Simulator if  I remember  correctly ) a software tool To simulate CPU.  It ran on a Vax  with  BSD 4.2. I have been  unable  to find any reference to It on the Internet . Do someone on this list  know anything offerte this software ?
>>
>> Thanks
>> Luca
>>
>> _______________________________________________
>> 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/20141014/d29f5e5b/attachment.html>

From dave at horsfall.org  Wed Oct 15 06:18:30 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 15 Oct 2014 07:18:30 +1100 (EST)
Subject: [TUHS] ISPS
In-Reply-To: <1413317352.94154.YahooMailNeo@web172702.mail.ir2.yahoo.com>
References: <lxjjt015oijbfusds9u0op34.1413104392543@email.android.com>
 <4627ED3F-8667-460F-8C61-5FA08A9565BE@ccc.com>
 <CAC20D2Px9fz==KO3TWTe07iYNDCokYn-stwaz0O23C3w5tmYVA@mail.gmail.com>
 <1413317352.94154.YahooMailNeo@web172702.mail.ir2.yahoo.com>
Message-ID: <alpine.BSF.2.00.1410150715300.1909@aneurin.horsfall.org>

On Tue, 14 Oct 2014, Luca Nini wrote:

> > http://repository.cmu.edu/cgi/viewcontent.cgi?article=3407&context=compsci
> 
> Thank yiou Clem.  I remember this paper...

Seconded.  I had graduated by then, but I certainly remember being taught 
something like it in Computer Science.

-- 
Dave Horsfall (VK2KFU)
http://www.horsfall.org/spam.html

From cubexyz at gmail.com  Fri Oct 17 11:51:56 2014
From: cubexyz at gmail.com (Mark Longridge)
Date: Thu, 16 Oct 2014 21:51:56 -0400
Subject: [TUHS] early cc variable and function names
Message-ID: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>

Hi folks,

I've been looking at Unix v5 cc limitations.

It seems like early cc could only use variable and function names up
to 8 characters.

This limitation occurs in v5, v6 and v7.

But when using the nm utility to print out the name list I see
function test1234() listed as:
000044T _test123

That seems to suggest that only the first 7 characters are
significant, but when looking at other sources they stated that one
can use up to 8 characters.

I hacked up a short program to test this:

main()
{
        test1234();
        test1235();
}

test1234()
{
        printf ("\nWorking");
}

test1235()
{
        printf ("\nAlso working");
}


This generated:
Multiply defined: test5.o;_test123

So it would seem that function names can only be 7 characters in
length. I am not sure if limitations of early cc were documented
anywhere. When I backported unirubik to v5 it compiled the longer
functions without any problem.

Did anyone document these sorts of limitations of early cc? Does
anyone remember when cc started to use function names longer than 7
characters?

Mark


From milov at cs.uwlax.edu  Fri Oct 17 12:20:23 2014
From: milov at cs.uwlax.edu (Milo Velimirovic)
Date: Thu, 16 Oct 2014 21:20:23 -0500
Subject: [TUHS] early cc variable and function names
In-Reply-To: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>
References: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>
Message-ID: <07F8EFBD-054E-4296-BDE9-879F6C36A649@cs.uwlax.edu>

External names were limited to 7 (user-defined) characters because the compiler prepended the _ to them. Function names were always external in that era of C. Internal variables could be up to 8 characters. As for longer names, they were allowed but only the first 8 ( including the compiler supplied _ for external names) were signiicant.

I'll look for my documentation from v6.

 - Milo

On Oct 16, 2014, at 8:51 PM, Mark Longridge wrote:

> Hi folks,
> 
> I've been looking at Unix v5 cc limitations.
> 
> It seems like early cc could only use variable and function names up
> to 8 characters.
> 
> This limitation occurs in v5, v6 and v7.
> 
> But when using the nm utility to print out the name list I see
> function test1234() listed as:
> 000044T _test123
> 
> That seems to suggest that only the first 7 characters are
> significant, but when looking at other sources they stated that one
> can use up to 8 characters.
> 
> I hacked up a short program to test this:
> 
> main()
> {
>        test1234();
>        test1235();
> }
> 
> test1234()
> {
>        printf ("\nWorking");
> }
> 
> test1235()
> {
>        printf ("\nAlso working");
> }
> 
> 
> This generated:
> Multiply defined: test5.o;_test123
> 
> So it would seem that function names can only be 7 characters in
> length. I am not sure if limitations of early cc were documented
> anywhere. When I backported unirubik to v5 it compiled the longer
> functions without any problem.
> 
> Did anyone document these sorts of limitations of early cc? Does
> anyone remember when cc started to use function names longer than 7
> characters?
> 
> Mark
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs



From jnc at mercury.lcs.mit.edu  Fri Oct 17 12:29:13 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 16 Oct 2014 22:29:13 -0400 (EDT)
Subject: [TUHS] early cc variable and function names
Message-ID: <20141017022913.7A77818C092@mercury.lcs.mit.edu>

    > From: Mark Longridge <cubexyz at gmail.com>

    > It seems like early cc could only use variable and function names up to
    > 8 characters.
    > This limitation occurs in v5, v6 and v7.
    > ...    
    > That seems to suggest that only the first 7 characters are significant,
    > but when looking at other sources they stated that one can use up to 8
    > characters.

The a.out symbol tables use 8-character fields to hold symbol names. However,
C automagically and unavoidably prepends an _ to all externals (I forget
about automatics, registers, etc - too tired to check right now), making the
limit for C names 7 characters.

    > I am not sure if limitations of early cc were documented anywhere.

I remember reading the above.

Other limits... well, you need to remember that C was still changing in that
period, so limits were a moving target.

    > When I backported unirubik to v5 it compiled the longer functions
    > without any problem.

ISTR that C truncated external names longer than 7 characters. Probably the
ones in that program were all unique within 7, so you won.

    > Did anyone document these sorts of limitations of early cc?

I seem to recall at least one document from that period (I think pertaining
to the so-called 'Typesetter C') about 'changes to C'.

Also, I have started a note with a list of 'issues with C when you're
backporting V7 and later code to V6', I'll see if I can dig them out tomorrow.

	Noel


From cowan at mercury.ccil.org  Fri Oct 17 12:40:49 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Thu, 16 Oct 2014 22:40:49 -0400
Subject: [TUHS] early cc variable and function names
In-Reply-To: <20141017022913.7A77818C092@mercury.lcs.mit.edu>
References: <20141017022913.7A77818C092@mercury.lcs.mit.edu>
Message-ID: <20141017024049.GI17227@mercury.ccil.org>

Noel Chiappa scripsit:

> The a.out symbol tables use 8-character fields to hold symbol names. However,
> C automagically and unavoidably prepends an _ to all externals (I forget
> about automatics, registers, etc - too tired to check right now), making the
> limit for C names 7 characters.

The _ was only for externals, including all procedure names.  It prevented
collisions with names introduced into the assembly-language source or
in libc.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
A male Jang appeared at my side.  "Get a grip on yourself," he said.
"Get a grip on your graks," I suggested.  --Tanith Lee, Drinking Sapphire Wine


From dave at horsfall.org  Fri Oct 17 12:21:59 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 17 Oct 2014 13:21:59 +1100 (EST)
Subject: [TUHS] early cc variable and function names
In-Reply-To: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>
References: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1410171317090.1909@aneurin.horsfall.org>

On Thu, 16 Oct 2014, Mark Longridge wrote:

> It seems like early cc could only use variable and function names up to 
> 8 characters.

In those days it took only the first seven and ignored the rest, 
prepending an underscore as you discovered.  I don't remember when longer 
names were recognised; for all I know it could've been around when 
pathnames could be longer than 14 chars (which I think may have been a 
BSDism).

-- 
Dave Horsfall (VK2KFU)
http://www.horsfall.org/spam.html


From lm at mcvoy.com  Fri Oct 17 12:52:42 2014
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 16 Oct 2014 19:52:42 -0700
Subject: [TUHS] early cc variable and function names
In-Reply-To: <20141017024049.GI17227@mercury.ccil.org>
References: <20141017022913.7A77818C092@mercury.lcs.mit.edu>
 <20141017024049.GI17227@mercury.ccil.org>
Message-ID: <20141017025242.GH6963@mcvoy.com>

On Thu, Oct 16, 2014 at 10:40:49PM -0400, John Cowan wrote:
> Noel Chiappa scripsit:
> 
> > The a.out symbol tables use 8-character fields to hold symbol names. However,
> > C automagically and unavoidably prepends an _ to all externals (I forget
> > about automatics, registers, etc - too tired to check right now), making the
> > limit for C names 7 characters.
> 
> The _ was only for externals, including all procedure names.  It prevented
> collisions with names introduced into the assembly-language source or
> in libc.

This is perhaps a side note but I believe all structure fields shared a 
namespace.  So stat.size and whatever.size were not allowed, they collided.
So we got sb.st_size which I personally love and wish it were still like
that.

xyz.size
abc.size
foobar.size

What are the types of those structures?

abc.st_size

Huh, abc is a struct stat.

I get that it was a bug and needed to be fixed but I wish that everyone 
still pretended that it was one namespace, makes code so much easier to
read.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From cowan at mercury.ccil.org  Fri Oct 17 13:46:18 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Thu, 16 Oct 2014 23:46:18 -0400
Subject: [TUHS] early cc variable and function names
In-Reply-To: <20141017025242.GH6963@mcvoy.com>
References: <20141017022913.7A77818C092@mercury.lcs.mit.edu>
 <20141017024049.GI17227@mercury.ccil.org>
 <20141017025242.GH6963@mcvoy.com>
Message-ID: <20141017034618.GJ17227@mercury.ccil.org>

Larry McVoy scripsit:

> xyz.size
> abc.size
> foobar.size
> 
> What are the types of those structures?

You can't tell because the names are meaningless.  With more meaningful
names, it's usually possible to see what the type must be.

-- 
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 lm at mcvoy.com  Fri Oct 17 13:54:36 2014
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 16 Oct 2014 20:54:36 -0700
Subject: [TUHS] early cc variable and function names
In-Reply-To: <20141017034618.GJ17227@mercury.ccil.org>
References: <20141017022913.7A77818C092@mercury.lcs.mit.edu>
 <20141017024049.GI17227@mercury.ccil.org>
 <20141017025242.GH6963@mcvoy.com>
 <20141017034618.GJ17227@mercury.ccil.org>
Message-ID: <20141017035436.GE11233@mcvoy.com>

So I've been doing C programming since the early 80's and leading 
people doing that for at least 20 years, huh, more like 25 years.

As much as I wish people did what you suggest, they don't.  And I 
mean really good people, top 1%.

So I like the type_name style.

As with many things, I may like it but I don't always get it.

On Thu, Oct 16, 2014 at 11:46:18PM -0400, John Cowan wrote:
> Larry McVoy scripsit:
> 
> > xyz.size
> > abc.size
> > foobar.size
> > 
> > What are the types of those structures?
> 
> You can't tell because the names are meaningless.  With more meaningful
> names, it's usually possible to see what the type must be.
> 
> -- 
> 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

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From random832 at fastmail.us  Fri Oct 17 23:35:11 2014
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Fri, 17 Oct 2014 09:35:11 -0400
Subject: [TUHS] early cc variable and function names
In-Reply-To: <alpine.BSF.2.00.1410171317090.1909@aneurin.horsfall.org>
References: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>
 <alpine.BSF.2.00.1410171317090.1909@aneurin.horsfall.org>
Message-ID: <1413552911.3770380.180156925.37C2AFA9@webmail.messagingengine.com>

On Thu, Oct 16, 2014, at 22:21, Dave Horsfall wrote:
> On Thu, 16 Oct 2014, Mark Longridge wrote:
> 
> > It seems like early cc could only use variable and function names up to 
> > 8 characters.
> 
> In those days it took only the first seven and ignored the rest, 
> prepending an underscore as you discovered.  I don't remember when longer 
> names were recognised; for all I know it could've been around when 
> pathnames could be longer than 14 chars (which I think may have been a 
> BSDism).

For externals, it's a limitation of the PDP-11 a.out format. Other
systems may or may not have had the same limit or a different limit.

For VAX, 4BSD appears to use an "index into file string table", whereas
3BSD still has an 8-character string. I don't see any provision in the
4BSD linker for loading 3BSD binaries.

Filenames over 14 characters appear to have been introduced in 4.1BSD.


From imp at bsdimp.com  Fri Oct 17 23:44:13 2014
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 17 Oct 2014 07:44:13 -0600
Subject: [TUHS] early cc variable and function names
In-Reply-To: <1413552911.3770380.180156925.37C2AFA9@webmail.messagingengine.com>
References: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>
 <alpine.BSF.2.00.1410171317090.1909@aneurin.horsfall.org>
 <1413552911.3770380.180156925.37C2AFA9@webmail.messagingengine.com>
Message-ID: <1462E6EC-86F5-4FFD-8FA7-DDA756256A32@bsdimp.com>


On Oct 17, 2014, at 7:35 AM, random832 at fastmail.us wrote:

> On Thu, Oct 16, 2014, at 22:21, Dave Horsfall wrote:
>> On Thu, 16 Oct 2014, Mark Longridge wrote:
>> 
>>> It seems like early cc could only use variable and function names up to 
>>> 8 characters.
>> 
>> In those days it took only the first seven and ignored the rest, 
>> prepending an underscore as you discovered.  I don't remember when longer 
>> names were recognised; for all I know it could've been around when 
>> pathnames could be longer than 14 chars (which I think may have been a 
>> BSDism).
> 
> For externals, it's a limitation of the PDP-11 a.out format. Other
> systems may or may not have had the same limit or a different limit.
> 
> For VAX, 4BSD appears to use an "index into file string table", whereas
> 3BSD still has an 8-character string. I don't see any provision in the
> 4BSD linker for loading 3BSD binaries.

As someone that wrote an assembler and a linker/loader for the VAX
back in the day (for my first CS class), I know that 4.2 definitely had
the string table, as did all the descendants that I encountered in the
field back during the great unix wars when I was instructed by my employer
to obfuscate certain symbols to “protect” IP.

Warner

> Filenames over 14 characters appear to have been introduced in 4.1BSD.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141017/6757e69a/attachment.sig>

From arnold at skeeve.com  Sat Oct 18 00:07:45 2014
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 17 Oct 2014 08:07:45 -0600
Subject: [TUHS] early cc variable and function names
In-Reply-To: <1462E6EC-86F5-4FFD-8FA7-DDA756256A32@bsdimp.com>
References: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>
 <alpine.BSF.2.00.1410171317090.1909@aneurin.horsfall.org>
 <1413552911.3770380.180156925.37C2AFA9@webmail.messagingengine.com>
 <1462E6EC-86F5-4FFD-8FA7-DDA756256A32@bsdimp.com>
Message-ID: <201410171407.s9HE7jXl010061@freefriends.org>

Warner Losh <imp at bsdimp.com> wrote:
> > For VAX, 4BSD appears to use an "index into file string table", whereas
> > 3BSD still has an 8-character string. I don't see any provision in the
> > 4BSD linker for loading 3BSD binaries.

I think System III or System V picked this up.

> > Filenames over 14 characters appear to have been introduced in 4.1BSD.

No, at 4.2 BSD with the Fast Filesystem.  (Maybe 4.1c or some such
already had the FFS, but the original 4.1 didn't...)

Arnold


From milov at cs.uwlax.edu  Sat Oct 18 00:22:00 2014
From: milov at cs.uwlax.edu (=?utf-8?Q?Milo_Velimirovi=C4=87?=)
Date: Fri, 17 Oct 2014 09:22:00 -0500
Subject: [TUHS] early cc variable and function names
In-Reply-To: <201410171407.s9HE7jXl010061@freefriends.org>
References: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>
 <alpine.BSF.2.00.1410171317090.1909@aneurin.horsfall.org>
 <1413552911.3770380.180156925.37C2AFA9@webmail.messagingengine.com>
 <1462E6EC-86F5-4FFD-8FA7-DDA756256A32@bsdimp.com>
 <201410171407.s9HE7jXl010061@freefriends.org>
Message-ID: <9B907A1F-0FAD-4633-8E74-17F332905E9B@cs.uwlax.edu>


On Oct 17, 2014, at 9:07 AM, arnold at skeeve.com wrote:

> Warner Losh <imp at bsdimp.com> wrote:
>>> For VAX, 4BSD appears to use an "index into file string table", whereas
>>> 3BSD still has an 8-character string. I don't see any provision in the
>>> 4BSD linker for loading 3BSD binaries.
> 
> I think System III or System V picked this up.
> 
>>> Filenames over 14 characters appear to have been introduced in 4.1BSD.
> 
> No, at 4.2 BSD with the Fast Filesystem.  (Maybe 4.1c or some such
> already had the FFS, but the original 4.1 didn't...)
> 
> Arnold
Right!
McKusick, et al. say that it came with the Fast Filesystem in 4.2 [1]

I recall a presentation at UW in Madison where he said, (paraphrasing from memory) We heard you guys. We included long file names in the Fast File System. (loud cheers)

 - Milo
[1] https://www.cs.berkeley.edu/~brewer/cs262/FFS.pdf

From jnc at mercury.lcs.mit.edu  Sat Oct 18 02:11:43 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 17 Oct 2014 12:11:43 -0400 (EDT)
Subject: [TUHS] early cc variable and function names
Message-ID: <20141017161143.5E25618C090@mercury.lcs.mit.edu>

    > From: jnc at mercury.lcs.mit.edu (Noel Chiappa)

    >> Did anyone document these sorts of limitations of early cc?

    > I seem to recall at least one document from that period (I think
    > pertaining to the so-called 'Typesetter C') about 'changes to C'.
    > ...
    > I'll see if I can dig them out tomorrow.

OK, there are three documents which sort of fall into this class. First,
there is something titled "New C Compiler Features", no date, available here:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/doc/cdoc/newstuff.nr

no date, but it appears to describe an early version of the so-called
'Typesetter C', mentioned in other documents, so this would be circa 1976 or
so.


There is a second document, untitled, no date, which I have not been able to
locate online at all. I scanned my hard-copy, available here:

  http://ana-3.lcs.mit.edu/~jnc/history/unix/CImprovements1.jpg
  ..
  http://ana-3.lcs.mit.edu/~jnc/history/unix/CImprovements5.jpg

>From the content, it seems to be from shortly after the previous one, so say,
circa 1977.

Sorry about the poor readability (it looked fine on the monitor of the
machine my scanner is attached to); fudging with contrast would probably make
it more readable. When I get the MIT V6 Unix tapes read (they have been sent
off to a specialist in reading old tapes, results soon, I hope) I might be
able to get more info (e.g. date/filename), and machine-readable source.


Finally, there is "Recent Changes to C", from November 15, 1978, available
here:

  http://cm.bell-labs.com/cm/cs/who/dmr/cchanges.pdf
  
which documents a few final bits.


There is of course also Dennis M. Ritchie, "The Development of the C
Language", available here:

  http://cm.bell-labs.com/who/dmr/chist.html

which is a good, interesting history of C.


    > Also, I have started a note with a list of 'issues with C when you're
    > backporting V7 and later code to V6'

I found several documents which are bits and pieces of this.

  http://ana-3.lcs.mit.edu/~jnc/history/unix/C_Backport.txt
  http://ana-3.lcs.mit.edu/~jnc/history/unix/V6_C.txt

Too busy to really clean them up at the moment.

	Noel


From b4 at gewt.net  Sat Oct 18 02:44:49 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Fri, 17 Oct 2014 12:44:49 -0400 (EDT)
Subject: [TUHS] 3BSD/32V: 2 RP06 (SIMH)
Message-ID: <alpine.DFB.2.11.1410171239360.858@meaghan.gimme-sympathy.org>

Afternoon,

# /etc/mkfs /dev/rrp1g 145673
isize = 65488
m/n = 3 500
write error: 2
# file rp0g
rp0g:   block special (0/6)
# file rp1g
rp1g:   block special (0/14)
# file rp0a
rp0a:   block special (0/0)
# file rp1a
rp1a:   block special (0/8)
# file rrp0a
rrp0a:  character special (4/0)
# file rrp1a
rrp1a:  character special (4/8)
# file rrp0g
rrp0g:  character special (4/6)
# file rrp1g
rrp1g:  character special (4/14)

DESCRIPTION
      Files with minor device numbers 0 through 7 refer to various
      portions of drive 0; minor devices 8 through 15 refer to
      drive 1, etc.

      The origin and size of the pseudo-disks on each drive are as
      follows:

What am I forgetting?  I have an image attached, I have modified hp.c to 
have NHP as 2.

Is it conflict between rp.c and hp.c? (I patched hp.c to have NHP 2 after 
patching NURP in rp.c to be 2).

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From random832 at fastmail.us  Sat Oct 18 05:29:10 2014
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Fri, 17 Oct 2014 15:29:10 -0400
Subject: [TUHS] early cc variable and function names
In-Reply-To: <201410171407.s9HE7jXl010061@freefriends.org>
References: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>
 <alpine.BSF.2.00.1410171317090.1909@aneurin.horsfall.org>
 <1413552911.3770380.180156925.37C2AFA9@webmail.messagingengine.com>
 <1462E6EC-86F5-4FFD-8FA7-DDA756256A32@bsdimp.com>
 <201410171407.s9HE7jXl010061@freefriends.org>
Message-ID: <1413574150.106130.180291125.467C98A8@webmail.messagingengine.com>

On Fri, Oct 17, 2014, at 10:07, arnold at skeeve.com wrote:
> Warner Losh <imp at bsdimp.com> wrote:
What's actually quoted is what I wrote.

> > > For VAX, 4BSD appears to use an "index into file string table", whereas
> > > 3BSD still has an 8-character string. I don't see any provision in the
> > > 4BSD linker for loading 3BSD binaries.
> 
> I think System III or System V picked this up.
> 
> > > Filenames over 14 characters appear to have been introduced in 4.1BSD.
> 
> No, at 4.2 BSD with the Fast Filesystem.  (Maybe 4.1c or some such
> already had the FFS, but the original 4.1 didn't...)

I was looking at 4.1c in the archive, sorry for not being clear.


From clemc at ccc.com  Sat Oct 18 05:41:17 2014
From: clemc at ccc.com (Clem Cole)
Date: Fri, 17 Oct 2014 15:41:17 -0400
Subject: [TUHS] early cc variable and function names
In-Reply-To: <20141017034618.GJ17227@mercury.ccil.org>
References: <20141017022913.7A77818C092@mercury.lcs.mit.edu>
 <20141017024049.GI17227@mercury.ccil.org> <20141017025242.GH6963@mcvoy.com>
 <20141017034618.GJ17227@mercury.ccil.org>
Message-ID: <CAC20D2PHWVf2OM7GK=cL9n6Q+6MfwHq4LcvFHMKwgYxE5RYEBQ@mail.gmail.com>

Larry - AMEN.

The key is that in the old days it was much easier to glance and code and
know which struct or union was being examined.  Today, that context is lost
and I have to think more about what the type of the ptr is.   Yes the
>>compiler<< knows, but I as the random programmer reading the code later
do not.

Larry and my experiences with very, very good programmers is the same.

Clem

On Thu, Oct 16, 2014 at 11:46 PM, John Cowan <cowan at mercury.ccil.org> wrote:

> Larry McVoy scripsit:
>
> > xyz.size
> > abc.size
> > foobar.size
> >
> > What are the types of those structures?
>
> You can't tell because the names are meaningless.  With more meaningful
> names, it's usually possible to see what the type must be.
>
> --
> 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
> _______________________________________________
> 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/20141017/2415f205/attachment.html>

From random832 at fastmail.us  Sat Oct 18 06:37:08 2014
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Fri, 17 Oct 2014 16:37:08 -0400
Subject: [TUHS] early cc variable and function names
In-Reply-To: <20141017025242.GH6963@mcvoy.com>
References: <20141017022913.7A77818C092@mercury.lcs.mit.edu>
 <20141017024049.GI17227@mercury.ccil.org>
 <20141017025242.GH6963@mcvoy.com>
Message-ID: <1413578228.125790.180311153.48CF1319@webmail.messagingengine.com>

On Thu, Oct 16, 2014, at 22:52, Larry McVoy wrote:
> abc.st_size
> 
> Huh, abc is a struct stat.
> 
> I get that it was a bug and needed to be fixed but I wish that everyone 
> still pretended that it was one namespace, makes code so much easier to
> read.

I'm not sure what your design is that you're more than a screen away
from either its declaration, a stat call, or the fact that it's got size
_and_ mode _and_ mtime etc.

And if you do that, why stop there? Why not require the type to be
repeated to dereference any pointer?

while(*x == 0)

is x a pointer to int, to char, to another pointer, etc?


From lm at mcvoy.com  Sat Oct 18 06:42:29 2014
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 17 Oct 2014 13:42:29 -0700
Subject: [TUHS] early cc variable and function names
In-Reply-To: <1413578228.125790.180311153.48CF1319@webmail.messagingengine.com>
References: <20141017022913.7A77818C092@mercury.lcs.mit.edu>
 <20141017024049.GI17227@mercury.ccil.org>
 <20141017025242.GH6963@mcvoy.com>
 <1413578228.125790.180311153.48CF1319@webmail.messagingengine.com>
Message-ID: <20141017204229.GA4249@mcvoy.com>

On Fri, Oct 17, 2014 at 04:37:08PM -0400, random832 at fastmail.us wrote:
> On Thu, Oct 16, 2014, at 22:52, Larry McVoy wrote:
> > abc.st_size
> > 
> > Huh, abc is a struct stat.
> > 
> > I get that it was a bug and needed to be fixed but I wish that everyone 
> > still pretended that it was one namespace, makes code so much easier to
> > read.
> 
> I'm not sure what your design is that you're more than a screen away
> from either its declaration, a stat call, or the fact that it's got size
> _and_ mode _and_ mtime etc.
> 
> And if you do that, why stop there? Why not require the type to be
> repeated to dereference any pointer?

Hey, everyone is welcome to their own opinion and it doesn't have to match
mine.  I review a lot of code, a lot of code that I didn't write.  Lots of
times the review is in a web browser that doesn't know how to tag to the
definition.  Sure I can clone the repo and make tags and tag to it but for
small reviews there is no need.

I do a bunch of code reviews every day.  foo.size is a lot less helpful
than foo.vfs_size or whatever.

Your mileage may vary, where I work we optimize for the reader not for
the writer.  That's how it is when you work for me.  When I work for 
you then your rules win :)
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From grog at lemis.com  Sat Oct 18 17:25:56 2014
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Sat, 18 Oct 2014 18:25:56 +1100
Subject: [TUHS] early cc variable and function names
In-Reply-To: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>
References: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>
Message-ID: <20141018072556.GC41494@eureka.lemis.com>

On Thursday, 16 October 2014 at 21:51:56 -0400, Mark Longridge wrote:
> So it would seem that function names can only be 7 characters in
> length. I am not sure if limitations of early cc were documented
> anywhere.

This is really an identifier issues, and it's documented in K&R 1st
edition, page 179:

  DEC PDP-11      7 characters, 2 cases
  Honeywell 6000  6 characters, 1 case
  IBM 360/370     7 characters, 1 case
  Interdata 8/32  8 characters, 2 cases

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: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141018/eafed5ba/attachment.sig>

From jnc at mercury.lcs.mit.edu  Sat Oct 18 20:32:21 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 18 Oct 2014 06:32:21 -0400 (EDT)
Subject: [TUHS] early cc variable and function names
Message-ID: <20141018103221.204F418C089@mercury.lcs.mit.edu>

    > From: Greg 'groggy' Lehey <grog at lemis.com>

    > This is really an identifier issues

Probably actually a function of the relocatable object format / linker on the
machines in question, which in most (all?) cases predated C itself.

    > it's documented in K&R 1st edition, page 179:

Oooh, good piece of detective work!

	Noel


From ron at ronnatalie.com  Sun Oct 19 09:03:21 2014
From: ron at ronnatalie.com (Ron Natalie)
Date: Sat, 18 Oct 2014 19:03:21 -0400
Subject: [TUHS] early cc variable and function names
In-Reply-To: <20141018103221.204F418C089@mercury.lcs.mit.edu>
References: <20141018103221.204F418C089@mercury.lcs.mit.edu>
Message-ID: <C23D45B6-2397-47D0-B1A7-04F989B37608@ronnatalie.com>

The assembler could handle 8 case independent symbols.   C prepended an underscore to avoid any symbol conflicts.    If I recall the compiler allowed longer symbols but it just lost those letters after 7.

Amusingly an early IBM 370 compiler omitted prepending the underscore which lead to hilarity when you declared variables called things like R15.

On Oct 18, 2014, at 6:32 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>> From: Greg 'groggy' Lehey <grog at lemis.com>
> 
>> This is really an identifier issues
> 
> Probably actually a function of the relocatable object format / linker on the
> machines in question, which in most (all?) cases predated C itself.
> 
>> it's documented in K&R 1st edition, page 179:
> 
> Oooh, good piece of detective work!
> 
>    Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From dave at horsfall.org  Sun Oct 19 09:11:30 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 19 Oct 2014 10:11:30 +1100 (EST)
Subject: [TUHS] early cc variable and function names
In-Reply-To: <C23D45B6-2397-47D0-B1A7-04F989B37608@ronnatalie.com>
References: <20141018103221.204F418C089@mercury.lcs.mit.edu>
 <C23D45B6-2397-47D0-B1A7-04F989B37608@ronnatalie.com>
Message-ID: <alpine.BSF.2.00.1410191010521.27395@aneurin.horsfall.org>

On Sat, 18 Oct 2014, Ron Natalie wrote:

> Amusingly an early IBM 370 compiler omitted prepending the underscore 
> which lead to hilarity when you declared variables called things like 
> R15.

Holy snot!

-- 
Dave Horsfall (VK2KFU)
http://www.horsfall.org/spam.html (and check the home page)


From M.Engel at leedsbeckett.ac.uk  Tue Oct 21 21:23:33 2014
From: M.Engel at leedsbeckett.ac.uk (Engel, Michael)
Date: Tue, 21 Oct 2014 11:23:33 +0000
Subject: [TUHS] Codata progress update
Message-ID: <5F320B50-8490-4B3C-B774-737B017603C1@leedsbeckett.ac.uk>


Hi,

it's time for an update on our progress with the Codata machine.

The serial interface problem was not caused by a defective transceiver
chip (which I found out after buying a couple…), but by an extreme 
amount of noise on the (quite long and old) serial cable we used to
connect the machine to the PC acting as a terminal. Using a USB
to serial adapter and a short 9-to-25-pin adapter cable solved this
problem. Well, try the obvious things first (using a scope helped).
The second CPU board also works, so we could build a complete
second machine with our spare boards if we have another multibus
backplane...

We could get the machine up and booting from the first 8" hard disk 
last Friday. Luckily, an old version of Kermit was installed and we 
were able to transmit a large part of the root file system from single
user more - especially the Unix kernels, driver sources, the build 
directories for the kernel, include files and the build directory for 
the standalone boot floppies. All with a speed of 500 bytes/s (9600
bps serial line minus kermit overhead). cksum was used to confirm
that the files were transferred correctly (this was the only checksumming 
tool that was available on the Codata, I didn't want to mount the fs
read-write and compile software before completing the backup).

I had to shut the machine down on Friday evening (security policy
that kicks you out of the building here), since I didn't want to leave
it running unattended over the weekend. Unfortunately, the disk 
seems to have developed a bad sector in the autoconfiguration 
region (the system seems to be quite modern in this respect). 
The kernel can be booted successfully, but it refuses to mount the 
root fs, complaining about a timeout. There seems to be a complete 
root file system on the second disk (the firmware is able to read files 
from the disk, but it doesn't offer a feature to list directories…), but the 
kernel on the second disk also is hardwired to mount its root fs from the 
first disk. Trying to connect disk 2 as disk 1 resulted in a non-booting 
system...

The good news is that both root file systems seem to be reasonably 
intact so far, I can read text files from the boot monitor. So our next 
step to backup the rest of the system is to build an emergency boot 
floppy. At the moment, however, the Codata refuses to talk to its 
floppy drive. The machine has a Multibus FD controller with its own 
8085 CPU and a uPD765, connected to a Toshiba 5.25" DD floppy 
drive (720 kB, 80 tracks, 9 sectors of 512 bytes), the model identifier
is DDF5-30C-34I (printed on the motor assembly). I couldn't find
any information on that drive online, so I hesitate to simply 
connect a more modern drive due to possible pinout differences.

I also found out a bit more on the SMD disk controller. It seems to
be an OEM variant of the Micro Computer Technology MCT-4300
controller. The only place I could find this mentioned was in a 
catalog of Multibus boards on archive.org. It has its own driver 
(cd.c), there is a separate one for the Interphase 2180 and an 
additional one for the Codata MFM controller.

So, if you happen to have any information on the Codata floppy
controller, the Toshiba floppy or the MCT-4300 SMD disk controller,
I would be happy to hear from you...

-- Michael



From jnc at mercury.lcs.mit.edu  Tue Oct 21 22:44:18 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 21 Oct 2014 08:44:18 -0400 (EDT)
Subject: [TUHS] Codata progress update
Message-ID: <20141021124418.5591E18C0CD@mercury.lcs.mit.edu>

    > From: "Engel, Michael" <M.Engel at leedsbeckett.ac.uk>

    > The machine has a Multibus FD controller with its own 8085 CPU and a
    > uPD765, connected to a Toshiba 5.25" DD floppy drive (720 kB, 80
    > tracks, 9 sectors of 512 bytes), the model identifier is DDF5-30C-34I
    > ... I couldn't find any information on that drive online, so I hesitate
    > to simply connect a more modern drive due to possible pinout differences.
    > ...
    > I also found out a bit more on the SMD disk controller. It seems to be
    > an OEM variant of the Micro Computer Technology MCT-4300 controller.
    > The only place I could find this mentioned was in a catalog of Multibus
    > boards on archive.org.
    > ...
    > So, if you happen to have any information on the Codata floppy
    > controller, the Toshiba floppy or the MCT-4300 SMD disk controller, I
    > would be happy to hear from you...

I don't, but can I suggest the Classic Computers mailing list:

  http://www.classiccmp.org/mailman/listinfo/cctalk

They seem to have an extremely deep well of knowledge, and perhaps someone
there can help? (I'd rate the odds very high on the floppy drive.)

	Noel


From jsteve at superglobalmegacorp.com  Mon Oct 27 20:32:52 2014
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Mon, 27 Oct 2014 18:32:52 +0800
Subject: [TUHS] speaking of early C compilers
Message-ID: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>

has anyone ever tried to compile any of the old C compilers with a 'modern'
C compiler?

I tried a few from the 80's (Microsoft/Borland) and there is a bunch of
weird stuff where integers suddenly become structs, structures reference
fields that aren't in that struct,   

c01.c
        register int t1;
....
                t1->type = UNSIGN;


And my favorite which is closing a bunch of file handles for the heck of it,
and redirecting stdin/out/err from within the program instead of just
opening the file and using fread/fwrite.. 

c00.c
	if (freopen(argv[2], "w", stdout)==NULL ||
(sbufp=fopen(argv[3],"w"))==NULL)


How did any of this compile?  How did this stuff run without clobbering
each-other?

I don't know why but I started to look at this stuff with some half hearted
attempt at getting Apout running on Windows.  Naturally there is no fork, so
when a child process dies, the whole thing crashes out.  I guess I could
simulate a fork with threads and containing all the cpu variables to a
structure for each thread, but that sounds like a lot of work for a limited
audience.

But there really is some weird stuff in v7's c compiler.


From jsteve at superglobalmegacorp.com  Mon Oct 27 22:06:52 2014
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Mon, 27 Oct 2014 20:06:52 +0800
Subject: [TUHS] Getting Unix v5 to talk
Message-ID: <0F0B9BFC06289346B88512B91E55670D2F87@EXCHANGE>

Have you looked at http://real-votrax.no-ip.org/

they have a votrax hooked up, and yes it'll use your phonemes that speak
generates. 
It just likes things to be upper case though.

So..
hello
!p
,h,e0,l,o0,o1,-1

works more like

H E0 L O0 O1 PA1

I wonder if anyone's generated wav's for each of the phonemes, then you
could hook up a line printer or something that'll read it as a pipe and just
play the wav's as needed..

It is rough 1970's speech synthesis, but I had one of those Intellivoice
things as a kid, so I kinda like it.

-----Original Message-----
From: Mark Longridge
To: tuhs
Sent: 10/13/14 8:57 AM
Subject: [TUHS] Getting Unix v5 to talk

Thanks to the efforts of Jonathan Gevaryahu I have managed
to get the Unix v5 speak utility to compile and execute.
All this was done using the simh emulator emulating a
PDP-11/70.

Jonathan managed extract enough of speak.c to reconstruct it
to the point it could be compiled with v5 cc. I believe it
was necessary to look at speak.o to accomplish this.

Jonathan also states that there are more interesting things
that could possibly be recovered from v6doc.tar.gz

One can look at speak.c source here:

http://www.maxhost.org/other/speak.c

Now had we have speak compiled we can go a bit further:

cat speak.v - | speak -v null
  generates speak.m from ascii file speak.v

speak speak.m
 computer
 !p         (prints out phonetics for working word)
 which outputs:
 ,k,a0,m,p,E2,U1,t,er,-1
 ctrl-d exits

Looking at speak.c we can see that it opens /dev/vs.
Fortunately we have the file /usr/sys/dmr/vs.c to look at
so this could be compiled into the kernel although I haven't
done this as yet.

speak.c looks like Unix v5 era code. My understanding is that
Unix v5 appeared in June 1974 and the comments say 'Copyright 1974'
so it seems plausible.

I'm intrigued by the possibility of getting Unix v5 to talk.

Mark
_______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs


From brantley at coraid.com  Mon Oct 27 23:03:15 2014
From: brantley at coraid.com (Brantley Coile)
Date: Mon, 27 Oct 2014 13:03:15 +0000
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
Message-ID: <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com>

Early C allowed you to use the '->' operator with any scaler.  See early C reference manuals.  This is the reason there is one operator to access a member of a structure using a pointer and another, '.', to access a member in a static structure.  The B language had no types, everything was a word, and dmr evolved C from B.  At first it made sense to use the '->' operator to mean add a constant to whatever is on the left and use as an l-value.  

You will also find that member names share a single name space.   The simple symbol table had an bit in each entry to delineate members from normal variables.  You could only use the same member name in two different structs if the members had the same offsets.  In other words, it was legal to add a member name to the symbol table that was already there if the value of the symbol was the same as the existing entry. 

Dennis' compilers kept some backward compatibility even after the language evolved away from them. 

This really shows the value of evolving software instead of thinking one has all the answers going into development.  If one follows the development of C one sees the insights learned as they went.  The study of these early Unix systems have a great deal to teach that will be valuable in the post Moore's law age.  Much of the worlds software will need to a re-evolution. 

By the way, did you notice the compiler overwrites itself?   We used to have to work in tiny spaces.  Four megabytes was four million dollars. 

Sent from my iPad

> On Oct 27, 2014, at 6:42 AM, Jason Stevens <jsteve at superglobalmegacorp.com> wrote:
> 
> has anyone ever tried to compile any of the old C compilers with a 'modern'
> C compiler?
> 
> I tried a few from the 80's (Microsoft/Borland) and there is a bunch of
> weird stuff where integers suddenly become structs, structures reference
> fields that aren't in that struct,   
> 
> c01.c
>        register int t1;
> ....
>                t1->type = UNSIGN;
> 
> 
> And my favorite which is closing a bunch of file handles for the heck of it,
> and redirecting stdin/out/err from within the program instead of just
> opening the file and using fread/fwrite.. 
> 
> c00.c
>    if (freopen(argv[2], "w", stdout)==NULL ||
> (sbufp=fopen(argv[3],"w"))==NULL)
> 
> 
> How did any of this compile?  How did this stuff run without clobbering
> each-other?
> 
> I don't know why but I started to look at this stuff with some half hearted
> attempt at getting Apout running on Windows.  Naturally there is no fork, so
> when a child process dies, the whole thing crashes out.  I guess I could
> simulate a fork with threads and containing all the cpu variables to a
> structure for each thread, but that sounds like a lot of work for a limited
> audience.
> 
> But there really is some weird stuff in v7's c compiler.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From ron at ronnatalie.com  Mon Oct 27 23:34:53 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 27 Oct 2014 09:34:53 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
 <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com>
Message-ID: <5BDD9EB6-4F00-4C28-BC7F-4A264996A625@ronnatalie.com>

Yep, the kernel was littered with funky memory constants using ->  to point at various registers.   Probably the most ubuiqtous was
#define PS 0177776
struct { 
    int integ;
};

yielding the PS->integ access to the Processor Status Register.




From random832 at fastmail.us  Mon Oct 27 23:40:36 2014
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Mon, 27 Oct 2014 09:40:36 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <5BDD9EB6-4F00-4C28-BC7F-4A264996A625@ronnatalie.com>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
 <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com>
 <5BDD9EB6-4F00-4C28-BC7F-4A264996A625@ronnatalie.com>
Message-ID: <1414417236.2834739.183752501.006CD61F@webmail.messagingengine.com>

On Mon, Oct 27, 2014, at 09:34, Ronald Natalie wrote:
> Yep, the kernel was littered with funky memory constants using ->  to
> point at various registers.   Probably the most ubuiqtous was
> #define PS 0177776
> struct { 
>     int integ;
> };
> 
> yielding the PS->integ access to the Processor Status Register.

Is there any reason this is superior to *(int *)0177776 [and e.g.
#define integ(x) (*(int *)(x))]? Did casting not exist back then?


From jnc at mercury.lcs.mit.edu  Mon Oct 27 23:46:58 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 27 Oct 2014 09:46:58 -0400 (EDT)
Subject: [TUHS] speaking of early C compilers
Message-ID: <20141027134658.C64BE18C0A5@mercury.lcs.mit.edu>

    > From: random832 at fastmail.us

    > Did casting not exist back then?

No, not in the early V6 compiler. It was only added as of the Typesetter
compiler. (I think if you look in those 'Recent C Changes' things I sent in
recently {Oct 17}, you'll find mention of it.)

	Noel


From jsteve at superglobalmegacorp.com  Mon Oct 27 23:54:53 2014
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Mon, 27 Oct 2014 21:54:53 +0800
Subject: [TUHS] speaking of early C compilers
Message-ID: <0F0B9BFC06289346B88512B91E55670D2F89@EXCHANGE>

 Thanks for clearing that the whole members out of nowhere thing.

I had thought (ha ha) that since I don't have a working fork, I could just
rebuild CC as a native 
executable, and then just call apout for each stage, but I never realized
how interdependent
they all are, at least C0 to C1.

It's crazy to think of how much this stuff cost once upon a time.  

And now we live in the era of javascript pdp-11's
http://pdp11.aiju.de/

-----Original Message-----
From: Brantley Coile
To: Jason Stevens
Cc: tuhs at minnie.tuhs.org
Sent: 10/27/14 9:03 PM
Subject: Re: [TUHS] speaking of early C compilers

Early C allowed you to use the '->' operator with any scaler.  See early
C reference manuals.  This is the reason there is one operator to access
a member of a structure using a pointer and another, '.', to access a
member in a static structure.  The B language had no types, everything
was a word, and dmr evolved C from B.  At first it made sense to use the
'->' operator to mean add a constant to whatever is on the left and use
as an l-value.  

You will also find that member names share a single name space.   The
simple symbol table had an bit in each entry to delineate members from
normal variables.  You could only use the same member name in two
different structs if the members had the same offsets.  In other words,
it was legal to add a member name to the symbol table that was already
there if the value of the symbol was the same as the existing entry. 

Dennis' compilers kept some backward compatibility even after the
language evolved away from them. 

This really shows the value of evolving software instead of thinking one
has all the answers going into development.  If one follows the
development of C one sees the insights learned as they went.  The study
of these early Unix systems have a great deal to teach that will be
valuable in the post Moore's law age.  Much of the worlds software will
need to a re-evolution. 

By the way, did you notice the compiler overwrites itself?   We used to
have to work in tiny spaces.  Four megabytes was four million dollars. 

Sent from my iPad

> On Oct 27, 2014, at 6:42 AM, Jason Stevens
<jsteve at superglobalmegacorp.com> wrote:
> 
> has anyone ever tried to compile any of the old C compilers with a
'modern'
> C compiler?
> 
> I tried a few from the 80's (Microsoft/Borland) and there is a bunch
of
> weird stuff where integers suddenly become structs, structures
reference
> fields that aren't in that struct,   
> 
> c01.c
>        register int t1;
> ....
>                t1->type = UNSIGN;
> 
> 
> And my favorite which is closing a bunch of file handles for the heck
of it,
> and redirecting stdin/out/err from within the program instead of just
> opening the file and using fread/fwrite.. 
> 
> c00.c
>    if (freopen(argv[2], "w", stdout)==NULL ||
> (sbufp=fopen(argv[3],"w"))==NULL)
> 
> 
> How did any of this compile?  How did this stuff run without
clobbering
> each-other?
> 
> I don't know why but I started to look at this stuff with some half
hearted
> attempt at getting Apout running on Windows.  Naturally there is no
fork, so
> when a child process dies, the whole thing crashes out.  I guess I
could
> simulate a fork with threads and containing all the cpu variables to a
> structure for each thread, but that sounds like a lot of work for a
limited
> audience.
> 
> But there really is some weird stuff in v7's c compiler.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From clemc at ccc.com  Tue Oct 28 00:04:30 2014
From: clemc at ccc.com (Clem Cole)
Date: Mon, 27 Oct 2014 10:04:30 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <1414417236.2834739.183752501.006CD61F@webmail.messagingengine.com>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
 <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com>
 <5BDD9EB6-4F00-4C28-BC7F-4A264996A625@ronnatalie.com>
 <1414417236.2834739.183752501.006CD61F@webmail.messagingengine.com>
Message-ID: <CAC20D2PBFBNxQffi+uYxefNy-9VQG16QxE2UZmsqk9sRoKz7Lg@mail.gmail.com>

Cast became part of Typesetter C IIRC - so V6 and before does not support
casting and a number of other "modern" C features.

Again you need to think about the time.   C, BLISS, PL/360 et al were being
developed to replace writing in raw assembler.  So supporting assembler
style idioms that allowed you to get the raw addresses like PS or specific
registers were natural and also remember the optimizers are still in their
infancy.

i.e.

while (SOME_HW_REG_BASE_ADDR->some_sub-register&SOME_MASK) {
     ... do something/spin etc .. ...
}

would be a two assembler instruction loop and a natural type of thing a
programmer we want to do,


The idea of things like "const" etc we use today - just did yet exist

As side note from those times, the BLISS compiler's optimizer (which was
much more sophisticated than the C compilers) got so good that idioms that
test constants like that were removed as .    So Wulf created "code
comments" (aka today's PRAGMAs) to inform the compiler that the writer of
the code knew what they were doing and to "just do it."  If you look at CMU
kernel code from things like Hydra and other kernels of time - you will see
a the code comment: "BOH" - meaning "Buzz Off Hobbes" - the nasty shot at
my friend Steve Hobbes. Bill student, who did much of the BLISS optimizer.

On Mon, Oct 27, 2014 at 9:40 AM, <random832 at fastmail.us> wrote:

> On Mon, Oct 27, 2014, at 09:34, Ronald Natalie wrote:
> > Yep, the kernel was littered with funky memory constants using ->  to
> > point at various registers.   Probably the most ubuiqtous was
> > #define PS 0177776
> > struct {
> >     int integ;
> > };
> >
> > yielding the PS->integ access to the Processor Status Register.
>
> Is there any reason this is superior to *(int *)0177776 [and e.g.
> #define integ(x) (*(int *)(x))]? Did casting not exist back then?
> _______________________________________________
> 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/20141027/c3bdd524/attachment.html>

From jnc at mercury.lcs.mit.edu  Tue Oct 28 00:48:33 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 27 Oct 2014 10:48:33 -0400 (EDT)
Subject: [TUHS] speaking of early C compilers
Message-ID: <20141027144833.536A618C0A5@mercury.lcs.mit.edu>

    > From: Jason Stevens

    > has anyone ever tried to compile any of the old C compilers with a
    > 'modern' C compiler?
    > ...
    > How did any of this compile? How did this stuff run without clobbering
    > each-other?

As Ron Natalie said, the early kernels are absolutely littered with all sorts
of stuff that, by today's standards, are totally unacceptable. Using a
variable declared as an int as a pointer, using a variable declared as a
'foo' pointer as a 'bar' pointer, yadda-yadda.

I ran (tripped, actually :-) across several of these while trying to get my
pipe-splicing code to work. (I used Version 6 since i) I am _totally_
familiar with it, and ii) it's what I had running.)

For example, I tried to be all nice and modern and declared my pointer
variables to be the correct type. The problem is that Unix generated unique
ID's to sleep on with code like "sleep(p+1, PPIPE)", and the value generated
by "p+1" depends on what type "p" is declared as - and if you look in pipe.c,
you'll see it's often declared as an int pointer. So when _I_ wrote
"sleep((p + 1), PPIPE)", with "p" declared as a "stuct file pointer", I got
the wrong number.

I can only speculate as to why they wrote code like this. I think part of it
is, as Brantley Coile points out, historical artifacts due to the evolution
of C from (originally) BCPL. That may have gotten them used to writing code
in a certain way - I don't know. I also expect the modern mindset (of being
really strict about types, and formal about coverting data from one to
another) was still evolving back then - partly because they often didn't
_have_ the tools (e.g. casts) to do it right. Another possibility is that
they were using line editors, and maintaining more extensive source is a pain
with an editor like that. Why write "struct file *p" wnen you can just write
"*p"? And of course everyone was so space-concious back then, with those tiny
disks (an RK05 pack is, after all, only 2.5MB - only slightly larger than a
3.5" floppy!) every byte counted.


I have to say, though, that it's really kind of jarring to read this stuff.

I have so much respect for their overall structure (the way the kernel is
broken down into sub-systems, and the sub-systems into routines), how they
managed to get a very powerful (by anyone's standards, even today's) OS into
such a small amount of code... And the _logic_ of any given routine is
usually quite nice, too: clear and efficient. And I love their commenting
style - no cluttering up the code with comments unless there's something that
really needs elucidation, just a short header to say, at a high level, what
the routine does (and sometimes how and why).

So when I see these funky declarations (e.g. "int *p" for something that's
_only_ going to be used to point to a "struct file"), I just cringe - even
though I sort of understand (see above) why it's like that. It's probably the
thing I would most change, if I could.

	Noel


From dave at horsfall.org  Tue Oct 28 01:04:33 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 28 Oct 2014 02:04:33 +1100 (EST)
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <1414417236.2834739.183752501.006CD61F@webmail.messagingengine.com>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
 <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com>
 <5BDD9EB6-4F00-4C28-BC7F-4A264996A625@ronnatalie.com>
 <1414417236.2834739.183752501.006CD61F@webmail.messagingengine.com>
Message-ID: <alpine.BSF.2.00.1410280159310.57132@aneurin.horsfall.org>

On Mon, 27 Oct 2014, random832 at fastmail.us wrote:

> Is there any reason this is superior to *(int *)0177776 [and e.g.
> #define integ(x) (*(int *)(x))]? Did casting not exist back then?

Type casts?  In a compiler/linker that supported e.g.:

int abort 4;

...

abort();

Thou jests...

-- 
Dave Horsfall (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From ron at ronnatalie.com  Tue Oct 28 01:09:27 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 27 Oct 2014 11:09:27 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <20141027144833.536A618C0A5@mercury.lcs.mit.edu>
References: <20141027144833.536A618C0A5@mercury.lcs.mit.edu>
Message-ID: <25DC9219-F0CD-4456-81A3-CF93EDD7A616@ronnatalie.com>

We thought the kernels got cleaned up a lot by the time we got to the BSD releases.    We were wrong.
When porting our variant of the 4 BSD to the Denelcor HEP supercomputer we found a rather amusing failure.

The HEP was a 64 bit word machine but it had partial words of 16 and 32 bits.   The way it handled these was to encode the word size in the lower bits of the address (since the bottom three weren't used in word addressing anyhow).    If the bottom three were zero, then it was the full word.  If it was 2 or 6, it was the left or right half word, and 1,3, 5, and 7 yielded the four quarter words.  (Byte operations used different instructions so they directly addressed the memory).

Now Mike Muuss who did the C compiler port made sure that all the casts did the right thing.   If you cast "int *" to "short *" it would tweak the low order bits to make things work.    However the BSD kernel in several places did what I call conversion by union:  essentially this:

union carbide {
     char*  c;
     short* s;
     int*     i;
} u;

u.s  = ...some valid short* ...
int* ip = u.i;

Note the compiler has no way of telling that you are storing and retrieving through different union members and hence the low order bits ended up reflecting the wrong word size and this led to some flamboyant failures.     I then spent a week running around the kernel making these void* and fixing up all the access points to properly cast the accesses to it.

The other amusing thing was what to call the data types.     Since this was a word machine, there was a real predisposition to call the 64 bit sized thing "int" but that meant we needed another typename for the 32 bit thing (since we decided to leave short for the 16 bit integer).     I lobbied hard for "medium" but we ended up using int32.   Of course, this is long before the C standards ended up reserving the _ prefix for the implementation.

The afore mentioned fact that all the structure members shared the same namespace in the original implementation is why the practice of using letter prefixes on them (like b_flags and b_next etc... rather than just flags or next) that persisted long after the C compiler got this issue resolved.

Frankly, I really wish they'd have fixed arrays in C to be properly functioning types at the same time they fixed structs to be proper types as well.     Around the time of the typesetter or V7 releases we could assign and return structs but arrays still had the silly "devolve into pointers" behavior that persists unto this day and still causes problems among the newbies.



From dave at horsfall.org  Tue Oct 28 01:13:38 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 28 Oct 2014 02:13:38 +1100 (EST)
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <20141027144833.536A618C0A5@mercury.lcs.mit.edu>
References: <20141027144833.536A618C0A5@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.00.1410280212020.57132@aneurin.horsfall.org>

On Mon, 27 Oct 2014, Noel Chiappa wrote:

> So when I see these funky declarations (e.g. "int *p" for something 
> that's _only_ going to be used to point to a "struct file"), I just 
> cringe - even though I sort of understand (see above) why it's like 
> that. It's probably the thing I would most change, if I could.

What, as opposed to spelling creat() with an "e"?

-- 
Dave Horsfall (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From jnc at mercury.lcs.mit.edu  Tue Oct 28 01:48:10 2014
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 27 Oct 2014 11:48:10 -0400 (EDT)
Subject: [TUHS] speaking of early C compilers
Message-ID: <20141027154810.EE17018C0A4@mercury.lcs.mit.edu>

    > From: Dave Horsfall <dave at horsfall.org>

    > What, as opposed to spelling creat() with an "e"?

Actually, that one never bothered me at all!

I tended to be more annoyed by _extra_ characters; e.g. the fact that 'change
directory' was (in standard V6) "chdir" (as opposed to just plain "cd") I
found far more irritating! Why make that one _five_ characters, when most
common commands are two?! (cc, ld, mv, rm, cp, etc, etc, etc...)

	Noel


From dave at horsfall.org  Tue Oct 28 02:25:41 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 28 Oct 2014 03:25:41 +1100 (EST)
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <20141027154810.EE17018C0A4@mercury.lcs.mit.edu>
References: <20141027154810.EE17018C0A4@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.00.1410280318570.57132@aneurin.horsfall.org>

On Mon, 27 Oct 2014, Noel Chiappa wrote:

> > What, as opposed to spelling creat() with an "e"?
> 
> Actually, that one never bothered me at all!

It still annoys me, and it lives on in O_CREAT.  Then again, I once got 
annoyed with TBL's use of "center" [sic], and promptly implemented 
"centre" as well.

> I tended to be more annoyed by _extra_ characters; e.g. the fact that 
> 'change directory' was (in standard V6) "chdir" (as opposed to just 
> plain "cd") I found far more irritating! Why make that one _five_ 
> characters, when most common commands are two?! (cc, ld, mv, rm, cp, 
> etc, etc, etc...)

Especially when the syscall itself is chdir().  Perhaps "cd" was used for 
something else at the time?

-- 
Dave Horsfall (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From norman at oclsc.org  Tue Oct 28 02:50:04 2014
From: norman at oclsc.org (Norman Wilson)
Date: Mon, 27 Oct 2014 12:50:04 -0400
Subject: [TUHS] speaking of early C compilers
Message-ID: <1414428608.27921.for-standards-violators@oclsc.org>

Noel Chiappa:

> I tended to be more annoyed by _extra_ characters; e.g. the fact that 
> 'change directory' was (in standard V6) "chdir" (as opposed to just 
> plain "cd") I found far more irritating! Why make that one _five_ 
> characters, when most common commands are two?! (cc, ld, mv, rm, cp, 
> etc, etc, etc...)

In the earliest systems, e.g. that on the PDP-7, the change-directory
command was just `ch'.

Two vague memories about the change:

-- Dennis, in one of his retrospective papers (possibly that
in the 1984 all-UNIX BLTJ issue, but I don't have it handy at
the moment) remarked about ch becoming chdir but couldn't
remember why that happened.

-- Someone else, possibly Tom Duff, once suggested to me that
in the earliest systems, the working directory was the only
thing that could be changed: no chown, no chmod.  Hence just
ch for chdir.  I don't know offhand whether that's true, but
it makes a good story.

Personally I'd rather have to type chdir and leav off th
trailing e on many other words than creat if it let me off
dealing with pieces of key system infrastructure that insist
on printing colour-change ANSI escape sequences (with, so far
as I can tell, no way to disable them) and give important files
names beginning with - so that grep pattern * produces an error.
But that happens in Linux, not UNIX.

Norman Wilson
Toronto ON


From crossd at gmail.com  Tue Oct 28 02:52:56 2014
From: crossd at gmail.com (Dan Cross)
Date: Mon, 27 Oct 2014 12:52:56 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <20141027144833.536A618C0A5@mercury.lcs.mit.edu>
References: <20141027144833.536A618C0A5@mercury.lcs.mit.edu>
Message-ID: <CAEoi9W6Qd6=M=u0G8iXRFZbqG9YesVq-hFM2+xLtpZH6Z0QTBw@mail.gmail.com>

An interesting digression....  A few years ago, the architects of MIT's
6.828 course ("Operating Systems Engineering") were unsatisfied with the
current stable of systems for teaching, so they did a re-implementation of
6th Edition in modern ANSI C (with a couple of GNU extensions for things
like assigning names to registers) targeting a multiprocessor x86.  It's an
interesting, accessible piece of work; a modern take on a classic.
http://pdos.csail.mit.edu/6.828/2014/xv6.html

        - Dan C.

On Mon, Oct 27, 2014 at 10:48 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Jason Stevens
>
>     > has anyone ever tried to compile any of the old C compilers with a
>     > 'modern' C compiler?
>     > ...
>     > How did any of this compile? How did this stuff run without
> clobbering
>     > each-other?
>
> As Ron Natalie said, the early kernels are absolutely littered with all
> sorts
> of stuff that, by today's standards, are totally unacceptable. Using a
> variable declared as an int as a pointer, using a variable declared as a
> 'foo' pointer as a 'bar' pointer, yadda-yadda.
>
> I ran (tripped, actually :-) across several of these while trying to get my
> pipe-splicing code to work. (I used Version 6 since i) I am _totally_
> familiar with it, and ii) it's what I had running.)
>
> For example, I tried to be all nice and modern and declared my pointer
> variables to be the correct type. The problem is that Unix generated unique
> ID's to sleep on with code like "sleep(p+1, PPIPE)", and the value
> generated
> by "p+1" depends on what type "p" is declared as - and if you look in
> pipe.c,
> you'll see it's often declared as an int pointer. So when _I_ wrote
> "sleep((p + 1), PPIPE)", with "p" declared as a "stuct file pointer", I got
> the wrong number.
>
> I can only speculate as to why they wrote code like this. I think part of
> it
> is, as Brantley Coile points out, historical artifacts due to the evolution
> of C from (originally) BCPL. That may have gotten them used to writing code
> in a certain way - I don't know. I also expect the modern mindset (of being
> really strict about types, and formal about coverting data from one to
> another) was still evolving back then - partly because they often didn't
> _have_ the tools (e.g. casts) to do it right. Another possibility is that
> they were using line editors, and maintaining more extensive source is a
> pain
> with an editor like that. Why write "struct file *p" wnen you can just
> write
> "*p"? And of course everyone was so space-concious back then, with those
> tiny
> disks (an RK05 pack is, after all, only 2.5MB - only slightly larger than a
> 3.5" floppy!) every byte counted.
>
>
> I have to say, though, that it's really kind of jarring to read this stuff.
>
> I have so much respect for their overall structure (the way the kernel is
> broken down into sub-systems, and the sub-systems into routines), how they
> managed to get a very powerful (by anyone's standards, even today's) OS
> into
> such a small amount of code... And the _logic_ of any given routine is
> usually quite nice, too: clear and efficient. And I love their commenting
> style - no cluttering up the code with comments unless there's something
> that
> really needs elucidation, just a short header to say, at a high level, what
> the routine does (and sometimes how and why).
>
> So when I see these funky declarations (e.g. "int *p" for something that's
> _only_ going to be used to point to a "struct file"), I just cringe - even
> though I sort of understand (see above) why it's like that. It's probably
> the
> thing I would most change, if I could.
>
>         Noel
> _______________________________________________
> 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/20141027/c06fe681/attachment.html>

From scj at yaccman.com  Tue Oct 28 03:09:21 2014
From: scj at yaccman.com (scj at yaccman.com)
Date: Mon, 27 Oct 2014 10:09:21 -0700
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
Message-ID: <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com>

Casts were invented as part of the port of Unix to the 32-bit Interdata. 
The early Unix system manuals actually printed the structure declarations
for things like directory inodes in the manual -- there were no header
files.  This meant a massive amount of work when we wanted to use
different structures for the 32-bit system.  To make matters worse, many
system calls returned -1 as an error indication, and on the Interdata
loading an integer from location -1 gave an unrecoverable machine fault
(!).  As a final blow, the lack of type checking between pointers and
structure members made it very hard to catch old code at compile time.

The cast syntax, arguably one of the ickiest parts of C syntax, was
invented in desperation -- we needed the feature, and there was no good
syntax proposal.  I blush to admit that the one Dennis chose is one that I
suggested, largely because (unlike some of the others) it was easy to
implement in Yacc.

We hacked a version of Lint to force structures whose physical declaration
locations were different to appear to be different structures, even if
they were identical.  Then, as header files were introduced, we could find
all the user-level structure declarations that were copied from the man
pages and fix them.  This was extremely valuable, and allowed a summer
intern from Princeton to convert most of the user-level programs to V7 in
a summer.

As an aside, one of the hairiest pieces of code I ever wrote was the part
of PCC that handled structure declarations--it had to understand the "old
style anything goes" syntax, but if the compiler decided that there was
some attempt to use the new semantics, it changed modes and retroactively
complained about possible type mismatches.  The code was festooned with
assertions, most of which were very short (memory being precious) -- one
or two words like "junk" or "garbage".  When compiling the V7 file system,
Ken managed to totally confound my code by declaring a structure that had
an array whose dimension was computed using a sizeof of another structure
declared inside of the sizeof.  He came to me one afternoon with a strange
expression on his face and asked "Hey Steve, what is a gummy
structure?"...



From beebe at math.utah.edu  Tue Oct 28 04:16:57 2014
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Mon, 27 Oct 2014 12:16:57 -0600 (MDT)
Subject: [TUHS] speaking of early C compilers
Message-ID: <CMM.0.95.0.1414433817.beebe@psi.math.utah.edu>

Norman Wilson writes today:

>> ...
>> -- Dennis, in one of his retrospective papers (possibly that
>> in the 1984 all-UNIX BLTJ issue, but I don't have it handy at
>> the moment) remarked about ch becoming chdir but couldn't
>> remember why that happened.
>> ...

The reference below contains on page 5 this comment by Dennis:

>> (Incidentally, chdir was spelled ch; why this was expanded when we
>>  went to the PDP-11 I don't remember)

@String{pub-PH                  = "Pren{\-}tice-Hall"}
@String{pub-PH:adr              = "Upper Saddle River, NJ 07458, USA"}

@Book{ATT:AUS86-2,
  author =       "AT{\&T}",
  key =          "ATT",
  title =        "{AT}{\&T UNIX} System Readings and Applications",
  volume =       "II",
  publisher =    pub-PH,
  address =      pub-PH:adr,
  pages =        "xii + 324",
  year =         "1986",
  ISBN =         "0-13-939845-7",
  ISBN-13 =      "978-0-13-939845-2",
  LCCN =         "QA76.76.O63 U553 1986",
  bibdate =      "Sat Oct 28 08:25:58 2000",
  bibsource =    "http://www.math.utah.edu/pub/tex/bib/master.bib",
  acknowledgement = ack-nhfb,
  xxnote =       "NB: special form AT{\&T} required to get correct
                 alpha-style labels.",
}

That chapter of that book comes from this paper:

@String{j-ATT-BELL-LAB-TECH-J   = "AT\&T Bell Laboratories Technical Journal"}

@Article{Ritchie:1984:EUT,
  author =       "Dennis M. Ritchie",
  title =        "Evolution of the {UNIX} time-sharing system",
  journal =      j-ATT-BELL-LAB-TECH-J,
  volume =       "63",
  number =       "8 part 2",
  pages =        "1577--1593",
  month =        oct,
  year =         "1984",
  CODEN =        "ABLJER",
  DOI =          "http://dx.doi.org/10.1002/j.1538-7305.1984.tb00054.x"
  ISSN =         "0748-612X",
  ISSN-L =       "0748-612X",
  bibdate =      "Fri Nov 12 09:17:39 2010",
  bibsource =    "Compendex database;
                 http://www.math.utah.edu/pub/tex/bib/bstj1980.bib",
  abstract =     "This paper presents a brief history of the early
                 development of the UNIX operating system. It
                 concentrates on the evolution of the file system, the
                 process-control mechanism, and the idea of pipelined
                 commands. Some attention is paid to social conditions
                 during the development of the system.",
  acknowledgement = ack-nhfb,
  fjournal =     "AT\&T Bell Laboratories Technical Journal",
  topic =        "computer systems programming",
}

Incidentally, on modern systems with tcsh and csh, I use both chdir
and cd; the long form does the bare directory change, whereas the
short form is an alias that also updates the shell prompt string and
the terminal window title.

I also have a personal alias "xd" (eXchange Directory) that is short
for the tcsh & bash sequence "pushd !*; cd .", allowing easy jumping
back and forth between pairs of directories, with updating of prompts
and window titles.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From ron at ronnatalie.com  Tue Oct 28 06:35:57 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 27 Oct 2014 16:35:57 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
 <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com>
Message-ID: <C9C60AE7-224E-403E-B126-4BBDE8454525@ronnatalie.com>

The original UNIX system calls returned error by setting the CARRY ("C") bit on the PSW.
It was the little wrapper to make them C callable that mapped that to -1.   Yes, there was much cleanup going to
Version 7 to get rid of using -1 with pointers in lieu of the null pointer.    The original argv list was terminated with a -1
as well.

Not that loading from *(int*) 0 was ever a good idea.   On the PDP-11, you got garbage...specifically the first few instructions of the program,
the first of which was "setd" and if you did "printf("%s\n", 0), you got something like "p&P6" printed out.

Some idiot decided in the split I/D mode (and later on the VAX) to put a ZERO at location zero.   This led to a lot more sloppy coding.
We moved to the Gould SEL machines and like your machine, the default was to get a trap on *(int*)0 as there was nothing mapped there.
We subsequently added a flag to the a.out format that changed this behavior (called "braindamaged vax compatibility mode") to map a zero
at zero for the few programs we only had in binary form and we couldn't fix their errant behavior.

> 
> The cast syntax, arguably one of the ickiest parts of C syntax, was
> invented in desperation -- we needed the feature, and there was no good
> syntax proposal.  I blush to admit that the one Dennis chose is one that I
> suggested, largely because (unlike some of the others) it was easy to
> implement in Yacc.

Yep, the problem was that the book said that a cast was to perform the same operation as assigning a value to an
invented temporary of the cast type.   This of course, didn't fully explain it in the case of some cast behavior.   C++
had to devolve the C cast into FIVE different kinds of cast to make it sane.




From clemc at ccc.com  Tue Oct 28 07:34:18 2014
From: clemc at ccc.com (Clem Cole)
Date: Mon, 27 Oct 2014 17:34:18 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <C9C60AE7-224E-403E-B126-4BBDE8454525@ronnatalie.com>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
 <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com>
 <C9C60AE7-224E-403E-B126-4BBDE8454525@ronnatalie.com>
Message-ID: <CAC20D2PvC-gN6-2Jv3TZe5FCaH6=KUfshhQ6dmsGTwqV+F7uqA@mail.gmail.com>

below

On Mon, Oct 27, 2014 at 4:35 PM, Ronald Natalie <ron at ronnatalie.com> wrote:

> The original UNIX system calls returned error by setting the CARRY ("C")
> bit on the PSW.
>
​I've forgotten that factoid.   I remember running into issues with it
because the CMU 11/40E had special CSV/CRET ​

​microcode which we could not use on the 11/34.  I've forgotten all the
hacks we had associated with the system calls.

I do remember, when we moved the CS systems' to EE 11/34 have to unwind a
whole ton of that.   When tjk brought a UNIX/TS based kernel from MH to us
we had reintegrate.   I've forgotten all the details now, I just remember
many, many hours cleaning things up


>
>
> Some idiot decided in the split I/D mode (and later on the VAX) to put a
> ZERO at location zero.   This led to a lot more sloppy coding.

When we did Magix for the the Tek Magonlia, we cheated and put zeros
there.  But as got smarter and better (like Masscomp and Stellar), we have
two versions of the C runtime - "production mode" and "development mode."
In one, we made sure there was a RO page of zeros @ location 0, so we
c​ould take the traps and try to clean things up.   If I recall correctly,
Bourne Shell and ADB were two of the worst offenders.  I also seem to
remember the original V7 library code was riddled with those bugs  ( in
particular I seem to remember that malloc/free code), which is why it was
such a problem - you own code could be clean, but you brought in a library
and got in trouble.

The other things for those days, that has not yet been brought up was the
famous "NUXI" problem.   The  PDP-11 byte swapping was idemic in the code.
  When the first ports to system that were not the same "endianess" came
about - you would find strange things in memory.

Clem

Clem





>
> >
> > The cast syntax, arguably one of the ickiest parts of C syntax, was
> > invented in desperation -- we needed the feature, and there was no good
> > syntax proposal.  I blush to admit that the one Dennis chose is one that
> I
> > suggested, largely because (unlike some of the others) it was easy to
> > implement in Yacc.
>
> Yep, the problem was that the book said that a cast was to perform the
> same operation as assigning a value to an
> invented temporary of the cast type.   This of course, didn't fully
> explain it in the case of some cast behavior.   C++
> had to devolve the C cast into FIVE different kinds of cast to make it
> sane.
>
>
> _______________________________________________
> 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/20141027/b833bad3/attachment.html>

From cowan at mercury.ccil.org  Tue Oct 28 10:16:36 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 27 Oct 2014 20:16:36 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <alpine.BSF.2.00.1410280318570.57132@aneurin.horsfall.org>
References: <20141027154810.EE17018C0A4@mercury.lcs.mit.edu>
 <alpine.BSF.2.00.1410280318570.57132@aneurin.horsfall.org>
Message-ID: <20141028001636.GL9104@mercury.ccil.org>

Dave Horsfall scripsit:

> Especially when the syscall itself is chdir().  Perhaps "cd" was used for 
> something else at the time?

On the other hand, chdir is conceptually compatible with mkdir and rmdir,
both commands and system calls.  I note that MS-DOS and successors allow
md and rd as alternatives.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Andrew Watt on Microsoft:  Never in the field of human computing has so
much been paid by so many to so few! (pace Winston Churchill)


From dave at horsfall.org  Tue Oct 28 11:09:08 2014
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 28 Oct 2014 12:09:08 +1100 (EST)
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <CAC20D2PvC-gN6-2Jv3TZe5FCaH6=KUfshhQ6dmsGTwqV+F7uqA@mail.gmail.com>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
 <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com>
 <C9C60AE7-224E-403E-B126-4BBDE8454525@ronnatalie.com>
 <CAC20D2PvC-gN6-2Jv3TZe5FCaH6=KUfshhQ6dmsGTwqV+F7uqA@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1410281157190.57132@aneurin.horsfall.org>

On Mon, 27 Oct 2014, Clem Cole wrote:

> [...] because the CMU 11/40E had special CSV/CRET microcode which we 
> could not use on the 11/34.

The 40E had microcode whilst the vanilla 40 didn't?  I thought only the 60 
was micro-programmable; I never did get around to implementing CSV/CRET on 
our 60 (Digital had a bunch of them when a contract with a publishing 
house fell through).

> The other things for those days, that has not yet been brought up was 
> the famous "NUXI" problem.   The  PDP-11 byte swapping was idemic in the 
> code.   When the first ports to system that were not the same 
> "endianess" came about - you would find strange things in memory.

Reminds me of the time when I used 2-char constants in case statements; my 
boss yelled at me.

-- 
Dave Horsfall (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

From jsteve at superglobalmegacorp.com  Tue Oct 28 11:55:00 2014
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Tue, 28 Oct 2014 09:55:00 +0800
Subject: [TUHS] speaking of early C compilers
Message-ID: <0F0B9BFC06289346B88512B91E55670D2F8A@EXCHANGE>

Wow BSD on a supercomputer!  That sounds pretty cool! 

http://web.ornl.gov/info/reports/1986/3445600639931.pdf

>From here it mentions it could scale to 16 process execution modules
(CPU's?) 

while here http://ftp.arl.mil/mike/comphist/hist.html it mentions 4 PEMs
which each could run 8 processes.

It still looks like an amazing machine.

-----Original Message-----
From: Ronald Natalie
To: Noel Chiappa
Cc: tuhs at minnie.tuhs.org
Sent: 10/27/14 11:09 PM
Subject: Re: [TUHS] speaking of early C compilers

We thought the kernels got cleaned up a lot by the time we got to the
BSD releases.    We were wrong.
When porting our variant of the 4 BSD to the Denelcor HEP supercomputer
we found a rather amusing failure.

The HEP was a 64 bit word machine but it had partial words of 16 and 32
bits.   The way it handled these was to encode the word size in the
lower bits of the address (since the bottom three weren't used in word
addressing anyhow).    If the bottom three were zero, then it was the
full word.  If it was 2 or 6, it was the left or right half word, and
1,3, 5, and 7 yielded the four quarter words.  (Byte operations used
different instructions so they directly addressed the memory).

Now Mike Muuss who did the C compiler port made sure that all the casts
did the right thing.   If you cast "int *" to "short *" it would tweak
the low order bits to make things work.    However the BSD kernel in
several places did what I call conversion by union:  essentially this:

union carbide {
     char*  c;
     short* s;
     int*     i;
} u;

u.s  = ...some valid short* ...
int* ip = u.i;

Note the compiler has no way of telling that you are storing and
retrieving through different union members and hence the low order bits
ended up reflecting the wrong word size and this led to some flamboyant
failures.     I then spent a week running around the kernel making these
void* and fixing up all the access points to properly cast the accesses
to it.

The other amusing thing was what to call the data types.     Since this
was a word machine, there was a real predisposition to call the 64 bit
sized thing "int" but that meant we needed another typename for the 32
bit thing (since we decided to leave short for the 16 bit integer).
I lobbied hard for "medium" but we ended up using int32.   Of course,
this is long before the C standards ended up reserving the _ prefix for
the implementation.

The afore mentioned fact that all the structure members shared the same
namespace in the original implementation is why the practice of using
letter prefixes on them (like b_flags and b_next etc... rather than just
flags or next) that persisted long after the C compiler got this issue
resolved.

Frankly, I really wish they'd have fixed arrays in C to be properly
functioning types at the same time they fixed structs to be proper types
as well.     Around the time of the typesetter or V7 releases we could
assign and return structs but arrays still had the silly "devolve into
pointers" behavior that persists unto this day and still causes problems
among the newbies.

_______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs


From clemc at ccc.com  Tue Oct 28 12:06:29 2014
From: clemc at ccc.com (Clem Cole)
Date: Mon, 27 Oct 2014 22:06:29 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <alpine.BSF.2.00.1410281157190.57132@aneurin.horsfall.org>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
 <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com>
 <C9C60AE7-224E-403E-B126-4BBDE8454525@ronnatalie.com>
 <CAC20D2PvC-gN6-2Jv3TZe5FCaH6=KUfshhQ6dmsGTwqV+F7uqA@mail.gmail.com>
 <alpine.BSF.2.00.1410281157190.57132@aneurin.horsfall.org>
Message-ID: <FB9C423A-9EDD-4F86-BE91-A79C9E57D216@ccc.com>

yes:  http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci

I had a 60 running v7 years later.   we also toyed with adding CSV/CRET but never did it because we got an 11/70 


> On Oct 27, 2014, at 9:09 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
>> On Mon, 27 Oct 2014, Clem Cole wrote:
>> 
>> [...] because the CMU 11/40E had special CSV/CRET microcode which we 
>> could not use on the 11/34.
> 
> The 40E had microcode whilst the vanilla 40 didn't?  I thought only the 60 
> was micro-programmable; I never did get around to implementing CSV/CRET on 
> our 60 (Digital had a bunch of them when a contract with a publishing 
> house fell through).
> 
>> The other things for those days, that has not yet been brought up was 
>> the famous "NUXI" problem.   The  PDP-11 byte swapping was idemic in the 
>> code.   When the first ports to system that were not the same 
>> "endianess" came about - you would find strange things in memory.
> 
> Reminds me of the time when I used 2-char constants in case statements; my 
> boss yelled at me.
> 
> -- 
> Dave Horsfall (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
> http://www.horsfall.org/spam.html (and check the home page whilst you're there)
> _______________________________________________
> 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/20141027/2e8be232/attachment.html>

From ron at ronnatalie.com  Tue Oct 28 22:22:10 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 28 Oct 2014 08:22:10 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <FB9C423A-9EDD-4F86-BE91-A79C9E57D216@ccc.com>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
 <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com>
 <C9C60AE7-224E-403E-B126-4BBDE8454525@ronnatalie.com>
 <CAC20D2PvC-gN6-2Jv3TZe5FCaH6=KUfshhQ6dmsGTwqV+F7uqA@mail.gmail.com>
 <alpine.BSF.2.00.1410281157190.57132@aneurin.horsfall.org>
 <FB9C423A-9EDD-4F86-BE91-A79C9E57D216@ccc.com>
Message-ID: <97AA639D-8BBF-4EE1-9E4D-5326E866B9BA@ronnatalie.com>


> On Oct 27, 2014, at 10:06 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> yes:  http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci <http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci>
> 
> I had a 60 running v7 years later.   we also toyed with adding CSV/CRET but never did it because we got an 11/70 

Problem with the 60 was it lacked Split I/D (as did the 40's).    We kind of relied on that for the kernels towards the end of the PDP-11 days,
We struggled with the lack of I/D on the 11/34 and 11/23 at BRL but finally gave up when TCP came along.   We just didn't have enough segments to handle all the overlaying needed to do.    I recycled all the non split-I/D machines into BRL GATEWAYS.

Of course, there was the famous (or imfamous) MARK instruction.   This thing was sort of a kludge, you actually pushed the instruction on the stack and then did the RTS into the stack to execute the MARK to pop the stack and jump back to the caller.      I know of no compiler (either DEC-written or UNIX) that used the silly thing.    It obviously wouldn't work in split I/D mode anyhow.   Years later while sitting in some DEC product announcement presentation, they announced the new T-11 chip (the single chip PDP-11) and the speaker said that it supported the entire instruction set with the exception of MARK.    Me and one other PDP-11 trivia guy are going "What?  No mark instruction?" in the back of the room.

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

From clemc at ccc.com  Tue Oct 28 22:42:12 2014
From: clemc at ccc.com (Clem Cole)
Date: Tue, 28 Oct 2014 08:42:12 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <97AA639D-8BBF-4EE1-9E4D-5326E866B9BA@ronnatalie.com>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
 <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com>
 <C9C60AE7-224E-403E-B126-4BBDE8454525@ronnatalie.com>
 <CAC20D2PvC-gN6-2Jv3TZe5FCaH6=KUfshhQ6dmsGTwqV+F7uqA@mail.gmail.com>
 <alpine.BSF.2.00.1410281157190.57132@aneurin.horsfall.org>
 <FB9C423A-9EDD-4F86-BE91-A79C9E57D216@ccc.com>
 <97AA639D-8BBF-4EE1-9E4D-5326E866B9BA@ronnatalie.com>
Message-ID: <CAC20D2NaZqx9mjCM67FLm8bBobG4yi+o7H8Vbibs6NLhHABUEg@mail.gmail.com>

On Tue, Oct 28, 2014 at 8:22 AM, Ronald Natalie <ron at ronnatalie.com> wrote:

> Problem with the 60 was it lacked Split I/D (as did the 40's).


​A problem was that it was 40 class processor and as you says that means it
was shared I/D (i.e. pure 16 bits) - so it lacked the 45 class 17th bit.
  The 60 has went into history as the machine that went from product to
"traditional products" faster than any other DEC product (IIRC 9 months).
I'm always surprised to hear of folks that had them because so few were
actually made.

I've forgotten the details nows, but they also had some issues when running
UNIX.  Steve Glaser and I chased those for a long time.  The 60 had the HCM
instruction sequences (halt a confuse microcode) which were some what
random although UNIX seemed to hit them.  DEC envisioned it as a commercial
machine and added decimal arithmetic to it for RSTS Cobol.​  I'm not sure
RSX was even supported on it.

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

From ron at ronnatalie.com  Tue Oct 28 22:52:47 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 28 Oct 2014 08:52:47 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <0F0B9BFC06289346B88512B91E55670D2F8A@EXCHANGE>
References: <0F0B9BFC06289346B88512B91E55670D2F8A@EXCHANGE>
Message-ID: <BBA0C370-422D-4ED4-8C12-F92F6154FB9B@ronnatalie.com>


> On Oct 27, 2014, at 9:55 PM, Jason Stevens <jsteve at superglobalmegacorp.com> wrote:
> 
> Wow BSD on a supercomputer!  That sounds pretty cool! 
> 
> http://web.ornl.gov/info/reports/1986/3445600639931.pdf
> 
> From here it mentions it could scale to 16 process execution modules
> (CPU's?) 
> 
> while here http://ftp.arl.mil/mike/comphist/hist.html it mentions 4 PEMs
> which each could run 8 processes.
> 
> It still looks like an amazing machine.

The US Army (notably the Ballistic Research Laboratory) contracted to have this computer built to solve fluid dynamics problems.    Originally, it was going to be an analog computer, then a hybrid, then Burton Smith came up with this idea for a high power multiple-instruction, multiple data stream parallel processor.   The BRL one had four PEMs each could run 8 processes in parallel but it could hardware schedule up to 256 processes.    Each data memory location had in addition to the 64 data bits semaphore bits called the "full/empty bits."   Instructions were such like "STORE AND SET FULL" and "WAIT EMPTY AND LOAD" so the hardware would suspend your thread (called processes in the hardware) until something else twiddled the bit.

Mike Muuss had pretty much ran the JHU EE computer and was my mentor all while I was there.   My junion year he had taken a job at BRL.   I worked for him as a summer intern and then consultant while Bob Jesse and I ran the JHU EE computer our senior years.   I spent a year in the defense industry when Mike said "I've got this great job for you."

Apparently nobody gave any concern to software on the HEP, and of course Mike's answer is "Let's put UNIX on it!"    He'd done this in the past with some graphics systems (11/34 based with vector processors attached) that had been delivered as remotes for the central CDC machine that never worked.    He'd also upgraded the ANTS (University of Illinois ArpaNet Terminal Server) from its dedicated software to UNIX when long leaders came out on the Arpanet making the ANTS incompatible.

Mike, Robert Miles, and I spent weeks out at the Denelcor facility developing our prototype UNIX at night (amusingly sometimes the Denelcor employees would come in and hit enter on their terminals to find our software still running... HEP, TWO, THREE, FOUR... was the login prompt...we were working for the Army after all).
Amusingly our machine was set up in a big room with tape on the floor showing where the building pillar at BRL was located.     You can see that tape in some of the publicity shots around.    Back at BRL there was tape on the floor where the HEP cabinets went around the real building pillar.

First thing Mike did was adapt the portable C compiler to generate code for the thing.    Bob wrote the assembler I believe and me the loader.    I also ported the F77 front end to PCC over (for the benefit of our eventual scientist users of the thing).      Next, I set up UNIX on the PDP-11 front end the thing had.    Mike then wrote the software that worked the "low speed bus" that you used to boot the thing up (more on this later) and the configuration of the switch network that interconnected all the PEMs and memory, etc... for high speed memory access.

Mike did the process scheduling part of the kernel while I delved into the I/O issues (my specialty at the time).    Bob aided by Doug Kingston took care of porting over most of the user mode code.    Once the thing was limping along we came to a startling discovery.   The thing, which had 32 UNIBUSes tied into it's I/O system, could only start about 10 ios a second.   That's not going to work.    I sat down at the Aberdeen Golden Corral steakhouse (our common dinner haunt) with Burton Smith and we designed a new I/O system, literally on napkins.   We built it out of spare parts, a spare memory switch node and I contributed a PDP-11/34 I had laying around for a control processor.    Now instead of feeding I/O to the front end which then talked tot he I/O system unibusses all over the low speed bus (aptly named), The PDP-11/34 running my "Little Operating System" that I used for the BRL Gateways listed to the high speed active switch for data and mirrored it to the slaved unibuses.    Essentially, the PEMs could now run the actual UNIBUS device drivers with just a slight tweak to bounce the CSR's off the PDP-11/34 with what appeared to be just a memory access.

At this point the Army had woken up to the fact that the Air Force had supercomputers and even the Navy had supercomputers, and darn it they needed supercomputers.    As a result of the fact that we were a scientific organization with heavy computer expertise, we were slated to get the first two.   The first being an X-MP which the Army used emergency authority to grab the next one out of production (which I believe was slated to go to Apple).     Meanwhile at BRL we had turned the HEP over to production use but by then it was getting a little long in the tooth speedwise.   Despite being built out of all discrete 10800 ECL chips, the more traditional processors were beating on the door.    Denelcor was well on it's way to going out of business at this point.    The one big job we ran on this was Mike's raytraced movie  "a bullet's eye view of a tank."    The HEP allowed us 60:1 compute time on the RT (Took one minute to make 1 second of movie....which was pretty darned good back then scares me when I watch video games these days).    Shortly after we did that, they shut the thing down and replaced it with the X-MP.

There weren't that many HEPs built.   In addition to ours, the University of Georgia got a 2 PEM one in exchange Georgia was to develop the software for the thing.     Messerschmidt got one, I never heard what they did with it.   The NSA got one on lease I believe and after Denelcor went out of business, I hear they shipped the whole thing back and dumped it on the loading dock of whatever hapless person happened to be occupying the last known address of Denelcor.   I've still got one of the DENELCOR H1000 name plates that were supposed to be affixed to thing but never got installed.

As for the X-MP, some of you may remember the discussions that were gone around 1985 about whether a hacker with a Cray could break the Unix crypt routine.   I put in my proposal and essentially was granted unlimited CPU time on the X-MP to try to vectorize the crypt routine and perform an analysis (I was heavy into computer security by then).   My conclusion was that the Cray vector stuff wasn't well suited to breaking DES...a faster version of the HEP would have been ideal.   Somewhere I do have a picture of me peering out of the center of the X-MP CPU.

One of the last things I did at BRL was sit on the SSB to buy the Cray 2.    I put my signature to a $25 MILLION dollar procurement.   The biggest single year purchase I made in my Reagan years in the government (I had bought several smaller UNIX machines in previous years at around $2MM a piece).



From ron at ronnatalie.com  Tue Oct 28 23:03:44 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 28 Oct 2014 09:03:44 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <CAC20D2NaZqx9mjCM67FLm8bBobG4yi+o7H8Vbibs6NLhHABUEg@mail.gmail.com>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
 <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com>
 <C9C60AE7-224E-403E-B126-4BBDE8454525@ronnatalie.com>
 <CAC20D2PvC-gN6-2Jv3TZe5FCaH6=KUfshhQ6dmsGTwqV+F7uqA@mail.gmail.com>
 <alpine.BSF.2.00.1410281157190.57132@aneurin.horsfall.org>
 <FB9C423A-9EDD-4F86-BE91-A79C9E57D216@ccc.com>
 <97AA639D-8BBF-4EE1-9E4D-5326E866B9BA@ronnatalie.com>
 <CAC20D2NaZqx9mjCM67FLm8bBobG4yi+o7H8Vbibs6NLhHABUEg@mail.gmail.com>
Message-ID: <2A352307-DB5B-4434-B5E3-C6747CD71AD4@ronnatalie.com>

> 
> I've forgotten the details nows, but they also had some issues when running UNIX.  Steve Glaser and I chased those for a long time.  The 60 had the HCM instruction sequences (halt a confuse microcode) which were some what random although UNIX seemed to hit them.  DEC envisioned it as a commercial machine and added decimal arithmetic to it for RSTS Cobol.​  I'm not sure RSX was even supported on it.
> 

Ah, RSTS...the Really Sh-ty Timesharing System.     An amusing UNIX story on that one.   Hopkins EE department was a RSTS shop running primarily the Basic Plus interpreter which was the core of some classroom courses (especially the Freshman course:  Modeling and Simulation).   When the the guys found out about UNIX they lobbied the department faculty to switch to UNIX and they were told they could provided that Basic Plus continued to run.

Amusingly, if you read the DEC processor handbook, it says the TRAP instruction is designed to invoke system calls.    UNIX did this of course.   Amuslingly, the DEC operating systems, including RSTS, used EMT to invoke system calls.   The book says this was put there to allow emulating other OSs.    Well this made it relatively easy.
Basic Plus was calling EMT so they just had to catch the EMT traps and emulate the few RSTS calls that Basic Plus needed to make.    JHU/UNIX was born.   It was a Version 6 UNIX (which original system administrator John Day decided that 6.06 was a great version number and he kept it through many software updates).    Mike took over and stared advancing the numbers again.

We also had an 11/40 (lacking memory management) running miniUnix.   They also ran miniUNIX in the Biomedical engineering lab on an LSI-11/03.    I upgraded that lab to 11/23 running full up UNIX later on.

You may recall that the UID was stored in a (unsigned) char in those days.   This was problematic when you had a student body of a couple of thousand.    The solution was a kludge:  "JHU Ownership."     If your GID was over 200, both your UID and GID were considered when computing identity.    Obviously, newgrp was disabled for those accounts and I spent many an hour trying various combinations of setuid/gid bits and setuid/gid calls to see if there were any way to abuse that.


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

From bqt at update.uu.se  Wed Oct 29 03:46:44 2014
From: bqt at update.uu.se (Johnny Billquist)
Date: Tue, 28 Oct 2014 18:46:44 +0100
Subject: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers)
In-Reply-To: <mailman.295.1414500157.3356.tuhs@minnie.tuhs.org>
References: <mailman.295.1414500157.3356.tuhs@minnie.tuhs.org>
Message-ID: <544FD684.6090001@update.uu.se>

On 2014-10-28 13:42, Clem Cole <clemc at ccc.com> wrote:

> yes:
> http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci

Cool. I knew CMU did a lot of things with 11/40 machines. I didn't know 
they had modified them to be able to write their own microcode, but 
thinking about it, it should have been obvious. As they did 
multiprocessor systems based on the 11/40, they would have had to modify 
the microcode anyway.

> I had a 60 running v7 years later. we also toyed with adding CSV/CRET
> but never did it because we got an 11/70
>> >On Oct 27, 2014, at 9:09 PM, Dave Horsfall<dave at horsfall.org>  wrote:
>> >
>>> >>On Mon, 27 Oct 2014, Clem Cole wrote:
>>> >>
>>> >>[...] because the CMU 11/40E had special CSV/CRET microcode which we
>>> >>could not use on the 11/34.
>> >
>> >The 40E had microcode whilst the vanilla 40 didn't?  I thought only the 60
>> >was micro-programmable; I never did get around to implementing CSV/CRET on
>> >our 60 (Digital had a bunch of them when a contract with a publishing
>> >house fell through).

DEC actually made two PDP-11s that were micro programmable. The 11/60 
and the 11/03 (if I remember right). DEC never had microprogramming for 
the 11/40, but obviously CMU did that.

Ronald Natalie<ron at ronnatalie.com> wrote:

>> >On Oct 27, 2014, at 10:06 PM, Clem Cole<clemc at ccc.com>  wrote:
>> >
>> >yes:http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci  <http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci>
>> >
>> >I had a 60 running v7 years later.   we also toyed with adding CSV/CRET but never did it because we got an 11/70
> Problem with the 60 was it lacked Split I/D (as did the 40's).    We kind of relied on that for the kernels towards the end of the PDP-11 days,
> We struggled with the lack of I/D on the 11/34 and 11/23 at BRL but finally gave up when TCP came along.   We just didn't have enough segments to handle all the overlaying needed to do.    I recycled all the non split-I/D machines into BRL GATEWAYS.
>
> Of course, there was the famous (or imfamous) MARK instruction.   This thing was sort of a kludge, you actually pushed the instruction on the stack and then did the RTS into the stack to execute the MARK to pop the stack and jump back to the caller.      I know of no compiler (either DEC-written or UNIX) that used the silly thing.    It obviously wouldn't work in split I/D mode anyhow.   Years later while sitting in some DEC product announcement presentation, they announced the new T-11 chip (the single chip PDP-11) and the speaker said that it supported the entire instruction set with the exception of MARK.    Me and one other PDP-11 trivia guy are going "What?  No mark instruction?" in the back of the room.

Yurg... The MARK instruction was just silly. I never knew of anyone who 
actually used it. Rumors have it that DEC just came up with it to be 
able to extend some patent for a few more years related to the whole 
PDP-11 architecture.

Clem Cole<clemc at ccc.com> wrote:

>> >Problem with the 60 was it lacked Split I/D (as did the 40's).
>
> ?A problem was that it was 40 class processor and as you says that means it
> was shared I/D (i.e. pure 16 bits) - so it lacked the 45 class 17th bit.
>    The 60 has went into history as the machine that went from product to
> "traditional products" faster than any other DEC product (IIRC 9 months).
> I'm always surprised to hear of folks that had them because so few were
> actually made.

I picked up four 11/60 machines from a place in the late 80s. I still 
have a complete set of CPU cards, but threw the last machine away about 
10 years ago.

> I've forgotten the details nows, but they also had some issues when running
> UNIX.  Steve Glaser and I chased those for a long time.  The 60 had the HCM
> instruction sequences (halt a confuse microcode) which were some what
> random although UNIX seemed to hit them.  DEC envisioned it as a commercial
> machine and added decimal arithmetic to it for RSTS Cobol.?  I'm not sure
> RSX was even supported on it.

RSX-11M supports it. So do RSTS/E and RT-11. RSX-11M-PLUS obviously 
don't, since it have a minimal requirement of 22-bit addressing.

The microcode specific instructions are interesting. But in general 
shouldn't crash things, but of course kernel is a different story. :-)

	Johnny



From ron at ronnatalie.com  Wed Oct 29 03:57:17 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 28 Oct 2014 13:57:17 -0400
Subject: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers)
In-Reply-To: <544FD684.6090001@update.uu.se>
References: <mailman.295.1414500157.3356.tuhs@minnie.tuhs.org>
 <544FD684.6090001@update.uu.se>
Message-ID: <873F0C73-0DD5-4138-9B23-DC060DCAE20D@ronnatalie.com>

> 
> I picked up four 11/60 machines from a place in the late 80s. I still have a complete set of CPU cards, but threw the last machine away about 10 years ago.

Chuckle.   My wife would kill me.   I finally got rid of the ASR-37 (you know a real UNIX teletype complete with a big NEWLINE key and able to interpret those ESC-8 and ESC-9 things that nroff outputs by default) decades ago (RS tells me he left it blocking someone's car in at Sprint or something, I disavow all knowledge of it).

While at BRL I was the king of the surplus PDP-11.    Any time a PDP-11 came up surplus I recycled it into internet routers.   Sometimes I took the older machines for either their RK05 or RL02 drives, or just the racks.    I got a call up from surplus people asking me about this $100,000 worth of computer equipment I had turned in and needed to come over and identify. 

What $100,000 worth of computer equipment?

It says here "One PDP-11/40 and accessories."

That thing is 16 years old.   That's the price the government paid for it then.   Do you know how much a 16 year old computer is worth?
(especially one that had been stripped of just about everything but the CPU box itself).




From ron at ronnatalie.com  Wed Oct 29 03:58:03 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 28 Oct 2014 13:58:03 -0400
Subject: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers)
In-Reply-To: <544FD684.6090001@update.uu.se>
References: <mailman.295.1414500157.3356.tuhs@minnie.tuhs.org>
 <544FD684.6090001@update.uu.se>
Message-ID: <0C36721E-ADCE-4119-B157-1A3F464CF8B9@ronnatalie.com>

Found a manual for the WCS for the 11/03...http://bitsavers.trailing-edge.com/pdf/dec/pdp11/1103/EK-KUV11-TM_LSI11_WCS.pdf
Amusing reading



From clemc at ccc.com  Wed Oct 29 04:22:00 2014
From: clemc at ccc.com (Clem Cole)
Date: Tue, 28 Oct 2014 14:22:00 -0400
Subject: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers)
In-Reply-To: <544FD684.6090001@update.uu.se>
References: <mailman.295.1414500157.3356.tuhs@minnie.tuhs.org>
 <544FD684.6090001@update.uu.se>
Message-ID: <CAC20D2NRL7wUpWKpUUN_7w693PLUXefwbR4tRad-HBT72+_iZw@mail.gmail.com>

On Tue, Oct 28, 2014 at 1:46 PM, Johnny Billquist <bqt at update.uu.se> wrote:

> DEC actually made two PDP-11s that were micro programmable. The 11/60 and
> the 11/03 (if I remember right). DEC never had microprogramming for the
> 11/40, but obviously CMU did that.


C.mmp was 11/40E's and C.m* was LSI/11's and both needed them for the
capabilities support.  I never really got to mess with the WCS units -
although we learned about them (along with ISPL/ISPS in courses), I did
hack on the OS and in user space of both systems - which was a wonderful
experience. It was how I learned about capabilities which I still have soft
spot.   But around that time, I was also introduced to this strange new
system language and system and started to get paid better as a programmer
for a group using it.   I never went back ;-)

As an a side, Wulf's dedication in the Hydra (C.mmp's OS) Book:  "To the
designers and builders of *real* programming systems."

BTW: the 780 & 750 had ustore but it was not user documented and the tools
were internal.   Paul Guilbo wrote much of both and later would write the
uCode for the Masscomp FPU and APU.   Paul was bitching about the great
tool(s) they had had at DEC, so one weekend two of us on the SW team got
sick of his bitching a couple of us hacked up a uCode assembler in the same
key in Yacc/lex/C (not BLISS ;-).

Later when a couple of ex-PRISM guys started a firm in California there was
an underground trade (i.e. no management knew about it).  We were both
using the same EE/CAD systems and we traded them some libraries for our
uCode tools.

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

From ron at ronnatalie.com  Wed Oct 29 04:39:33 2014
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 28 Oct 2014 14:39:33 -0400
Subject: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers)
In-Reply-To: <CAC20D2NRL7wUpWKpUUN_7w693PLUXefwbR4tRad-HBT72+_iZw@mail.gmail.com>
References: <mailman.295.1414500157.3356.tuhs@minnie.tuhs.org>
 <544FD684.6090001@update.uu.se>
 <CAC20D2NRL7wUpWKpUUN_7w693PLUXefwbR4tRad-HBT72+_iZw@mail.gmail.com>
Message-ID: <F22A537B-ED19-45DB-BA18-D3E43FD4445B@ronnatalie.com>


> On Oct 28, 2014, at 2:22 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> BTW: the 780 & 750 had ustore but it was not user documented and the tools were internal.   Paul Guilbo wrote much of both and later would write the uCode for the Masscomp FPU and APU.   Paul was bitching about the great tool(s) they had had at DEC, so one weekend two of us on the SW team got sick of his bitching a couple of us hacked up a uCode assembler in the same key in Yacc/lex/C (not BLISS ;-).

Apparently they were at least advertised as available for the 780.
http://h18000.www1.hp.com/info/SP2509/SP2509PF.PDF


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

From clemc at ccc.com  Wed Oct 29 05:03:53 2014
From: clemc at ccc.com (Clem Cole)
Date: Tue, 28 Oct 2014 15:03:53 -0400
Subject: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers)
In-Reply-To: <F22A537B-ED19-45DB-BA18-D3E43FD4445B@ronnatalie.com>
References: <mailman.295.1414500157.3356.tuhs@minnie.tuhs.org>
 <544FD684.6090001@update.uu.se>
 <CAC20D2NRL7wUpWKpUUN_7w693PLUXefwbR4tRad-HBT72+_iZw@mail.gmail.com>
 <F22A537B-ED19-45DB-BA18-D3E43FD4445B@ronnatalie.com>
Message-ID: <CAC20D2OwsV2uBbwS+7Jh7hC=bbMHvNbsfvM9qtY2hLKR=n3vpA@mail.gmail.com>

That SPF shows a date of 1987.   Masscomp was '83 for the FP and 84 for the
APU and I know we could not get them - but then again KO was mad at us.  At
that point we had more of the 780 HW guys then DEC did, plus a bunch of
ex-VMS and ex-LDP folks.   The nasty-gram letter from Ken was framed and
hung out the office of one of the VPs (I wonder if Palmer of one of the
other Masscomp pack rats still has a picture of it).

I know we tried to get it for our Vax, and it was a clear - no way.

On Tue, Oct 28, 2014 at 2:39 PM, Ronald Natalie <ron at ronnatalie.com> wrote:

>
> On Oct 28, 2014, at 2:22 PM, Clem Cole <clemc at ccc.com> wrote:
>
>
> BTW: the 780 & 750 had ustore but it was not user documented and the tools
> were internal.   Paul Guilbo wrote much of both and later would write the
> uCode for the Masscomp FPU and APU.   Paul was bitching about the great
> tool(s) they had had at DEC, so one weekend two of us on the SW team got
> sick of his bitching a couple of us hacked up a uCode assembler in the same
> key in Yacc/lex/C (not BLISS ;-).
>
>
> Apparently they were at least advertised as available for the 780.
> http://h18000.www1.hp.com/info/SP2509/SP2509PF.PDF
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141028/8835e1ca/attachment.html>

From cowan at mercury.ccil.org  Wed Oct 29 08:02:50 2014
From: cowan at mercury.ccil.org (John Cowan)
Date: Tue, 28 Oct 2014 18:02:50 -0400
Subject: [TUHS] speaking of early C compilers
In-Reply-To: <2A352307-DB5B-4434-B5E3-C6747CD71AD4@ronnatalie.com>
References: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>
 <2c9c14d6fd7d2e98ae0bc98d7f593ff9.squirrel@webmail.yaccman.com>
 <C9C60AE7-224E-403E-B126-4BBDE8454525@ronnatalie.com>
 <CAC20D2PvC-gN6-2Jv3TZe5FCaH6=KUfshhQ6dmsGTwqV+F7uqA@mail.gmail.com>
 <alpine.BSF.2.00.1410281157190.57132@aneurin.horsfall.org>
 <FB9C423A-9EDD-4F86-BE91-A79C9E57D216@ccc.com>
 <97AA639D-8BBF-4EE1-9E4D-5326E866B9BA@ronnatalie.com>
 <CAC20D2NaZqx9mjCM67FLm8bBobG4yi+o7H8Vbibs6NLhHABUEg@mail.gmail.com>
 <2A352307-DB5B-4434-B5E3-C6747CD71AD4@ronnatalie.com>
Message-ID: <20141028220250.GC3885@mercury.ccil.org>

Ronald Natalie scripsit:

> Amusingly, if you read the DEC processor handbook, it says the TRAP
> instruction is designed to invoke system calls.    UNIX did this
> of course.   Amuslingly, the DEC operating systems, including RSTS,
> used EMT to invoke system calls.   The book says this was put there
> to allow emulating other OSs.    Well this made it relatively easy.

Unless I have utterly forgotten, EMT was to be used by DEC and TRAP
by users.  Since Bell Labs was a user, they used TRAP (I asked ken --
I think it was ken, definitely not Ken -- about this).  Of course,
DEC didn't anticipate that any user would write an operating system!

On RSTS/E as opposed to RSTS, both EMT and TRAP went to the user
executive.  To reach the kernel, you did EMT 377 followed by another
EMT, but EMT 377; EMT 377 was vectored back to the user as an EMT 377.
That's what allowed RSTS/E to host other OSes that used EMT.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Nobody expects the RESTifarian Inquisition!  Our chief weapon is
surprise ... surprise and tedium  ... tedium and surprise ....
Our two weapons are tedium and surprise ... and ruthless disregard
for unpleasant facts....  Our three weapons are tedium, surprise, and
ruthless disregard ... and an almost fanatical devotion to Roy Fielding....


From bqt at update.uu.se  Wed Oct 29 08:48:10 2014
From: bqt at update.uu.se (Johnny Billquist)
Date: Tue, 28 Oct 2014 23:48:10 +0100
Subject: [TUHS] 11/40E and 11/60
In-Reply-To: <CAC20D2NRL7wUpWKpUUN_7w693PLUXefwbR4tRad-HBT72+_iZw@mail.gmail.com>
References: <mailman.295.1414500157.3356.tuhs@minnie.tuhs.org>
 <544FD684.6090001@update.uu.se>
 <CAC20D2NRL7wUpWKpUUN_7w693PLUXefwbR4tRad-HBT72+_iZw@mail.gmail.com>
Message-ID: <54501D2A.30607@update.uu.se>

On 2014-10-28 19:22, Clem Cole wrote:
>
> On Tue, Oct 28, 2014 at 1:46 PM, Johnny Billquist <bqt at update.uu.se
> <mailto:bqt at update.uu.se>> wrote:
>
>     DEC actually made two PDP-11s that were micro programmable. The
>     11/60 and the 11/03 (if I remember right). DEC never had
>     microprogramming for the 11/40, but obviously CMU did that.
>
>
> C.mmp was 11/40E's and C.m* was LSI/11's and both needed them for the
> capabilities support.  I never really got to mess with the WCS units -
> although we learned about them (along with ISPL/ISPS in courses), I did
> hack on the OS and in user space of both systems - which was a wonderful
> experience. It was how I learned about capabilities which I still have
> soft spot.   But around that time, I was also introduced to this strange
> new system language and system and started to get paid better as a
> programmer for a group using it.   I never went back ;-)

Yeah, it was the C.mmp I was thinking of when I said that CMU obviously 
had to have been playing at this.

> BTW: the 780 & 750 had ustore but it was not user documented and the
> tools were internal.   Paul Guilbo wrote much of both and later would
> write the uCode for the Masscomp FPU and APU.   Paul was bitching about
> the great tool(s) they had had at DEC, so one weekend two of us on the
> SW team got sick of his bitching a couple of us hacked up a uCode
> assembler in the same key in Yacc/lex/C (not BLISS ;-).

:-)
As someone else mentioned, the 11/780 had a separate product for user 
written microcode. I think it actually also included a different board 
for the CPU, with more memory for the microcode. So it must have been 
documented externally somehow, somewhere.

The 11/750 was not documented for external use, I think. However, I have 
some vague memory of seeing something about user written microcode for 
it as well.
And of course, Ultrix had a microcode patch for the 11/750, which fixed 
some bugs in a couple of instructions. This microcode patch is still 
included in the NetBSD/vax distribution. :-)

The 86x0 machines always loaded microcode from the FE RL02, and there is 
documentation on that microcode available today, although it was DEC 
internal at the time. And I still happen to have access to an 8650. But 
no time to actually try and play with the microcode. And that machine is 
rather complex as well. That's when things started to get pipelined and 
other stuff that makes things much more difficult to fool around with.

	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  Wed Oct 29 08:54:43 2014
From: bqt at update.uu.se (Johnny Billquist)
Date: Tue, 28 Oct 2014 23:54:43 +0100
Subject: [TUHS] 11/40E and 11/60
In-Reply-To: <CAC20D2OwsV2uBbwS+7Jh7hC=bbMHvNbsfvM9qtY2hLKR=n3vpA@mail.gmail.com>
References: <mailman.295.1414500157.3356.tuhs@minnie.tuhs.org>
 <544FD684.6090001@update.uu.se>
 <CAC20D2NRL7wUpWKpUUN_7w693PLUXefwbR4tRad-HBT72+_iZw@mail.gmail.com>
 <F22A537B-ED19-45DB-BA18-D3E43FD4445B@ronnatalie.com>
 <CAC20D2OwsV2uBbwS+7Jh7hC=bbMHvNbsfvM9qtY2hLKR=n3vpA@mail.gmail.com>
Message-ID: <54501EB3.5030205@update.uu.se>

On 2014-10-28 20:03, Clem Cole wrote:
> That SPF shows a date of 1987.   Masscomp was '83 for the FP and 84 for
> the APU and I know we could not get them - but then again KO was mad at
> us.  At that point we had more of the 780 HW guys then DEC did, plus a
> bunch of ex-VMS and ex-LDP folks.   The nasty-gram letter from Ken was
> framed and hung out the office of one of the VPs (I wonder if Palmer of
> one of the other Masscomp pack rats still has a picture of it).
>
> I know we tried to get it for our Vax, and it was a clear - no way.

That SPD is from 1987, true. But that is for version 3.0...
I know that the user microcode option for the 11/780 is really much 
older than that. But I wonder how many actually ever purchased it?

	Johnny

>
> On Tue, Oct 28, 2014 at 2:39 PM, Ronald Natalie <ron at ronnatalie.com
> <mailto:ron at ronnatalie.com>> wrote:
>
>
>>     On Oct 28, 2014, at 2:22 PM, Clem Cole <clemc at ccc.com
>>     <mailto:clemc at ccc.com>> wrote:
>>
>>
>>     BTW: the 780 & 750 had ustore but it was not user documented and
>>     the tools were internal.   Paul Guilbo wrote much of both and
>>     later would write the uCode for the Masscomp FPU and APU.   Paul
>>     was bitching about the great tool(s) they had had at DEC, so one
>>     weekend two of us on the SW team got sick of his bitching a couple
>>     of us hacked up a uCode assembler in the same key in Yacc/lex/C
>>     (not BLISS ;-).
>
>     Apparently they were at least advertised as available for the 780.
>     http://h18000.www1.hp.com/info/SP2509/SP2509PF.PDF
>
>
>


-- 
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


