RX50 on RQDX3 on 2.11BSD

Jason T. Miller jasomill at shaffstall.com
Wed Jun 7 05:06:40 AEST 2000

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); so, back to the
old '11 for another round of test-disk making. My test data was simple
enough: 512 bytes of 16-bit unsigned integer one, followed by 512 bytes of
UINT16 2, usw. to UINT16 800; the easier to figure out the interleave, my
precious... But I didna even get that far: observe (testrx50.img is
409,600 bytes):

	$ 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? 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.
  - Disks formatted with the aforementioned Custom Hardware (a Shaffstall
6000 media conversion system, for the curious) for a) DEC Rainbow, b)
RT-11, and c) DECmate II, seem to work flawlessly, at the physical level,
but exhibit the below-mentioned quirks, logically.

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.

  - The '11/2.11BSD never seem to write the first two sectors, although
no error is returned to this effect; in fact, the data in sector three is
from offset 1024 in the input data (0x0003 in the above example). Is this
due to disk label support or something? The raw (character) device reports
itself as read-only, even for root.
  - The remaining data sometimes (but not always; the specific
circumstances involved I have not yet figured out conclusively -- physical
interleave, preexisting data (!), or, something else?) carries an
interleave, though I admit I haven't figured it out yet (meaning I haven't
sat down and done it, not that I don't know how).

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?

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? Does this void my field service contract, as my field
service engineer is growing bored with staying up all night trying to
understand funky DEC floppy hardware, as Parts currently has Guinness on
a 180-day lead and it is a neccessary part of such an operation?

Wonder what DEC would think of allowing (providing?) old PDP hardware docs
for the archive?


More information about the TUHS mailing list