Subject: Re: New owner of a PDP-8e

From: [email-masked] (Charles Lasner)
Date: Wed, 28 Oct 1992 05:37:31 GMT

In article <[email-masked]> [email-masked] (Erkki Ruohtula) writes:
>In article <[email-masked]> [email-masked] (Charles Lasner) writes:
>>If an 8/a-type expander box is added to an 8/e, then the KT8A or CESI
>>memory extensions are possible.  The KT8A provides for up to 128K, and the
>>CESI MEC8 and static RAM memory boards allow up to 512K.  BTW, these are 12-bit
>>words, not bytes, so it's 768K of 8-bit bytes, which is more than a PC-XT
>>can have, or any MS-DOS real-mode environment on a PC, etc.
>
>A strange word size. How do you normally process characters on this box?
>As 6 six-bit characters in a word, or as 12 bit characters (the latter
>certainly would be good for international applications!)

There have been several coding schemes used on the -8 over the years:

OS/8 used 8-bit characters packed three into two adjacent 12-bit words.  This
24-bit scheme is repeated as necessary.  Standard file format is line 
terminator is CR and LF, and a ^Z at the end.  The high-bit is to be stripped
as it can't be trusted.  This is not a limitation of the O/S, rather of the
typical appliation programs.

There exists an alternate set of utilities that use an alternate set of
conventions where ^A is used as a terminator, and it consists of an
editor, a text processor, and an assembler.  You are virtually forced to
consider them a set, although it's fairly easy to mostly convert back and
forth from these utilities from DISC Systems to DEC's standard CUSP's.

If the files are binary, then of course the data is 8-bit, but in a format
that uses the same packing scheme as for ASCII text, except that the data is
the same as the original paper-tape 8-bit frames.  Only the loader and
related utilities understand this underlying format.  Other utilities use
their own formats, since the only requirement is that the data is
representable as contiguous blocks of 12-bit words.  Memory-image files
are essentially just that, with the exception of a header block that
indicates loading instructions for the rest of the file.

The directory entries are in six-bit subset ASCII, since the file names are
caseless.

There have also been other encoding schemes: a six-bit code can be used for
7-bit ASCII where one code is reserved as a case shift.  This is how the
internal coding of FOCAL, 1969 is performed, as well as the old OS/8
editor which is a hacked-up version of the original paper-tape editor.  The
notion is that case shifting happens infrequently, so you are accepting the
tradeoff that it is high overhead.  There are two variants: the case is
either transient, or it is locking and a flip-flop.  Either method has
advantages and disadvantages depending on application.  The method chosen for
these programs for their internal operation is the transient form.  On
file operations to the O/S, they convert from their internal format to the
OS/8 7-bit format.

Some systems have been written for pure upper-case languages.  In this case,
the format is six-bit ASCII, which in turn comes in two flavors: ASCII-40
and ASCII&77.  The first tends to "invert" the character codes, and the
second tends to keep the same values, at least for half of the codes, 
and the other half is still reminiscent of the original value.  Either
can be easily converted back to the original 7-bit form.

WPS-8 uses an 8-bit character code, where the high-bit is used to initiate
various extensions to the basic ASCII text characters.  Some functions
implemented are embolden delimiters, underline delimiters, ruler definition
delimiters, soft-return, etc.

Character codes for the VT8E are 12-bit codes, since you have to include
the character attribute bits.  This is a DMA device, and programming it
is similar to, and a forerunner of the typical micro video interface, where
you poke at memory to create the screen you see.  In fact, I once wrote a
terminal emulator for the VT8E.  Since it is intrinsically a 6-bit-only
device, I simulated case by bolding the upper-case only.  There exists a
TECO implementation for this hardware that does precisely this, and <ESC>
chars are displayed as bold "$" chars, etc.  Due to the high DMA rate,
the screen updates are equivalent to a serial baud rate of approx. 3/4 
MegaBaud.

Since the file systems impose no restrictions other than 12-bit representation,
it is possible to use 12-bit chars, or 24-bit chars, or even 36-bit or 48-bit
chars.  As is possible on any other machine, there is no real limit, just that
there is a granularity at some level of 12-bits.  On the PDP-10, the same
principle applies, except this level of granularity is 36 bits/word.

There are so many 8-bit-byte-oriented systems today, that most people have
simply lost track of how to pack words with character codes, usually taken
from smaller sets than the word size.

Simple co-routines are used to do this packing and unpacking which run
quite efficiently both of speed and size.

Some custom applications have been written for PDP-8's in the typesetting
world.  They tend to use specialized 6, 7, or 8-bit codes, packed as
necessary into the host O/S's 12-bit format, but they are hardly similar to
ASCII.  I have written programs to deal with "ANPA ASCII" which is a severely
modified code based partially on ASCII with some extensions added from
the type-setting world (and some curious deletions!).  Since it is expressable
in 8-bit, I just packed it in the standard way: three chars in 2 12-bit words.

Note that all disk blocks are even-word sizes.  This means that there is
no waste in storing the characters into the blocks, although the 8-bit
character count is an even multiple of 3.  OS/8 standard would be 384
chars/block since the blocks are 256 12-bit words.  (There are 128 pairs
of words or 128 triple 8-bit bytes.)

cjl