Subject: How "good" is a pdp-8?

From: [email-masked] (Patrick Thomas)
Date: Wed, 23 Jun 93 14:50:17 GMT

Michigan State University was selling a PDP-8 with two disk drives and all
the necessary hardware for $35. Since the price is right (cheap), I was 
thinking of picking it up. I've heard a bunch about the pdp-8 and pdp-11,
but I don't really know what they're capable of. A bit of reading (the
Small Computer Handbook published by DEC in 1970) didn't really
offer much insight, either :-(. Can anybody offer any suggestions as to 
how powerful this machine really is?

  Thanks a lot!

   -- Patrick

---

From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: Wed, 23 Jun 1993 15:47:28 GMT

>From article <[email-masked]>,
by [email-masked] (Patrick Thomas):

> Can anybody offer any suggestions as to 

How do you measure power?  32K 12 bit words of main memory is one good
measure of power that makes it not too different from early model PDP-11
systems which had 48K 8 bit bytes.  A 1.2 to 1.4 microsecond memory
cycle time is another good measure.  By the standards of a modern PC,
this is close to nothing, but it's enough to handle quite a bit of work.

Applications?  The guy from cleveland who's trying to dispose of a pair
of -8/E systems once owned by the Cleveland Sun Newspaper has hardware
configurations that suggest that the machines began life as 10 user
timesharing systems.  I'd assume, being at a newspaper, that the users
were doing word-processing or newspaper-style text formatting.  Similar
timesharing systems were widely used in public schools and small colleges
for instructional computing until they were displaced, mostly by Apple II
systems.

FORTRAN was widely used on the -8, and DECUS lists a LISP interpreter in
their catalog.  The immense (and unwarranted) popularity of BASIC today
is largely the result of its widespread use on PDP-8 systems.

The huge popularity of the PDP-8 is due to one major factor.  Starting
in 1965 and ending in the early to mid 1970s, the PDP-8 was the least
expensive general purpose computer system on the market.  DEC offered a
wide range of peripherals, from fast disk systems to process control
interface hardware.
					Doug Jones
					[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: Wed, 23 Jun 1993 21:06:45 GMT

>for instructional computing until they were displaced, mostly by Apple II

I wrote a 40-user system for the newswire industry on the following hardware:

PDP-8/e with EAE
32K
paper-tape reader/punch
VT8E
console TTY:
LPT:
several KL8-type interfaces
RK8E with 2-4 RK05's
up to 4 8-channel Telcon serial multiplexors.

Each task is logically attached to either a port on a Telcon, a KL8,
the reader/punch, console, etc. (40 tasks maximum not counting the
"system" essentially meaning the disk queues, etc.  Telcon ports can be
defined to be either an "editing" terminal (a buffered terminal that can
execute commands, or send a file to the -8) or a "console" terminal (can't
send a file, but has access to all of the other commands including commands
privileged to operators only; the protocol is different to a console terminal
because it's what most of us are familiar with while the editing terminal
protocol is quite different.  The design reason was so that the editors
didn't have to do anything special to communicate with the -8.  Commands
from an editing terminal essentially look like ^E{command}^D while file
transmission essentially looks like ^A{body of file}^D and no commands
should be echoed.  Consoles are the normal full-duplex with BS-SP-BS
editing and echoing, etc., and have a command prompt.

As a hack to help the editors, when viewing a file from the -8, it came into
the editing terminal a page at a time (if requested) and ended the page
with a blank line containing "MORE?" on it.  They could hit the command-send
key and the MORE command would be returned to the -8.  The MORE command was
defined to output the next page, but only if in the midst of a paged file
send, and then only to an editing terminal.  This allowed the editors to 
page through their files and hit a key to goto the next page, etc.  The
next page did a line-up-erase function to obliterate the MORE? and allow the
end result of a clean copy of the file as if it had been loaded without the
paging, etc.

Each file contained a complex header of routing and other filing info.  The
system maintained a flat file directory of all files in a sorting order that
favored right-justification of names instead of the normal left-justification.
This allows names such as

FILE1
FILE2
FILE3
...
FILE8
FILE9
FILE10

to be held in that order without resorting to making it FILE01, etc.

The innards of the directory itself are a balanced B-tree with the root
block cached.  For a system of up to about 100,000 files, this means that
it takes at most two disk reads to get to the leaf entry for any particular
file.

The purpose of this system is to collect files created by editors and
output them in an 8-tiered priority queue with complex routing, etc.
Each file contains the particular routing for itself which can include
selective output routing to any system port, all ports, all printers, all
"live" lines (meaning the active output to the wire-service ports, etc.)
and any and all forms of individualized priorities for any lines including
the ability to schedule deferred output.  In strict accordance with SEC
guidelines, the system supports guaranteed delays between selected lines
(no brokers can receive info until 15 minutes after at least one news
service has received it, etc.).

One VT8E is supported on the system emulating a VT05.  All of this *barely*
fits in 32K including a field set aside for reusable disk buffers.  The
support code for all of the system fits in 4K and the reentrant serially
reusable code exists in another 12K to support each of the possible task
types.  All configuration consists of off-line customization of the relevant
device tabled, so once a system is up, it stays fixed, etc.

All output queues of a selected type are saved in a linked audit trail to
allow for selective retransmission, and also to allow for off-line customer
billing after the fact.

The entire system, complete with utilities, comes to just under 32K of code
which can be simultaneously loaded into memory as the result of assembling
the whole thing together (about 60,000 lines of code, a lot of which are
definitions, etc.) or it can be assembled separately as modules.  The
whole assembly is far beyond the capabilities of OS/8 CREF.SV, and this was
one of the factors that led to modularizing the sources, etc.

The complete binary includes a stand-alone sysgen utility to write our
selected areas of memory to designated RK8E disk blocks.  When it's all
written out, the result is a bootable disk that runs a menu of utilites,
including putting up the real-time system, and an off-line crash recovery
utility that can recover from any form of directory devistation.  (The
files self-identify in their own data records and are also doubly-linked.
Should the directory be wiped, all you have to do is a linear search through
all blocks looking for file chains and you can rebuild the directory.  When
all blocks have been traversed, you have recreated the complete directory
except for any trashed files.  If duplicates are found, the operator can
either trash them or rename them for investigation later when the system is
up again.

One cute feature is automatic file creation from timed-out ASCII text
input.  A bunch of remote users of this system needed to dump raw ASCII
files into the system from remote machines.  The files were then to be
called up by the editors for reprocessing, etc.  So, we added timed-out
serial ports that then created files with automatic names, such as TTY00001,
TTY00002, TTY00003, etc.  Also, some of the ports were occasionally hooked to
paper-tape readers because parts of some of the older networks used paper-tape
as recently as 1989.

Somehow I don't see anyone doing this on an Apple II :-).

cjl

---

From: [email-masked] (Jon Krueger)
Date: 24 Jun 93 01:07:51 GMT

Douglas W. Jones writes:

> How do you measure power?  [some suggestions, such as how much
> work it could do, e.g.] 10 user timesharing systems

Another task a single 8/a or 8/e with 32K of 12 bit words did was
real-time data acquisition and process control for up to 6 concurrent
stations, each executing up to 64 parallel state sets, all at 10
millisecond resolution, while at the same time in the foreground
running a monitor that could interrogate any variable in any station
at any time, or editing, compiling, running data analysis, graphics,
transferring files to other machines, formatting documents.

And doing it all reliably.  If it crashed, the behavior of those 6
rats in those six stations all started to extinguish -- weeks, months,
or even years of training could be lost.  It didn't crash.

-- Jon
--
Jon Krueger  [email-masked]

---

From: [email-masked] (Patrick Thomas)
Date: Fri, 25 Jun 93 21:32:01 GMT

Well, unfortunately, the PDP-8 that Michigan SU had for $35 is gone. It 
was picked up later on the day of my original post (last friday). Oh well...

  On the other hand, I heard PDP-8 emulators are available out there.
Anybody have info they'd care to share or mail on that subject?

  Thanks,
   --- Patrick

---

From: [email-masked] (Jeff Makey)
Date: 27 Jun 93 15:26:54 PDT

In article <[email-masked]> [email-masked] (Patrick Thomas) writes:
>I heard PDP-8 emulators are available out there.

I once wrote a PDP-8/L emulator in BASIC+, DEC's (very nice) version
of BASIC for the RSTS/E operating system on the PDP-11.  It worked,
but with all of the software layers it was *very* slow: with PDP-8
BASIC loaded it took several seconds to parse a blank line.  However,
I have no doubt that an emulated PDP-8 running on a modern RISC
machine would be faster than the original.

                            :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Domain: [email-masked]    UUCP: nosc!crash!jeff

---

From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: Mon, 28 Jun 1993 20:50:04 GMT

I have an emulator for the PDP-8/E written in C.  It currently is fully
up to running FOCAL-1969, and I'm almost done with the KM8E (that's the
memory management unit) emulation, which reminds me, does anyone have
something in the way of code to exercise the KM8E?

My emulator has extremely accurate emulation of I/O timing, so that a
program using the high-speed paper-tape-reader will be unable, by way
of timing loops or other software tricks, to tell that it isn't being run
on the real thing.  Of course, this means that TTY output comes at a speed
determined by the emulated baud-rate times the speed-up or slow-down of
the emulator.  Running at an emulated 1200 baud on my IBM RT, the emulator
looks like it's running at 110 baud from the keyboard's point of view.
It runs about 3 times faster on my SPARCbook (a laptop SPARCstation).

On the other hand, FOCAL was a nice enough little language that your
average throw-away FOCAL code runs fast enough that you don't mind the
cost of emulation.

When I get the KM8E tested (soon, I hope) I'll release the code to the
community.
					Doug Jones
					[email-masked]

---

From: [email-masked] (Bob Supnik)
Date: 29 Jun 1993 18:35:34 -0400

In article <[email-masked]>, jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes...
> [text deleted]

Yeah, mine is also about 3/4 done.  CPU, MMU, EAE, reader, punch, keyboard,
terminal, clock.  Timing is approximate and adjustable: the emphasis is
on raw performance.  I've got and run the core instruction diagnostics,
and I've also got something that purports to be an MMU test, but without
listings or instructions these things are difficult to work with.

The key problems I have are:

1) How to do asynchronous I/O from the keyboard in a reasonably O/S
   independent way?
2) How to sync the simulated clock with the REAL clock, with the same
   restriction.

There are solutions to both under both VMS and UNIX, but they are very
different.

Now, on to the RK8E...

Bob Supnik	>[email-masked]
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation

---

From: [email-masked] (Charles Lasner)
Date: Wed, 30 Jun 1993 09:32:55 GMT

>listings or instructions these things are difficult to work with.

Not really a good choice for an emulator, since it's a fair amount of PDP-8
overhead-ridden device.  Of course, the grandaddy worst case of all is the
RX family, but there is a lot of RK kludges in the handler as well, and the
performance of the thing is predicated on some sublte real-time considerations
as well.

There are two much better choices for an emulator:

The most obvious is the fully extended RF08 (minus the DV08, please!).  This
is the standard RF08 with 4 platters with an extra unit bit to address
8 platters.  The DV08 was usually bundled with it.  This was an option that
did a verify after write and could interrupt on verify error.  Thus, it was
totally software compatible with standard RF software because you could
ignore it except in an interrupt handler similar in scope to a parity memory
handler, etc.  The extra bit of platter addressibility is obvious.  In many
machines, an 8 platter RF could fit in the machine's memory.  Transfers are
initiated by setting the 3-cycle data break locations and then waiting for the
DMA to finish.

The DF32 did use tricks like the DECtape to monitor the WC and CA addresses
and update them during the transfer, but the RF is too fast, and can thus
be emulated by faking the results after the fact.  Practical handlers can
either wait for a done flag or an interrupt, but they assume the hardware
accomplished the transfers once started, ideal for an emulator.

The other alternative is to emulate the CESI SCSI host adaptor for the -8
because this device controls industry standard SCSI devices which can be
totally open-ended as to what you want to support, thus you can have huge
disks on the -8.  My machines sports one or two 80 Meg MFM disks on an OMTI
5400 controller with HD floppies and a SyQuest removable cartridge disk drive.
Emulating this would be rather nice.  The instruction set is merely a point
and go IOT set.  The commands are passed via DMA to the onboard micro-based
controller, and are essentially SCSI commands as would be sent to an SCSI
device, slightly augmented with -8-specific info such as address and field,
etc.  IF the command is a read or write or a few others, then there is also
an implied DMA operation after the fact, and the done flag is set when the
two-stage DMA process is finished.  Of course, this all means that an
emulator can just look at what's being attempted and deal with the SCSI 
command itself rather than do a PDP-8 instruction-by-instruction emulation.
Thus, this is the polar opposite to a handler for an RX.

cjl