Subject: Why a DECmate isn't a PDP-8
From : lasner@watsun.cc.columbia.edu (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





