Yes, it has that impact, but it has no effect at all on the physical interface.
Sadly, a few controllers in the "old" days were built to the original ST506
spec, meaning that, like their 8" predecessors, they stepped at a fixed rate of
3 ms per step. You could, of course, devise a scheme for changing the rate at
which the pulses were generated, but I never had a taste for that much
self-abuse.
The earliest HDC's seemed to favor using an FDC chip to control head
positioning. They didn't ramp the seek rate up and down on longer seeks, though
it seems some do in today's floppy drives. Unfortunately, PC-BIOS based
firmware steps the floppy drives too slowly and doesn't make provision for the
drives' capability to step faster.
Dick
----- Original Message -----
From: "Tony Duell" <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 02, 2001 5:53 PM
Subject: Re: D connector tirade (was: Re: Age-old ethernet equipment)
>
> Actually, the ST412 physical interface is, unless I've missed something in
the
> (insert ridiculously large number here) times
I've done it in every way
> identical to the ST506. The only difference I've noted is that the
> ST412-series drives were capable of buffering the step pulses in order to
> compute fast seek velocity profiles. This is a firmware effect, not a
hardware
Yes, that is the difference. The ST412 (and almost all later drives)
support buffered seeks. This does have some implications for the
interface -- namely how fast you can send the step pulses.
It doesn't normally matter in practice in that just about all 'ST506'
drives support buffered seeks, but you can still step them slowly [1] if
you want to. But I still think it should be called the ST412 interface,
not the ST506 interface (unless the drive in question doesn't support
buffered seeks).
[1] At least it's not an SA4000. That (14" winchester) drive supported
buffered seeks, but badly. You could either send it one step at a time
and wait for seek complete to be asserted before sending the next one
(unbuffered seeking) or send it a load of step pulses fast, and it would
buffer them, then do the seek, then assert seek complete. What you
couldn't do is send it pulses relatively slowly, but too fast for it to
step complete after each one. If you did that, the step counter
miscounted, and the heads ended up on the wrong cylinder.
> > > > [2] I am not sure how anyone can write a hardware book without a
single
> > > > schematic or timing diagram, but
the PC-crowd seem to manage it.
> > > >
> > > They have to write what their intended readers can understand. After
all,
> lots
> >
> > OK, but if I'd not call such a book a 'hardware bible' or a
'hardware
> > reference'. Those terms should imply some technical information...
> >
> The people willing to buy and rely on such things get what they deserve.
Most
of them
don't read the things anyway.
True... My moan is that I _can't_ seem to buy a decent book on modern PC
hardware, with some facts in it that are not obvious from looking at the
machine for 10 minutes...
A
catchy title will sell products so abysmally lacking in both value and
Not to me it won't.... I have this habit of _looking_ at books before I
buy them.
> underlying knowledge that anybody who would actually read such a thing would
be
appalled.
Indeed...
Apart from the IBM Technical Reference manuals (which are excellent,
although rather dated), is there a good book on PC hardware? Because I've
yet to see anything I would spend any money on...
Frankly, I've yet to see a good book on PC-anything.
The IBM manuals are at least reasonably accurate and complete for the IBM
hardware. The older ones include schematics and ROM source, and other
similar information.
> > It's odd, but I've never had any success doing things like that, even
> > when I use so-called compatible parts. But if I get the pinouts, and sit
> > down with a logic analyser (if the timing diagrams are not available), I
> > can generally get things to talk to each other.
> >
> The PC-generation wasn't when this started. I'm about (once I have time) to
sit
No, but it got a lot worse with PCs.
At least with S100 stuff (say) you often had schematics. And pinouts of
all the connectors. And data sheets for the chips. Some manufacturers
were better than others, of course, but few supplied only manuals that
were as bad as the so-called documentation you get with PC products these
days.
> down with my S-100 hardware and produce logic analyzer snapshots and import
them
> into my PC so I can use them in documenting what
REALLY happens on the bus
with
> each of a number of CPU boards. My experience
has been that the
documentation
provided with
CP/M-era hardware was often fraught with error and even with
Some was, but there were some _excellent_ manuals about. In general, the
schematics in the manuals were pretty darn close to the hardware as
supplied. And the data sheets on the chips (at least on chips from
reputable manufacturers) included things like timing diagrams that were
very near what you'd see on a logic analyser.
Yes, there were errors in the text (the most serious being the missing
off of the inverting bar on some signal names, possibly due to the
printing process). But I never bothered with the text anyway. It was
quicker to read the schematic and work out what was really going on. I
rarely read the jumper setting information in the manual, and I
certainly never depended on it. I used the schematics.
> disinformation. The situation with PC-generation stuff seems to have been
that
> the mfg's simply saved themselves the trouble
of publishing disinformation
about
> their products, since the PC was designed for
people who'd see a logic
diagram
as being a
foreign language anyway.
But alas for those of us who'd rather read a schematic than a manual at
the 'This computer, this disk, this smack on head' level, you can't get
proper manuals on PC hardware, not even as an option.
-tony