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_at_p850ug1.demon.co.uk>
To: <classiccmp_at_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
>
>
Received on Mon Apr 02 2001 - 23:12:35 BST