RX50 on RQDX3 on 2.11BSD

[Roger Ivie]

>Does anyone have experience using the RX50 floppy drive under 2.11BSD? I
>patched my FreeBSD kernel to handle RX50-format (80 cyl / 1 hd / 10 sec)
>diskettes, and noticed what seemed to be some sort of logical sector
>interleave (I also have hardware that does physical diskette reads /
>dumps, which assured me that I was getting the physical data off the disk
>in the order prescribed by the sector ID address marks);

Yes, there is a software interleave on RX50 diskettes. It also varies 
from system
to system; I'm pretty certain PDP-11s and VAXes use the same software 
interleave
(otherwise you couldn't exchange diskettes between a Pro350 and a MicroVAX II),
but the DECmate II and III use a different software interleave. I 
have a memo here
somewhere; it's getting a bit faded, perhaps I should do an underground HTML
translation of it... Ah yes, here it is:

DEC format supported by RQDX controller (this is 1984, so the only 
RQDX controller
is RQDX1 at the time) used by Pro300, Micro-PDPs, MicroVAX I:

- 10 sectors per track
- 2 for 1 interleaving with 3 to 1 intercylinder skew
- Physical track # = (LBN/10) + 1 with wraparound to track 0 [IOW, logical
   track 0 is physical track 1 and physical track 0 is logical track 79]
- Physical sector # = X ( m ) where m = LBN mod 50, n = m/10, c = m mod 10:

        |c=0|c=1|c=2|c=3|c=4|c=5|c=6|c=7|c=8|c=9|
     ---+---+---+---+---+---+---+---+---+---+---+
     n=0| 01| 03| 05| 07| 09| 02| 04| 06| 08| 10|
     ---+---+---+---+---+---+---+---+---+---+---+
     n=1| 03| 05| 07| 09| 01| 04| 06| 08| 10| 02|
     ---+---+---+---+---+---+---+---+---+---+---+
     n=2| 05| 07| 09| 01| 03| 06| 08| 10| 02| 04|
     ---+---+---+---+---+---+---+---+---+---+---+
     n=3| 07| 09| 01| 03| 05| 08| 10| 02| 04| 06|
     ---+---+---+---+---+---+---+---+---+---+---+
     n=4| 09| 01| 03| 05| 07| 10| 02| 04| 06| 08|
     ---+---+---+---+---+---+---+---+---+---+---+

DECmates and Rainbows don't use an intercylinder skew. Rainbows have the
whacky logical track wrapping while DECmates don't.

Yes, the RQDX3 is supposed to do this for you so you don't have to deal
with it, unless you're foolishly trying to read DECmate or Rainbow disks
on an RQDX3, at which point you need to carefully figure out how the lack
of intercylinder skew on the DECmates interacts with the cylinder skew
on the RQDX3.

I know the RQDX3 implements the soft interleave because I did the firmware
for Digital's SCSI floppy controller. I maintained that the device driver
should deal with the interleave because it varies from format to format and
the SCSI controller can't tell whether a particular RX50 is a DECmate RX50
or a VAX RX50. VMS didn't want to deal with the soft interleave because they
don't have to on the RQDX3. I lost the fight and had to go back into the
SCSI controller and rev the firmware to deal with the soft interleave.

>	$ dd if=testrx50.img of=/dev/ra12a
>	800+0 records in
>	800+0 records out
>	$ dd if=/dev/ra12a of=test
>	800+0 records in
>	800+0 records out
>	$ diff testrx50.img test
>	Binary files testrx50.img and test differ
>
>WHOA! This shouldn't happen, should it?

No, it shouldn't, at least AFAIK.

> In my late-night screwings-around,
>I recall the following Additional Facts:
>  - Disks formatted with my PC floppy drive (using my kernel hacks -
>available on request [although until I get them working, no guarantees in
>re: their applicability to this or any other use; although I will attest
>that they won't make your kernel crash, at least not in 4.0-STABLE])
>usually work okay, but sometimes give hard errors.

This shouldn't be a problem. There are some potential difficulties
involving the gap lengths; IIRC it's possible to format floppies that
work on a PC but don't work with the HDC 9224 used on the RQDX3 because
the 9224 requires a little bit more time to clean itself up in one of
the gaps. Unfortunately, I don't recall the details; this was all a long
time ago. I think it involves the gap between the header and data fields of
a sector, but don't hold me to that.

>I'll note at this point that the media I'm using is 3M DS/DD 96tpi (_not_
>high density), and disks formatted with the 6000 (RT-11) worked perfectly
>under RSX-11.

That's good. You should not be using high-density disks.

>Finally, I noticed there is no floppy-specific code in the MSCP driver, so
>all the gory details of floppy control (along with the gory details of the
>above) must be dealt with by the RQDX3. Anybody got documentation for this
>little slice 'o heaven?

What sort of info are you looking for? Floppy drivers are a PITA to write
and you should be happy the RQDX3 is hiding it from you.

>And, er, _really_ finally, is it really true that I can put any HD AT
>drive (well, any one that sports DS jumpers) on the RQDX3 and it'll
>function as an RX33?

The DEC drive changes speed based on the head write current signal of
the interface. AT drives don't change speed; the data separator on an
AT controller runs at 300KHz for low-density instead of 250KHz to deal
with that little slice o' heaven. If you stick any HD AT drive on an
RQDX3, you may be able to read high-density disks, but you probably will
not be able to read low-density disks (i.e., RX50s).

Oh yeah. Since the DEC drives change speed, that means there's an extra
little slice o' heaven in the floppy support code to wait for the drive
to change speed when the density changes. Are you _sure_ you want
documentation for that little slice o' heaven?

--
Roger Ivie
rivie at teraglobal.com
Not speaking for TeraGlobal Communications Corporation

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id GAA17070
	for pups-liszt; Wed, 7 Jun 2000 06:22:55 +1000 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)