9 Apr
2007
9 Apr
'07
7:13 p.m.
Hi folks,
I've got the first stage of my floppy disc reader working! Meaning, the
data separator and synchroniser works - I have a circuit that outputs a pulse
whenever the MFM 'magic sync sequence' (0x4489) is detected. In theory, I can
use that to sync the reader against sector boundaries on IBM-format discs, or
track boundaries on Amiga discs.
The data separator is an Verilog HDL reimplementation of the data separator
used in Petr Simandl's Sinclair Spectrum +2A floppy disc controller
(<http://www.simandl.cz/stranky/zxs/obrazky/zx_radic_89k.jpg>, but there's a
better quality schematic at <http://www.worldofspectrum.org/BackToThePlus3/>).
I'm driving the whole thing off a 32MHz TTL oscillator, divided down to 16MHz
for 3.5" DSHD, and 8MHz for 3.5" DSDD. I haven't tried FM encoded data yet,
though I have no reason to suspect it won't work, as long as I can figure out
what the clock divider needs to be set to.
I'm seriously miffed that I spent an afternoon trying to figure out why I
could get the separator to lock onto a DSDD disc but not a DSHD - seems most
of my DSHD discs are of marginal quality. The MPF920 in my desktop read them
fine, but the rather battered Panasonic JU-257A427P (complete with broken
drive door return spring) I was using with the FDR couldn't read them at all,
hence the huge number of SYNC pulses. Garbage in, garbage out.
I guess the next step is to do the RAM interface and bit timer, then the
MCU interface and firmware. The whole thing is currently squashed into a
Xilinx XC9572XL 3.3V CPLD, with a little room to spare for the acquisition
circuitry. The data-separator and sync detector are only using 29 of the 72
available logic macrocells, so I've probably got enough room for a 16-bit RAM
address latch, with space to spare. Can't really tell until I start
implementing it though.
Current power consumption is roughly 5V at 325mA while reading, according
to the display on my bench PSU.
For anyone who cares, I've thrown a couple of screenshots from my logic
analyser on my website:
Main blog entry:
<http://blog.philpem.me.uk/?p=129>
720k (250kbps) sync - with SYNC lagging by one DWIN transition:
<http://blog.philpem.me.uk/wp-content/uploads/2007/04/hpla-fdd-reader-syncing-against-720k-floppy.png>
<http://blog.philpem.me.uk/wp-content/uploads/2007/04/hpla-fdd-reader-syncing-against-720k-floppy-zoomed-long.png>
1.44MB (500kbps) sync - revised sync logic - SYNC doesn't lag now:
<http://blog.philpem.me.uk/wp-content/uploads/2007/04/hpla-fdd-reader-syncing-against-1440k-floppy.png>
If anyone wants to see the (messy) Verilog code I've got at the moment,
contact me off-list and I'll send you a copy. It's probably very badly
written, but it works.
The tool I used to grab the screenshots from the analyser (a HP 1651B) is
also due to go online 'at some point' (read: when I can be bothered to fix
some of the bugs)... It basically emulates a HP Thinkjet and converts the
graphics output into a .BMP file, which is then converted to a PNG with
Irfanview and PNGOUT.
If and when this project gets a bit further off the ground, I plan to set
up another mailing list to handle discussions related to the disc reader --
for now, though, I think it's probably best to keep the discussions on the
classiccmp list.
For anyone that cares, I'll be posting announcements on the 'floppy-reader'
mailing list on my server
(<http://mail.philpem.me.uk/mailman/listinfo/floppy-reader_philpem.me.uk>).
It's open-access, so anyone that feels like commenting is welcome to do so.
Thanks,
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
9 Apr
9 Apr
10:08 p.m.
On 10 Apr 2007 at 0:13, Philip Pemberton wrote:
I've got the first stage of my floppy disc
reader working! Meaning, the
data separator and synchroniser works - I have a circuit that outputs a pulse
whenever the MFM 'magic sync sequence' (0x4489) is detected. In theory, I can
use that to sync the reader against sector boundaries on IBM-format discs, or
track boundaries on Amiga discs.
Philip, it sounds like an interesting project. However, I've got an
itch in my brain that I can't seem to scratch. If you're doing bit
transition timings, why even bother to have an AM detector or data
separator? You can do all of that in software. Are you restricting
your design to MFM and FM encodings?
IWhat am I missing here?
Cheers,
Chuck
10 Apr
10 Apr
4:24 a.m.
Chuck Guzis wrote:
On 10 Apr 2007 at 0:13, Philip Pemberton wrote:
I suspect it's just to read disks that don't start the track at the index
pulse (I'd wondered the same thing until his post about Amiga floppies).
Stitching bits of track buffer together is quite possibly impractical due to
slight fluctuations in drive RPM and hardware delays when an index pulse is
detected. I suspect the only way to reliably read such disks is to either do
the "start of track" detection in hardware, or to sample the track from the
first index pulse up to the third index pulse and decode in software.
It's an interesting problem, and not one I'd given any thought to: I'd made
the assumption that start-of-data was always going to follow some sort of
hardware-supplied pulse (either index alone or index + sector in the case of
hard-sectored disks)
cheers
Jules
I've got the first stage of my floppy disc
reader working! Meaning, the
data separator and synchroniser works - I have a circuit that outputs a pulse
whenever the MFM 'magic sync sequence' (0x4489) is detected. In theory, I can
use that to sync the reader against sector boundaries on IBM-format discs, or
track boundaries on Amiga discs.
Philip, it sounds like an interesting project. However, I've got an
itch in my brain that I can't seem to scratch. If you're doing bit
transition timings, why even bother to have an AM detector or data
separator? You can do all of that in software. Are you restricting
your design to MFM and FM encodings?
12:57 p.m.
On 10 Apr 2007 at 3:24, Jules Richardson wrote:
I suspect it's just to read disks that don't
start the track at the index
pulse (I'd wondered the same thing until his post about Amiga floppies).
The buffer on the CW is large enough to record much more than a
single revolution of a diskette, so when dealing with diskettes of
this type, I fill it up with larger sample. Decoding then proceeds
with the first good (complete) sector in the buffer. I don't even
bother to pay attention to the index pulse in this case--I just allow
a certain amount of settling time after seeking and begin recording
for a sufficiently long time to grab about a rev and a half.
It's really no problem at all.
Cheers,
Chuck
1:28 p.m.
On 4/10/07, Chuck Guzis <cclist at sydex.com> wrote:
On 10 Apr 2007 at 3:24, Jules Richardson wrote:
That's how the Amiga trackdisk.device does it... turn on the motor,
slurp up a few thousand bits, then go looking for the first header.
It does help that there's a set of blitter terms to convert MFM to
binary and back using spare cycles from the graphics co-processor.
I suspect it's just to read disks that
don't start the track at the index
pulse (I'd wondered the same thing until his post about Amiga floppies).
The buffer on the CW is large enough to record much more than a
single revolution of a diskette, so when dealing with diskettes of
this type, I fill it up with larger sample. Decoding then proceeds
with the first good (complete) sector in the buffer. I don't even
bother to pay attention to the index pulse in this case--I just allow
a certain amount of settling time after seeking and begin recording
for a sufficiently long time to grab about a rev and a half.
I can
t quote chapter and verse for the exact amount of excess rotation that
trackdisk.device does, but anecdotally, I recall 1.1 revolutions.
-ethan
2:14 p.m.
Chuck Guzis wrote:
On 10 Apr 2007 at 3:24, Jules Richardson wrote:
Out of interest, do you always do this for "unknown" media as a matter of
course - or would you normally read a single track between index pulses, do
some software analysis to see what it is, and then go back to re-read more
than a single disk revolution?
I suppose in an ideal world I'd assume that catastrophic failure of the media
could happen very quickly - so priority is to get a snapshot of the disk onto
modern storage before that happens. In other words, it'd be great if "the
device" (be it CW or whatever) imaged enough in one pass, rather than
requiring a read / analyze / tweak read-again cycle.
In reality I've not seen many floppies (at least not 5.25") fail spectacularly
- but I have come across a few.
I suspect it's just to read disks that
don't start the track at the index
pulse (I'd wondered the same thing until his post about Amiga floppies).
The buffer on the CW is large enough to record much more than a
single revolution of a diskette, so when dealing with diskettes of
this type, I fill it up with larger sample.
4:39 p.m.
On 10 Apr 2007 at 13:14, Jules Richardson wrote:
Out of interest, do you always do this for
"unknown" media as a matter of
course - or would you normally read a single track between index pulses, do
some software analysis to see what it is, and then go back to re-read more
than a single disk revolution?
Unknown media that is fairly old--yes--I record 2 revs worth and sort
it all out later. Known media, is a different matter.
In reality I've not seen many floppies (at least
not 5.25") fail spectacularly
- but I have come across a few.
Oh, I can name a few "spectacular" brands that have been sent with
"see through" tracks already on them. It seems that at least with
some drives, fouling the head results in increased damage to any
diskettes you might subsequently read.
For reading, I've toyed a bit with the thought of using a non-contact
head, maybe like a bernoulli box. But musing is as far as I've
gotten.
I put a dual 90MB drive up on eBay and got no interest; maybe I
should look into tearing into one of the drives...
Cheers,
Chuck
5:20 p.m.
Chuck Guzis wrote:
It's a case of stopping and cleaning the drive heads as soon as it happens...
and cleaning the drive heads after accessing *every* different disk in the
same batch, as it's reasonable to assume that storage conditions could be a
factor and other disks in the same pile will be prone to failing in the same
way. :-(
In reality
I've not seen many floppies (at least not 5.25") fail spectacularly
- but I have come across a few.
Oh, I can name a few "spectacular" brands that have been sent with
"see through" tracks already on them. It seems that at least with
some drives, fouling the head results in increased damage to any
diskettes you might subsequently read. For reading, I've toyed a bit with the thought of
using a non-contact
head, maybe like a bernoulli box. But musing is as far as I've
gotten.
I put a dual 90MB drive up on eBay and got no interest; maybe I
should look into tearing into one of the drives...
Interesting. I see maybe three or four such drives offered on the local (UK)
freecycle list each year. I think I've got a couple in the attic, just because
I thought I might need them some day.
cheers
Jules
4:38 a.m.
Chuck Guzis wrote:
Philip, it sounds like an interesting project.
However, I've got an
itch in my brain that I can't seem to scratch. If you're doing bit
transition timings, why even bother to have an AM detector or data
separator? You can do all of that in software. Are you restricting
your design to MFM and FM encodings?
Oh, no, not at all. The reason I added the data separator and sync detector
was primarily because of Amiga format floppies. The track starts with a pair
of $4489 sync words, and isn't synchronised to the index pulse. It just makes
it easier to decode the data - if you know where the sync word is, you know
where the SOT is, so you know where to start decoding data, which bits are
data and which bits contain clocking information.
If the disc doesn't use the $4489 sync word, you start reading at the leading
edge of the index pulse, run one revolution, then stop reading at the second
trailing edge. That leaves you with a RAM full of undecoded MFM data, that you
can sync against manually. The sync detector lets you skip the synchronisation
stage for discs written as an entire track - just take every second stored bit
as a data bit.
I'm quite tempted to make the sync word configurable, so you could sync on any
8-bit MFM sequence you liked. I know there's at least one other 'missing
clock' sync word in common use (IIRC it's 0xC1 with a missing clock in the
second nibble).
The other 'interesting' bit is going to be handling read/write for
hard-sectored discs. Reading shouldn't be too hard - AIUI, you'd wait for an
index pulse, start reading, then wait for N+1 index pulses (where N=number of
sectors -- n+1 provides one sector of overlap) and stop. Storing the index
pulse state in the MSbit of the counter value byte would let you seek for a
sector. The index pulse would need to write the current count to RAM and zero
the counter every time an index was detected, otherwise writing the data back
would be pretty difficult (the index->sector data timing skew would require
correction).
Writing back would involve a bit of 'fun' involving a primitive state machine.
Probably something along the lines of checking to see if the MSbit was a 1,
and waiting for an index pulse before sending the pulse and decrementing the
counter.
I can foresee all this circuitry filling two or three separate CPLDs...
BTW, Chuck, thanks for posting the floppy drive pinout - it was very helpful.
Thanks,
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
5:09 a.m.
Philip Pemberton wrote:
I'm quite tempted to make the sync word
configurable, so you could sync
on any 8-bit MFM sequence you liked. I know there's at least one other
'missing clock' sync word in common use (IIRC it's 0xC1 with a missing
clock in the second nibble).
That seems sensible - along with the option of no sync word at all (in which
case you count index pulses and stop after n counts - where n is also
configurable)
The other 'interesting' bit is going to be
handling read/write for
hard-sectored discs. Reading shouldn't be too hard - AIUI, you'd wait
for an index pulse, start reading, then wait for N+1 index pulses (where
N=number of sectors -- n+1 provides one sector of overlap) and stop.
Yep - the only gotcha is that the sector pulses and index pulse is on the same
line, but the index pulse has different timing to the sector pulses to allow
differentiation.
Writing back would involve a bit of 'fun'
I'd thought the same thing. I wasn't even going to think about it at this
stage to be honest - my primary goal is to allow archiving of data onto modern
media (and interpretation of that data); being able to recreate the original
on magnetic media is more of a secondary task.
I think I'd mentioned this privately to Chuck the other week, but I'm not sure
if "playing back" raw data to a drive will even work, given that there will be
slight differences in drive RPM between drives: a track buffered on a "slow"
drive would run past the end of track on a "fast" drive by a few bits. It
makes me wonder if the only way to do a 100% reliable write is to interpret
the data that you're writing, lay down a format (which is guaranteed not to
overflow available space), then lay down the actual data.
7:04 a.m.
Jules Richardson wrote:
That seems sensible - along with the option of no sync
word at all (in
which case you count index pulses and stop after n counts - where n is
also configurable)
So the current must/should/nice-to-have list goes something like:
MUST HAVE
---------
Reading of soft-sector discs, unsynchronised, sync'd to index mark, or sync'd
to MFM SYNC words
READ SOFT TRACK UNSYNC, READ SOFT TRACK INDEXED, READ SOFT TRACK MFMSYNC
Reading of hard-sector discs, sync'd to index marks+track mark
READ HARD TRACK, READ HARD SECTOR operations
Support for multiple drive interfaces:
Shugart SA400/800 style (8")
Tandon TM100 style (5.25")
PC 3.5"
Support for multiple bit rates:
125kbit/sec
250kbit/sec 720KB 3.5" 360KB 5.25"
300kbit/sec
500kbit/sec 1.44MB 3.5" 1.2MB 5.25"
1Mbit/sec 2.88MB 3.5"
SHOULD HAVE
-----------
Writing of soft-sector discs, unsynchronised or sync'd to index mark
WRITE SOFT TRACK UNSYNC, WRITE SOFT TRACK INDEXED
Writing of hard-sector discs, sync'd to index marks+track mark
WRITE HARD TRACK, WRITE HARD SECTOR operations
NICE TO HAVE
------------
Programmable MFM SYNC word -- 16-bit register
"Stop after N index counts" mode with configurable N value
Support for MFM pre-decoding
Any additions or comments?
Yep - the only gotcha is that the sector pulses and
index pulse is on
the same line, but the index pulse has different timing to the sector
pulses to allow differentiation.
Problem is, I don't have any hard-sector discs,
99% of the problems with this project are probably going to boil down to odd
disc format and drive availability - all I've got is a 40/80 switchable Viglen
drive for the BBC, a 1.2MB 5.25" and a couple of DS-HD 3.5" drives. Oh, and
maybe an IBM 2.88MB somewhere too, but with an odd interface connector.
I'd thought the same thing. I wasn't even
going to think about it at
this stage to be honest - my primary goal is to allow archiving of data
onto modern media (and interpretation of that data); being able to
recreate the original on magnetic media is more of a secondary task.
That's my primary goal too - archiving and analysis. Building something with
similar capabilities to a Trace disc duplicator would be kinda cool though.
I think I'd mentioned this privately to Chuck the
other week, but I'm
not sure if "playing back" raw data to a drive will even work, given
that there will be slight differences in drive RPM between drives: a
track buffered on a "slow" drive would run past the end of track on a
"fast" drive by a few bits.
Well, as far as I can tell, the speed variation across drives is about 10%
absolute max. The TEAC FD-05HF-8630 is specified to have no more than 1.5%
long-term speed variation (LSV), and less than 3% instantaneous speed
variation (ISV). The Samsung (SEMA) SFD321B is specced at 1.5% ISV and 1.5% LSV.
Formatting systems take this variation into account anyway - IIRC the IBM
format doesn't use all the (theoretically) usable 200ms zone between the index
pulses. There's probably a good few tens of milliseconds gap between the end
of the track and the next index pulse. My data on the IBM format is a bit
sketchy though - can anyone confirm this?
In any case, if what I've said is true, all you really need to do is activate
/WRITE_GATE with /WR DATA high to erase the data on the track, then write the
data you want on the second pass. That'll ensure that the data you've written
is synchronised properly, and the controller won't be able to see any of the
older data because it's all been zeroed out before the actual track was written.
It makes me wonder if the only way to do a
100% reliable write is to interpret the data that you're writing, lay
down a format (which is guaranteed not to overflow available space),
then lay down the actual data.
It might be worth taking a look at Tim Mann's CW2DMK and DMK2CW tools - they
read an IBM MFM-format floppy and convert it to a DMK image, and can then
write it back to disc using the Catweasel controller. It's certainly possible
to make a near-exact copy of a disc.
At the moment, I'm going to try and do as much as possible with the discs and
drives I've got - thankfully the IBM format uses the same MFM syncword as
Amiga floppies, but in a different way, so I can confirm that my sync detector
and data separator works. Now I need to do the disc read/write stuff, then the
host interface and software.
After that? I start begging for floppies in unusual formats, and drives that
can read them :)
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
1:16 p.m.
On 10 Apr 2007 at 9:38, Philip Pemberton wrote:
I'm quite tempted to make the sync word
configurable, so you could sync on any
8-bit MFM sequence you liked. I know there's at least one other 'missing
clock' sync word in common use (IIRC it's 0xC1 with a missing clock in the
second nibble).
Too many years ago (probably about 12 or 13), I did a similar lashup
to decode some Smith Corona 2.8" diskettes. I used a WD9216 8-pin
data separator and a 2660 USART that I had kicking around in my
hellbox. Since the 2660 allows for a double-byte sync character, it
was pretty easy to find address headers using the sync "hunt"
feature. IIRC, I don't recall if the format relied on missing sync
pulses for AMs.
These were oddball diskettes--you started a read and the head swept a
spiral across the entire diskette, then returned to the beginning
automatically. A CW wouldn't have worked, because of the volume of
data in a single read operation.
Cheers,
Chuck
11 Apr
11 Apr
9:56 a.m.
New subject: DELUA prints? (M7521)
Does someone have a scan of the M7521 DELUA print set? I don't see
it on bitsavers...
--tnx
--tom
10 Apr
10 Apr
6:12 a.m.
On Tue, 10 Apr 2007, Philip Pemberton wrote:
The data separator is an Verilog HDL reimplementation
of the data separator
used in Petr Simandl's Sinclair Spectrum +2A floppy disc controller
(<http://www.simandl.cz/stranky/zxs/obrazky/zx_radic_89k.jpg>, but there's a
better quality schematic at
<http://www.worldofspectrum.org/BackToThePlus3/>). I'm driving the whole
thing off a 32MHz TTL oscillator, divided down to 16MHz for 3.5" DSHD, and
8MHz for 3.5" DSDD. I haven't tried FM encoded data yet, though I have no
reason to suspect it won't work, as long as I can figure out what the clock
divider needs to be set to.
Stupid question: where is the PLL? Is this a digital PLL built around the
SN74188? Isn't that only the data separator, i.e. detection of data
windows, which is then MFM only? This design looks a bit too
primitive...
[...]/hpla-fdd-reader-syncing-against-720k-floppy-zoomed-long.png
Hmm, /RDDAT, DWIN and DATA don't look right to me. You seem to generate
DATA bits during clock time. Is /RDDAT coming from the floppy and is DATA
going to the FDC?
/RDDAT shows the bit pattern 10100001, i.e. $A1. But the address mark for
MFM consists of four bytes ($A1A1A1xx), and the address mark bytes have
clock bits 2, 3 and 4 removed, your data stream seems only to have bit
3 removed.
But it's possible that I just don't fully understand this design.
Christian
7:19 a.m.
Christian Corti wrote:
/RDDAT is the data the floppy drive fed out.
DATA is the bitstream after the data separator has cleaned it up (it sometimes
double-clocks, but that doesn't seem to matter).
DWIN is the Data Window. When it transitions from high-to-low or low-to-high,
a new data or clock cell starts. If there's a transition on DATA during the
cell, then the bit is a 1, else it's a 0. Clock and data bits are mixed
together, but based on the SYNC state, you can figure out what phase of DWIN
signifies a data bit.
Stupid question: where is the PLL? Is this a digital
PLL built around
the SN74188? Isn't that only the data separator, i.e. detection of data
windows, which is then MFM only? This design looks a bit too primitive...
It's a state machine.
[...]/hpla-fdd-reader-syncing-against-720k-floppy-zoomed-long.png
Hmm, /RDDAT, DWIN and DATA don't look right to me. You seem to generate
DATA bits during clock time. Is /RDDAT coming from the floppy and is
DATA going to the FDC? /RDDAT shows the bit pattern 10100001, i.e. $A1. But
the address mark
for MFM consists of four bytes ($A1A1A1xx), and the address mark bytes
have clock bits 2, 3 and 4 removed, your data stream seems only to have
bit 3 removed.
Um, no.
The MFM sync word does decode as 0xA1, but it has a missing clock bit in the
lower nibble - it's encoded as:
01 00 01 00 10 00 10 01
^
missing clock
Which is invalid MFM data, but still maintains the (1,3) RLL property, so the
drive and data separator aren't confused by it.
Take into account that you're looking at a waveform with the SYNC output
skewed by one DWIN transition. The first '0' is missing from that trace. DWIN
changes state just before the X marker, clocking in a 0.
Then DWIN transitions again, and because there was a transition on DATA in
that bit cell, a 1 is clocked into the shift register. So now
SR = xxxx xxxx xxxx xx01
Skip ahead to the next DATA pulse - DWIN has changed state three times,
clocking in three zeroes. So SR = xxxx xxxx xx01 000. Then DWIN changes state
again, and because of the DATA pulse, a 1 is clocked in. Now
SR = xxxx xxxx xx01 0001.
Now skip ahead to the DWIN=1 before the second sync pulse. Now
SR = x010 0010 0100 0100
DWIN changes state again, clocking the 1 into the shift register. Now
SR = 0100 0100 1000 1001
SR is equal to the sync word, so the SYNC output goes high. In the 'early'
version, this was a registered output timed against DWIN, so it lagged by one
DWIN transition. In the new version, it's a combinatorial output (a straight
compare).
Does that make it any clearer?
Thanks.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
11:02 a.m.
On Tue, 10 Apr 2007, Philip Pemberton wrote:
0 1 0 0 0 1 0 0 1 0 0 0 1 0 0 1
C D C D C D C D C D C D C D C D
D = $A1
C = $0A
Ok, I was referring to the IBM 5114 maintenance manual which describes FM
and MFM encoding that IBM used for their drives/controllers. But you are
right, e.g. the "Floppy Disk Data Separator Design Guide for the DP8463" says
that the address mark $A1 has a clock pattern of $0A. I don't really know
what IBM meant with "missing clock bits 2, 3 and 4"... I think it applies
to the $FE or $F8 address mark in FM.
Christian
It's a state machine.
Yes, I begin to understand. I've missed the part where the state machine
is clocked with the master clock. This makes more sense now.
/RDDAT shows
the bit pattern 10100001, i.e. $A1. But the address mark for
MFM consists of four bytes ($A1A1A1xx), and the address mark bytes have
clock bits 2, 3 and 4 removed, your data stream seems only to have bit 3
removed.
Um, no.
The MFM sync word does decode as 0xA1, but it has a missing clock bit in the
lower nibble - it's encoded as:
01 00 01 00 10 00 10 01
^
missing clock 
8:35 p.m.
On Tue, 10 Apr 2007, Christian Corti wrote:
Ok, I was referring to the IBM 5114 maintenance manual
which describes FM
and MFM encoding that IBM used for their drives/controllers. But you are
right, e.g. the "Floppy Disk Data Separator Design Guide for the DP8463" says
that the address mark $A1 has a clock pattern of $0A. I don't really know
what IBM meant with "missing clock bits 2, 3 and 4"... I think it applies
to the $FE or $F8 address mark in FM.
While you are at it, notice that the 1771 can create some FM data address
marks that the 179x can not. Worse yet, they are used in TRS80 (model 1)
disk formats.
12 Apr
12 Apr
9:50 p.m.
From: Fred Cisin <cisin at xenosoft.com
On Tue, 10 Apr 2007, Christian Corti wrote:
Hi
In FM there is always a clock bit and a location for the data bit. Missing
clock is just that, missing clock! No change to the data bits.
MFM may or may not have a clock, depending on the data 1 bit density.
If missing a clock, it means where a clock bit should be related to data.
Dwight
Ok, I was referring to the IBM 5114 maintenance
manual which describes
FM
and MFM encoding that IBM used for their
drives/controllers. But you are
right, e.g. the "Floppy Disk Data Separator Design Guide for the DP8463"
says
that the address mark $A1 has a clock pattern of
$0A. I don't really
know
what IBM meant with "missing clock bits 2, 3
and 4"... I think it
applies
> to the $FE or $F8 address mark in FM.
While you are at it, notice that the 1771 can create some FM data address
marks that the 179x can not. Worse yet, they are used in TRS80 (model 1)
disk formats.
_________________________________________________________________
The average US Credit Score is 675. The cost to see yours: $0 by Experian.
http://www.freecreditreport.com/pm/default.aspx?sc=660600&bcd=EMAILFOOT…
13 Apr
13 Apr
5:01 a.m.
On Thu, 12 Apr 2007, dwight elvey wrote:
In FM there is always a clock bit and a location for
the data bit. Missing
clock is just that, missing clock! No change to the data bits.
MFM may or may not have a clock, depending on the data 1 bit density.
If missing a clock, it means where a clock bit should be related to data.
I know what clock bits are ;-)
The question was, why three missing clock bits (the MFM address mark has
only one missing bit at position 5). But I've found out that this applies
to the FM address mark where the clock bits 2, 3 and 4 are missing. The
IBM manual just wasn't precise enough on this point.
Christian
10:41 a.m.
From: Christian Corti <cc at corti-net.de
On Thu, 12 Apr 2007, dwight elvey wrote:
Hi
I suspect that it was the difference in technology. When FM started,
the clock/data separator was usually a couple of one-shots. This was
probably more error prone at spotting missing clocks.
When MFM came along, most were using PLL's. Since these actually
tracked the data on the disk, they were more sensitive to catch
things like a single missing clock.
The other thing is that in MFM, the sequence is already missing
a number of clocks because of the data sequence. Missing the
last one makes it an illegal sequence.
In FM, it may be the same thing. It isn't until the third clock is
missing that it is truly an illegal sequence. You have to look at
the data sequences to verify this.
Dwight
_________________________________________________________________
Mortgage refinance is Hot. *Terms. Get a 5.375%* fix rate. Check savings
https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm…
In FM there is always a clock bit and a location
for the data bit. Missing
clock is just that, missing clock! No change to the data bits.
MFM may or may not have a clock, depending on the data 1 bit density.
If missing a clock, it means where a clock bit should be related to data.
I know what clock bits are ;-)
The question was, why three missing clock bits (the MFM address mark has
only one missing bit at position 5). But I've found out that this applies
to the FM address mark where the clock bits 2, 3 and 4 are missing. The IBM
manual just wasn't precise enough on this point.
Christian
6292
days inactive
6296
days old
19 comments
8 participants
participants (8)
-
cc＠corti-net.de -
cclist＠sydex.com -
cisin＠xenosoft.com -
classiccmp＠philpem.me.uk -
dkelvey＠hotmail.com -
ethan.dicks＠gmail.com -
julesrichardsonuk＠yahoo.co.uk -
uban＠ubanproductions.com