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. 
28 Jul
28 Jul
4:37 a.m.
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).
A possibility - Christial, try using SR= to set the step rate slower.
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.
Yeah, known problem - I issue a second recal if the first does not
result in track-0. Agreed, with the "right" controller, and failure
mode, this can result in 512 step pulses going to the drive - not much
you can do.
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.
IMD only works on one drive at a time, and only issues one command at a
time.
Thanks for the input - I'll ask Christian to check out a slower step
rate.
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
7:28 a.m.
From: "Dave Dunfield" <dave06a at
dunfield.com>
Hi
One other thing. Ususally one doesn't see this one but on a machine I
put together, using a different processor, on one command I was
able to beet the busy response of the controller chip. It was on only
one command but I don't recall which command.
If the PC is running the bus faster than the 765 is clocking, one can
be too quick.
I recall putting a short delay to make sure the status read was coorrect.
I know it was this because I did an experiment that I'd read it twice.
The second read was OK but not the first.
Dwight
_________________________________________________________________
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_mig…
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).
A possibility - Christial, try using SR= to set the step rate slower.
30 Jul
30 Jul
12:52 p.m.
One other thing. Ususally one doesn't see this one
but on a machine I
put together, using a different processor, on one command I was
able to beet the busy response of the controller chip. It was on only
one command but I don't recall which command.
If the PC is running the bus faster than the 765 is clocking, one can
be too quick.
I recall putting a short delay to make sure the status read was coorrect.
I know it was this because I did an experiment that I'd read it twice.
The second read was OK but not the first.
Thanks - I hadn't thought about that, and I'll look into it. Funny thing
about PCs - slower CPU (even significantly slower) doesn't necessarily mean
slower time between I/O accesses... This could be a factor.
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
12:21 p.m.
On 30 Jul 2007 at 14:52, Dave Dunfield wrote:
Thanks - I hadn't thought about that, and I'll
look into it. Funny
thing about PCs - slower CPU (even significantly slower) doesn't
necessarily mean slower time between I/O accesses... This could be a
factor.
I'd suggest using a couple of transitions of the 50 usec. "refresh"
flag. It's part of the legacy PC design and is present on almost
anything PC-AT and later.
Simple and consistent without bothering with calibrating program
loops.
Cheers,
Chuck
12:33 p.m.
Chuck Guzis wrote:
On 30 Jul 2007 at 14:52, Dave Dunfield wrote:
I've never heard of this. Are you talking about monitoring a bit in the
8253?
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
Thanks - I hadn't thought about that, and
I'll look into it. Funny
thing about PCs - slower CPU (even significantly slower) doesn't
necessarily mean slower time between I/O accesses... This could be a
factor.
I'd suggest using a couple of transitions of the 50 usec. "refresh"
flag. It's part of the legacy PC design and is present on almost
anything PC-AT and later.
1:01 p.m.
On 30 Jul 2007 at 14:33, Jim Leonard wrote:
I've never heard of this. Are you talking about
monitoring a bit in
the 8253? -- Jim Leonard (trixter at oldskool.org)
Bit 4, port 61h. You can use a simple toggle test to see if it's
there, but on just about every system I've ever seen, it is. One of
the holdovers from the PC-AT architecture.
Cheers,
Chuck
1 Aug
1 Aug
4:56 p.m.
Chuck Guzis wrote:
On 30 Jul 2007 at 14:33, Jim Leonard wrote:
I was confused because I always thought this was the speaker read gate.
It seems we are both right (the AT and later works as you describe;
the PC/XT bits in that location are a speaker read latch). Here is some
information paraphrased from the PC Timing FAQ:
Bit 4 of Port B at I/O address 61 hex on an AT and later machine is a
read-only bit carrying a signal called Refresh Detect. This signal comes
I've never heard of this. Are you talking
about monitoring a bit in
the 8253?
Bit 4, port 61h. You can use a simple toggle test to see if it's
there, but on just about every system I've ever seen, it is. One of
the holdovers from the PC-AT architecture. from a 'T' (toggle) flip-flop which is clocked
by the refresh trigger
signal, which comes from CTC channel one. Assuming that the
RAM refresh
rate has not been changed, this bit will toggle (change from 0 to 1 or
from 1 to 0) once every 15.0857 microseconds (the exact
value is
216/14.31818), and Port B can be polled in a loop to implement a delay
of any length. For short delays, with interrupts locked out, this gives
an accurate and very convenient relative delay mechanism. However, for
long delays, it would be naughty to leave interrupts locked out for the
entire delay period, and interrupts will cause gaps in the polling
process, slightly lengthening the delay (it will wait longer than expected).
There are several caveats. This method will not work on PCs and XTs.
Also it will not work in an environment where Port B is emulated (for
example, under OS/2 and probably any other virtual DOS machine). If the
DRAM refresh period has been changed, the timing will be changed
proportionately. Finally, Microchannel PS/2 architecture may not
emulate this bit properly due to the level triggering they use.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
7:03 p.m.
On 1 Aug 2007 at 18:56, Jim Leonard wrote:
Bit 4 of Port B at I/O address 61 hex on an AT and
later machine is a
read-only bit carrying a signal called Refresh Detect. This signal
comes from a 'T' (toggle) flip-flop which is clocked by the refresh
trigger signal, which comes from CTC channel one. Assuming that the
RAM refresh rate has not been changed, this bit will toggle (change
from 0 to 1 or from 1 to 0) once every 15.0857 microseconds (the exact
value is 216/14.31818), and Port B can be polled in a loop to
implement a delay of any length. For short delays, with interrupts
locked out, this gives an accurate and very convenient relative delay
mechanism. However, for long delays, it would be naughty to leave
interrupts locked out for the entire delay period, and interrupts will
cause gaps in the polling process, slightly lengthening the delay (it
will wait longer than expected).
I believe I mentioned that it wasn't present on the PC-XT and that it
was AT-and later. In any case, it's easy--a simple 65K loop
checking this bit for toggling will root out the aberrent machines.
Fortunately for everyone, these are mostly the slower (x88/86/186)
systems that are very amenable to a simple counted CPU loop.
When I do my delay, I wait for the bit to flip once, then again, then
again. Simple--even my old NT and 98 diskette device drivers worked
with it.
Cheers,
Chuck
11:09 p.m.
Chuck Guzis wrote:
When I do my delay, I wait for the bit to flip once,
then again, then
again. Simple--even my old NT and 98 diskette device drivers worked
with it.
What about interrupt jitter? Or did you lock out certain interrupts
while you were measuring?
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
11:29 p.m.
On 2 Aug 2007 at 1:09, Jim Leonard wrote:
Chuck Guzis wrote:
With the 765, jitter and intervening interrupts is immaterial. You
need the delay when issuing commands and reading status to ensure
that a *minimum" time has passed. If an interrupt intervenes, it's
immaterial, as you've satisfied the minimum delay criterion.
If you needed absolute precision, I suppose you could mask or disable
interrupts, but in the case of disk commands, it's not necessary.
Cheers,
Chuck
When I do my delay, I wait for the bit to flip
once, then again, then
again. Simple--even my old NT and 98 diskette device drivers worked
with it.
What about interrupt jitter? Or did you lock out certain interrupts
while you were measuring?
6128
days inactive
6134
days old
10 comments
5 participants
participants (5)
-
ajp166＠bellatlantic.net -
cclist＠sydex.com -
dave06a＠dunfield.com -
dkelvey＠hotmail.com -
trixter＠oldskool.org