Subject: PDP-8 VM? (Re: Was [tn]roff really first written in assembler?)
From: [email-masked] (Ignatios Souvatzis)
To: [email-masked]
Date: Tue, 1 Oct 91 19:17:43 +0100

Date: Tue, 1 Oct 91 19:17:43 +0100
From: [email-masked] (Ignatios Souvatzis)
To: [email-masked]
In-Reply-To: [email-masked]'s message of 26 Sep 91 13:04:05 GMT
Subject: PDP-8 VM? (Re: Was [tn]roff really first written in assembler?)
Reply-To: [email-masked]
Return-Receipt-To: [email-masked]
X-Mailer: GNU Emacs 18.51.0
X-Face: #rB\(f0m-qD2bY_7cpmZ003p,.l7>l`p}-q43!):$O(uULZbza}e&4,:u->2+c;hF`R[4bO
 ed'#>RHkOj9)lR>|Q~s5]r,HaF}DPNgWP:\C;{2b%\()YWy#HYY-5e."ZQgvy]d;h{jrC>!F>2V_IX
 Jv+W12\ivy]

Forwarded from alt.folklore.computers (please answer there, too, if
you can):

   From: [email-masked] (Bruce M. Walker)
   Newsgroups: alt.folklore.computers
   Date: 26 Sep 91 13:04:05 GMT
   Distribution: alt
   Organization: ISG Technologies Inc., Mississauga Ontario

   In article <[email-masked]>
   [email-masked] (R. Kym Horsell) writes:

   > Another product that _may_ be related was a real TYPESETTING
   > system about the same era used by one of the local rags. 
   > I _think_ it was a DEC-supported (at least DEC-Oz) product.
   > 
   > It ran to 250K instructions and was written for a PDP8.  In
		    ~~~~~~~~~~~~
   > assembler.  God knows how the hardware managed the address space!?...

   Now there's some folklore you don't see every day!  That must have been
   some trick; the PDP8 with the (KM8?) memory extension could manage 32K
   words (12 bit, for those not up on -8isms) *max*.  You could get a hard
   disk for it at one point (800K maybe, tops?), but I never heard of any
   virtual memory versions of TSS-8 or OS/8.

   Now I could believe 250K lines of assembler . . .

Paper mail: Ignatios Souvatzis, Radioastronomisches Institut der 
            Universitaet Bonn, Auf dem Huegel 71, D-5300 Bonn 1, FRG
Internet:   [email-masked]
            [email-masked]

"Achtung!

  Es freut uns, so gute Displaysoftware installiert zu haben, dass einige
  Benutzer den Unterschied zwischen dem Bild auf einem Monitor und einem Blatt
  Papier uebersehen. Benutzer, die Marken mit Kugelschreiber auf dem Monitor
  machen, werden gebeten, darauf zu achten, dass Monitore sich schlecht wie
  Papier behandeln lassen, sich also weder fuer das Abheften, noch Knicken
  eignen. Die Korrektur von Tipfehlern mit Tipp-Ex sollte schon aufgrund der
  Schaedlichkeit dieser Korrekturfluessigkeit vermieden werden."

Date: Tue, 1 Oct 91 21:45:53 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: PDP-8 program size, etc.

Date: Tue, 1 Oct 91 21:45:53 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: PDP-8 program size, etc.

    In regard  to the recent query about PDP-8 program size, I believe
the author is referring  to TYPESET-8, which runs on 32K PDP-8 systems.
I don't believe it is  250K instructions, but perhaps with all utilities
counted it could be a piece of that.

    It is not necessary to have a large address space for programs to be
large, nor is it necessary to have the "crutch" of virtual memory, which
is merely a lazy man's mechanism to simulate the space when it really
isn't there.

    Many programs have seldom needed sections which can be dynamically
loaded when necessary.  As long as a suitably large area is reserved for
loading the largest item, it is a favorable tradeoff to load these
portions on a demand basis.  LRU algorithms can even be applied to avoid
redundant disk access where applicable, etc.

    Often, data can be handled on a virtual basis by relatively small
programs.  Use of this method guarantees no significent upper bound on
the process, as the only changes involve allocating more disk space for
the data.

    By careful design, programs can avoid significent overhead
associated with the typical sloppy usage of virtual memory.  PDP-8
programs don't have the luxury of being sloppy, so are often efficient
by default.  This is over and above the inherent avantage of the
efficiency of the PDP-8 instruction set, which makes 4K-16K programs a
practicality where competing systems often require over four times as
much memory.  This can often be amplified by the presence of large
ROM-based systems and RAM-based system kernels that must also be loaded
for the proper operation of the program.  Contrast this with the P?S/8
residency requirement of 128 words and the OS/8 equivalent of 256 words.
These systems run often miniscule programs of only a few groups of 128
words to produce useful results.  Total system memory requirement may be
as little as 4K-8K words total, with an upper limit of 32K.

    BTW, PDP-8s have an upper limit of 32K, but PDP-8/a systems support
two memory extensions:

    The KT8A raises the limit to 128K using -8/a memory boards made by
DEC, CESI, and possibly other vendors.

    The MEC8 from CESI has two operating modes: KT8A hardware compatible
(but *not* software compatible) and MEC8-only mode, which requires CESI
memory boards strapped for the MEC8-only mode, and of course special
software.  The software is a superset of the MEC8 software to control
the MEC8 in KT8A-compatible mode.

    Over the years, other proposed schemes have appeared, some
experimentally implemented.  One scheme involved defining a window into
an alternate memory space with no built-in upper limit.  This is
analogous to the current PC expanded memory implementations.  The PDP-8
version was discussed in the early '70s.

    Someone suggested segmented memory, where the program must maintain
a smaller address space than PDP-8 normal restrictions, but a mechanism
exists to map segments from a larger space.  For example, the PDP-8
address space could be split into four quadrants of 1K each.  Then the
memory mapper could define which 1K from a larger space responded to
addresses in each segment.  I don't believe this method was ever
implemented, but it could be done given a processor redesign.

cjl

To: [email-masked]
Subject: PDP-8e up for grabs
Date: Tue, 15 Oct 91 08:31:41 PDT
From: [email-masked]

To: [email-masked]
Subject: PDP-8e up for grabs
Date: Tue, 15 Oct 91 08:31:41 PDT
From: [email-masked]

Due to some pretty major upheavals in my professional life, I am
looking at having to relocate.  I have a DEC Lab-8e, and have found that
I'm probably never going to find time to give it the care and attention
it wants.  Thus, I'm hoping to find a new home for my '8, and this seems
to be the best place to post!

It's a DEC Lab-8e with a third-party floppy drive subsystem (two 8" drives).
I'm told that it was working when deinstalled, and it appears physically
complete.  There are ~8 serial cables, all snipped off hanging out of
the box.  There are also some mysterious power-supply type items which
I received with it, though their relationship to the rest of the beast
is less than clear.

The real point here is not to make a lot of money for myself, but to
find a good home where this machine can be brought back to life.  I'd
just like to break even on this for myself.  I believe I paid $250 for
this box, so I'm looking for an offer around there, plus shipping.  If
someone's local enough that they can pick it up and save shipping, so much
the better for me!

E-mail should reach me here for the time being, but you can also call me
at (503)246-6321 evenings.  If that goes away too, you can leave a message
for my care of my folks at (408)427-0789.

					Thanks,
					Andy Valencia
					[email-masked]

Summary-line: 11-Oct    [email-masked]  #M993
Date: Fri, 11 Oct 91 23:22:34 EDT
From: [email-masked]
To: [email-masked]
Subject: M993

Date: Fri, 11 Oct 91 23:22:34 EDT
From: [email-masked]
To: [email-masked]
Subject: M993

I have a question for anyone who has a working RK8E/RK05 system:

I got an RK8E a while ago, and I have two RK05's from a PDP-11 system.
I've been looking for the cable/board assembly, M993, but all the usual
used places that never let me down don't have it, so I got tired of
phoning around and called DEC.  They took my money ($109!!!) and then
the cretinous slimebags sent me the M993 module with no cables.
What I need to know is:

1. How the cables are oriented on the M993 (the board which plugs into
the RK05).  With the board right side up in front of you, do the cables
come out of the right or left side of the connector blocks?  (or one
of each?)

2. Which way do the 40-pin berg connectors mount onto the other end of
the cables (I'm having trouble visualizing whether it matters).
With the board lying face up and the cable stretched flat across the
floor, will the connectors point up or down (or one of each)?

3. Which cable is which when it reaches the RK8E?  And do they plug
in with the cable against the board or away from it?

4. How long are these cables normally?  Is there some standard length,
or some maximum length which I shouldn't exceed, or whatever?

Also, does anyone know where to get 16-sector packs, cheap?

Thanks,   [email-masked]

Date: Fri, 18 Oct 91 18:31:01 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]

Date: Fri, 18 Oct 91 18:31:01 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]

From: Charles Lasner <[email-masked]>
To: [email-masked]
Cc: lasner
Subject: Announcement of additional KERMIT-12 utilities.

From:	Charles Lasner ([email-masked])
To:	PDP-8 Lovers everywhere
Subj:	Announcement of additional utilities for KERMIT-12

    While no changes have been made to the body of KERMIT-12 itself,
several things have been changed/added.

    At the request of the KERMIT distribution service (KERMSRV) certain
files have been slightly modified so they are acceptable to that bitnet,
etc. facility.  (Seems to be a problem with LRECL>80.) All files are now
80 or less.  Except for the .DOC file, all it took was a little
"cosmetic surgery" on a few lines.  FTP'd copies are mostly unaffected.
Most of the problems have to do with interpretation of the inter-page FF
character being treated as the first character of the "record" in this
non-stream-oriented system.

    At this time there is no actual doc file, as the file K12MIT.DOC is
merely a truncation of the listing of K12MIT.PAL as passed through PAL8
and CREF.  Anyone with a system big enough to support a 200+K long
source file can create this file themselves.  In addition, due to
certain quirks within PAL8 and CREF "beating" against unix line
conventions, the file K12MIT.DOC at watsun.cc.columbia.edu was slightly
different from the precise output of the assembly process, but again,
only a cosmetic change.

    Since this file greatly exceeded the KERMSRV restriction, it has
been withdrawn in favor of the source fragment equivalent to it taken
directly from K12MIT.PAL.  This source fragment is short enough that
even an RX01-based OS/8 system can create the listing file from it thus
recreating the original K12MIT.DOC locally.  All this will disappear in
the future when a "proper" doc file appears.  In the meantime,
K12MIT.DOC in whatever form it is available contains hardware hints and
kinks, assembly options, and other info useful to users and anyone
interested in the "innards" of the program, as well as an edit history
of how K12MIT got to be where it is now starting from its "grandfather"
K08MIT.  It ends at the first line of the code in K12MIT.PAL, but
includes all of the special purpose definitions particular to the
various devices supported, such as DECmate I, DECmate II, etc.  Any
changes to customize KERMIT-12 are still accomplished using the separate
patch file K12PCH.PAL which is unchanged.

    New files cover two areas: 1) direct loading without KERMIT-12, and
2) .BOO format support.

1)  Many users have the hardware for running KERMIT-12, but don't
already have it or another suitable program to acquire it yet, a real
"catch-22" situation.  Towards that end, a set of utilities has been
provided to directly load KERMIT-12 without already having it.

    Most PDP-8 sites do have access to some other machine.  Hopefully,
the serial connection to be used is fairly "clean" and error-free, or at
least some of the time.  These programs depend on this fact.  This could
either be a connection to a remote multi-user system or something like a
null-modem connection to a nearby IBM-PC.  The programs assume only a
few things:

    a)  The connection is error free.

    b)  The other end doesn't absolutely require anything be sent to it
        to send data to the PDP-8 end.  (The -8 end will not send ^S/^Q
        or anything like that because this is unnecessary; all data goes
        only into PDP-8 memory directly.)

    c)  The other end will send the data at a time controlled from its
        end, or after at most one character sent from the PDP-8 end of
        the link.

    The first situation is illustrated by the example of a PC connected
to the -8.  The -8 program is started, and it waits indefinitely after
the -8 user presses any one key.  (The corresponding character is sent
to the PC where it is ignored.)  The PC end is initiated with a command
such as COPY K12FL0.IPL AUX: and the data goes to the -8.

    The second situation is illustrated by a remote system where a
command such as TYPE K12FL0.IPL is available.  The delimiting CR is not
typed at this time, and will be finished later by the loading program.
The initial connection up until the TYPE command is not covered by the
loading program itself, so the user must supply a basic comm program,
which is possible to accomplish in about 10 words or less if the rates
are "favorable", or worst-case, a terminal can be used and the line
switched over to the -8 at the appropriate time.  In any case, CR or
other appropriate character is hit on the -8 and the loading program
echoes it down the line (and on the console) to initiate the data
down-load.

    d)  The other end is assumed to send the file verbatim without
        insertion of <del> characters (octal 177) and
        upper-case/lower-case is preserved.

    If all of these assumptions are met, then the down-load accomplishs
a partial acquisition of K12MIT.SV, the primary binary file of
KERMIT-12.  The process must be repeated several times to acquire all
portions.  If a local compare utility is available that can compare
absolute binary files, perhaps the process can be totally repeated to
assure reliable results by comparing runs.

    The method used is borrowed from the field-service use of a
medium-speed serial port reader on the -8 for diagnostic read-in.  This
reader is *almost* compatible with the device 01 reader such as the
PC8E.  The difference is that the *real* PC8E is fully asynchronous,
whereas the portable reader just spews out the characters without any
protocol.  The PC8E can't drop any characters in theory, although there
are reports of misadjusted readers that drop characters at certain
crucial data rates.  (The PC8E runs at full speed if possible, and
failing this falls back to a much slower speed.  All operations depend
on the use of the hardware handshakes of the IOTs etc., so nothing
should be lost but throughput.  Misadjusted readers may drop characters
when switching over to the slower mode.)

    The reason the field reader is acceptable is that it is used only to
load diagnostics directly into memory using the RIM and BIN loaders.
These minimal applications can't possibly fall behind the reader running
at full speed.  This is the same principle used here to down-load
KERMIT-12.

    The loading program is a 46 word long program suitable to be toggled
into ODT and saved as a small core-image program.  The user starts the
program and then (at the appropriate time) presses one key (usually CR
if it matters) and the loader waits for remote input.  As the other end
sends the data, it is directly loaded into memory.  There is a
leader/trailer convention, just like paper-tape binary, so at
end-of-load the program exits to OS/8 at 07600.  At this time the user
issues a SAVE command.  This completes the down-load of a single field
of K12MIT.SV.

    At the current time, there are actually two fields of K12MIT.SV,
namely 00000-07577 and 10000-17577, and there are two such loaders.
There is no check for proper field, so the proper loader must be used
with the proper data, else the fields will get cross-loaded and will
certainly fail.

    Once the two fields are obtained as separate .SV files (named
FIELD0.SV and FIELD1.SV) they can be combined using ABSLDR.SV with the
/I switch (image mode) set.  The resultant can be saved as K12MIT.SV.
This, if all went well, is identical in every way to the distributed
K12MIT.SV (which is only distributed in encoded form; see below).

    Actual file differences will only exist in the extraneous portions
of the file representing the header block past all useful information
and the artifacts of loading which represent 07600-07777 and 17600-17777
which are not used.  This is the normal case for any OS/8 system when
any file is saved.  Merely saving an image twice will cause this to
happen.  At this point, K12MIT.SV can be used as intended, namely to
acquire, via KERMIT protocol, the entire release.  It is recommended
that this provisional copy of K12MIT.SV be abandoned as soon as the
encoded copy is decoded since the encoding process provides some
assurances of valid data (using checksumming, etc.).

    This process can be accomplished on any KL-style -8 interface
including PT08, etc., or on the printer port of VT-78 and all DECmates.
When used on the DECmates, there may be some minor problems associated
with the down-load which may have to be done as the first use of the
printer port after power-on, or some other restriction.  The loader
includes a suggested instruction for DECmate use if problematic (and
raises the program length to 47 words).  Also, due to observed bugs in
the operating system (OS/278 only), there are restrictions on the use of
ABSLDR.SV that cause certain command forms to fail while other seemingly
equivalent forms succeed!  This is documented in the latest K12MIT.BWR
file in the distribution.  The command form stated in the K12IPL.PAL
file is the only known form that works correctly on these flawed
systems.

    The format for down-load files is known as .IPL or Initial Program
Load format.  It consists of a leader containing only lower-case letters
(code 141-177 only) followed by "printable" data in the range 041 (!)
through 140 (`).  Each of the characters represents six bits of data, to
be read left to right as pairs, which load into PDP-8 12-bit memory.
The implied loading address is always to start at 0000 of the implied
field.  The leader comment contains documentation of which field of data
from K12MIT.SV it is.  The trailer consists of one lower-case character
followed by anything at all.  This is why it is crucial that DEL (177)
not appear anywhere in the body of the file.

    Throughout the file, all codes 040 or less are ignored.  This allows
for spaces in the lower-case leader for better readability, and for
CR/LF throughout the entire file.  CR/LF is added every 32 words (64
characters) to satisfy cetain other systems' requirements.  The trailer
contains documentation on a suggested SAVE command for the particular
data just obtained.

2)  PDP-8 ENCODE format is the format of choice to obtain binary OS/8
image files because of the validation techniques employed, etc.  This is
the standard method of distributing K12MIT.SV as well as other
"critical" files such as TECO macros and other image files.  In the
MS-DOS world there exists another very popular format known as .BOO
encoding.  It would be useful to support this format on the PDP-8 as
well.

    .BOO format files are smaller because they use six-bit encoding
instead of five-bit encoding, or at least in theory.  Both ENCODE and
.BOO use repeat compression techniques, but ENCODE can compress 12-bit
words of any value, while .BOO only compresses zeroes and that itself is
based on a byte-order view of the data.  PDP-8 programs often include
large regions of non-zero words such as 7402 (HLT) which would not
compress when looked at as bytes.  Such files would show compression
rations quite different from the norm.

    In any case, .BOO format is useful on the PDP-8 because it allows
inter-change with .BOO files created on other systems, such as PCs.
This allows the exchange of unusually formatted files, such as TECO
macros between PDP-8s and PCs.  (Both systems support a viable version
of TECO.)

    The new KERMIT-12 utilities include a .BOO encoder and .BOO decoder,
known as K12ENB.PAL (or ENBOO.PAL) and K12DEB.PAL (or DEBOO.PAL)
respectively.  They use .BOO encoded files unpacked in the standard OS/8
"3 for 2" order to preserve the original byte contents when the files
originate from other systems.  (Technically, .BOO format doesn't require
this, but the obvious advantages dictate it.  Anything encoded into .BOO
format must merely have a 24-bit data structure encoded into four
six-bit characters, so in theory any encoding of two adjacent PDP-8
12-bit words would be acceptable.  By additionally supplying the bits in
OS/8 pack/unpack order guarantees the inter-system compatibility as
well.)

    There is an inherent weakness in the original .BOO format which must
be addressed.  .BOO format files always end on one of two data fields:
either a repeat-zero compression field, or on a 24-bit field expressed
as four characters.  Should the data in a 24-bit field consist of only
two or even one bytes, there are one or two extraneous null bytes
encoded into the field to complete it.

    Presumably the need to add the extra bytes is to allow validation of
the format.  In any case, only the encoder knows just how many (0, 1, 2)
bytes are extraneous.  We can presume that if the last byte is non-zero,
it is significant.  If the last two are both zero, then the last or
possibly both are extraneous with no way to tell.

    On PC systems, the general trend is to ignore these one or two extra
bytes because so far there haven't been any complaints of failure.  I
have personally discovered that a widely used PC .BOO encoding program
(written in C) erroneously adds two null bytes as a short compression
field beyond the data!  This is not a .BOO format issue, but rather a
genuine program bug.  Apparently few PC users are concerned that
encoding their files prevents transparent delivery to the other end.

    In the OS/8 world, the situation is quite different.  Each OS/8
record is 256 words or 384 bytes.  If even a single byte is added, this
creates an additional all-zeroes record.  Besides wasting space, it is
conceivable that such a file could be dangerous to use under OS/8
depending on content.  (Certain files, such as .HN files are partially
identified by their length.  File damage, such as lengthening a file
from two to three records will confuse the SET utility, etc.)  Many
files cannot be identified as having been artifically lengthened (and
may be hard to shorten!), so this must be avoided.

    I have invented a fix for the problem: repeat compression fields are
expressed as ~ followed by a count.  2 means two null bytes and is thus
the smallest "useful" field to be found.  (It takes two characters to
express what would take 2-2/3 characters in encoded format.  One null
would only take 1-1/3 characters, not two, so this case is vestigial,
but must be supported for the benefit of brain-dead decoders.) The value
of 0 means a count of literally zero, thus ~0 is a "NOP" to a decoder.
I have successfully tested MS-DOS programs written in BASIC and C that
decode .BOO files successfully even if ~0 is appended to the end with no
ill effects.  (They correctly ignored the appended fields.)

    In my encoding scheme, ~0 at the end of a data field containing
trailing zeroes means to "take back" a null byte. ~0~0 means to take
back two null bytes.  Thus files encoded with ENBOO.PAL either end in a
repeat-compression field as before, or in a data encoding field possibly
followed by ~0 or ~0~0 if necessary.  The corresponding DEBOO.PAL
correctly decodes such files perfectly.

    Should files encoded with ENBOO reach "foreign" systems, they will
do what they always do, i.e., make files one or two bytes too long
occasionally, with no other ill effects.  Files originating from such
systems will certainly be lacking any trailing correction fields and
will cause DEBOO to perform as foolishly as MSBPCT.  Extraneous null
bytes will appear at the end of the file in OS/8 just as in MS-DOS in
this case.  (Note that if the file length is not a multiple of 384
bytes, additional bytes are added by DEBOO as well, but this is not a
design weakness of .BOO format.  It is caused by the clash of fixed
record size and a variable size format.)

    Hopefully, files originating on OS/8 will be decoded on OS/8 as
well, thus preserving file lengths.  Most "foreign" files will probably
be ASCII, so the ^Z convention will allow removal of trailing null bytes
at either end.  It is hoped that MS-DOS and other systems "upgrade"
their .BOO format files to be compatible with the PDP-8 version.

    All KERMIT-12 files are available via the normal distribution
"paths" of anonymous FTP and/or KERMSRV.  The user is directed to the
file /ftp/pub/kermit/d/k12mit.dsk as a "roadmap" to the entire
distribution.  Each .PAL file includes assembly instructions.  Most use
non-default option switches and non-default loading and saving
instructions, so each must be carefully read.  The development support
files (TECO macro, .IPL generator, recent copies of PAL8, CREF, etc.)
are included in the total collection.  Development is not possible on
RX01 systems due to inadequate disk space, but RX02's are barely
adequate with a lot of disk exchanges.  (Future versions may require
larger disks for development.)

Charles Lasner ([email-masked])