Subject: Old RL questions

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

Here's another one of those old questions that may still need a
present-day comment or two (hundred) on, etc.

>Date: 12-Jun-89 20:22:02 +0200
>From: Johnny Billquist <[email-masked]>
>To: [email-masked]
>Subject: RL8A.

>More questions on hardware.

>The RL8A is for the RL01 drives, according to my manuals.
>However, would it be possible to add RL02 to the controller also?
>I know that on pdp-11 you can add both RL01 and RL02 to the same
>controller, but I don't know about RL8A.
>Note. I do not have the RL8A manual, only a manual on omnibus
>options.

The RL8A is indeed for both RL01 and RL02.  The problem is that it's not
for both of them at the same time.  As far as I can tell, the reason is
that the RL02 has exactly twice as many tracks, thus the track difference
register has one additional significent bit.  In hindsight, DEC apparently
never set a standard as to what to set this bit to on the RL01, and
instead there's a hardware jumper on the RL8A that makes that bit be
ignored.  Thus, sloppy code (relative to this bit) can be used on RL01
that could fail if the bit were thrown the other way to make all RL02
software function, etc.

Can anyone shed any light on just what the correct value of this bit is?
In theory, if we know what it's supposed to be, we can patch all code to
conform to the requirement.  If so, then the jumper can be set to the RL02
position, and then the RL buss can support mixed drives just like the -11,
etc.  Additionally, I understand that the obscure option for the DECmate
I, the RL278, is for RL02 only, i.e., doesn't support that bit that makes
the RL01 "happy" regardless of register value, etc.  Thus, it would be
possible for an RL01 to be hooked to a DM I, etc.

The bit could be any of the following:

1)  Always meant to be 0

2)  Always meant to be 1

3)  Always meant to be a sign extension of the bit immediately to its
right

4)  Some form of parity bit?

Given the way the RL02 does it, I suspect the first case, but I would
appreciate any authoritative input.

>Does anyone know if it is easy to lay my hands on a RL8A by the
>way. I think it would be great to have disks larger than the RK05.
>Especially if I get an OS that support larger disks than 4095 blocks.
>(OS/8).
>Anybody cares to guess on the price?

The RL is a lower-performance drive than the RK05, especially for OS/8
purposes.  You may get more devices of 4095 records on it (especially
RL02) but each is the same OS/8 limit of 4095.  An RK05 is usually set to
two devices each 3248 records, because that splits the device in half.
It's actually quite easy to make RKA0: be 4096 records, and then have RKB0
be the rest, so you do get a full-size device.  In any case, this is more
of a matter of the limitation of OS/8 than the limitation of the RL
drives, etc.

>Also, what OS:es has different people tried. Could you give
>me a summary of good and bad, and I'll put it together and
>post it here if more people are interested.
>I think that support for hardware, such as the FPP would
>be interesting to know about, for example, also...

On the -8, there really hasn't been much support for the RL other than the
OS/8 and COS-310 handlers.  I believe the multi-user WPS used the RL as
the disk device.

OS/8 support is kludged to fit within the confines of the traded-off OS/8
handler and its two-page limit.

The RL drive has actual bad block tables, one factory and one
user-written.  OS/8 support is predicated on the existence of a utility
(sometimes called up by the CCL FORMAT command) that divvies up the 40
sector/track RL drive into "wedges".  The RL01 has two wedges, each of 16
sectors on every track, and an additional half-size wedge consisting of
the remaining 8 sectors on each track.  On the RL02, the outer wedges
correspond to the RL01's wedges, but since there are twice as many tracks,
there are also two additional inner wedges. The additional 8 sectors of
the inner and outer half-wedges are combined to support a fifth device.

Within each wedge there is a local bad block table that is written in a
format that is more "friendly" to the handlers.  Each table only contains
bad block info about the particular wedge.  Each wedge allows a maximum of
16 local bad blocks.  (The overall drive allows many more!  Thus, while a
cartridge could be usable by other software, OS/8 could flunk an otherwise
usable cartridge, etc.)

To calculate a physical sector from a logical sector, the list is checked
for any bad sector less than or equal to the requested logical sector. 
For any found entry, the requested sector is bumped by one.  The final
result is mapped into its relative position within the wedge, etc.  Thus,
bad sectors are "straddled" over.  Notice that this calculation must be
performed for each sector.  This is part of why the fact that the RL
hardware supports a multi-sector transfer word count mechanism is
worthless to OS/8.

The other reason is more insidious:  For no reason that makes any sense,
the RL word count hardware when used in 12-bit mode implements a bizarre
transfer scheme.  (Note: in 8-bit mode, it makes good sense - the word
count is a byte transfer count; each byte goes right justified into a
separate word of memory.) If you limit the word count to 128, then indeed
an entire page is filled with data taken from the first 192 x 8 or 128 x
12 bits.

But if the word count is extended, additional words are taken from the
same physical sector.  This prevents multi-page transfers!  No useful
purpose is served by this scheme.  Indeed, as many as 170 words can be
transferred by this method from any one sector.  Note this doesn't even
represent a complete sector image, as there is still an additional 8-bit
byte that doesn't transfer!  (If this was to be used as some form of
image-copy mode, then it should have transferred 171 words where the last
word has four dummy bits, etc.)

Thus, because it's impossible to usefully setup a multi-page transfer, the
bad-block testing is granularized to individual sectors in the wedge.
Each page transfer involves checking for bad-block straddling, and must be
setup as an independent event.  Because of all of this overhead, it's
impossible to transfer the physically adjacent sector without incurring a
full-revolution latency penalty, thus, the contents of each wedge is
mapped by a 2:1 interleave.

In most designs, a 2:1 interleave just means that it takes two revolutions
to transfer the entire track's data, but in this case it means it takes
two revolutions to transfer only the 16 (or 8) sector wedge.  Thus, it
means there are twice as many cases of overall handler call that are
involved with an entire revolution latency than otherwise might have been
avoided.  (Calls for 8 or less pages on good boundaries can avoid having
to include the time of an entire revolution latency; without the
interleave this could have been as many as 16.  The relevant numbers for
the half-wedges become 4 instead of 8, etc.

The straddling scheme could have been modified to avoid whole tracks if
necessary to preserve throughput at the expense of larger device size
penalties for bad spots, similar to the "cluster" concept of MS-DOS, etc.
Each full wedge is exactly the full size of an OS/8 4096 record device.
One physical record is unavailable as it contains the local bad-block
table itself.  Each time a handler is loaded, that record is read into the
handler using a word count of just 16; thus the bad-block table becomes
addressable data within the page of code of the handler itself, etc.)

>Should I add a disclaimer? Everybody else in any other list seems
>to use them? Nah, what the heck...

We don't need disclaimers!

Here's some more on the same subject:

>Date: Mon, 12 Jun 89 21:17:23 EDT
>From: "Christopher R. Zach" <[email-masked]>
>Subject:  RL8A.
>To: [email-masked]
>cc: [email-masked]
>In-reply-to: Msg of 12-Jun-89 20:22:02 +0200 from Johnny Billquist <BQT at kicki.stacken.kth.se>

>Johnny:
>	My guess is that the Rl02 will work on the RL8A. When Dec made the
>RL01, they left room for possible expansion (then the masses got the 02). 
>To tell you the truth, the Rl02 is just a RL01 with 2X the tracks. As far
>as software goes, that's another story. You would have to hack the OS/8
>driver to be able to access those extra sectors. Check the sourcecode.
>You might have to only change a few things (like #tracks). Once the driver
>is patched, the rest should go smoothly.
>							CZ

Chris's guess is pretty good about the hardware.  But the software is
another thing entirely!  OS/8 RL02 handlers clearly are derived from the
older RL01 code, but map everything differently, etc.  The FORMAT utility
must create twice as many localized bad-block tables to accomodate the
additional OS/8 devices that appear on the RL02, etc.

Johnny asked about how other systems would fare on the RL drives. Here is
what P?S/8 would have to do to live on an RL:

In P?S/8, there is enough room in the handler to accomplish bad-block
handling using the real tables of the disk, thus avoiding the OS/8
"crutch" of the localized tables.  However, it's marginally easier to
mimic the OS/8 data scheme.  (Note: if all bad-block tables are accurate
and consistent, it wouldn't matter!  The only advantage gained is the
ability to access the data in the OS/8 equivalent of record 4095 since it
wouldn't be reserved.  P?S/8 can consider logical blocks of 0000 through
4095 while in this scheme OS/8 must only consider blocks 0000 through at
most 4094.  In actuality, this is only 0000 through 4079, since the last
16 records are reserved for straddling blocks in case of the maximal
number of locally handled bad-blocks, etc.)

P?S/8 allows devices with 4096 blocks by the simple expedient of being
consistent to indicating the highest block, while OS/8 instead reckons
size by the count of available blocks.  This creates the headache of the
case where the size would wrap from 7777 to 0000. Since all real devices
always have a block 0000, it makes more sense to indicate the block number
of the highest transferrable block. Thus, a 4096 block device can have an
entry of 7777.  But in OS/8, this case must be avoided, since it is
indicated by a value of 0000, thus the notion of 4095, *not* 4096 as the
largest size of an individual logical device, etc.

In theory, when a P?S/8 handler is loaded, it's conceivable that the
handler could determine what physical drive is being accessed (I assume
that if you attempt to read past a certain physical sector, you get an
error on an RL01 and a transfer on an RL02; merely seeking should suffice,
etc.) and then setup all relevant mapping on the fly using the tables on
the pack, etc.

Since P?S/8 logical device sizes are 1/2 that of OS/8, instead of the 2.5
OS/8 devices on an RL01 (two and one additional that is .5 the size the
others), there would be P?S/8 logical units 0 through 4 for a total of
five devices.  But in P?S/8, logical units are passed as part of the
addressing space of any one handler.  If the pack is discovered to be an
RL02, then there would be the maximum of eight logical devices addressed
through the system handler, and two additional that require a non-system
handler to access.  Thus, P?S/8 can address an entire RL01 with one system
or non-system handler while OS/8 requires three handlers.  P?S/8 can
address 4/5 of an RL02 with one system or non-system handler and the
remaining 1/5 with an additional non-system handler while OS/8 requires
five handlers.

In many ways, the RL was a major step backwards.  Competing designs using
the same overall form-factor as the RL pre-exist it by years. However, all
of these previous designs share some improvements over the RL design -
error-free devices, and hardware automatic seeking. Back-to-back transfers
are normal!  The only "advance" was that it used an early form of imbedded
servo control.  This makes the drive cheaper, not better.  (And admittedly
avoids problems such as drive alignment, etc.) The drawbacks that the
software has to face are more important, unrelated, and were never
necessary to the design.

Because of the lack of a proper interrupt structure associated with the
program-controlled primitive seek, interrupt-driven systems have to take
special pains to live with an RL drive.  (OS/8 and P?S/8 aren't interrupt
driven in general.) For a great example, ask someone familiar with all of
the major kludges in RT-11 just to get the beast to work at all!  (Note:
even the lowly RX01 uses automatic seek!)

cjl