I wish it was that simple, just write pre-compensation. The amiga has three different settings for wpc, 0 ns, 140 ns, 280 ns. These are tiny amounts, and I can deal with this normally. There’s a register for it in Paula.

What I am seeing would amount to 1000ns of difference! So 6us might show up as 5us, or 4us might show up as 5us. This error can occur(does occur) in both directions (which is precisely why it’s tough to deal with it!!!!!) WPC only shows up as a negative adjustment.

Sorry for the delay in my postings. I’m going to put up, today, java code that does the conversion from RAW MFM. It’s ugly, and I still need to refactor but it works. Even if you work in C or other languages, it should be readable. Please let me know if you don’t understand something.

Because there are phase errors included by the read amplifer, many floppy controllers do negative pre-compensation during the write. It shifts some of the pulses to the middle of the interval. Check your data against this picture:

http://www.tomas-franke.cz/speccy/precomp.jpg

I also worked on my FPGA engine and it produces the correct “MFM symbol possibilities” now.

http://www.tomas-franke.cz/speccy/sample.zip

but how can I get the sector data from them?

Analog data – most of read amplifiers have some output for already amplified signal so seems that it is nice point to use this signal for next steps of processing – but i’m thinking also on different idea – rebuild electronics of FDD – completely new electronics in stepper and read channel part – maybe this is the only way to rescue some disks…

ADC – there is lot of ADC on market – i’m thinking about AD9066 (but this open – to be onest choice for ADC seems to be not critical) – it should be fine for this job and with some FPGA frontend should allow to create flexible and transparent (from transmission channel point of view) way to process read data.

Just search for datasheet – read amplifiers IC for FDD like NJM3470, BH6625, CXA3010, CXA1362 – reimplementing this functionality in DSP should be possible at current technology state.

Yes, I’m familiar with those patents. I had a post about them awhile back.

While some things, like the block diagrams, etc help — trying to following along the legalese is pretty tough. Trying to distill the technical info from the patents can be tough.

How do you intend on getting access to the analog signal? Do you then intend on doing A->D so you can process it? Do you have any ADC’s in mind? This definitely sounds interesting.

im thinking about something similar to Yours project but i want to have access to the analog signal and use for decoding multibit representation for analog magnetic flux.

Right now, the current gen solution is pretty heavy in terms of hardware. I use a $150 eval board, but 90% of the hardware on that board is simply not used. I need to distill down the true requirements to make it viable for home DIY’ers to build it. I don’t think this would be hard but it depends on the availability of spartan-3e (or similar) prototype boards.

After the index pulse ends, there is 12 zero bytes (clock pulses only) to synchronize the PLL. Then, comes the INDEX MARK. A sync word with some clocks missing just like Amiga’s 4489. The sync word repeats 3 times. Index mark in never checked.

Then comes a little gap.

—repeats for EACH sector—
Then 12 zero bytes again, followed by another sync word called SECTOR MARK, 3 times. Then comes the track number, sector number, head number and X. All are binary bytes, The X is the sector length(0=128,1=256,2=512..up to 4096). Then 2 bytes of CRC16, Low first.
Another small gap.
Then 12 zero bytes again, followed by another sync word called DATA MARK, 3 times. Then the sector data itself followed by 2 bytes of CRC16, Low first.
Sector ends with bigger gap.
—end of repeat—

MFM coding itself is the same as Amiga – one clock between two zero databits.
But because PC writes each sector separately, gaps after the headers and after the data are needed. This is because the spin motor variations…

I cant remember the sync words, but it is well described in the datasheet of Western Digital WD2797 controller. There is byte by byte description of the whole track here.