inital results on error correction

I think it’s probably fair to say that you’re more likely to see a missing bit (or rather a missing flux transition) than see a transition that wasn’t actually there.

Assuming you haven’t already thought of that, perhaps you could incorporate it into your algorithm?

FWIW, I’m working on something broadly similar to your Amiga floppy reader, but for just about any disc format instead of specialising on one specific format. It’s basically a USB-enabled Microchip PIC bolted onto an FPGA — the FPGA reads and writes the transitions (the logic can be summed up as “a huge, messy state machine”) and the PIC tells the FPGA what to do (including loading the microcode from an Atmel Dataflash chip on power-up).
I’m aiming for timing resolution more than anything — the plan is to build something that can not only read or write just about any floppy disc format (MFM, FM, GCR, the list goes on) but also identify the type of copy protection in use (if any) and tell you if a given track has been modified after the disc was mastered (utterly useless for reading old data discs, but good for seeing if the ‘original’ copy of $SOME_OLD_RARE_GAME is really original, and if not, what exactly was changed).

But anyway, enough of my ranting. I’m just reading through some of your past posts — you have some very interesting ideas.

> While I probably agree with you, do you have a specific rationale behind why you believe that a transition is likely to be seen as no-transition, rather than the other way around?

I was thinking along the lines of the magnetic field of the recorded data weakening over time, but there would still be a transition between N-polarised and S-polarised.
I suppose the more likely event is the transition between two bit zones becoming more indistinct, and harder for the head amplifier to detect. Again, you’d see a no-transition but that would be because the transition was too weak to trigger the FDD’s threshold detection circuitry.

> I’ve been doing a lot of reading on FPGA’s lately. Very interesting devices. If I had more time and money, I’d really like to get some. You using Xilinx or Altera? Verilog/VHDL ?

Verilog on Xilinx CPLDs and Altera FPGAs. A bit of an odd choice, but that’s basically because I bought a load of the Xilinx XC9500 and XC9500XL chips (quite a few of them) from Ebay, then found that nobody in the UK sold small quantities of Xilinx FPGAs. My usual supplier had a bunch of Altera Cyclone-IIs, so I bought four of them to play with.

> Have you seen the Amiga custom chips done on an FPGA? It’s really awesome.

Minimig? Yep, I’ve seen it. I’ve been trying to find some good references on what the Amiga floppy controller can actually do (and how to program it), but haven’t found much beyond “it raw-reads, then the CPU decodes the data”.

> Your work sounds an awful lot like what the people at SPS and CAPS do.

I’m actually working with them to make my floppy reader suitable for use as an archiving / preservation tool. Something broadly similar to a Trace duplicator, but built from almost-off-the-shelf parts.

> How are you detecting changes vs original mastering?

By looking out for changes in the read rate. It’s highly unlikely that two drives will have exactly the same rotational speed (mechanical and electrical tolerances are pretty much inescapable). So let’s assume your mastering drive was running at 350RPM (vs 360RPM typical for a 3.5″ disc). If someone then writes a sector on a drive that runs at ~355RPM, then the data rate will increase fractionally relative to the mastered area.

If you assume that nearly all the disc was mastered, and that only a few sectors are likely to have been modified (e.g. high score data), then you have a large sample of one type of data which makes it fairly easy to spot the ‘odd one out’.

> Do you run a blog/site etc covering the details? I’d like to read about that!

https://blog.philpem.me.uk and https://www.philpem.me.uk. Most of the discussion is happening on the Classiccmp mailing list at http://www.classiccmp.org; there isn’t much about it on my blog.

> And detecting copy protection? Checking for long-tracks, more than 80 tracks, etc?

Because it’s reading from either an Index Pulse to another Index Pulse, or from an MFM SYNC word (which is custom programmable — Sync A1 aka 0x4489, or indeed any MFM pattern is valid) to an index or sync word, you’ve got the entire physical track. A bit of data processing will tell you if the track is a long-track or just noise or a blank track. The data timing graphs are a total giveaway…
There are a few articles about this type of analysis on the SPS’s website.

> How are you going about reading the disks? Time between transitions? and do you sample? or edge-detect or ?

Edge-detect, with an internal 15-bit 40MHz timer/counter to do time-between-transitions measurement. Resolution is circa 25 nanoseconds (a Trace duplicator does 50ns), and 4Msamples of SDRAM basically means you can store an entire track at the maximum resolution. The counter locks at 0x7FFF if the timer overflows.

The Index pulse state is stored in the MSbit of the data word.

I’m thinking about adding an option to track the disc’s current rotational position for each transition as well. That way you can figure out that the disc was running – say – 2% too slow for part of the track and 1% fast for the rest of it, and adjust the timing values in software to match up. That is to say, you eliminate any error caused by your particular disc drive’s spindle motor varying in speed.

> I struggled to find a working method…… Other people use different ways…. i think Jens @ Individual Computers uses the time BETWEEN transitions as a way of telling what the data is.

Oh, the Catweasel. It wouldn’t be quite so bad if he’d actually used a fairly sane clock rate (an integer multiple of the data rate).

My design goals are/were:
– Low cost — no sense in making something nobody can afford.
– Small, light and easy to carry around — if you’ve got the last remaining copy of XYZ123/OS 3.14159, you’re hardly going to want to let it out of your sight… being able to grab a laptop, the reader and a power supply and visit the owner, image the discs and leave would be tremendously useful.
– Reliable, easy to repair — no weird parts that can’t be substituted out with something else!
– USB interface — fast (ish) and standard.
– Open-source design and software
– Cross-platform — Linux, Windows, Mac OS X.
– High accuracy — at least as good as a Trace duplicator, if not better.
– Read any standard disc, and most copy-protected discs, including protection detection/analysis — like Copy II PC, but far more capable.

Fun fun stuff indeed.