ajp166 at bellatlantic.net
Fri Jul 27 12:28:56 CDT 2007
>Subject: Re: Imagedisk 1.17
> From: "Dave Dunfield" <dave06a at dunfield.com>
> Date: Fri, 27 Jul 2007 07:11:40 -0500
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>> Lately I've found a very nasty bugs in IMD 1.16 (at least with a secondary
>> FDC, tested on two different machines of different speed with different
>> FDC). Reading disks is mostly fine, but writing to a drive connected to a
>> secondary FDC doesn't work reliably. The problem is that the drive won't
>> step properly, i.e. sometimes it misses a step pulse which makes the
>> written disk unusable. The same problem occurs e.g. with the clean head
>> routine. I had a look on your source code and I think it's a timing
>> issue. I've inserted a small delay ('delay(55);') into the seek routine
>> (between line 998 and line 999 in version 1.16) and this solved all the
>> problem. I think that the seek routine is called too early after having
>> sent the previous command to the FDC although it shouldn't matter because
>> wrfdc officially waits for the FDC to be ready before sending a byte. But
>> apparently some (many? all?) FDCs appear to be in a ready state although
>> they are not yet ready to do a seek... really weird.
>It's impossible to test every FDC (at least in a free project). This
>explaination doesn't make sense because the seek routine has a 55ms settleing
>delay at the end (which you can increase with the SD= option), and the clean-
>head routine has a 100ms delay between seeks, which makes a total of 150ms
>delay. There are no other intervening commands during "clean heads" - since
>seek() waits for seek complete, 150ms should be plenty of time for the
>controller to be ready for another command. This also does not explain why
>reading a disk would work, so I suspect there is some other factor involved
>This is the first I've heard of this problem - if you have problems with
>ImageDisk, the best way to get it fixed correctly might be to work with
>me on it instead of posting "fixes" to public forums. But... thats what
>happens when you release source code.
Ah, the step gremlin. It's an old 765(all!!!) problem. The problem is when
the step pulse is set to minimum acceptable for the drive it's possible that
due to internal timing of the 765 it can shorten the step timing of the
first pulse by 1 count. If that occurs many drives seek badly and you get
read or write errors because your not where you thought you were.
Note: some old drives due to the lubricants turning to goo will also exhibit
this type of error. There is one solution, step slower (SRT+1).
Another problem is the 765 was designed for 77track drives (8" floppy)
and there were no 80track minifloppies. So the Recal only issued
77 step pulses and would flag an see error if the drive was 80track.
One fix is to issue a new Recal and see if the drive properly homed
this time. The problem is there are some cores that fixed this and will
issue up to 256 step pulses. The problem can also arise when using
SA400/400L style drives ans some (not all) will jump track (loose
the groove on the positioner disk) if stepped too far past tracks
000 or 39.
Last gremlin is the 765(and cores) were designed to Seek/Recal up to 4
drives but PC hardware does not always decode this and may have drive 0
also appearing as drive 2 or 3 which makes it susceptable to being
repositioned by commands not intended for it.
More information about the cctalk