Hi guys, I've spent the past two days working on the Python API and Firmware for the DiscFerret. This work has resulted in a few enhancements... Firstly, I've made the RAM access routines a heck of a lot faster. How much faster? About SEVEN TIMES. The 001A firmware can access RAM at about 30Kbytes per second (peak is ~31KiB/sec during a RAM read). Upgrade to Firmware 001B, and this increases to ~220 KiB/sec, or very close to the theoretical limit of the Microchip USB engine (which is about 250KiB/sec). I'm looking for other ways to boost the transfer rate, but I think this is as far as it's going to go. To put this in perspective, if we assume that it takes one second to read a disc track, and that we get 128Kbytes of data from that read... 80 tracks double-sided = 160 tracks 160 * 128 = 20,480 KiB = 20MiB 20480 / 220 = 93 seconds to transfer the data (only!) Disc rotates at 300RPM. 60 seconds / 300RPM = 0.2 seconds per revolution If we wait for the second index pulse before reading, that's a maximum wait of 0.4 seconds, plus 0.2 seconds to read each track = 0.6 seconds per track, excluding seek 0.6 * 160 = 96 seconds 96 seconds + 93 seconds = 189 seconds... or three minutes and nine seconds. If you reduce the clock rate from 80MHz to 40MHz, that halves the amount of data which needs to be transferred, thus bringing the time down to 141 seconds, or two minutes and twenty-one seconds. Did I mention that -- at full speed -- this is about 30 seconds faster than the SPS Kryoflux analyser? If you're happy with Catweasel-level accuracy (~20MHz acq frequency), then you can get this down to 117 seconds... a shade under two minutes per disc. Admittedly, to get this speed-up, you need to reflash the firmware -- short the BOOT jumper, plug in the power cable and USB, then use mphidflash to upgrade the firmware. Unplug the cables, remove the jumper, then plug the USB and power cables back in. Simple! Next up -- the Python API now handles RAM access chunking. Tell it to read 512K of data, and it'll run off and figure out how many READ commands need to be sent, and how to read those bytes from the hardware in the fastest way possible (i.e. how many bytes it can stuff in each packet). It's also fully backwards compatible with the 1A firmware, although you'll hit the 30KiB/sec speed limit... I've also set up a mailing list -- it's open-access, sign up and you can post, or you can skim the list archives as much as you please. I'll be posting news about software updates, answering questions, and helping out with hardware issues. The mailing list homepage is: http://mail.discferret.com/mailman/listinfo/discferret-l_discferret.com If for some reason you don't like the Mailman web interface (or it refuses to play nice), you can also subscribe to the list by sending an email to discferret-l-request at discferret.com with the subject "subscribe" (no quotes). I'll be posting a slightly longer message there in a few minutes detailing exactly what you need to do to upgrade a Release 1A DiscFerret to Release 1B, including a new firmware HEX file. I should probably turn the DiscFerret site into a semi-closed Wiki (some pages protected, others open, "if you're on the mailing list you can edit the Wiki"), though that's a job for later... I'm also toying with the idea of offloading data separation onto the DiscFerret FPGA, meaning that you'd be able to program the data separator, then just grab a stream of clock and data bits instead of the timing stream. Less effort if all you want is an ADF file, and less data to transfer too... Enjoy! -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/