Subject: Re: What's a PDP-8?

From: [email-masked] (Paul Gallagher)
Date: 2 Mar 1994 01:44:29 -0500

In <[email-masked]> [email-masked] (Margaretha M. Guenther) writes:

>How did the PDP-8 compare to later Micros?

I'm curious too.  How do they compare in terms of RAM?  What's program memory,
which is mentioned in the FAQ?  Also, what were the common operating systems
for the machines?

I remember as a kid, back in 1976, learning to program in Basic on some kind of
PDP-8.  As far as I can remember, this involved starting up the computer by
flipping some switches on the machine, then entering the numbered Basic lines
at the prompt on the teletype, and storing them on paper tape.  It seems like
some steps are missing there in my memory, since I don't recall interacting
with an operating system at all...

Paul
[email-masked]

---

From: [email-masked] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: 2 Mar 1994 15:42:49 GMT

>From article <[email-masked]>,
by [email-masked] (Paul Gallagher):

> I'm curious too.  How do they compare in terms of RAM?

	A PDP-8 without memory management option has a maximum of 4K words
	(call it 12K bytes).  The normal memory management option ups this
	to 32K words (48K bytes).  When you recall that this was sold as
	a low end machine in the early 1970's, it's not too different from
	the memory people remember on the original Apple II or the original
	Altair 8800.

	In the late 1970's, larger memory expansion options came out, but
	none ever let you hang a megabyte on the machine, and after the
	PDP-8/E cpu in 1970, nobody tried to design a faster model.  Your
	average Power PC today can run a PDP-8 emulator faster than any
	hardware implementation anyone ever sold.

> What's program memory, which is mentioned in the FAQ?

	Grepping the faq for the string "program memory" I find it discussed
	in the DECmate III+ entry.  This machine had two memory banks of 32K
	words each, one available to application programs and the operating
	system, and one used by DEC's slushware to emulate hardware functions
	that were done in software on this model.  This took care of, for
	example, keyboard and screen handling, so that console I/O looked,
	to the operating system, like a serial line interface to a DEC VT
	series terminal.  If you don't have a DECmate (and I don't), you
	don't need to worry about this stuff.  Even if you do, you're most
	likely to live with DEC's slushware and confine your hacking to the
	32K of program memory.
	
> Also, what were the common operating systems for the machines?

	DEC's OS-8 (and various renumberings like OS-278) was the only
	really common operating system, but many others were written, such
	as TSS-8, a timesharing system.

> I remember as a kid, back in 1976, learning to program in Basic on some
> kind of PDP-8.  ...  I don't recall interacting with an operating system
> at all...

	You probably didn't interact with an operating system.  DEC sold
	stand-alone BASIC and FOCAL systems that didn't rest on any
	operating system.

					Doug Jones
					[email-masked]

---

From: [email-masked] (Paul Gallagher)
Date: 3 Mar 1994 23:53:18 -0500

>	stand-alone BASIC and FOCAL systems that didn't rest on any

Thank you very much for the help.  You're probably right about this.  I
found this in the FAQ:

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

I wonder how much that cost.  That's a very limited machine!  I went to
school in Concord, Mass., which is right next to Maynard, the home of Digital,
so we may have received the computers as a gift.

Paul
[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: 4 Mar 1994 06:47:11 GMT

>so we may have received the computers as a gift.

I can't comment on DEC's pricing or gifting, but I can give some
background on the development of POLY BASIC which was done while I was at
POLY itself.

The original POLY BASIC was attempted as a system program on the original
R-L Monitor System (aka MS/8, the forerunner of P?S/8).  It was not
entirely successful because of limitations of the system that aren't
useful to BASIC in its extended form:

R-L files consist of text in sequential form without line numbers much
like any other system.  However, there are also line numbers stored at
the back end of the files in binary form.  They are paired with pointers
to the text they pertain to.  R-L utilities can choose to ignore the
line-number info or retain it as necessary.  Of course in BASIC, the
numbers are quite integral to the program.  An ugly solution would have
been to have *double* line numbers:

100	100	REM LINE 100
110	110	PRINT "INFINITE LOOP"
120	120	GOTO 100
130	130	END

The reason this is necessary is that POLY BASIC supports EDIT RESEQUENCE
where the line numbers are resequenced in nice neat increments (by 10)
and all of the references in the program context are changed
accordingly.  It would become quite unweildy to hinge this on the binary
line numbers at the back of the file, since this would make the input to
the compiler dependent on the entire file, as opposed to sequential
buffers of the input files, etc.

Thus, a decision was reached to make POLY BASIC a stand-alone system.
The file format is straight text including the digits of the line numbers.

All versions of POLY BASIC were developed on and for a 4K PDP-8 with a
TC01 and a TU55 DECtape.  (This is also the minimum configuration for
MS/8 and also P?S/8.)  Eventually, after it all worked, it was taken to
Digital where support was added for other devices.  (It was the first
time that Richard Lary and Lenny Elekman had access to these other
devices such as RF08, etc.)

Eventually, in a move not everyone believes is ethical, DEC sold this
software after it was submitted to DECUS.  They changed the name to
EDU-System 30.  There was also a version called EDU 15/30.  It could run
on a TD8E using either the MR8E-C ROM and KM8E (to access the field 7
ROM) or 8K.  (Creating the system put an altered image of teh ROM into
field 1 and built a system that depended on it.  Overall, there was
dependance on the non-volatility of core.)

A feature DEC added on was the ability to read mark-sense punch cards.
In some instances, non-standard marks were made to stand for entire
tokens such as PRINT, etc.  This allows a school system to trade student
tedium of hand-marking cards for individualized editing of files and
limited disk space.

All in all, POLY BASIC shows just what can be done with a 4K machine
given a reasonable set of peripherals etc.

cjl

---

From: [email-masked] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: 4 Mar 1994 15:43:43 GMT

>From article <[email-masked]>, by [email-masked] (Paul Gallagher):
> 
> I wonder how much that cost.

Entry level EduSystems always sold for under $10,000 dollars.  I've got
a letter from DEC to an old professor of mine (now dead) dating to about
1972, offering him an entry-level EduSystem, based on a PDP-8/E, for about
7500 dollars, including teletype, FOCAL and BASIC.

					Doug Jones
					[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: 4 Mar 1994 16:47:42 GMT

In article <[email-masked]>,
>7500 dollars, including teletype, FOCAL and BASIC.

Not good enough.  Neglecting the cost of the software, we are talking
about adding on at least a TD8E with TU56H, KM8E, MR8E-C in the most
minimal EDU-15/30 system.  And it was geared towards classrooms
encouraged to add on mark-sense card capabilities so we include a CR8E
(CR8F?  I think that's what they call a mark-sense version of the card
reader).

EDU 30 systems are more money still because it requires either TC01/08
and TU55/56 or DF32 or RF08 (or to be run on a PDP-12 LINCtape system).
(Or an obscure hack: 32K "RAM" disk in core.)  EDU 15/30 was brought out
because of the TD8E being less money than any of the above.

The only actual difference between 15/30 and 30 is the disk device
support was excised out and replaced with a two-choice routine: MR8E-C
ROM in field 7 or a "fake" copy of the ROM in field 1.  Either method
requires extended memory control (M837 or KM8E).  Other than the
faked-out device handling analogous to the equivalent in OS/8 and P?S/8,
this is a strictly 4K system.

However, it is capable of running significently larger programs than
4K-BASIC or FOCAL because it's a true compiler.  Only user code and a
run-time are in memory after the compiler has done its work.
Additionally, it's not any form of interpreter in any sense (generates
code, not tokens).  The compiler is itself more than 4K as it swaps parts
of itself in.  The editor is about 2K and has overlays for the various
functions such as edit resequence.  User files and the editor occupy 4K.
Edit resequence brings in the resequencer code over the editor and
updates the user file in place.  Then the editor is swapped back in, etc.
The RUN command writes the user file to a dedicated scratch space.  The
compiler comes in and reads in the user file in several passes.  Segments
of the compiler are called in to parse as necessary.  The net result is a
binary file (incidentally compatible with MS/8 and P?S/8 internally!)
written to a dedicated scratch space.  IF there are no errors, the
run-time system is loaded and the user's binary overlays the run-time
system which then executes the stack of user code, etc.  While most of
the run-time system is resident during execution, there are a few
swappable routines where the run-time is required to execute
seldom-needed routines, etc.

So, this is "somewhat" more than the minimal 4K FOCAL and BASIC systems!

cjl

---

From: [email-masked] (Magnus Olsson)
Date: Mon, 7 Mar 1994 18:01:32 GMT

In article <[email-masked]>,
>110	110	PRINT "INFINITE LOOP"

Wouldn't the obvious solution have been to dispense with Basic's
using line numbers as labels (which has always appeared as sort of a kluge
to me) and introduce Fortran-style labels instead? That would make your
example look like

100		REM THIS LINE DOESN'T NEED ANY LABEL
110	10	PRINT "INFINITE LOOP"
120		GOTO 10

instead, and the programs would not only be more readable but also
the renumbering problem would go away.

Of course, modern Basics have chosen this direction (but with
alphanumeric labels rather than just numeric ones). But I suppose that
you had compatibility with other Basics (that all used line numbers
back then) as a design goal?  Pity, since you might have made the
"modern Basic" revolution happen a few years earlier... 

              Magnus Olsson                | \e+      /_
    Department of Theoretical Physics      |  \  Z   / q
        University of Lund, Sweden         |   >----<           
 [email-masked],  [email-masked]  |  /      \===== g
PGP key available via finger or on request | /e-      \q

---

From: [email-masked] (Charles Lasner)
Date: 8 Mar 1994 19:22:52 GMT

In article <[email-masked]>,
>the renumbering problem would go away.

We are mixing a discussion up here.

1)	The model for BASIC back that far was GE-235 BASIC.  It worked as
POLY BASIC imitated.  In that kind of system, the line numbers can't be
dispensed with because of the integrated editing environment.  In the
R-L/P?S/8 kind of system, you can go either way.  But to accede to the
R-L line numbers means to have to depend on them when required.  Since
the numbers are stored at the back end of the file, you have to read in
the text and numbers into two different buffers and independently work
with them whenever a resequence is required.  Remember, this a 4K total
system!  Of course it could have been done, but would have required a
forced writing out of the file, then reading it back in on both ends
until the "middle" was reached, then doing another pass on it again,
perhaps writing out and then reading in again a detail file that marks
all of the areas marked for resequencing, etc.  That much swapping would
be quite a sight, especially on DECtape!

So, they chose to invent a new operating system that worked like the GE
system, and the line numbers are stored as plain text characters; the
editor requires them.

2)	Your method minimizes line-numbers, but hardly eradicates them.
In any case, being lock-step with the GE system prevents your
suggestions; leaving it on the R-L/P?S/8-type system would have at least
allowed for future expansion as you suggest.  However, doing so forces
the dependency on the binary line numbers at least being allocated for,
i.e., BASIC could put up some form of alternate character-oriented editor
without enforced line-numbers.

Some versions of TECO have had to put up with that nuisance - allowing
for the stripping/restoring of line numbers for the benefit of SOS, etc.

>"modern Basic" revolution happen a few years earlier... 

Yes, had they been forced into having at least one language component
allowed to exist sans line number, then they would have likely stayed
within the R-L/P?S/8 guidelines of merely treating line numbers as an
artifact of a suggested editor, not a contents enforcement as in POLY BASIC.

Additionally, P?S/8 has outgrown the original R-L limitation of files
fixed to exactly 2K length with the line-number info at the back end of
the file, etc.  It is possible to create variable length files similar to
OS/8 and pass these to system programs.  The trade-off is that the 2K
files can be edited in the style of the line-number BASIC without much
overhead, even on DECtape-based systems with 4K.  The longer files have
to be edited using more common techniques with the attendant largely
increased tape motion, etc.

By the time BASIC was revisited for OS/8, the line numbers are just text
in the file.  If the language can delete unnecessary line numbers in the
text, so be it.  (Note: most of the PDP-8 BASIC's were written by the same
handful of people!)

cjl

ps: A bootable version of POLY BASIC for TC01/08 DECtape may become
available to be placed on sunsite.  If so, it can be dealt with by any
OS/8 system that can support ENCODE.SV and DECODE.SV.  However, it can
only be *run* if the hardware includes TC01/08.  If anyone can provide
alternate bootables (such as TD8E) it can be posted to the archive as
well (using my machine to accomplish it).