ftp.update.uu.se/ftp.update.uu.se.2014.03.zip/ftp.update.uu.se/pub/decmate/dmpt1

Text File | 1995-05-03 | 11KB | 200 lines

Subject: Why a DECmate isn't a PDP-8
From : [e-mail] (Charles Lasner)
Date: Mon, 1 Mar 1993 18:39:56 GMT

This newsgroup is primarily for PDP-8 family stuff, and will therefore support
DECmates as well.  But a DECmate isn't *quite* a PDP-8 as we know it.  Certain
problems thwart the prevailing software from running on it, and instead some
"bastardized" versions have appeared (such as OS/278).  This will be the
first in a series of articles to detail the areas of incompatibilty and
what can be done about them.

1)    CPU issues.

    The DECmate is based on the 6120 micro version of the PDP-8.  It is
mostly compatible, and includes the powerful extension of CP memory and
related hardware, dual push-down stacks, etc.  Certain instructions have
minor differences such as the exact definitions of the PDP-8/e-originating
superset instructions GTF and RTF.  The differences are so slight that the
existing software for PDP-8/e interrupt handling will just work, but certain
diagnostic programs will likely fail on these specific points.  There are
differences such as:

PDP-8/e RTF does not clear the AC afterwards; 6120 does.  This is even a
useful improvement as there is no software reason not to clear the AC at
that point.  (The AC is being loaded from a temporary to restore the former
status saved during an interrupt.  Then the AC has to be loaded with the
former AC value, thus a CLA after RTF is in all practical 8/e code.  The
RTF performing its own clear thus allows a 6120-only interrupt handler that
is shorter/faster.)

PDP-8/e GTF reads back the state of interrupt into bit[4].  PDP-8/e RTF
ignores bit[4] and re-enables the interrupt.  6120 GTF reads back a one into
bit[4].  6120 RTF loads interrupt enable per AC[4].  For normal interrupt
handling for PDP-8/e, this sequence is essentially compatible enough.  Note
that classic PDP-8 interrupt handling is totally compatible on all models,
but that there are PDP-8/e and newer interrupt routines, etc.

The use of extended memory instructions on the PDP-8/e is compatible with
former processors, but can be extended via the KT8A or CESI MEC8 extensions.
The 6120 is only compatible with the subset found on the PDP-8/e without
those extensions because other instructions have been assigned to the same
IOTs.  These include new instructions such as GCF (Get Current Fields) which
is essentially the non-interrupt-oriented version of GTF, etc., and a set of
instructions only valid in CP memory to handle that section.  Some of the
instructions are defined for CP memory trap, and others are for manipulating
the built-in dual stack.

As long as the program sticks to the compatible subset found in a 32K PDP-8/e,
the instructions are otherwise compatible.

2)    Console issues.

    On I/O, the 6120 largely parts company with the PDP-8/e.  The actual
implementation of I/O on the DECmate consists of using packaged interfaces
usually called "pie" chips (or Programmed Interface Elements).  The problem
with these chips is that they are only *almost* compatible with existing
PDP-8 interfaces whereas the prevailing OSes demand *total* compatibility
with the older hardware.  There are several internal interfaces within the
DECmate for particular use of no concern to the OS, and this is not at issue,
such as the internal interface for the keyboard which is actually on an
additional serial port (bidirectionally) or the APU/XPU interface, etc.

PDP-8 compatibility demands that the device 03/04 instructions be truly
compatible.  On the 6121 PIE chip, liberties were taken with the design that
cause out-and-out incompatibility such that only trivial programming examples
still work, while the actual usage within the operating system is totally
incompatible.  A breakdown of the console instructions:

6030    Clear the keyboard flag, do not advance the reader if a TTY: is the
    console device, do not clear the AC.  The 6120 version of this is to
    *set* the flag!  (This instruction is not used on earlier models, so
    compatibility issues aren't as bad as it sounds!)

6031    Skip on the keyboard flag.  Notably, the PDP-8 convention is that
    this instruction work *precisely* as stated.  Specifically, 6031
    must skip if the flag is set.  Repeating the instruction must repeat
    the same effect.  On the 6120, 6031 executes as skip on *and clear*
    the flag, thus 6031 when repeated is totally incompatible, because
    the flag won't raise until the data is read.  PDP-8 OS compatibility
    demands that the 6031 repeat facility be present.  Without this,
    various programs, handlers, and all BATCH operations are incompatible.
    OS/278 consists of a bunch of wimpy emasculated versions of cusps that
    either don't work properly, have existing bugs to be fixed, or kludges
    to create the perception of ^C and/or ^S/^Q handling being present
    correctly, but in point of fact, it is 100% deficient in this area.
    When OS/278 is run on an actual PDP-8, it behaves as poorly since it
    can't take advantage of the proper console interface, instead sticking
    to the subset where 6031 cannot skip repeatedly, etc.

6032    Clear the AC, advance reader run if a TTY: console, clear the keyboard
    flag.  On the 6120, 6032 merely clears the AC.  Since 6031 clears the
    flag, they didn't bother to make 6032 accomplish it.  However, 6032 on
    the 6120 will allow the flag to raise for the *next* character since
    the interface is both buffered and simulated.  Due to hardware
    limitations of the DECmate, it is not possible to re-implement the
    simulated console interface any better than currently provided.  The
    base reason for this is that only the "even" IOT's are trapped and
    emulated while the "odd" IOT's are allowed to be used in hardware.  Had
    the entire interface been trapped, we could emulate the compatible
    version!

6033    NOP  This IOT is essentially reserved for situations where the
    interface baud rate could be programmed, but doesn't apply in the case
    of either the PDP-8 or the DECmate.

6034    Read the latest character, do not disturb the flag.  The data is
    logically ORed into the AC.  This is used to notice that the data
    is a ^C or other character without disturbing the flag, so that other
    software can check it again, after being swapped in.  (It's used in
    conjunction with 6031 which doesn't clear the flag when it skips.)  The
    6120 version of this instruction is to OR into the AC the *previously
    read* character provided by either 6032 or 6036, but it cannot initiate
    a new character by itself.  While it is of marginal utility to be able
    to re-read a previously read character, the inability to read in the
    latest character without disturbing the flag is the crux of the
    compatibility issue.

6035    Load interrupt enable for devices 03/04 per AC[11].  On the 6120 this
    is changed to device 03 only.  The 04 function is handled by 6045.
    Since this is a PDP-8/e instruction, it is not a serious compatibility
    issue except for initialization routines that use interrupts.  However,
    since the keyboard is emulated on the DECmate, interrupt timings may
    prove "choppy" compared to a real PDP-8, and interrupts to the console
    are not recommended.

6036    LOAD the AC with the latest character and clear the flag.  Also enable
    reader run if the console is a TTY:.  Essentially this is the OR of
    6032 and 6034.  The 6120 still ORs together the two operations, but
    the underlying two operations aren't compatible, since the flag is
    unaffected.  However, reading the character will cause the next
    character's flag to raise (when available).  If 6032 or 6036 is not
    executed, then the flag will *never* raise even if the user pounds on
    the keyboard!  (There is an OS/278 ODT bug related to this which is
    fixable per se, but not the ^C handling as described above.)

6037    NOP

6040    Set the output flag.  Actually compatible on 6120!  (And not needed
    for compatibility with earlier machines that didn't have it.)

6041    Skip on output flag.  Like the input flag, the 6120 also clears the
    flag when issuing 6041.  There is less of a compatiblilty issue since
    it is possible to write code that doesn't depend on the second skip,
    as long as you time out the flag in any initialization code.  (P?S/8
    has always done this in the past; OS/8 tends to not overlap the
    console I/O so therefore the skip on flag gets checked after outputting
    not before, so this is good enough for most routines.)

6042    Clear the output flag.  On the 6120 it clears the AC.  Usually the
    AC contents is unimportant during 6042, so not a serious compatibility
    issue, but diagnostics will fail.

6043    NOP

6044    Output the character, do not clear the flag.  Same on 6120, but since
    the output routine is emulated, the flag will immediately be up when
    the program is running after the trap.  On a real PDP-8, the flag
    comes up one character time later after it's actually sent, not
    immediately.  This could affect some interrupt routines.  Again,
    interrupt handling of the console is not recommended on the DECmate,
    especially on the output side.

6045    On the PDP-8/e, this is skip on input OR output flag raised AND
    interrupt enable in the device.  Useful to cause interrupt polling
    routines that have to favor other devices to have less overhead.  If
    the device actually has the flag raised, then you have to do a few
    extra instructions, but when the interrupt is elsewhere, it lowers
    the latency.  On the 6120, this is replaced with load interrupt
    enable for device 04 only per AC[11].  Since this is an extension
    beyond the basic interface, this is a compatibility issue for
    interrupt-driven PDP-8/e and newer routines only.

6046    Output the character and clear the flag now, causing it to raise
    later.  On the 6120, the instruction is trapped, so the net result
    is to raise the flag when the trap handling is over and execution
    resumes.  Causes interrupt routines to always be entered and no
    background processing to occur during the simulated interrupt
    handling, which is not recommended.  Non-interrupt programming is
    not affected by this aspect of compatibility however.

6047    NOP

So, in summary, console handling is severely incompatible with regard to
keyboard handling, and moderately incompatible for screen handling, most
notably in regard to either flag initialization and/or interrupt handling.
Yet, simple-minded examples from Introduction to Programming will more-or-less
work; "live" OS routines cannot work.  I am working on a replacement system
to be known as OS/8 Version 5, which will work within the available subset
and thus will run on all models.  However, existing OS/8 cannot work on the
DECmates, and OS/278 cannot perform many functions found in OS/8.

Next time, more info on other compatibility issues.

cjl