Subject: FORSALE: RK8E disk controllers

From: [email-masked] (Richard F. Lukes)
Date: Sun, 12 Sep 1993 01:44:23 GMT

I have a small number of RK8E Omnibus disk controllers for PDP8 systems.
It consists of two circuit boards, interconnecting blocks,  and a set of
cables.  Asking $150US or best offer.

Thanks,
--Rich
-- 
Richard F. Lukes                    [email-masked]
Computer Science Department
University of Manitoba
WORK: (204)-474-8696                HOME: (204)-257-6701

---

From: [email-masked] (Johnny Billquist)
Date: 12 Sep 93 11:38:13 GMT

>cables.  Asking $150US or best offer.

Huh? My RK8E controllers are all three boards. Do you have a more modern
version?
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

---

From: [email-masked] (Richard F. Lukes)
Date: Sun, 12 Sep 1993 16:39:41 GMT

>Huh? My RK8E controllers are all three boards. Do you have a more modern

Sorry for the confusion. The RK8E is three boards.  I made a mistake
in my posting...
--Rich
-- 
Richard F. Lukes                    [email-masked]
Computer Science Department
University of Manitoba
WORK: (204)-474-8696                HOME: (204)-257-6701

---

From: [email-masked] (Charles Lasner)
Date: 12 Sep 1993 19:43:15 GMT

In article <bqt.747833893@Minsk>,
>Huh? My RK8E controllers are all three boards. Do you have a more modern

Complete RK8E controllers aren't worth that much.  I have taken away gratis
complete systems, generally consisting of an 8/e with 32K and EAE, lab
peripherals, two H960 cabinets, some kind of terminal, generally an LA-36,
and an RK8E with two RK05.  Sorry, but in the "real world" pieces of old
computers have no commercial value.  However, these cards do have some
value to some of the collectors on this group, but it's more a matter of
either spare parts, or expanding an existing hobby machine, not anything more.

I will admit that RK8E cards did have a more lingering value to the used
computer market, simply because they were commanding a relatively high
percentage of their original over-price later than most other PDP-8 stuff.  In
part this is because they are modules, and thus take up less inventory space,
thus less likely to wind up in the used computer broker's dumpster, or sold
off to a trashman, etc.

However, speaking from experience, these cards are very difficult to fix.
They have a lot of chips used in circuits you can be tempted to "shotgun"
meaning that if you suspect that the problem is in N chips, then change all
N of them at once, etc.  The reason this comes up is that a lot of the
operations are too automatic, and only done once per overall disk operation.
It's difficult to create scope-loopable events to trace out on a scope, etc.

In any case, shotgunning techniques *also* don't work on these cards, because
the lands are very tiny, and the holes in the lands are undersized!  Thus, the
mere event of unsoldering a chip without damaging the board becomes next to
impossible.  In fact, if only a hand-type vacuum desoldering tool is available,
it's well nigh impossible!  (Pump-operated desolderers are sucking solder 
while they are also heating the joint, while solder-suckers are manually
released for a single shot from either a different vantage point if you have
enough hands, or are applied a second or so later than the heat.  Either way,
they fail to pull out as much solder as the pump vacuum desolderer.  In the
case of the RK8E and a few other type boards, such as the motherboard of a
DECmate III, etc. you need to such out that last bit of solder that's
intimately touching the innards of the hole that the lead is shoved tight
through.  If not, you can't dislodge the lead without land/plate-through hole
damage.  Moreover, all of this assumes that you will destroy the chip you
remove (although most aren't really worth too much per se) and are removing
it pin by pin.  In fact, I'll make a standing offer: if you can remove a
chip from an RK8E that works, in my presence, and not break any lands/holes
in the process, using a hand solder-sucker, and then can put the same chip
back in where it was removed from, and it still works afterwards, you can
*have* that RK8E!

Mini-FAQ for RK8E family

Here's some RK-isms that might apply somewhere.

The RK8E is originally a three-board set where the third card connects to
a special drive cable that is Berg-type on the RK8E end and is a double-height
connector at the other end.  That end is meant to go into an RK05 family drive
which could be an RK05A, RK05J, or RK05F.  (J is the upgraded A production,
and includes ECO's to make the drive cheaper to manufacture, and eliminates
a lot of expense and overhead dropping support of obsolete machinings that
evolved over the lifetime of the A drive to become obsolete, or were dropped
because they were actually detrimental!  For example, the old air system
included a bottom cover whose position contributed to the head alignment!
To avoid the need to align the heads when changing the air filter, the
air system was redesigned to eliminate the bottom cover entirely.  The new
drive eliminates the basic machining to support the cover at all.  The
F is a double-drive that responds as two selected A/J drives.  It is actually
not a fixed drive as purported, but rather a removable drive where the
cartridge handling basket, etc. have been removed, so it's merely harder
to remove, but still removable.  It is possible to restore the full function
of removability to an F drive, merely by using the proper components taken
from a defunct J drive, etc.  If you remove the false front, the F drive
reveals a front logo clearly meant to be the front of a removable F drive.
The reason all this was done is that DEC didn't want to confuse customers
over more than one type of seemingly identical, yet incompatible pack!  If
you use premium media, they can be used in either J or F drives, but are
not interchangeable media.  Only an F can format and read/write a pack
meant for an F, but if that pack is formatted in a J, it's then fine for
all J drives, and now incompatible with an F.  Moreover, it could get too
dirty being used in a J to be later acceptable for an F (after reformat!), etc.
And of course, since the drives can't read or write each others format,
there is the additional confusion of people trying to place the pack in the
wrong drive type, etc.  To avoid all of this, they just decided to make the
F a "fixed" pack.  You still have to place in the drive an appropriate
12 or 16 sector pack in order to use it with an -11 or -8 system respectively.
Also, a J drive's electronics are the same as the F's double-stepping drive,
which wasn't anticipated in the original A drive.  The modules are redesigned
to have J-F option switches onboard, etc.)

RK8E board sets normally support up to 4 RK05 drives (where an F drive counts
as an even/odd pair) and are noted as *not* using RK11D-type unit selection.
This means that there are four select lines, each waking up one drive.  This
is the same scheme as used commonly in more recent floppy drives, etc.  The
RK11D-type selection method means that you assert that line, and then ignore
one of the four select lines.  Then, the other three select lines form a
3 line -> 8 line encoder so that 3 bits support up to 8 drives.

There exists a modification to the RK8E board set known as RKS8E.  This
implements the RK11D-type selection.  To address four more drives, an
additional bit is added, defined as AC[0] during the IOT 0 of the RK8E
instructions.  (RK8E normally doesn't use this instruction.)  The latest
version of the RK formatting programming supports this bit.  If this IOT is
never issued, the drives are totally compatible for any operations on drives
0-3.  The rest of the RKS8E consists of adding a fourth card, and replacing
all of the over-the-top interconnects with a flexible printed circuit cable
device (similar technology to what's inside of many fairly recent telephones,
i.e., flexible printed circuit boards) that connects to all four cards.

The fourth card (M7107) is etched with the words "4096 Word Count Module" and
this is precisely what (at most) it can cause to happen.  The normal transfer
of an RK8E is to read or write one sector of 256x12 words, then wait for
additional programming to initiate another transfer.  In real-time, this is
nearly impossible; some people have had to resort to two-way interleave to
achieve passable performance.  Non-real-time handlers such as OS/8 and P?S/8
do manage to keep up with one-one interleave as long as there are no 
interrupts during the critical period between sectors, etc.  (There is less
than 100 microseconds available to issue the next operation to avoid a
full rotation latency.)  The M7107 implements a 4-bit register to allow
extra automatic transfers to occur without program intervention.  The only
restriction is that the sectors are in search order on the disk, and all on
the same track.  Thus, if you ask for sector 00, you can ask for sectors 01
through 17 to be transferred as well, but if you ask for sector 01, and
request 15 additional sectors, the last one will be sector 00 on the same
track, not the next one!  (Neither a head select or a track select change
will result; all transfers are to the current head/track.  However, if you
maintain transfers to full tracks in normal order, this is precisely what
will happen.)

As far as I can tell, the modifications are limited to the first two cards
when converting an RK8E -> RKS8E.  The "conventional wisdom" in the used
computer industry (and totally false!) was that the RKS8E was an "upgrade"
to an RK8E, i.e., an unmodified RK8E board set merely needs to be plugged
into the M7107 and the flexible cable set.  In fact, they become a four board
set that cannot be split up without unmodifying the boards!

Due to confusion about how the bits are counted, the bits chosen for the
word-count register are AC[1-4] during the same IOT 0 that is loading the
AC[0] bit into the high-order unit select bit.  But the bits are backwards in
the PDP-8 sense, meaning that the least significant bit is on the left, and
the most significant on the right!  (The designers thought that 0 is the
least significant bit, so they put the unit bit there, and that 1-4 were the
next most significant bits, so they put them there, etc.!)

The RK8E includes a maintainence instruction which is only used in diagnostics.
It allows various registers to be shifted out for examination, etc.  However,
due to a timing quirk, the maintainence instruction *ONLY* doesn't work on
a KK8A CPU-based machine!  Thus, the diagnostic comes with a warning that to
run it, the CPU has to be changed to KK8F (8/e card set) with terminator, etc.

There is rumor that the entire RK8E was redesigned onto two hex boards and
then designated RK8L (*not* RK8A!) and this is what the formatting programming
calls it, etc.  The RK8L implements the maintainence instruction correctly
so there is no CPU consideration, and also supports the RKS8E enhancements, 
etc.  This board certainly got into prototype production, if not actual
production.

There is an additional variant of the RK8E called RK8F.  This is a modification
made to allow the RK to be plugged into the DW8E level converter.  The DW8E
is available for all negative and positive buss machines using two variants - 
DW8E-P and DW8E-N.  Each DW8E supports a set of common non-DMA slots and
and certain slots reserved for individual DMA peripherals.  You have to
plug in certain option cards to "wake up" the slots at all even if there
isn't a DMA peripheral plugged in there.  (Rewiring the slot should cure this
problem!  The idea was that multiplexing was done by denying some of the
basic Omnibus timing signals to the slots until the DMA had its "turn", thus
the slots are "dead" even to non-DMA, etc.  However, only the RK8F was
ever designed for DW8E usage, so the need for a second DMA peripheral is
moot, thus it's better to just jumper in the missing timing signals to those
slots to get back more viable non-DMA slots, etc.)  So, in essence, there
are slots "reserved" for the RK8F in a DW8E, etc.

The RK8F modification essentially implements positive-buss-type DMA control
signals instead of Omnibus control signals commanding the RK DMA cycles.  It
takes about 20 add/cuts to implement it on the front card (M7104).  According
to documentation, the RK8F modification affects M7104 and M7105, not M7106.
Close investigation reveals no changes on the M7105.  Speculation is that the
change was merely an ECO requirement, so that in-production M7105 needs not
be changed to become part of RK8F.  (I have participated in changing over
two sets of RK8F back into RK8E.)  In any case, M7106 is unmodified as
documented.  I have a print set marked in DEC-standard red and green to
show adds/cuts, and all apply to the M7104.  (And it's an RK8E print set that
is neither the oldest nor the newest revision.)

Each RK8E cable must be connected to the first RK05 drive.  Each drive has
a double-height wire-wrap green block connector for the purpose.  Either
slot can be used.  The other slot must contain either an M930 UNIBUS terminator
or a UNIBUS cable to another drive.  In any case, the last drive in the
chain must have an M930 terminator card.

Each drive's unit select is determined in the drive according to a select
module plugged into the wire-wrap block.  The card contains a tap switch
with eight positions to support 0-7.  The part is the same switch used on
PDP-8/e 4K and 8K memory stacks to tap off the memory strobe timing with.
There is a modification to the RK05 which allows a cable to be placed into
the switch's lands that terminates in an Mate'N'Lok connector in the
bottom front of the drive, where another connector from a modified front panel
plugs in.  On the modified front panel is a unit select switch, the identical
component as used in the TU56 for unit select.  This allows user-selectable
drives.  In the case of a modified RK05F drive, the low-order bit of the
unit select is ignored (as is the case back on the tap switch on the
unmodified card as well!).  Modifications can be found on A, J, and F drives
and consists of removing the tap switch, adding the cable, cutting a hole
on the front panel, and adding the switch and mating cable.

RK8E software considerations:

As explained above, there are problems with real-time on the original RK8E
controller, mostly solved by using the RKS8E modifications (RK8L) if
available.  The alternative is to use 2:1 interleave which allows a few
milliseconds between transfers to get the next one started, but does
mean the aggregate transfer rate per track is cut in half.  The software
has to determine where the next sector to be accessed is, determine if
that transfer is on the same or the other head, and if it involves a
seek to another (usually the next) track.  If a seek is involved, a bit
must additionally be set to allow the sector headers to be checked for
track validity to indicate a seek error didn't happen (only the track part
of the address is checked; the sector number is ignored since that's always
determined from the physical hard sector marks on the bottom of the media).
Once the bit is set, at least one sector must be sacrificed as the one
checked, so this must be avoided when a seek doesn't occur, or a full
turn rotation penalty will be paid attempting to transfer the next physical
sector, etc.

Most users of OS/8 and P?S/8 don't use real-time applications, so the software
can barely keep up with the one hundred microsecond window of time available
to initiate the next sector in sequence.  Should an interrupt occur from
another part of the application, the disk performance suffers, but it's not
detrimental in any other way, etc.

Formatting the RK8E is actually rather trivial, because something somewhat
risky is involved here: the drive *always* rewrites the sector header when
writing to the disk.  (This is why all the checking is done in the handlers
for the disk!)  Formatting consists of merely writing normally while always
disabling that header-checking bit.  The standard formatter writes out
self-identifying data in each of the sectors while the header-check bit is
disabled.  After the fact, a normal read is attempted.  The data must be
written to the correct place, as evidenced by the self-identification, and
of course there must be no data errors, and no seek errors, etc.

There is a bug in the RK8ENS OS/8 non-system handler in that the error
recovery routine chooses a less desirable error-clearing routine.  In some
circumstances, a certain kind of controller error can occur that the OS/8
attempt can't clear (it just gets the same error again), thus the handler
fails unnecessarily.  Using an alternate error-clearing routine (involves
making a one-word patch to the handler) will correctly handle all cases.
The P?S/8 non-system handler does the correct error-recovery action.

Due to lack of room, the OS/8 system handler not only has the same bug,
but it is less selective in its error recovery, i.e., the maximal effort
including recalibration, is always applied regardless of error type.  (The
non-system handler only recalibrates when necessary, albeit with that
problematic case that can perpetuate itself as described above, etc.)  The
same fix can likely be applied as in the non-system handler, but it still
will take the long-way-around approach to handling all errors.  For example,
if a read parity error occurs, the non-system handler will realize that this
error requires merely a retry, not a recalibrate (needed only on seek-type
errors), while the system handler treats all error conditions equally, so it
would recalibrate then re-read after a read-parity error, etc.  Due to larger
code space being available, the P?S/8 system handler does the same error
recovery procedure as the patched OS/8 non-system handler or the P?S/8
non-system handler.

Booting the RK8E requires that the disk read start at track 0 head 0 sector
0 into location 00000 and wait for overlay at 00031.  Since the controller
cannot determine which drive was involved in the last transfer, the AC
is used as a convention to determine which drive is the one being booted to.
The bits left over from loading the control register for unit select are to
be placed in the AC while waiting, which is usually the case after the likely
instruction sequence anyway.

A curious feature of the OS/8 system handler is that it has a co-resident
entry point for another handler for the other half of the disk.  Each
OS/8 logical device on an RK8E system represents either the inner half or
the outer half of the 2.5 MB device.  It is also possible to patch the
system so that the first device is 4096 records long and waste the rest of
the disk, but usually the device is addressed as two 3248 record devices.
The system device is usually RKA0: and the other half would be RKB0:.  These
are the permanent names of the non-system devices as seen from the non-system
handler.  However, the system handler works off of the device just booted to,
so these relationships are only conditionally true, i.e., only if booted to
drive 0.  If the disk is booted to say drive 1, then SYS: is currently
equivalent to RKA1:, not RKA0:.  Of course, it is always referred to as 
SYS:, and is always correct.

However, due to the structure of OS/8, the handler that is co-resident
with SYS:, and of course will likely be assigned to be also known as DSK:,
must be configured as RKB0:, which will actually be incorrect in this
situation, since it ought to be RKB1:, or more properly RKBu: where u= the
currently booted unit.  It is recommended that if the specific cartridge
tends to be booted to different drives in different situations, that the
non-system handler be used to reference specifically RKB0:, or RKB1:, or
whatever, since that definition won't change.  (Of course, this whole
phenomena can be looked upon as either a quirk or a feature!)

In the P?S/8 environment, the disk is partitioned into logical units
each 1/2 the size of the OS/8 units, and the system handler addresses
two drives total, since each P?S/8 system handler addresses (up to) eight
logical units.  Thus, if a P?S/8 system disk is booted to either drive 0
or 1, the units stay the same, except that the unit booted to could be
any of the eight units, likely 0 if the drive is 0, and 4 if the drive is 1.
(Actually, P?S/8 defines an extension of the standard bootstrap that allows
booting to the nearest 1/4 drive.  When used with the standard bootstrap, 
this means that the boot unit is either 0 or 4 as above.)  As in OS/8, the
entire process repeats itself if the drive unit is either 2 or three.  There
is sufficient space in the system handler to accommodate supporting the RKS8E
or RK8L extension of drives 4,5,6,7 as well in a like manner, etc.

In the P?S/8 environment, the disk is addressed to the nearest 128-word
logical block, which in this case is to the 1/2 physical record.  The
handler includes code to manage this correctly so that unreferenced record
halves remain undisturbed.  (When OS/8 writes an odd number of pages to
an RK8E, the other half of the last record gets zeroed out.  When P?S/8 makes
a similar call, the other half's data is preserved.  Internally the handler
carries this out by buffering the data, part from the original record, and
the new data from the user's call, and both are written out together.  Some
CP/M and early MS-DOS systems work this way as well, using 1024 bytes per
sector on floppies where the call is to read or write only 512 bytes, etc.)
The handler does check for the (likely) cases where the extra kludging need
not be done, so the usual disk performance is identical to OS/8 where
comparisons can be made, etc.  To accomplish this, P?S/8 requires 8K, rather
than its usual 4K, so RK8E support comparing OS/8 to P?S/8 has the rather
unusual nature that they both require 8K, whereas in most situations P?S/8
requires 4K while OS/8 requires 8K, or alternatively P?S/8 requires 8K while
OS/8 requires 12K for more difficult devices, etc.

COS-300/310 RK8E disks are layed out identically to OS/8 on RK8E, and
each system can directly access each other's files without unusual handlers.
(Of course COS internal conventions, such as file innards for non-executables,
base date year, text format, restrictions on most executables, commands to
access files being more restrictive and totally different, etc. still apply,
but on most devices there is an extra layer of incompatibility because the
device handling is also different, but not in the case of the RK8E, etc.)

cjl