On Tue, Jun 06, 2000 at 02:06:40PM -0500, Jason T. Miller wrote:
Wonder what DEC would think of allowing (providing?)
old PDP hardware docs
for the archive?
I'm afraid you'd have to ask Mentec.
--
Wilko Bulte FreeBSD, the power to serve
http://www.freebsd.org
http://www.nlfug.nl
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id FAA16881
for pups-liszt; Wed, 7 Jun 2000 05:40:28 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
From Tim Shoppa <SHOPPA(a)trailing-edge.com> Wed
Jun 7 05:38:29 2000
Received: from
timaxp.trailing-edge.com
(
timaxp.trailing-edge.com [63.73.218.130])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id FAA16877
for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Wed, 7 Jun 2000 05:40:23 +1000 (EST)
(envelope-from SHOPPA(a)timaxp.trailing-edge.com)
Received: by
timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.ADFA.OZ.AU;
Tue, 6 Jun 2000 15:38:29 -0400
Date: Tue, 6 Jun 2000 15:38:29 -0400
From: Tim Shoppa <SHOPPA(a)trailing-edge.com>
To: PUPS(a)MINNIE.CS.ADFA.OZ.AU
Message-Id: <000606153829.20200e60(a)trailing-edge.com>
Subject: Re: RX50 on RQDX3 on 2.11BSD
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Does anyone have experience using the RX50 floppy drive
under 2.11BSD?
Yeah, sure.
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?
No, it shouldn't, but I'm confused as to where you're doing this at.
Is this on FreeBSD?
Also:
- 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.
This must have something to do with the 2.11BSD disk label. The raw
character device should be writable, can you try rm'ing the appropriate
entries and remaking them with /dev/MAKEDEV?
Also note that you may have to issue a disklabel command to make it
possible for you to clobber the sectors where the disk label would otherwise
live.
- 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).
Yes, there is a physical<->logical block interleave on the RX50. See, for
example, John Wilson's PUTR source code ( at
ftp://ftp.dbit.com/pub/ibmpc/putr/
- assuming that
ftp.dbit.com is back up by now!) for details and
example code.
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.
That's true, the RQDX3 takes care of all that. If you look at any DEC
Professional RX50 driver source code, you'll see the interleave code in there.
For example, from RT-11's DZ.MAC sources:
;
; In standard RT-PC mode, a 2:1 interleave is used on a single track and
; a 2 sector skew is used across tracks.
("RT-PC" means "RT-11 on a DEC Professional", roughly!)
and later, in a breathtaking example of tight driver interleave code
(really, study it very closely, this is good stuff!):
; Normal I/O, convert block number to track and sector number and interleave
;
ASL R2 ;Make word count unsigned byte count
MOV (PC)+,R4 ;Loop count for 8 bit division
.BYTE -7.,-10. ;Count becomes 0, -10 in high byte for later
50$: CMP #1280.,R5 ;Does 10 go into dividend (10.*200)?
BHI 60$ ;Branch if not, C-bit clear
ADD #-1280.,R5 ;Subtract 10 from dividend, and set C-bit
;(10.*200)
60$: ROL R5 ;Shift dividend and quotient
INCB R4 ;Decrement loop count
BLE 50$ ;Branch until divide done
MOVB R5,R1 ;Copy track number 0:79, zero extend
ADD R4,R5 ;Make sector < 0
MOV R1,R4 ;Copy track number
ASL R1 ;Multiply by 2 (skew)
70$: SUB #10.,R1 ;Reduce track number * 2 MOD 10
BGT 70$ ; to find offset for this track, -10:0
MOV R1,TRKOFF ;Save it
BR 100$ ;Go save parameters and start
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?
The DEC RX33 floppy drive *is* a TEAC FD55GFR, also commonly found
on PC-clones.
Not just *any* HD AT floppy drive will work. Not only does it need
to support the drive select jumpers, it also needs a bit more jumper
configurability. The exact jumper settings vary depending on which
exact FD55 model and revision you're using. As of a few months
ago many of the jumper setting legends were decoded on the spec sheets
you could get from TEAC's faxback service.
The standard reference on this subject for the past decade has been
Terry Kennedy's THIRD-PARTY-DISKS.TXT, available via anonymous FTP
from
ftp://ftp.spc.edu/third-party-disks.txt
Since this subject comes up several times a year, would it be possible
to link to the above document from somewhere in the PUPS archive, Warren?
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW:
http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id GAA16978
for pups-liszt; Wed, 7 Jun 2000 06:01:47 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
From Tim Shoppa <SHOPPA(a)trailing-edge.com> Wed
Jun 7 05:59:51 2000
Received: from
timaxp.trailing-edge.com
(
timaxp.trailing-edge.com [63.73.218.130])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id GAA16974
for <PUPS(a)MINNIE.CS.ADFA.EDU.AU>; Wed, 7 Jun 2000 06:01:42 +1000 (EST)
(envelope-from SHOPPA(a)timaxp.trailing-edge.com)
Received: by
timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.ADFA.EDU.AU;
Tue, 6 Jun 2000 15:59:51 -0400
Date: Tue, 6 Jun 2000 15:59:51 -0400
From: Tim Shoppa <SHOPPA(a)trailing-edge.com>
To: PUPS(a)minnie.cs.adfa.edu.au
Message-Id: <000606155951.20200e60(a)trailing-edge.com>
Subject: Re: RX50 on RQDX3 on 2.11BSD
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> Wonder what DEC would think of allowing
(providing?) old PDP hardware docs
> for the archive?
I'm afraid you'd have to ask Mentec.
No, Mentec doesn't (generally) own the rights to those. Mentec owns the
rights to several former DEC OS's, most notably RT-11, RSX-11M, RSX-11M+,
and RSTS/E, and many of the corresponding layered products. But they
don't even own all the former DEC PDP-11 software; for instance, they
don't have XXDP, DOS-11, PAL-11, etc...
Of probable interest to many of the readers of this mailing list,
Mentec is gearing up to offer a hobbyist license for the RT, RSX-11M, RSX-11M+,
and RSTS/E. Note, in particular, that there is a "PDP-11 Hobbyist" link
on Mentec's page at
http://www.mentec.com/mentecinc/default.asp
The link is currently disabled, but I expect it'll be active in the next
week or so.
Tim.
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id GAA17027
for pups-liszt; Wed, 7 Jun 2000 06:14:35 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
From Roger Ivie <rivie(a)teraglobal.com> Wed Jun 7
06:12:14 2000
Received: from
ns1.teraglobal.com (
ns1.teraglobal.com [63.210.171.3])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id GAA17023
for <pups(a)minnie.cs.adfa.edu.au>; Wed, 7 Jun 2000 06:14:32 +1000 (EST)
(envelope-from rivie(a)teraglobal.com)
Received: from [10.10.50.26] (208.186.13.23) by
ns1.teraglobal.com with ESMTP
(Eudora Internet Mail Server 2.2.2); Tue, 6 Jun 2000 13:12:22 -0700
Mime-Version: 1.0
X-Sender: rivie(a)ns1.teraglobal.com
Message-Id: <v0421010eb563058aacb7(a)[10.10.50.26]>
In-Reply-To:
<Pine.LNX.4.10.10006061323100.5676-100000(a)guildenstern.shaffstall.com>
References:
<Pine.LNX.4.10.10006061323100.5676-100000(a)guildenstern.shaffstall.com>
Date: Tue, 6 Jun 2000 14:12:14 -0600
To: pups(a)minnie.cs.adfa.edu.au
From: Roger Ivie <rivie(a)teraglobal.com>
Subject: Re: RX50 on RQDX3 on 2.11BSD
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
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(a)teraglobal.com
Not speaking for TeraGlobal Communications Corporation
Received: (from major@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(a)minnie.cs.adfa.edu.au)