Mail Archives: djgpp/2005/07/14/21:01:05
Hello wrote:
> "Ari Lukumies"
>
>>IMNSHO, this is more caused by the drive's rw-heads capabilities and speed
>>tolerances.
>
> Out of spec floppies are always a problem, of course. (That's one of the
> reasons copy protected floppies are such a pita.)
> But even allowing for that, there are issues, since the floppy controller in
> the standard PC is so unforgiving.
> A too short index hole gap was a very common problem. Infamous, really.
> The PC controller just couldn't always handle it, even if the floppy was in
> spec.
In these sentences, you did not once mentioned the physics of the
hardware (drive, if you'd prefer). Do you know, there are also physics
involved? Other than the floppies themselves? A controller is just one
piece having to do with electricity dealing with hardware, it is not
/the/ hardware. A 'too short index hole gap' is an aspect that can be
dealt with either the hardware or the controler (althoug, as you say,
it shouldn't always be).
>>Later, IBM introduced the 1.2MB floppy disk. It had even more problems,
>>since it used narrower rw-heads than the previous 360kB
>
> Yup. But often, the problems were still things such as too short gaps, etc.
But most often, this was caused by the /hardware/, gaps could still be
programmed to a proper length, taken the /hardware/ into account.
> Things that were within official specs, but just not quite what some PC
> floppy controllers expected.
> Or just barely under the official specs. They'd work fine in other
> controllers, but not the ones in most PC's.
Here, you failed to mention the tolerances I talked about (-4% to +4%
for the head positioning, that's a fact for this tolerance, the speed
tolerance percentages I do not recall after so many years of
engineering and maintaining the drives). Not that the tolerances were
necessarily met by custom manufacturers, I admit.
>>BTW, this goes for hard disks, also: if you use one in one computer and
>>move it to another, it may require reformatting before being usable (or
>>reliably stabile, at least).
>
> Not for IDE drives. The IDE drives have the controllers built into the
> drives.
They have an internal clock, but that's scaled when you warm the IDE
disk for about 40 minutes before the first installation. Afterwards,
the speed of the input from the system where you use the drive does
matter to timing of the data transfer to/from the disk subsystem, and
for high-speed disks, that speed gap may either work or render your
disk unusable, unless you reformat it in another system.
> The only case where you might have problem is in the older mid 90's
> computers that used several of the early methods to get past the 8g (and
> various other, smaller sizes) size limitations.
What I said above goes even more for nowadays' greater capacity and
speed SATA and PATA disks; the SCSI ones are one different branch
altogether, with their own control mechanism, and thus do not apply
here. A slight change of temperature, even, may render your new hard
disk unusable.
> Eventually, computers standardized on a single LBA mode, but there for a
> while, taking a hard drive from one computer to another was a gamble.
The disks geometry was using LBA-style addressing long before anybody
knew MS-DOS existed. The term for most of the people (like you,
apparently) surfaced when Winchester/IBM standard 1024-track system
came to its end and people needed more storage capacity for their home
use; the small-systems (PC) disk manufacturers took it in and started
marketing it, with the help of the BIOS manufacturers (thank god).
> But that's really more of an OS problem, not a hardware problem.
If you do not have hardware to support post-1024 tracks, how do you
make software make use of it? (NB: software here means both the OS
support and the BIOS support; some geeks use pure FDC to access the
tracks, but how many of those made it to the market?)
> There are thermal tolerances and so on that can cause a hard drive to have
> problems. But that's not dependant on any particular computer etc. And it
> wont effect taking an IDE drive to another computer.
Ok, build me a computer with a hard drive that works from, say, minus
40 degrees of Celcius to, say, plus 35 degrees Celcius without cooling
or heating (yes, here in Finland, we do have that much of temperature
variation). Whether this will have an effect on another computer is
not the question, the question is that, it /is/ dependant on a
particular computer, whether the thermal tolerances matter or not. Or
do you disagree?
> Older mfm, rll, etc. drives could be picky, but those aren't exactly common
> these days.
Did I ever mention them? (I may now: I have a few of both, the RLL are
better, but not so much supported on the older machines.)
> I've written programs to feed each byte to the
> controller, etc. And written programs to read each byte. To copy floppies.
> (Although my copy programs were never as sophisticated as the commercial
> stuff.)
As you have done so, you also know what's behind it, and how it
changes due to the changes of the /hardware/ related to the chips that
are just a way to give commands to it?
> But the standard PC controller can be unforgiving at times. If the gap is
> just a byte too short, the floppy becomes unreliable. It may work fine in
> one system and totally fail in others.
That's what I started my post with. Now you finally accept it.
> And the gap after the index hole is infamous for causing problems. That's
> one you dare not shorten.
Have you often came across a situation where it caused a problem?
Once? Twice? I bet, not 'regularly'.
> Modern PC's *may* be a bit more reliable with the floppy, but I wouldn't bet
> on it. After all, they are designed to be completely compatbile, and that
> usually means the same limitations and problems, just on the off chance some
> floppy or program might depend on it. And they are such a low end,
> uninteresting piece of hardware, I doubt much effort actually goes into
> making them reliable, beyond the minimal they have to.
Nowadays, the PC (and OS) manufacturers tend to make the floppy drives
totally compatible by totally annihilating them - eventually no one
will have one. So much for the trouble, here comes another one: the
CD/DVD-swing!
> However, you have to remember, they were written explicitly to copy the copy
> protected floppies!
[copying programs]
> So it's not too unreasonable to assume they use every trick the authors can
> think of to find out exactly how that track is done. Ranging from doing a
> full "read raw track" kind of command, to reading each sector and timing the
> rotation delay, to counting bits, to switching head positions (to detect a
> sector (real or home made) on an otherwise unformatted track), to whatever.
I suspect, the programs used even more tricks than there were in the
book. I once tried to make a copy of a disk. It was perfectly legal,
but somehow it got partly unreadable in sunset (didn't like to be on a
windowsill I guess). I launched CopyIIPC, which to that time was the
best copier I'd ever encountered (for making the one backup that was
allowed by the program license, of course), and it did make a copy of
that partly demolished floppy. Only, it copied the demolished parts
also, so that the resulting floppy also was partly demolished.
That's what I call software engineering. :)
> The point was, though, that if somebody does try to make a backup and it
> doesn't work, unless they are absolute newbies or brain dead AOL'ers, they
> are going to do a search to find out what's wrong.
>
> They aren't going to do it once and then give up. Unless the program is
> uninteresting and they don't really want a copy.
>
> And they'll find instructions on how to go ahead and do what they want to
> do.
And now they'll have a few more posts to wander through.
No offence, (I should be offended myself, having done so much posting),
-atl-
--
A multiverse is figments of its own creations
- Raw text -