Floppy disk (MFM) data separator design?

[Philip Pemberton]

In message <[email protected]>

I'm not sure whether your floppy controller wants to see the encoded data
(as Jim's PLL data recovery circuit produces) or whether it wants to see
the recovered data.

Here's an extract from the Rockwell R6765 datasheet (the NEC uPD765 datasheet
says basically the same thing IIRC):
RDD: Read Data.
Read Data input from the floppy disk drive (FDD) containing clock and data
bits.
RDW: Read Data Window.
Data Window input generated by the Phase Locked Loop (PLL) and used to
sample data from the FDD.
VCO: Voltage Controlled Oscillator Sync
This output signal inhibits the VCO in the PLL circuit when low and enables
the VCO in the PLL circuit when high. This inhibits RDD and RDW from being
generated until valid data is detected from the FDD.

If it expects the data separator circuit to
decode the data before sending it to the controller, then you'll need to
add the address mark detector and a divide-by-2 for the clock going to the
data recovery flip-flop.

I honestly don't know what it expects. The designs I've seen use an
all-in-one data separator IC, i.e. the SED9420, UM8326, UM8329, FDC9216,
FDC9229 or UM9228.

Thanks.

 

[Mike]

In message <[email protected]>

Here's an extract from the Rockwell R6765 datasheet (the NEC uPD765 datasheet
says basically the same thing IIRC):
RDD: Read Data.
Read Data input from the floppy disk drive (FDD) containing clock and data
bits.

--> That's the key: it's a single line that contains clock and data. It
contains both because it hasn't been decoded.

RDW: Read Data Window.
Data Window input generated by the Phase Locked Loop (PLL) and used to
sample data from the FDD.

--> More on this below.

VCO: Voltage Controlled Oscillator Sync
This output signal inhibits the VCO in the PLL circuit when low and enables
the VCO in the PLL circuit when high. This inhibits RDD and RDW from being
generated until valid data is detected from the FDD.

I honestly don't know what it expects. The designs I've seen use an
all-in-one data separator IC, i.e. the SED9420, UM8326, UM8329, FDC9216,
FDC9229 or UM9228.

Thanks.

I scrounged up a uPD765 data sheet online, and I'm looking at figure 2,
"System Configuration," on page 5-18 (apparently it came from a databook).
It shows the FDD producing RDD, and a PLL in between the FDD and the uPD765
producing RDW.

Effectively, the floppy output is simply the output of a pulse detector,
which is simply a stream of pulses corresponding to magnetic transitions
(each transition will represent a 1 in the MFM code). That gets fed to the
PLL, which produces the RDW used to clock the data, and also gets fed to
the controller, which uses the RDW input to clock the RDD pulses.

Here's where things get strange. In the Timing Waveforms section, there is
a diagram showing the FDD Read Operation. There, it shows a narrow RDD
pulse in the middle of a half-RDW cycle. That's not the way HDD's ever
worked, but oh well. Jim's system can probably generate the necessary
signals with no problem, although you might have to grab the 'VCO' output
from a different phase of the '164.

What you don't need to do is decode the MFM data, find the address mark, or
anything else. Just send the RDD and RDW to the uPD765, and it should be
happy.

-- Mike --

 

[Philip Pemberton]

In message <[email protected]>

I scrounged up a uPD765 data sheet online, and I'm looking at figure 2,
"System Configuration," on page 5-18 (apparently it came from a databook).

I pulled a copy off Freetradezone (here's a hint - search for "E-Insite
Freetradezone" with google, hit the "I'm Feeling Lucky" button and work from
there). I've been working from Rockwell's R6765/R6265 datasheet. Basically
the same as NEC and SMsC's 765 datasheets, except for a few bits that are
clearer than others (and other bits that are about as clear as mud).

Here's where things get strange. In the Timing Waveforms section, there is
a diagram showing the FDD Read Operation. There, it shows a narrow RDD
pulse in the middle of a half-RDW cycle. That's not the way HDD's ever
worked, but oh well.

Surely you mean FDDs, not HDDs?

Jim's system can probably generate the necessary
signals with no problem, although you might have to grab the 'VCO' output
from a different phase of the '164.

VCO is an output from the 765 that is used to reset the VCO. I guess I'd
have to add something to clear the shift register when the VCO output on the
765 goes low. An AND gate and an inverter should do it.

What you don't need to do is decode the MFM data, find the address mark, or
anything else. Just send the RDD and RDW to the uPD765, and it should be
happy.

That's good. I can afford to waste (ho hum) a bit of space on the PCB with a
few 74TTL chips. I actually prefer 74TTL for most things except address
decoding. The address decoders I'm using are based on Lattice GALs.

Thanks.

 

[Uns Lider]

The catch is, most of the ones I've seen use the so-called "Super I/O" chips
with built-in address decoding. I want a chip I can shove on the bus, add an
address decoder, then just start sending commands to it.

Hard wire all but the low-order address inputs of the SuperIO to the 0x1f0 or
whatever it's looking for, and hook the read/write strobes to the output of
your external address decoder.

-- uns

 

[Mike]

In message <[email protected]>

I pulled a copy off Freetradezone (here's a hint - search for "E-Insite
Freetradezone" with google, hit the "I'm Feeling Lucky" button and work from
there). I've been working from Rockwell's R6765/R6265 datasheet. Basically
the same as NEC and SMsC's 765 datasheets, except for a few bits that are
clearer than others (and other bits that are about as clear as mud).

Surely you mean FDDs, not HDDs?

No - I worked mainly on HDDs, which is how I know they worked differently.
Here's the difference:

HDD
_________ _________
Data ___/ \___________________/ \_________
____ ____ ____ ____ ____
Clock ___/ \____/ \____/ \____/ \____/ \____

FDD (according to the uPD765 data sheet)
_____ _____
RDD _______/ \__________/ \______________________
______________ ______________
RDW ___/ \______________/ \____


In the FDD, RDW really is a window, not a clock. My guess is that they
either have an overclocked sampler in the 765 sampling RDD, or they just
use an SR flip-flop to grab the data, and the next clock edge to reset the
flip-flop.

VCO is an output from the 765 that is used to reset the VCO. I guess I'd
have to add something to clear the shift register when the VCO output on the
765 goes low. An AND gate and an inverter should do it.

When I said 'VCO', I meant the '164 in Jim's circuit. It's performing the
function of a VCO is a PLL, even though it's not voltage controlled (and
not even adjustable, except by increasing its length or changing its clock
rate).

In any event, since Jim follows the '164 with a TFF, there probably won't
be glitches at the output, even if you generate glitches when you reset the
'164.

That's good. I can afford to waste (ho hum) a bit of space on the PCB with a
few 74TTL chips. I actually prefer 74TTL for most things except address
decoding. The address decoders I'm using are based on Lattice GALs.

-- Mike --

 

[Jim Thompson]

In message <[email protected]>
Mike <[email protected]> wrote:

[snip]
In the FDD, RDW really is a window, not a clock.

That is correct.

My guess is that they
either have an overclocked sampler in the 765 sampling RDD, or they just
use an SR flip-flop to grab the data, and the next clock edge to reset the
flip-flop.


When I said 'VCO', I meant the '164 in Jim's circuit. It's performing the
function of a VCO is a PLL, even though it's not voltage controlled (and
not even adjustable, except by increasing its length or changing its clock
rate).

It's a PJL (phase-jerked-loop ;-) ...constant frequency but pulled to
correct the phase by the data pulses.

In any event, since Jim follows the '164 with a TFF, there probably won't
be glitches at the output, even if you generate glitches when you reset the
'164.


-- Mike --

...Jim Thompson

 

[Michael Black]

In message <[email protected]>

The formats were, IIRC:
3.5" DD - 720k
3.5" HD - 1.44MB
3.5" QD - 2.88MB
5.25" SD - 120k
5.25" DD - 360k
5.25" HD - 1.2MB

Later.

The problem is that the original line about "300K" was in reference
to the data rate from the drive to the controller. Everything else
is about disk capacity, which is a different thing.

Michael

 

[Michael Black]

They were 300 RPM...

Didn't the high density go to 360 RPMs?

Michael

 

[Mike]

It's a PJL (phase-jerked-loop ;-) ...constant frequency but pulled to
correct the phase by the data pulses.

Sounds like a trademark is in order.

I use the same thing today, but typically with 64 phases instead of 8, and
a loop filter in front of the phase selector. If the jitter from phase
stepping isn't unacceptable, and you can select phases fast enough to track
frequency offsets, it's a great system.

-- Mike --

 

[Jim Thompson]

Sounds like a trademark is in order.

I use the same thing today, but typically with 64 phases instead of 8, and
a loop filter in front of the phase selector. If the jitter from phase
stepping isn't unacceptable, and you can select phases fast enough to track
frequency offsets, it's a great system.

-- Mike --

Somewhere around here I have a design for a PJL that I did for a
satellite telephone. It features only small jerks allowed plus has
"freewheeling" mode where signal is locked out under noisy conditions.

...Jim Thompson

 

[Mark Zenier]

The missing information is how to synchronize to the data pattern so you
get the right bit. At the start of each sector, there's a preamble, which
is a simple repeating pattern that the PLL uses to acquire timing. After
that, there's an address mark, which is a fixed pattern that's different
than the preamble. The preamble and address mark are the same for every
sector on the disk. Following the address mark is the data - a fixed number
of bytes. Following the data are one or two CRC bytes to check for data
corruption.

Actually there are at least three different address marks, (all of which
violate the MFM encoding rules so that they can be easily detected by
hardware). One encoding for the sector's address record, one for the data
field, and one for "deleted" data fields. The deleted fields are now
used for marking bad sectors, but have had different uses. (The format
orginated with a pretty brainless data entry system to replace punched
cards.)


Mark Zenier [email protected] Washington State resident

 

[Fred Abse]

They were 300 RPM..

THAT'S what I was trying to remember.

 

[Mike]

Actually there are at least three different address marks, (all of which
violate the MFM encoding rules so that they can be easily detected by
hardware). One encoding for the sector's address record, one for the data
field, and one for "deleted" data fields. The deleted fields are now
used for marking bad sectors, but have had different uses. (The format
orginated with a pretty brainless data entry system to replace punched
cards.)

You're thinking of something different, or thinking of drives other than
those used in PCs. The MFM data separator chips I worked on didn't pass on
anything to the controller until after the address mark. There were two
possible address marks, as I recall, but the choice was hard wired by the
drive maker.

-- Mike --