From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Why a DECmate isn't a PDP-8
Date: Sun, 7 Mar 1993 03:05:55 GMT

This is the second in a series of posts about why the DECmate series of
small computers is not quite what we know as a PDP-8.  Part one dealt with
the few minor CPU issues and detailed the significent differences in the
console interfaces between all PDP-8 (and VT-78) models and the DECmates.

2a)	Consequences of the console problems and what to do about them.

	Since the console interface is hopelessly "mangled" we have to learn
to live with it.  Existing PDP-8 programs designed for the various OSes will
have to be either supported as is or be changed for DECmate and PDP-8 use.

P?S/8 has already undergone a console "overhaul" such that all system programs
can now be run on any model of PDP-8, VT-78, PDP-12, or DECmate.  (The family
of 8 rule applied to P?S/8 as well as OS/8, thus neither will run on a PDP-5
or PDP-8/s.)  To accomplish a compatible console interface compromise, the
following rules were laid down:

	If a program is meant to strictly run on a PDP-8 or VT-78 only, then
it can assume the old-style console interface exists.  Thus, *only* on a PDP-8
can the following code or equivalent be used:

	KSF			/FLAG UP?
	JMP	NOT		/FORGET IT
	KRS			/READ IT IN NOW; DON'T DISTURB THE FLAG
	AND	(177)		/GET RID OF PARITY BIT
	TAD	(-3)		/COMPARE TO ^C
	SZA CLA			/SKIP IF IT MATCHES
	JMP	CLRIT		/JUMP IF OTHER
/	DO WHAT'S NEEDED HERE, SUCH AS SET THE DF TO 00, ETC.
	JMP I	(7600)		/KEYBOARD MONITOR WILL NOTICE THE ^C

CLRIT,	KCC			/CLEAR THE FLAG WE NOTICED ON OTHER THAN ^C
NOT,	CLA			/CONTINUE PROCESSING; NO ^C PRESSED

This code is applicable to OS/8 and P?S/8, but only on PDP-8's, not DECmates.
The changes to the keyboard monitor of either system has to still include the
check for ^C by noticing the KSF skips, execute KRB and check if the character
is ^C and take the appropriate action, etc.

Note that the pre-DECmate P?S/8 and all pre-V4 OS/8 family systems essentially
worked this way, etc.

To function on the DECmate, P?S/8 was modified so that there is a new system
concept: the "soft ^C" bit.  In this specific case, it was defined as bit[11]
of the memory size word in 007611 to facilitate being set with an ISZ
instruction, etc.  Here is a reworked piece of code that can function only
on the newly reworked P?S/8 system:

	KSF			/FLAG UP?
	JMP	NOT		/FORGET IT
	KRB			/WE MUST READ THE CHARACTER IN
	AND	(177)		/GET RID OF PARITY BIT
	TAD	(-3)		/COMPARE TO ^C
	SZA CLA			/SKIP IF IT MATCHES
	JMP	NOT		/JUMP IF OTHER
/	DO WHAT'S NEEDED HERE, SUCH AS SET THE DF TO 00, ETC.
	ISZ I	(7611)		/SET THE "^C WAS HIT" BIT
	JMP I	(7600)		/KEYBOARD MONITOR WILL NOTICE THE ^C

The keyboard monitor in this case won't have a skipping KSF, but since it
also examines bit[11] of 007611, it will notice the abort that way.  Thus,
we have an equivalent of the original code that works on either PDP-8 or
DECmate hardware, but only under the new operating system.  This code has
an additional advantage:  certain applications run from an alternate device
where a user abort can occur, such as another terminal on other than devices
03/04, etc.  This could be a serial printer with a keyboard, or a graphics
terminal, etc., where it could be desirable to write an application that
would have the option of user abort from this alternate device.  The program
can check for its local abort condition and exit as the replacement console
routines would above, thus logically extending the operation to the alternate
device.

OS/8 requires modification to allow a similar abort exit that is as generic.
The keyboard monitor will have to be made sensitive to a new bit, as well as
responding to a skipping KSF/KRB combination that detects ^C, which will allow
compatibility with older programs, but only if the hardware is actually a PDP-8
or VT-78, etc.  The current candidate is 007601, which is the function word in
OS/8's memory save routine that is initiated in 007600.  The breakdown of that
word is:

1 0 1 0 0 0 0 0 0 0 0 0

^______________________		Indicates this call is a write function

  ^ ^ ^ ^ ^ ___________       	Indicates that 8 pages should be written out

            ^ ^ ^               Indicates that field 00 is to be used

                  ^ ^ ^         These bits are usually undefined

The use of bits[9-11] of the function word of OS/8 are not defined for any
file-structured device with a minor exception: bit[11] being set is optionally
to be set for the benefit of the existing DECtape/LINCtape handlers to indicate
that the caller believes that there is less overhead directing the handler to
initiate searching for the requested block in the forward direction, whereas
the default is to search backwards.  Statistically, most searches ought to be
initiated backwards on these devices because it is likely that the next tape
transfer is contiguous to the previous one.  However, once the latest transfer
is completed, it is impossible to restart another transfer without backing up
the tape because the latest block has already partially gone by.  Thus, in
practice, the only calls that can benefit are those where the caller needs
widely spread out information stored on known blocks that are futher apart
than the overshoot factor of the tape (typically 2-3 blocks must be skipped
to make use of an additional forward transfer; the DECtape copy program makes
use of this feature by only copying half the tape deliberately skipping over
many blocks, and then copying only the previously skipped blocks while
spinning the tape in the reverse direction skipping over the previously copied
blocks.).

In actual fact, there are only a small handful of static calls within OS/8
that are made with this bit set, due to the design of OS/8 lacking much need
for the feature of search direction override; the usual OS/8 component isn't
forward of the previously read in component, etc.  Thus, while a useful feature
in principle, not much of OS/8 sets the bit because in the static sense, there
isn't too much that can be done to predict this situation.

Actually, this is unfortunate, since in the dynamic sense, there are quite a
few more situations where the actual call could have been made more efficiently
had the handler been aware of the circumstances which were not told to the
handler.

In P?S/8, the OS tells the handler nothing at all in this regard, yet overall
performance is noticeably better.  Part of the reason for this is that in P?S/8
DECtape handlers, the handler is internally responsible for maintaining the
current position of the tape.  Any call will be used to determine whether to
search forward or backwards based solely on the current tape position info
obtained from the previous call to the handler.

Years ago I wrote such a handler for OS/8 that ignores bit[11] in the
function word and instead maintains this "dead reckoning" on its own.  If
interest is warranted, I can locate this code and make it available to the
user community.  (It is not an exact knee-jerk "clone" of the standard OS/8
TC01/08 DECtape handler as there are design philosophy differences on other
issues as well, but IMHO any user would appreciate the differences and would
prefer my handler to the standard one.)

In any case, it is clear that the following handlers are up for consideration:

TC01/08 system and non-system handlers.
TD8E system and non-system handlers and the TD8E MR-8EC ROM system handler.
PDP-12 LINCtape handler
LINC-8 LINCtape hander for a modified LINC-8 and the non-system handler.  Also
the 12K system handler for an unmodified LINC-8 and a possible two-page handler
for use as a non-system handler on original hardware.

The TC01/08 system consideration was outlined above.  The TD8E system handler
is also written to obey this bit.  Among other considerations already 
implemented in P?S/8 is the same optimization for search direction on this
hardware.  It is likely that both the system and non-system handlers can be
made similarly "smarter".  The ROM-based system ignores the bit.  The PDP-12
hardware is too complicated to allow the OS/8 handlers to deal with the bit,
so all transfers are made starting with a reverse search.  It is conceivable
that the LINC-8 handlers can be made similarly smarter; the modified LINC-8
hardware includes helpouts to the handler for P?S/8 to accomplish this already,
but it isn't clear that the non-system handler for an unmodified machine can
accomplish this in less than two pages.

In any case, it would appear that an adequate job can be done to eradicate the
need for this bit in OS/8 completely.  The worst-case consequence of the bit
is that the call to save memory during the exit via 007600 would involve a
transfer initiated with a forward search.  (And it's conceivable that this
might even be the proper thing to do!)  There are no other OS/8 handlers that
pay attention to this bit.  (Note, there are non-file-structured devices that
use these bits; this is irrelevant!)

So, a replacement console routine for OS/8 Version 5 would be the same as
the P?S/8 example, except that the location being incremented would be
007601, not 007611.  The OS/8 keyboard monitor would have to be made sensitive
to bit[11] of 007601 as well as the case of the KSF/KRB skip of a ^C but only
on PDP-8 hardware.

Thus, a replacement OS/8 system can be built for use on PDP-8's or DECmates,
but every system program that requires DECmate application must be upgraded
to the new standard.

Along the way, some other issues will be addressed, such as creeping model
dependencies, which must be eliminated to allow one system version to run
on all of the machines it ought to, which is not currently the case in OS/8.
(P?S/8 already has accomplished this:  you can carry a single RX01-type 8"
floppy disk to any appropriately configured machine all the way from a
classic 1965 PDP-8 through a DECmate II and boot that very same disk on
any of the machines.)

Next time, more DECmate-specific quirks that impede compatibility due to
other problems, etc.

cjl