Reading an MFM hard drive with a floppy disc analyser

Jules Richardson jules.richardson99 at
Fri Dec 5 18:43:49 CST 2008

Philip Pemberton wrote:
> Jules Richardson wrote:
>> Well, extra lines isn't a big deal I suppose - heck, you could even do 
>> that bit 'manually' and read platters one at a time, flipping a switch 
>> between each pass.
> True, though the hardware I'm actually thinking of using is my USB 
> hack-and-bodge floppy reader. FPGA, PICmicro, and a few buffers/level 
> translators.

OK, so you can probably throw something in there to switch heads via software, 

>> Well, run some figures as a sanity-check... say 256*8 bits per sector, 
>> 32 sectors/track on a formatted ST506 - 32 x 256 x 8 = 64Kb of actual 
>> data per track.
>> 83.35 seems sensible as some kind of theoretical maximum, given 
>> storage of sector headers and the like.
> And MFM is basically one flux transition per (data) bit guaranteed, 
> meaning 83.35kbps isn't actually that strange a figure.

Yeah. I think your calculations were right, anyhow...

>> 101353.6 Kb is approx 98Mb, or approx 12MB - so that seems not 
>> unreasonable.
>> However, remember that's *sample count*, not total storage.
> True. An FDI file containing the sample data isn't likely to be /that/ 
> much bigger though.

No; the raw data file size is manageable I think - it's just the buffer size 
that needs to be reasonably big.

> But it'll take a bloody age transferring that much data over USB2 Full 
> Speed (1.2Mbps peak).

I think I did once put in a request for a SCSI version ;)

>> So, what's an upper boundary on bits per sample? I suppose you could 
>> have an entire track with just one sample on it right at the end, so 
>> your upper boundary is the 16.67ms figure.
> MFM is a (1,3)RLL code. That means you can have a minimum of 1 and a 
> maximum of 3 empty bit cells between flux transitions.

Yeah, but that's for complete data, is it not? I'm not sure what happens if 
given a damaged drive - given that ST506/412 is dumb, presumably it just 
blindly spits out what it finds on the disk surface? It'd be nice to be able 
to capture whatever the drive throws at this device, in the hope of making 
some sense out of (or 'beyond') damaged sections in software later. If the 
track data has 'holes' then the device needs to be able to record the length 
of those holes in order to portray what's on the disk accurately.

>> More typically though samples are going to occur *far* more frequently 
>> - so to cope with all possible situations you (in theory) need a very 
>> large sample length (which in 99.9999% of cases is going to contain a 
>> lot of 0s in the upper bits!)
 > [lots of numbers]

I'll look at those later - it's too noisy to concentrate round here right now :-)

>> 1) Just have an absolutely colossal buffer with a large number of bits 
>> per sample
> SRAM is relatively expensive though. SDRAM isn't, but then you have to 
> deal with refreshing and other "fun" things like that.

Yeah, I came to that conclusion way back when, too.

> Hmm, use the top 2 bits to specify the timing resolution, and the rest 
> as a timing value. Drop between 0 and 3 bits depending on how far over 
> 14 bits your count has gone...
> That's going on my "try this" list.

It should work, I think, subject to not throwing too much away.

>> For some reason when I looked at this I think I believed I could get 
>> away with 9 bits per sample including a flag bit dictating two 
>> different sample resolutions (i.e. somewhere around 1Mb of buffer) - 
>> unfortunately all my notes on this are stuck in storage right now 
>> though (plus ideally I'd go for a microcontroller approach with a 
>> variable sample length I think)
> Ultimately it depends on what you're sampling. A 3.5" DSDD floppy, 
> sampled at 7.08MHz ends up with few samples above ~64 counts (IIRC, my 
> density graphs are on the laptop, which is switched off). Based on that, 
> 7 bits would probably be fine up to 14MHz, 8 bits up to 28MHz.
> Assuming, of course, that the disc is "perfectly" formatted. As in, the 
> entire track is MFM.

Uh huh. There's not necessarily a guarantee on that for a damaged drive, I 
fear (and few STxxx drives seem to exist without at least a few defects)

I can't remember if my 9 bits per sample (including flag bit) was just for 
MFM, or if I figured it'd work for RLL, too (or ten bits if recording with 
each sample whether there's an index pulse or not - I think I'd dreamed up a 
way of doing that separately so as to not encroach on buffer size (but it's 
more complex to do so).

>> Recreating the data onto another drive is a different matter, of 
>> course - but I've always been more interested in salvaging existing 
>> data onto more modern media for analysis.
> Half the problem is that the timing is going to get progressively worse 
> the further down the line you go. Kinda like what happens when you dub 
> an audio tape. By the time you've gotten to the point of having a 3rd- 
> or 4th-generation copy, the audio is almost completely masked by the 
> background hiss.

Yeah. I think what needs to happen is that you sample a drive, essentially 
turn it back into data bytes in software on a host machine, bung some sector 
header voodoo around it, and *then* spit it back to the destination drive 
using this device...

For now, I'm more worried about ailing STxxx drives and getting data off them 
(and making sense of it) - writing back is more of a secondary issue (but is 
probably an extra 10% logic on this device to support writes, I suspect).

Aside: I'm not sure if it's beneficial having a number of buffers and 
reading/writing multiple head data in parallel? I worry about running STxxx 
drives for longer than necessary :-) Probably not viable just from a RAM cost 
point of view, though...



More information about the cctech mailing list