27 Jul
2007
27 Jul
'07
10:28 a.m.
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>
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.
Allison
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
here..
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.