Subject: Supporting PDP-8/e's without disks

From: [email-masked] (Charles Lasner)
Date: Thu, 18 Feb 1993 02:53:42 GMT

It is becoming increasingly obvious that there is a new "breed" of PDP-8
collector/hobbyist/user/enthusiast, somewhat apart from oldtimers such as
myself.  For me, a PDP-8 is what I want to make of it, since I have about
15000% of a whole machine to choose from, and can just crank up a machine
with whatever on it I need, so I guess that "spoils" me somewhat :-).

Today, we have PDP-8 newbies.  They unfortunately are coming into the -8
from a bad vantage point - they are getting incomplete machines.

The PDP-8 was more-or-less the transitional machine of the industry: it could
be had as a system which could be configured for software development or a
significent application, or it could be stripped down to a "naked CPU" with
hardly anything beyond the KK8F CPU card set and maybe some DEC memory and
a console interface.

The "Paper-Tape Software System" doesn't help us any either, since basically
the stuff is beneath contempt, although can you really do any better whan all
you have available is a CPU with 4K or 8K or memory, and a KL8E at 110 baud
to an ASR33 TTY:?

So, a lot of requests are coming to the environs of this group basically 
looking for assistance with these deficient configurations, and hoping that
somehow they can be supported either at all, or beyond reasonable expectations.

Let me start by making a very clear statement:

The PDP-8 is *not* all about playing with paper-tape!  Except for some
quirky low-level usage, the vast majority of PDP-8 usage occurs in systems of
"significence" where the prevailing operating systems (OS/8, P?S/8, etc) can
run.

So, am I saying to abandon these people?  Hardly, as we of course welcome
anyone into the land of -8.  It's just that you "can't get there from here" if
you don't have enough hardware.

So, how much hardware is enough hardware?

The following is the *minimum* requirement in order to do "something" on the
machine:

1)	*Functional* PDP-8 model with at least 4K of memory, preferably more.
This includes any model of PDP-8, LINC-8, PDP-12, 8/i, 8/l, 8/e, 8/f, 8/m, 8/a
and the few knockoffs from noted companies such as CESI, DCC, and possibly
Fabritek, as well as a few Eastern European clones such as the TPA.  Also,
any VT-78 or DECmate model qualifies for at least this portion of the
requirement (if not the entire requirement).

2)	A fully compatible device 03/04 console interface with a baud rate
appropriate for an ASCII terminal.  The minimum acceptable device is an 
ASR33 Teletype hooked to a 110 baud current-loop interface.  However, an
actual Teletype doesn't support lower-case, and is quite slow, as well as
lacking any "frills" such as backspacing, esc-sequence/cursor tricks, etc.
Preferably, an enterprising PDP-8-er can locate at least some form of
"glass TTY" that someone has discarded because it ain't "fancy" enough, etc.
The truth is that most of the software is geared for something less than
a VT-100.  (Also, it VT-100 mode is supported, make sure that it can easily
be put into VT-52 mode, since some of the software frills inconsistently
assume one or the other!) 

	The most popular interfaces tend to either be built-in for the older
models, thus most of the problems center around either changing the baud
rate or the interface type there.  While DEC did specify an RS-232 connector
board for the 8/l-8/l-12 family, it is a rare beast.  Someone reading this
group likely can document how to construct such a card for those wanting an
RS-232 connection.  The baud-rate generator card can be hand-modified to 
support a faster rate if you can hand-adjust the oscillator.  Merely changing
a timing capacitor and readjusting a pot gets you where you want to go.  I
started a project to produce a replacement card with a crystal oscillator and
can fill in anyone interested in fleshing out that little project.  (It uses
the 5016/8016 baud-rate chip as DEC uses in the DECmates, etc. to get the
16 standard rates, etc.  Thus, flipping DIP switches gets you what you need.)

	For most other would-be users, the problems seem to be getting
Omnibus boards to do what they want.  The usual problem is the machine
comes with a "vanilla" KL8E (M8650) which is setup for a 110 baud current-loop
TTY: only.  To fix this, Doug Jones has prepared a "cheat sheet" that outlines
how to change the card over to 150 baud and up by powers of two up to at least
76800 baud.  Note that the card supports as a standard feature, the BC01V
or BC05C comm cable for RS-232 usage.  There is no modem control, however,
data terminal ready, etc. can be held high for compatibility, etc.  Doug's
notes explain how to make the equivalent of these cables.  A word of warning:
when reproducing these cables, there is no "margin of error".  Should you
screw up, you can really burn a lot of stuff out!  Please do not undertake
this project if you don't understand DEC's notation regarding Berg connector
pin numbers, etc.!  Also, note that there is a jumper in the Berg end of the
cable.  This jumper is *not* meant to be run through the cable, so it must be
implemented at the cable end.  Thus, it complicates attempts to construct the
cable using flat ribbon cable, but it can be done by picking out the relevant
conductors and looping them together, etc.

The specifics of modifying a KL8E for 150*2^N baud involve removing the
two-stop-bits jumpers, and changing the crystal speed from 14.418 to 18.661
MHz.  In other words, raising the frequency by a factor of 15/11.  At this
point, it hasn't been determined if the crystal cut is meant to be a variant
of the "series" or "parallel" variety.  (These are severely different kinds
of crystal types; there are more subtle differences which have to do with
either accuracy or stability, etc.  Unfortunately, if you use the wrong
type, it may seem to work, but will be both erratic, and worse, will be at
the wrong frequency!)  My personal method is to toss the whole DEC analog 
circuit and replace with a canned oscillator.  In fact, since DEC used a
pulse transformer of a convenient design, 3 of the 4 leads are actually
in the proper place!  Placing a jumper from the can output to where the
TTL chip wants the can output, and adding the actual can is all you need
to do.  Personal preference of mine is to suck out all of the unused parts,
and then solder back in the clear holes, to give the board a "wave soldered"
look.

Note that additional serial ports are desirable, or even necessary (see below).

KL8-JA (M8655) cards are a compatible viable alternative to KL8E, but only
go up to 9600 baud as delivered, and can only be modified by changing jumpers
to 19200 baud.  However, the board is much easier to setup, since most (but
not all) of the options are setup with DIP switches.

Note that the factory jumpers on KL8E are automagically device 03/04, while
the user jumpers have to setup in strange loop patterns to accomplish a
device code pair setup.

3)	A disk device for the OS(es) to reside on.  This is hopefully something
like an SCSI disk or Omnibus Hardcard IDE disk, or an RK8E/RK05 or two or four,
or TC01/08 DECtape with TU55/56 drives, or RX01/02 or whatever.  Note that
removable media, such as 8" floppies or DECtapes, allows direct interchange
between like systems.

For the "disadvantaged" users of which I wrote at the top of this, there is
another way to go: use a serving nearby machine connected to the PDP-8 via
a serial link preferably at a decent baud rate (38400).  PDP-8 connection
is made via another KL-type interface identical to the console interface
except set to a different pair of receive/transmit codes.

Due to the "frugal" environment of the OS/8 system handler, this "weak link"
establishes the spec for a handler and server.  The basics of this are that
the serving end of the link has to be able to handle a burst of characters
arriving at 100% of the baud rate, yet be prepared to time out the transfer
should it take longer.  The maximum packet size will be about 6K for the
longest PDP-8 transaction, and will be stated as part of the data itself
(at the start of the transaction).  When sending to the -8, there will need to
be an "echoing" protocol because the -8 cannot be depended upon to have 
necessarily received the character.  Thus, each character will have to be 
acknowledged with a return character back to the server.  Such is the
consequence of a loosely-coupled interface where one side is not guaranteed
to be obeying the protocol absolutely.

The PDP-8 is always in control of the protocol, so a value will be reserved
that means to abort any in-progress operation, and start a new one literally
unconditionally.  The PDP-8 will likely not be able to time-out the server,
since manual restart is likely on the -8 should the protocol break down.  But
the server should time out the -8 which could get "stuck".

By obeying this and other similar "rules" it is possible to get the
advantage of having a disk from the -8's point of view, and yet take
advantage of the likely vaster storage available on other machines that the
user might have on hand.  So, while not as handy as a HardCard, it still beats
the hell out of paper-tape!

Additionally, once the user has such a system, by adding an additional
KL-type interface, it is feasible to run my Kermit-12, together with the
provided utilities, etc.  Using this package, it is then possible for
everyone to exchange files, including PDP-8 binary files, and even entire
disk images, etc. down the net via e-mail, etc.

In future posts, I'll indicate details of a serving program.  After writing
some actual handler code, I'll see just how stringent the server side has
to be.  (This has been done before, but not on serial interfaces.  Using
a parallel interface with full handshaking, it was possible to write a
one-page handler will good efficiency.  Serial interfaces without any
handshaking requires more work on the -8 side, yet OS/8 won't allow more than
a two-page handler at most :-(.)