🚀 go-pugleaf

In article <BttDwA.579@watdragon.uwaterloo.ca> kcwellsc@watdragon.uwaterloo.ca (Ken Wellsch) writes:
>>I have heard some of this before, all too fuzzy though.
>>
>>I have seen actual DEC RD51 drives that come with metallic cutable jumpers on 
>>the DS lines.  DS0, DS1, DS2 are intact and DS3 is cut.  This means that this
>>particular drive will select on 0 or 1 or 2 but not 3.  I have been told that
>>the reason for cutting the DS3 line is that in (presumably one of the PRO
>>models, because it ain't a DECmate or RB), the controller uses the incompatible
>>notion of *reading* back DS3 instead of potentially asserting it.  Thus, a
>>5 Meg has the DS3 set and a 10 Meg has it clear, so the machine "knows" what
>>size disk it is.  (This is back when there only were RD50 and RD51 supported.)
>>
>>Is there anything to this?
>
>I don't know.  I can only mention what my docs have.  The Pro pocket service
>guide says to cut the "fourth from the back of the drive" jumper.  They've
>used a seven jumper dip leaving the 8th (toward the front of the drive) empty.
>I don't have the Seagate info to know what the jumpers do.  My old uVAX-1
>docs say to cut the back two and the fourth (as for the Pro).  I've forgotten
>what the setting for the RD50 is, possibly all jumpered.

I got out the RD51 (ST-412) in question.  There are 8 possible socket-based 
jumpers, but DEC's plug can't do the last one.  The first 4 are DS0,1,2,3, and
then it gets unclear.  I believe one of them is to make the disk do an
automatic recalibrate when turned on, which is unnecessary since the controller
issues a recalibrate command, it just makes it take longer to boot, and on
some systems might make a time-out error happen.  (Wasn't there a Rainbow ROM
patch on account of this kind if problem?)

So, this all seems consistent: if you ground DS3, then something in DEC's
controller reads it, even though this is wildly outside of the normal spec
for the ST-506-compatible MFM drives.  If it's grounded, it's a 5 meg, and
if it's not, it's a 10 meg, unless some other software "knows better" which
may merely be the master boot code that was read in by the ROM in its belief
that the disk was either 5 or 10 megs.  A smart boot program could tell the
ROM what it needed to know to correct the situation, etc.  In most systems,
it should be self-evident because the system is implicitly self-configured.
Perhaps the system attempted is too feeble to make the correct guess so it
falls back on the ROM's misunderstanding of the size, etc.

There is a plausible alternate explanation for all of this:

All disks *other than* the RD50 support buffered stepping of tracks, but the
RD50 requires track step commands at the physical rate of the disk or slower.
Faster disks can receive the steps serially, but at a high rate such as every
few microseconds.  Some even take advantage of this to realize a performance
improvement by using a so-called "rampup/rampdown" algorithm.  The idea is
that you can move the head during a seek too fast to stop on the desired
track, but not too fast to realize where it is.  If the controller has the
opportunity to realize that the disk is seriously in the wrong are, the
controller (the one built into the newer disks, not the host machine's
controller!) can affect a high-speed stroke to more quickly get close to
the desired track, then slow down at the end to finish the seek to the
desired track.  Thus, a "smart" disk can have much lower worst-case seek
times, even though a next-track seek is no faster all other things equal.

Perhaps the PRO controller knows how to issue these high-speed seek command
steps, and needs to know when it's an RD50 that it better not attempt to do
it on.

cjl