Subject: Responses to old RX questions from June, 1989

From: [email-masked] (Charles Lasner)
Date: 17 Mar 1994 07:44:49 GMT

I've just finished archiving the PDP8-Lovers list stuff for June, 1989!
It can now be found on sunsite.unc.edu in the directory:

/pub/academic/computer-science/history/pdp-8/pdp8-lovers as the file
8906.lov in keeping with the filename convention established, etc.

In going through it, I found a few (marginally!) worthwhile things to
respond to.  Here goes one or two of them:

>Date:  1-Jun-89 18:13:16 +0200
>From: Johnny Billquist <[email-masked]>
>To: [email-masked]
>Subject: RX8 vs. RX28.
>
>There exists both the RX8 and RX28 drive for the omnibus,
>RX8 using RX01, and RX28 using RX02, however, a paper of mine
>states that the RX28 consists of the RX8-E and an RX02.
>Is it possible to hang an RX02 drive to my RX8-E, use the
>RX28 device driver, and just be happy?
>
>	/Johnny

Of course!  Well, sort-of.

On the hardware issue, of course this is correct, and is the only way to
even do it.  The same M8357 module is always used for all Omnibus RX
applications regardless of which drive pair is used.

The software for the RX series, even just limiting the discussion to OS/8
family is another matter entirely.  For the moment, let's just stick to
the official DEC type of support as has been seen in various OS/8 family
incarnations. 

The original RX01 handler was eventually officially withdrawn!  It had the
dubious distinction of actually not exactly qualifying as a handler at the
fundamental level: 

1) Write out the caller-specified buffer data to the caller-specified
logical record for the caller-specified length. Return with an error if
this cannot be carried out. 

2) Read in the caller-specified data at the specified logical record for
the caller-specified length into the caller-specified buffer. Make a
reasonable attempt at error recovery and return an error only if this
cannot be carried out. 

This "almost" handler couldn't carry out either 1) or 2)!  When you
attempt a write, it's quite possible to get an error before the actual
write is carried out, such as a seek error, etc.  In such a case, the
handler would attempt an error recovery procedure that causes the
caller-specified data to be ignored!  In its place is written the current
contents of unit 0, track 1, sector 1!  Assuming the error condition
abates, the handler returns to the caller without an error return as if
the caller's request has been carried out, yet it has not!  There is no
way to determine if this has happened without a followup readback and data
compare, since merely verifying the readability doesn't reveal the
problem!  (Note: neither readback and data compare nor verify is performed
by any OS/8 utility!)

When the handler is patched to remove error recovery, then it does almost
qualify as a reasonable handler - at least it then *is* a handler!
However, by removing error retry, then 2) doesn't occur. It is *not*
reasonable to never retry a read on an RX device because this raises the
error rate.  (This is a device where it is recommended to carry out a
series of at least data-read retries and also seek/recalibrate operations
for the likes of a seek error; in its original form, the handler actually
carries out too much error recovery, i.e., it does everything in the event
of anything going wrong, etc.  Such "over-recovery" actually encourages
certain types of errors, such as the inability to recover from marginal
data errors where leaving the head down eventually overcomes the read
error, etc. To my knowledge, the only available handlers that deal with
RX's in the recommended manner are in P?S/8!)

Thus, you have two choices with this original handler: 1) Play Russian
Roulette with your data writing and only maybe find out eventually (I got
some DECUS disks with this very defect!) that it was mis-written way back
when, 2) Remove the error recovery and then know that the data written is
reliable, but constantly be subject to premature handler fails caused by
total lack of error recovery!

This handler did allow an 8K RX01 system!  It was eventually "retired" in
favor of the series of 12K system handlers that at least don't have this
problem!  Additionally, the inclusion of a 12K handler for other than a
TD8E could only be accomplished when a standard was developed for programs
that move handlers around, such as F4 and BASIC, etc.  Up until then, this
was known as "The TD8E Problem" but it eventually became obvious that
there would be a group of problematic handlers.  It is apparent that the
problems of this handler led to the completion of that specification
sooner! 

An additional quirk of this early handler (and a few that followed it) was
that it required an odd feature of the RX01 that wasn't available on the
RX02.  When the handler is entered/exited, the done flag is used as an
idle/busy flag.  Thus, the handler should wait until the done flag raises,
then proceed with the work of the caller, then raise the done flag and
leave.  This allows CAF and other buss resets to make all compatible
handlers wait for the self-test to complete, etc. and allows good
synchronization of all code, etc. 

However, there is a problem with the instruction set of the RX: all
skip-on-flag instructions also clear the associated flag (shades of the
DECmate keyboard problem to come!).  Thus, once you have waited for a
function to finish, the flag is no longer up.  Thus, to fulfill the
specification, the handler performs a "NOP" function as it leaves without
checking the done flag, which of course eventually raises harmlessly (in a
few hundred microseconds or so).  By the time the next call is made, the
flag is already up and adds no material delay time, etc. 

The specific function used by these early handlers is function 100, which
while being a NOP on an RX01, is the "Set Media Density" function on the
RX02!  Fortunately, there are protocol considerations associated with
proper use of the function which aren't performed by these handlers, so
you never have a case of accidental data destruction!  However, all the
handler calls get unclearable errors, etc. 

Actually, the RX02 has a compatibility mode switch inside.  Throwing the
switch makes function 100 become a compatible NOP, thus allowing the early
handlers to function (as RX01's!) on the RX02 drive.  In this mode, it is
impossible to reference any double-density aspect of the RX02.  (Note:
there are some other programs that can be confused by this bit in
conjunction with an anomalous status register bit elsewhere in the RX02!)

Eventually, DEC released 12K handlers that overcome this problem by using
an alternate function for the NOP, the "read error register" function.
This will function equally on RX01 or RX02, etc.

Another issue was speed, especially on the VT78, DEC's slowest RX-worthy
model.  The routine to calculate physical sectors/tracks from logical
records is written for minimum code size; it runs extremely slow!  On the
VT78, the situation is so bad that throughput suffers because the mapped
2:1 interleave cannot be kept up with because of the calculation overhead.
(Note: in P?S/8, better algorithms are used that do keep up on the VT78!
However, this is because in P?S/8 there is far more handler space
available to accomplish this!)

To partially offset this, the sector calculation is initiated during the
time spent waiting for reading or writing.  This does make a marked
improvement on the VT78, except for the higher track numbers where it
still falls behind.

Since OS/8 only allows two pages for handlers, error recovery has always
been the greatest weak spot of the handlers.  The only advance has been
past the original handler's fatal weakness.  All newer handlers can do
some semblance of error recovery, and will never falsely write other than
the user's data!  (Of course all of these handlers still "over-recover"
since there is never enough handler code space to sort out particular
errors, etc.)

Newer handlers for single-density media are all RX02-aware. Generally, the
only change is the boot code.  The original boot code cannot be used
because it accidentally sets a density bit in the command, and thus can
only work on the RX02 set to compatibility mode.  (Note: the official RX01
boot can fit into the MI8E (M847) 32 word boot card limit while the
official RX01/02 boot is too long!)

The newer boot attempts to load drive 0 or 1 in both single and double
density modes.  If executed on an RX01, the density bits are ignored.  For
compatibility, the newer boot indicates which drive and also which density
in a way useful to both early and late handlers. (Some of the data is
redundant, but wouldn't be useful to the RX02 in the form early RX01
handlers demand!)

The non-system handlers are also generally available in an alternate form
with a different device code.  This is to allow two pairs of drives on a
single Omnibus machine.  In the VT78 and DECmate I, this is accomplished
with a single interface that multiplexes against a bit in the new
instruction SEL (6750) which defines AC[11] as selecting which pair of
drives is selected currently.  On power clear pair 0 is selected.  Since
there is no room in the system handler to select this, the non-system
handlers always ensure that pair 0 is selected when exiting! 

(Actually, there is a third method of selecting drives beyond the first
pair: in the DSD-210, there is an available bit adjacent to the unit
select bit DEC uses.  Thus, this bit can be used to select a second pair
of drives.  DSD actually sold a box containing three drives; several -8
users have them.  The drive buss supports up to four drives.  There exists
a non-system handler that has three co-resident handlers within it for
this configuration; the code is essentially the same as DEC's on all other
aspects of the hardware, etc.  P?S/8 handlers support up to four drives
using either the SEL method or the DSD unit bit method.  As in OS/8,
reassembling the handler for an alternate device code produces a handler
for alternate Omnibus address, etc.)

As of OS/78 V3, a new non-system handler appeared that, through a PIP
kludge, can actually handle both single and double density diskettes with
a single handler.  When the handler is called for the first time, it
determines whether the media is either:

1)  Single-sided single density

2)  Single-sided double density

3)  Double-sided single density

4)  Double-sided double density

Note that the double-sided diskettes require RX03 hardware!  While never
released, DEC did prototype the RX03, and wrote both OS/8 and RT-11
support for it!  DSD (among others) produced RX03-compatible hardware that
used the RT-11 support. 

The double-sided support consists of an additional status bit only
allowable on an RX02/03 (which is an error bit on an RX01!).  On an RX02,
the bit always reads 0.  Support for a double-sided device consists of
appending the "back" side of the disk to the front thus exactly doubling
the allowed logical length, etc. 

Since the logical record length of any device in the system is only known
to PIP.SV, PIP was modified to perform a special-case check for the
logical device number of this RXNS handler.  (So much for device
independence!)

If the RX logical device number is being used, PIP calls the handler with
the impossible record number 7777.  Of course, an error occurs. However,
instead of just returning an arbitrary negative number on the error return
(generally 4000 or 7777, but anything negative is allowed), the handler
returns the two's complement of the logical length of the currently
mounted diskette.  Thus, PIP can determine how to zero the device!  All
other OS/8 programs use the existing directory info to determine the
device size, etc., so this is actually viable.  (Note: the error recovery
associated with this handler for inexplicable reasons is marginally
inferior to prior versions.  It is speculated that the person responsible
for the code didn't understand just what proper error recovery actual is!
Newer still versions seem to have an even more degraded version of error
recovery!)

When the DECmate II was introduced, a hardware incompatibility in the
design occurred which renders all existing RX handlers up to that point
obsolete.  (This includes all user-written variants, such as byte-oriented
handlers, etc.)

On the DECmate II, III, III+, attempts to use the standard RX code will
instead reference the RX50 drives, and will not work due to the different
geometry of the RX50 drives (and perhaps other differences, etc.). 

To access the RX01/02 on the RX78 option of the DECmate II requires an
additional bit be set in the SEL (6750) instruction.  Not only does
bit[11] set the pair number, but bit[0] sets the RX78; clearing this bit
selects the RX50 (as does power clear which selects RX50 pair 0).  No
existing RX01/02 code ever set that bit before.  In some cases it is
possible to revamp the handlers to properly maintain the extra bit(s), but
in others the handlers are already compromised to the limit with other
tradeoffs (performance, error recovery, etc.).

To make matters worse, the designers of OS/278 "changed the rules"! Now,
the done flag has to be *NOT* set between calls!  If it should be found to
be set, it's an error!  (There is a sufficiently large error recovery
count to make this not too much of a problem, but the physical drive
pseudo-recalibration effort is made should the flag be up, etc.) When the
handler leaves, no effort is made to raise the done flag again.  Because
of this, it is almost hopeless for any of the earlier handlers to be
modified for use in OS/278.  In some cases it is marginally possible, but
it's not clear that it's even worth the effort!  (Note: OS/8 Version 5
will maintain the original convention!  Older handlers are welcome there!)
Thus, most OS/278 users never install any user-written RX handlers.

In the OS/278 handlers, pseudo-recalibration is used for no apparent
reason; the drive is seeked between the highest track and track 0, then
the operation is retried.  I don't understand how that is supposed to
clear a seek error!  Clearly it violates all documentation for the
RX01/02!  (And the RX50 handlers do the same thing!)

>Date: Fri,  2 Jun 89 08:00:51 EDT
>From: "Christopher R. Zach" <[email-masked]>
>Subject:  RX8 vs. RX28.
>To: [email-masked]
>cc: [email-masked]
>In-reply-to: Msg of 1-Jun-89 18:13:16 +0200 from Johnny Billquist <BQT at kicki.stacken.kth.se>
>
>Johnny:
>	Forget it. The RX02 uses a different controller because it is a DMA
>device (RX01 used interrupts). Also, the RX01 control doesn't have the extra
>registers to handle DD disks.
>							CZ

Christopher Zach is apparently confusing the Omnibus and the UNIBUS! Only
on the UNIBUS (and Q-buss, etc.) are RX02 controllers DMA.

Moreover, he is wrong about the RX01 controller!  There is support for an
RX02 on the RX11!  It just does things a byte at a time!

The RX01 requires either 8 bit or 12 bit data/commands.  The RX02 requires
either 16 bit or 12 bit commands.  Only the RX8E can set the 12-bit mode.
Thus, in 12-bit mode, the commands for single density are identical.  You
just have to be careful not to set to one the density stuff in the
high-order bits!  If you use byte mode, then you have to wait for an extra
TR flag and send 8 more bits, which contain the appropriate density info
either way.  (Note: -8 code has to carefully determine that the drive
actually *is* an RX02 before doing this!  On the RX01 you must *not* do
this!  Some confusion lies in the proper method of identification of
whether a drive actually is an RX02; the RX02 manual gives a standard
definition, however it is WRONG!  On the RX02 the bit means "I am an RX02
even if the RX01 compatibility switch is thrown" while on an RX01 it means
"I am an RX01 and the selected drive is either write-protected or not
ready" which is inconsistent with the conclusions of the RX02 manual!  You
must use alternate means to determine this status!)

So, on the -11, the same method the -8 uses to talk to byte-mode RX02 can
be used, i.e., 16-bit commands are sent 8 bits at a time, and 8-bit data
is used, etc. 

cjl

---

From: [email-masked] (Charles Lasner)
Date: 18 Mar 1994 08:13:49 GMT

Here's another of those questions that came up almost four years ago
that perhaps is worthy of a current answer:

Date: Fri,  2 Jun 89 07:59:07 EDT
From: "Christopher R. Zach" <[email-masked]>
Subject:  Expansion and memory...
To: [email-masked]
cc: [email-masked]
In-reply-to: Msg of 31-May-89 22:48:46 +0200 from Johnny Billquist <BQT at kicki.stacken.kth.se>

Johnny:
	Dec did a lot of that stuff with certian devices HAVING to be in
certain places. I think the reason was so that field service would have an
easier time of finding the different parts of the system.
	However, for best system results, it is a good idea to place the
memory as close to the cpu as possible (this allows the cpu to work with
the memory first, instead of going through a bunch of device controllers.
							CZ

This seems again to be one of those UNIBUS versus Omnibus confusions.

While Chris' reasoning makes sense on the UNIBUS, on the Omnibus
there are different rules.

In essence, the memory goes at the back of the box with the
terminator just behind it.  The CPU goes at the beginning of the
buss.  DMA peripherals are in the middle, as are all other cards
except for two notable exceptions: the KA8E and KD8E.  I suspect the
main reason for the exceptions is that it's accounted for in the
design timing, and additionally, the unweildy cables don't want to be
brought into the trough area of the -8/e power supply unnecessarily.
This would tend to make a messy area of cable pile-up even worse!

Even if the machine is expanded into two boxes, as long as the memory
is in the back box, the rule still applies.  If using an 8/a and an
8/e box, then as long as the memory is 8/a type, it would still go
into a low-numbered 8/a slot with the CPU terminator (M8320) in the
top slot.

Of course you cannot accomodate this if the memory is in the 8/e box,
since then all of the cards in the 8/a box are past the inter-box
cable.  I'm not sure if DEC ever recommended this configuration.
Clearly they would want you to have 8/a memory if you had an 8/a box!

cjl