keithI’ve been more active on the project than the posts have illustrated. I’ve been working on a few different things :
Been trying different PLL solutions, examining how Paula does it, and actually analyzing my read data with Matlab to get a graphical view of the “problem.” Most of my solutions, while they technically work (ie they have the desired behavior), they don’t actually solve the problem at hand. I have to get a better hand on what “bad data” looks like, and then try to invent solutions that address the specific problems I’ve seen. I’m also using Paula as one metric of “goodness.” In my mind, my controller should be better — should read disks that the amiga is not able to.
I don’t think I fully understand the problem. I know what the SYMPTOMS are — flux transitions are read sometimes as being “in the middle.”, 5us between pulses where 4us=’10’ and 6us=’100′. What the heck does 5us mean? How do we bias this towards the right direction? Many of the controllers use some sort of PLL — but I see values one after another that span the acceptable range of values. You can’t track something that doesn’t trend!
I also want to get a better handle on how Paula works. I’ve got it hooked back up to the logic analyzer, and been trading messages on English Amiga Board about disk DMA and the like. I’d like to do automatic comparisons between the output of Paula and my project and see when Paula gets it right, but I get it wrong!
Hi Keith! Great work – i hope that You know Paula FDD patents? US4780844 and US4829473 ?
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.
Hi Pandy,
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.
currently i’m collecting various data about FDD – focusing mostly on internal construction fo the FDD itself – there is series various IC dedicated to signal (analog) processing – from my knowledge (bit theoretical at this stage) read signal is amplified and processed in series of analog filters – at the end it is differentiated and with help of comparator converted to the digital data – i’m afraid that without extended processing in analog domain it will be difficult to fine tune process of reading itself – i see how You struggling with jitter and thresholds then i realize that maybe limitation is in FDD.
Currently there is few projects on FDD reading (like KryoFlux) but seems that they began achieve point when increasing complexity give almost no gain in quality.
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.
Maybe these mystic variations are the write pre-compensation.
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:
https://www.tomas-franke.cz/speccy/precomp.jpg
I also worked on my FPGA engine and it produces the correct “MFM symbol possibilities” now.
https://www.tomas-franke.cz/speccy/sample.zip
but how can I get the sector data from them?
Omikron,
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.
Omnikron, go check out the download section. I’ve put the MFM decoding routines that will take you from RAW to decoded amiga data.