10 Jun
2010
10 Jun
'10
6:13 p.m.
The last two nights I've been busy archiving some of my Amiga floppy
collection. Most disks were written over 20 years ago.
On a sample size of about 150 floppies, most of them were perfectly
readable by my homegrown usb external amiga floppy drive controller.
I paid very close attention to the failures or ones where my controller
struggled.
Without sounding too obvious here, the time between the pulses (which
more or less define the data) were grossly out of spec. The DD pulses
should nominally be 4us, 6us, and 8us apart before pre-write
compensation. Most good disks are slightly faster, and normal times for
these ranges are:
4us: 3.2-4.2us. Many around 3.75us
6us: 5.5-6.2us.
8us: 7.5-8.2us
(notice margins around 1-1.3us)
My original microcontroller implementation was 3.2-4.2, 5.2-6.2, and
7.2-8.2.
When my current FPGA controller would have a problem, I'd notice that
there were problems right on a boundary. So maybe pulses were coming in
at 3.1us apart instead of 3.2. Or maybe 4.3 instead of 4.2. So I kept
bumping the intervals apart, making a larger range of pulse times
acceptable --- the XOR sector checksums were passing, so I was likely
making the right choices. The bits were ending up in the right buckets.
But as I went through some of these disks, I ended up with the
difference between ranges(and basically my noise margin) being reduced
smaller and smaller. Some to the point where an incoming pulse time
might fall darn smack in the middle of the noise margin. Which bucket
does THAT one go into?
My approach has been very successful(easily 95%+), but it makes me
wonder about Phil's DiscFerret dynamic adaptive approach where a sample
of the incoming data defines the ranges.
Some disk drives and controllers might be faster or slower than others,
and if you create custom ranges for each disk (each track?), perhaps
you'll have better luck.
Keith
10 Jun
10 Jun
6:39 p.m.
On 10 Jun 2010 at 18:13, Keith wrote:
Some disk drives and controllers might be faster or
slower than
others, and if you create custom ranges for each disk (each track?),
perhaps you'll have better luck.
Just so--and it might even be good to derive your ranges for
individual sectors. I'm working with a bunch of 8" samples this week
from some manufacturing equipment and it's
perfectly obvious that
some sectors were rewritten by a somewhat out-of-spec drive.
Since
this is an 8" drive with a line-powered AC motor, my suspicion is a
slipping belt or a dry bearing.
--Chuck
6:45 p.m.
On 6/10/10, Chuck Guzis <cclist at sydex.com> wrote:
On 10 Jun 2010 at 18:13, Keith wrote:
Except that Amigas read and write an entire track in one pass, unlike
most disk schemes.
You might see variation from track to track, though.
-ethan
Some disk drives and controllers might be faster
or slower than
others, and if you create custom ranges for each disk (each track?),
perhaps you'll have better luck.
Just so--and it might even be good to derive your ranges for
individual sectors. 
6:46 p.m.
Keith wrote:
Without sounding too obvious here, the time between the pulses (which
more or less define the data) were grossly out of spec. The DD pulses
should nominally be 4us, 6us, and 8us apart before pre-write
compensation. Most good disks are slightly faster, and normal times
for these ranges are:
4us: 3.2-4.2us. Many around 3.75us
6us: 5.5-6.2us.
8us: 7.5-8.2us
(notice margins around 1-1.3us)
My original microcontroller implementation was 3.2-4.2, 5.2-6.2, and
7.2-8.2.
When my current FPGA controller would have a problem, I'd notice that
there were problems right on a boundary. So maybe pulses were coming
in at 3.1us apart instead of 3.2. Or maybe 4.3 instead of 4.2. So I
kept bumping the intervals apart, making a larger range of pulse times
acceptable --- the XOR sector checksums were passing, so I was likely
making the right choices. The bits were ending up in the right buckets.
But as I went through some of these disks, I ended up with the
difference between ranges(and basically my noise margin) being reduced
smaller and smaller. Some to the point where an incoming pulse time
might fall darn smack in the middle of the noise margin. Which bucket
does THAT one go into?
My approach has been very successful(easily 95%+), but it makes me
wonder about Phil's DiscFerret dynamic adaptive approach where a
sample of the incoming data defines the ranges.
This is exactly why good floppy
controller hardware uses a PLL for data
recovery, rather than one-shots, simple state machines, and the other
approaches that were taken to save money, board space, etc.
My experiments with floppy data recovery in software used a simple DPLL,
and I found that it tracked the data much better than any simple
threshold scheme.
The best data separators actually used PLLs with two feedback paths with
different characteristics, one to track longer-term variation due to
motor speed, and one to track short-term effects.
Eric
7:31 p.m.
On 10 Jun 2010 at 15:46, Eric Smith wrote:
My experiments with floppy data recovery in software
used a simple
DPLL, and I found that it tracked the data much better than any simple
threshold scheme.
What I was trying to say, but in a rather roundabout way. Given
that most common floppy data separators can accommodate at least a +/-
10% variation (or more) in long-term speed variation, a too-slow
drive can easily write a sector that's way out-of-spec timing-wise on
a track that's otherwise perfectly in spec. It's necessary that any
read algorithm be able to adjust to short-term (sector-to-sector)
variations, as well as long-term (track to track) ones.
Given that you *know* the structure of a track ahead of time, there
should be no reason that your data recovery routines can't be *much*
better than the usual brain-dead floppy controller's efforts.
Ethan Dicks wrote:
Except that Amigas read and write an entire track in
one pass,
unlike most disk schemes.
Heh, there are a couple of other systems that do that (Commodore
didn't invent it). I've got an 8" hard-sectored floppy sitting on my
desk here, where the data for cylinder 9, complete with address ID is
duplicated on cylinder 3. Apparently there's no "look before you
write" in whatever wrote it.
--Chuck
11 Jun
11 Jun
1:12 p.m.
On 6/10/2010 7:31 PM, Chuck Guzis wrote:
What I was trying to say, but in a rather roundabout
way. Given
that most common floppy data separators can accommodate at least a +/-
10% variation (or more) in long-term speed variation, a too-slow
drive can easily write a sector that's way out-of-spec timing-wise on
a track that's otherwise perfectly in spec. It's necessary that any
read algorithm be able to adjust to short-term (sector-to-sector)
variations, as well as long-term (track to track) ones.
Chuck,
Thanks for the response. I know you've advanced this position before.
My relatively simple "time between pulses" method works probably 95% of
the time. It's getting this last 5% to read correctly where it looks
like I'll need some more sophisticated algorithms.
Thanks
Keith
1:51 p.m.
On 11 Jun 2010 at 13:12, Keith M wrote:
Thanks for the response. I know you've advanced
this position before.
My relatively simple "time between pulses" method works probably 95%
of the time. It's getting this last 5% to read correctly where it
looks like I'll need some more sophisticated algorithms.
Keith,
You should set your sights higher--you should be able to read 100% of
the floppies that are readable by the Commodore drive and a few that
the Commodore drive can't.
If you think about it a bit, you can do a substantially better job
with "problem disks'. For example (I'll use standard IBM 3740-type
format as a basis), if a legacy floppy controller mis-reads an ID
header, it will return a "Sector not found" type of error. However,
as a programmer you know what the disk layout is and what the sector
ordering should be--and approximately where any given sector should
be. So, to read the sector, you assume the contents of the ID header
and switch to looking for the closest DAM. There's your sector.
Take a look at some of the old Western Digitial FDC app notes,
particularly those for the 179x controllers for ideas on how data
separators can be implemented.
--Chuck
3:11 p.m.
Chuck Guzis wrote:
Take a look at some of the old Western Digitial FDC
app notes,
particularly those for the 179x controllers for ideas on how data
separators can be implemented.
Note that the only data separator worth a damn in the WDC app note are
the two that use PLLs. The most commonly used was the one in Figure 14
that uses a 74LS629 VCO and the phase comparator of the WD1691. The
circuit by MPI in Figure 13 that uses an MC4024 VCO looks OK but I
haven't seen it used. The rest are crap.
Figure 11 uses a one-shot, and won't work reliably even for single
density. It's comparable to the worthless data separator built into the
1771. Figure 12 uses a state machine and works approximately the same
way the Apple II read state machine works. It's probably good enough
for single density, but won't work reliably for double density.
Eric
5:12 p.m.
On 11 Jun 2010 at 12:11, Eric Smith wrote:
Note that the only data separator worth a damn in the
WDC app note are
the two that use PLLs. The most commonly used was the one in Figure
14 that uses a 74LS629 VCO and the phase comparator of the WD1691.
The circuit by MPI in Figure 13 that uses an MC4024 VCO looks OK but I
haven't seen it used. The rest are crap.
Figure 11 uses a one-shot, and won't work reliably even for single
density. It's comparable to the worthless data separator built into
the 1771. Figure 12 uses a state machine and works approximately the
same way the Apple II read state machine works. It's probably good
enough for single density, but won't work reliably for double density.
There seems to have been a general move toward "good enough" in the
early 80s. The first version of the IBM 5150 floppy controller used
an IBM hybrid-packaged design; the second version used conventional
TTL and a 4024 VCO that was good enough, but not as good as the first
version. I think later controllers (as used in the 5170) used the
all-digital WD9216 type of data seaparator. With the all-in-one FDCs
(WD37C65, N82077), the question of data separator design became a
nonstarter. Just plug it in with no adjustments needed.
I suppose "good enough" accurately describes the Apple II scheme;
"gutless wonder" would be another term that comes to mind. GCR with
the only error conrol being a one-byte arithmetic checksum on each
sector. Were there ever any "turbo" mods to run an Apple II at more
than 2MHz without breaking the floppy logic?
--Chuck
5:37 p.m.
On 06/11/2010 02:12 PM, Chuck Guzis wrote:
I think later controllers (as used in the 5170) used
the
all-digital WD9216 type of data seaparator.
The SMC 9216 and 9229 (and the Western
Digital second-source) are
actually quite good. They use a DPLL. The 9239 uses an even better DPLL.
With the all-in-one FDCs
(WD37C65, N82077), the question of data separator design became a
nonstarter. Just plug it in with no adjustments needed.
Some of the all-in-ones used an analog PLL (notably the 279x), some a
DPLL. I've never had any trouble with them, so I think they're probably
designed reasonably well.
I suppose "good enough" accurately describes
the Apple II scheme;
"gutless wonder" would be another term that comes to mind.
I would argue
that it's some of the best engineering ever, bearing in
mind that all engineering involves tradeoffs. (I would argue that the
essence of engineering is knowing how to make the tradeoff of getting
the best design for the constraints, including the manufacturing cost.)
The GCR is being done at effectively the single-density flux-transition
timing, so doing a simple state-machine data separator (which is better
than a one-shot but not as good as a PLL) is actually adequate.
GCR with
the only error conrol being a one-byte arithmetic checksum on each
sector.
For a small sector size, a one-byte checksum isn't that bad.
Were there ever any "turbo" mods to run
an Apple II at more
than 2MHz without breaking the floppy logic?
No. You can't even run at 2 MHz. The accelerators all slow down to
normal Apple II speed (effectively 1.023 MHz average) for disk access.
The final disk controller Apple offered for the Apple II, the one that
could handle the high-density 3.5" "Apple Superdrive" (not to be
confused with their later DVD "Superdrive"), used an on-board 6502 core,
running at 2 MHz IIRC.
Eric
6:05 p.m.
On 11 Jun 2010 at 14:37, Eric Smith wrote:
I would argue that it's some of the best
engineering ever, bearing in
mind that all engineering involves tradeoffs. (I would argue that the
essence of engineering is knowing how to make the tradeoff of getting
the best design for the constraints, including the manufacturing cost.)
So the Commodore 1541 would, by that logic, be some of the worst
engineering ever? (Consider the complexity of what's in the box that
operates a single drive) :)
Given that, then one could extrapolate that engineering has nothing
whatever to do withe success or failure of a product.
(Where's my Coleco ADAM?)
--Chuck
7:18 p.m.
I would argue
that it's some of the best engineering ever, bearing in
mind that all engineering involves tradeoffs. (I would argue that the
essence of engineering is knowing how to make the tradeoff of getting
the best design for the constraints, including the manufacturing cost.)
So the Commodore 1541 would, by that logic, be some of the worst
engineering ever? (Consider the complexity of what's in the box that
operates a single drive) :) 
12 Jun
12 Jun
10:42 a.m.
At 06:18 PM 6/11/2010, Cameron Kaiser wrote:
I don't remember who said it, but I recall
someone(tm) (Bob Russell?) once
observing that the 1541 disk drive was the best computer Commodore ever made.
I remember (Amiga's) Jim Mackraz repeating that. I also remember pulling
a dissected 1541 from the Dumpster when Amiga Corp. Los Gatos closed.
- John
3:39 p.m.
I remember hearing that the Laserwriter was the
fastest, most powerful
computer that Apple made.
I beelvie that was true at one time. The Laserwriter had a 68000 clocked
at 12MHz, whilethe Macs of the period had 68000s clocked at 8MHz
While not fast, nor powerful, the model M keyboard was
the best product
that IBM made.
That's a very strong claim,; IBM must have made many thousands of
different products over the years.
-tony
3:22 p.m.
I don't remember who said it, but I recall
someone(tm) (Bob Russell?) once
observing that the 1541 disk drive was the best computer Commodore ever made.
Surely that should be said about something like the 8050, which had a
pair of 6502s inside, with shared memeory (its used the trick that the
6502 onlt accesses memeory druing one state of the clock line, so by
inverting the clock signal to one of the procerssors, they can trivially
share memeory.
-tony
11 Jun
11 Jun
9:05 p.m.
On 11 Jun 2010 at 14:37, Eric Smith wrote:
No. You can't even run at 2 MHz. The
accelerators all slow down to
normal Apple II speed (effectively 1.023 MHz average) for disk access.
Right. Looking back at my "Understanding the Apple IIe", the
sequencer runs at 2MHz and the 6502, half that. But the recording
wasn't what I'd call "single density", which to me implies FM. It's
definitely 5-of-8 or 6-of-8 GCR.
--Chuck
12 Jun
12 Jun
6:09 p.m.
On 06/11/2010 06:05 PM, Chuck Guzis wrote:
On 11 Jun 2010 at 14:37, Eric Smith wrote:
I never said it was. I said that it used the same flux-transition
timing as single density, thus the requirements for a reliable data
separator are more akin to those of single density than double density.
Eric
No. You can't even run at 2 MHz. The
accelerators all slow down to
normal Apple II speed (effectively 1.023 MHz average) for disk access.
Right. Looking back at my "Understanding the Apple IIe", the
sequencer runs at 2MHz and the 6502, half that. But the recording
wasn't what I'd call "single density", which to me implies FM.
11 Jun
11 Jun
5:39 p.m.
On Fri, 11 Jun 2010, Chuck Guzis wrote:
I suppose "good enough" accurately describes
the Apple II scheme;
"gutless wonder" would be another term that comes to mind. GCR with
the only error conrol being a one-byte arithmetic checksum on each
sector. Were there ever any "turbo" mods to run an Apple II at more
than 2MHz without breaking the floppy logic?
Weren't the Zip Chip and Rocket Chip good enough to not cause problems
like that?
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
5:43 p.m.
On 06/11/2010 02:39 PM, David Griffith wrote:
On Fri, 11 Jun 2010, Chuck Guzis wrote:
Yes, by slowing the clock to normal speed for some interval after every
access to the floppy controller I/O ports (usually C0E0..C0EF).
Eric
Were there ever any "turbo" mods to run
an Apple II at more
than 2MHz without breaking the floppy logic?
Weren't the Zip Chip and Rocket Chip good enough to not cause problems
like that?
12 Jun
12 Jun
8:48 a.m.
On Fri, 11 Jun 2010, David Griffith wrote:
On Fri, 11 Jun 2010, Chuck Guzis wrote:
More accurately stated, they were _smart_ enough to not cause problems by
detecting accesses to the diskette controller hardware and slowing down to
the base 1Mhz. clock rate for a short period of time.
Steve
--
I suppose "good enough" accurately
describes the Apple II scheme;
"gutless wonder" would be another term that comes to mind. GCR with
the only error conrol being a one-byte arithmetic checksum on each
sector. Were there ever any "turbo" mods to run an Apple II at more
than 2MHz without breaking the floppy logic?
Weren't the Zip Chip and Rocket Chip good enough to not cause problems like
that? 
11 Jun
11 Jun
6:51 p.m.
Chuck Guzis wrote:
I suppose "good enough" accurately describes
the Apple II scheme;
"gutless wonder" would be another term that comes to mind. GCR with
the only error conrol being a one-byte arithmetic checksum on each
sector. Were there ever any "turbo" mods to run an Apple II at more
than 2MHz without breaking the floppy logic?
I don't know about the ][ itself, but the ZipChip accelerator for the
//c runs at 4MHz with the floppy operating correctly.
Peace... Sridhar
12 Jun
12 Jun
8:55 a.m.
On Fri, 11 Jun 2010, Sridhar Ayengar wrote:
Chuck Guzis wrote:
As I metioned in a response to the original post, all A2 accelerators that
I'm aware of slow to 1Mhz. for GCR floppy access.
The only exception might be the internal logic for the original Unidisk
3.5" drive. It used an embedded 65C02 and could read entire tracks at a
time. However, it relied on very conservative 4:1 physical sector
skewing.
For the IIGS, Apple developed a custom ASIC for diskette I/O that I
believe could operate at a 2Mhz. clock. With the newer "dumb" 3.5" Apple
drives, it was capable of reading track-at-a-time with 2:1 interleave.
The fun started when you read such a diskette on a Unidisk 3.5 :-) It got
2x slower than usual due to an extra rotation between every sector
transfer. Even on the IIGS, accelerator cards slowed to the "as designed"
clock speed for diskette I/O.
Steve
--
I suppose "good enough" accurately
describes the Apple II scheme;
"gutless wonder" would be another term that comes to mind. GCR with
the only error conrol being a one-byte arithmetic checksum on each
sector. Were there ever any "turbo" mods to run an Apple II at more
than 2MHz without breaking the floppy logic?
I don't know about the ][ itself, but the ZipChip accelerator for the //c
runs at 4MHz with the floppy operating correctly.
13 Jun
13 Jun
1:32 p.m.
On 06/12/2010 05:55 AM, Steven Hirsch wrote:
For the IIGS, Apple developed a custom ASIC for
diskette I/O that I
believe could operate at a 2Mhz. clock.
Same "IWM" ASIC they used in the Apple IIc, Lisa 2, Mac, etc.
It can operate at 2 MHz, but not when running the same old RWTS code (or
the ProDOS or GS/OS equivalents). The IIgs slows to 1 MHz for 5.25-inch
disk access, same as the other models. Not sure about 3.5-inch disk
access. IIRC, the higher-speed choice on the IIgs is 2.8 MHz, but it is
forced to slow down to 1 MHz for bus access, including most of the
internal peripherals such as the IWM.
Eric
12 Jun
12 Jun
2:22 p.m.
On 06/11/2010 03:51 PM, Sridhar Ayengar wrote:
I don't know about the ][ itself, but the ZipChip accelerator for the
//c runs at 4MHz with the floppy operating correctly.
Maybe when accessing a
3.5" drive, I'm not sure, but it slows down to 1
MHz to access 5.25" drives.
2:53 p.m.
Chuck Guzis wrote:
You should set your sights higher--you should be able
to read 100% of
the floppies that are readable by the Commodore drive and a few that
the Commodore drive can't.
If you think about it a bit, you can do a substantially better job
with "problem disks'.
You're absolutely right, and this is why I'm posting. :)
A lot of the datasheets, and app notes, etc are just slightly beyond my
current experience. I'm working on it. :)
Thanks for the comments.
Keith
11 Jun
11 Jun
11:58 p.m.
Here's a great document that addresses the floppy data separator in
detail:
http://www.nalanda.nitc.ac.in/industry/appnotes/Natsemi/AN-505.pdf
Weird that it's not on the National site--but here it is, from India,
no less.
Wonder if someone could lean on the suits at National to leave all of
their old app notes online? It can't use that much space and there's
a lot of good information in them, even the old ones.
--Chuck
12 Jun
12 Jun
12:30 a.m.
Here's another paper that concerns itself with the design of a
digital data separator:
http://hungngo-asic-design.tripod.com/Chip_Tech_HDD_paper.pdf
--Chuck
3:18 p.m.
Chuck Guzis wrote:
Here's another paper that concerns itself with the
design of a
digital data separator:
http://hungngo-asic-design.tripod.com/Chip_Tech_HDD_paper.pdf
--Chuck
Thanks Chuck for the links.
Keith
13 Jun
13 Jun
11:39 a.m.
From: cclist at sydex.com
Here's another paper that concerns itself with the design of a
digital data separator:
http://hungngo-asic-design.tripod.com/Chip_Tech_HDD_paper.pdf
--Chuck
Hi
This paper got me thinking a little. With digitized data,
it should be possible to not only correct for bit shift in
mild cases but also detect when it is so sever that
there is an error.
My understanding is that bit shift is a phase error that
looks like the response is too slow. In other words
two pulse getting too close tend to spread apart.
It seems one can create a number of FIR filters to
analyze the data. Some with corrections for to much
precompensation and others with correction for too
little. You then just feed them all in parallel and pick the
one for that tracks with the least timing error, for
that particular track.
This is something that can not be done inthe analog
world because analog tends to be IIR and not FIR.
In the article you've posted, they've oversampled
by 32 ( 5 bits ). It is a bit high for most but I suspect a sampling
system of maybe 8 is more practical for our use.
This way, one could tune for the bit shift seem on
each track, which should be similar. Also, one
could keep track of errors, such as knowing when
a pulse was missed and use that to correct if and
error was detected.
Dwight
_________________________________________________________________
The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=…
11 Jun
11 Jun
1:06 p.m.
On 6/10/2010 6:46 PM, Eric Smith wrote:
This is exactly why good floppy controller hardware
uses a PLL for data
recovery, rather than one-shots, simple state machines, and the other
approaches that were taken to save money, board space, etc.
My experiments with floppy data recovery in software used a simple DPLL,
and I found that it tracked the data much better than any simple
threshold scheme.
Can you please give me an approximate idea of how you did this? Did you
have a counter, then constantly adjust the output based on the time of
arriving pulses? Got any psuedocode? :)
Thanks
Keith
2:59 p.m.
On 06/11/2010 10:06 AM, Keith M wrote:
Can you please give me an approximate idea of how you
did this? Did
you have a counter, then constantly adjust the output based on the
time of arriving pulses?
Yes. a variable for the period (inverse of frequency), and a counter
for the phase. At each iteration the period is added to the phase
counter. The phase counter is used to identify the windows for the
pulses. When the leading edge of a pulse is detected, the amount of
time before or after the nominal location in which the pulse is expected
is the phase error. (Note that the absence of a pulse is not considered
to have a phase error of zero.) For a second-order DPLL, the phase
error is filtered to adjust both the period and the phase; the transfer
functions of the filter are the critical adjustments.
I had two coefficients I called alpha and beta. These were just my
names for them; there are probably official names for them in control
theory, but I haven't looked into what they would be. What I did was:
period := period + alpha * phase_error;
phase := phase + beta * phase_error;
Both alpha and beta should be very small, e.g., under 0.01. For a
first-order DPLL, beta would be zero. Non-zero beta provides for better
tracking of instantaneous phase changes, but if it is too high, causes
the jitter to have more effect on the period.
Using control theory it is possible to do an analysis of the performance
of the DPLL, but that seemed like too much work to me, so I just
experimented with the parameters manually.
Eric
12 Jun
12 Jun
10:03 p.m.
Eric Smith wrote:
On 06/11/2010 10:06 AM, Keith M wrote:
> Can you please give me an approximate idea of how you did this? Did
> you have a counter, then constantly adjust the output based on the
> time of arriving pulses?
Eric, thanks for the detailed response.
I'm still new to many of the concepts so please bear with me.
Yes. a variable for the period (inverse of
frequency), and a counter
for the phase. At each iteration the period is added to the phase
counter. The phase counter is used to identify the windows for the
pulses.
So my nominal frequency is 500khz, with my period being 2us. The actual
window is the duration in which if a pulse occurs within it, it produces
a valid raw mfm bit(aka a '1' bit)? And if no pulse is received in that
window, then we assume a '0' bit?
So then how big would my window be? 2us? The pulse produced by most
drives are around 250-350ns.
When you say at each iteration, do you mean each received pulse?
I'm working with a 50mhz system clock, so my clock ticks are at 20ns.
If we are adding the period to phase counter, then it sounds like the
phase counter would be decrementing. We want to detect the edge in the
middle of the window, so the trigger point for "window open" might be
0+(1/2 window size), with the "window closed" point being at 0-(1/2
window size) or something.
When the leading edge of a pulse is detected, the
amount of
time before or after the nominal location in which the pulse is expected
is the phase error.
Makes sense.
(Note that the absence of a pulse is not considered
to have a phase error of zero.)
I really have to do more reading on this.
For a second-order DPLL, the phase
error is filtered to adjust both the period and the phase; the transfer
functions of the filter are the critical adjustments.
I had two coefficients I called alpha and beta. These were just my
names for them; there are probably official names for them in control
theory, but I haven't looked into what they would be. What I did was:
period := period + alpha * phase_error;
phase := phase + beta * phase_error;
And so your alpha and beta just prevent a large phase error from
immediately throwing around the window. It takes many similar large
phase errors to adjust the window by the whole phase error amount.
If my period is already adjusted for the phase error, and added to the
phase counter, why are we now modifying the phase counter again with
phase error? We modify the long term period (frequency) AND make sure
that the current cycle gets the adjustment too?
Thanks
Keith
13 Jun
13 Jun
1:41 a.m.
On 06/12/2010 07:03 PM, Keith wrote:
I got an extra "not" in there. The absence of a pulse has an effective
phase error of zero; it doesn't cause any adjustment to the PLL.
So then how big would my window be? 2us?
For adjusting the PLL, you can interpret the window as zero-length. The
leading edge of the pulse is always either before or after the window by
some length. However, you're doing some sort of time quantization, so
there will be some point at which you can't tell which, so you consider
the error to be zero.
The pulse produced by most drives are around
250-350ns.
The pulse width doesn't tell you anything. Only the leading edge of the
pulse is significant. The drive electronics has a one-shot that
generates the pulse when it sees a flux transition.
When you say at each iteration, do you mean each
received pulse?
No. The PLL is free-running. There is a pulse window every 2 us (or
whatever), so the PLL period is going to be approximately 2 us.
(Note that
the absence of a pulse is not considered to have a phase
error of zero.)
I really have to do more reading on this.
If my period is already adjusted for the phase error, and added to the
phase counter, why are we now modifying the phase counter again with
phase error? We modify the long term period (frequency) AND make sure
that the current cycle gets the adjustment too?
To better track ISV. However,
setting beta to zero may be reasonable.
Eric
2:21 a.m.
It should be observed that the typical "time since last pulse" sort
of data collection done by most of these things (e.g. Catweasel) and
inerpreted by a "threshold" sort of algorithm does constittute a PLL
of sorts, since phase errors tend to self-correct long-term speed
variations (i.e. every sample is relative only to the previous one).
In other words, if the drive is spinning too slowly and pulses (1t,
1.5t and 2t for MFM) come a bit late, the error isn't cumulative.
FWIW,
Chuck
3:03 a.m.
On 06/12/2010 11:21 PM, Chuck Guzis wrote:
It should be observed that the typical "time
since last pulse" sort
of data collection done by most of these things (e.g. Catweasel) and
inerpreted by a "threshold" sort of algorithm does constittute a PLL
of sorts, since phase errors tend to self-correct long-term speed
variations (i.e. every sample is relative only to the previous one).
In other words, if the drive is spinning too slowly and pulses (1t,
1.5t and 2t for MFM) come a bit late, the error isn't cumulative.
It's not a PLL since it doesn't even try to adjust the frequency to
maintain phase lock. It only changes the instantaneous phase. There's
no "Loop" in it, nor "Lock".
Eric
2:28 p.m.
On 13 Jun 2010 at 0:03, Eric Smith wrote:
It's not a PLL since it doesn't even try to
adjust the frequency to
maintain phase lock. It only changes the instantaneous phase.
There's no "Loop" in it, nor "Lock".
I'll agree that it takes a mental stretch, but there is a "lock". and
a "loop" is easy enough to incorporate.
Play along with me on this one. I'll use a Catweasel for my model,
since it's most familiar to people.
Suppose there is a Catweasel reading a disk at 50t (the reference
frequency), where t is the assumed "short" inerval of an MFM stream.
That means that the center points of the sampling windows are 50t,
75t and 100t. Let's also assume some finite sample window size that
allows for capture of a sample on either side of the window center,
plus or minus a fixed number of counts. Note that there is a 1-count
"jitter" in the Catweasel hardware, where a pulse arriving at 50t can
be reported as 49t, as well as 50t; let's assume that the windows are
wide enough to accomodate that.
What's lacking is "loop" or feedback term to adjust window centers to
track variations in speed. Without it, this is no better than the
average UART receiver.
However, there is also an error quantity. Just as one can take the
error signal from a traditional PLL and estimate the spindle speed of
the drive, so can one sum the intervals reported by the Catweasel and
compare it with an ideal and obtain the spindle speed of the drive.
On a per-sample basis, one can compare the value of the sample with
its corresponding window center to obtain an error value.
Thus, one can take this error value and adjust the sampling window
centers appropriately, giving a "loop" and a "lock" to the incoming
data stream.
Thus, one has a reference, a lock, and a loop based on an error
value. Maybe not a PLL in the strict sense, but something that
shares the characteristics of one.
--Chuck
14 Jun
14 Jun
4:54 p.m.
On 06/13/2010 11:28 AM, Chuck Guzis wrote:
Play along with me on this one.
Well, yes, if you elaborate on the design until it is a PLL, then it is
a PLL. The point I was disagreeing with is that using a fixed frequency
and only adjusting the instantaneous phase when a pulse occurs is a
simple kind of PLL, since it isn't.
Eric
11 Jun
11 Jun
6:08 p.m.
On 10/06/10 23:13, Keith wrote:
My original microcontroller implementation was
3.2-4.2, 5.2-6.2, and
7.2-8.2.
You're using fixed-position analysis? That is, "if the pulse was between
X and Y us after the last pulse, it was a 01" and so on?
The problem with that is you'll have issues with Instantaneous Speed
Variation (and possibly Continuous Speed Variation). Basically:
* A floppy drive motor does not rotate at a constant speed.
* Some drives are faster than others (this is CSV)
* The friction between the disc and the head (and/or the disc liner)
can, will and *does* make the motor slow down. The variations in this
are called "ISV".
This is why a PLL is required -- to keep track of the ISV and eliminate
it (or get close to eliminating it) from the measurements.
My approach has been very successful(easily 95%+), but
it makes me
wonder about Phil's DiscFerret dynamic adaptive approach where a sample
of the incoming data defines the ranges.
DFA (DiscFerret Analyser) gets a similar success rate. I'm having issues
setting the coefficients for the "soft-PLL" -- make the PLL too slow and
it misses ISV, make it too fast and it'll track the data not the ISV.
You could probably implement a version of the PLL from the WDC 1797
appnote if you wanted -- that should be fairly easy to do. Here are a
few references which might help out:
ftp://ftp.eskimo.com/u/m/mzenier/AN917.pdf -- Motorola AN917. This is
read-channel stuff mostly, but IIRC it has a bit about encoding too.
ftp://ftp.eskimo.com/u/m/mzenier/cd-8002-1.pdf -- "Encoding/Decoding
Techniques Double Floppy Disc Capacity" by Hoeppner and Wall. Computer
Design, Feb 1980. A great little introduction to MFM data storage.
<http://bitsavers.org/pdf/westernDigital/FD179X_Application_Notes_Jun80.pdf>
-- WD FD179x Application Notes. A couple of data separator designs, and
some of the background info.
<http://www.analog-innovations.com/SED/FloppyDataExtractor.pdf>
Jim Thompson at Analog Innovations came up with a neat little data
separator called a "phase jerked loop" -- this is the schematic of a PJL
data separator, similar to the datasep engine used in the DiscFerret.
Difference is that the DF's separator is a synchronous design, while the
PJL is partially asynchronous.
I seem to recall there being a (WD?) application note or datasheet that
basically said one of the WD controller chips' built-in data separators
shouldn't be used because it wasn't reliable... I wish I could find a
reference for that.. :)
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
6:38 p.m.
On 11 Jun 2010 at 23:08, Philip Pemberton wrote:
I seem to recall there being a (WD?) application note
or datasheet
that basically said one of the WD controller chips' built-in data
separators shouldn't be used because it wasn't reliable... I wish I
could find a reference for that.. :)
WD1771 application note, under "Data Seperation"(sic) "...and (sic)
external data seperator (sic) is recommended." Actually, the number
of (sics) in that AN probably sets some sort of record.
And yet, I've run across several systems (wasn't the TRS-80 Mod I one
of them?) that blithely ignored this recommendation.
--Chuck
12 Jun
12 Jun
9:21 p.m.
Philip Pemberton wrote:
On 10/06/10 23:13, Keith wrote:
Phil,
I don't know what's it's technically called, but yes.
As I mentioned, it actually works pretty well. I open up the intervals
and make it pretty liberal on what it accepts. As far as I know, I
don't think I've opened them up enough that I incorrectly categorize a
pulse incorrectly. But I am starting to be close to that, and there's
likely a reason why everyone here (and most commercial FDCs) implement
some type of PLL.
I'm definitely up for increasing the robustness of my project.
My original microcontroller implementation was
3.2-4.2, 5.2-6.2, and
7.2-8.2.
You're using fixed-position analysis? That is, "if the pulse was between
X and Y us after the last pulse, it was a 01" and so on? The problem with that is you'll have issues with
Instantaneous Speed
Variation (and possibly Continuous Speed Variation). Basically:
* A floppy drive motor does not rotate at a constant speed.
* Some drives are faster than others (this is CSV)
* The friction between the disc and the head (and/or the disc liner)
can, will and *does* make the motor slow down. The variations in this
are called "ISV".
I've read about these before. When you say the drive motor doesn't
rotate at a constant speed, you mean that despite it having an average
of 300 rpm, that there is some speed up and slow down throughout a
single revolution? I've measured time between index pulses, and so far
they appear to be 200.x ms.
I've seen this called MSV, motor speed variation, too. (In the AN-505
PDF) AN-505 also says MSV is 1-2% and 1-2% for ISV.
This is why a PLL is required -- to keep track of the
ISV and eliminate
it (or get close to eliminating it) from the measurements.
My original plan was that these variations could be accounted for with
simply expanding my tolerances. And there's no doubt that my method
does handle _some_ of this. I can handle 5-10% differences pretty
easily. The worst cases though definitely reveal the lack of more
intelligent handling.
DFA (DiscFerret Analyser) gets a similar success rate.
I'm having issues
setting the coefficients for the "soft-PLL" -- make the PLL too slow and
it misses ISV, make it too fast and it'll track the data not the ISV.
Do you have your code up someplace? Verilog or VHDL?
Thanks for all the links, they should be valuable. I'm still working on
the basic concepts of a PLL. Once I get a better handle, I think
writing the code for a basic one should be within my reach.
Thanks
Keith
13 Jun
13 Jun
5:03 a.m.
On 13/06/10 02:21, Keith wrote:
OK, same as my "proof of concept" analyser then.
What I'm doing is a histogram analysis, followed by a peak-detect, and
then picking the centre points between the peaks as the thresholds.
Problem is, this only corrects for MSV. On a disc which has been written
with pre-compensation, this is (usually) fine. Without precomp, or on an
old disc which is suffering from bit-shift, it's a whole different ball
game.
You're
using fixed-position analysis? That is, "if the pulse was
between X and Y us after the last pulse, it was a 01" and so on?
I don't know what's it's technically called, but yes. I've read about these before. When you say the
drive motor doesn't
rotate at a constant speed, you mean that despite it having an average
of 300 rpm, that there is some speed up and slow down throughout a
single revolution?
That's ISV (Instantaneous Speed Variation). MSV and ISV are two
different things. ISV is usually caused by variations in friction in the
disc mechanism. MSV is a bit different -- that's a difference in the
average speed and varies on a per-drive basis.
A lot of older drives (Amstrad 3" drives in particular) used motors
which had a small speed-adjust screw. A single drive could be adjusted
by a few percent relative to another. On modern drives, the speed is
locked against a quartz crystal or a ceramic resonator, and is typically
much more accurate. There's still a several-digit-PPM variation between
drives though.
I've measured time between index pulses, and so
far
they appear to be 200.x ms.
200.0 is your target but some variation is normal. Hook up a frequency
counter with a serial or HPIB output and plot the time for each rotation
on a graph. It won't be a straight line...
Do you have your code up someplace? Verilog or VHDL?
I can't release the software source as yet, because it's part of my
final-year university project. The Verilog code is open, though, but I
haven't set the version control repository as public yet.
Thanks for all the links, they should be valuable.
I'm still working on
the basic concepts of a PLL. Once I get a better handle, I think writing
the code for a basic one should be within my reach.
Also look up Roman Black's Bresenham Timer algorithm --
http://romanblack.com/one_sec.htm
I've been thinking about how this looks like it could be used as a PLL
(you'd probably need two phase-accumulators, one driven by the incoming
data), but haven't really spent much time on implementation...
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
5114
days inactive
5118
days old
41 comments
13 participants
participants (13)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
cisin＠xenosoft.com -
classiccmp＠philpem.me.uk -
dgriffi＠cs.csubak.edu -
dkelvey＠hotmail.com -
eric＠brouhaha.com -
ethan.dicks＠gmail.com -
jfoust＠threedee.com -
keithvz＠verizon.net -
ploopster＠gmail.com -
snhirsch＠gmail.com -
spectre＠floodgap.com