Hi guys... I've just this second got my DiscFerret talking to an ST506 hard drive. Specifically, a Control Data / Magnetic Peripherals 94205-51 "Wren IIHH", apparently also known as the Seagate ST253. 989 cylinders, 5 heads, 17 sectors. It also seems to bear an uncanny shape-and-weight resemblance to a breezeblock... But anyway, I digress. First, the pretty pictures: Linear histogram: http://www.discferret.com/temp/st506/dat.lin_histogram.png Logarithmic histogram: http://www.discferret.com/temp/st506/dat.log_histogram.png Scatter graph: http://www.discferret.com/temp/st506/dat.scatter.png The log-histogram shows a very distinctive MFM timing pattern (three peaks at 1T, 1.5T and 2T), and the scatter-graph shows that the timing data is split into 17 distinctive segments: the sectors. So what's the catch? 1) The DiscFerret PSU doesn't have enough grunt to run a Winchester drive (or at least a 5.25 half-height like the Wren) and a 3.5in floppy drive at the same time. This is an academic point, because you need an adapter board to hook the 'Ferret up to the ST506 drive, and you can't have both a floppy drive and the adapter plugged in at the same time. 2) I haven't got the software decoder working. Yet. I need to play with the sync-word scanner -- the WD2010 controller chip does strange things to the IDENT flag byte. Adding a few don't-care bits to the mask and implementing a 16bit CRC should sort this out. The data looks good, but I can't prove it until I make MagScan read it. I've made a few modifications to the Microcode too: - The acquisition and RAM Write clocks have been increased to 100MHz. This provides a bit more timing resolution, and makes it a little easier to convert from a timing count to an absolute time (especially if you're reading a timing histogram and don't have a calculator). - The data separator has been partly re-implemented. I've ditched the shift-register counter in the DPLL and replaced it with a parameterised binary counter. Now the sync-word detector can run from almost any reasonable input clock rate. I've got it running at 40MHz at the moment (it used to run at 32MHz). - A FIFO has been added between the data sources (acquisition module and parallel port) and the memory write controller. I did this because there was a risk that a timing value could be lost if a transition occurred within 5 or 6 clocks of a RAM write (the previous transition, or a counter overflow). Still to do: - Make the current acquisition abort if the FIFO overflows - Decouple the acquisition and memory-write clocks. The RAM has a 10ns access time (i.e. 100MHz), and I'd like to see if the acquisition engine can be made to go faster. This should work as long as it doesn't get hit with more than 256 fast transitions in a burst... The DPLL change came about because the FPGA I'm using only allows the on-chip PLLs to be driven from a global clock input, and only one PLL can use the GCK. So for each PLL you want to use, you have to provide a separate GCK... This is a fairly easy board tweak (you bridge two pins on the FPGA with wire or solder), but it'll break backwards compatibility... :( So a good day was had by all, it seems :) The new Microcode is in the usual place (the Mercurial repository). I'll push a compiled version into the Firmware repository in the next couple of minutes. Thanks, -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/