From jones@cs.uiowa.edu Fri Oct  1 13:21:03 EDT 1993
Article: 474 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8,comp.sys.tandy
Path: news.columbia.edu!news.media.mit.edu!bloom-beacon.mit.edu!usc!cs.utexas.edu!uwm.edu!vixen.cso.uiuc.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@cs.uiowa.edu
Subject: Re: Warehouse load of antique
Sender: news@news.uiowa.edu (News)
Message-ID: <1993Oct1.144010.9118@news.uiowa.edu>
Date: Fri, 1 Oct 1993 14:40:10 GMT
References: <JOLLIE.93Sep30170354@hopper.cs.uiowa.edu>
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: University of Iowa, Iowa City, IA, USA
Lines: 54
Xref: news.columbia.edu alt.folklore.computers:52566 alt.sys.pdp8:474 comp.sys.tandy:5183

Here's an update on the antique collection.  The pile has been picked
over, but much of the stuff remains.

>  1) A Charles River Universe 68 system
	This system has found a good home, in Pittsburgh, filling
	a longstanding hole in a collection.

>  2) A PDP-11/04 with a TFI disk controller
	This system is still available.  TFI is a Cedar Rapids Iowa
	company that apparently built the glue to hang off-brand
	peripherals onto PDP-11 systems and then sold them to
	small businesses.  The disk controller is all wire-wrap
	construction, with socketed IC chips.

>  3) A TRS 80 Model II system, with printer on a stand, etc.
	Still available.

>  4) An IBM 5224 line printer and 2 IBM 5251 data display terminals.
	Still available -- we're tracking down the local System 36
	consultant who knows all the local System 36 users.

>  5) A Singer Programmatic Flexowriter 2201 and Selectadata box.
	I took it.  You should have seen the look on my wife's
	face when I brought it home.  And getting the thing out
	of my van was murder.  Flexowriters weigh a ton!
	I'll see if I can get it working, but I'll gladly send it
	to a museum, if it's wanted and if I can figure out how
	to get it there for less than an arm and a leg!

>  6) Two Burroughs L6000 accounting machines.
	Still available.  These are desk sized monsters, and they're
	very likely to be valuable additions to a museum collection,
	as illustrations of the transistion in small business data
	processing from dedicated accounting machines to general
	purpose computers.

>  7) An NCR electromechanical accounting machine.
	Still available, still a nice museum piece.

>  8) A pile of old power supplies, dumb terminals, and electronics scrap.
	Greatly diminished.  Most of the working terminals are gone.

9) In going through the pile of stuff last night, we found another printer,
	a nice IBM PC compatable dot-matrix printer with a stock of ribbons.

10) There's also a Singer Fridden accounting machine, comparable to the
	NCR machine (item 7).

Jeff Ollie and I have both volunteered to help find homes for this stuff.
Contact him at jollie@cs.uiowa.edu, or contact me, or call the owner of
the stuff (Paul McKeen, (319)-337-2035).

					Doug Jones
					jones@cs.uiowa.edu


From jondich@mathcs.carleton.edu Sun Oct  3 11:34:22 EDT 1993
Article: 475 of alt.sys.pdp8
Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!headwall.Stanford.EDU!rutgers!noao!CS.Arizona.EDU!organpipe.uug.arizona.edu!galileo.physics.arizona.edu!news
From: jondich@mathcs.carleton.edu (Jeff Ondich)
Newsgroups: alt.sys.pdp8
Subject: pdp8e documentation wanted
Message-ID: <1993Oct1.174551.27601@galileo.physics.arizona.edu>
Date: 1 Oct 93 17:45:51 GMT
Sender: news@galileo.physics.arizona.edu (C-news)
Organization: University of Arizona Physics Department
Lines: 16


I would like to get any PDP8E documentation I can find.  In particular, I  
am interested in circuit diagrams.  If you have any suggestions on how to  
proceed, I'd appreciate hearing them.  If you have documentation you want  
to unload, I'd like to hear that, too.

By the way, I called DEC, and they want $2000 for the circuit diagrams.   
(Really--that's three zeros after the two.)

Thanks,

Jeff Ondich
Carleton College
Northfield, MN
(507) 663-4364
jondich@mathcs.carleton.edu


From lasner@watsun.cc.columbia.edu Sun Oct  3 11:38:18 EDT 1993
Article: 476 of alt.sys.pdp8
Path: news.columbia.edu!watsun.cc.columbia.edu!lasner
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: pdp8e documentation wanted
Date: 3 Oct 1993 15:34:00 GMT
Organization: Columbia University
Lines: 89
Message-ID: <28mrd8$8kc@apakabar.cc.columbia.edu>
References: <1993Oct1.174551.27601@galileo.physics.arizona.edu>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <1993Oct1.174551.27601@galileo.physics.arizona.edu>,
Jeff Ondich <jondich@mathcs.carleton.edu> wrote:
>
>I would like to get any PDP8E documentation I can find.  In particular, I  
>am interested in circuit diagrams.  If you have any suggestions on how to  
>proceed, I'd appreciate hearing them.  If you have documentation you want  
>to unload, I'd like to hear that, too.
>
>By the way, I called DEC, and they want $2000 for the circuit diagrams.   
>(Really--that's three zeros after the two.)

DEC has recently changed its policy about much documentation.  Perhaps you can
indicate which part of DEC had the nerve to quote you a price based on the
arbitrary spiraling of old catalog prices, and doesn't want to listen to the
rest of the company's ideas about good will, etc.  By directing this 
unreasonable action to the proper channels, perhaps we can get the stuff
released, etc.  DEC is still so big a company that the standard lack of
communications applies.

Once I had to point out a related problem:

DECtape guide parts had a certain price, and there was a general policy of
inching up all prices on parts.  It was unreasonable, but at least it was
sort-of gradual.  This particular part then was subject to a typo, in part
because of confusing its price/quantity with something else apparently
sold in quantities of 10.  In any case, the price of this part was mistakenly
changed.  The part in question has a left and a right.  For years the price
was the same, and the unaffected one was merely subjected to the price creep
all generally were, etc., but the other one was now suddenly 8 times the 
price of the other!

I had numerous conversations with a whole bunch of DEC employees.  Some had
"creative" answers such as their "proof" that it was so much more difficult
to manufacture the left one than the right one.  (The fact that I could
produce the entire parts price history for both items going back for 10 years
showing perfect tracking until a specific typo didn't phase them.)

Some had noise like "they agreed it was wrong but couldn't do anything about
it" or equivalent.  The one I finally dealt with said that he had the ability
to make a "special" order so that I could get it at the intended price, but
that this was a "one-time deal" and to not expect it to apply to any other
aspects of the pricing book, even if it was a similar mistake.  And further
he wouldn't even try to have the price book corrected, etc.

As is predictable, the type price stuck, and was then subjected to many
iterations of being jacked up, often at unconscionable increments, although
no worse than any other comparable part.  (All of this is to harass you into
buying new equipment.)  So, the last time I saw both parts, one was priced
by thieves, and the other was highway robbery, about 10 and 80 times what
they were worth.

Obviously, this is the work of a department out of control, but within DEC
this sort of thing happens.  This latest problem with prints prices may
represent an analogous situation.

In any case, DEC's recent attitude is that the old stuff is non-commercial
and groups like ours should have access to them.  $2000 price tags on what
was a $30 set of prints is not exactly access in my book!  So, perhaps by
calling all of this sort of thing out to upper suits could get the stuff
out of there, perhaps for free!

I nominate Doug Jones for this one, since he would then be able to distribute
copies of it to all of us who desire it, etc.

I have here in my hands right now what in fact the poster may be looking for:

This is revision AE of the PDP-8/e print set from 9/75.  Unlike most of the
prior prints, this is not in an orange cover, but rather has a blue cover 
without the peek-a-boo hole in it (that allowed you to see what print set
it was, yet the front cover is generic).  The first printset page has the
appropriate printing in the upper-right corner so it could be used with an
orange cover sheet.  Over the blue page is a clear plastic sheet to protect
it and the whole thing is held together by a plastic 3-hole u-shaped
thingie that is essentially a binder spine.  It is white, and has the
Digital logo on the edge.  (The previous orange types were usually held with
only one large staple, which often ripped out, so this is clearly an
improvement.  I have seen other prints of this type, such as RX02, but this
is the only 8/e print set I've seen done this way.)

If it's carefully taken apart and restored by someone with a long-page
copier (possibly reduced?  It's likely these are in turn already reduced
down from the typical large drafting prints DEC used to actually distribute
as loose sheets.  I actually have a couple of those, but only of very old
vintage cards, etc.) then it could be distributed.

So, Doug, how's your connections on getting print sets reprinted with
permission?

cjl


From ard@siva.bris.ac.uk Sun Oct  3 23:21:20 EDT 1993
Article: 477 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!pipex!warwick!bsmail!siva.bris.ac.uk!ard
From: ard@siva.bris.ac.uk (PDP11 Hacker .....)
Subject: Re: Qbus RL02 controller
Message-ID: <3OCT199318474695@siva.bris.ac.uk>
News-Software: VAX/VMS VNEWS 1.41    
Sender: usenet@info.bris.ac.uk (Usenet news owner)
Nntp-Posting-Host: siva.bris.ac.uk
Organization: University of Bristol Physics Department
References: <1993Sep30.001355.3478965@sue.cc.uregina.ca>
Date: Sun, 3 Oct 1993 17:47:00 GMT
Lines: 28

In article <1993Sep30.001355.3478965@sue.cc.uregina.ca>, john@mercury.cs.uregina.ca (John Rosloot) writes...
>     Does anyone know of companies (preferably in Canada) which repair old
>DEC boards? I have an M8013 RLV11 Disk Control Board which gives solid fault
>lights on all my RL02 drives. Also, is there some fatal incompatibility between
>this board and the Micro PDP 11/73 bus? This board first failed when I tried
>it in the '73. It had been running fine in an 11/23 beforehand. Of course, it
>may have been killed in transit by static or something; I wasn't particularly
>careful with it. I have transferred other devices between the '23 and '73 (a
>QD01 disk controller and an RX02 floppy controller) without problems. Still,
>I want to be sure that I don't get the board repaired only to have it blow up
>when I put it in the '73 again. Any help?

Sorry to post some '11 stuff to the PDP8 newsgroup, but...
The RLV11 is a 2-board set. I have one in my MINC. The boards are M8013 and
M8014 I think, and it matters which order they go in the backplane. Also, the
backplane MUST be one with CD interconnect, not one that will take
twice-as-many dual-height boards. I seem to remember that the 11/73 backplane
does not have CD interconnect.
fault-lights at power-on normally mean that the drives do not have a clock
signal. This comes from the controller. I think that both boards have to be
fitted correctly and the cable the right way round to get the clock signal.
BTW, no matter what other netters tell you, the RLV11 can control RL02's. Mine
does.

> 
>John, no sig
-tony



From david.turner@asacomp.com Sun Oct  3 23:21:44 EDT 1993
Article: 478 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Subject: EMULATOR WANTED
From: david.turner@asacomp.com (David Turner)
Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!sgiblab!barrnet.net!infoserv!asacomp!david.turner
Distribution: world
Message-ID: <35.121.2946.0NCD185D@asacomp.com>
Date: Fri,  1 Oct 93 22:35:00 -0500
Organization: ASA CompuHelp, Inc.
Lines: 15

I read that there is several PDP-8 emulators around. I am looking for
one that will run on an IBM Clone. I don't need it to do any fancy I/O
work (ie real peripherals), but just want one that will run standard
PDP-8/E software and any I/O would come and go to files on the hard
disk (except for screen I/O). Ideally, there would be certain filenames
or directories on the drive that would be for the different types of I/O
devices... does that make sense? :-) I just want it to practice writing
some PDP-8 code.

In any case, is there an emulator that someone could recommend to me?

Regards,
** David Turner **
---
 þ QMPro 1.0 14-3452 þ ¯ìûÔÔh·¤ ŽCþhanks for hanging up, dear.


From lasner@watsun.cc.columbia.edu Mon Oct  4 10:35:24 EDT 1993
Article: 479 of alt.sys.pdp8
Path: news.columbia.edu!watsun.cc.columbia.edu!lasner
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: EMULATOR WANTED
Date: 4 Oct 1993 03:59:53 GMT
Organization: Columbia University
Lines: 122
Message-ID: <28o73p$3f5@apakabar.cc.columbia.edu>
References: <35.121.2946.0NCD185D@asacomp.com>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <35.121.2946.0NCD185D@asacomp.com>,
David Turner <david.turner@asacomp.com> wrote:
>I read that there is several PDP-8 emulators around. I am looking for
>one that will run on an IBM Clone. I don't need it to do any fancy I/O
>work (ie real peripherals), but just want one that will run standard
>PDP-8/E software and any I/O would come and go to files on the hard
>disk (except for screen I/O). Ideally, there would be certain filenames
>or directories on the drive that would be for the different types of I/O
>devices... does that make sense? :-) I just want it to practice writing
>some PDP-8 code.

Without having a *real* emulator, you don't get the utilities to actually
run the code, or even write it.  There really isn't too much available for a
complete development environment for the -8 on other machines available.

You would have to write a comprehensive assembler (Doug Jones seems to be
the latest to attempt this;  over the years many have started, and to the
best of my knowledge, none have finished!) to assemble real -8 code from, 
and then you need a means to load the binary into a simulated CPU with
memory, and the attendant peripherals you want the program to actually run
from.  Treating the -8 as merely a paper-tape system, whether emulated or not,
severely shortchanges the process of dealing with the machine.

However, a practical emulator is being worked on for PC-class machines.  It
depends on the ability of the 5.25" HD drive to physically read floppies that
are compatible with existent peripherals.  Someone else is working on one for
the Mac as well, etc.

The reason this can be done is that there are three viable disk formats that
can be used to run from an -8, and also on an emulator:

1)	5.25" CESI HD format is essentially the same as standard PC format
	except that it uses 26 sectors/track, and the sectors are 256 bytes.
	The PDP-8 can only access 12 bits every pair of bytes, but that's
	quite a useful size on the -8, since it means that each physical
	record is 1 pdp-8 page long.  This works quite well with P?S/8 and
	OS/8 standards.  Such disks can be booted on my PDP-8/e-a machine
	directly; you can run P?S/8 in 4K on such a machine or OS/8 in 8K
	on the same hardware, etc.  The controller is an OMTI 20 family or
	5000 series SCSI controller which supports HD floppies, MFM hard disks
	and optionally a QIC-02 tape backup unit.  All are in turn custom-
	supported by the MDC8 SCSI host adaptor from CESI.  The -8 offloads the
	data transfer (via DMA) to an on-board micro, so all it has to do is
	start up the transfer operation of DMAing an SCSI command in memory,
	to the micro which then does the command.  If the command is read or
	write, then the micro initiates a DMA operation for the data transfer
	as well.  PDP-8 programming consists of setting up the SCSI command
	and a few augmentations, and pointing the micro to the DMA address of
	this command, then wait for done and/or interrupt.  The controller
	is used the same way with hard disks, except that you have to logically
	map the partitioned disk to appropriate sized chunks for the various
	P?S/8 and/or OS/8 logical devices, etc.

	So reading such a disk is really quite easy on a PC.  In fact, the -8
	can read standard PC disks, but that format isn't quite so attractive
	for the prevailing software.  (And there's that limitation on getting
	at those extra bits.)

2)	The OMTI 5000 series specifically also supports 3.5" drives in HD as
	well.  By configuring the SCSI adaptor accordingly, the MDC8 can easily
	support the same logical drives, but physically be 3.5" with the same
	variation.  While not an efficient use of the media, this format can
	also be used on PC's, and also can be used on a newer MAC.

3)	DECmate RX50 format can also be used on the PC.  There is a slight
	problem in attempting to get OS/278 to run on a real -8, much less
	an emulated one, since OS/278 has problems of "emasculation" relative
	to OS/8.  No one is attempting to emulate the quirky variants of an
	actual DECmate, but the format itself is what matters.  Using various
	methods (such as Kermit-12 on a DECmate and on an -8, etc.) it's quite
	easy to get an OS/8 system written onto an RX50 that can only boot on
	a mythical machine, i.e., a PDP-8 with the DECmate's RX50 hardware, but
	with the PDP-8's otherwise compatible hardware.  On the DECmate, such
	a system is viable when referenced as a non-system device, but would
	boot on an emulator.

	In fact, there exists a CESI board called the FLP8 that solves just 
	about all of these problems of data compatibility:

The FLP8 can support a pair of identical drives that can be compatible with
the TEAC FD55E or F.  When considered as a single-sided device, it can be
configured to be media compatible with RX50.  The card is in turn a quad
Omnibus card suitable for the PDP-8/e,f,m,a, or perhaps a DW8E for earlier
machines, etc.  The overall programming style is RX01-like, although not
really compatible when used with these 5.25" drives.  (It can also be
configured to be used with 8" drives and be in fact a superset of the actual
RX01, in that it can also format!  The commands reserved for RX02 use of the
"set media density" will format on this device.  Formatting also applies to
the use with the RX50 format.)

So, an FLP8 can be used on a PDP-8/e using 5.25" drives (such as FD55GFR with
the jumpers set to emulate an FD55E such as is the case inside of the DECmate
III+; an RX33 *is* a TEAC FD55GFR/V drive!).  For such a device that is
similar to both an RX01 and also the RX portion of the DECmate, it is fairly
easy to write a set of handlers for P?S/8 and/or OS/8 (borrowing liberally
from the existing RX01 and DECmate RX50 handlers).  So, a bootable (on a real
-8/e) system can be created that would be data-compatible with the DECmate and
also can be directly emulated on the PC.  Also, this device supports 8-bit mode
thus allowing it to be configured to completely be able to access PC floppies,
thus opening up yet another avenue of compatibility.  PC HD 1.2 MB floppies
in MS-DOS format could be accessed using something to be named PIPMS.  And
of course such a utility could be run on an emulated version on an actual
PC so as to be an easy data conversion route between PDP-8 software and the
MS-DOS system running the emulator, etc.  Such a system could also access the
bootable floppies from the MDC8 system, including getting at the data bits
lost in the MDC8 transfers, etc.  (Note: while the FLP8 is a good device for
data transfer, it is *not* a good device to emulate!  This is a high overhead
slow device at best, and makes the real and emulated machines slow down quite
a lot!  The MDC8 is probably the best standard device to emulate since the -8
isn't directly involved with the transfer, etc.

Regardless of device chosen, this makes for the best avenue between emulations
and the real -8's.  Emulators can also choose to implement non-dismountable
media such as the RF08.  Before and after the emulation execution, the RF
image can be contained in an auxiliary file, etc.  This would likely be
implemented as a RAM disk, thus increasing the basic speed of the emulator.
Paper-tape devices can be emulated as files such as READER.BIN and PUNCH.BIN
for compatibility with these simple devices.  We already have utilities to
move PDP-8 binary files around that can be represented on systems such as
MS-DOS in the appropriate format, etc.

cjl


From ivie@cc.usu.edu Tue Oct  5 17:59:12 EDT 1993
Article: 480 of alt.sys.pdp8
Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu
Newsgroups: alt.sys.pdp8
Subject: Re: pdp8e documentation wanted
Message-ID: <1993Oct4.094804.1405@cc.usu.edu>
Date: 4 Oct 93 09:48:04 MDT
References: <1993Oct1.174551.27601@galileo.physics.arizona.edu> <28mrd8$8kc@apakabar.cc.columbia.edu>
Organization: Utah State University
Lines: 16

In article <28mrd8$8kc@apakabar.cc.columbia.edu>, lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
> If it's carefully taken apart and restored by someone with a long-page
> copier (possibly reduced?  It's likely these are in turn already reduced
> down from the typical large drafting prints DEC used to actually distribute
> as loose sheets.  I actually have a couple of those, but only of very old
> vintage cards, etc.) then it could be distributed.
> 
> So, Doug, how's your connections on getting print sets reprinted with
> permission?

What we really need to be able to do is scan 'em and stash 'em in an 
archive somewhere....
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
ivie@cc.usu.edu |     'obsolete-ready'


From enders@warp6.cs.misu.NoDak.edu Tue Oct  5 17:59:27 EDT 1993
Article: 481 of alt.sys.pdp8
Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!moe.ksu.ksu.edu!osuunx.ucc.okstate.edu!constellation!aardvark.ucs.uoknor.edu!ns1.nodak.edu!news.NoDak.edu!enders
Newsgroups: alt.sys.pdp8
Subject: Re: pdp8e documentation wanted
Message-ID: <ENDERS.93Oct4143636@warp6.cs.misu.NoDak.edu>
From: enders@warp6.cs.misu.NoDak.edu (Todd Enders A262 857-3018)
Date: Mon, 4 Oct 1993 19:36:36 GMT
Sender: usenet@ns1.nodak.edu (Usenet login)
References: <1993Oct1.174551.27601@galileo.physics.arizona.edu><28mrd8$8kc@apakabar.cc.columbia.edu> <1993Oct4.094804.1405@cc.usu.edu>
Organization: Minot State University -- Minot, ND
In-Reply-To: ivie@cc.usu.edu's message of 4 Oct 93 09:48:04 MDT
Nntp-Posting-Host: warp6.cs.misu.nodak.edu
Lines: 8


     In fact, why limit one's self to pdp8's?  I, for one, would *love* to
see the print set for something like a pdp9, or a pdp10 of any flavour.  A
wall-sized schematic of the Instruction Set Processor on a KA10 would be
just *too* cool!

Todd     enders@warp6.cs.misu.nodak.edu



From jonathan@virtual.cuc.ab.ca Tue Oct  5 17:59:46 EDT 1993
Article: 482 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8,comp.sys.tandy
Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!library.ucla.edu!news.mic.ucla.edu!unixg.ubc.ca!acs.ucalgary.ca!cpsc.ucalgary.ca!xenlink!fsa.ca!virtual!jonathan
From: jonathan@virtual.cuc.ab.ca (Jonathan Levine)
Subject: Re: Warehouse load of antique
Message-ID: <CEDr61.n2I@virtual.cuc.ab.ca>
Organization: Virtual Universe Corp, Calgary, Alberta, Canada
References: <7.9741.41.0N5524A7@cs.uiowa.edu> <28f2fk$3m9@agate.berkeley.edu>
Distribution: world
Date: Mon, 4 Oct 1993 16:01:13 GMT
Lines: 15
Xref: news.columbia.edu alt.folklore.computers:52722 alt.sys.pdp8:482 comp.sys.tandy:5207

In article <28f2fk$3m9@agate.berkeley.edu> korpela@mofo.ssl.berkeley.edu (Eric J. Korpela) writes:

>Eric Korpela                        |  The two most common things in the
>korpela@ssl.berkeley.edu            |  universe are Hydrogen and stupidity.
>                                    |        -Harlan Ellison

Actually, I saw a variation of this signature attributed to Frank Zappa, who
was quoted as saying "Stupidity is like hydrogen.  It's a basic building
block of the universe."

-- 
Jonathan Levine       | jonathan@virtual.cuc.ab.ca
                      |  
voice: 403-261-5652   | Virtual Universe Corporation (Calgary AB) 
fax  :     237-0005   | Survival Research Laboratories    (SF CA) 


From jones@cs.uiowa.edu Sat Oct  9 04:16:58 EDT 1993
Article: 483 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8,alt.answers,news.answers
Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@cs.uiowa.edu (Douglas W. Jones)
Subject: PDP-8 Summary of Models and Options (posted every other month)
Summary: Descriptions of all models of the DEC PDP-8 computer.
	Those posting to alt.sys.pdp8 should read this.
Sender: news@news.uiowa.edu (News)
Message-ID: <1993Oct8.214457.18226@news.uiowa.edu>
Approved: news-answers-request@MIT.Edu
Date: Fri, 8 Oct 1993 08:08:08 GMT
Expires: Wed, 8 Dec 1993 08:08:08 GMT
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: Computer Science, University of Iowa, Iowa City, Iowa, USA
Keywords: FAQ DEC PDP 8
Followup-To: alt.sys.pdp8
Lines: 1200
Xref: news.columbia.edu alt.sys.pdp8:483 alt.answers:1026 news.answers:13435

Archive-name: dec-faq/pdp8-models
Last-modified: Oct 1, 1993

Frequently Asked Questions about DEC PDP-8 models and options.

	By Douglas Jones, jones@cs.uiowa.edu
	(with help from many folks)


Sites known to carry FTPable copies of this file:

	rtfm.mit.edu:/pub/usenet/alt.sys.pdp8
	sunsite.unc.edu:/pub/academic/computer-science/history/pdp-8/doc


Contents

	What is this FAQ?
	What is a PDP-5?
	What is a PDP-8?
	What is a LINC-8?
	What is a PDP-8/S?
	What is a PDP-8/I?
	What is a PDP-8/L?
	What is a PDP-12?
	What is a PDP-8/E?
	What is a PDP-8/F?
	What is a PDP-8/M?
	What is a PDP-8/A?
	What is a VT78?
	What is a DECmate I?
	What is a DECmate II?
	What is a DECmate III?
	What is a DECmate III+?


What is this FAQ?
		
	The purpose of this document is to supplement the material in the
	primary "Frequently Asked Questions about the PDP-8" file with
	more detailed information about the hardware and options of the
	different models of the PDP-8 sold by DEC.

	Although this document is something of a history of the DEC PDP-8
	family, the primary purpose of this document is as a guide and
	general outline to the PDP-8 models and options likely to be
	encountered by those involved in collecting and restoring systems. 


What is a PDP-5?
	Date of introduction:  Aug 11, 1963, unveiled at WESCON.
	Date of withdrawal:    early 1967.
	Price: $27,000

	Technology:  Built with DEC System Modules, the original line of
		transistorized logic modules sold by DEC.  Supply voltages
		of +10 and -15 volts; the logic levels -3 (logic 1) and
		0 (logic 0).  Logic packaged on boards that were about 4.75
		inches wide with each card mounted in a metal frame with
		a 22 pin edge connector.

		Input output devices were connected to the daisy-chained
		I/O bus using military-style armored cables and connectors.
		Use of toggle switches (as opposed to slide switches) on
		the front panel was another vestige of military-style design.

	Reason for introduction:  This machine was inspired by the success
		of the CDC-160, Seymour Cray's 12 bit minicomputer, and by
		the success of the LINC, a machine that was built by DEC
		customers out of System modules.  These demonstrated that
		there was a market for a small inexpensive computer, and
		from the start, DEC's advertisements were aimed at this
		market.  "Now you can own the PDP-5 computer for what a
		core memory alone used to cost: $27,000", ran one 1964 ad.

	Reason for withdrawal:  The PDP-8 outperformed the PDP-5, and did
		so for a lower price.

	Compatability:  The core of the PDP-8 instruction set is present,
		but memory location zero is the program counter, and
		interrupts are handled differently.  The Group 1 OPR rotate
		instructions cannot be combined with IAC or CMA; this limits
		the ability of the PDP-5 to support code from later models.

		The machine did not support 3 cycle data-break (DMA transfers
		using memory to hold buffer address and word-count
		information), so many later PDP-8 peripherals could not
		be used on the PDP-5.  In addition, DMA transfers are not
		allowed outside the program's current 4K data field, severely
		limiting software compatability on systems with over 4K of
		memory where either interrupts or software initiated changes
		to the data field during a transfer would cause chaos.

	Standard configuration:  CPU with 1K or 4K of memory (2K and 3K
		versions were not available).

	Peripherals:

		An extended arithmetic element (EAE) was available; this was
		an I/O device, using IOT instructions to evoke EAE operations.
		As a result, it was not compatable with the later PDP-8 EAEs.
		In addition, machines with the EAE option had a different
		front panel from those without.

		The type 552 DECtape control and type 555 DECtape transports
		were originally developed for the PDP-5.

		After the PDP-8 was introduced, DEC offered a bus converter
		that allowed the PDP-5 to support standard PDP-8 negibus
		peripherals, so long as they avoided using 3-cycle data
		break transfers.  The standard 804 PDP-8 expander box was
		frequently sold as an upgrade to PDP-5 systems.


What is a PDP-8?
	Date of introduction:  1965 (Unveiled March 22, in New York)
	Date of withdrawal:    1968.
	Also known as:
		Classic PDP/8 (to point out lack of a model suffix)
		PCP-88, an OEM label, used Foxboro Corporation.
	Price: $18500

	Technology:  Mostly DEC R-series logic modules; these were originally
		discrete compponent transistor logic, but around the time
		the PDP-8 was introduced, DEC introduced the Flip Chip,
		a hybrid diode/resistor "integrated circuit" on a ceramic
		substrate.  These were pin-compatable with the discrete
		components they replaced, and DEC began to refer to their
		R-series modules as flip-chip modules and they even
		advertised the PDP-8 as an integrated circuit computer.
		A typical flip-chip module, the R111, had three 2-input nand
		gates and cost $14, with no price change from 1965 to 1970.

		S-series logic modules were also used; these are essentially
		the same as their R-series cousins, but with different
		pull-up resistors for higher speed at lower fanout.  Many
		R and S series modules have trimmers that must be tuned to
		the context, making replacement of such modules more complex
		than a simple board swap.

		As with the system modules used in the PDP-5, the supply
		voltages were +10 and -15 volts and the logic levels were
		-3 (logic 1) and 0 (logic 0).  Logic was packaged on boards
		that were 2.5 inches wide by 5 inches high.  The card edge
		connector had 18 contacts on 1/8 inch centers.  Some double
		width cards were used; these had two card edge connectors
		and were 5 1/8 inches wide.  Machine wrapped wire-wrap
		technology was used on the backplane using 24-gauge wire.

		The "negibus" or negative logic I/O bus used -3 and 0 volt
		logic levels in 92 ohm coaxial cable, with 9 coaxial cables
		bundled per connector card and 6 bundles making up the basic
		bus.  4 (originally 5) more bundles were required to support
		data-break (DMA) transfers.  Bus termination was generally
		kluged in with 100 ohm resistors clipped or wrapped into the
		backplane, although a bus terminator card was occasionally
		used.  Some time after the first year of production, flat
		ribbon cable made of multiple coaxial cables was used, and
		later still, flat mylar stripline cable was used (or misused
		when shielding was necessary but omitted).

		Core memory was used, with a 1.5 microsecond cycle time,
		giving the machine an add time of 3 microseconds.  4K of
		core occupied an aluminum box 6 inches on a side and needed
		numerous auxiliary flip-chips for support.  It is worth
		noting that the PDP-8 was about as fast as was practical
		with the logic technology used; only by using tricks like
		memory interleaving or pipelining could the machine have
		been made much faster.

	Reason for introduction:  This machine was inspired by the success
		of the PDP-5 and by the realization that, with their new
		Flip-Chip technology, DEC could make a table-top computer
		that could be powered by a single standard wall outlet;
		of course, adding any peripherals quickly increased the
		power requirement!

	Reason for withdrawal:  The PDP-8/I was less expensive, and after
		initial production difficulties, it equalled the performance
		of the PDP-8.

	Compatability:  The core of the PDP-8 instruction set is present,
		but the Group 1 OPR instruction IAC cannot be combined with
		any of the rotate instructions.  If RAR and RAL or RTR and
		RTL are combined, the results are unpredictable (simultaneous
		set and reset of bits of AC results in metastable behavior).
		The IOT 0 instruction was used for the internal type 189 ADC,
		and not for the later CAF (clear all flags) instruction.
		As a result, if the ADC option was not present, IOT 6004
		(or microcoded variants) would hang the machine.

		If the extended arithmetic element is present, the SWP
		(exchange AC and MQ) instruction does not work.  This
		works on later models when the EAE is present, although
		it was only documented with the introduction of the
		PDP-8/E.  Finally, the EAE lacks the SCL (shift count
		load) instruction that is present on later models.

		On machines with over 8K, an attempt to change the
		data field to a non-existant field caused a bizarre double-
		indirect and skip instruction execution that must be
		accounted for in memory diagnostics.

	Standard configuration:  The PDP-8 was sold as a CPU with 4K of
		memory, a 110 baud current loop teletype interface and an
		ASR 33 Teletype.  The standard in-cabinet logic includes
		support for the full negibus interface, including data-break
		(DMA) transfers.

		Both a rack-mount model with rosewood trim and an elegant
		plexiglass enclosed table-top configuration were standard.
		Under the skin, basic machine occupied a volume 33 inches
		high by 19 inches wide by 22 inches deep.  The two halves
		of the backplane were mounted vertically, like the covers
		of a book, with the spine in back and circuit modules
		inserted from the two sides.  Sliding the CPU out of the
		relay rack or removing the plexiglass covers allows the
		backplane to be opened for access to the wires.

	Expandability:  In-cabinet options include the type 182 extended
		arithmetic element (EAE), the type 183 memory extension
		control subsystem, and the type 189 low performance
		analog to digital converter (ADC).  Prewired backplane
		slots were reserved for all of these.

		Expansion beyond 4K of memory requires an additional
		type 804 rack and power supply.  A type 184 memory module
		is needed for each 4K field of memory, up to a maximum of
		32K.  The rack-mount CPU occupied a large part of one rack,
		allowing room for a single type 184 memory expansion module
		below the CPU; generally, a second rack was needed for any
		added peripherals or memory.

		At the end of the production run, some PDP-8 systems were
		sold with PDP-8/I memory, allowing room for an additional
		4K without need for an expansion chassis.  These nonstandard
		machines were very difficult to maintain!

	Peripherals:  At the time of introduction, the following negibus
		peripherals were offered.

		-- Type 750C high speed paper tape reader and control.
		-- Type 75E high speed paper tape punch and control.
		-- Type 138E analog to digital converter and multiplexor.
		-- Type 34D oscilloscope display (dual digital to analog).
		-- Type 350B incremental (CalComp) plotter control.
		-- Type 451 card reader and control.
		-- Type 450 card punch control for IBM Type 523 punch.
		-- Type 64 (later 645) Mohawk line printer and control.
		-- Type RM08 serial magnetic drum system (up to 256K words).
		-- Type 552 DECtape control (for type 555 DECtape drives).
		-- Type 57A magnetic tape control (IBM type 729 drive).
		-- Type 580 magnetic tape system.

		By 1967, the following peripherals had been added to the line:

		-- Type TC01 DECtape control for up to 8 TU55 transports.
		-- Type AF01 analog to digital converter and multiplexor.
		-- Type AA01A 3 channel digital to analog (scope display).
		-- Type AX08 parallel digital input port.

		By 1968, the following new peripheral had been added:

		-- Type DF32 fixed head disk system (up to 256K words).
		-- Type BE01 OEM version of the TC01 (no blinking lights).
		-- Type BE03 dual TU55 drive for the TC01.

		Finally, as DEC abandoned the negibus, they introduced the
		DW08B negibus to posibus converter so newer posibus
		peripherals could be used on older negibus machines.
		
		
What is a LINC-8?
	Date of introduction:  1966 (during or before March)
	Date of withdrawal:    1969 (displaced by PDP-12)
	Price: $38,500

	Technology:  DEC Flip Chip modules, as in the PDP-8, with a LINC CPU
		partially reimplemented in Flip Chips and partially emulated
		with PDP-8 instructions.  (The original LINC was built from
		the same System Modules used in the PDP-5.)

	Compatability:  Identical to the PDP-8.

	Standard configuration:  The combined PDP-8/LINC CPU, plus
		4K of memory was central to the system.  The set of
		peripherals bundled with the machine was impressive:

		-- An ASR 33 Teletype modified for the LINC character set.
		-- Two LINCtape drives.
		-- 8 analog to digital converter channels with knob inputs.
		-- Another 8 ADC channels with jack inputs.
		-- 18 programmable relay outputs, good up to 60 Hz.
		-- 1 Tektronics 560 oscilliscope.

		The X and Y axis control for the scope came from DACs
		attached to the LINC's AC and MB registers, respectively.

	Expandability:

		Up to 3 additional pairs of LINCtape drives could be added,
		for a total of 8 drives.  Each pair of drives cosmetically
		resembled the type BE03 dual DECtape transport, but single
		drives were not available.

		Up to 2 additional ranks of 8 ADC channels could be added.

		A second oscilliscope could be added.


What is a PDP-8/S?
	Date of introduction:  1966 (Unveiled, Aug 23, WESCON, Los Angeles).
	Date of withdrawal:    1970.
	Price: $10,000

	Technology:  DEC Flip Chip modules and core memory, as in the
		PDP-8.  Unlike the PDP-8, the PDP-8/S memory was mounted
		on quad-height single-width boards that plugged into the
		standard flip-chip sockets.

	Reason for introduction:  This machine was developed as a
		successful exercise in minimizing the cost of the machine.
		It was the least expensive general purpose computer made
		with second generation (discrete transistor) technology,
		and it was one of the smallest such machines to be mass
		produced (a number of smaller machines were made for
		aerospace applications).  It was also incredibly slow,
		with a 36 microsecond add time, and some instructions
		taking as much as 78 microseconds.  By 1967, DEC took the
		then unusual step of offering this machine for off the
		shelf delivery, with one machine stocked in each field
		office available for retail sale.

	Reason for withdrawal:  The PDP-8/L vastly outperformed the PDP-8/S,
		and it did so at a lower price.

	Compatability:  The core of the PDP-8 instruction set is present,
		but there are a sufficient number of incompatabilities
		that, as with the PDP-5, many otherwise portable "family
		of 8" programs will not run on the PDP-8/S.  Perhaps the
		worst incompatability is that the Group 1 OPR instruction
		CMA cannot be combined with any of the rotate instructions;
		as with the PDP-8, IAC also cannot be combined with rotate.

	Standard configuration:  CPU with 4K of memory, plus 110 baud current
		loop teletype interface.  Both a rack-mount table-top
		versions were sold (both 9" high by 19" wide by 20"? deep).

		The rack mount could be slid out of the rack on slides for
		for maintenance.  A variant PDP-8/S was packaged vertically
		in the base of an ASR33 teletype!

	Expandability:  The CPU supported the standard PDP-8 negibus, but
		I/O bandwidth was 1/5 that of the PDP-8.  Thus, most, but
		not all PDP-8 peripherals could be used.  A few DEC
		peripherals such as the DF32 came with special options to
		slow them down for compatability with the PDP-8/S.  The
		speed problems were such that there was never any way to
		attach DECtape to this machine.


What is a PDP-8/I?
	Date of introduction:  1968 (announced before December '67)
	Date of withdrawal:    1971.

	Technology:  DEC M-series logic modules, called M-series flip-chips
		as the term flip-chip was applied to the module format
		instead of to DEC's hybrid integrated circuits.  M-series
		modules used TTL chips, with a +5 supply, packaged on the
		same format board as was used with the original flip-chips,
		but with double-sided card-edge connectors (36 contacts
		instead of 18).  Modules were limited to typically 4 SSI
		ICs each.  The M113, a typical M-series module, had 10
		2-input nand gates and cost $23 in 1967 (the price fell to
		$18 in 1970).  Wire-wrapped backplanes used 30-gauge wire.

		The PDP-8/I, as originally sold, supported the then-standard
		PDP-8 negibus.  4K words of core were packaged in a 1 inch
		thick module made of 5 rigidly connected 5 by 5 inch
		two-sided printed circuit boards.  Connectors and support
		electronics occupied an additional 32 backplane slots.

		Nominally, the core memory (which, curiously, used a negative
		logic interface!) was supposed to run at a 1.5 microsecond
		cycle time, but many early PDP-8/I systems were delivered
		running at a slower rate because of memory quality problems.
		DEC went through many vendors in the search for good memory!
		The memory interface was asynchronous, allowing the CPU to
		delay for slow memory.  DEC continued to make the classic
		PDP-8 until the problems with memory speed were solved.

	Reason for introduction:  This machine was developed in response
		to the introduction of DIP component packaging of TTL
		integrated circuits.  This allowed a machine of about
		the same performance as the original PDP-8 to fit in about
		half the volume and sell for a lower price.

	Reason for withdrawal:  The PDP-8/E made slight performance
		improvements while undercutting the price of the PDP-8/I.

	Compatability:  The core of the PDP-8 instruction set is present,
		and unlike the original PDP-8, IAC can be combined with
		rotate in a single microcoded Group 1 OPR instruction.
		Combined RAR and RAL or RTR and RTL produce the logical
		and of the expected results from each of the combined shifts.

		If the extended arithmetic element is present, the SWP
		(exchange AC and MQ) instruction works, but this was not
		documented.

		On large memory configurations, memory fetches from a
		nonexistant memory field take about 30 microseconds (waiting
		for a bus timeout) and then they return either 0000 or 7777
		depending on whether the fetch was from an even or odd field.

	Standard configuration:  CPU with 4K of memory, plus 110 baud current
		loop teletype interface.  Pedestal, rack-mount and table-top
		versions were made.  In the pedestal version, the logic
		filled the body of the pedestal, with the console lights
		and switches on top.  In one rack-mount version, the machine
		was built on a backplane that was bolted to the back of the
		rack, while the front panel hung from the front (unlike all
		other rack-mounted PDP-8 models, this version could not be
		swung out for maintenance on chassis slides).  Finally,
		a boxed version was sold that could be used on table-top
		or mounted on chassis slides.

	Expandability: 4K of memory could be added internally, and additional
		memory could be added externally using a rack-mounted MM8I
		memory expansion module for each 4K or 8K addition over 8K.

		The backplane of the PDP-8/I was prewired to hold a Calcomp
		plotter interface, with the adjacent backplane slot reserved
		for the cable connection to the plotter.

		Initially, the CPU was sold with bus drivers for the PDP-8
		negibus, allowing this machine to support all older DEC
		peripherals, but later machines were sold with posibus
		interfaces, and DEC made an effort to convert earlier
		machines to the posibus in the field.

		A posibus to negibus converter, the DW08A, allowed use of
		all older PDP-8 peripherals, with small modifications.
		The change from negibus to posibus during the period of
		PDP-8/I production leads to confusion because surviving
		systems may have any of three I/O bus configurations:
		Negibus, early posibus, or final posibus.  The early
		posibus used the same connectors and cables as the negibus,
		with only 9 conductors per connector, while the final
		posibus used both sides of the connector paddles, for 18
		bus lines per connector.  To add to this confusion, some
		negibus PDP-8/I systems were rewired to use 18 conductor
		posibus cables while still using negative logic!

		Eventually, an add-on box was sold that allowed PDP-8/E
		(OMNIBUS) memory to be added to a PDP-8/I.  Additionally,
		Fabritek sold a 24K memory box for the 8/I.


What is a PDP-8/L?
	Date of introduction:  1968 (announced before August '68)
	Date of withdrawal:    1971.
	Price: $8,500

	Technology:  DEC M-series flip Chip modules, as in the PDP-8/I,
		with the same core memory as the 8/I, but the memory cycle
		cycle time was downgraded to 1.6 microseconds to avoid the
		speed problems of the -8/I.

		The positive I/O bus, or posibus, was a 100 ohm bus clamped
		between 0 and 3 volts with TTL drivers and receivers.  This
		was packaged with 18 signal lines per 2-sided interconnect
		cable, using mylar ribbon cable in most cases.  Electrically,
		coaxial cable could be used, but the slots in the CPU
		box were too small to allow convenient use of this option.

	Reason for introduction:  This machine was developed as a moderately
		successful exercise using M-series logic to produce a
		lower cost but moderately fast machine.  The idea was to
		cut costs by limiting provisions for expansion.

	Reason for withdrawal:  The PDP-8/E made performance improvements
		while slightly undercutting the price of the PDP-8/L.

	Compatability:  The core of the PDP-8 instruction set is present,
		but all Group 3 OPR instructions are no-ops, even the
		Group 3 version of the CLA instruction.  This is because
		there was no provision made for adding an EAE to this machine.
		Microcoding RAR and RAL together works as in the PDP-8/I.
		Finally, a new front panel feature was added, the protect
		switch.  When thrown, this makes the last page of the last
		field of memory read-only (to protect your bootstrap code).

		The instruction to change the data field on an 8/L becomes
		a no-op when the destination data field is non-existant; on
		all other machines, attempts to address non-existant fields
		are possible.  When the 8/L is upgraded with memory expander
		boxes supporting a total of over 8K of memory, access to
		nonexistant data fields becomes possible and always returns
		0000 on read.

	Standard configuration:  A CPU with 4K of memory, plus 110 baud
		current loop teletype interface was standard.  Both
		rack-mount and table-top versions were sold (both 9" high
		by 19" wide by 21" deep).  The backplane was on top,
		with modules plugged in from the bottom.  The rack-mount
		version could be slid out for maintenance.

	Expandability:  The CPU supported a new bus standard, the PDP-8
		posibus.  There is little space for in-box peripherals, but
		an expander box with the same volume as the CPU was available,
		the BA08A; this was originally intended to hold an additional
		4K of memory and provide room for additonal in-box peripheral
		interfaces such as the PDP-8/I Calcomp plotter interface,
		but this box could be used for peripherals only if other
		memory expansion boxes were used.

		DEC eventually offered the BM12L, an 8K expansion box,
		allowing 12K total memory on a PDP-8/L.  Curiously, this
		contains precisely the modules needed to upgrade a 4K
		PDP-8/I or PDP-12 to an 8K machine, or to populate an MM8I
		box to add 8K of additional memory to an 8/I or PDP-12.

		Finally, DEC eventually offered a box allowing PDP-8/E
		(OMNIBUS) memory to be used with the PDP-8/L.  PDP-8/L
		configurations with over 8K of memory were awkward
		because the front panel only showed one bit of the extended
		memory address.  As a result, extra lights and switches
		for the additional bits of the memory address were
		mounted on the front of the memory expander boxes for
		the large configurations.

		Posibus peripherals were quickly produced by changing the
		bus interface logic and backplane slots on old negative bus
		peripherals, but many early PDP-8/L systems were sold with
		DW08A bus level converters to run old negibus peripherals.

		Posibus peripherals introduced after the PDP-8/L (and also
		used with posibus versions of the PDP-8/I) included:

		-- The TC08P DECtape controller (for 8 TU55 or 4 TU56).
		-- The DF32D-P fixed head disk controller (a posibus DF32).
		-- The FPP-12 floating point processor.
		-- The TR02 simple magnetic ttape control.
		-- The RK08 disk subsystem, 4 disk packs, 831,488 words each.


What is a PDP-12?
	Date of introduction:  1969 (February or earlier).
	Date of withdrawal:    1973.
	Price: $27,900

	Technology:  DEC M-series flip Chip modules, as in the PDP-8/I.

	Reason for introduction:  This machine was developed as a follow-up
		to the LINC-8.  Originally it was to be called the LINC-8/I,
		but somehow it got its own number.  In effect, it
		was a PDP-8/I with added logic to allow it to execute most
		of the LINC instruction set, with trapping and software
		emulation used more selective than on the LINC-8.

	Reason for withdrawal:  The LAB-8/E and the LAB-11 (a PDP-8/E
		and a PDP-11/20 with lab peripherals) eventually proved
		the equal of the PDP-12 in practice, and LINC compatability
		eventually proved to be of insufficient value to keep the
		machine alive in the marketplace.
		
	Compatability:  This machine is fully compatable with the PDP-8/I,
		with additional instructions to flip from PDP-8 mode to
		LINC mode and back.  IOT 0 could enable the API, causing
		trouble with later PDP-8 code that assumes IOT 0 is "Clear
		all flags".  Also, the DECtape instruction DTLA (6766)
		becomes part of a stack-oriented extension to the
		instruction set, PUSHJ.

	Standard configuration:  PDP-8/LINC CPU with 4K of memory, plus 110
		baud current loop interface, plus output relay registers.
		In addition, the standard configuration included either
		two TU55 or one TU56 drive, with a PDP-12 only controller
		allowing it to handle either LINCtape or DECtape.  In
		additoon, a 12" scope was always included, with a connector
		that can connect to a second scope.

	Expandability:  An analog to digital converter and multiplexor
		was needed to fully support knob-oriented LINC software.

		Other options included:

		-- the KW12 programmable lab clock.
		-- additional TU55 or TU56 drives (up to 8 transports).
		-- the PC05 paper tape reader punch.


What is a PDP-8/E?
	Date of introduction:  1970 (during or before August).
	Date of withdrawal:    1978.
	Also known as:
		Industrial-8 (with a red color scheme)
		LAB-8/E (with a green color scheme)
	Price: $7,390

	Technology:  Nominally made from DEC M-series flip Chip modules,
		but in a new format, quad-wide (10.5 inches wide), double-
		height (9 inches, including card-edge connector, excluding
		handles).  SSI and MSI TTL logic were used on these boards,
		and the entire CPU fit on 3 boards.

		Interconnection between boards was through a new bus, the
		OMNIBUS.  This eliminated the need for a wire-wrapped
		backplane, since all slots in the bus were wired identically.
		A new line of peripheral interfaces was produced, most being
		single cards that could be plugged directly into the inside
		the main enclosure.  These included a set of posibus adapters
		allowing use of older peripherals on the new machine.

		Interboard connectors were needed for some multiboard
		options, including the CPU and memory subsystems.  These
		used standard 36 pin backplane connectors on the opposite
		side of the board from the backplane.  Some boards, notably
		memory boards, had a total of 8 connector fingers, 4 for
		the omnibus and 4 for interboard connectors.

		The core memory cycle time was 1.2 or 1.4 microseconds,
		depending on whether a read-modify-write cycle was involved.
		A 4K core plane was packaged on a single quad-wide double-
		high board, with most of the drive electronics packed onto
		two adjacent boards.  Soon after the machine was introduced,
		an 8K core plane was released in the same format.

	Reason for introduction:  The cost of the PDP-8/I and PDP-8/L was
		dominated by the cost of the interconnect wiring, and this
		cost was a result of the use of small circuit boards.  By
		packing a larger number of chips per board, similar function
		could be attained in a smaller volume because less interboard
		communication was required.  The PDP-8/E exploited this to
		achieve a new low in cost while attaining a new high in
		performance.

	Reason for withdrawal:  This machine was slowly displaced by the
		PDP-8/A as the market for large PDP-8 configurations
		declined in the face of pressure from 16 bit mini and
		microcomputers.

	Compatability:  As with the PDP-8/I and PDP-8/L, there are no limits
		on the combination of IAC and rotate instructions.  Unlike
		the early machines, basic Group 3 OPR operations for loading
		and storing the MQ register work even if there is no extended
		arithmetic element.  Finally, a new instruction was added,
		BSW; this swaps the left and right bytes in AC, and is
		encoded as a Group 1 OPR instruction using the "double the
		shift count bit".

		An odd quirk of this machine is that the RLR RAR combination
		ands the AC with the op-code, and the RTR RTL combination
		does an effective address computation loading the high 5 bits
		of AC with the current page and the lower bits of AC with the
		address field of the OPR instruction!

		The EAE has a new mode, mode B.  Previous EAE designs were
		single-mode.  Mode B supports a large set of 24 bit
		operations and a somewhat more rational set of shift
		operations than the standard EAE.  All prior EAE designs
		would hang on the microcoded CLA NMI (clear/normalize)
		instruction applied to a nonzero AC.  This instruction
		is redefined to be a mode changing instruction on the 8/E.

	Standard configuration:  A CPU with 4K of memory, plus 110 baud
		current loop teletype interface.  Both a rack-mount table-top
		versions were sold (both 9" high by 19" wide by 21" deep).
		The rack mount version was mounted on slides for easy
		maintenance.  The OMNIBUS backplane was on the bottom,
		with boards inserted from the top.

		The standard OMNIBUS backplane had 20 slots, with no
		fixed assignments, but the following conventional uses:

		-- KC8E programmer's console (lights and switches)
		-- M8300 \_ KK8E CPU registers
		-- M8310 /  KK8E CPU control
		-- 
		-- 
		-- M833  - Timing board (system clock)
		-- M865  - KL8E console terminal interface.
		--
		--
		--   -- space for more peripherals
		--
		--
		-- M849  - shield to isolate memory from CPU
		-- G104  \
		-- H220   > MM8E 4K memory
		-- G227  /
		--
		--   -- space for more memory
		--
		-- M8320 - KK8E Bus terminator

		Most of the early boards with 3 digit numbers were defective
		in one way or another, and the corrected boards added a
		trailing zero.  Thus, the M833 was generally replaced with
		an M8330, and the M865 was replaced with the M8650.

	Expandability:  The following are among the OMNIBUS boards that
		could be added internally:

		-- M8650 - KL8E RS232 or current loop serial interface.
		-- M8340 \_ Extended arithmetic element.
		-- M8341 /  (must be attached in two slots adjacent to CPU.
		-- M8350 - KA8E posibus interface (excluding DMA transfers).
		-- M8360 - KD8E data break interface (one per DMA device).
		-- M837  - KM8E memory extension control (needed for over 4K).
		-- M840  - PC8E high speed paper tape reader-punch interface.
		-- M842  - XY8E X/Y plotter control.
		-- M843  - CR8E card reader interface.

		There were many other internal options.  There was room in
		the basic box for another 20 slot backplane; taking into
		account the 2 slots occupied by the M935 bridge between
		the two backplanes, this allowed 38 slots, and a second
		box could be added to accomodate another 38 slot backplane,
		bridged to the first box by a pair of BC08H OMNIBUS
		extension cables.

		Given a M837 memory extension control, additional memory
		could be added in increments of 4K by adding G104, H220,
		G227 triplets.  The suggested arrangement of boards on the
		OMNIBUS always maintained the M849 shield between memory
		other options.  The one exception was that the M8350 KA8E
		and M8360 KD8E external posibus interfaces were typically
		placed at the end of the OMNIBUS right before the terminator.

		The following options were introduced later, and there were
		many options offered by third party suppliers.

		-- G111  \
		-- H212   > MM8EJ 8K memory
		-- G233  /
		-- M8357 -- RX8E interface to RX01/02 8" diskette drives.
		-- M7104 \
		-- M7105  > RK8E RK05 Disk Interface
		-- M7106 /
		-- M8321 \
		-- M8322  \ TM8E Magtape control for 9 track tape.
		-- M8323  /
		-- M8327 /

		At one point, DEC packaged a PDP-8/E in a desk with no
		front panel controls other than power and bootstrap switch,
		along with an RX01 accessable from the front and a VT50
		on top.  This was sold as the Class-ic system, with an
		intended market in the classroom (hence the name); it was
		the forerunner, in terms of packaging, of many later DEC
		office products.
		

What is a PDP-8/F?
	Date of introduction:  1972.
	Date of withdrawal:    1978.

	Technology:  an OMNIBUS machine, as with the PDP-8/E.  First use
		of a switching power supply in the PDP-8 family.

	Reason for introduction:  The PDP-8/E had a large enough box and
		a large enough power supply to accomodate a large
		configuration.  By shortening the box and putting in a
		small switching power supply, a lower cost OMNIBUS machine
		was possible.

	Reason for withdrawal:  The PDP-8/A 800 displaced this machine,
		providing similar expansion capability at a lower cost.

	Compatability:  The PDP-8/F used the PDP-8/E CPU and peripherals.

	Standard configuration:  Identical to the PDP-8/E, except that
		the KC8E front panel was replaced with a KC8M front panel
		that had LEDs instead of incandescent lights; this front
		panel could also be installed on PDP-8/E systems, but the
		PDP-8/E front panel could not be used on a PDP-8/F because
		of the lack of a +8 supply for the lights.  The original
		PDP-8/F box had a defective power supply, but a revised
		(slightly larger) box corrected this problem.

	Expandability:  This machine could be expanded using all PDP-8/E
		OMNIBUS peripherals, including the external expansion
		chassis.  The relatively small internal power supply and
		the lack of room for a 20 slot bus expander inside the
		first box were the only limitations.  There were minor
		compatability problems with some options, for example,
		the power-fail auto-restart card, as originally sold, was
		incompatable with the PDP-8/F power supply.


What is a PDP-8/M?
	Date of introduction:  1972.
	Date of withdrawal:    1978.

	Technology:  This machine was a PDP-8/F (with a PDP-8/E CPU)

	Reason for introduction:  DEC knew that OEM customers were an
		important market, so they packaged the PDP-8/F for this
		market, with no hardware changes behind the front panel.

	Reason for withdrawal:  Same as the PDP-8/F

	Compatability:  The PDP-8/M used the PDP-8/E CPU and peripherals.

	Standard configuration:  Identical to the PDP-8/F, except that
		the KC8M front panel was replaced with a minimal function
		panel and the color scheme was different.  Because of this,
		one of the following options were required:

		-- M848  -- KP8E Power fail and auto-restart.
		-- M847  -- MI8E Hardware Bootstrap Loader.

	Expandability:  All options applying to the PDP-8/F applied.  In
		addition, the KC8M front panel (standard with the PDP-8/F)
		was available as an option.


What is a PDP-8/A?
	Date of introduction:  1975
	Date of withdrawal:    1984

	Technology:  This machine used the OMNIBUS with a new single-board
		CPU, made possible by the use of TTL MSI and LSI components
		on an extra-wide board (formally, hex high, double high)
		with 6 connector fingers instead of the usual 4.

	Reason for introduction:  Using TTL MSI and LSI components, DEC
		was able to reduce the PDP-8 CPU to a single hex wide
		double high card.  Similarly, they were able to make an
		4K core memory card, and later, an 8K board in this
		format, and they were able to introduce a static RAM card
		using semiconductor memory.  The net effect was to reduce
		the minimum system to 3 boards.

		In addition, the market for the PDP-8 was dominated by
		small systems, with fewer and fewer customers needing
		large-scale expandability.  Thus, the 20 slot backplane
		of the early Omnibus machines was too big; with the new
		single board CPU and memory, a 12 slot backplane was enough.

	Reason for withdrawal:  The market for the PDP-8 family was
		shrinking in the face of pressure from larger minicomputers
		and the new monolithic microcomputers.  After 1975, many
		PDP-8 sales were to captive customers who had sufficient
		software investments that they could not afford to move.
		Only the word-processing and small business markets
		remained strong for first-time PDP-8 sales, and in these,
		the specialized DEC VT-78 and DECmate machines were more
		cost effective than the open architecture OMNIBUS machines.
		
	Compatability:  The new PDP-8/A CPU was largely compatable with
		the PDP-8/E CPU, except that the combination of RTR and
		RTL (Group 1 OPR instructions) loaded the next address.
		The power-fail auto-restart option included the standard
		skip on power low instruction, but also a new skip on
		battery empty instruction to test the battery used for
		back-up power on the new solid state memory.

	Standard configuration:  The PDP-8/A was sold with a new short
		OMNIBUS backplane, mounted on its side above a power supply
		and a battery to back up the solid state memory.  The
		minimum configuration included a limited function control
		panel and the following components on the bus:

		-- M8315 -- KK8A CPU board
		-- M???? -- MS8A 1K to 4K solid state memory.
		-- M8316 -- DKC8AA serial/parallel interface and clock.

		The M8316 board contained a remarkable but useful
		hodgepodge of commonly used peripherals, including the
		console terminal interface, a parallel port, the power/fail
		auto-restart logic, and a 100 Hz real time clock.

		The original configuration sold had a 10 slot backplane and
		a poor power supply.  The later base model had a 12 slot
		backplane, the 8/A 400.

	Expandability:  All PDP-8/E peripherals and options could be used
		with the PDP-8/A.  The KK8A cpu was not as fast as the KK8E
		used in the PDP-8/E, but the KK8E CPU could be substituted
		for the KK8A CPU, and many PDP-8/A systems were sold with
		this substitution.

		A box with a 20 slot backplane, the 8/A 800, was available
		for large configurations.  A pair of PDP-8/A backplanes
		could be connected using BC08H cables, and there was a
		special cable, the BC80C, for connecting a hex wide 8A
		backplane to a PDP-8/E, -8/F or -8/M backplane.

		By late 1975, the PDP-8/A was being sold in a workstation
		configuration, with the CPU and dual 8" diskette drives
		in a desk with a video terminal (VT57?) on top.  This
		followed the pattern set by the Class-ic packaging of the
		PDP-8/E, but it was aimed at the word-processing market.

		The following additional PDP-8/A (hex) boards were offered:

		-- G649  \_ MM8AA 8K Core stack (too slow for 8/E CPU!).
		-- H219A /  MM8AA 8K Core memory control.
		-- G650  \_ MM8AB 16K Core stack (ok for 8/E CPU!).
		-- H219B /  MM8AB 16K Core memory control.
		-- M???? -- MR8F 1K ROM (overlayable with RAM).
		-- M8317 -- KM8A memory extender (with variations).
		-- M8319 -- KL8A 4 channel RS232 or current loop serial I/O.
		-- M???? -- RL8A controller for 1 to 4 RL01/RL02 disk drives.

		-- M8416 -- KT8AA Memory management unit.
		--          KC8AA Programmer's Console (requires M8316)
		-- M8417 -- MSC8DJ 128K DRAM MOS Memory.

		Note that memory extension to 128K was a new PDP-8/A feature
		that was necessarily incompatable with the older PDP-8 memory
		expansion options, although the conventional PDP-8 memory
		expansion instructions still operate correctly on the first
		32K.  Access to additional fields involved borrowing IOT
		instructions that were previously dedicated to other devices.

		The MM8A options require the use of a box with a -20V power
		supply, either the 8A-500 or the 8A-800.  Also, the use of
		the MSC8 DRAM memory cards requires a CPU that supports
		the memory stall signal, early PDP-8/E CPUs did not.


What is a VT78?
	Date of introduction:  1978
	Date of withdrawal:    1980 (Displaced by the DECmate)
	Also known as:  DECstation 78 

	Technology:  Intersil 6100 microprocessor, packaged in a VT52 case.
		The 6100 processor was able to run at 4 MHz, but in the
		VT78, it was only clocked at 2.2 MHz because of the speed
		of the DRAM used and the deliberate use of graded out chips.

	Reason for introduction:  Using TTL MSI and LSI components, DEC
		could pack their CPU into vacant space in a standard
		terminal case, allowing PDP-8 systems to compete with
		personal computers in the small business and office
		automation market.  This was a natural follow-on to the
		workstation configurations in which the PDP-8/A was already
		being sold.

	Compatability:  The Group I OPR combinations RAL RAR and RTL RTR
		are no-ops.  Unlike all earlier PDP-8 models, autoindex
		locations 10 to 17 (octal) only work in page zero mode;
		these operate like all other memory location when addressed
		in current page mode from code running on page zero.  Other
		than this, it is fully PDP-8/E compatable, even at the level
		of I/O instructions for the standard periperals; this was
		the last PDP-8 to offer this level of compatability.

		It was not possible to continue from a halt without
		restarting the machine.  In addition, none of the peripherals
		available on this machine needed DMA (data break) transfers.

	Standard configuration:  The VT78 was sold with 16k words of DRAM
		with the keyboard and display of the VT52 terminal.  An RX01
		dual 8" diskette drive was standard, packaged in the
		pedestal under the terminal.  The console (device 03/04),
		the printer (output only) port (device 66), and the serial
		ports (devices 30/31 and 32/33) are compatable with the
		M8650 KL8E, with the latter extended to allow software
		controlled baud rates selection.  The parallel port
		(device 47) and 100Hz clock are compatable with the
		comparable PDP-8/A options on the M8316 DKC8AA.

		The standard ROM boots the system from the RX01 after setting
		the baud rates to match that selected by the switches on the
		bottom of the VT52 case.

	Expandability:  This was a closed system, with few options.  The
		base configuration was able to support two RX01 drives
		(later RX02), for a total of 4 transports.  Various boot
		ROM's were available, including a paper-tape RIM loader ROM
		for loading diagnostics from tape.  Another ROM boots the
		system from a PDP-11 server in the client/server
		configuration used by WPS-11.


What is a DECmate I?
	Date of introduction:  1980
	Date of withdrawal:    1984 (Phased out in favor of the DECmate II)
	Also known as:  DECmate (prior to the DECmate II, no suffix was used)

	Technology:  Based on the Intersil/Harris 6120 microprocessor,
		packaged in a VT-100 box with keyboard and display.

	Reason for introduction:  This machine was aimed primarily at
		the market originally opened by the VT78, using the IM6120
		as a substitute for the older 6100 chip and optimizing
		for minimum cost and mass production efficiency.

	Compatability:  A new feature was introduced in the 6120
		microprocessor:  The Group I OPR combination RAL RAR was
		defined as R3L, or rotate accumulator 3 places left, so
		that byte swap (BSW) is equivalent to R3L;R3L.  RTR RTL
		remained a no-op, as in the 6100.

		Also, the EAE operations not implemented in the basic
		CPU cause the CPU to hang awaiting completion of the
		operation by a coprocessor.  Unfortunately, no EAE
		coprocessor was ever offered.

		The printer port offered software baud-rate selection
		compatable with the VT78 baud-rate selection scheme.
		The data communications option was completely incompatable
		with all previous PDP-8 serial ports.

		The console and printer ports are not fully compatable with
		the earlier PDP-8 serial ports.  Specifically, on earlier
		serial interfaces, it was possible to test flags without
		resetting them, but on the DECmate machines, testing the
		keyboard input flag always resets the flag as a side effect.
		In addition, on the console port, every successful test of
		the flag must be followed by reading a character or the
		flag will never be set again.

		It was not possible to continue from a halt without
		restarting the machine.

		The large amount of device emulation performed by the CPU
		in supporting screen updates severely limits the ability of
		the system to run in real time.

	Standard configuration:  The DECmate I was sold with 32k words of
		memory, with a small additional control memory added to
		handle control/status and boot options.  The console
		terminal keyboard and display functions are largely
		supported by control memory routines (as opposed to having
		separate hardware for terminal support, as in the VT78).

		DECmate I came with an integral printer port, compatable
		with the VT78 (device 32/33), and it had an RX02 dual 8 inch
		diskette drive, mounted in the short cabinet under the
		terminal/CPU box.  A 100Hz clock was included, as in the
		VT78 and PDP-8/A.

	Expandability:  This was a closed system, with limited options.
		Specifically, a second RX02 could be connected (or an RX01,
		because that had a compatable connector), the DP278A and
		DP278B communications boards (really the same board, but
		the DP278B had 2 extra chips), and the RL-278 disk
		controller, able to accomodate from 1 to 4 RL02 rack mount
		disk drives.

		When the DP278A option is added, additional control
		memory is included containing a ROM-based terminal
		emulator allowing diskless operation.  The emulator is
		an extended VT100 subset that is essentially compatable
		in 80 column mode.  The DP278A option could support
		both asynchronous and synchronous protocols, and the DP278B
		could handle SDLC and other nasty bit-stuffing protocols.

		Various pedestal and desk configurations were sold for
		housing the RX01 and RX02 drives, most being teacart style
		designs, but there was also a pedestal version that was
		essentially a repackaging of the RX02 with new 8 inch
		disk transports (physically incompatable with earlier
		DEC transports).

What is a DECmate II?
	Date of introduction:  1982
	Date of withdrawal:    1986 
	Price: $1,435

	Technology:  Based on the 6120 microprocessor, this shared the same
		packaging as DEC's other competitors in the PC market, the
		Rainbow (80x86 based) and the PRO-325 (PDP-11 based).

	Reason for introduction:  This machine was introduced in order to
		allow more flexibility than the DECmate I and to allow more
		sharing of parts with the VT220 and DEC's other personal
		computers.

	Compatability:  Same as the DECmate I, except it could continue
		from a halt.  There was better hardware for device emulation
		support, allowing for somewhat better real-time performance,
		and the data communications port was an incompatable
		improvement on the incompatable DECmate I communications
		port.  The improved data communications port make it
		essentially as powerful as the DP-278B on the DECmate I,
		with a more efficient but bizarre software interface.

	Standard Configuration:  The DECmate II was sold with 32K of program
		memory, plus a second full bank for dedicated control
		panel functions, an integral RX50 dual 5 1/4 inch diskette
		drive with an 8051 controller chip, a printer port, a 100Hz
		real-time clock, a data communications port, and interfaces
		to the monitor and keyboard.  The diskette drive can read
		single-sided 48 track-per-inch diskettes, allowing the
		possibility of reading (but not writing) IBM PC diskettes.

	Expandability:  This was the most open of the DECmate systems, with
		a number of disk options:  An additional pair of RX50 drives
		could be added, and with the RX78 board, it could support
		a pair of dual 8 inch drives, either RX01 or RX02.

		As an alternative to the RX78, there was a controller for
		an MFM hard drive.  The interface to the RX78 board wasn't
		fully compatable with earlier interfaces to RX01 and RX02,
		and there was no way to have both an RX78 and an MFM drive.
		The MFM drive could be up to 64 MB, with 16 sectors per
		track, 512 bytes each and at most 8 heads and 1024 (or
		possibly 4096) cylinders.  A power supply upgrade was needed
		to support the MFM drive.  DEC sold this machine with 5,
		10 and 20 meg hard drives, Seagate ST-506, 412, and 225
		respectively.

		A graphics board supporting a color monitor could be added
		in addition to the monochrome console display.

		A coprocessor board could be added, with communication to
		and from the coprocessor through device 14.  DEC sold three
		boards, an APU board (Z80 and 64K), and two XPU boards (Z80,
		8086 and either 256K or 512K).  If these added processors
		are used, the 6120 processor is usually used as an I/O server
		for whatever ran on the coprocessor.  The XPU boards used
		a Z80 for I/O support, so 8086 I/O was very indirect,
		particularly if it involved I/O to a PDP-8 device that was
		emulated from control memory!  Despite this, I/O through
		the DECmate version of MS/DOS is generally faster than
		MS/DOS on more recent 80286 and 80386 based IBM PCs because
		of effective use of the coprocessors (but they couldn't
		run MS/DOS code that bypasses MS/DOS for I/O).


What is a DECmate III?
	Date of introduction:  1984
	Date of withdrawal:    1990 
	Price: $2,695

	Technology:  Same as the DECmate II.

	Reason for introduction:  Again, DEC discovered that the market
		for large systems was dominated by other products, and
		that the PDP-8 based products were rarely expanded to their
		full potential.  Thus, there was no point in paying the
		price of expandability.

	Compatability:  Same as the DECmate II, except that the printer
		port is fixed at 4800 baud.

	Standard Configuration:  The DECmate III was sold with 32K of program
		memory, plus a second full bank for dedicated control
		panel functions, an integral RX50 dual 5 1/4 inch diskette
		drive with an 8051 controller chip, a printer port, a 100Hz
		real-time-clock, a data communications port, and interfaces
		for the VR-201 monitor and keyboard.

	Expandability:  A revised version of the Z80 based coprocessor
		for the DECmate II was available, and a graphics board
		compatable with the later DECmate II graphics board
		could be added allowing the standard monochrome monitor
		to be replaced with a VR-241 color monitor.  Two monitor
		configurations were not supported.  An obscure variant
		of the DEC scholar modem was also supported as an option.


What is a DECmate III+?
	Date of introduction:  1985
	Date of withdrawal:    1990 

	Technology:  Same as the DECmate II.

	Reason for introduction:  This machine apparently represents the
		last gasp of the PDP-8, hunting for the remains of the
		ever-shrinking market niche that the earlier DECmates
		had carved out.  The market niche was not there, and
		the production runs for this machine were short enough
		that UV erasable EPROM technology was used where earlier
		DECmates had used mask programmed chips.

	Compatability:  Same as the DECmate II, but the machine was unable
		to read 48 track per inch IBM formatted diskettes.  Again
		the printer port was fixed at 4800 baud.

	Standard Configuration:  The DECmate III+ was sold with 32K of
		program memory, plus a second bank for dedicated
		control panel functions, an integral RX33 single 5 1/4
		inch diskette drive with an 8751 controller chip, a
		printer port, a data communications port and interfaces
		to the monitor and keyboard.  A hard disk controller
		compatable with the optional one on the DECmate II was
		included, supporting an integral ST-225 20 MB disk;
		it is likely that it can only handle up to 1024 cylinders,
		but it is otherwise compatable with the DECmate II.

	Expandability: The same coprocessor option sold with the
		DECmate III was available, but because of the lack of a
		second floppy drive, this was rarely used (the Z80 was
		most likely to be used to run CP/M, but that system
		requires two drives to handle the installation procedure;
		an appropriately configured bootable image created on a
		DECmate II or III could run on a DECmate III+).

		The same graphics board as used on the DECmate III was
		also available.  The circuit traces and connectors for
		the Scholar modem are present, but this option was never
		sold on the DECmate III+.


From jones@cs.uiowa.edu Sat Oct  9 04:17:11 EDT 1993
Article: 484 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8,alt.answers,news.answers
Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@cs.uiowa.edu (Douglas W. Jones)
Subject: PDP-8 Summary of Models and Options (posted every other month)
Summary: Descriptions of all models of the DEC PDP-8 computer.
	Those posting to alt.sys.pdp8 should read this.
Sender: news@news.uiowa.edu (News)
Message-ID: <1993Oct8.214620.18324@news.uiowa.edu>
Approved: news-answers-request@MIT.Edu
Date: Fri, 8 Oct 1993 08:08:08 GMT
Expires: Wed, 8 Dec 1993 08:08:08 GMT
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: Computer Science, University of Iowa, Iowa City, Iowa, USA
Keywords: FAQ DEC PDP 8
Followup-To: alt.sys.pdp8
Lines: 1200
Xref: news.columbia.edu alt.sys.pdp8:484 alt.answers:1027 news.answers:13436

Archive-name: dec-faq/pdp8-models
Last-modified: Oct 8, 1993

Frequently Asked Questions about DEC PDP-8 models and options.

	By Douglas Jones, jones@cs.uiowa.edu
	(with help from many folks)


Sites known to carry FTPable copies of this file:

	rtfm.mit.edu:/pub/usenet/alt.sys.pdp8
	sunsite.unc.edu:/pub/academic/computer-science/history/pdp-8/doc


Contents

	What is this FAQ?
	What is a PDP-5?
	What is a PDP-8?
	What is a LINC-8?
	What is a PDP-8/S?
	What is a PDP-8/I?
	What is a PDP-8/L?
	What is a PDP-12?
	What is a PDP-8/E?
	What is a PDP-8/F?
	What is a PDP-8/M?
	What is a PDP-8/A?
	What is a VT78?
	What is a DECmate I?
	What is a DECmate II?
	What is a DECmate III?
	What is a DECmate III+?


What is this FAQ?
		
	The purpose of this document is to supplement the material in the
	primary "Frequently Asked Questions about the PDP-8" file with
	more detailed information about the hardware and options of the
	different models of the PDP-8 sold by DEC.

	Although this document is something of a history of the DEC PDP-8
	family, the primary purpose of this document is as a guide and
	general outline to the PDP-8 models and options likely to be
	encountered by those involved in collecting and restoring systems. 


What is a PDP-5?
	Date of introduction:  Aug 11, 1963, unveiled at WESCON.
	Date of withdrawal:    early 1967.
	Price: $27,000

	Technology:  Built with DEC System Modules, the original line of
		transistorized logic modules sold by DEC.  Supply voltages
		of +10 and -15 volts; the logic levels -3 (logic 1) and
		0 (logic 0).  Logic packaged on boards that were about 4.75
		inches wide with each card mounted in a metal frame with
		a 22 pin edge connector.

		Input output devices were connected to the daisy-chained
		I/O bus using military-style armored cables and connectors.
		Use of toggle switches (as opposed to slide switches) on
		the front panel was another vestige of military-style design.

	Reason for introduction:  This machine was inspired by the success
		of the CDC-160, Seymour Cray's 12 bit minicomputer, and by
		the success of the LINC, a machine that was built by DEC
		customers out of System modules.  These demonstrated that
		there was a market for a small inexpensive computer, and
		from the start, DEC's advertisements were aimed at this
		market.  "Now you can own the PDP-5 computer for what a
		core memory alone used to cost: $27,000", ran one 1964 ad.

	Reason for withdrawal:  The PDP-8 outperformed the PDP-5, and did
		so for a lower price.

	Compatability:  The core of the PDP-8 instruction set is present,
		but memory location zero is the program counter, and
		interrupts are handled differently.  The Group 1 OPR rotate
		instructions cannot be combined with IAC or CMA; this limits
		the ability of the PDP-5 to support code from later models.

		The machine did not support 3 cycle data-break (DMA transfers
		using memory to hold buffer address and word-count
		information), so many later PDP-8 peripherals could not
		be used on the PDP-5.  In addition, DMA transfers are not
		allowed outside the program's current 4K data field, severely
		limiting software compatability on systems with over 4K of
		memory where either interrupts or software initiated changes
		to the data field during a transfer would cause chaos.

	Standard configuration:  CPU with 1K or 4K of memory (2K and 3K
		versions were not available).

	Peripherals:

		An extended arithmetic element (EAE) was available; this was
		an I/O device, using IOT instructions to evoke EAE operations.
		As a result, it was not compatable with the later PDP-8 EAEs.
		In addition, machines with the EAE option had a different
		front panel from those without.

		The type 552 DECtape control and type 555 DECtape transports
		were originally developed for the PDP-5.

		After the PDP-8 was introduced, DEC offered a bus converter
		that allowed the PDP-5 to support standard PDP-8 negibus
		peripherals, so long as they avoided using 3-cycle data
		break transfers.  The standard 804 PDP-8 expander box was
		frequently sold as an upgrade to PDP-5 systems.


What is a PDP-8?
	Date of introduction:  1965 (Unveiled March 22, in New York)
	Date of withdrawal:    1968.
	Also known as:
		Classic PDP/8 (to point out lack of a model suffix)
		PCP-88, an OEM label, used Foxboro Corporation.
	Price: $18500

	Technology:  Mostly DEC R-series logic modules; these were originally
		discrete compponent transistor logic, but around the time
		the PDP-8 was introduced, DEC introduced the Flip Chip,
		a hybrid diode/resistor "integrated circuit" on a ceramic
		substrate.  These were pin-compatable with the discrete
		components they replaced, and DEC began to refer to their
		R-series modules as flip-chip modules and they even
		advertised the PDP-8 as an integrated circuit computer.
		A typical flip-chip module, the R111, had three 2-input nand
		gates and cost $14, with no price change from 1965 to 1970.

		S-series logic modules were also used; these are essentially
		the same as their R-series cousins, but with different
		pull-up resistors for higher speed at lower fanout.  Many
		R and S series modules have trimmers that must be tuned to
		the context, making replacement of such modules more complex
		than a simple board swap.

		As with the system modules used in the PDP-5, the supply
		voltages were +10 and -15 volts and the logic levels were
		-3 (logic 1) and 0 (logic 0).  Logic was packaged on boards
		that were 2.5 inches wide by 5 inches high.  The card edge
		connector had 18 contacts on 1/8 inch centers.  Some double
		width cards were used; these had two card edge connectors
		and were 5 1/8 inches wide.  Machine wrapped wire-wrap
		technology was used on the backplane using 24-gauge wire.

		The "negibus" or negative logic I/O bus used -3 and 0 volt
		logic levels in 92 ohm coaxial cable, with 9 coaxial cables
		bundled per connector card and 6 bundles making up the basic
		bus.  4 (originally 5) more bundles were required to support
		data-break (DMA) transfers.  Bus termination was generally
		kluged in with 100 ohm resistors clipped or wrapped into the
		backplane, although a bus terminator card was occasionally
		used.  Some time after the first year of production, flat
		ribbon cable made of multiple coaxial cables was used, and
		later still, flat mylar stripline cable was used (or misused
		when shielding was necessary but omitted).

		Core memory was used, with a 1.5 microsecond cycle time,
		giving the machine an add time of 3 microseconds.  4K of
		core occupied an aluminum box 6 inches on a side and needed
		numerous auxiliary flip-chips for support.  It is worth
		noting that the PDP-8 was about as fast as was practical
		with the logic technology used; only by using tricks like
		memory interleaving or pipelining could the machine have
		been made much faster.

	Reason for introduction:  This machine was inspired by the success
		of the PDP-5 and by the realization that, with their new
		Flip-Chip technology, DEC could make a table-top computer
		that could be powered by a single standard wall outlet;
		of course, adding any peripherals quickly increased the
		power requirement!

	Reason for withdrawal:  The PDP-8/I was less expensive, and after
		initial production difficulties, it equalled the performance
		of the PDP-8.

	Compatability:  The core of the PDP-8 instruction set is present,
		but the Group 1 OPR instruction IAC cannot be combined with
		any of the rotate instructions.  If RAR and RAL or RTR and
		RTL are combined, the results are unpredictable (simultaneous
		set and reset of bits of AC results in metastable behavior).
		The IOT 0 instruction was used for the internal type 189 ADC,
		and not for the later CAF (clear all flags) instruction.
		As a result, if the ADC option was not present, IOT 6004
		(or microcoded variants) would hang the machine.

		If the extended arithmetic element is present, the SWP
		(exchange AC and MQ) instruction does not work.  This
		works on later models when the EAE is present, although
		it was only documented with the introduction of the
		PDP-8/E.  Finally, the EAE lacks the SCL (shift count
		load) instruction that is present on later models.

		On machines with over 8K, an attempt to change the
		data field to a non-existant field caused a bizarre double-
		indirect and skip instruction execution that must be
		accounted for in memory diagnostics.

	Standard configuration:  The PDP-8 was sold as a CPU with 4K of
		memory, a 110 baud current loop teletype interface and an
		ASR 33 Teletype.  The standard in-cabinet logic includes
		support for the full negibus interface, including data-break
		(DMA) transfers.

		Both a rack-mount model with rosewood trim and an elegant
		plexiglass enclosed table-top configuration were standard.
		Under the skin, basic machine occupied a volume 33 inches
		high by 19 inches wide by 22 inches deep.  The two halves
		of the backplane were mounted vertically, like the covers
		of a book, with the spine in back and circuit modules
		inserted from the two sides.  Sliding the CPU out of the
		relay rack or removing the plexiglass covers allows the
		backplane to be opened for access to the wires.

	Expandability:  In-cabinet options include the type 182 extended
		arithmetic element (EAE), the type 183 memory extension
		control subsystem, and the type 189 low performance
		analog to digital converter (ADC).  Prewired backplane
		slots were reserved for all of these.

		Expansion beyond 4K of memory requires an additional
		type 804 rack and power supply.  A type 184 memory module
		is needed for each 4K field of memory, up to a maximum of
		32K.  The rack-mount CPU occupied a large part of one rack,
		allowing room for a single type 184 memory expansion module
		below the CPU; generally, a second rack was needed for any
		added peripherals or memory.

		At the end of the production run, some PDP-8 systems were
		sold with PDP-8/I memory, allowing room for an additional
		4K without need for an expansion chassis.  These nonstandard
		machines were very difficult to maintain!

	Peripherals:  At the time of introduction, the following negibus
		peripherals were offered.

		-- Type 750C high speed paper tape reader and control.
		-- Type 75E high speed paper tape punch and control.
		-- Type 138E analog to digital converter and multiplexor.
		-- Type 34D oscilloscope display (dual digital to analog).
		-- Type 350B incremental (CalComp) plotter control.
		-- Type 451 card reader and control.
		-- Type 450 card punch control for IBM Type 523 punch.
		-- Type 64 (later 645) Mohawk line printer and control.
		-- Type RM08 serial magnetic drum system (up to 256K words).
		-- Type 552 DECtape control (for type 555 DECtape drives).
		-- Type 57A magnetic tape control (IBM type 729 drive).
		-- Type 580 magnetic tape system.

		By 1967, the following peripherals had been added to the line:

		-- Type TC01 DECtape control for up to 8 TU55 transports.
		-- Type AF01 analog to digital converter and multiplexor.
		-- Type AA01A 3 channel digital to analog (scope display).
		-- Type AX08 parallel digital input port.

		By 1968, the following new peripheral had been added:

		-- Type DF32 fixed head disk system (up to 256K words).
		-- Type BE01 OEM version of the TC01 (no blinking lights).
		-- Type BE03 dual TU55 drive for the TC01.

		Finally, as DEC abandoned the negibus, they introduced the
		DW08B negibus to posibus converter so newer posibus
		peripherals could be used on older negibus machines.
		
		
What is a LINC-8?
	Date of introduction:  1966 (during or before March)
	Date of withdrawal:    1969 (displaced by PDP-12)
	Price: $38,500

	Technology:  DEC Flip Chip modules, as in the PDP-8, with a LINC CPU
		partially reimplemented in Flip Chips and partially emulated
		with PDP-8 instructions.  (The original LINC was built from
		the same System Modules used in the PDP-5.)

	Compatability:  Identical to the PDP-8.

	Standard configuration:  The combined PDP-8/LINC CPU, plus
		4K of memory was central to the system.  The set of
		peripherals bundled with the machine was impressive:

		-- An ASR 33 Teletype modified for the LINC character set.
		-- Two LINCtape drives.
		-- 8 analog to digital converter channels with knob inputs.
		-- Another 8 ADC channels with jack inputs.
		-- 18 programmable relay outputs, good up to 60 Hz.
		-- 1 Tektronics 560 oscilliscope.

		The X and Y axis control for the scope came from DACs
		attached to the LINC's AC and MB registers, respectively.

	Expandability:

		Up to 3 additional pairs of LINCtape drives could be added,
		for a total of 8 drives.  Each pair of drives cosmetically
		resembled the type BE03 dual DECtape transport, but single
		drives were not available.

		Up to 2 additional ranks of 8 ADC channels could be added.

		A second oscilliscope could be added.


What is a PDP-8/S?
	Date of introduction:  1966 (Unveiled, Aug 23, WESCON, Los Angeles).
	Date of withdrawal:    1970.
	Price: $10,000

	Technology:  DEC Flip Chip modules and core memory, as in the
		PDP-8.  Unlike the PDP-8, the PDP-8/S memory was mounted
		on quad-height single-width boards that plugged into the
		standard flip-chip sockets.

	Reason for introduction:  This machine was developed as a
		successful exercise in minimizing the cost of the machine.
		It was the least expensive general purpose computer made
		with second generation (discrete transistor) technology,
		and it was one of the smallest such machines to be mass
		produced (a number of smaller machines were made for
		aerospace applications).  It was also incredibly slow,
		with a 36 microsecond add time, and some instructions
		taking as much as 78 microseconds.  By 1967, DEC took the
		then unusual step of offering this machine for off the
		shelf delivery, with one machine stocked in each field
		office available for retail sale.

	Reason for withdrawal:  The PDP-8/L vastly outperformed the PDP-8/S,
		and it did so at a lower price.

	Compatability:  The core of the PDP-8 instruction set is present,
		but there are a sufficient number of incompatabilities
		that, as with the PDP-5, many otherwise portable "family
		of 8" programs will not run on the PDP-8/S.  Perhaps the
		worst incompatability is that the Group 1 OPR instruction
		CMA cannot be combined with any of the rotate instructions;
		as with the PDP-8, IAC also cannot be combined with rotate.

	Standard configuration:  CPU with 4K of memory, plus 110 baud current
		loop teletype interface.  Both a rack-mount table-top
		versions were sold (both 9" high by 19" wide by 20"? deep).

		The rack mount could be slid out of the rack on slides for
		for maintenance.  A variant PDP-8/S was packaged vertically
		in the base of an ASR33 teletype!

	Expandability:  The CPU supported the standard PDP-8 negibus, but
		I/O bandwidth was 1/5 that of the PDP-8.  Thus, most, but
		not all PDP-8 peripherals could be used.  A few DEC
		peripherals such as the DF32 came with special options to
		slow them down for compatability with the PDP-8/S.  The
		speed problems were such that there was never any way to
		attach DECtape to this machine.


What is a PDP-8/I?
	Date of introduction:  1968 (announced before December '67)
	Date of withdrawal:    1971.

	Technology:  DEC M-series logic modules, called M-series flip-chips
		as the term flip-chip was applied to the module format
		instead of to DEC's hybrid integrated circuits.  M-series
		modules used TTL chips, with a +5 supply, packaged on the
		same format board as was used with the original flip-chips,
		but with double-sided card-edge connectors (36 contacts
		instead of 18).  Modules were limited to typically 4 SSI
		ICs each.  The M113, a typical M-series module, had 10
		2-input nand gates and cost $23 in 1967 (the price fell to
		$18 in 1970).  Wire-wrapped backplanes used 30-gauge wire.

		The PDP-8/I, as originally sold, supported the then-standard
		PDP-8 negibus.  4K words of core were packaged in a 1 inch
		thick module made of 5 rigidly connected 5 by 5 inch
		two-sided printed circuit boards.  Connectors and support
		electronics occupied an additional 32 backplane slots.

		Nominally, the core memory (which, curiously, used a negative
		logic interface!) was supposed to run at a 1.5 microsecond
		cycle time, but many early PDP-8/I systems were delivered
		running at a slower rate because of memory quality problems.
		DEC went through many vendors in the search for good memory!
		The memory interface was asynchronous, allowing the CPU to
		delay for slow memory.  DEC continued to make the classic
		PDP-8 until the problems with memory speed were solved.

	Reason for introduction:  This machine was developed in response
		to the introduction of DIP component packaging of TTL
		integrated circuits.  This allowed a machine of about
		the same performance as the original PDP-8 to fit in about
		half the volume and sell for a lower price.

	Reason for withdrawal:  The PDP-8/E made slight performance
		improvements while undercutting the price of the PDP-8/I.

	Compatability:  The core of the PDP-8 instruction set is present,
		and unlike the original PDP-8, IAC can be combined with
		rotate in a single microcoded Group 1 OPR instruction.
		Combined RAR and RAL or RTR and RTL produce the logical
		and of the expected results from each of the combined shifts.

		If the extended arithmetic element is present, the SWP
		(exchange AC and MQ) instruction works, but this was not
		documented.

		On large memory configurations, memory fetches from a
		nonexistant memory field take about 30 microseconds (waiting
		for a bus timeout) and then they return either 0000 or 7777
		depending on whether the fetch was from an even or odd field.

	Standard configuration:  CPU with 4K of memory, plus 110 baud current
		loop teletype interface.  Pedestal, rack-mount and table-top
		versions were made.  In the pedestal version, the logic
		filled the body of the pedestal, with the console lights
		and switches on top.  In one rack-mount version, the machine
		was built on a backplane that was bolted to the back of the
		rack, while the front panel hung from the front (unlike all
		other rack-mounted PDP-8 models, this version could not be
		swung out for maintenance on chassis slides).  Finally,
		a boxed version was sold that could be used on table-top
		or mounted on chassis slides.

	Expandability: 4K of memory could be added internally, and additional
		memory could be added externally using a rack-mounted MM8I
		memory expansion module for each 4K or 8K addition over 8K.

		The backplane of the PDP-8/I was prewired to hold a Calcomp
		plotter interface, with the adjacent backplane slot reserved
		for the cable connection to the plotter.

		Initially, the CPU was sold with bus drivers for the PDP-8
		negibus, allowing this machine to support all older DEC
		peripherals, but later machines were sold with posibus
		interfaces, and DEC made an effort to convert earlier
		machines to the posibus in the field.

		A posibus to negibus converter, the DW08A, allowed use of
		all older PDP-8 peripherals, with small modifications.
		The change from negibus to posibus during the period of
		PDP-8/I production leads to confusion because surviving
		systems may have any of three I/O bus configurations:
		Negibus, early posibus, or final posibus.  The early
		posibus used the same connectors and cables as the negibus,
		with only 9 conductors per connector, while the final
		posibus used both sides of the connector paddles, for 18
		bus lines per connector.  To add to this confusion, some
		negibus PDP-8/I systems were rewired to use 18 conductor
		posibus cables while still using negative logic!

		Eventually, an add-on box was sold that allowed PDP-8/E
		(OMNIBUS) memory to be added to a PDP-8/I.  Additionally,
		Fabritek sold a 24K memory box for the 8/I.


What is a PDP-8/L?
	Date of introduction:  1968 (announced before August '68)
	Date of withdrawal:    1971.
	Price: $8,500

	Technology:  DEC M-series flip Chip modules, as in the PDP-8/I,
		with the same core memory as the 8/I, but the memory cycle
		cycle time was downgraded to 1.6 microseconds to avoid the
		speed problems of the -8/I.

		The positive I/O bus, or posibus, was a 100 ohm bus clamped
		between 0 and 3 volts with TTL drivers and receivers.  This
		was packaged with 18 signal lines per 2-sided interconnect
		cable, using mylar ribbon cable in most cases.  Electrically,
		coaxial cable could be used, but the slots in the CPU
		box were too small to allow convenient use of this option.

	Reason for introduction:  This machine was developed as a moderately
		successful exercise using M-series logic to produce a
		lower cost but moderately fast machine.  The idea was to
		cut costs by limiting provisions for expansion.

	Reason for withdrawal:  The PDP-8/E made performance improvements
		while slightly undercutting the price of the PDP-8/L.

	Compatability:  The core of the PDP-8 instruction set is present,
		but all Group 3 OPR instructions are no-ops, even the
		Group 3 version of the CLA instruction.  This is because
		there was no provision made for adding an EAE to this machine.
		Microcoding RAR and RAL together works as in the PDP-8/I.
		Finally, a new front panel feature was added, the protect
		switch.  When thrown, this makes the last page of the last
		field of memory read-only (to protect your bootstrap code).

		The instruction to change the data field on an 8/L becomes
		a no-op when the destination data field is non-existant; on
		all other machines, attempts to address non-existant fields
		are possible.  When the 8/L is upgraded with memory expander
		boxes supporting a total of over 8K of memory, access to
		nonexistant data fields becomes possible and always returns
		0000 on read.

	Standard configuration:  A CPU with 4K of memory, plus 110 baud
		current loop teletype interface was standard.  Both
		rack-mount and table-top versions were sold (both 9" high
		by 19" wide by 21" deep).  The backplane was on top,
		with modules plugged in from the bottom.  The rack-mount
		version could be slid out for maintenance.

	Expandability:  The CPU supported a new bus standard, the PDP-8
		posibus.  There is little space for in-box peripherals, but
		an expander box with the same volume as the CPU was available,
		the BA08A; this was originally intended to hold an additional
		4K of memory and provide room for additonal in-box peripheral
		interfaces such as the PDP-8/I Calcomp plotter interface,
		but this box could be used for peripherals only if other
		memory expansion boxes were used.

		DEC eventually offered the BM12L, an 8K expansion box,
		allowing 12K total memory on a PDP-8/L.  Curiously, this
		contains precisely the modules needed to upgrade a 4K
		PDP-8/I or PDP-12 to an 8K machine, or to populate an MM8I
		box to add 8K of additional memory to an 8/I or PDP-12.

		Finally, DEC eventually offered a box allowing PDP-8/E
		(OMNIBUS) memory to be used with the PDP-8/L.  PDP-8/L
		configurations with over 8K of memory were awkward
		because the front panel only showed one bit of the extended
		memory address.  As a result, extra lights and switches
		for the additional bits of the memory address were
		mounted on the front of the memory expander boxes for
		the large configurations.

		Posibus peripherals were quickly produced by changing the
		bus interface logic and backplane slots on old negative bus
		peripherals, but many early PDP-8/L systems were sold with
		DW08A bus level converters to run old negibus peripherals.

		Posibus peripherals introduced after the PDP-8/L (and also
		used with posibus versions of the PDP-8/I) included:

		-- The TC08P DECtape controller (for 8 TU55 or 4 TU56).
		-- The DF32D-P fixed head disk controller (a posibus DF32).
		-- The FPP-12 floating point processor.
		-- The TR02 simple magnetic ttape control.
		-- The RK08 disk subsystem, 4 disk packs, 831,488 words each.


What is a PDP-12?
	Date of introduction:  1969 (February or earlier).
	Date of withdrawal:    1973.
	Price: $27,900

	Technology:  DEC M-series flip Chip modules, as in the PDP-8/I.

	Reason for introduction:  This machine was developed as a follow-up
		to the LINC-8.  Originally it was to be called the LINC-8/I,
		but somehow it got its own number.  In effect, it
		was a PDP-8/I with added logic to allow it to execute most
		of the LINC instruction set, with trapping and software
		emulation used more selective than on the LINC-8.

	Reason for withdrawal:  The LAB-8/E and the LAB-11 (a PDP-8/E
		and a PDP-11/20 with lab peripherals) eventually proved
		the equal of the PDP-12 in practice, and LINC compatability
		eventually proved to be of insufficient value to keep the
		machine alive in the marketplace.
		
	Compatability:  This machine is fully compatable with the PDP-8/I,
		with additional instructions to flip from PDP-8 mode to
		LINC mode and back.  IOT 0 could enable the API, causing
		trouble with later PDP-8 code that assumes IOT 0 is "Clear
		all flags".  Also, the DECtape instruction DTLA (6766)
		becomes part of a stack-oriented extension to the
		instruction set, PUSHJ.

	Standard configuration:  PDP-8/LINC CPU with 4K of memory, plus 110
		baud current loop interface, plus output relay registers.
		In addition, the standard configuration included either
		two TU55 or one TU56 drive, with a PDP-12 only controller
		allowing it to handle either LINCtape or DECtape.  In
		additoon, a 12" scope was always included, with a connector
		that can connect to a second scope.

	Expandability:  An analog to digital converter and multiplexor
		was needed to fully support knob-oriented LINC software.

		Other options included:

		-- the KW12 programmable lab clock.
		-- additional TU55 or TU56 drives (up to 8 transports).
		-- the PC05 paper tape reader punch.


What is a PDP-8/E?
	Date of introduction:  1970 (during or before August).
	Date of withdrawal:    1978.
	Also known as:
		Industrial-8 (with a red color scheme)
		LAB-8/E (with a green color scheme)
	Price: $7,390

	Technology:  Nominally made from DEC M-series flip Chip modules,
		but in a new format, quad-wide (10.5 inches wide), double-
		height (9 inches, including card-edge connector, excluding
		handles).  SSI and MSI TTL logic were used on these boards,
		and the entire CPU fit on 3 boards.

		Interconnection between boards was through a new bus, the
		OMNIBUS.  This eliminated the need for a wire-wrapped
		backplane, since all slots in the bus were wired identically.
		A new line of peripheral interfaces was produced, most being
		single cards that could be plugged directly into the inside
		the main enclosure.  These included a set of posibus adapters
		allowing use of older peripherals on the new machine.

		Interboard connectors were needed for some multiboard
		options, including the CPU and memory subsystems.  These
		used standard 36 pin backplane connectors on the opposite
		side of the board from the backplane.  Some boards, notably
		memory boards, had a total of 8 connector fingers, 4 for
		the omnibus and 4 for interboard connectors.

		The core memory cycle time was 1.2 or 1.4 microseconds,
		depending on whether a read-modify-write cycle was involved.
		A 4K core plane was packaged on a single quad-wide double-
		high board, with most of the drive electronics packed onto
		two adjacent boards.  Soon after the machine was introduced,
		an 8K core plane was released in the same format.

	Reason for introduction:  The cost of the PDP-8/I and PDP-8/L was
		dominated by the cost of the interconnect wiring, and this
		cost was a result of the use of small circuit boards.  By
		packing a larger number of chips per board, similar function
		could be attained in a smaller volume because less interboard
		communication was required.  The PDP-8/E exploited this to
		achieve a new low in cost while attaining a new high in
		performance.

	Reason for withdrawal:  This machine was slowly displaced by the
		PDP-8/A as the market for large PDP-8 configurations
		declined in the face of pressure from 16 bit mini and
		microcomputers.

	Compatability:  As with the PDP-8/I and PDP-8/L, there are no limits
		on the combination of IAC and rotate instructions.  Unlike
		the early machines, basic Group 3 OPR operations for loading
		and storing the MQ register work even if there is no extended
		arithmetic element.  Finally, a new instruction was added,
		BSW; this swaps the left and right bytes in AC, and is
		encoded as a Group 1 OPR instruction using the "double the
		shift count bit".

		An odd quirk of this machine is that the RLR RAR combination
		ands the AC with the op-code, and the RTR RTL combination
		does an effective address computation loading the high 5 bits
		of AC with the current page and the lower bits of AC with the
		address field of the OPR instruction!

		The EAE has a new mode, mode B.  Previous EAE designs were
		single-mode.  Mode B supports a large set of 24 bit
		operations and a somewhat more rational set of shift
		operations than the standard EAE.  All prior EAE designs
		would hang on the microcoded CLA NMI (clear/normalize)
		instruction applied to a nonzero AC.  This instruction
		is redefined to be a mode changing instruction on the 8/E.

	Standard configuration:  A CPU with 4K of memory, plus 110 baud
		current loop teletype interface.  Both a rack-mount table-top
		versions were sold (both 9" high by 19" wide by 21" deep).
		The rack mount version was mounted on slides for easy
		maintenance.  The OMNIBUS backplane was on the bottom,
		with boards inserted from the top.

		The standard OMNIBUS backplane had 20 slots, with no
		fixed assignments, but the following conventional uses:

		-- KC8E programmer's console (lights and switches)
		-- M8300 \_ KK8E CPU registers
		-- M8310 /  KK8E CPU control
		-- 
		-- 
		-- M833  - Timing board (system clock)
		-- M865  - KL8E console terminal interface.
		--
		--
		--   -- space for more peripherals
		--
		--
		-- M849  - shield to isolate memory from CPU
		-- G104  \
		-- H220   > MM8E 4K memory
		-- G227  /
		--
		--   -- space for more memory
		--
		-- M8320 - KK8E Bus terminator

		Most of the early boards with 3 digit numbers were defective
		in one way or another, and the corrected boards added a
		trailing zero.  Thus, the M833 was generally replaced with
		an M8330, and the M865 was replaced with the M8650.

	Expandability:  The following are among the OMNIBUS boards that
		could be added internally:

		-- M8650 - KL8E RS232 or current loop serial interface.
		-- M8340 \_ Extended arithmetic element.
		-- M8341 /  (must be attached in two slots adjacent to CPU.
		-- M8350 - KA8E posibus interface (excluding DMA transfers).
		-- M8360 - KD8E data break interface (one per DMA device).
		-- M837  - KM8E memory extension control (needed for over 4K).
		-- M840  - PC8E high speed paper tape reader-punch interface.
		-- M842  - XY8E X/Y plotter control.
		-- M843  - CR8E card reader interface.

		There were many other internal options.  There was room in
		the basic box for another 20 slot backplane; taking into
		account the 2 slots occupied by the M935 bridge between
		the two backplanes, this allowed 38 slots, and a second
		box could be added to accomodate another 38 slot backplane,
		bridged to the first box by a pair of BC08H OMNIBUS
		extension cables.

		Given a M837 memory extension control, additional memory
		could be added in increments of 4K by adding G104, H220,
		G227 triplets.  The suggested arrangement of boards on the
		OMNIBUS always maintained the M849 shield between memory
		other options.  The one exception was that the M8350 KA8E
		and M8360 KD8E external posibus interfaces were typically
		placed at the end of the OMNIBUS right before the terminator.

		The following options were introduced later, and there were
		many options offered by third party suppliers.

		-- G111  \
		-- H212   > MM8EJ 8K memory
		-- G233  /
		-- M8357 -- RX8E interface to RX01/02 8" diskette drives.
		-- M7104 \
		-- M7105  > RK8E RK05 Disk Interface
		-- M7106 /
		-- M8321 \
		-- M8322  \ TM8E Magtape control for 9 track tape.
		-- M8323  /
		-- M8327 /

		At one point, DEC packaged a PDP-8/E in a desk with no
		front panel controls other than power and bootstrap switch,
		along with an RX01 accessable from the front and a VT50
		on top.  This was sold as the Class-ic system, with an
		intended market in the classroom (hence the name); it was
		the forerunner, in terms of packaging, of many later DEC
		office products.
		

What is a PDP-8/F?
	Date of introduction:  1972.
	Date of withdrawal:    1978.

	Technology:  an OMNIBUS machine, as with the PDP-8/E.  First use
		of a switching power supply in the PDP-8 family.

	Reason for introduction:  The PDP-8/E had a large enough box and
		a large enough power supply to accomodate a large
		configuration.  By shortening the box and putting in a
		small switching power supply, a lower cost OMNIBUS machine
		was possible.

	Reason for withdrawal:  The PDP-8/A 800 displaced this machine,
		providing similar expansion capability at a lower cost.

	Compatability:  The PDP-8/F used the PDP-8/E CPU and peripherals.

	Standard configuration:  Identical to the PDP-8/E, except that
		the KC8E front panel was replaced with a KC8M front panel
		that had LEDs instead of incandescent lights; this front
		panel could also be installed on PDP-8/E systems, but the
		PDP-8/E front panel could not be used on a PDP-8/F because
		of the lack of a +8 supply for the lights.  The original
		PDP-8/F box had a defective power supply, but a revised
		(slightly larger) box corrected this problem.

	Expandability:  This machine could be expanded using all PDP-8/E
		OMNIBUS peripherals, including the external expansion
		chassis.  The relatively small internal power supply and
		the lack of room for a 20 slot bus expander inside the
		first box were the only limitations.  There were minor
		compatability problems with some options, for example,
		the power-fail auto-restart card, as originally sold, was
		incompatable with the PDP-8/F power supply.


What is a PDP-8/M?
	Date of introduction:  1972.
	Date of withdrawal:    1978.

	Technology:  This machine was a PDP-8/F (with a PDP-8/E CPU)

	Reason for introduction:  DEC knew that OEM customers were an
		important market, so they packaged the PDP-8/F for this
		market, with no hardware changes behind the front panel.

	Reason for withdrawal:  Same as the PDP-8/F

	Compatability:  The PDP-8/M used the PDP-8/E CPU and peripherals.

	Standard configuration:  Identical to the PDP-8/F, except that
		the KC8M front panel was replaced with a minimal function
		panel and the color scheme was different.  Because of this,
		one of the following options were required:

		-- M848  -- KP8E Power fail and auto-restart.
		-- M847  -- MI8E Hardware Bootstrap Loader.

	Expandability:  All options applying to the PDP-8/F applied.  In
		addition, the KC8M front panel (standard with the PDP-8/F)
		was available as an option.


What is a PDP-8/A?
	Date of introduction:  1975
	Date of withdrawal:    1984

	Technology:  This machine used the OMNIBUS with a new single-board
		CPU, made possible by the use of TTL MSI and LSI components
		on an extra-wide board (formally, hex high, double high)
		with 6 connector fingers instead of the usual 4.

	Reason for introduction:  Using TTL MSI and LSI components, DEC
		was able to reduce the PDP-8 CPU to a single hex wide
		double high card.  Similarly, they were able to make an
		4K core memory card, and later, an 8K board in this
		format, and they were able to introduce a static RAM card
		using semiconductor memory.  The net effect was to reduce
		the minimum system to 3 boards.

		In addition, the market for the PDP-8 was dominated by
		small systems, with fewer and fewer customers needing
		large-scale expandability.  Thus, the 20 slot backplane
		of the early Omnibus machines was too big; with the new
		single board CPU and memory, a 12 slot backplane was enough.

	Reason for withdrawal:  The market for the PDP-8 family was
		shrinking in the face of pressure from larger minicomputers
		and the new monolithic microcomputers.  After 1975, many
		PDP-8 sales were to captive customers who had sufficient
		software investments that they could not afford to move.
		Only the word-processing and small business markets
		remained strong for first-time PDP-8 sales, and in these,
		the specialized DEC VT-78 and DECmate machines were more
		cost effective than the open architecture OMNIBUS machines.
		
	Compatability:  The new PDP-8/A CPU was largely compatable with
		the PDP-8/E CPU, except that the combination of RTR and
		RTL (Group 1 OPR instructions) loaded the next address.
		The power-fail auto-restart option included the standard
		skip on power low instruction, but also a new skip on
		battery empty instruction to test the battery used for
		back-up power on the new solid state memory.

	Standard configuration:  The PDP-8/A was sold with a new short
		OMNIBUS backplane, mounted on its side above a power supply
		and a battery to back up the solid state memory.  The
		minimum configuration included a limited function control
		panel and the following components on the bus:

		-- M8315 -- KK8A CPU board
		-- M???? -- MS8A 1K to 4K solid state memory.
		-- M8316 -- DKC8AA serial/parallel interface and clock.

		The M8316 board contained a remarkable but useful
		hodgepodge of commonly used peripherals, including the
		console terminal interface, a parallel port, the power/fail
		auto-restart logic, and a 100 Hz real time clock.

		The original configuration sold had a 10 slot backplane and
		a poor power supply.  The later base model had a 12 slot
		backplane, the 8/A 400.

	Expandability:  All PDP-8/E peripherals and options could be used
		with the PDP-8/A.  The KK8A cpu was not as fast as the KK8E
		used in the PDP-8/E, but the KK8E CPU could be substituted
		for the KK8A CPU, and many PDP-8/A systems were sold with
		this substitution.

		A box with a 20 slot backplane, the 8/A 800, was available
		for large configurations.  A pair of PDP-8/A backplanes
		could be connected using BC08H cables, and there was a
		special cable, the BC80C, for connecting a hex wide 8A
		backplane to a PDP-8/E, -8/F or -8/M backplane.

		By late 1975, the PDP-8/A was being sold in a workstation
		configuration, with the CPU and dual 8" diskette drives
		in a desk with a video terminal (VT57?) on top.  This
		followed the pattern set by the Class-ic packaging of the
		PDP-8/E, but it was aimed at the word-processing market.

		The following additional PDP-8/A (hex) boards were offered:

		-- G649  \_ MM8AA 8K Core stack (too slow for 8/E CPU!).
		-- H219A /  MM8AA 8K Core memory control.
		-- G650  \_ MM8AB 16K Core stack (ok for 8/E CPU!).
		-- H219B /  MM8AB 16K Core memory control.
		-- M???? -- MR8F 1K ROM (overlayable with RAM).
		-- M8317 -- KM8A memory extender (with variations).
		-- M8319 -- KL8A 4 channel RS232 or current loop serial I/O.
		-- M???? -- RL8A controller for 1 to 4 RL01/RL02 disk drives.

		-- M8416 -- KT8AA Memory management unit.
		--          KC8AA Programmer's Console (requires M8316)
		-- M8417 -- MSC8DJ 128K DRAM MOS Memory.

		Note that memory extension to 128K was a new PDP-8/A feature
		that was necessarily incompatable with the older PDP-8 memory
		expansion options, although the conventional PDP-8 memory
		expansion instructions still operate correctly on the first
		32K.  Access to additional fields involved borrowing IOT
		instructions that were previously dedicated to other devices.

		The MM8A options require the use of a box with a -20V power
		supply, either the 8A-500 or the 8A-800.  Also, the use of
		the MSC8 DRAM memory cards requires a CPU that supports
		the memory stall signal, early PDP-8/E CPUs did not.


What is a VT78?
	Date of introduction:  1978
	Date of withdrawal:    1980 (Displaced by the DECmate)
	Also known as:  DECstation 78 

	Technology:  Intersil 6100 microprocessor, packaged in a VT52 case.
		The 6100 processor was able to run at 4 MHz, but in the
		VT78, it was only clocked at 2.2 MHz because of the speed
		of the DRAM used and the deliberate use of graded out chips.

	Reason for introduction:  Using TTL MSI and LSI components, DEC
		could pack their CPU into vacant space in a standard
		terminal case, allowing PDP-8 systems to compete with
		personal computers in the small business and office
		automation market.  This was a natural follow-on to the
		workstation configurations in which the PDP-8/A was already
		being sold.

	Compatability:  The Group I OPR combinations RAL RAR and RTL RTR
		are no-ops.  Unlike all earlier PDP-8 models, autoindex
		locations 10 to 17 (octal) only work in page zero mode;
		these operate like all other memory location when addressed
		in current page mode from code running on page zero.  Other
		than this, it is fully PDP-8/E compatable, even at the level
		of I/O instructions for the standard periperals; this was
		the last PDP-8 to offer this level of compatability.

		It was not possible to continue from a halt without
		restarting the machine.  In addition, none of the peripherals
		available on this machine needed DMA (data break) transfers.

	Standard configuration:  The VT78 was sold with 16k words of DRAM
		with the keyboard and display of the VT52 terminal.  An RX01
		dual 8" diskette drive was standard, packaged in the
		pedestal under the terminal.  The console (device 03/04),
		the printer (output only) port (device 66), and the serial
		ports (devices 30/31 and 32/33) are compatable with the
		M8650 KL8E, with the latter extended to allow software
		controlled baud rates selection.  The parallel port
		(device 47) and 100Hz clock are compatable with the
		comparable PDP-8/A options on the M8316 DKC8AA.

		The standard ROM boots the system from the RX01 after setting
		the baud rates to match that selected by the switches on the
		bottom of the VT52 case.

	Expandability:  This was a closed system, with few options.  The
		base configuration was able to support two RX01 drives
		(later RX02), for a total of 4 transports.  Various boot
		ROM's were available, including a paper-tape RIM loader ROM
		for loading diagnostics from tape.  Another ROM boots the
		system from a PDP-11 server in the client/server
		configuration used by WPS-11.


What is a DECmate I?
	Date of introduction:  1980
	Date of withdrawal:    1984 (Phased out in favor of the DECmate II)
	Also known as:  DECmate (prior to the DECmate II, no suffix was used)

	Technology:  Based on the Intersil/Harris 6120 microprocessor,
		packaged in a VT-100 box with keyboard and display.

	Reason for introduction:  This machine was aimed primarily at
		the market originally opened by the VT78, using the IM6120
		as a substitute for the older 6100 chip and optimizing
		for minimum cost and mass production efficiency.

	Compatability:  A new feature was introduced in the 6120
		microprocessor:  The Group I OPR combination RAL RAR was
		defined as R3L, or rotate accumulator 3 places left, so
		that byte swap (BSW) is equivalent to R3L;R3L.  RTR RTL
		remained a no-op, as in the 6100.

		Also, the EAE operations not implemented in the basic
		CPU cause the CPU to hang awaiting completion of the
		operation by a coprocessor.  Unfortunately, no EAE
		coprocessor was ever offered.

		The printer port offered software baud-rate selection
		compatable with the VT78 baud-rate selection scheme.
		The data communications option was completely incompatable
		with all previous PDP-8 serial ports.

		The console and printer ports are not fully compatable with
		the earlier PDP-8 serial ports.  Specifically, on earlier
		serial interfaces, it was possible to test flags without
		resetting them, but on the DECmate machines, testing the
		keyboard input flag always resets the flag as a side effect.
		In addition, on the console port, every successful test of
		the flag must be followed by reading a character or the
		flag will never be set again.

		It was not possible to continue from a halt without
		restarting the machine.

		The large amount of device emulation performed by the CPU
		in supporting screen updates severely limits the ability of
		the system to run in real time.

	Standard configuration:  The DECmate I was sold with 32k words of
		memory, with a small additional control memory added to
		handle control/status and boot options.  The console
		terminal keyboard and display functions are largely
		supported by control memory routines (as opposed to having
		separate hardware for terminal support, as in the VT78).

		DECmate I came with an integral printer port, compatable
		with the VT78 (device 32/33), and it had an RX02 dual 8 inch
		diskette drive, mounted in the short cabinet under the
		terminal/CPU box.  A 100Hz clock was included, as in the
		VT78 and PDP-8/A.

	Expandability:  This was a closed system, with limited options.
		Specifically, a second RX02 could be connected (or an RX01,
		because that had a compatable connector), the DP278A and
		DP278B communications boards (really the same board, but
		the DP278B had 2 extra chips), and the RL-278 disk
		controller, able to accomodate from 1 to 4 RL02 rack mount
		disk drives.

		When the DP278A option is added, additional control
		memory is included containing a ROM-based terminal
		emulator allowing diskless operation.  The emulator is
		an extended VT100 subset that is essentially compatable
		in 80 column mode.  The DP278A option could support
		both asynchronous and synchronous protocols, and the DP278B
		could handle SDLC and other nasty bit-stuffing protocols.

		Various pedestal and desk configurations were sold for
		housing the RX01 and RX02 drives, most being teacart style
		designs, but there was also a pedestal version that was
		essentially a repackaging of the RX02 with new 8 inch
		disk transports (physically incompatable with earlier
		DEC transports).

What is a DECmate II?
	Date of introduction:  1982
	Date of withdrawal:    1986 
	Price: $1,435

	Technology:  Based on the 6120 microprocessor, this shared the same
		packaging as DEC's other competitors in the PC market, the
		Rainbow (80x86 based) and the PRO-325 (PDP-11 based).

	Reason for introduction:  This machine was introduced in order to
		allow more flexibility than the DECmate I and to allow more
		sharing of parts with the VT220 and DEC's other personal
		computers.

	Compatability:  Same as the DECmate I, except it could continue
		from a halt.  There was better hardware for device emulation
		support, allowing for somewhat better real-time performance,
		and the data communications port was an incompatable
		improvement on the incompatable DECmate I communications
		port.  The improved data communications port make it
		essentially as powerful as the DP-278B on the DECmate I,
		with a more efficient but bizarre software interface.

	Standard Configuration:  The DECmate II was sold with 32K of program
		memory, plus a second full bank for dedicated control
		panel functions, an integral RX50 dual 5 1/4 inch diskette
		drive with an 8051 controller chip, a printer port, a 100Hz
		real-time clock, a data communications port, and interfaces
		to the monitor and keyboard.  The diskette drive can read
		single-sided 48 track-per-inch diskettes, allowing the
		possibility of reading (but not writing) IBM PC diskettes.

	Expandability:  This was the most open of the DECmate systems, with
		a number of disk options:  An additional pair of RX50 drives
		could be added, and with the RX78 board, it could support
		a pair of dual 8 inch drives, either RX01 or RX02.

		As an alternative to the RX78, there was a controller for
		an MFM hard drive.  The interface to the RX78 board wasn't
		fully compatable with earlier interfaces to RX01 and RX02,
		and there was no way to have both an RX78 and an MFM drive.
		The MFM drive could be up to 64 MB, with 16 sectors per
		track, 512 bytes each and at most 8 heads and 1024 (or
		possibly 4096) cylinders.  A power supply upgrade was needed
		to support the MFM drive.  DEC sold this machine with 5,
		10 and 20 meg hard drives, Seagate ST-506, 412, and 225
		respectively.

		A graphics board supporting a color monitor could be added
		in addition to the monochrome console display.

		A coprocessor board could be added, with communication to
		and from the coprocessor through device 14.  DEC sold three
		boards, an APU board (Z80 and 64K), and two XPU boards (Z80,
		8086 and either 256K or 512K).  If these added processors
		are used, the 6120 processor is usually used as an I/O server
		for whatever ran on the coprocessor.  The XPU boards used
		a Z80 for I/O support, so 8086 I/O was very indirect,
		particularly if it involved I/O to a PDP-8 device that was
		emulated from control memory!  Despite this, I/O through
		the DECmate version of MS/DOS is generally faster than
		MS/DOS on more recent 80286 and 80386 based IBM PCs because
		of effective use of the coprocessors (but they couldn't
		run MS/DOS code that bypasses MS/DOS for I/O).


What is a DECmate III?
	Date of introduction:  1984
	Date of withdrawal:    1990 
	Price: $2,695

	Technology:  Same as the DECmate II.

	Reason for introduction:  Again, DEC discovered that the market
		for large systems was dominated by other products, and
		that the PDP-8 based products were rarely expanded to their
		full potential.  Thus, there was no point in paying the
		price of expandability.

	Compatability:  Same as the DECmate II, except that the printer
		port is fixed at 4800 baud.

	Standard Configuration:  The DECmate III was sold with 32K of program
		memory, plus a second full bank for dedicated control
		panel functions, an integral RX50 dual 5 1/4 inch diskette
		drive with an 8051 controller chip, a printer port, a 100Hz
		real-time-clock, a data communications port, and interfaces
		for the VR-201 monitor and keyboard.

	Expandability:  A revised version of the Z80 based coprocessor
		for the DECmate II was available, and a graphics board
		compatable with the later DECmate II graphics board
		could be added allowing the standard monochrome monitor
		to be replaced with a VR-241 color monitor.  Two monitor
		configurations were not supported.  An obscure variant
		of the DEC scholar modem was also supported as an option.


What is a DECmate III+?
	Date of introduction:  1985
	Date of withdrawal:    1990 

	Technology:  Same as the DECmate II.

	Reason for introduction:  This machine apparently represents the
		last gasp of the PDP-8, hunting for the remains of the
		ever-shrinking market niche that the earlier DECmates
		had carved out.  The market niche was not there, and
		the production runs for this machine were short enough
		that UV erasable EPROM technology was used where earlier
		DECmates had used mask programmed chips.

	Compatability:  Same as the DECmate II, but the machine was unable
		to read 48 track per inch IBM formatted diskettes.  Again
		the printer port was fixed at 4800 baud.

	Standard Configuration:  The DECmate III+ was sold with 32K of
		program memory, plus a second bank for dedicated
		control panel functions, an integral RX33 single 5 1/4
		inch diskette drive with an 8751 controller chip, a
		printer port, a data communications port and interfaces
		to the monitor and keyboard.  A hard disk controller
		compatable with the optional one on the DECmate II was
		included, supporting an integral ST-225 20 MB disk;
		it is likely that it can only handle up to 1024 cylinders,
		but it is otherwise compatable with the DECmate II.

	Expandability: The same coprocessor option sold with the
		DECmate III was available, but because of the lack of a
		second floppy drive, this was rarely used (the Z80 was
		most likely to be used to run CP/M, but that system
		requires two drives to handle the installation procedure;
		an appropriately configured bootable image created on a
		DECmate II or III could run on a DECmate III+).

		The same graphics board as used on the DECmate III was
		also available.  The circuit traces and connectors for
		the Scholar modem are present, but this option was never
		sold on the DECmate III+.


From jones@cs.uiowa.edu Sat Oct  9 04:29:50 EDT 1993
Article: 485 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8,alt.answers,news.answers
Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@cs.uiowa.edu (Douglas W. Jones)
Subject: PDP-8 Frequently Asked Questions (posted every other month)
Summary: Answers to common questions about antique DEC PDP-8 computers.
	Those posting to alt.sys.pdp8 should read this.
Sender: news@news.uiowa.edu (News)
Message-ID: <1993Oct8.220111.18851@news.uiowa.edu>
Approved: news-answers-request@MIT.Edu
Date: Fri, 8 Oct 1993 08:08:08 GMT
Expires: Wed, 8 Dec 1993 08:08:08 GMT
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: Computer Science, University of Iowa, Iowa City, Iowa, USA
Keywords: FAQ DEC PDP 8
Followup-To: alt.sys.pdp8
Lines: 984
Xref: news.columbia.edu alt.sys.pdp8:485 alt.answers:1028 news.answers:13437

Archive-name: dec-faq/pdp8
Last-modified: Oct 1, 1993

Frequently Asked Questions about the DEC PDP-8 computer.

	By Douglas Jones, jones@cs.uiowa.edu
	(with help from many folks)

The most recent version of this file is available by anonymous FTP from:

	rtfm.mit.edu:/pub/usenet/alt.sys.pdp8
	sunsite.unc.edu:/pub/academic/computer-science/history/pdp-8/doc

	
Contents:

	What is a PDP?
	What is a PDP-8?
	What is the PDP-8 instruction set?
	What does PDP-8 assembly language look like?
	What character sets does the PDP-8 support?
	What different PDP-8 models were made?
	What about the LINC-8 and PDP-12?
	Where can I get a PDP-8 today?
	Where can I get PDP-8 documentation?
	What operating systems were written for the PDP-8?
	What programming languages were supported on the PDP-8?
	Where can I get PDP-8 software?
	Where can I get additional information?
	What use is a PDP-8 today?
	Who's Who?


What is a PDP?

	In 1957, Ken Olson and Harlan Anderson founded Digital Equipment
	Corporation (DEC), capitalized at $100,000, and 70% owned by
	American Research and Development Corporation.  Olson and Anderson
	wanted to call the company Digital Computer Corporation, but the
	venture capitalists insisted that they avoid the term Computer and
	hold off on building computers.  With facilities in an old woolen
	mill in Maynard Massachusetts, DEC's first product was a line of
	transistorized digital "systems modules", plug-in circuit boards
	with a few transistorized logic gates per board.  Starting in
	1960, DEC finally began to sell computers (the formal acceptance
	of the first PDP-1 by BBN is reported in Computers and Automation,
	April 1961, page 8B).  Soon after this, there were enough users
	that DECUS, the Digital Equipment Computer User's Society was
	founded.

	DEC's first computer, the PDP-1, sold for only $120,000 at a time
	when other computers sold for over $1,000,000.  (A good photo of
	a PDP-1 is printed in Computers and Automation, Dec. 1961, page 27).
	DEC quoted prices as low as $85,000 for minimal models of this
	machine.  The venture capitalist's insistance on avoiding the term
	computer was based on the steriotype that computers were big and
	expensive and needed a computer center and a large staff; by using
	the term Programmable Data Processor, or PDP, DEC avoided these
	stereotypes by entirely avoiding the term "computer"; thus, for
	over a decade, all digital computers sold by DEC were called PDPs.
	(In early DEC documentation, plural form "PDPs" is used as a
	generic term for all DEC computers.)

	In the early 1960's, DEC was the only manufacturer of large
	computers without a computer leasing plan.  IBM and all the
	other larger manufacturers leased most of their machines, and
	many machines were never offered for outright sale.  DEC's cash
	sales approach led to the growth of third party computer leasing
	companies such as DELOS, a spinoff of BB&N.

	DEC built a number of different computers under the PDP label, with
	a huge range of price and performance.  The largest of these are
	fully worthy of large computer centers with big support staffs.
	Many early DEC computers were not really built by DEC.  With the
	PDP-3 and LINC, for example, customers built the machines using DEC
	parts and facilities.  Here is the list of PDP computers:

	MODEL  DATE  PRICE     BITS  COMMENTS
	=====  ====  ========  ====  =====
	PDP-1  1960  $120,000  18    DEC's first computer
	PDP-2            NA    24    Never built?
	PDP-3            NA    36    One was built by a customer, not by DEC.
	PDP-4  1962   $60,000  18    Predecessor of the PDP-7.
	PDP-5  1963   $27,000  12    The ancestor of the PDP-8.
	PDP-6  1964  $300,000  36    A big computer; 23 built, most for MIT.
	PDP-7  1965   $72,000  18    Widely used for real-time control.
	PDP-8  1965   $18,500  12    The smallest and least expensive PDP.
	PDP-9  1966   $35,000  18    An upgrade of the PDP-7.
	PDP-10 1967  $110,000  36    A PDP-6 successor, great for timesharing.
	PDP-11 1970   $10,800  16    DEC's first and only 16 bit computer.
	PDP-12 1969   $27,900  12    A PDP-8 relative.
	PDP-13           NA          Bad luck, there was no such machine.
	PDP-14                       A ROM-based programmable controller.
	PDP-15 1970   $16,500  18    A TTL upgrade of the PDP-9.
	PDP-16 1972      NA    8/16  A register-transfer module system.

	Corrections and additions to this list are welcome!  The prices
	given are for minimal systems in the year the machine was first
	introduced.  The bits column indicates the word size.  Note that
	the DEC PDP-10 became the DECSYSTEM-20 as a result of marketing
	considerations, and DEC's VAX series of began as the Virtual
	Address eXtension of the never-produced PDP-11/78.

	It is worth mentioning that it is generally accepted that the Data
	General Nova (see photo, Computers and Automation, Nov. 1968,
	page 48) was originally developed as the PDP-X, a 16-bit
	multi-register version of the PDP-8.  A prototype PDP-X was built
	at DEC before the design was rejected.  This and a competing 16-bit
	design were apparently submitted to Harold McFarland at
	Carnegie-Mellon University for evaluation; McFarland (and perhaps
	Gordon Bell, who was at C-MU at the time) evaluated the competing
	designs and rejected both in favor of what we know as the PDP-11.
	(A less common version of this story is that the reason that DEC
	never produced a PDP-13 was because the number 13 was assigned to
	what became the Nova; this is unlikely because the PDP-X prototype
	came before the PDP-11.)  Both DEC and Data General are quiet about
	these stories.

	Today, all of the PDP machines are in DEC's corporate past, with the
	exception of the PDP-11 family of minicomputers and microprocessors.

	Of course, occasionally, some lab builds a machine out of DEC
	hardware and calls it a PDP with a new number.  For example, the
	Australian Atomic Energy Commission once upgraded a PDP-7 by adding
	a PDP-15 on the side; they called the result a PDP-22.
	

What is a PDP-8?

	The PDP-8 family of minicomputers were built by Digital Equipment
	corporation between 1965 and 1990, although it is worth noting
	that the term minicomputer first came into prominence in early 1968.
	(See Interdata ad, Computers and Automation, May 1968, page 10).
	The PDP-8 was largely upward compatable with the PDP-5, a machine
	that was unveiled on August 11, 1963 at WESCON, and the inspiration
	for that machine came from two earlier machines, the LINC and the
	CDC 160.  All of these machines were characterized by a 12 bit word
	with no hardware byte structure, a 4K minimum memory configuration,
	and simple but powerful instruction sets.

	Although some people consider the CDC 160 the first minicomputer,
	the PDP-8 was the definitive minicomputer.  By late 1973, the
	PDP-8 family was the best selling computer in the world, and it is
	likely that it was only displaced from this honor by the Apple II
	and later, the IBM PC.  Most models of the PDP-8 set new records
	as the least expensive computer on the market at the time of their
	introduction.  The PDP-8 has been described as the model-T of the
	computer industry because it was the first computer to be mass
	produced at a cost that just about anyone could afford.

	C. Gordon Bell has said that the basic idea of the PDP-8 was not
	really original with him.  He gives credit to Seymour Cray (of CDC
	and later Cray) for the idea of a single-accumulator 12 bit
	minicomputer.  Cray's CDC 160 family (see CACM, march 1961, photo
	on page 244, text on page 246) was such a machine, and in addition
	to the hundreds of CDC 160 systems sold as stand-alone machines,
	a derivative 12 bit architecture was used for the I/O processors
	on Cray's first great supercomputer, the CDC 6600.

	Note that Cray's 12 bit machines had 6 basic addressing modes with
	variable length instruction words and other features that were far
	from the simple elegance of the PDP-8.  Despite its many modes,
	the CDC architecture lacked the notion of current page addressing,
	and the result is that, for examples that don't involve indexing,
	PDP-8 code is generally as tight as the code on Cray's machines.


What is the PDP-8 instruction set?

	The PDP-8 word size is 12 bits, and the basic memory is 4K
	words.  The minimal CPU contained the following registers:

		PC - the program counter, 12 bits.
		AC - the accumulator, 12 bits.
		L  - the link, 1 bit, commonly prefixed to AC as <L,AC>.

	It is worth noting that many operations such as procedure linkage
	and indexing, which are usually thought of as involving registers,
	are done with memory on the PDP-8 family.

	Instruction words are organized as follows:
		 _ _ _ _ _ _ _ _ _ _ _ _
		|_|_|_|_|_|_|_|_|_|_|_|_|
		|     | | |             |
		|  op |i|z|    addr     |

		op   - the opcode.
		i    - the indirect bit (0 = direct, 1 = indirect).
		z    - the page bit (0 = page zero, 1 = current page).
		addr - the word in page.

	The top 5 bits of the 12 bit program counter give the current page,
	and memory addressing is also complicated by the fact that absolute
	memory locations 8 through 15 are incremented prior to use when
	used as indirect addresses.  These locations are called auto-index
	registers (despite the fact that they are in memory); they allow
	the formulation of very tightly coded array operations.

	The basic instructions are:

		000 - AND - and operand with AC.
		001 - TAD - add operand to <L,AC> (a 13 bit value).
		010 - ISZ - increment operand and skip if result is zero.
		011 - DCA - deposit AC in memory and clear AC.
		100 - JMS - jump to subroutine.
		101 - JMP - jump.
		110 - IOT - input/output transfer.
		111 - OPR - microcoded operations.

	The ISZ and other skip instructions conditionally skip the next
	instruction in sequence.  The ISZ is commonly used to increment a
	loop counter and skip if done, and it is also used as an general
	increment instruction, either followed by a no-op or in contexts
	where it is known that the result will never be zero.

	The JMS instruction stores the return address in relative word
	zero of the subroutine, with execution starting with relative word
	one.  Subroutine return is done with an indirect JMP through the
	return address.  Subroutines commonly increment their return
	addresses to index through inline parameter lists or to perform
	conditional skips over instructions following the call.

	The IOT instruction has the following form:
		 _ _ _ _ _ _ _ _ _ _ _ _
		|1|1|0|_|_|_|_|_|_|_|_|_|
		|     |           |     |
		|     |   device  | op  |

	The IOT instruction specifies one of up to 8 operations on one of
	64 devices.  Typically (but not universally), each bit of the op
	field evokes an operation, and these can be microcoded in left to
	right order.  Prior to the PDP-8/E, there were severe restrictions
	on the interpretation of the op field.

	As an example of the use of IOT instructions, consider the console
	terminal interface.  On early PDP-8 systems, this was always
	assumed to be an ASR 33 teletype, complete with low-speed paper
	tape reader and punch.  It was addressed as devices 03 (the
	keyboard/reader) and 04 (the teleprinter/punch):
		 _ _ _ _ _ _ _ _ _ _ _ _
		|1|1|0|_|_|_|_|_|_|_|_|_|
		      |0 0 0 0 1 1|0 0 1  - KSF - keyboard skip if flag
		      |0 0 0 0 1 1|0 1 0  - KCC - keyboard clear flag
		      |0 0 0 0 1 1|1 0 0  - KRS - keyboard read static

	The keyboard flag is set by the arrival of a character.  The KCC
	instruction clears both the flag and the accumulator.  KRS ors the
	8 bit input data with the low order 8 bits of AC.  The commonly
	used KRB instruction is the or of KCC and KRS.  To await one byte
	of input, use KSF to poll the flag, then read it with KRB.
		 _ _ _ _ _ _ _ _ _ _ _ _
		|1|1|0|_|_|_|_|_|_|_|_|_|
		      |0 0 0 1 0 0|0 0 1  - TSF - teleprinter skip if flag
		      |0 0 0 1 0 0|0 1 0  - TCF - teleprinter clear flag
		      |0 0 0 1 0 0|1 0 0  - TPC - teleprinter print static

	The teleprinter flag is set by the completion of the TPC operation
	(as a result, on startup, many applications use TPC to print a null
	in order to get things going).  TCF clears the flag, and TPC
	outputs the low order 8 bits of the accumulator.  The commonly used
	TLS instruction is the or of TCF and TPC.  To output a character,
	first use TSF to poll the flag, then write the character with TLS.

	IOT instructions may be used to initiate data break transfers from
	block devices such as disk or tape.  The term "data break" was,
	for years, DEC's preferred term for cycle-stealing direct-memory-
	access data transfers.

	Some CPU functions are accessed only by IOT instructions.  For
	example, interrupt enable and disable are IOT instructions:
		 _ _ _ _ _ _ _ _ _ _ _ _
		|1|1|0|_|_|_|_|_|_|_|_|_|
		      |0 0 0 0 0 0|0 0 1  - ION - interrupts turn on
		      |0 0 0 0 0 0|0 1 0  - IOF - interrupts turn off

	An interrupt was requested when any device raised its flag.  The
	console master clear switch would reset all flags and disable
	interrupts.  Effectively, an interrupt is a JMS instruction to
	location zero, with the side effect of disabling interrupts.  The
	interrupt service routine would test flags and perform the
	operations needed to reset them, and then return using ION
	immediately before the indirect return JMP.  The effect of ION
	is delayed so that interrupts are not enabled until after the JMP.

	The instructions controlling the optional memory management unit
	are also IOT instructions.  This unit allows the program to address
	up to 23K of main memory by adding a 3 bit extension to the memory
	address.  Two extensions are available, one for instruction fetch
	and direct addressing, the other for indirect addressing.

	A wide variety of operations are available through the OPR
	microcoded instructions:
	         _ _ _ _ _ _ _ _ _ _ _ _
	Group 1 |1|1|1|0|_|_|_|_|_|_|_|_|
		         1                - CLA - clear AC
		           1              - CLL - clear the L bit
	                     1            - CMA - ones complement AC
	                       1          - CML - complement L bit
	                               1  - IAC - increment <L,AC>
	                         1 0 0    - RAR - rotate <L,AC> right
	                         0 1 0    - RAL - rotate <L,AC> left
		                 1 0 1    - RTR - rotate <L,AC> right twice
		                 0 1 1    - RTL - rotate <L,AC> left twice

	In general, the above operations can be combined by oring the
	bit patterns for the desired operations into a single instruction.
	If none of the bits are set, the result is the NOP instruction.
	When these operations are combined, they operate top to bottom
	in the order shown above.  The exception to this is that IAC cannot
	be combined with the rotate operations on some models, and attempts
	to combine rotate operations have different effects from one model
	to another (for example, on the PDP-8/E, the rotate code 001 means
	swap 6 bit bytes in the accumulator, while previous models took
	this to mean something like "shift neither left nor right 2 bits").
	         _ _ _ _ _ _ _ _ _ _ _ _
	Group 2 |1|1|1|1|_|_|_|_|_|_|_|0|
	                   1     0        - SMA - skip on AC < 0  \
	                     1   0        - SZA - skip on AC = 0   > or
	                       1 0        - SNL - skip on L /= 0  /
	                   0 0 0 1        - SKP - skip unconditionally
	                   1     1        - SPA - skip on AC >= 0 \
	                     1   1        - SNA - skip on AC /= 0  > and
	                       1 1        - SZL - skip on L = 0   /
	                 1                - CLA - clear AC
	                           1      - OSR - or switches with AC
	                             1    - HLT - halt

	The above operations may be combined by oring them together,
	except that there are two distinct incompatible groups of skip
	instructions.  When combined, SMA, SZA and SNL, skip if one or the
	other of the indicated conditions are true, while SPA, SNA and SZL
	skip if all of the indicated conditions are true (logical and).
	When combined, these operate top to bottom in the order shown;
	thus, the accumulator may be tested and then cleared.  Setting
	the halt bit in a skip instruction is a crude but useful way to
	set a breakpoint for front-panel debugging.  If none of the bits
	are set, the result is an alternative form of no-op.

	A third group of operate microinstructions (with a 1 in the least
	significant bit) deals with the optional extended arithmetic
	element to allow such things as hardware multiply and divide, 24
	bit shift operations, and normalize.  These operations involve
	an additional data register, MQ or multiplier quotient, and a small
	step count register.  On the PDP-8/E and successors, MQ and the
	instructions for loading and storing it were always present, even
	when the EAE was absent, and the EAE was extended to provide a
	useful variety of 24 bit arithmetic operations.


What does PDP-8 assembly language look like?

	There are many different assemblers for the PDP-8, but most use
	a compatable basic syntax; here is an example:

	START,	CLA CLL		/ Clear everything
		TAD	X	/ Load X
		AND I	Y	/ And with the value pointed to by Y
		DCA	X	/ Store in X
		HLT		/ Halt

	X,	1 		/ A variable
	Y,	7 		/ A pointer

	Note that labels are terminated by a comma, and comments are
	separated from the code by a slash.  There are no fixed fields
	or column restrictions.  The "CLA CLL" instruction on the first
	line is an example of the microcoding of two of the Group 1
	operate instructions.  CLA alone has the code 7200 (octal),
	while CLL has the code 7100; combining these as "CLA CLL" produces
	7300, the instruction to clear both AC and the link bit.  As a
	general rule, except when memory reference instructions are
	involved, the assembler simply ors together the values of all
	blank separated fields between the label and comment.
	
	Indirection is indicated by the special symbol I in the operand
	field, as in the third line of the example.  The typical PDP-8
	assembler has no explicit notation to distinguish between page zero
	and current page addresses.  Instead, the assembler is expected to
	note the page holding the operand and automatically generate the
	appropriate mode.  If the operand is neither in the current page
	nor page zero, some assemblers will raise an error, others will
	automatically generate an indirect pointer to the off-page operand
	(This feature should be avoided!).

	Note, in the final two lines of the example, that there is no
	"define constant" pseudo-operation.  Instead, where a constant
	is to be assembled into memory, the constant takes the place of
	the op-code field.

	The PDP-8 has no immediate addressing mode, but most assemblers
	provide an optional mechanism to allow the programmer to ignore
	this lack:

		TAD	(3)	/ add 3, from memory on the current page.
		TAD	[5]	/ add 5, from memory on page zero.
		JMP I	(LAB)	/ jump indirect through the address of LAB.

	Assemblers that support this automatically fill the end of each page
	with constants defined in this way that have been accumulated during
	the assembly of that page.  Note that the variants "(3" and "[5"
	(with no closing parentheses) are usually allowed but the use of
	this sloppy form is generally discouraged.  Furthermore, the widely
	used PAL8 assembler interprets "(3)+1" as being the same as "(3+1)".

	Arithmetic is allowed in operand fields and constant definitions,
	but expressions are evaluated in strict left-to-right order, as
	shown below:

		TAD	X+1	/ add the contents of the location after X.
		TAD	(X-1)	/ add the address of the location before X.

	Other operators allowed included and (&), or (!), multiply (^) and
	divide (%), as well as a unary sign (+ or -).  Unfortunately, one
	of the most widely used assemblers, PAL8, has trouble when unary
	operators are mixed with multiplication or division.
	
	Generally, only the first 6 characters of identifiers are
	significant and numeric constants are evaluated in octal.

	Other assembly language features are illustrated below:

	/ Comments may stand on lines by themselves
				/ Blank lines are allowed

		*200		/ Set the assembly origin to 200 (octal)

	NL0002=	CLA CLL CML RTL	/ Define new opcode NL0002.

		NL0002		/ Use new opcode (load 0002 in AC)
		JMP	.-1	/ Jump to the previous instruction

	X1=	10		/ Define X1 (an auto-index register address)

		TAD I	X1	/ Use autoindex register 1

		IAC; RAL	/ Multiple instructions on one line

		$		/ End of assembly

	The assembly file ends with a line containing a $ (dollar sign)
	not in a comment field.

	The $, * and =  syntax used by most PDP-8 assemblers replace
	functions performed by pseudo-operations on many other assemblers.
	In addition, PAL8, the most widely used PDP-8 assembler supports
	the following pseudo-operations:

		DECIMAL		/ Interpret numeric constants in base 10
		OCTAL		/ Interpret numeric constants in base 8
		EJECT		/ Force a page eject in the listing
		XLIST		/ toggle listing
		PAGE 	 	/ Advance location counter to next page
		FIELD	N	/ Assemble into extended memory field N
		TEXT	STRING	/ Pack STRING into consecutive 6 bit bytes
		ZBLOCK	N	/ Allocate N words, initialized to zero
		IFDEF	S <C>	/ Assemble C if symbol S is defined
		IFNDEF	S <C>	/ Assemble C if symbol S is not defined
		IFZERO	E <C>	/ Assemble C if expression E is zero
		IFNZRO	E <C>	/ Assemble C if expression E is not zero

	Conditonally assembled code must be enclosed in angle brackets.
	The conditionally assembled code may extend over multiple lines.


What character sets does the PDP-8 support?

	With its 12 bit word, the PDP-8 is somewhat awkward in its support
	for modern 7 and 8 bit character sets.  Nonetheless, from the
	beginning, PDP-8 software has generally assumed that text I/O would
	be in 7 bit ASCII.  Most early PDP-8 systems used teletypes as
	console terminals; as sold by DEC, these were configured for mark
	parity, so most older software assumes 7 bit ASCII, upper case
	only, with the 8th bit set to 1.  On output, lines are generally
	terminated with both CR and LF; on input, CR is typically (but not
	always) the line terminator and LF is typically ignored.  In
	addition, the tab character (HT) is generally interpreted in terms
	of a tab-stop every 8 spaces.

	Most of the better engineered PDP-8 software tends to fold upper
	and lower case on input, and it ignores the setting of the 8th bit.

	Internally, PDP-8 programmers are free to use other character sets,
	but the TEXT pseudo-operation strongly encourages the 6 bit
	character set called "stripped ASCII".  To map from upper-case-only
	ASCII to stripped ASCII, each 8 bit character is anded with octal
	77 and then packed 2 characters per word, left to right.  Many
	programs use a semi-standardized scheme for packing mixed upper and
	lower case into 6 bit TEXT form; this uses ^ to flip from upper to
	lower case or lower to upper case, % to encode CR-LF pairs, and @
	(octal 00) to mark end of string.  Note that this scheme makes no
	provision for encoding the %, ^ and @ characters, nor does it allow
	control characters other than the CR-LF pair.

	Files under the widely used OS/8 system consist of sequences of 256
	word blocks.  When used for text, each block holds 384 bytes, packed
	3 bytes per pair of words as follows:

			aaaaaaaa		ccccaaaaaaaa
			bbbbbbbb		CCCCbbbbbbbb
			ccccCCCC

	Control Z is used as an end of file marker.  Because most of the
	PDP-8 system software was originally developed for paper tape,
	binary object code is typically stored in paper-tape image form
	using the above packing scheme.


What different PDP-8 models were made?

	The total sales figure for the PDP-8 family is estimated at over
	300,000 machines.  Over 7000 of these were sold prior to 1970.
	During the PDP-8 production run, a number of models were made, as
	listed in the following table.  Of these, the PDP-8/E is generally
	considered to be the definitive machine.  If the PDP-8 is
	considered to be the Model T of the computer industry, perhaps
	the PDP-8/E should be considered to be the industry's Model A.

	MODEL	DATES	SALES   COST	TECHNOLOGY	REMARKS

	PDP-5	63-67	 116		Transistor
	PDP-8	65-69 	1450	$18,500	Transistor
	LINC-8	66-69	 142	$38,500	Transistor
	PDP-8/S	66-70	1024	$10,000	Transistor
	PDP-8/I	68-71 	3698	$12,800	TTL
	PDP-8/L	68-71 	3902	 $8,500	TTL		Scaled down 8/I
	PDP-12	69-73?	3500?	$27,900	TTL		Followup to LINC-8
	PDP-8/E	70-78	>10K?	 $7,390	TTL MSI	Omnibus
	PDP-8/F	72-78?	>10K?	<$7K	TTL MSI Omnibus Based on 8/E CPU
	PDP-8/M	72-78?	>10K?	<$7K	TTL MSI Omnibus OEM version of 8/F
	PDP-8/A	75-84?	>10K?	 $1,317	TTL LSI Omnibus New CPU or 8/E CPU
	VT78    78-80		<$10K	Intersil IM6100
	Dm I    80-84			Harris 6120
	Dm II	82-86		 $1,435	Harris 6120
	Dm III	84-90		 $2,695	Harris 6120
	Dm III+	85-90			Harris 6120

	Additional information is available in part two of this FAQ,
	where all known models of the PDP-8, along with variants,
	alternate marketing names, and other peculiarities are given.

	The last years of the PDP-8 family were dominated by the
	PDP-8 compatable microprocessor based VT78 and DECmate (Dm in the
	above table) machines.  DEC also used the Intersil IM6100 and
	Harris 6120 microprocessors in many peripheral controllers for
	the PDP-11 and PDP-15.  While all of the earlier PDP-8 systems
	were open architecture systems, the DECmates had closed
	architectures with an integrated console terminals and limited
	peripheral options.

	The following PDP-8 compatible or semi-compatible machines were
	made and sold by others; very little is known about many of these:

	MODEL		DATE	MAKER, NOTES

	MP-12		6?	Fabritek
	TPA		68?	Hungarian, a PDP-8/L clone, ran FOKAL
	Saratov		?	Russian, another PDP-8/L clone
	Voronezh	?	Russian, another PDP-8/? clone
	SPEAR u-LINC	?	SPEAR, Inc, Waltham Mass.
	DCC-112		70-71	Digital Computer Controls
	DCC-112H	71	Digital Computer Controls
	6100 Sampler	7?	Intersil, their IM6100 promotional kit
	Intercept I	7?	Intersil, based on IM6100
	Intercept Jr	7?	Intersil, based on IM6100
	PCM-12		7?	Pacific CyberMetrix, based on Intercept bus
	PCM-12A		7?	Pacific CyberMetrix, fixed to clock at 4MHz
	SBC-8		84-88	CESI, Based on IM6120, SCSI bus
	

What about the LINC/8 and PDP-12?

	Wesley Clark, then at Lincoln Labs, developed the LINC, or
	Laboratory INstrumentation Computer, as a personal laboratory
	computer in the early 1960's.  He developed it in response to
	the needs of Mary Brazier, a neurophysiologist at MIT who needed
	better laboratory tools.  Over 24 LINC systems were built by
	customers before late 1964 when DEC began selling a commercial
	version (see Computers and Automation, Nov. 1964, page 43).
	By the time DEC introduced the LINC-8, 43 LINC systems had been
	installed (see Computers and Automation, Mar. 1966, page 34).

	When Lincoln Labs decided that the LINC did not fit their mission,
	a group at the the National Institute of Health funded an
	experiment to see if the LINC would be a productive tool in the
	life sciences.  As a result of this project, 12 LINCs were
	built and debugged, each by its eventual user.

	The LINC was the first 12 bit minicomputer built using DEC hardware.
	Like the PDP-5 and other early DEC computers, it was built with
	system modules, DEC's first family of logic modules.  Along with
	the CDC 160, it paved the way for the PDP-5 and PDP-8.

	When compared with the PDP-8, the LINC instruction set was not
	as well suited for general purpose computation, but the common
	peripherals needed for lab work such as analog to digital and
	digital to analog converters were all bundled into the LINC
	system.  Users judged it to be a superb laboratory instrument.

	One of the major innovations introduced with the LINC was the
	LINCtape.  These tapes could be carelessly pocketed or dropped on
	the floor without fear of data loss, and they allowed random
	access to data blocks.  DEC improved on this idea slightly to
	make their DECtape format, and DECtape was widely used with all
	DEC computers made in the late 1960's and early 1970's.

	The motives behind the development of LINCtape were the same
	motivives that led IBM to develop the floppy disk almost a decade
	later, and in fact, DECtape survived as a widely used medium until
	DEC introduced the RX01 8 inch floppy disk drive around 1975.

	Within a year of the introduction of the PDP-8, DEC released the
	LINC-8, a machine that combined a PDP-8 with a LINC in one package.
	The success of the LINC-8 led DEC to re-engineer the machine using
	TTL logic in the late 1960's; the new version was originally to be
	called the LINC-8/I, but it was sold as the PDP-12.  Both the
	LINC-8 and the PDP-12 had impressive consoles, with separate sets
	of lights and switches for the LINC and PDP-8 halves.

	The success of the LINC-8 also led to the development of a clone,
	the SPEAR micro-LINC.  This machine used Motorola MECL integrated
	circuits and was available for delivery in (June 1965? this date
	must be wrong!).

	The LINC-8 and PDP-12 could run essentially any PDP-8 or LINC
	software, but because they included instructions for switching
	between modes, a third body of software was developed that required
	both modes.

	One feature of LINC and LINC-8 software is the common use of the
	graphic display for input-output.  These machines were some of the
	first to include such a display as a standard component, and many
	programs used the knobs on the analog to digital converter to move
	a cursor on the display in the way we now use a mouse.

	LAP, the Linc Assembly Program, was the dominant assembler used
	on the LINC.  WISAL (WISconson Assembly Language) or LAP6-W was
	the version of this assembler that survived to run on the PDP-12.
	Curiously, this includes a PDP-8 assembler written in LINC code.

	LAP6-DIAL (Display Interactive Assembly Language) evolved from
	this on the PDP-12 to became the dominant operating system for
	the PDP-12.  The 8K version of this is DIAL MS (Mass Storage),
	even if it has only two LINCtape drives.  These were eventually
	displaced by the OS/8 variant known as OS/12.


Where can I get a PDP-8 today?

	The CESI machine may still be on the market, for a high price, but
	generally, you can't buy a new PDP-8 anymore.  There are quite a
	few PDP-8 machines to be found in odd places on the used equipment
	market.  They were widely incorporated into products such as
	computer controlled machine tools, X-ray diffraction machines, and
	other industrial and lab equipment.  Many of them were sold under
	the EduSystem marketing program to public schools and universities,
	and others were used to control laboratory instrumentation.
	After about 1976, Reuters bought on the order of 10,000 OMNIBUS
	based machines per year, with perhaps 2000 per year going to other
	customers.

	If you can't get real hardware, you can get emulators.  Over the
	years, many PDP-8 emulators have been written; the best of these
	are indistinguishable from the real machine from a software
	prespective, and on a modern high-speed RISC platform, these
	frequently outperform the hardware they are emulating.

	Finally, you can always build your own.  The textbook "The Art of
	Digital Design," second edition, by Franklin Prosser and David
	Winkel (Prentice-Hall, 1987, ISBN 0-13-046780-4) uses the design
	of a PDP-8 as a running example.  Many students who have used this
	book were required to build working PDP-8 systems as lab projects.


Where can I get PDP-8 documentation?

	Part II of this FAQ cites the key documents published by DEC
	describing each model of the PDP-8.  These are all out of print,
	and DEC was in the habit of printing much of their documentation
	on newsprint with paperback bindings, which is to say, surviving
	copies tend to be yellow and brittle.  DEC distributed huge
	numbers of catalogs and programming handbooks in this inexpensive
	paperback format, and these circulate widely on the second-hand
	market.  When research laboratories and electronics shops are
	being cleaned out, it is still common to find a few dusty,
	yellowed copies of these books being thrown out.

	Douglas Jones has made a small number of bound photocopies of
	DEC's 1973 introduction to programming, perhaps the definitive
	introduction to the PDP-8, and the other early DEC handbooks need
	similar treatment before they all crumble.

	Maintenance manuals are harder to find, but more valuable.  If you
	need one, you usually need to find someone willing to photocopy
	one of the few surviving copies.  Fortunately, DEC has been
	friendly to collectors, granting fairly broad letters of permission
	to reprint obsolete documentation, and the network makes if fairly
	easy to find someone who has the documentation you need and can
	get copies.


What operating systems were written for the PDP-8?

	A punched paper-tape library of stand-alone programs was commonly
	used with the smallest (diskless and tapeless) configurations from
	the beginning up through the mid 1970's.  Many paper tapes from
	this library survive to the present at various sites!  The minimum
	configuration expected by these tapes is a CPU with 4K memory,
	and a teletype ASR 33 with paper tape reader and punch.

	The DECtape Library System was an early DECtape oriented save and
	restore system that allowed a reel of tape to hold a directory of
	named files that could be loaded and run on a 4K system.
	Eventually, this supported a very limited tape-based text editor
	for on-line program development.  This did not use the DECtape's
	block addressable character; the software was based on minimal
	ports of the paper-tape based software described above.

	The 4K Disk Monitor System provided slightly better facilities.
	This supported on-line program development and it worked with any
	device that supported 129 word blocks (DECtape, the DF32 disk, or
	the RF08 disk).

	MS/8 or the R-L Monitor System, was developed starting in 1966
	and submitted to DECUS in 1970.  This was a disk oriented system,
	faster than the above, with tricks to make it run quickly on
	DECtape based systems.

	POLY BASIC was a BASIC only system submitted to DECUS and later
	sold by DEC as part of its EduSystem marketing program.

	P?S/8 was developed starting in 1971 from an MS/8 foundation.  It
	runs on minimal PDP-8 configurations, supports somewhat device
	independant I/O and requires a random-access device for the file
	system (DECtape is random-access!).  P?S/8 runs compatably on
	most PDP-8 machines including DECmates, excepting only the PDP-8/S
	and PDP-5.  P?S/8 is still being developed!

	OS/8, developed in parallel with P?S/8, became the main PDP-8
	programming environment sold by DEC.  The minimum configuration
	required was 8K words and a random-access device to hold the
	system.  For some devices, OS/8 requires 12K.  There are a large
	number of OS/8 versions that are not quite portable across various
	subsets of the PDP-8 family.  OS/78 was developed from OS/8 to
	support the DECmate I, and OS/278 was developed for the later
	DECmate machines.  These have unnecessary incompatabilities with
	earlier versions of OS/8 and with pre-Omnibus machines.  There are
	also stories that DEC included code in either OS/8 or one of its
	predecessors to make it incompatable with the DCC-112.

	OS8 (no slash) may still be viable.  It requires 8K of main memory,
	an extended arithmetic unit, and DECtape hardware.  Unlike most
	PDP-8 operating systems, it uses a directory structure on DECtape
	compatable with that used on the PDP-10.

	TSS/8 was developed in 1968 as a timesharing system.  It required
	a minimum of 12K words of memory and a swapping device.  It was
	the standard operating system on the EduSystem 50 which was sold
	to many small colleges and large public school systems.  Each user
	gets a virtual 4K PDP-8; many of the utilities users ran on these
	virtual machines were only slightly modified versions of utilities
	from the Disk Monitor System or paper-tape environments.

	Other timesharing systems developed for the PDP-8 include MULTI-8,
	ETOS, MULTOS, and OMNI-8; some of these required nonstandard
	memory management hardware.  By the mid 1970's, some of these were
	true virtual machine operating systems in the same spirit as IBM's
	VM-370; they typically supported some version of OS/8 running on a
	32K virtual PDP-8 assigned to each user.  Some could support
	different user operating systems on each virtual machine, others
	supported addressing of more than 4K for data, but limited code to
	field zero of a process's virtual memory.

	CAPS-8 was a cassette based operating system supporting PAL and
	BASIC.  There are OS/8 utilities to manipulate CAPS-8 cassettes,
	and the file format on cassette is compatible with a PDP-11 based
	system called CAPS-11.

	WPS was DEC's word processing system, developed on the 8/E and
	widely used on the 1980's vintage machines with a special WPS
	keycaps replacing the standard keycaps on the keyboard.  It was
	heavily promoted on the VT-78, and when the DECmates came out, DEC
	began to suppress knowledge that DECmates could run anything else.
	WPS-11 was a curious distributed system using a PDP-11 as a file
	server for a cluster of VT-78 WPS systems.

	COS-310, DEC's commercial operating system for the PDP-8, supported
	the DIBOL language.  COS-310 was a derivative of MS/8 and OS/8, but
	with a new text file format.  The file system is almost the same as
	OS/8, but dates are recorded differently, and a few applications
	can even run under both COS and OS/8.  COS was the last operating
	system other than WPS promoted by DEC for the DECmates.


What programming languages are supported on the PDP-8

	The PAL family of assembly languages, particularly PAL III and PAL8
	are as close to a standard assembly language as can be found for
	the PDP-8.  These produce absolute object code and there are
	versions of PAL for minimally configured machines, although these
	have sever symbol table limitations.

	MACRO-8 was DEC's first macro assembly language for the PDP-8, but
	it was rarely used outside the paper-tape environment.  MACREL and
	SABR are assembly languages that produce relocatable output.  SABR
	is the final pass for the ALICS II FORTRAN compiler, and MACREL was
	developed in (unfulfilled) anticipation of similar use.  MACREL was
	heavily used by the DECmate group at DEC.

	There was also RALF, the relocatable assembler supporting RTPS
	FORTRAN, and FLAP, an absolute assembler derived from RALF.
	Both SABR and RALF/FALP are assemblers that handle their intended
	applications but have quirky and incompatible syntax.

	A subset of FORTRAN was supported on both the PDP-5 and the
	original PDP-8.  Surviving documentation describes a DEC compiler
	from 1964 and a compiler written by Information Control Systems
	from 1968.  The latter, ALICS II FORTRAN, was originally a paper
	tape based compiler, but it forms the basis of the OS/8 8K FORTRAN
	compiler, and was also adapted to the Disk Monitor System.

	RTPS FORTRAN required 8K and a floating point processor; it had
	real-time extensions and was a full implementation of FORTRAN IV
	(also known as ANSI FORTRAN 66).  OS/8 F4 is RTPS FORTRAN stripped
	of the requirement for hardware floating point (if the hardware is
	missing, it uses software emulation).

	FOCAL, an interpretive language comparable to BASIC, was available
	on all models of the family, including the PDP-5 and PDP-8/S.
	Varsions of FOCAL run under PS/8, P?S/8 and other systems.

	Many versions of BASIC were also available, from DEC and other
	sources.  DEC BASIC was widely used on PDP-8 systems sold under the
	EduSystem marketing program.  A paper-tape version was available
	that ran in 4K, versions for OS/8 and TSS/8, an 8K stand-alone
	time-sharing version, and others.

	DIBOL was DEC's attempt at competing with COBOL in the commercial
	arena.  It was originally implemented under MS/8 but most versions
	were sold to run under the COS operating system.

	Algol was available from a fairly early date.

	At least two Pascal compilers were developed for the PDP-8.  One
	was a Pascal-S interpreter, written in assembler, the other was a
	Pascal-P compiler with a P-code interpreter written in assembler.

	At least two LISP interpreters were written for the PDP-8; one
	runs in 4K, the other can use up to 16K.

	POLY SNOBOL was a version of SNOBOL that was somewhere between
	Griswald's definitions of SNOBOL 3 and SNOBOL 4.

	TECO, the text editor, is available, and is also a general purpose
	language, and someone is working on a PDP-8 C.  The story of TECO
	on the PDP-8 is convoluted.  Russ Ham implemented TECO under his
	OS8 (without a slash) system.  This version of TECO was pirated by
	the Oregon Museum of Science and Industry (OMSI), where the system
	was ported to PS/8.  Richard Lary and Stan Rabinowitz made it
	more compatible with other versions of TECO, and the result of
	work is the version distributed by DECUS.  RT-11 TECO for the
	PDP-11 is a port of this code.


Where can I get PDP-8 software?

	DECUS, the DEC User Society, is still alive and well, and their
	submission form still lists PAL8 and FOCAL as languages in which
	they accept submissions!  The DECUS library is available on-line
	by anonymous FTP at acfcluster.nyu.edu in subdirectory DECUS.
	To quote the README file from the current on-line catalog, "Items
	from older DECUS Library catalogs are still also available
	(provided their media can still be read), but machine readable
	catalog information is not available for these."  Direct questions
	by E-mail to INFORMATION@DECUS.ORG.

	The following anonymous FTP sites contain publically accessable
	archives of PDP-8 software and other information:

	  ftp.telebit.com:/pub/pdp8
	  ftp.update.uu.se:/pub/pdp8
	  sunsite.unc.edu:/pub/academic/computer-science/history/pdp-8.

	The latter archive also maintains an archive of traffic in
	alt.sys.pdp8 in the directory ...pdp8/usenet.


Where can I get additional information?

	The file WHAT-IS-A-PDP8, by Charles Lasner contains considerable
	additional information; this file is included in the telebit.com
	archive cited above.  This file gives details of every PDP-8 model
	including the small quirks and incompatabilities that (to be
	generous) allow software to determine which model it is running on.
	These quirks also make it all too easy for careless programmers to
	write almost portable software with very obscure bugs.

	The mailing list pdp8-lovers@ai.mit.edu reaches a number of PDP-8
	owners and users, not all of whom have USENET feeds.  The USENET
	newsgroup alt.sys.pdp8 needs to be gatewayed to this mailing list.

	Many "archival" books have included fairly complete descriptions
	of the PDP-8; among them, "Computer Architecture, Readings and
	Examples" by Gordon Bell and Allen Newell is among the most
	accurate and complete (but difficult to read).


What use is a PDP-8 today?

	What use is a Model T today?  Collectors of both come in the same
	basic classes.  First, there are antiquarians who keep an old one
	in the garage, polished and restored to new condition but hardly
	ever used.  Once a year, they warm it up and use it, just to prove
	that it still works, but they don't make much practical use of it.

	PDP-8 systems maintained by antiquarians are frequently in beautiful
	shape.  Antiquarians worry about dust, chipped paint, and missing
	switches, and they establish newsgroups and mailing lists to help
	them locate parts and the advice needed to fix their machines.

	In the second class are those who find old machines and soup them
	up, replacing major parts to make a hotrod that only looks like
	the original from the outside, or keeping the old mechanism and
	putting it to uses that were never intended.  Some PDP-8 owners,
	for example, have built PDP-8 systems with modern SCSI disk
	interfaces!  There is serious interest in some quarters in
	constructing an omnibus board that would support an IDE disk of
	the variety that was mass-produced for the IBM PC/AT.

	Last, there are the old folks who still use their old machines for
	their intended purposes long after any sane economic analysis
	would recommend such use.  If it ain't broke, don't fix it, and if
	it can be fixed, why bother replacing it?  Both Model T Fords and
	the classic PDP-8 machines are simple enough that end users can
	maintain and repair them indefinitely.  All you need to keep a
	vintage -8 running are a stock of inexpensive silicon diodes and
	a stock of 2N3639B or better, 2N3640 transistors.

	Unlike most modern personal computers, PDP-8 systems were routinely
	sold with complete maintenance manuals; these included schematic
	diagrams, explanations of not only how to use the devices, but how
	they are built, and suggestions to those considering building their
	own peripherals.  Compared with many so-called "open systems" of
	today, the PDP-8 was far better documented and far more open.

	Finally, the PDP-8 is such a minimal machine that it is an excellent
	introduction to how computers really work.  Over the years, many
	students have built complete working PDP-8 systems from scratch as
	lab projects, and the I/O environment on a PDP-8 is simple enough
	that it is a very appropriate environment for learning operating
	system programming techniques.

Who's Who?

	C. Gordon Bell is generally credited with the original design of
	the PDP-8.  He was also involved with recommending what became
	the PDP-11 when that design was competing with the design that
	probably became the NOVA, and as vice president of research, he
	oversaw the development of the DEC VAX family.

	Alan Kotok worked with Bell in working up the original
	specifications of the PDP-8.

	Ben Gurley designed most of the big DEC machines, starting with
	the PDP-1.  The actual design work on the -8, however, was done
	by Ed deCastro, who later founded Data General to build the Nova.

	Ken Olson ran DEC from the beginning.

	Ed Yourdon, who later became well known as a programming methodology
	guru, hacked up the PAL III assembler for the -8, based on PAL II.

	Charles Lasner developed P?S/8, and he is widely known as the grand
	old man of the movement to preserve these historic machines.

	Wesley Clark developed the LINC while working at Lincoln Labs;
	this was the first 12 bit minicomputer built with DEC parts.

	Mary Allen Wilkes Clark developed the early LAP programs for the
	LINC.

	Douglas W. Jones wrote this FAQ, but prior to the summer of 1992,
	he'd never used a PDP-8.  He has also written a report on how to
	photocopy and archivally bind ailing paperback books such as DEC's
	handouts, and he has written a PAL-like cross assembler in C.


From sja@world.std.com Tue Oct 19 01:12:01 EDT 1993
Article: 411 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: samba.oit.unc.edu!concert!decwrl!world!sja
From: sja@world.std.com (Stuart J Adams)
Subject: Looking for rsx11 format floppy reader (Files 11/ods-1)
Message-ID: <CF2IDI.4qx@world.std.com>
Organization: The World Public Access UNIX, Brookline, MA
Date: Mon, 18 Oct 1993 00:51:17 GMT
Lines: 15


I am looking for a way to read ods-1 format (rsx11) floppies created on a VMS
machine on a Sun or PC. I found various programs to read the newer
ods-2 format but have not been able to find original ods-1 reader.
I believe the ods-1 format is the rsx11 (FILES 11) format used on 
the pdp 11 series ???

(I assume ods-1 format is what you get when you initialize the floppy
 with the vms command: initialize/structure=1 dkb400:)

Thanks,
Stuart Adams
sja@world.std.com


From brianm@cbme.unsw.EDU.AU Tue Oct 19 01:12:21 EDT 1993
Article: 412 of alt.sys.pdp8
Newsgroups: comp.sys.hp,alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!uunet!munnari.oz.au!metro!usage!brianm
From: brianm@cbme.unsw.EDU.AU (Brian Murray)
Subject: Hewlett Packard 9810A calculator
Message-ID: <1993Oct18.071411.4072@usage.csd.unsw.OZ.AU>
Summary: HP9810A
Sender: news@usage.csd.unsw.OZ.AU
Nntp-Posting-Host: plod.cbme.unsw.edu.au
Organization: none
References: <1993Oct1.170740.2114@NMC.ED.RAY.COM> <1993Oct4.135550.359@acs.eku.edu> <28qnes$5q9@c3po.jvnc.net>
Date: Mon, 18 Oct 1993 07:14:11 GMT
Lines: 21
Xref: samba.oit.unc.edu comp.sys.hp:33489 alt.sys.pdp8:412

I have an HP 9810A calculator (1971 vintage, about the size of
a large VCR, full of gold-plated PCB's, 3 line by 15 digit LED
display, thermal printer, magnetic program card reader/writer,
has plug-in rom cartridges, etc.) which almost works,
but not quite. I get the display to light up and it sort-of
responds to keypresses, but every numeral you type produces
a '0' digit on the display. Typing 3 digits for example
produces '000' on the display. Does anyone know anything about
this beast? Does anyone have any schematics for it? Anyone
know any tricky things about it (assuming I get it to
work again)? The pinout of the peripheral bus (it has 3
peripheral slots, as well as 3 cartridge slots)?
It came with 3 cartridges : Mathematics, Peripheral II,
and Printer Alpha. Anyone have any manuals that I might
be able to copy? Anyone even heard of it?

Thanks in advance ....
-- 
------------------------------------------------ Brian Murray ---
brianm@cbme.unsw.edu.au  CBX250  Apple//c  VAX 11/750  SGI Indigo
-----------------------------------------------------------------


From jones@cs.uiowa.edu Tue Oct 19 01:13:03 EDT 1993
Article: 413 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!umn.edu!spool.mu.edu!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@cs.uiowa.edu
Subject: Re: FOCAL
Sender: news@news.uiowa.edu (News)
Message-ID: <1993Oct18.165004.24802@news.uiowa.edu>
Date: Mon, 18 Oct 1993 16:50:04 GMT
References: <29uc0c$9bd@senator-bedfellow.MIT.EDU>
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: University of Iowa, Iowa City, IA, USA
Lines: 12
Xref: samba.oit.unc.edu alt.folklore.computers:48940 alt.sys.pdp8:413

grisha@athena.mit.edu (Crystobal J. Junta):

> So many people actually remember it! :-) Yay!!!

> 2. For old times' sake, would people like a comp.lang.focal newsgroup?

Given the tight historic link between FOCAL and the DEC PDP-8, why not
just discuss FOCAL in alt.sys.pdp8; that group has plenty of spare
bandwidth, and FOCAL fits right in.

                                Doug Jones
                                jones@cs.uiowa.edu


From lasner@sunSITE.unc.edu Tue Oct 19 01:33:20 EDT 1993
Article: 414 of alt.sys.pdp8
Path: samba.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: FOCAL
Date: 19 Oct 1993 05:33:37 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 54
Message-ID: <29vu7h$3mn@samba.oit.unc.edu>
References: <29uc0c$9bd@senator-bedfellow.MIT.EDU> <1993Oct18.165004.24802@news.uiowa.edu>
NNTP-Posting-Host: calypso.oit.unc.edu

In article <1993Oct18.165004.24802@news.uiowa.edu>,
 <jones@cs.uiowa.edu> wrote:
>grisha@athena.mit.edu (Crystobal J. Junta):
>
>> So many people actually remember it! :-) Yay!!!
>
>> 2. For old times' sake, would people like a comp.lang.focal newsgroup?
>
>Given the tight historic link between FOCAL and the DEC PDP-8, why not
>just discuss FOCAL in alt.sys.pdp8; that group has plenty of spare
>bandwidth, and FOCAL fits right in.

That suits me fine!  FOCAL is one of those topics that will get discussed
in conjunction with all older DEC machines.  The original PDP-8 version
spawned severall others, including some for other DEC machines under our
purview, etc.

Incidentally, FOCAL's source code carries an undeserved repuation for being
a piece of well-written PDP-8 code; it isn't really!  However, the following
*is* true about it:

1)	It has the handicap of having to be compatible with the PDP-5 and
PDP-8/s.  Thus several PDP-8 and up techniques can't be used.

2)	It was cross-developed on the TOPS-10 system to be assembled with PAL10
and listed on a line-printer during an era when PDP-8's generally had only
an ASR-33 terminal and no LPT:!  The documentation level can merely be
considered as more than minimal, and certainly less than more recent work
where an LPT: was available, etc.

3)	Some of the coding techniques are examples of how *not* to use
auto-index registers, since when used as in FOCAL, they are more trouble than
they are worth!  (Revisions of FOCAL exist which eliminate the auto-index
usage producing small faster code!)

4)	While FOCAL can run in 4K, it can be made quite a bit smaller than it
is in the original paper-tape version.  The P?S/8 version fits FOCAL including
a file system interface to P?S/8 in 4K!  It is possible under P?S/8 to
create FOCAL source files that are submitted as a batch to P?S/8 FOCAL
including any relevant data files, etc.  Additionally, FOCAL is often the
site of assembly-language patches to customize it for specific applications
and is highly documented in this regard.  The P?S/8 version is actually
highly compliant with the documentation in spite of the changes, etc., and
P?S/8 FOCAL includes a binary patch loader to allow and encourage this form
of customization, etc. (Binary patches and source files can both be passed to
P?S/8 FOCAL, etc.)  This is one language where if you don't like the lack of
a feature, just write it in!

FOCAL was once at the heart of a "great debate" within DEC.  Various people
went to bat in the FOCAL VS BASIC issues, etc.  In any case, we have both
FOCAL and BASIC in various forms; use whichever one is the most appropriate
(or FORTRAN or PASCAL or whatever you want!)

cjl (self-confessed occasional user of FOCAL)


From dicks@math.ohio-state.edu Wed Oct 20 03:27:48 EDT 1993
Article: 415 of alt.sys.pdp8
Path: samba.oit.unc.edu!concert!uvaarpa!caen!usenet.cis.ufl.edu!eng.ufl.edu!spool.mu.edu!howland.reston.ans.net!math.ohio-state.edu!not-for-mail
From: dicks@math.ohio-state.edu (Ethan Dicks)
Newsgroups: alt.sys.pdp8
Subject: Re: Looking for rsx11 format floppy reader (Files 11/ods-1)
Date: 19 Oct 1993 02:21:33 -0400
Organization: Department of Mathematics, The Ohio State University
Lines: 21
Sender: dicks@math.ohio-state.edu
Message-ID: <2a011d$gou@math.mps.ohio-state.edu>
References: <CF2IDI.4qx@world.std.com>

In article <CF2IDI.4qx@world.std.com>,
Stuart J Adams <sja@world.std.com> wrote:
>
>I am looking for a way to read ods-1 format (rsx11) floppies created on a VMS
>machine on a Sun or PC. I found various programs to read the newer
>ods-2 format but have not been able to find original ods-1 reader.
>I believe the ods-1 format is the rsx11 (FILES 11) format used on 
>the pdp 11 series ???

I'd like to know what you've found and where to get a copy of it.  I'd love
to be able to read ODS-2 floppies on a PC or under UNIX.  If I could do that,
I'd fire up a copy of vmsbackup and directly read backup floppies on a
useful machine.

-ethan

-- 
This message was (fortunately) not brought to you by Intel...
  "Intel: bringing you the "backward" in backward compatibilty."

dicks@math.ohio-state.edu -or- erd@kumiss.cmhnet.org


From jones@pyrite Wed Oct 20 03:29:04 EDT 1993
Article: 416 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!umn.edu!spool.mu.edu!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: FOCAL
Sender: news@news.uiowa.edu (News)
Message-ID: <1993Oct19.141601.22977@news.uiowa.edu>
Date: Tue, 19 Oct 1993 14:16:01 GMT
References: <1993Oct19.030832.1442@d-and-d.com>
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: University of Iowa, Iowa City, IA, USA
Lines: 20
Xref: samba.oit.unc.edu alt.folklore.computers:48975 alt.sys.pdp8:416

>From article <1993Oct19.030832.1442@d-and-d.com>,
by dnichols@d-and-d.com (DoN. Nichols):
> 
> 	But there wasn't room for a reasonable BASIC in the PDP-8.

First, there's no such thing as a reasonable BASIC.

Second, by 1973, DEC's EduSystem 5 was being sold, consisting of a
4K PDP-8/E with Basic.  The 1973 Introduction to Programming says
that this basic contained the following commands:  LET, PRINT,
READ, DATA, GOTO, IF, FOR, NEXT, GOSUB, RETURN, INPUT, REM, RESTORE,
DEF, DIM, STOP, END, LIST, RUN, SCRATCH, the single character print
command (:), and the nine standard functions.

Now I'll be the first to admit that this misses the boat in the
area of parameter passing, pointers, records, object oriented
development environments, and the like, but it is certainly as
reasonable a language as FOCAL.
					Doug Jones
					jones@cs.uiowa.edu


From lasner@sunSITE.unc.edu Wed Oct 20 03:59:51 EDT 1993
Article: 417 of alt.sys.pdp8
Path: samba.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: FOCAL
Date: 20 Oct 1993 08:00:13 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 90
Message-ID: <2a2r6d$m9u@samba.oit.unc.edu>
References: <1993Oct19.030832.1442@d-and-d.com> <1993Oct19.141601.22977@news.uiowa.edu>
NNTP-Posting-Host: calypso.oit.unc.edu

In article <1993Oct19.141601.22977@news.uiowa.edu>,
Douglas W. Jones,201H MLH,3193350740,3193382879 <jones@pyrite> wrote:
>
>First, there's no such thing as a reasonable BASIC.

Agreed, and as much an oxymoron as military intelligence or computer science.

>
>Second, by 1973, DEC's EduSystem 5 was being sold, consisting of a
>4K PDP-8/E with Basic.  The 1973 Introduction to Programming says
>that this basic contained the following commands:  LET, PRINT,
>READ, DATA, GOTO, IF, FOR, NEXT, GOSUB, RETURN, INPUT, REM, RESTORE,
>DEF, DIM, STOP, END, LIST, RUN, SCRATCH, the single character print
>command (:), and the nine standard functions.
>
>Now I'll be the first to admit that this misses the boat in the
>area of parameter passing, pointers, records, object oriented
>development environments, and the like, but it is certainly as
>reasonable a language as FOCAL.

Perhaps a brief history of PDP-8 BASIC is in order:

(in no particular order)

CINET-BASIC is really FOCAL patched to look like BASIC.  It runs as does
FOCAL in a 4K paper-tape environment that can be hostile to O/S'es with
conventions about the disposition of 07600-07777.  (A trait also shared by
many paper-tape programs, especially diagnostics!)

Lenny Elekman's 4K BASIC, as described above.  This is a tokenizing "digestive"
interpreter that can run much faster than brute-force interpreting FOCAL.  The
standard drawback applies: Comments waste space, and the precise form of the
original source is not preserved, rather the LIST command does a lot of
guesswork formatting, etc.  Again, it needs just about all of 4K, although
it will wipe out 07600-07777 as a pushdown stack, etc. so that OS's can
at least load it!

Various offshoots of Elekman's BASIC exist, such as Jack Burness' 8K version
and the variant of that usually known as LAB-8/E BASIC.  They are one and
the same program with conditional assembly for the lab functions, etc.  The
lab version has an interesting bug: should a lab peripheral cause an unexpected
interrupt, the location where the constant 10. is stored gets clobbered,
causing arithmetic errors and the curious LIST behavior where line numbers
get changed such as line 100 becomes line 104.57!  A still further variant
was added to CAPS-8.  Some of these systems go under the "edu-system"
series, but it's hard to tell the differences without a score-card.  I think
that EDU-10 and -5 are the same beast except that the ":" feature is missing
from -10.

There is some form of TSS8 BASIC which is supposed to run in 4K with a lot
of swapping unique to TSS8.

OS/8 BASIC uses a compiler and run-time system with a lot of chaining to
allow for excessive modularity as a deliberate design feature.  It is 
noteworthy as the most widely bug-reported OS/8 program of all time.  Variants
of it exist known as CBASIC (commercial BASIC meaning arithmetic on strings
containing decimal numbers) or Industrial BASIC (adding some digital I/O
functions, etc.).

Lenny Elekman and Richard Lary's original POLY BASIC is a true compiler,
run-time, and complete BASIC-only O/S that runs in 4K on a disk device
or DECtape.  This is an efficient compiler that creates interpretive code
quickly, and is ideal for student batch runs, etc.  DEC sold variants of it
called EDU-30 or -15/30.  Card reader support was added to allow for student
batches with off-line card preparation, etc.  Various people have worked on
variants of this for OS/8 as well.  At least one variation did something
rather interesting:  You are required to save the various components of
the program in a proscribed order on the system device, the only device the
program can be run from.  Then, you ought to delete all of the individual
entries, and create a super-entry covering all of the files, since the
modules load each other relying on the disk record offsets implied by the
saving procedure being explicitly followed, etc.  Thus, this is the only way
to guarantee that record ordering should the files be moved, etc.  Another
version was attempted using the same general methodology as OS/8 BASIC, etc.
which trades generic file handling for inefficiency, etc.

Contrasting this, all FOCAL implementations stem from FOCAL, 1969 or one
of its predecessors.  The standard version is the assembly of the two
files generally known as FOCAL.ZZM and FLOAT.ZZM.  The splitting of the
files into two modules is arbitrary, and doesn't completely address the usual
reasons for modularity, and are more likely related to file size than anything
else, etc.

Also, note that virtually all of these programs include a primitive albeit
functional editing environment to type in the programs.  All of the versions
that are not true compilers have to run with the editing means occupying
part of the 4K or 8K space!

cjl


From magnus@thep.lu.se Thu Oct 28 02:02:02 EDT 1993
Article: 418 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!paladin.american.edu!howland.reston.ans.net!pipex!sunic!news.lth.se!news.lu.se!magnus
From: magnus@thep.lu.se (Magnus Olsson)
Subject: FOCAL - some more questions
Message-ID: <1993Oct20.151252.17762@nomina.lu.se>
Sender: news@nomina.lu.se (USENET News System)
Nntp-Posting-Host: dirac.thep.lu.se
Organization: Dept. of Theoretical Physics, Lund University, Lund, Sweden
References: <1993Oct19.161828.5467@nomina.lu.se> <2a1m9o$b4j@senator-bedfellow.mit.edu>
Date: Wed, 20 Oct 1993 15:12:52 GMT
Lines: 46
Xref: samba.oit.unc.edu alt.folklore.computers:49014 alt.sys.pdp8:418

In article <2a1m9o$b4j@senator-bedfellow.mit.edu>,
Crystobal J. Junta <grisha@athena.mit.edu> wrote:
>I don't have any documentation, on machine-readable or hardcopy, but
>I do remember the language.

Thanks for posting the summary - it seems to be enough to get started!

Thanks also to James Hightower (jamesh@netcom.com) for posting the
FOCAL interpreter to alt.sources. I had some difficulties compiling it
under Ultrix - apparently the code to handle the Library command isn't
BSD 4.2 compatible. I've commented it out for the time being; as soon
as I get some time, I'll rewrite it so it compiles under Ultrix (and,
preferably, MS-DOS as well - somebody asked about compiling it under
MS-DOS). 

Also, the interpreter doesn't seem to be for exactly the same version
of the language as Crystobal's description. I'll probably hack it
so it agrees with Crystobal's post. Before I start, however, some
more questions:

* The posted interpreter interprets the line numbers in the way that
  "1.1" is equivalent to "1.01". Was this the normal FOCAL behaviour?

* The interpreter types all numbers in the E format, i.e., the number
  1 is typed as "1.00000E+01". Was this the normal behaviour on the
  old FOCAL implementations?  At least I would expect a more "user-
  friendly" floating point format, like that used by most Basics,
  from a novice language like FOCAL.

* Crystobal's post says that you could do things like
  A "Enter a number", number
  to first print a prompt, and then read in a number.
  The interpreter only accepts 
  A number
  without the prompt string. WHich behaviour was the most common?


Once I get the answer to these questions, I'll start hacking the
interpreter. If no legal hurdles turn up, I'll make the code
available on the Net as soon as it's finished.

              Magnus Olsson                | \e+      /_
    Department of Theoretical Physics      |  \  Z   / q
        University of Lund, Sweden         |   >----<           
 magnus@thep.lu.se,  thepmo@selund.bitnet  |  /      \===== g
PGP key available via finger or on request | /e-      \q


From jones@cs.uiowa.edu Thu Oct 28 02:04:23 EDT 1993
Article: 419 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!umn.edu!spool.mu.edu!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@cs.uiowa.edu
Subject: Re: FOCAL - What I know now and what I'd like to know
Sender: news@news.uiowa.edu (News)
Message-ID: <1993Oct20.175537.8517@news.uiowa.edu>
Date: Wed, 20 Oct 1993 17:55:37 GMT
References: <16C6DD70C.U204056@HNYKUN11.URC.KUN.NL>
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: University of Iowa, Iowa City, IA, USA
Lines: 40
Xref: samba.oit.unc.edu alt.folklore.computers:49019 alt.sys.pdp8:419

>From article <16C6DD70C.U204056@HNYKUN11.URC.KUN.NL>,
by U204056@HNYKUN11.URC.KUN.NL:
>  
> i : insert ?????
>  
> Now there are two ver important questions I'd like to ask.
>  
> 1) How are conditional operations done. I.e. is there some sort of
>    'if' ?
	That's the I command.  I as in IF.  IF expression a,b,c

	It's the old FORTRAN arithmetic IF statement, goto line a
	if the expression is less than zero, line b if it's equal
	to zero, and line c if it's greater than zero.

	If one of the destination addresses is missing, you fall through
	to the next instruction, possibly the next instruction on the
	same line if semicolons are used as instruction separators.

> 2) Is there a datatype like strings in FOCAL

	Not really.  On input, if you type letters when numbers are
	expected, you get something like A=0, B=1, C=2 ... and so on,
	except E which means "times ten to the".  Numeric constants such
	as 0yes (that's a leading zero) are legal.  As a result, you can
	accept textual input and compare it with the expected 0yes and 0no
	strings, but there's no way to distinguish "k" from "ba", and
	who knows what a "beet" evaluates to.  Don't try to write a
	word processor in FOCAL.

> (Right, I should look in the cs library. Yeah, unfortunatly nothing
>  like a manual could be found.....)

	Look under the title "Programming Lanugages" published by Digital
	Equipment Corporation in various editions in the early 1970's.
	It is Volume 2 of the PDP-8 Handbook Series, and it has chapters
	on FOCAL, FORTRAN, the PAL assembler, and other stuff.

					Doug Jones
					jones@cs.uiowa.edu


From frank@rover.uchicago.edu Thu Oct 28 02:05:37 EDT 1993
Article: 420 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: samba.oit.unc.edu!concert!xanth.cs.odu.edu!lll-winken.llnl.gov!uwm.edu!linac!uchinews!rover.uchicago.edu!frank
From: frank@rover.uchicago.edu (Frank - Hardware Hacker - Borger)
Subject: Re: FOCAL - what about a tutorial?
Message-ID: <20OCT199312032331@rover.uchicago.edu>
Followup-To: alt.sys.pdp8
News-Software: VAX/VMS VNEWS 1.41    
Sender: news@uchinews.uchicago.edu (News System)
Reply-To: frank@rover.uchicago.edu
Organization: Joint Center for Radiation Therapy
References: <1993Oct19.161828.5467@nomina.lu.se> <2a1m9o$b4j@senator-bedfellow.MIT.EDU>
Date: Wed, 20 Oct 1993 18:03:00 GMT
Lines: 38

In article <2a1m9o$b4j@senator-bedfellow.MIT.EDU>, grisha@athena.mit.edu (Crystobal J. Junta) writes...
>I don't have any documentation, on machine-readable or hardcopy, but
>I do remember the language.
> 
>Since it is an interpreter, you can use it in interactive mode and program 
>mode - just like BASIC.  To write a program, put line numbers before commands.
>Line numbers are, believe it or not, real with 1 or 2 digits after the decimal
>point.  So the following are valid line numbers:
> 
>1.01, 2.2, 3.41, 
>and the following are not valid:
>1, 1.00, 3.443

	Not valid as line numbers, but can be used in DO and GOTO statements

>D : Do.  Calls a subroutine, which are more like BASIC kind of subroutines than
>real procedures of structured languages.  Format: D line-number|line-group.
>This requires some explanation.  When you call D with a line number, it will go
>to that line number and start executing commands from there until it encounters
>R (or until the program ends). 

	As I remember it, D 1.23 would only execute line 1.23 and then return.

> Now, line-group concept is cute, IMO.  Line group
>is a number which an integer.  Thus 2, 3 are line groups.  Group 2 consists of all
>line numbers from 2.01 to 2.99, e.g., 2.1, 2.02, 2.33.  D called with a group 
>number as an argument, will go to the first line in the group and will execute
>lines in the group until it encounters R OR until the group ends.  

	Yes. The whole concept of floating-point line numbers made one cringe,
	but it really made for very tight code, an important point when a
	BIG machine had 12k bytes (8 k words.)
>					
Frank R. Borger - Physicist     ___      It's 9:00 am. Do you know where your
Michael Reese - U of Chicago   |___      children are? Well, it depends on
Center for Radiation Therapy   | |_) _   whether or not the Judge opened
net: Frank@rover.uchicago.edu    | \|_)  the schools today.
ph: 312-791-8075 fa: 791-2517       |_)  


From jones@pyrite Thu Oct 28 02:07:45 EDT 1993
Article: 421 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!umn.edu!zip.eecs.umich.edu!destroyer!uunet!pipex!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: FOCAL - some more questions
Sender: news@news.uiowa.edu (News)
Message-ID: <1993Oct20.191624.10712@news.uiowa.edu>
Date: Wed, 20 Oct 1993 19:16:24 GMT
References: <1993Oct20.151252.17762@nomina.lu.se>
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: University of Iowa, Iowa City, IA, USA
Lines: 106
Xref: samba.oit.unc.edu alt.folklore.computers:49030 alt.sys.pdp8:421

>From article <1993Oct20.151252.17762@nomina.lu.se>,
by magnus@thep.lu.se (Magnus Olsson):
> 
> * The posted interpreter interprets the line numbers in the way that
>   "1.1" is equivalent to "1.01". Was this the normal FOCAL behaviour?

Here's the output of a simple experiment, run under FOCAL 1969 on a PDP-8/E
emulator.  FOCAL 1969 is generally considered to be definitive.  It had
predecessors, but most later versions try for compatability with it.

*1.01 COMMENT
*1.1  COMMENT
*WRITE
C-FOCAL,1969

01.01 COMMENT
01.10 COMMENT
*

So, it's clear that 1.1 should be the same as 1.10 and not the same as 1.01

> * The interpreter types all numbers in the E format, i.e., the number
>   1 is typed as "1.00000E+01". Was this the normal behaviour on the
>   old FOCAL implementations?

Here's the output from another test run under FOCAL 1969 to demonstrate
the output formats:

*WRITE
C-FOCAL,1969

01.01 SET I=1
01.02 TYPE I,!
01.03 TYPE 1/I,!
01.04 SET I=I*10
01.05 GO 1.02
*GO
=    1.0000
=    1.0000
=   10.0000
=    0.1000
=  100.0000
=    0.0100
= 1000.0000
=    0.0010
= 10000.000
=    0.0001
= 100000.00
=    0.0000
= 1000000.0
=    0.0000
= 10000000
=    0.0000
= 0.10000010E+09
=    0.0000
= 0.1000?01.00 @ 01.03
*

The above run was terminated by hitting control C.  Note the clear and
understandable output diagnostics that result!  I think the ? is the
error indicator, the 01.00 is the error message, and the @ 01.03 says
it was executing line 1.03 when it was interrupted.

> * Crystobal's post says that you could do things like
>   A "Enter a number", number

Here's an example illustrating this.  All I did is change the above
program and run it again:

*01.01 A "Enter a Number",I
*GO
Enter a Number:8000000
= 8000000.0
=    0.0000
= 80000000
=    0.0000
= 0.80000010E+09
=    0.0000
= 0.80000010E+10
=    0.?01.00 @ 01.02
*

And, in your hacking, don't forget to include provisions for the
following behavior (again, I edited the program and then run it):

*01.02 TYPE I,!; GOTO 01.01
*GO
Enter a Number:A
=    1.0000
Enter a Number:B
=    2.0000
Enter a Number:AB
=   12.0000
Enter a Number:1E2
=  100.0000
Enter a Number:AEB
=  100.0000
Enter a Number:YES
= 0.25000000E+21
Enter a Number:?01.00 @ 01.01
*

Note that this is as far as FOCAL 1969 goes in string handling!

					Doug Jones
					jones@cs.uiowa.edu


From bennett@scm.dsto.gov.au Thu Oct 28 02:08:23 EDT 1993
Article: 422 of alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!ukma!eng.ufl.edu!spool.mu.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!dstos3.dsto.gov.au!bennett
From: bennett@scm.dsto.gov.au
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Subject: Re: FOCAL
Date: 21 Oct 93 09:05:40 +0930
Organization: Defence Science and Technology Organisation
Lines: 23
Message-ID: <1993Oct21.090540.1@scm.dsto.gov.au>
References: <1993Oct19.030832.1442@d-and-d.com> <1993Oct19.141601.22977@news.uiowa.edu>
NNTP-Posting-Host: dstos3.dsto.gov.au
Xref: samba.oit.unc.edu alt.folklore.computers:49051 alt.sys.pdp8:422

> From article <1993Oct19.030832.1442@d-and-d.com>,
> by dnichols@d-and-d.com (DoN. Nichols):
> 
> First, there's no such thing as a reasonable BASIC.

I hope I got the attribution right there.  Are you writing as a FOCAL lover, 
or comp.sci.language purist ?

While it was fashionable amongst computing science types to knock Basic, the 
usual argument overlooked the following :

1. Powerful software could be easily written and debugged in DEC's variations, 
   eg BasicPlus.  It could also be compiled in BP2. Long variable names made
   for readable code. 

2. It's just as easy to write bad code in Pascal etc as in Basic, ie, bad code 
   is more a function of the programmmer than the language.

(I'll just go and slip on my asbestos jocks !!)

Regards,

John Bennett                                   bennett@scm.dsto.gov.au


From dnichols@d-and-d.com Thu Oct 28 02:09:10 EDT 1993
Article: 423 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!ceilidh!dnichols
From: dnichols@d-and-d.com (DoN. Nichols)
Subject: Re: FOCAL
Message-ID: <1993Oct21.034520.6476@d-and-d.com>
Sender: usenet@d-and-d.com (Usenet)
Nntp-Posting-Host: shindig
Organization: D and D Data, Vienna VA
References: <1993Oct19.030832.1442@d-and-d.com> <1993Oct19.141601.22977@news.uiowa.edu> <1993Oct21.090540.1@scm.dsto.gov.au>
Date: Thu, 21 Oct 1993 03:45:20 GMT
Lines: 42
Xref: samba.oit.unc.edu alt.folklore.computers:49067 alt.sys.pdp8:423

In article <1993Oct21.090540.1@scm.dsto.gov.au> bennett@scm.dsto.gov.au writes:
>> From article <1993Oct19.030832.1442@d-and-d.com>,
>> by dnichols@d-and-d.com (DoN. Nichols):
>> 
>> First, there's no such thing as a reasonable BASIC.
>
>I hope I got the attribution right there.  Are you writing as a FOCAL lover, 

	Nope!  You didn't!  I *might* have added (but didn't) ", (if you can
consider BASIC to be reasonable. :-)"

>or comp.sci.language purist ?


What *I* wrote was:
->From article <1993Oct19.030832.1442@d-and-d.com>,
->by dnichols@d-and-d.com (DoN. Nichols):
->> 
->>       But there wasn't room for a reasonable BASIC in the PDP-8.

And, the line to which you were responding was written by:

->From: jones@pyrite (Douglas W. Jones,201H MLH, 3193350740,3193382879) 

Sorry that I've lost the article number - it wasn't included in the headers
I swept out of the previous article.

	I never really got a chance to use FOCAL.

	I've used several dialects of BASIC (after 6800 assembly language),
and managed to do reasonable things with them.  Some versions I find quite
reasonable, such as HP's "Rocky Mountain BASIC", or OS-9's BASIC-09.
However, I do find that I prefer languages like C, or even Pascal for the
sort of things that I would have done in BASIC.  (I say "even Pascal",
because I was using random-access files by the time I got to Pascal, and
most implementations don't make it very easy.  (Some don't even make it
possible. :-)
-- 
 Email:   <dnichols@d-and-d.com>  |  ...!uunet!ceilidh!dnichols 
		 <dnichols@ceilidh.beartrack.com>
 Donald Nichols (DoN.)  |   Voice (Days): (703) 704-2280 (Eves): (703) 938-4564
	--- Black Holes are where God is dividing by zero ---


From grisha@athena.mit.edu Thu Oct 28 02:11:09 EDT 1993
Article: 424 of alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!howland.reston.ans.net!sol.ctr.columbia.edu!news.kei.com!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!athena.mit.edu!grisha
From: grisha@athena.mit.edu (Crystobal J. Junta)
Newsgroups: alt.sys.pdp8
Subject: Re: FOCAL - what about a tutorial?
Date: 22 Oct 1993 12:13:33 GMT
Organization: Massachusetts Institute of Technology
Lines: 4
Distribution: world
Message-ID: <2a8ipd$1n0@senator-bedfellow.MIT.EDU>
References: <1993Oct19.161828.5467@nomina.lu.se> <2a1m9o$b4j@senator-bedfellow.MIT.EDU> <20OCT199312032331@rover.uchicago.edu>
NNTP-Posting-Host: w20-575-37.mit.edu

Also, there is a post on alt.folklore.computers - FOCAL-8 - which
gives a summary of the language.  I now realize that I forgot to describe
focal functions - well, :-(.  So if you want, check it out.


From cgordon@vpnet.chi.il.us Thu Oct 28 02:13:47 EDT 1993
Article: 425 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!amiserv!vpnet!cgordon
From: cgordon@vpnet.chi.il.us (gordon hlavenka)
Subject: Re: FOCAL
Message-ID: <1993Oct22.015933.17438@vpnet.chi.il.us>
Organization: Vpnet - Public Access Unix and Usenet
References: <29uc0c$9bd@senator-bedfellow.MIT.EDU> <1993Oct18.165004.24802@news.uiowa.edu>
Date: Fri, 22 Oct 1993 01:59:33 GMT
Lines: 26
Xref: samba.oit.unc.edu alt.folklore.computers:49169 alt.sys.pdp8:425

grisha@athena.mit.edu (Crystobal J. Junta):
>
>For old times' sake, would people like a comp.lang.focal newsgroup?

01.00 C RESPONSE POSTING
01.01 T "Hooray!!!",!
01.02 F X=1,10; D 2
01.03 T "Again?";A A
01.04 I (A-0Y)01.05,01.01,01.05
01.05 I (A-0N)01.03,01.06,01.03
01.06 Q

02.00 C RING TTY BELL
02.01 T "^G"

(or, for systems with 4 users and only 4K of core)
1.1 T "Hooray!!!",!;F X=1,10;T "^G"

(and yes, I know the "For" is superfluous...)

My apologies for posting source to a discussion group...:-)

-- 
----------------------------------------------------
Gordon S. Hlavenka           cgordon@vpnet.chi.il.us
Proud father of Daniel Scott     born August 9, 1993


From ivie@cc.usu.edu Thu Oct 28 02:14:29 EDT 1993
Article: 426 of alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Subject: Re: FOCAL - some more questions
Message-ID: <1993Oct22.101043.2424@cc.usu.edu>
Date: 22 Oct 93 10:10:43 MDT
References: <1993Oct19.161828.5467@nomina.lu.se> <2a1m9o$b4j@senator-bedfellow.mit.edu> <1993Oct20.151252.17762@nomina.lu.se>
Organization: Utah State University
Lines: 40
Xref: samba.oit.unc.edu alt.folklore.computers:49202 alt.sys.pdp8:426

In article <1993Oct20.151252.17762@nomina.lu.se>, magnus@thep.lu.se (Magnus Olsson) writes:
> Thanks also to James Hightower (jamesh@netcom.com) for posting the
> FOCAL interpreter to alt.sources. I had some difficulties compiling it
> under Ultrix - apparently the code to handle the Library command isn't
> BSD 4.2 compatible. I've commented it out for the time being; as soon
> as I get some time, I'll rewrite it so it compiles under Ultrix (and,
> preferably, MS-DOS as well - somebody asked about compiling it under
> MS-DOS). 

The library code will compile under Ultrix if you:

	- change "struct dir" to "struct dirent"
	- replace "DIRSIZ" with "MAXNAMLEN"

Don't know if it works; I haven't played with the library stuff.

The other change I had to make involved structs that ended with:

	  char whatever[];
	}

The code does this to malloc() a block of memory (for a program line or
a symbol value) with a header on the front. Ultrix disallows this. I modified
the struct to be:

	  char *whatever;
	}

and then modified the code allocating the structs to toss in the address of
the extra malloc()d space on the end.

Finally, I modified the code to not crash if the interpreter runs off the end
of the program.

With these changes, it runs under Ultrix. Still crashes under Alpha OSF/1, 
though.
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
ivie@cc.usu.edu |     'obsolete-ready'


From jac@pilot.njin.net Thu Oct 28 02:18:17 EDT 1993
Article: 427 of alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!howland.reston.ans.net!pipex!uunet!dziuxsolim.rutgers.edu!pilot.njin.net!jac
From: jac@pilot.njin.net (Jonathan Chandross)
Newsgroups: alt.folklore.computers,alt.sys.pdp8,alt.sources
Subject: FOCAL in C with doc and example
Message-ID: <Oct.22.22.42.03.1993.16572@pilot.njin.net>
Date: 23 Oct 93 02:42:05 GMT
Followup-To: alt.folklore.computers
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 2420
Xref: samba.oit.unc.edu alt.folklore.computers:49204 alt.sys.pdp8:427 alt.sources:7322

A few days ago someone posted a version of FOCAL that was written
in C.  Alas, it would not compile and came with no documentation.

I hacked it enough to make it compile (the original version as posted
is included), added a Makefile, wrote up a brief manual for it, and
wrote an example FOCAL script.  (As I've never written a FOCAL program
before this, experienced FOCAL programmers may take issue with it.)

I have tested it under SCO 3.2.4 and SunOS.  Change the OS line in the
Makefile to reflect your os.  I had to make a change (about 5 minutes
ago) to the line 170 in focal.c to make it work under SunOS:
	ctp = clp->l_text;
became:
	if (clp != NULL) {
		ctp = clp->l_text;
	} else
		ctp = NULL;
I also had to change DIRSIZ to dp.d_namelen on two lines.

I have tested the fixes (made a few minutes ago) under both SCO and SunOS
and the example program works correctly.  All of my poking around was done
under SCO, so the SunOS version may not be as robust.  I do not know if
these changes have broken something.

DISCLAIMER:
	I did not write the code; if you don't like the programming
	style, or the constructs make you shudder, don't blame me.

	I do not expect this to work on your machine. If it does not
	and you have a fix, send it to me.  I cannot provide assistance
	in debugging any problems you might encounter.

	I know next to nothing about the internals.

	Flamage to /dev/null.

Enjoy.

If you send me an interesting program I may include it in the next posting
of this, assuming I don't live to regret this posting version. 


Jonathan A. Chandross
Internet: jac@pilot.njin.net
UUCP: rutgers!pilot.njin.net!jac
********************************************************************************
:	This is a shell archive.
:	Remove everything above this line and
:	run the following text with /bin/sh to create:
:	Read.Me
:	example
:	Makefile
:	focal.c
:	focal.c.ORIG
: This archive created: Fri Oct 22 22:22:12 1993
cat << 'SHAR_EOF' > Read.Me

FOCAL 1981 Reference Manual

FOCAL stands for "Formulating On-line Calculations in Algebraic Language"
and is a very simple language performing calculations of various sorts.
This version of FOCAL, which I did *not* write, implements only a subset
of the FOCAL language as defined by DEC.  Major missing features include
built-in functions and the trace feature.  The error messages do not
conform to the DEC syntax, although this can be considered an
improvement.  Finally, the floating point math range is limited since it
uses doubles instead of the 24-bit two's complement mantissa and 12-bit
two's complement exponent format used by the PDP-8 implementation.

The contents of this all to brief manual were derived from:
	Title  = Programming Languages
	Series = Digital PDP-8 Handbook Series
	Author = Digital Equipment Corporation
	Date   = May, 1970
which contains greater details.

The "focal.c" program was posted to the net without any documentation in
1981 and reposted by a third party in 1993.  I took the 1993 posting, made
the program compile, and added a makefile, while keeping as close to the
original author's coding style as possible.  The original version can be
found in "focal.c.ORIG".  I don't know who the original author is and
neither does the fellow who reposted it in 1993.  I used my copy of the
_Programming Languages_ book to write up enough to use the package.

Files in this distribution:
	Makefile		Make script
	Read.Me			This file
	example			Example of the major FOCAL constructs
	focal.c			Focal interpreter in C
	focal.c.ORIG		Original version as posted to net

To run the example, invoke focal and then type:
	library call example
	go
or
	l c example
	g
depending upon how terse you like to be.  Alternatively, you can invoke
FOCAL and type commands at it.  The FOCAL prompt is a "*".

I had absolutely nothing whatsoever to do with the software other than
making the few minor changes necessary to make it work.

I make no representation that the information contained herein is
accurate or useful, nor do I make no representation that the software
will compile or execute properly on your machine.  If it does not, I
do not want to know about it.

Documentation and code changes COPYRIGHT 1993 by Jonathan A. Chandross.
Redistribution permitted so long as no charge is made and modifications
to either the code or the manual are clearly marked as such, and no
change leads the reader to conclude that I had anything to do with the
software.

I would like to thank Doug Jones for his useful comments on this brief
description of FOCAL.


Jonathan A. Chandross
jac@pilot.njin.net
10/20/93

********************************************************************************

Command   Abbreviation   Example of Form	Description
ask		a	 ask x,y,z		FOCAL types a colon for
						each variable; the user
						types a value to define
						each variable
comment		c	 comment		If a line begins with the
						letter C, the remainder
						of the line will be ignored
do		d	 do 4.1			Execute line 4.1; return
						to command following "do"
						command
			 do 4			Execute all lines in group 4;
						return to command following
						"do" command
			 do 4.0			Execute all lines in group 4;
						return to command following
						"do" command
erase		e	 erase			Erases the symbol table
			 erase 2.0		Erases all group 2 lines
			 erase 2.1		Deletes line 2.1
			 erase all		Deletes all lines
for		f	 for index=initial,limit,step; (commands)
			 for index=initial,limit; (commands)
						For loop.  Execute (commands)
						for each value:
						   index = initial
						   while index <= limit
						       <commands>
						       index = index + step
						For example,
							for i=1,10,2;t i!
						loops from 1 to 10 stepping
						by 2, printing out the loop
						index each time. If no step
						is specified, the value "1"
						is used.
go		g	 go			Starts execution with lowest
						numbered line number.
			 go 4.2			Go to line 4.2
goto		g	 goto			Starts execution with lowest
						numbered line number.
			 goto 4.2		Go to line 4.2
library call	l c	 library call <name>	Load program <name> from
						current directory
library delete	l d	 library delete <name>	Delete program <name> from
						current directory
library list	l l	 library list		List current directory
library save	l s	 library save <name>	Save program as <name>
if 		i	 if (x) L0, L1, L2	Where X is a defined
			 if (X) L0, L1;		identifier, a value, or an
			    (commands)		expression, followed by one
			 if (X) L0;		to three line numbers:
			    (commands)		  If X < 0 goto L0
						  if X = 0 goto L1
						  if X > 0 goto L2
quit		q	 quit			Exit FOCAL
return		r	 return			Terminates "do" subroutine
						and returns to caller
set		s	 set a = 5/b*c;		Defines identifiers in the
						symbol table
type		t	 type a * b + c;	Evaluates expression and
						types out "=" and result
						in current output format
			 type a - b, c/e;	Computes and types each
						expression separated by
						commas.
			 type "text"		Types "text".  May be
						followed by "!" to
						generate carriage-return
						line-feed, or "#" to
						generate carriage-return.
						The "$" option is not
						supported.
write		w	 write			FOCAL types out the entire
			 write all		indirect program
			 write 1.0		FOCAL types out all group
						1 lines
			 write 1.1		FOCAL types out line 1.1
						1 lines

********************************************************************************

Operators:
	Name	Syntax		Description
	+	a + b		Addition
	-	a - b		Subtraction
	*	a * b		Multiplication
	/	a / b		Division

********************************************************************************

Grouping operators: (),<>,[]
	()
	<>
	[]

	Example:
		set x = [<(a * b) + c> / d]

	Note that the "(" and ")" operators are also used for arrays.

********************************************************************************

Arrays:
	An array element is defined by assigning to it.  Referring to
	an undefined element results in an error.  For example, the
	command below creates an array with ten elements by setting
	each element to the value "30":
		for i=1,10; set coeff(i) = 30;
	The command below prints out the array:
		for i=1,10; t coeff(i)!;

********************************************************************************

Output Control:
	Name	Syntax		Description
	"	"..."		Text string.
					t "this is a string"
	!	"..."!		Output a carriage-return, line-feed after
				the string
					t "this is a string"!
	#	"..."#		Output a carriage-return after string
					t "this is a string"#
	%	%x.y		Output in scientific notation
				   x	total number of digits to be output
				   y	number of digits to right of decimal
					point

********************************************************************************

Line Numbering:
	Any line not beginning with a line number is executed immediately.
	Line numbers take the form:
		<group> "." <line>
	For example:
		2.1 type "This is line 2.1"!
	This creates the line "1" in the group "2".

	The <group> provides a way to package a sequence of lines.  This
	allows the sequence to be invoked as a subroutine, or manipulated
	in other ways, such as deleting the group as a whole or printing
	it out as a whole.  For example, the command:
		erase 2
	deletes all lines in group 2.

********************************************************************************

Line Syntax:

	Multiple commands can be placed on the same line provided each
	is separated by a ";".  The syntax is:
		<command> [";" <command>]*
	For example:
		set x = 3;set y =5; type x + y

	This ";" separator is also used by the "for" statement to separate
	the statements to execute during each iteration.  Given a "for"
	loop of the form:
		for ...;s1,s2,s3
	s1, s2, and s3 are the statements executed during each iteration
	of the "for" loop.  For example
		for i = 1,10,2; type "i is ", i!; type "i + 2 is ", i + 2!
SHAR_EOF
cat << 'SHAR_EOF' > example
1.01 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
1.02 C
1.03 C Brief demonstration of FOCAL's features.
1.04 C
1.05 C COPYRIGHT 1993 by Jonathan A. Chandross (jac@pilot.njin.net)
1.06 C All Rights Reserved
1.07 C Redistribution without fee permitted.
1.08 C
1.09 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
1.10 set a=1; set b=2
1.20 type "Calling subroutine 10, value is: ",%1.a+b!
1.21 do 10
1.22 type "Returned from subroutine, exiting."!
1.23 type "Calling subroutine 20"!
1.24 do 20
1.25 type "Calling line 11 in subroutine 20"!
1.26 do 20.11
1.30 type "Calling subroutine 30"!
1.31 do 30
1.40 type "Calling subroutine 40"!
1.41 do 40
1.50 type "Calling subroutine 50"!
1.51 do 50
1.94 quit
1.95 type "THIS LINE NEVER EXECUTES"!

10.01 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
10.02 C
10.03 C Group 10
10.04 C
10.05 C Give global variables "a" and "b" new values
10.06 C Print out message and sum
10.07 C Return
10.08 C
10.09 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
10.10 set a=3; set b=4
10.11 type "In Subroutine, value is: ",%1.a+b!
10.12 return
10.13 type "THIS LINE IN SUBROUTINE NEVER EXECUTES"!

20.01 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
20.02 C
20.03 C Group 20
20.04 C
20.06 C Print out message 1
20.06 C Print out message 2
20.08 C
20.09 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
20.10 type "In Subroutine 20, line 10, MESSAGE 1"!
20.11 type "In Subroutine 20, line 11, MESSAGE 2"!
20.12 return

30.01 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
30.02 C
30.03 C Group 30
30.04 C
30.06 C Output what we are doing
30.06 C output numbers from 1 to 10, stepping by 2
30.08 C
30.09 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
30.10 type "Counting to 10 by 2's"!
30.11 for i = 1,10,2; type i!
30.12 return

40.01 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
40.02 C
40.03 C Group 40
40.04 C
40.06 C Prompt for a number
40.06 C Print out whether number is < 0, = 0, or > 0
40.08 C
40.09 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
40.10 type "Input a number"
40.20 ask x
40.25 if x 40.30, 40.40, 40.50
40.30 type "Value ", x, " < 0"!; return
40.40 type "Value ", x, " = 0"!; return
40.50 type "Value ", x, " > 0"!; return

50.01 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
50.02 C
50.03 C Group 50
50.04 C
50.06 C Demonstrates arrays
50.06 C for i = 1 to 3
50.07 C		value[i] = 10 + i
50.08 C		print "Entry[" i "] is" value[i]
50.09 C
50.10 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
50.20 for i = 1,3; set value(i) = 10 + i; type "Entry(",i,") = ",value(i)!
SHAR_EOF
cat << 'SHAR_EOF' > Makefile

CC	= /usr/local/bin/gcc

OS	= -Dunix -Dbsd_unix
#OS	= -Dunix -Dsysv_unix
#OS	= -Dvms
#OS	= -Ddecus

FLAGS	= $(OS) -g2

all: focal

focal: focal.c
	$(CC) $(FLAGS) -o focal focal.c
	
clean:
	rm -f focal

SHAR_EOF
cat << 'SHAR_EOF' > focal.c
/*
 * Focal, 1981.
 * Dedicated to the old times,
 * when an 8k PDP-8 was considered
 * a BIG machine.
 */

#include <stdio.h>

#ifndef decus
#include <ctype.h>
#include <signal.h>
#else
int     $$narg = 1;                     /* No argv prompt               */
#endif

#include <setjmp.h>

#ifdef  bsd_unix
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/dir.h>
#endif

#ifdef  sysv_unix
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/dir.h>
#endif

#define NID     16                      /* # characters in id */

struct  line
{
        struct  line *l_fp;             /* Link */
        char    l_lno;                  /* Line */
        char    l_gno;                  /* Group */
        char    *l_text;                /* Text */
};

struct  lno
{
        char    ln_lno;                 /* Line */
        char    ln_gno;                 /* Group */
        int     ln_type;                /* Type */
};

#define LN_ALL  0                       /* All */
#define LN_GRP  1                       /* Group */
#define LN_LINE 2                       /* Line */
#define LN_NONE 3                       /* No number */

struct  control
{
        struct  control *c_fp;          /* Link */
        int     c_mode;                 /* Control mode */
        struct  line *c_lp;             /* Saved current line */
        char    *c_tp;                  /* Saved text pointer */
        struct  sym *c_sp;              /* Symbol (for) */
        double  c_limit;                /* Limit (for) */
        double  c_step;                 /* Step (for) */
};

#define C_TOP   0                       /* Top level */
#define C_DLINE 1                       /* Do line */
#define C_DGRP  2                       /* Do group */
#define C_DALL  3                       /* Do all */
#define C_FOR   4                       /* FOR loop */

struct  sym
{
        struct  sym *s_fp;              /* Link */
        int     s_type;                 /* Type of entry */
        int     s_subs;                 /* Subscript */
        union   {
                double  s_value;        /* The data */
                double  (*s_funp)();    /* Function pointer */
        } s_un;
        char    *s_id;                 /* Name */
};

#define S_SCAL  0
#define S_ARRAY 1
#define S_FUNC  2

char    cbuf[128];                      /* Command buffer */
char    abuf[128];                      /* Ask buffer */
char    *ctp;                           /* Current text pointer */
struct  line    *line;                  /* Line list header */
struct  line    *clp;                   /* Current line pointer */
struct  sym     *sym;                   /* Symbol table */
int     mode;                           /* Current processing mode */
struct  sym     *forsp;                 /* Symbol pointer (for) */
double  forlimit;                       /* Loop limit (for) */
double  forstep;                        /* Loop step (for) */
struct  control *control;               /* Control stack */
jmp_buf env;                            /* Saved state for errors */
int     intflag;                        /* Interrupt flag */

extern double  atof();
extern void    onintr();                       /* ^C catcher */
extern double  eval();
extern double  primary();
extern double  term();
extern struct  sym     *getsym();
extern struct  sym     *lookup();
extern struct  line    *alocline();

main()
{
        register c;

        setjmp(env);
#ifndef decus
        signal(SIGINT, &onintr);
#endif
	printf("\nFOCAL 1981\n\n");
        for (;;) {
                putchar('*');
                if (gets(cbuf) == NULL) {
                        putchar('\n');
                        break;
                }
                mode = C_TOP;
                clp  = NULL;
                ctp  = cbuf;
                if ((c=getnb()) != 0) {
                        if (isdigit(c))
                                inject(c);
                        else {
                                --ctp;
                                process();
                        }
                }
        }
}

process()
{
        double limit, step;
        double value;
        register c;
        register struct sym *sp;
        register struct line *lp;
        struct lno lno;
        struct line *lp1, *lp2, *lp3;
        int grp;

loop:
        if (intflag) {
                intflag = 0;
                diag("^C");
        }
        while ((c=getnb()) == ';')
                ;
        if (c == 0) {
                if (mode == C_FOR) {
                        forsp->s_un.s_value += forstep;
                        if (forstep>0.0 && forsp->s_un.s_value<=forlimit
                        ||  forstep<0.0 && forsp->s_un.s_value>=forlimit) {
                                clp = control->c_lp;
                                ctp = control->c_tp;
                                goto loop;
                        }
                        popfor();
                }
                if (clp != NULL) {
                        grp = clp->l_gno;
                        clp = clp->l_fp;
			if (clp != NULL) {
				ctp = clp->l_text;
			} else
				ctp = NULL;
                }
                if (clp == NULL) {
                        if (mode == C_TOP)
                                return;
                        popdo();
                } else if (mode == C_DLINE
                || (mode==C_DGRP && grp!=clp->l_gno))
                        popdo();
                goto loop;
        }
        while (isalpha(*ctp))
                ++ctp;
        if (isupper(c))
                c = tolower(c);
        switch (c) {

        case 'a':
                do {
                        sp = getsym();
                        putchar(':');
                        if (gets(abuf) == NULL) {
                                putchar('\n');
                                diag("EOF in ask");
                        }
                        sp->s_un.s_value = atof(abuf);
                } while ((c=getnb()) == ',');
                --ctp;
                break;

        case 'c':
                while (*ctp != 0)
                        ++ctp;
                break;

        case 'd':
                getlno(&lno, -1);
                pushdo();
                if (lno.ln_type==LN_NONE || lno.ln_type==LN_ALL) {
                        if ((clp=line) == NULL)
                                diag("No program");
                        ctp = clp->l_text;
                        mode = C_DALL;
                        goto loop;
                }
                if (lno.ln_type == LN_GRP) {
                        lp = line;
                        while (lp!=NULL && lp->l_gno<lno.ln_gno)
                                lp = lp->l_fp;
                        if (lp!=NULL && lp->l_gno==lno.ln_gno) {
                                clp = lp;
                                ctp = clp->l_text;
                                mode = C_DGRP;
                                goto loop;
                        }
                        badline();
                }
                lp = line;
                while (lp != NULL
                && (lp->l_gno != lno.ln_gno
                ||  lp->l_lno != lno.ln_lno))
                        lp = lp->l_fp;
                if (lp != NULL) {
                        clp = lp;
                        ctp = clp->l_text;
                        mode = C_DLINE;
                        goto loop;
                }
                badline();

        case 'e':
                getlno(&lno, -1);
                if (lno.ln_type == LN_NONE) {
                        erasesyms();
                        break;
                }
                lp1 = NULL;
                lp2 = line;
                while (lp2 != NULL) {
                        if (lno.ln_type == LN_ALL
                        || (lp2->l_gno  == lno.ln_gno
                        && (lno.ln_type==LN_GRP || lp2->l_lno==lno.ln_lno))) {
                                if (lp2 == clp)
                                        diag("Erasing current line");
                                lp3 = lp2;
                                lp2 = lp2->l_fp;
                                if (lp1 == NULL)
                                        line = lp2; else
                                        lp1->l_fp = lp2;
                                free((char *) lp3);
                        } else {
                                lp1 = lp2;
                                lp2 = lp2->l_fp;
                        }
                }
                break;

        case 'f':
                sp = getsym();
                clearfors(sp);
                if (getnb() != '=')
                        diag("Missing = sign");
                sp->s_un.s_value = eval();
                if (getnb() != ',')
                        diag("Missing comma");
                limit = eval();
                if ((c=getnb()) == ';')
                        step = 1.0;
                else if (c == ',') {
                        step = eval();
                        if (getnb() != ';')
                                diag("Missing semi");
                } else
                        diag("Bad for");
                pushfor();
                forsp = sp;
                forlimit = limit;
                forstep = step;
                mode = C_FOR;
                break;

        case 'g':
                getlno(&lno, -1);
                if (lno.ln_type == LN_NONE) {
                        if ((clp=line) == NULL)
                                diag("No program");
                        ctp = clp->l_text;
                        goto loop;
                } else if (lno.ln_type == LN_LINE) {
                        lp = line;
                        while (lp != NULL
                        && (lp->l_gno != lno.ln_gno
                        ||  lp->l_lno != lno.ln_lno))
                                lp = lp->l_fp;
                        if (lp != NULL) {
                                clp = lp;
                                ctp = clp->l_text;
                                goto loop;
                        }
                }
                badline();

        case 'i':
                value = eval();
                if (value >= 0.0) {
                        while ((c = *ctp)!=0 && c!=',' && c!=';')
                                ++ctp;
                        if (c != ',')
                                goto loop;
                        ++ctp;
                        if (value != 0.0) {
                                while ((c = *ctp)!=0 && c!=',' && c!=';')
                                        ++ctp;
                                if (c != ',')
                                        goto loop;
                                ++ctp;
                        }
                }
                getlno(&lno, -1);
                if (lno.ln_type == LN_LINE) {
                        lp = line;
                        while (lp != NULL
                        && (lp->l_gno != lno.ln_gno
                        ||  lp->l_lno != lno.ln_lno))
                                lp = lp->l_fp;
                        if (lp != NULL) {
                                clp = lp;
                                ctp = clp->l_text;
                                goto loop;
                        }
                }
                badline();

        case 'l':
                library();
                break;

        case 'q':
                if (clp == NULL)
                        exit(0);
                return;

        case 't':
                type();
                break;

        case 'r':
                while (mode == C_FOR)
                        popfor();
                popdo();
                break;

        case 's':
                sp = getsym();
                if (getnb() != '=')
                        diag("Missing = sign");
                sp->s_un.s_value = eval();
                break;

        case 'w':
                getlno(&lno, -1);
                save(&lno, stdout);
                break;

        default:
                diag("Illegal command");
        }
        goto loop;
}

badline()
{
        diag("Bad line number");
}

pushdo()
{
        register struct control *cp;

        if ((cp=(struct control *)malloc(sizeof(struct control))) == NULL)
                diag("Out of space (control stack)");
        cp->c_fp = control;
        control  = cp;
        cp->c_mode = mode;
        cp->c_tp = ctp;
        cp->c_lp = clp;
}

pushfor()
{
        register struct control *cp;

        if ((cp=(struct control *)malloc(sizeof(struct control))) == NULL)
                diag("Out of space (control stack)");
        cp->c_fp = control;
        control  = cp;
        cp->c_mode = mode;
        cp->c_tp = ctp;
        cp->c_lp = clp;
        cp->c_sp = forsp;
        cp->c_limit = forlimit;
        cp->c_step = forstep;
}

popdo()
{
        register struct control *cp;

        if ((cp=control) == NULL)
                diag("Return not in do");
        control = cp->c_fp;
        ctp = cp->c_tp;
        clp = cp->c_lp;
        mode = cp->c_mode;
        free((char *) cp);
}

popfor()
{
        register struct control *cp;

        if ((cp=control) == NULL)
                diag("For stack botch");
        control = cp->c_fp;
        forsp = cp->c_sp;
        forlimit = cp->c_limit;
        forstep = cp->c_step;
        mode = cp->c_mode;
        free((char *) cp);
}

clearfors(sp)
register struct sym *sp;
{
        register struct control *cp1, *cp2;


        if (mode==C_FOR && forsp==sp)
                popfor();
        else {
                cp1 = NULL;
                cp2 = control;
                while (cp2 != NULL) {
                        if (cp2->c_mode==C_FOR && cp2->c_sp==sp) {
                                if (cp1 == NULL)
                                        control = cp2->c_fp; else
                                        cp1->c_fp = cp2->c_fp;
                                free((char *) cp2);
                                break;
                        }
                        cp1 = cp2;
                        cp2 = cp2->c_fp;
                }
        }
}

library()
{
        register char *p;
        register c, d;
        char *sctp;
        struct line *lp1, *lp2;
#ifdef  bsd_unix
        struct direct db;
#endif
#ifdef  sysv_unix
        struct direct db;
#endif
        struct stat sb;
        int     fd;
        register FILE *fp;

        c = getnb();
        if (c!='c' && c!='s' && c!='l' && c!='d')
                diag("Bad library command");
        while (isalpha(*ctp))
                ++ctp;
        while ((d = *ctp)==' ' || d=='\t')
                ++ctp;
        if (c!='l' && d==0)
                diag("Missing file name");
        p = ctp;
        while (*ctp != 0)
                ++ctp;
        switch (c) {

        case 'c':
                if ((fp=fopen(p, "r")) == NULL)
                        diag("Cannot open");
                lp1 = line;
                while (lp1 != NULL) {
                        lp2 = lp1->l_fp;
                        free ((char *) lp1);
                        lp1 = lp2;
                }
                line = NULL;
                sctp = ctp;
                while (getline(abuf, fp) != 0) {
                        ctp = abuf;
                        if ((c=getnb()) != 0) {
                                if (isdigit(c) == 0)
                                        diag("Direct line in call");
                                inject(c);
                        }
                }
                fclose(fp);
                ctp = sctp;
                break;

#ifdef  unix
        case 'd':
                if (unlink(p) < 0)
                        diag("Cannot delete");
                break;

        case 'l':
                if (d == 0)
                        p = ".";
                if (stat(p, &sb) < 0
                || (sb.st_mode&S_IFMT) != S_IFDIR
                || (fd = open(p, 0)) < 0)
                        diag("Bad directory");
#ifdef  bsd_unix
                while (read(fd, &db, sizeof(db)) == sizeof(db)) {
                        if (db.d_ino == 0
                        ||  strncmp(db.d_name, ".",  db.d_namlen) == 0
                        ||  strncmp(db.d_name, "..", db.d_namlen) == 0)
                                continue;
                        printf("%.*s\n", db.d_namlen, db.d_name);
                }
#endif
#ifdef sysv_unix
                while (read(fd, &db, sizeof(db)) == sizeof(db)) {
                        if (db.d_ino == 0
                        ||  strncmp(db.d_name, ".",  DIRSIZ) == 0
                        ||  strncmp(db.d_name, "..", DIRSIZ) == 0)
                                continue;
                        printf("%.*s\n", DIRSIZ, db.d_name);
                }
#endif
                close(fd);
                break;
#endif
        case 's':
                if ((fp=fopen(p, "w")) == NULL)
                        diag("Cannot create");
                save(NULL, fp);
                fclose(fp);
                break;
        }
}

inject(c)
register c;
{
        register struct line *lp1, *lp2, *lp3;
        struct lno  lno;

        getlno(&lno, c);
        if (lno.ln_type != LN_LINE)
                diag("Illegal line number");
        lp1 = NULL;
        lp2 = line;
        while (lp2 != NULL
        && (lp2->l_gno < lno.ln_gno
        || (lp2->l_gno==lno.ln_gno&&lp2->l_lno<=lno.ln_lno))) {
                if (lp2->l_gno == lno.ln_gno
                &&  lp2->l_lno == lno.ln_lno) {
                        lp3 = lp2;
                        lp2 = lp2->l_fp;
                        if (lp1 == NULL)
                                line = lp2; else
                                lp1->l_fp = lp2;
                        free((char *) lp3);
                        break;
                }
                lp1 = lp2;
                lp2 = lp2->l_fp;
        }
        if ((c=getnb()) != 0) {
                lp3 = alocline(--ctp);
                lp3->l_fp  = lp2;
                lp3->l_gno = lno.ln_gno;
                lp3->l_lno = lno.ln_lno;
                strcpy(lp3->l_text, ctp);
                if (lp1 == NULL)
                        line = lp3; else
                        lp1->l_fp = lp3;
        }
}

getline(cp, fp)
register char *cp;
register FILE *fp;
{
        register c;

        while ((c=getc(fp))!=EOF && c!='\n')
                *cp++ = c;
        if (c == EOF)
                return (0);
        *cp = 0;
        return (1);
}

type()
{
        register char *fmt;
        register c;
        char fmtb[20];
        int x, y;

        fmt = "%6e";
        while ((c=getnb())!=0 && c!=';') {
                if (c == '%') {
                        if ((c=getnb())==0 || c==';' || c==',') {
                                fmt = "%6e";
                                --ctp;
                                continue;
                        }
                        x = getnum(c);
                        if (getnb() != '.')
                                diag("Missing . in format");
                        y = getnum(getnb());
                        sprintf(fmtb, "%%%d.%df", x, y);
                        fmt = fmtb;
                        continue;
                }
                if (c == ',')
                        continue;
                if (c == '!') {
                        putchar('\n');
                        continue;
                }
                if (c == '#') {
                        putchar('\r');
                        continue;
                }
                if (c == '"') {
                        while ((c = *ctp++)!='\0' && c!='"')
                                putchar(c);
                        if (c == '\0') {
                                diag("Missing string quote");
                                break;
                        }
                        continue;
                }
                --ctp;
                printf(fmt, eval());
        }
        --ctp;
}

save(lnop, fp)
register struct lno *lnop;
FILE *fp;
{
        struct lno lno;
        register struct line *lp;
        register tgroup, lgroup;

        if (lnop == NULL) {
                lno.ln_type = LN_ALL;
                lnop = &lno;
        }
        lp = line;
        if (lnop->ln_type!=LN_NONE && lnop->ln_type!=LN_ALL) {
                while (lp!=NULL && lp->l_gno<lnop->ln_gno)
                        lp = lp->l_fp;
                if (lp==NULL || lp->l_gno!=lnop->ln_gno)
                        diag("Line not found");
                if (lnop->ln_type == LN_LINE) {
                        while (lp!=NULL && lp->l_lno!=lnop->ln_lno)
                                lp = lp->l_fp;
                        if (lp == NULL)
                                diag("Line not found");
                }
        }
        while (lp != NULL) {
                putline(lp, fp);
                if (lnop->ln_type == LN_LINE)
                        break;
                lgroup = lp->l_gno;
                if ((lp = lp->l_fp) != NULL) {
                        tgroup = lp->l_gno;
                        if (lnop->ln_type==LN_GRP && tgroup!=lnop->ln_gno)
                                break;
                        if (tgroup != lgroup)
                                putc('\n', fp);
                }
        }
}

double
eval()
{
        double val, rop;
        register c;

        if ((c=getnb())=='+' || c=='-') {
                val = primary();
                if (c == '-')
                        val = -val;
        } else {
                --ctp;
                val = primary();
        }
        while ((c=getnb())=='+' || c=='-') {
                rop = primary();
                if (c == '+')
                        val = val + rop;
                else
                        val = val - rop;
        }
        --ctp;
        return (val);
}

double
primary()
{
        double val, rop;
        register c;

        val = term();
        while ((c = getnb())=='*' || c=='/') {
                rop = term();
                if (c == '*')
                        val = val * rop;
                else
                        val = val / rop;
        }
        --ctp;
        return (val);
}

double
term()
{
        register c;
        register char *cp;
        double val;
        int fsign, fdot, fexp;
        int term_type, subs;
        struct sym *sp;
        char id[NID];
        char nbuf[20];

        if ((c = getnb())=='(' || c=='[' || c=='<') {
                val = eval();
                if (++c != ')')
                        ++c;
                if (c != getnb())
                        diag("Mismatched enclosures");
                return (val);
        }
        if (c=='.' || isdigit(c)) {
                fsign = 1;
                fexp = 0;
                fdot = 0;
                if (c == '.')
                        ++fdot;
                cp = &nbuf[0];
                for (;;) {
                        if (cp >= &nbuf[19])
                                diag("Number too long");
                        *cp++ = c;
                        if ((c = *ctp++) == '.') {
                                if (fdot++)
                                        break;
                        } else if (c == 'e') {
                                if (fexp++)
                                        break;
                                fsign = 0;
                                fdot = 1;
                        } else if (c=='+' || c=='-') {
                                if (fsign++)
                                        break;
                        } else if (!isdigit(c))
                                break;
                }
                --ctp;
                *cp = '\0';
                return (atof(nbuf));
        }
        if (isalpha(c)) {
                cp = &id[0];
                do {
                        if (cp < &id[NID-1])
                                *cp++ = c;
                        c = *ctp++;
                } while (isalnum(c));
                *cp = 0;
                if (id[0] == 'f') {
                        /* ... */
                }
                term_type = S_SCAL;
                while (c==' ' || c=='\t')
                        c = *ctp++;
                if (c == '(') {
                        term_type = S_ARRAY;
                        subs = (int) eval();
                        if (getnb() != ')')
                                diag("Missing ) in subscript");
                } else
                        --ctp;
                if ((sp=lookup(id, term_type, subs)) == NULL)
                        diag("Undefined variable");
                return (sp->s_un.s_value);
        }
        diag("Expression syntax");
}

struct  sym *
lookup(id, lookup_type, subs)
char *id;
register lookup_type;
{
        register struct sym *sp;

        sp = sym;
        while (sp != NULL) {
                if (sp->s_type == lookup_type
                && (lookup_type!=S_ARRAY || sp->s_subs==subs)
                &&  strcmp(id, sp->s_id) == 0)
                        break;
                sp = sp->s_fp;
        }
        return (sp);
}

struct sym *
getsym()
{
        register c;
        char id[NID];
        register char *cp;
        register struct sym *sp;
        int subs, getsym_type;

        if (isalpha(c = getnb()) == 0)
                diag("Missing variable");
        cp = &id[0];
        do {
                if (cp < &id[NID-1])
                        *cp++ = c;
                c = *ctp++;
        } while (isalnum(c));
        *cp = 0;
        getsym_type = S_SCAL;
        while (c==' ' || c=='\t')
                c = *ctp++;
        if (c == '(') {
                getsym_type = S_ARRAY;
                subs = (int) eval();
                if (getnb() != ')')
                        diag("Bad subscript");
        } else
                --ctp;
        if ((sp=lookup(id, getsym_type, subs)) == NULL) {
                sp = (struct sym *)malloc(sizeof(*sp));
                if (sp == NULL)
                        diag("Out of space (symbols)");
                sp->s_id = (char *)malloc(strlen(id)+1);
                sp->s_fp = sym;
                sym = sp;
                sp->s_type = getsym_type;
                sp->s_subs = subs;
                strcpy(sp->s_id, id);
        }
        return (sp);
}

putline(lp, fp)
register struct line *lp;
FILE *fp;
{
        fprintf(fp, "%02d.%02d %s\n", lp->l_gno, lp->l_lno, lp->l_text);
}

static char badlno[] = "Bad line or group number";

getlno(lnop, c)
register struct lno *lnop;
register c;
{
        register gn, ln;

        if (c < 0)
                c = getnb();
        if (c=='\0' || c==';') {
                --ctp;
                lnop->ln_type = LN_NONE;
                return;
        }
        if (c=='A' || c=='a') {
                while (isalpha(*ctp))
                        ++ctp;
                lnop->ln_type = LN_ALL;
                return;
        }
        if (!isdigit(c))
                diag(badlno);
        if ((gn = getnum(c))<1 || gn>99)
                diag(badlno);
        if (*ctp != '.') {
                lnop->ln_gno = gn;
                lnop->ln_lno = 0;
                lnop->ln_type = LN_GRP;
                return;
        }
        ++ctp;
        if ((ln=getnum(*ctp++)) == 0) {
                lnop->ln_gno = gn;
                lnop->ln_lno = 0;
                lnop->ln_type = LN_GRP;
                return;
        }
        if (ln<1 | ln>99)
                diag(badlno);
        lnop->ln_gno = gn;
        lnop->ln_lno = ln;
        lnop->ln_type = LN_LINE;
}

getnum(c)
register c;
{
        register n;

        n = 0;
        while (isdigit(c)) {
                n = 10*n + c - '0';
                c = *ctp++;
        }
        --ctp;
        return (n);
}

struct line *
alocline(cp)
register char *cp;
{
        register struct line *lp;

        lp = (struct line *) malloc(sizeof(*lp));
        if (lp == NULL)
                diag("Out of memory");
	lp->l_text = (char *)malloc(strlen(cp)+1);
        return (lp);
}

diag(s)
char *s;
{
        register struct line *lp;
        register char *cp;

        printf("%s!\n", s);
        if ((lp=clp) != NULL) {
                putline(lp, stdout);
                printf("      ");
                cp = lp->l_text;
        } else {
                printf("*%s\n ", cbuf);
                cp = cbuf;
        }
        while (cp < ctp) {
                putchar(' ');
                ++cp;
        }
        printf("^\n");
        while (control != NULL)
                popdo();
        longjmp(env, 0);
}

getnb()
{
        register c;

        while ((c = *ctp++)==' ' || c=='\t')
                ;
        return (c);
}

void onintr()
{
        ++intflag;
}

erasesyms()
{
        register struct sym *sp1, *sp2;

        sp1 = sym;
        sym = NULL;
        while (sp1 != NULL) {
                sp2 = sp1->s_fp;
                free((char *) sp1);
                sp1 = sp2;
        }
}

SHAR_EOF
cat << 'SHAR_EOF' > focal.c.ORIG
/*
 * Focal, 1981.
 * Dedicated to the old times,
 * when an 8k PDP-8 was considered
 * a BIG machine.
 */
/*)BUILD
                $(DTOA) = 1
*/

#define unix
#ifdef  vms
#undef  unix
#endif
#ifdef  decus
#undef  unix
#endif
#include <stdio.h>
#ifndef decus
#include <ctype.h>
#include <signal.h>
#else
int     $$narg = 1;                     /* No argv prompt               */
#endif

#include <setjmp.h>

#ifdef  unix
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/dir.h>
#endif

#define NID     16                      /* # characters in id */

struct  line
{
        struct  line *l_fp;             /* Link */
        char    l_lno;                  /* Line */
        char    l_gno;                  /* Group */
        char    l_text[];               /* Text */
};

struct  lno
{
        char    ln_lno;                 /* Line */
        char    ln_gno;                 /* Group */
        int     ln_type;                /* Type */
};

#define LN_ALL  0                       /* All */
#define LN_GRP  1                       /* Group */
#define LN_LINE 2                       /* Line */
#define LN_NONE 3                       /* No number */

struct  control
{
        struct  control *c_fp;          /* Link */
        int     c_mode;                 /* Control mode */
        struct  line *c_lp;             /* Saved current line */
        char    *c_tp;                  /* Saved text pointer */
        struct  sym *c_sp;              /* Symbol (for) */
        double  c_limit;                /* Limit (for) */
        double  c_step;                 /* Step (for) */
};

#define C_TOP   0                       /* Top level */
#define C_DLINE 1                       /* Do line */
#define C_DGRP  2                       /* Do group */
#define C_DALL  3                       /* Do all */
#define C_FOR   4                       /* FOR loop */

struct  sym
{
        struct  sym *s_fp;              /* Link */
        int     s_type;                 /* Type of entry */
        int     s_subs;                 /* Subscript */
        union   {
                double  s_value;        /* The data */
                double  (*s_funp)();    /* Function pointer */
        } s_un;
        char    s_id[];                 /* Name */
};

#define S_SCAL  0
#define S_ARRAY 1
#define S_FUNC  2

char    cbuf[128];                      /* Command buffer */
char    abuf[128];                      /* Ask buffer */
char    *ctp;                           /* Current text pointer */
struct  line    *line;                  /* Line list header */
struct  line    *clp;                   /* Current line pointer */
struct  sym     *sym;                   /* Symbol table */
int     mode;                           /* Current processing mode */
struct  sym     *forsp;                 /* Symbol pointer (for) */
double  forlimit;                       /* Loop limit (for) */
double  forstep;                        /* Loop step (for) */
struct  control *control;               /* Control stack */
jmp_buf env;                            /* Saved state for errors */
int     intflag;                        /* Interrupt flag */

extern double  atof();
extern int     onintr();                       /* ^C catcher */
extern double  eval();
extern double  primary();
extern double  term();
extern struct  sym     *getsym();
extern struct  sym     *lookup();
extern struct  line    *alocline();

main()
{
        register c;

        setjmp(env);
#ifndef decus
        signal(SIGINT, &onintr);
#endif
        for (;;) {
                putchar('*');
                if (gets(cbuf) == NULL) {
                        putchar('\n');
                        break;
                }
                mode = C_TOP;
                clp  = NULL;
                ctp  = cbuf;
                if ((c=getnb()) != 0) {
                        if (isdigit(c))
                                inject(c);
                        else {
                                --ctp;
                                process();
                        }
                }
        }
}

process()
{
        double limit, step;
        double value;
        register c;
        register struct sym *sp;
        register struct line *lp;
        struct lno lno;
        struct line *lp1, *lp2, *lp3;
        int grp;

loop:
        if (intflag) {
                intflag = 0;
                diag("^C");
        }
        while ((c=getnb()) == ';')
                ;
        if (c == 0) {
                if (mode == C_FOR) {
                        forsp->s_un.s_value += forstep;
                        if (forstep>0.0 && forsp->s_un.s_value<=forlimit
                        ||  forstep<0.0 && forsp->s_un.s_value>=forlimit) {
                                clp = control->c_lp;
                                ctp = control->c_tp;
                                goto loop;
                        }
                        popfor();
                }
                if (clp != NULL) {
                        grp = clp->l_gno;
                        clp = clp->l_fp;
                        ctp = clp->l_text;
                }
                if (clp == NULL) {
                        if (mode == C_TOP)
                                return;
                        popdo();
                } else if (mode == C_DLINE
                || (mode==C_DGRP && grp!=clp->l_gno))
                        popdo();
                goto loop;
        }
        while (isalpha(*ctp))
                ++ctp;
        if (isupper(c))
                c = tolower(c);
        switch (c) {

        case 'a':
                do {
                        sp = getsym();
                        putchar(':');
                        if (gets(abuf) == NULL) {
                                putchar('\n');
                                diag("EOF in ask");
                        }
                        sp->s_un.s_value = atof(abuf);
                } while ((c=getnb()) == ',');
                --ctp;
                break;

        case 'c':
                while (*ctp != 0)
                        ++ctp;
                break;

        case 'd':
                getlno(&lno, -1);
                pushdo();
                if (lno.ln_type==LN_NONE || lno.ln_type==LN_ALL) {
                        if ((clp=line) == NULL)
                                diag("No program");
                        ctp = clp->l_text;
                        mode = C_DALL;
                        goto loop;
                }
                if (lno.ln_type == LN_GRP) {
                        lp = line;
                        while (lp!=NULL && lp->l_gno<lno.ln_gno)
                                lp = lp->l_fp;
                        if (lp!=NULL && lp->l_gno==lno.ln_gno) {
                                clp = lp;
                                ctp = clp->l_text;
                                mode = C_DGRP;
                                goto loop;
                        }
                        badline();
                }
                lp = line;
                while (lp != NULL
                && (lp->l_gno != lno.ln_gno
                ||  lp->l_lno != lno.ln_lno))
                        lp = lp->l_fp;
                if (lp != NULL) {
                        clp = lp;
                        ctp = clp->l_text;
                        mode = C_DLINE;
                        goto loop;
                }
                badline();

        case 'e':
                getlno(&lno, -1);
                if (lno.ln_type == LN_NONE) {
                        erasesyms();
                        break;
                }
                lp1 = NULL;
                lp2 = line;
                while (lp2 != NULL) {
                        if (lno.ln_type == LN_ALL
                        || (lp2->l_gno  == lno.ln_gno
                        && (lno.ln_type==LN_GRP || lp2->l_lno==lno.ln_lno))) {
                                if (lp2 == clp)
                                        diag("Erasing current line");
                                lp3 = lp2;
                                lp2 = lp2->l_fp;
                                if (lp1 == NULL)
                                        line = lp2; else
                                        lp1->l_fp = lp2;
                                free((char *) lp3);
                        } else {
                                lp1 = lp2;
                                lp2 = lp2->l_fp;
                        }
                }
                break;

        case 'f':
                sp = getsym();
                clearfors(sp);
                if (getnb() != '=')
                        diag("Missing = sign");
                sp->s_un.s_value = eval();
                if (getnb() != ',')
                        diag("Missing comma");
                limit = eval();
                if ((c=getnb()) == ';')
                        step = 1.0;
                else if (c == ',') {
                        step = eval();
                        if (getnb() != ';')
                                diag("Missing semi");
                } else
                        diag("Bad for");
                pushfor();
                forsp = sp;
                forlimit = limit;
                forstep = step;
                mode = C_FOR;
                break;

        case 'g':
                getlno(&lno, -1);
                if (lno.ln_type == LN_NONE) {
                        if ((clp=line) == NULL)
                                diag("No program");
                        ctp = clp->l_text;
                        goto loop;
                } else if (lno.ln_type == LN_LINE) {
                        lp = line;
                        while (lp != NULL
                        && (lp->l_gno != lno.ln_gno
                        ||  lp->l_lno != lno.ln_lno))
                                lp = lp->l_fp;
                        if (lp != NULL) {
                                clp = lp;
                                ctp = clp->l_text;
                                goto loop;
                        }
                }
                badline();

        case 'i':
                value = eval();
                if (value >= 0.0) {
                        while ((c = *ctp)!=0 && c!=',' && c!=';')
                                ++ctp;
                        if (c != ',')
                                goto loop;
                        ++ctp;
                        if (value != 0.0) {
                                while ((c = *ctp)!=0 && c!=',' && c!=';')
                                        ++ctp;
                                if (c != ',')
                                        goto loop;
                                ++ctp;
                        }
                }
                getlno(&lno, -1);
                if (lno.ln_type == LN_LINE) {
                        lp = line;
                        while (lp != NULL
                        && (lp->l_gno != lno.ln_gno
                        ||  lp->l_lno != lno.ln_lno))
                                lp = lp->l_fp;
                        if (lp != NULL) {
                                clp = lp;
                                ctp = clp->l_text;
                                goto loop;
                        }
                }
                badline();

        case 'l':
                library();
                break;

        case 'q':
                if (clp == NULL)
                        exit(0);
                return;

        case 't':
                type();
                break;

        case 'r':
                while (mode == C_FOR)
                        popfor();
                popdo();
                break;

        case 's':
                sp = getsym();
                if (getnb() != '=')
                        diag("Missing = sign");
                sp->s_un.s_value = eval();
                break;

        case 'w':
                getlno(&lno, -1);
                save(&lno, stdout);
                break;

        default:
                diag("Illegal command");
        }
        goto loop;
}

badline()
{
        diag("Bad line number");
}

pushdo()
{
        register struct control *cp;

        if ((cp=(struct control *)malloc(sizeof(struct control))) == NULL)
                diag("Out of space (control stack)");
        cp->c_fp = control;
        control  = cp;
        cp->c_mode = mode;
        cp->c_tp = ctp;
        cp->c_lp = clp;
}

pushfor()
{
        register struct control *cp;

        if ((cp=(struct control *)malloc(sizeof(struct control))) == NULL)
                diag("Out of space (control stack)");
        cp->c_fp = control;
        control  = cp;
        cp->c_mode = mode;
        cp->c_tp = ctp;
        cp->c_lp = clp;
        cp->c_sp = forsp;
        cp->c_limit = forlimit;
        cp->c_step = forstep;
}

popdo()
{
        register struct control *cp;

        if ((cp=control) == NULL)
                diag("Return not in do");
        control = cp->c_fp;
        ctp = cp->c_tp;
        clp = cp->c_lp;
        mode = cp->c_mode;
        free((char *) cp);
}

popfor()
{
        register struct control *cp;

        if ((cp=control) == NULL)
                diag("For stack botch");
        control = cp->c_fp;
        forsp = cp->c_sp;
        forlimit = cp->c_limit;
        forstep = cp->c_step;
        mode = cp->c_mode;
        free((char *) cp);
}

clearfors(sp)
register struct sym *sp;
{
        register struct control *cp1, *cp2;


        if (mode==C_FOR && forsp==sp)
                popfor();
        else {
                cp1 = NULL;
                cp2 = control;
                while (cp2 != NULL) {
                        if (cp2->c_mode==C_FOR && cp2->c_sp==sp) {
                                if (cp1 == NULL)
                                        control = cp2->c_fp; else
                                        cp1->c_fp = cp2->c_fp;
                                free((char *) cp2);
                                break;
                        }
                        cp1 = cp2;
                        cp2 = cp2->c_fp;
                }
        }
}

library()
{
        register char *p;
        register c, d;
        char *sctp;
        struct line *lp1, *lp2;
#ifdef  unix
        struct dir db;
        struct stat sb;
        int     fd;
#endif
        register FILE *fp;

        c = getnb();
        if (c!='c' && c!='s' && c!='l' && c!='d')
                diag("Bad library command");
        while (isalpha(*ctp))
                ++ctp;
        while ((d = *ctp)==' ' || d=='\t')
                ++ctp;
        if (c!='l' && d==0)
                diag("Missing file name");
        p = ctp;
        while (*ctp != 0)
                ++ctp;
        switch (c) {

        case 'c':
                if ((fp=fopen(p, "r")) == NULL)
                        diag("Cannot open");
                lp1 = line;
                while (lp1 != NULL) {
                        lp2 = lp1->l_fp;
                        free ((char *) lp1);
                        lp1 = lp2;
                }
                line = NULL;
                sctp = ctp;
                while (getline(abuf, fp) != 0) {
                        ctp = abuf;
                        if ((c=getnb()) != 0) {
                                if (isdigit(c) == 0)
                                        diag("Direct line in call");
                                inject(c);
                        }
                }
                fclose(fp);
                ctp = sctp;
                break;

#ifdef  unix
        case 'd':
                if (unlink(p) < 0)
                        diag("Cannot delete");
                break;

        case 'l':
                if (d == 0)
                        p = ".";
                if (stat(p, &sb) < 0
                || (sb.st_mode&S_IFMT) != S_IFDIR
                || (fd = open(p, 0)) < 0)
                        diag("Bad directory");
                while (read(fd, &db, sizeof(db)) == sizeof(db)) {
                        if (db.d_ino == 0
                        ||  strncmp(db.d_name, ".",  DIRSIZ) == 0
                        ||  strncmp(db.d_name, "..", DIRSIZ) == 0)
                                continue;
                        printf("%.*s\n", DIRSIZ, db.d_name);
                }
                close(fd);
                break;
#endif
        case 's':
                if ((fp=fopen(p, "w")) == NULL)
                        diag("Cannot create");
                save(NULL, fp);
                fclose(fp);
                break;
        }
}

inject(c)
register c;
{
        register struct line *lp1, *lp2, *lp3;
        register struct lno  lno;

        getlno(&lno, c);
        if (lno.ln_type != LN_LINE)
                diag("Illegal line number");
        lp1 = NULL;
        lp2 = line;
        while (lp2 != NULL
        && (lp2->l_gno < lno.ln_gno
        || (lp2->l_gno==lno.ln_gno&&lp2->l_lno<=lno.ln_lno))) {
                if (lp2->l_gno == lno.ln_gno
                &&  lp2->l_lno == lno.ln_lno) {
                        lp3 = lp2;
                        lp2 = lp2->l_fp;
                        if (lp1 == NULL)
                                line = lp2; else
                                lp1->l_fp = lp2;
                        free((char *) lp3);
                        break;
                }
                lp1 = lp2;
                lp2 = lp2->l_fp;
        }
        if ((c=getnb()) != 0) {
                lp3 = alocline(--ctp);
                lp3->l_fp  = lp2;
                lp3->l_gno = lno.ln_gno;
                lp3->l_lno = lno.ln_lno;
                strcpy(lp3->l_text, ctp);
                if (lp1 == NULL)
                        line = lp3; else
                        lp1->l_fp = lp3;
        }
}

getline(cp, fp)
register char *cp;
register FILE *fp;
{
        register c;

        while ((c=getc(fp))!=EOF && c!='\n')
                *cp++ = c;
        if (c == EOF)
                return (0);
        *cp = 0;
        return (1);
}

type()
{
        register char *fmt;
        register c;
        char fmtb[20];
        int x, y;

        fmt = "%6e";
        while ((c=getnb())!=0 && c!=';') {
                if (c == '%') {
                        if ((c=getnb())==0 || c==';' || c==',') {
                                fmt = "%6e";
                                --ctp;
                                continue;
                        }
                        x = getnum(c);
                        if (getnb() != '.')
                                diag("Missing . in format");
                        y = getnum(getnb());
                        sprintf(fmtb, "%%%d.%df", x, y);
                        fmt = fmtb;
                        continue;
                }
                if (c == ',')
                        continue;
                if (c == '!') {
                        putchar('\n');
                        continue;
                }
                if (c == '#') {
                        putchar('\r');
                        continue;
                }
                if (c == '"') {
                        while ((c = *ctp++)!='\0' && c!='"')
                                putchar(c);
                        if (c == '\0') {
                                diag("Missing string quote");
                                break;
                        }
                        continue;
                }
                --ctp;
                printf(fmt, eval());
        }
        --ctp;
}

save(lnop, fp)
register struct lno *lnop;
FILE *fp;
{
        struct lno lno;
        register struct line *lp;
        register tgroup, lgroup;

        if (lnop == NULL) {
                lno.ln_type = LN_ALL;
                lnop = &lno;
        }
        lp = line;
        if (lnop->ln_type!=LN_NONE && lnop->ln_type!=LN_ALL) {
                while (lp!=NULL && lp->l_gno<lnop->ln_gno)
                        lp = lp->l_fp;
                if (lp==NULL || lp->l_gno!=lnop->ln_gno)
                        diag("Line not found");
                if (lnop->ln_type == LN_LINE) {
                        while (lp!=NULL && lp->l_lno!=lnop->ln_lno)
                                lp = lp->l_fp;
                        if (lp == NULL)
                                diag("Line not found");
                }
        }
        while (lp != NULL) {
                putline(lp, fp);
                if (lnop->ln_type == LN_LINE)
                        break;
                lgroup = lp->l_gno;
                if ((lp = lp->l_fp) != NULL) {
                        tgroup = lp->l_gno;
                        if (lnop->ln_type==LN_GRP && tgroup!=lnop->ln_gno)
                                break;
                        if (tgroup != lgroup)
                                putc('\n', fp);
                }
        }
}

double
eval()
{
        double val, rop;
        register c;

        if ((c=getnb())=='+' || c=='-') {
                val = primary();
                if (c == '-')
                        val = -val;
        } else {
                --ctp;
                val = primary();
        }
        while ((c=getnb())=='+' || c=='-') {
                rop = primary();
                if (c == '+')
                        val = val + rop;
                else
                        val = val - rop;
        }
        --ctp;
        return (val);
}

double
primary()
{
        double val, rop;
        register c;

        val = term();
        while ((c = getnb())=='*' || c=='/') {
                rop = term();
                if (c == '*')
                        val = val * rop;
                else
                        val = val / rop;
        }
        --ctp;
        return (val);
}

double
term()
{
        register c;
        register char *cp;
        double val;
        int fsign, fdot, fexp;
        int term_type, subs;
        struct sym *sp;
        char id[NID];
        char nbuf[20];

        if ((c = getnb())=='(' || c=='[' || c=='<') {
                val = eval();
                if (++c != ')')
                        ++c;
                if (c != getnb())
                        diag("Mismatched enclosures");
                return (val);
        }
        if (c=='.' || isdigit(c)) {
                fsign = 1;
                fexp = 0;
                fdot = 0;
                if (c == '.')
                        ++fdot;
                cp = &nbuf[0];
                for (;;) {
                        if (cp >= &nbuf[19])
                                diag("Number too long");
                        *cp++ = c;
                        if ((c = *ctp++) == '.') {
                                if (fdot++)
                                        break;
                        } else if (c == 'e') {
                                if (fexp++)
                                        break;
                                fsign = 0;
                                fdot = 1;
                        } else if (c=='+' || c=='-') {
                                if (fsign++)
                                        break;
                        } else if (!isdigit(c))
                                break;
                }
                --ctp;
                *cp = '\0';
                return (atof(nbuf));
        }
        if (isalpha(c)) {
                cp = &id[0];
                do {
                        if (cp < &id[NID-1])
                                *cp++ = c;
                        c = *ctp++;
                } while (isalnum(c));
                *cp = 0;
                if (id[0] == 'f') {
                        /* ... */
                }
                term_type = S_SCAL;
                while (c==' ' || c=='\t')
                        c = *ctp++;
                if (c == '(') {
                        term_type = S_ARRAY;
                        subs = (int) eval();
                        if (getnb() != ')')
                                diag("Missing ) in subscript");
                } else
                        --ctp;
                if ((sp=lookup(id, term_type, subs)) == NULL)
                        diag("Undefined variable");
                return (sp->s_un.s_value);
        }
        diag("Expression syntax");
}

struct  sym *
lookup(id, lookup_type, subs)
char *id;
register lookup_type;
{
        register struct sym *sp;

        sp = sym;
        while (sp != NULL) {
                if (sp->s_type == lookup_type
                && (lookup_type!=S_ARRAY || sp->s_subs==subs)
                &&  strcmp(id, sp->s_id) == 0)
                        break;
                sp = sp->s_fp;
        }
        return (sp);
}

struct sym *
getsym()
{
        register c;
        char id[NID];
        register char *cp;
        register struct sym *sp;
        int subs, getsym_type;

        if (isalpha(c = getnb()) == 0)
                diag("Missing variable");
        cp = &id[0];
        do {
                if (cp < &id[NID-1])
                        *cp++ = c;
                c = *ctp++;
        } while (isalnum(c));
        *cp = 0;
        getsym_type = S_SCAL;
        while (c==' ' || c=='\t')
                c = *ctp++;
        if (c == '(') {
                getsym_type = S_ARRAY;
                subs = (int) eval();
                if (getnb() != ')')
                        diag("Bad subscript");
        } else
                --ctp;
        if ((sp=lookup(id, getsym_type, subs)) == NULL) {
                sp = (struct sym *)malloc(sizeof(*sp)+strlen(id)+1);
                if (sp == NULL)
                        diag("Out of space (symbols)");
                sp->s_fp = sym;
                sym = sp;
                sp->s_type = getsym_type;
                sp->s_subs = subs;
                strcpy(sp->s_id, id);
        }
        return (sp);
}

putline(lp, fp)
register struct line *lp;
FILE *fp;
{
        fprintf(fp, "%02d.%02d %s\n", lp->l_gno, lp->l_lno, lp->l_text);
}

static char badlno[] = "Bad line or group number";

getlno(lnop, c)
register struct lno *lnop;
register c;
{
        register gn, ln;

        if (c < 0)
                c = getnb();
        if (c=='\0' || c==';') {
                --ctp;
                lnop->ln_type = LN_NONE;
                return;
        }
        if (c=='A' || c=='a') {
                while (isalpha(*ctp))
                        ++ctp;
                lnop->ln_type = LN_ALL;
                return;
        }
        if (!isdigit(c))
                diag(badlno);
        if ((gn = getnum(c))<1 || gn>99)
                diag(badlno);
        if (*ctp != '.') {
                lnop->ln_gno = gn;
                lnop->ln_lno = 0;
                lnop->ln_type = LN_GRP;
                return;
        }
        ++ctp;
        if ((ln=getnum(*ctp++)) == 0) {
                lnop->ln_gno = gn;
                lnop->ln_lno = 0;
                lnop->ln_type = LN_GRP;
                return;
        }
        if (ln<1 | ln>99)
                diag(badlno);
        lnop->ln_gno = gn;
        lnop->ln_lno = ln;
        lnop->ln_type = LN_LINE;
}

getnum(c)
register c;
{
        register n;

        n = 0;
        while (isdigit(c)) {
                n = 10*n + c - '0';
                c = *ctp++;
        }
        --ctp;
        return (n);
}

struct line *
alocline(cp)
register char *cp;
{
        register struct line *lp;

        lp = (struct line *) malloc(sizeof(*lp)+strlen(cp)+1);
        if (lp == NULL)
                diag("Out of memory");
        return (lp);
}

diag(s)
char *s;
{
        register struct line *lp;
        register char *cp;

        printf("%s!\n", s);
        if ((lp=clp) != NULL) {
                putline(lp, stdout);
                printf("      ");
                cp = lp->l_text;
        } else {
                printf("*%s\n ", cbuf);
                cp = cbuf;
        }
        while (cp < ctp) {
                putchar(' ');
                ++cp;
        }
        printf("^\n");
        while (control != NULL)
                popdo();
        longjmp(env, 0);
}

getnb()
{
        register c;

        while ((c = *ctp++)==' ' || c=='\t')
                ;
        return (c);
}

onintr()
{
        ++intflag;
}

erasesyms()
{
        register struct sym *sp1, *sp2;

        sp1 = sym;
        sym = NULL;
        while (sp1 != NULL) {
                sp2 = sp1->s_fp;
                free((char *) sp1);
                sp1 = sp2;
        }
}

SHAR_EOF
:	End of shell archive
exit 0


From cgordon@vpnet.chi.il.us Thu Oct 28 02:20:53 EDT 1993
Article: 428 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!math.ohio-state.edu!pacific.mps.ohio-state.edu!linac!Firewall!uunet!amiserv!vpnet!cgordon
From: cgordon@vpnet.chi.il.us (gordon hlavenka)
Subject: Re: FOCAL - what about a tutorial?
Message-ID: <1993Oct23.061131.15537@vpnet.chi.il.us>
Organization: Vpnet - Public Access Unix and Usenet
References: <1993Oct19.161828.5467@nomina.lu.se> <2a1m9o$b4j@senator-bedfellow.mit.edu>
Date: Sat, 23 Oct 1993 06:11:31 GMT
Lines: 79


(NOTE:  I worked with FOCAL 1969 and FOCAL-8.  It's been 15 years or
so, and so these two versions may be somewhat mishmoshed in my
brain...)

Crystobal J. Junta <grisha@athena.mit.edu> wrote:
>Variables: The version I remember did not support
>string variables, just real and integers.
True mostly.  However, FOCAL treats text input as numbers, with the
digits continuing upward as for HEX.  In other words, 'A' has a value
of ten, 'B' is eleven, and so on.  The system is still base ten, so an
'A' in the tens place means ten tens, or one hundred.  The one
exception ti this is the letter 'E', which is used for exponentiation
in scientific notation.  So the word 'YES' has a numeric value of
3500 * 10^29, while the word 'NO' is worth 255.  These can be used in
IF statements by preceding the word with a zero to force the parser to
evaluate it as a number.  You have to be careful not to overflow,
especially since E is the most commonly-used letter in English...

>A : Ask.  Waits for input from keyboard.  Format: A ["optional
>prompt",]var[var,var......] (equivalent to BASIC's INPUT).  See also S, T.
I don't recall ever using prompts with ASK.  Perhaps this was
supported in later versions.

>D : Do.  Calls a subroutine, which are more like BASIC kind of subroutines than
>real procedures of structured languages.  Format: D line-number|line-group.
>This requires some explanation.  When you call D with a line number, it will go
>to that line number and start executing commands from there until it encounters
>R (or until the program ends).  Now, line-group concept is cute, IMO.  Line
>group is a number which an integer.  Thus 2, 3 are line groups.  Group 2
>consists of all line numbers from 2.01 to 2.99, e.g., 2.1, 2.02, 2.33.
>D called with a group number as an argument, will go to the first line in the
>group and will execute lines in the group until it encounters R OR until the
>group ends.  Then it returns control to the command after D.  (sort of
>equivalent to BASIC's GOSUB). 
I seem to recall that 'D 2.11' would return after line 2.11 _without_
requiring an 'R', while 'D 2' would execute starting at 2.00 and
continuing until encountering an 'R' _or_ line 2.99.

>E : Erase.  This is an interpreter command telling it to erase lines.
'E' by itself re-initializes all variables to zero.  'E 1.01' erases
line 1.01.  'E A' erases the whole program.  I seem to recall that
'E A' did _not_ initialize variables, but I could be wrong on this.
Also, I think 'E 2' would erase 2.00 to 2.99.

>F : For.  The looping construct for for loops.
The tough part about this one is that there is no 'NEXT' equivalent --
FOR in FOCAL will only execute the commands you can fit on an
80-character line.  This leads to heavy use of subroutines, viz
2.12 F X=1,100,5;T X,!;D 3
2.13 C (STUFF TO DO AFTER THE FOR LOOP)
3.00 C (STUFF TO DO IN THE FOR LOOP...)

>L : Library.  It actually includes a set of commands, as follows:  
Since all we had were two ASR-33s, the only use we got from 'L' was
that it suppressed the TTY echo while loading (paper) tapes.  I don't
remember how we got the echo back...  CTRL/C maybe?  Or perhaps I'm
thinking of the 'TAPE' command in EDUSYSTEM-20 BASIC.

FOCAL would only look at the first letter of the command, so the
command 'QWERTY' would end your program, and look cuter in the
listing.  Also, we used to use 'RUN AWAY' a lot to restart programs.

10.00 C END GAME ROUTINE
10.01 T "YOUR SCORE IS",S,".",!!,"PLAY AGAIN? ";A A
10.02 I (A-0YES)10.03,10.2,10.03
10.03 I (A-0NO)10.04,10.3,10.04
10.04 T "PLEASE ANSWER YES OR NO.",!;G 10.01
10.20 C PLAY IT AGAIN
10.21 RUN AWAY!
10.30 C ALL DONE
10.31 QWERTY



-- 
----------------------------------------------------
Gordon S. Hlavenka           cgordon@vpnet.chi.il.us
Proud father of Daniel Scott     born August 9, 1993


From jhhl@panix.com Thu Oct 28 02:22:02 EDT 1993
Article: 429 of alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!howland.reston.ans.net!spool.mu.edu!nigel.msen.com!yale.edu!cmcl2!panix!not-for-mail
From: jhhl@panix.com (Henry Lowengard)
Newsgroups: alt.sys.pdp8
Subject: FOCAL and MUCAL
Date: 23 Oct 1993 11:36:07 -0400
Organization: PANIX Public Access Internet and Unix, NYC
Lines: 28
Message-ID: <2abj17$pmu@panix.com>
NNTP-Posting-Host: panix.com
Summary: FOCAL and me
Keywords: languages

Because FOCAL was available as source through DECUS, we
obtained a copy at my high school (Loomis Chaffee in 
Windsor, CT) around '72 or so. We has a PDP/8e with
2 fields of memory... 
 Some time previously, a few of us students had discovered
the phenomenon later known as 'the kludge harp' where
noise picked up over a radio could be pitched and used
as a sine wave oscillator. 
The trick was to run freely through core and then jump
somewhere. As a matter of fact, it made for the shortest
(or longest) possible 'useful' PDP8 program: fill all
of core (ah - at last I can refer correctly to core as core)
with 0's (AKA AND instructions) and way up at 7777 put
   JMP I Z 10
Stick a radio near the machine and this makes a siren noise!
  but back to FOCAL.... I hacked in an instruction which 
would let you set up the second field as a giant kludge harp
running oscillator , so with the added programmable underwear
of FOCAL, I could do some crude algorithmic music compositions!
This new version of FOCAL I dubbed MUCAL. Sorry - I have no tapes
(paper or magnetic) . These same principals were useful when
programming a 8008 home-grown machine (with 1 1/4 K) for similar
purposes!
      jhhl
-- 
+---------------------------------------------------------------------------+
| jhhl   @panix.com    Henry Lowengard     43 W16 #2D NYC 10011-6320 USA    |
+---------------------------------------------------------------------------+


From cpu@chac.win.net Thu Oct 28 02:22:10 EDT 1993
Article: 430 of alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!spool.mu.edu!caen!malgudi.oar.net!witch!chac!cpu
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Message-ID: <221@chac.win.net>
References: <29uc0c$9bd@senator-bedfellow.MIT.EDU> <1993Oct18.165004.24802@news.uiowa.edu><1993Oct22.015933.17438@vpnet.chi.il.us>
Reply-To: cpu@chac.win.net (Kip Crosby)
From: cpu@chac.win.net (Kip Crosby)
Date: Sat, 23 Oct 1993 15:39:48 GMT
Subject: Re: FOCAL
Lines: 10
Xref: samba.oit.unc.edu alt.folklore.computers:49243 alt.sys.pdp8:430

 
In article <1993Oct22.015933.17438@vpnet.chi.il.us>, gordon hlavenka (cgordon@vpnet.chi.il.us) writes:
>grisha@athena.mit.edu (Crystobal J. Junta):
>>
>>For old times' sake, would people like a comp.lang.focal newsgroup?
>
>01.00 C RESPONSE POSTING
>01.01 T "Hooray!!!",!

  Is this an RFD?         :-)

__________________________________________
Kip Crosby                cpu@chac.win.net   
Computer History Association of California 
     "History is what you make it...." 


From jamesh@netcom.com Thu Oct 28 02:23:11 EDT 1993
Article: 431 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!umn.edu!csus.edu!netcom.com!jamesh
From: jamesh@netcom.com (James Hightower)
Subject: Re: FOCAL - some more questions
Message-ID: <jameshCFDHLz.773@netcom.com>
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
References: <1993Oct19.161828.5467@nomina.lu.se> <2a1m9o$b4j@senator-bedfellow.mit.edu> <1993Oct20.151252.17762@nomina.lu.se>
Date: Sat, 23 Oct 1993 23:08:22 GMT
Lines: 32
Xref: samba.oit.unc.edu alt.folklore.computers:49245 alt.sys.pdp8:431

magnus@thep.lu.se (Magnus Olsson) writes:


>Once I get the answer to these questions, I'll start hacking the
>interpreter. If no legal hurdles turn up, I'll make the code

Speaking of legal, I think it's high time to finger someone as the
author of this fine thing what I posted to alt.sources...

Lenny Gray <lenngray@netcom.com>(famed author of DEC's EduSystem/10 BASIC
and RT/11 BASIC,) wrote that the author was Rick Merrill, once of DEC. 

Ozan S. Yigitl <oz@sis.yorku.ca>(famed author of much hip stuff) wrote
that the author is David Conroy, famous for his public domain PDP-11
DECUS C compiler.

This morning I dug through the pile of RK05 packs from whence this came,
(a job which required re-assembling my trusty ol' PDP-11/03) and found
the FOCAL source living on a disk that did indeed appear to contain some
part of a DECUS C distribution, so perhaps DC did have something to
do with it. Or perhaps he got it from RM. Either way, they both
deserve a hand! (clap clap)

This is almost as much fun as the Three Stooges marathon on TBN.

JJH
-------------------------------------------------------------------------------
Oh Yeah: Disclaimer, Disclaimer, Disclaimer, The views expressed belong
only to me (and maybe Courtny). It should not reflect on any others
(except Mario from Canada, a real perv).


From person@plains.NoDak.edu Thu Oct 28 02:30:17 EDT 1993
Article: 432 of alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!usc!cs.utexas.edu!convex!constellation!aardvark.ucs.uoknor.edu!ns1.nodak.edu!plains.NoDak.edu!person
Newsgroups: alt.sys.pdp8
Subject: Re: FOCAL - what about a tutorial?
Message-ID: <CF7qH7.oHF@ns1.nodak.edu>
From: person@plains.NoDak.edu (Brett Person)
Date: Wed, 20 Oct 1993 20:34:18 GMT
Sender: usenet@ns1.nodak.edu (Usenet login)
References: <1993Oct19.161828.5467@nomina.lu.se> <2a1m9o$b4j@senator-bedfellow.MIT.EDU>
Organization: North Dakota Higher Education Computing Network
Nntp-Posting-Host: plains.nodak.edu
Lines: 9

Was anyone able to get this to compile out-of-the-box?  I've tried on two
machines now, with lots o' compiler errors.  I've tried both Sun  and Linux. 

Seems to have a problem with DIRSIZ and a couple of structs not being
properly declared. 
-- 
Brett Person
North Dakota State University
person@plains.nodak.edu || person@plains.bitnet


From frisbie@flying-disk.com Thu Oct 28 02:30:57 EDT 1993
Article: 433 of alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!flying!frisbie
From: frisbie@flying-disk.com
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Subject: Re: FOCAL - some more questions
Message-ID: <1993Oct25.073059.121@flying-disk.com>
Date: 25 Oct 93 07:30:59 PDT
References: <1993Oct19.161828.5467@nomina.lu.se> <2a1m9o$b4j@senator-bedfellow.mit.edu> <1993Oct20.151252.17762@nomina.lu.se> <jameshCFDHLz.773@netcom.com>
Organization: Flying Disk Systems, Inc.
Lines: 21
Xref: samba.oit.unc.edu alt.folklore.computers:49307 alt.sys.pdp8:433

In article <jameshCFDHLz.773@netcom.com>, 
jamesh@netcom.com (James Hightower) writes:

> This morning I dug through the pile of RK05 packs from whence this came,
> (a job which required re-assembling my trusty ol' PDP-11/03) and found
> the FOCAL source 

I'm glad to see that someone other than me still has an operating
RKV11-D controller.   I used mine on my PDP-11/03 for many years
before moving it to my 11/73.   This required "hot-wiring" the
extra two DMA address bits that DEC neglected to include.  I
still use it several times a month.

Several years ago, a certain well-known RT-11 developer was
visiting me.   Said developer declared that DEC had never made
such a product, even after seeing it.

--  Alan E. Frisbie               Frisbie@Flying-Disk.Com
--  Flying Disk Systems, Inc.
--  4759 Round Top Drive          (213) 256-2575 (voice)
--  Los Angeles, CA 90065         (213) 258-3585 (FAX)


From ivie@cc.usu.edu Thu Oct 28 02:31:10 EDT 1993
Article: 434 of alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu
Newsgroups: alt.sys.pdp8
Subject: Re: FOCAL - what about a tutorial?
Message-ID: <1993Oct25.093932.2545@cc.usu.edu>
Date: 25 Oct 93 09:39:32 MDT
References: <1993Oct19.161828.5467@nomina.lu.se> <2a1m9o$b4j@senator-bedfellow.MIT.EDU> <CF7qH7.oHF@ns1.nodak.edu>
Organization: Utah State University
Lines: 14

In article <CF7qH7.oHF@ns1.nodak.edu>, person@plains.NoDak.edu (Brett Person) writes:
> Was anyone able to get this to compile out-of-the-box?  I've tried on two
> machines now, with lots o' compiler errors.  I've tried both Sun  and Linux. 
> 
> Seems to have a problem with DIRSIZ and a couple of structs not being
> properly declared. 

Compiled out of the box under Alpha/VMS. Given the tweaks I had to make to
get it to compile under Ultrix (I posted them a few days ago), I'm not sure
that I know why it compiled....
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
ivie@cc.usu.edu |     'obsolete-ready'


From frank@rover.uchicago.edu Thu Oct 28 02:31:27 EDT 1993
Article: 435 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!math.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!rover.uchicago.edu!frank
From: frank@rover.uchicago.edu (Frank - Hardware Hacker - Borger)
Subject: Re: FOCAL and MUCAL
Message-ID: <23OCT199313012698@rover.uchicago.edu>
Summary: FOCAL and me
News-Software: VAX/VMS VNEWS 1.41    
Keywords: languages
Sender: news@uchinews.uchicago.edu (News System)
Reply-To: frank@rover.uchicago.edu
Organization: Joint Center for Radiation Therapy
References: <2abj17$pmu@panix.com>
Date: Sat, 23 Oct 1993 19:01:00 GMT
Lines: 24

In article <2abj17$pmu@panix.com>, jhhl@panix.com (Henry Lowengard) writes...
>the phenomenon later known as 'the kludge harp' where
>noise picked up over a radio could be pitched and used
>as a sine wave oscillator. 
>The trick was to run freely through core and then jump
>somewhere. As a matter of fact, it made for the shortest
>(or longest) possible 'useful' PDP8 program: fill all
>of core (ah - at last I can refer correctly to core as core)
>with 0's (AKA AND instructions) and way up at 7777 put
>   JMP I Z 10
>Stick a radio near the machine and this makes a siren noise!

	There was a DECUS program we obtained which let you play music,
	(up to 4 part harmony,) by twanging on core and sticking a radio near
	the CPU. (A later improvement was to hang an amp and a speaker on
	one output line.)

	The program came with several examples, including "The Entertainer"

Frank R. Borger - Physicist     ___      It's 9:00 am. Do you know where your
Michael Reese - U of Chicago   |___      children are? Well, it depends on
Center for Radiation Therapy   | |_) _   whether or not the Judge opened
net: Frank@rover.uchicago.edu    | \|_)  the schools today.
ph: 312-791-8075 fa: 791-2517       |_)  


From lasner@sunSITE.unc.edu Thu Oct 28 02:31:39 EDT 1993
Article: 436 of alt.sys.pdp8
Path: samba.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Subject: Re: FOCAL - some more questions
Date: 28 Oct 1993 06:30:28 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 23
Message-ID: <2anou4$p76@samba.oit.unc.edu>
References: <1993Oct19.161828.5467@nomina.lu.se> <2a1m9o$b4j@senator-bedfellow.mit.edu> <1993Oct20.151252.17762@nomina.lu.se> <jameshCFDHLz.773@netcom.com>
NNTP-Posting-Host: calypso.oit.unc.edu
Xref: samba.oit.unc.edu alt.folklore.computers:49384 alt.sys.pdp8:436

In article <jameshCFDHLz.773@netcom.com>,
James Hightower <jamesh@netcom.com> wrote:
>
>Lenny Gray <lenngray@netcom.com>(famed author of DEC's EduSystem/10 BASIC
>and RT/11 BASIC,) wrote that the author was Rick Merrill, once of DEC. 

Rick Focal was indeed the author of FOCAL.  (Well, some people called Merrill
that!)

However, EDU-10 is the product of Lenny Elekman.  8K-BASIC and LAB-8/e BASIC
are based on it, and are enhanced by Jack Burness.  (They are actually both
the same program with conditionals for the LAB-8/e added functions, etc.)
There is also a CAPS-8 variant of it as well.

cjl

ps: While I don't have the time right now to discuss it in detail, there
seems to be a lot of the "deaf leading the dumb leading the blind" discussion
about FOCAL going on here, and a lot of it is just plain wrong.  FOCAL-8 is
more a marketing ploy than a different program from FOCAL, 1969.  And people
are misremembering features, etc.  A lot of it stems from either confusing
FOCAL with other languages, or remembering non-standard implementations or
worse.  Perhaps we need a definitive spec for just what FOCAL actually is.


From jones@cs.uiowa.edu Sat Oct 30 09:19:41 EDT 1993
Article: 437 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!paladin.american.edu!howland.reston.ans.net!news.moneng.mei.com!uwm.edu!linac!Firewall!uunet!news.uiowa.edu!news
From: jones@cs.uiowa.edu
Subject: Playing Music (Was: MUCAL)
Sender: news@news.uiowa.edu (News)
Message-ID: <1993Oct26.142913.4309@news.uiowa.edu>
Date: Tue, 26 Oct 1993 14:29:13 GMT
References: <2ahp6l$e4d@panix.com>
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: University of Iowa, Iowa City, IA, USA
Lines: 10

>From article <2ahp6l$e4d@panix.com>, by jhhl@panix.com (Henry Lowengard):

>   The best we high school students came up with was 2 part, but we made
> an 'autobooting' tape which played Bach's prelude #2 ....

If anyone has any of these old paper tapes, I'd dearly love to try to
run them!  Please, hunt them up if you have them!

					Doug Jones
					jones@cs.uiowa.edu


From jones@cs.uiowa.edu Sat Oct 30 09:22:47 EDT 1993
Article: 438 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!paladin.american.edu!howland.reston.ans.net!news.moneng.mei.com!uwm.edu!linac!Firewall!uunet!news.uiowa.edu!news
From: jones@cs.uiowa.edu
Subject: RIM (was: MUCAL)
Sender: news@news.uiowa.edu (News)
Message-ID: <1993Oct26.143118.4420@news.uiowa.edu>
Date: Tue, 26 Oct 1993 14:31:18 GMT
References: <2ahp6l$e4d@panix.com>
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: University of Iowa, Iowa City, IA, USA
Lines: 46

>From article <2ahp6l$e4d@panix.com>, by jhhl@panix.com (Henry Lowengard):
>>	one output line.)
> 
>   Now, I used to be able to do the RIM loader sight unseen in a few seconds,,
> but I'm surprised it hasn't shown up in signatures here.
> (that's a subtle request for an addition to the FAQ)


   1            /	RIM LOADERS FOR PAPER TAPE INPUT
   2            
   3            /UNCOMMENT FOLLOWING FOR TTY INPUT
   4            /KSFIOT= KSF
   5            /KRBIOT= KRB
   6            /KCCIOT= KCC
   7            /KRSIOT= KRS
   8            /HSR=    0
   9            
  10            /UNCOMMENT FOLLOWING FOR HIGH SPEED READER INPUT
  11            KSFIOT= RSF
  12            KRBIOT= RRB RFC
  13            KCCIOT= RFC
  14            KRSIOT= RRB RFC
  15            HSR=    1
  16            
  17            / FIXUP TO CHANGE BRANCH TARGET FROM TTYC TO HSRC
  18            HSRF=	HSRC-TTYC^HSR
  19            
  20            *7756
  21 07756 6014 BEG,	KCCIOT		/ INITIALIZE READER
  22 07757 6011 TTYC,	KSFIOT		/ AWAIT INPUT
  23 07760 5357 	JMP	TTYC
  24 07761 6016 	KRBIOT		/ GET A CHARACTER
  25 07762 7106 	CLL RTL
  26 07763 7006 	RTL
  27 07764 7510 	SPA		/ SKIP IF HIGH BIT OF 8 BIT CHAR RESET
  28 07765 5374 	JMP	TTYC+HSRF	/ ELSE LOOP (SKIPPING LEADER)
  29 07766 7006 	RTL		/ 6 BIT CHAR IN AC[0-5], LINK=BIT 7
  30 07767 6011 	KSFIOT		/ AWAIT INPUT
  31 07770 5367 	JMP	.-1	
  32 07771 6016 	KRSIOT		/ OR 6 BIT CHAR INTO AC[6-12]
  33 07772 7420 	SNL		/ SKIP NEXT IF BIT 7 OF CHAR 1 WAS SET
  34 07773 3776 	DCA I	TEMP	/ STORE DATA
  35 07774 3376 HSRC,	DCA	TEMP	/ SET ADDRESS OF NEXT DATA WORD
  36 07775 5357 	JMP	BEG+HSR	/ GO GET NEXT DATA WORD
  37 07776 0000 TEMP,	.-.		/ ADDRESS OF NEXT DATA WORD
  38            $


From jhhl@panix.com Sat Oct 30 09:24:26 EDT 1993
Article: 439 of alt.sys.pdp8
Path: samba.oit.unc.edu!concert!xanth.cs.odu.edu!lll-winken.llnl.gov!sundance.llnl.gov!fastrac.llnl.gov!usenet.ee.pdx.edu!news.reed.edu!batcomputer!caen!math.ohio-state.edu!howland.reston.ans.net!europa.eng.gtefsd.com!news.ans.net!cmcl2!panix!not-for-mail
From: jhhl@panix.com (Henry Lowengard)
Newsgroups: alt.sys.pdp8
Subject: Re: FOCAL and MUCAL
Date: 25 Oct 1993 19:58:13 -0400
Organization: PANIX Public Access Internet and Unix, NYC
Lines: 45
Message-ID: <2ahp6l$e4d@panix.com>
References: <2abj17$pmu@panix.com> <23OCT199313012698@rover.uchicago.edu>
NNTP-Posting-Host: panix.com
Keywords: languages

In <23OCT199313012698@rover.uchicago.edu> frank@rover.uchicago.edu (Frank - Hardware Hacker - Borger) writes:

>In article <2abj17$pmu@panix.com>, jhhl@panix.com (Henry Lowengard) writes...
>>the phenomenon later known as 'the kludge harp' where
>>noise picked up over a radio could be pitched and used
>>as a sine wave oscillator. 
>>The trick was to run freely through core and then jump
>>somewhere. As a matter of fact, it made for the shortest
>>(or longest) possible 'useful' PDP8 program: fill all
>>of core (ah - at last I can refer correctly to core as core)
>>with 0's (AKA AND instructions) and way up at 7777 put
>>   JMP I Z 10
>>Stick a radio near the machine and this makes a siren noise!

>	There was a DECUS program we obtained which let you play music,
>	(up to 4 part harmony,) by twanging on core and sticking a radio near
>	the CPU. (A later improvement was to hang an amp and a speaker on
>	one output line.)

>	The program came with several examples, including "The Entertainer"
  The best we high school students came up with was 2 part , but we made
an 'autobooting' tape which played Bach's prelude #2 (I think) from Preludes
 and fugues. The technique was worked out by friends of mine who wouldn't
tell me how they did it. (I figured it out eventually). 
A particularly beautiful piece could be played by aiming the data pointer
at the RIM loader code. 
  Now, I used to be able to do the RIM loader sight unseen in a few seconds,,
but I'm surprised it hasn't shown up in signatures here.
(that's a subtle request for an addition to the FAQ)
Somewhere around here I have the tape with my diasassembly package on it..
it did an analysis of how the locations were used and assigned mnemonics
based on that usage! (i.e. if a location was only ANDed, it would be called
MASK01 or something like that). 
  Not only did I have the PDP/8 in highschool, but at college (Trinity College
 Hartford CT) they had a venerable PDP/8 running TSS8 which was by legend
the oldest running PDP8 at the time (74-75), it having a serial number
in the low 30's. We found a mate for it to replace old failing core, 
but eventually replaced it with a PDP 11/45, and now, I suppose, a VAX of
some sort. 
The last  working PDP8 I ever saw was in '79 at the Rockefeller Institute
     jhhl
-- 
+---------------------------------------------------------------------------+
| jhhl   @panix.com    Henry Lowengard     43 W16 #2D NYC 10011-6320 USA    |
+---------------------------------------------------------------------------+


From dicks@math.ohio-state.edu Sat Oct 30 09:30:31 EDT 1993
Article: 440 of alt.sys.pdp8
Path: samba.oit.unc.edu!concert!inxs.concert.net!taco!lll-winken.llnl.gov!koriel!cs.utexas.edu!math.ohio-state.edu!not-for-mail
From: dicks@math.ohio-state.edu (Ethan Dicks)
Newsgroups: alt.sys.pdp8
Subject: DECmate system software sought
Date: 26 Oct 1993 23:24:28 -0400
Organization: Department of Mathematics, The Ohio State University
Lines: 19
Sender: dicks@math.ohio-state.edu
Distribution: na
Message-ID: <2akplc$9ds@math.mps.ohio-state.edu>


I was just given a DECmate II with a RD disk controller and managed
to find a working ST225 in my closet, so I am on the hunt for DECmate
software.

I have downloaded the various teledisk'ed files from sunsite, but I didn't
see any OS/278 binaries, just source.  I did get the system test diskette
and was able to format the RD31 and test the system.  Also, when I boot
the WPS install diskette, it tells me that I must install the master menu
first.  I didn't see anything named "master menu".

Thanks,
-ethan

-- 
This message was (fortunately) not brought to you by Intel...
  "Intel: bringing you the "backward" in backward compatibilty."

dicks@math.ohio-state.edu -or- erd@kumiss.cmhnet.org


From cgordon@vpnet.chi.il.us Sat Oct 30 11:30:56 EDT 1993
Article: 441 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!sol.ctr.columbia.edu!news.columbia.edu!psinntp!psinntp!laidbak!obdient!amiserv!vpnet!cgordon
From: cgordon@vpnet.chi.il.us (gordon hlavenka)
Subject: Re: FOCAL and MUCAL
Message-ID: <1993Oct26.205034.22691@vpnet.chi.il.us>
Keywords: languages
Organization: Vpnet - Public Access Unix and Usenet
References: <2abj17$pmu@panix.com>
Date: Tue, 26 Oct 1993 20:50:34 GMT
Lines: 47

In article <2abj17$pmu@panix.com>, Henry Lowengard <jhhl@panix.com> wrote:
>the phenomenon later known as 'the kludge harp' where
>noise picked up over a radio could be pitched and used
>as a sine wave oscillator. 

While I was in the U.S. Navy, I had the luxury of being allowed to
have my pdp8/e onboard the ship (!)  There was an unused office space
that I set it up in.  Strapped an ASR-33 stand to the bulkhead and
started in to having fun.

Of course everyone who has hacked an 8e (or probably anything else) in
an *.edu environment has discovered the musical possibilities.  My
favorite little ditty was a FOCAL program which played the classic
4-note "Twilight Zone" theme over and over.  Now, a couple years out
of high school, I broke out that old paper tape again.

One evening, as I was reading a magazine in my little computer room
(with TZ in the background) I decided to drop in on one of my pals who
was standing watch in CIC.  (CIC stands for "Combat Information
Center", and is where most of the weapons control consoles and
navigational consoles are located.)

When I walked in, there was a minor commotion going on over bu the
SLQ-32 console.  SLQ-32 was (at the time) the absolute super-duperest
"passive radar" system in the fleet.  Using SLQ-32, you could identify
and track other ships by examining their RF emissions.  Some versions
of the SLQ-32 included active jamming capabilities as well.

When a new RF signal ("emitter") was spotted, the SLQ-32's computer
(If the operator wasn't playing Pong :-) would try to classify it
based on a dictionary of past experience.

Anyway, the SLQ-32 had just picked up a new emitter.  It seemed to be
pretty close to the ship, since it covered a pretty wide bearing range.
And the PRF didn't match anything in the catalog.  The EW2 running the
console was suspecting that he had some kind of equipment failure.  He
decided to manually time the PRF, so he turned on the...  SPEAKER!!!

CIC was filled with everyone's favorite four notes.

I went back and turned off the 8e, which was on a table 4 feet below
the SLQ-32's port antenna.

-- 
----------------------------------------------------
Gordon S. Hlavenka           cgordon@vpnet.chi.il.us
Proud father of Daniel Scott     born August 9, 1993


From jones@pyrite Sat Oct 30 11:31:57 EDT 1993
Article: 442 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!wupost!howland.reston.ans.net!vixen.cso.uiuc.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: FOCAL - some more questions
Sender: news@news.uiowa.edu (News)
Message-ID: <1993Oct28.140429.8373@news.uiowa.edu>
Date: Thu, 28 Oct 1993 14:04:29 GMT
References: <2anou4$p76@samba.oit.unc.edu>
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: University of Iowa, Iowa City, IA, USA
Lines: 18
Xref: samba.oit.unc.edu alt.folklore.computers:49631 alt.sys.pdp8:442

>From article <2anou4$p76@samba.oit.unc.edu>,
by lasner@sunSITE.unc.edu (Charles Lasner):
> 
> .... And people are misremembering features, etc.  A lot of it stems
> from either confusing FOCAL with other languages, or remembering
> non-standard implementations or worse.  Perhaps we need a definitive
> spec for just what FOCAL actually is.

Well, why not just use FOCAL 1969 as the reference standard.  The object
code (BIN format) is still available, and anyone with a PDP-8 or a
halfway decent PDP-8 emulator can run it and get the real thing, as
opposed to halfway implementations in C.  The only trouble with an
emulated PDP-8 running FOCAL is that it's a bit slower than the C
version, but on a modern processor (such as a Sun SPARC IV) emulators
run almost as fast at a PDP-8/E and a whole lot faster than a PDP-8/S.

					Doug Jones
					jones@cs.uiowa.edu


From lasner@sunSITE.unc.edu Sat Oct 30 11:56:51 EDT 1993
Article: 443 of alt.sys.pdp8
Path: samba.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Subject: Re: FOCAL - some more questions
Date: 30 Oct 1993 15:56:52 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 56
Message-ID: <2au2s4$bir@samba.oit.unc.edu>
References: <2anou4$p76@samba.oit.unc.edu> <1993Oct28.140429.8373@news.uiowa.edu>
NNTP-Posting-Host: calypso.oit.unc.edu
Xref: samba.oit.unc.edu alt.folklore.computers:49643 alt.sys.pdp8:443

In article <1993Oct28.140429.8373@news.uiowa.edu>,
Douglas W. Jones,201H MLH,3193350740,3193382879 <jones@pyrite> wrote:
>From article <2anou4$p76@samba.oit.unc.edu>,
>by lasner@sunSITE.unc.edu (Charles Lasner):
>> 
>> .... And people are misremembering features, etc.  A lot of it stems
>> from either confusing FOCAL with other languages, or remembering
>> non-standard implementations or worse.  Perhaps we need a definitive
>> spec for just what FOCAL actually is.
>
>Well, why not just use FOCAL 1969 as the reference standard.  The object
>code (BIN format) is still available, and anyone with a PDP-8 or a
>halfway decent PDP-8 emulator can run it and get the real thing, as
>opposed to halfway implementations in C.  The only trouble with an
>emulated PDP-8 running FOCAL is that it's a bit slower than the C
>version, but on a modern processor (such as a Sun SPARC IV) emulators
>run almost as fast at a PDP-8/E and a whole lot faster than a PDP-8/S.

I agree.  The need to be compatible is one of the design objectives of the
P?S/8 FOCAL implementation.  A lot of FOCAL programs need to take advantages of
just about every quirk of the language, etc.

To clear up a piece of the FOCAL spec:

The output format of FOCAL is controlled by a format control variable called %
The initial setting is %8.03, thus accounting for the attempts to output up to
8 digits with three decimal points, resorting to floating notation where it
doesn't fit, etc.  But this is merely the default.  The % operation can be
set from any TYPE (or ASK!) statement using such as:

1.01 TYPE %10.04,1+1

The format control applies until changed again.  % with no args means to always
use floating notation.  Due to a quirk of the implementation, the leading zero
is required on the decimal point portion of the format control statement, thus
%8.03 is *not* %8.3 !  (This could be easily fixed, but would then make the
binary not position-specific compatible, and could possibly make existing
programs not work correctly.  Changing the position of code is unacceptable
due to the enormous amount of patches written to FOCAL, 1969 depending on
absolute binary locations, etc.  P?S/8 FOCAL touches no part of the code,
except for certain areas bodily moved or excised out altogether, primarily
stuff that tends not to get patched, and the space is then used to implement
the interface to the system, etc.)

As to emulators, I am puzzled by the notion that an allegedly fast machine
with tons of MIPS could have trouble emulating a sub-1-MIP PDP-8/e.  I guess
either MIPS overstates the alleged "power" (Meaningless Instructions Per
Second which implies fast NOP's but not useful instruction rate) and/or gross
overhead in C-generated object code.

As a reference point, I would choose the PDP-15-based PDP-8 emulator.  This is
a single-accumulator machine that is essentially an 18-bit cousin of the PDP-8
and is about twice as fast as an 8/e.  Yet, the emulator runs PDP-8 software
at about 1/6 the speed of the real PDP-8!

cj "How about a SPARC-8" l


From greg@huia.canterbury.ac.nz Thu Nov  4 10:10:44 EST 1993
Article: 444 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!umn.edu!spool.mu.edu!olivea!hal.com!decwrl!waikato!comp.vuw.ac.nz!canterbury.ac.nz!huia!greg
From: greg@huia.canterbury.ac.nz (Greg Ewing)
Subject: Re: FOCAL - some more questions
Message-ID: <CFn5J0.JA3@cantua.canterbury.ac.nz>
Nntp-Posting-Host: huia.canterbury.ac.nz
Reply-To: greg@huia.canterbury.ac.nz (Greg Ewing)
Organization: University of Canterbury, Christchurch, New Zealand
References: <2anou4$p76@samba.oit.unc.edu> <1993Oct28.140429.8373@news.uiowa.edu>
Date: Fri, 29 Oct 1993 04:23:24 GMT
Lines: 21
Xref: samba.oit.unc.edu alt.folklore.computers:49693 alt.sys.pdp8:444

In article <1993Oct28.140429.8373@news.uiowa.edu>, jones@pyrite (Douglas
W. Jones,201H MLH,3193350740,3193382879) writes:
|> Well, why not just use FOCAL 1969 as the reference standard.  The object
|> code (BIN format) is still available, and anyone with a PDP-8 or a
|> halfway decent PDP-8 emulator can run it and get the real thing

Where can one get this from? I have a crazy idea for an adventure
game with an embedded fully-functional PDP-8, and a genuine language
implementation from the period would be just the thing to go with it.

Are there any other pieces of PDP-8 software around? A BASIC and/or
operating system would be neat.

|> 
|> 					Doug Jones
|> 					jones@cs.uiowa.edu

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of Japan Inc.|
greg@cosc.canterbury.ac.nz	   +--------------------------------------+


From hsnewman@wixer.bga.com Thu Nov  4 10:22:33 EST 1993
Article: 445 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: samba.oit.unc.edu!concert!uvaarpa!caen!usenet.coe.montana.edu!decwrl!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!milano!cactus.org!wixer!hsnewman
From: hsnewman@wixer.bga.com (Harris Newman)
Subject: DECWAR/MEGAWAR source code wanted
Message-ID: <1993Oct30.201140.7696@wixer.bga.com>
Organization: Real/Time Communications
Date: Sat, 30 Oct 1993 20:11:40 GMT
Lines: 8

I am looking for the source to a game which ran on a Dec 10 called Decwar.
It was developed at the university of texas, in fortran.  It is a multiplayer
star trek game.  If you have played Megawar on compuserve, that is it, but
rewritten with slightly more functionality. Anyone with any information,
please contact me at hsnewman@wixer.bga.com, or 512-322-3841.
Thanks!


From magnus@thep.lu.se Thu Nov  4 10:24:17 EST 1993
Article: 446 of alt.sys.pdp8
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: samba.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!howland.reston.ans.net!pipex!sunic!news.lth.se!news.lu.se!magnus
From: magnus@thep.lu.se (Magnus Olsson)
Subject: The FOCAL interpreter - more problems
Message-ID: <1993Oct31.115333.29222@nomina.lu.se>
Sender: news@nomina.lu.se (USENET News System)
Nntp-Posting-Host: dirac.thep.lu.se
Organization: Dept. of Theoretical Physics, Lund University, Lund, Sweden
References: <2anou4$p76@samba.oit.unc.edu> <1993Oct28.140429.8373@news.uiowa.edu> <1993Oct29.152857.29424@ifi.informatik.uni-stuttgart.de>
Date: Sun, 31 Oct 1993 11:53:33 GMT
Lines: 85
Xref: samba.oit.unc.edu alt.folklore.computers:49799 alt.sys.pdp8:446

In article <1993Oct29.152857.29424@ifi.informatik.uni-stuttgart.de>,
krause <krause@azu.informatik.uni-stuttgart.de> wrote:
>We have compiled and tested the FOCAL compiler on a PC. 
 (i suppose you mean "interpreter" and not "compiler")

>We found a lot of
>discrepancies to the original 4K FOCAL (1969). We tried to run the 'perpetual
>calendar' and the 'towers of hanoi' which both run as well on our pdp8/e as
>on a existing pdp8/e emulator.
>
>Some of the 'defects' we found:
>* No math-functions implemented. We did this, with the restriction, that the 
>  exponentiation has the same priority as * and /.
>* In expressions the various enclosure symbols had to match: ( < [ ] > ).
>  in 'real' FOCAL it is also possible to write:
>  S A = 5 * (3+1]
>* It is also allowed to write:
>  T "HELLO
>* Line numbering did not conform to the original:
>  Entering
>  1.1 T "HELLO
>  produced 
>  1.01 T "HELLO
>  correct is:
>  1.10 T "HELLO
>* We added a rudimentary trace feature, which lists the current line numbers.
>* The behaviour of the DO within and outside the current line group differed
>  also from the original.

I also found some of these problems. Another problem is I/O: The
posted interpreter (I mean the original version, not your patched one,
which I wasn't able to compile; see below) seems to take the easy way
out, just using the C library's I/O functions. As a result, all
output is printed in a desperately ugly "E format" (probably just the
output of a 'printf ("%e",x)').

Also, which is more important, the interesting "letters as digits"
feature of FOCAL doesn't seem to work. I'm of course referring to the
fact that all letters except 'E' should be interpreted as digits, so
that 'A'=1, 'B'=2 and so on, and that it should be possible to use
numerical literals such as "0YES" and "0NO".

If you haven't already fixed this, IMHO you definitely should!

>The patched FOCAL.C along with two example programs from the book 'programming
>languages part 2 (C 1970 by Digital Equipment Corporation) is put to 
>alt.sources.

Thanks a lot! However, this won't compile under Ultrix (which, I
suppose, means it won't compiler under 4.2BSD either).

I get the following errors:

>% cc focal.c -lm
>"focal2.c", line 54: warning: illegal zero sized structure member: l_text
>"focal2.c", line 95: warning: illegal zero sized structure member: s_id
>Undefined:
>_randomize
>_stricmp
>%

Obviously, you're using two library functions randomize and stricmp that
aren't part fo the standard Unix library. 

The first two error messages have been discussed here before: they were
fixed in the first patched version of the interpreter that was posted
on alt.sources. Maybe you should have a look at that.

Finally, an observation:

Intending no disrespect to the original author of the Focal
interpreter, I must conclude that it was a quick-and-dirty hack that
obviously never has been tested with real Focal code. Unfortunately,
it was taken by us unfortunate Focal-deprived newbies [:-)] as
defining the real language, which means that a lot of people are now
running around with the wrong ideas about Focal (for example that the
line number "1.1" is equivalent to "1.01" rather than to "1.10"). 

I really appreciate the efforts to put this right. 

              Magnus Olsson                | \e+      /_
    Department of Theoretical Physics      |  \  Z   / q
        University of Lund, Sweden         |   >----<           
 magnus@thep.lu.se,  thepmo@selund.bitnet  |  /      \===== g
PGP key available via finger or on request | /e-      \q


