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

This is the third in a series of posts about why the DECmate series of small
computers is not quite what we know as a PDP-8.  Already covered are the minor
CPU issues, and the significent differences in the console interfaces between
all PDP-8s and all DECmates, and what can be done about these particular
consequences, etc.

3)	Disk issues.

	Systems such as OS/8 and P?S/8 have to be configured for whatever
machine-specific disk environment they run on, so in theory, this aspect of
compatibility shouldn't be an issue.  However, there are some problematic
compatibility details anyway.

	The DECmate I is essential compatible on this issue, as the boot
device of the DECmate I is either an RX01/02 or an RL02.  The only actual
difference between the DECmate I RX interface and a PDP-8 version is that
the VT-78-style interface is present, i.e., the software has to deal with
the potential of two pairs of RX drives.  This is controlled by the SEL
IOT (6750) which is defined as: load pair select per AC[11] where 0=the drive
pair found on the PDP-8 and 1=the optional pair found only on the VT-78 or
DECmate I (VT-278).  Some system handlers for RX do not include the SEL
instruction to ensure this condition, but it is the default state of the
machine.  All software, such as the non-system handler to access the second
pair, is responsible for resetting the select line to ensure the proper
functioning of the system handler; it is likely that certain, but not all,
existing system handlers for RX usage will be so tightly coded that this
convention must be obeyed, since this is another tradeoff of features and
performance versus handler space that could not have been anticipated by
the authors of these handlers.  There are user-written RX handlers to
accomplish such things as byte-mode transfers to gain back 33% more disk
space over the standard DEC 12-bit mode.  There are also handlers to allow
for accompishing this with/without the use of the otherwise wasted space on
track 0, and also to mimic the disk layout of COS and/or WPS to allow
conversion programs such as WPFLOP to function.  Still others are designed to
be able to boot a byte-mode system so that the system device also benefits
from the additional space, etc.  There also exists a set of handlers for use
on RT-11-style disk layout to gain faster throughput as well.

The overall point here is that there has been a lot of RX work provided by the
user community seeking performance beyond what little DEC has provided.  By
switching the "rules" and requiring the software maintain yet another item of
"housekeeping" compromises these handlers yet further.  (Even in 12-bit mode,
it is impossible to accomplish all of the requirements of an RX handler in
only two pages, the OS/8 upper limit.  There exists an analogous handler for
P?S/8 usage, which requires three pages; P?S/8 allows handlers up to 32 pages
long.  Thus, any two-page handler is compromised in some way, usually in the
area of error recovery or performance, possibly only affecting certain models,
etc.)

The DECmate II complicates this issue further.  On this specific machine, the
RX-78 option allows for one or two pairs of RX01/02 (and at the same time
prevents the RD51D hard disk option; you can either have one pair of RX50 and
a hard disk or up to eight floppies implemented as two pairs of RX01/02 and
two pairs of RX50).  However, the selection interface of the DECmate II is
incompatible with that of the VT-78 and DECMate I, and requires several more
instructions to provide compatible selection with the prior models.  Thus,
all existing user-written and older DEC-provided handlers cannot run on the
DECmate II.  Only those that can be modified slightly can be made to run on
this hardware (which is somewhat more difficult presently than necessary; see
below).

This issue is complicated further by a specific design "philosophy" of OS/278:
In OS/8, the RX done flag is used as a status indicator.  Assuming no interrupt
enabled (or the RX device interrupt is specifically disabled; this is in the
province of any interrupt-driven program designed for the machine, etc.) the
done flag being up is used as an idle status indicator.  The reason for this
is that a handler can never know the current status of the drives when it is
called; there could be a system reset in progress, which takes up to five
seconds to complete.  The convention for the handlers is to assume that you
should wait for the done flag to raise, since it's already up or will be
up (eventually) at which time you should proceed with the main work of the
call.  Handler exit is accomplished by executing an innocuous function that
cannot fail (such as READ ERROR REGISTER) and then exiting without waiting for
the function to complete.  (The problem is that to test the done flag is to
clear it, since the relevant IOT (SDN) is Skip on DoNe set, clear done flag.)
Thus, the hardware is now in a favorable state for the next caller.  Should
a power-clear condition occur at some point, the handler will have to wait
for up to five seconds, but can otherwise proceed, etc.

When OS/278 was introduced, the new designers revised this convention.  Under
OS/278, the RX done flag is always assumed to be clear.  This sometimes causes
handlers to fail, or at the least go through some error recovery cycles before
accomplishing the requested handler calls, etc.  There exists some user 
programs that make the system crash when run from an OS/278 floppy, while
functioning correctly when run from an OS/278 hard disk volume!  All of this
is traceable to bad interaction with the new convention.

To operate under this convention will add an undue burden to the handlers
written by the user community, and it isn't necessary.  I have already written
P?S/8 handlers that work perfectly fine under the original flag convention on
the DECmate II hardware.  (I have created a "bootable" RX01/02 P?S/8 system.
Since the hardware of the DECmate II can only boot to an RX50 or hard disk
volume, it is necessary to first boot to the RX50, then run a "re-boot"
program to bring up the RX01/02-based P?S/8, which is meant to be booted
directly on a PDP-8 or VT-78 or DECmate I, etc.)

OS/8 version 5 will restore the original convention, and thus will require
rewriting the DEC-style handlers accordingly.  However, all user-written
handlers will function as intended, i.e., will function only on the PDP-8
system they were designed for.  If possible, all handlers should be modified
to be compatible with the restrictions of all of the machines.  (Some of the
specific requirements are: 1) Must be able to have decent throughput on the
slow VT-78; this is often not the case, especially on writes.  2) Must be
able to support the SEL hardware of the VT-78/DECmate I, and preferably the
DECmate II.  3) Should have decent error recovery if possible.  In general,
it's impossible to have all of this, especially if the format involves the
use of byte-mode transfers, and the format is single density, thus requiring
checking for the possibility of performing byte-mode single density transfers
on RX02 as opposed to RX01 which programs slightly differently in this
mode, etc.)

In any case, the user-community software investment in RX utility will not
go to waste.

In the case of the DECmate I, there is only one consideration: the RL8A
controller allows for the ability to support existing software for RL01
or RL02, but not both.  There exists a support jumper on the RL8A hardware
that prevents some unforeseen consequence from occuring regarding the bit
normally used in the RL02 for additional seek cylinders, etc.  Apparently,
the jumper has to be set so that the hardware isn't subject to a mis-set
bit in the software.  Several theories exist as to what the proper setting
of this bit is, that the hardware provides to the drives, etc.  Possible
examples are: 1) always one. 2) always zero. 3) Sign extension of the bit
immediately to the right of this bit. 4) some form of parity.  In any case,
RL01 software doesn't maintain any consistent usage of this bit, so the
hardware jumper is used to maintain compatibility.  When the RL02 is used,
the software correctly uses this (extra) bit.  Thus, mixed systems of RL01
and RL02 are not allowed.  In theory, if/when we find out what this bit
setting is, we can possibly modify all of the RL01 software to support an
RL01 in a controller where the bit is set for full RL02 support, similar to
the existing PDP-11 support currently.

In any case, RL8A users cannot currently mix RL01 and RL02 drives.  The DECmate
I RL-278 controller apparently lacks this jumper altogether, thus only allowing
RL02 drives, until the software clean-up described is implemented.  In the
case of RL02 software specifically, the DECmate I is fully compatible.  (This
does assume that the software is *otherwise* compatible, such as with the
DECmate console interface or CPU differences!)

On the DECmate II, III, III+, new software has to be written for the RX50, 
since the DEC-provided OS/278 handlers instigate the above-mentioned flag
incompatibility.  This should prove as difficult as modifying the user-written
handlers, etc.

DECmate II and III+ hard disk volume software is essentially acceptable, up
to a point, since this is the province of these machines only.

Next time, problems of the RX50 and hard disk volume software not covered yet.

cjl