-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I've released a new version of the DiscFerret interface library and microcode. This is libdiscferret v1.5, with microcode release 0x0028. The reason I'm declaring this an urgent update is because in an earlier release of the microcode (possibly back to the initial release) introduced an extremely nasty bug... This bug WILL corrupt the data read from the disc if either * An index pulse arrives at the same time as a flux transition, or * The counter overflows immediately before a transition. In either of these cases, the flux transition will be dropped, and either a Counter Overflow or an Index Trigger byte will be stored instead. For extra bonus points, the counter overflow logic made it absolutely impossible to represent a counter value of 127, or a multiple thereof. These would cause an overflow store... followed by another count up. The transition would be completely ignored. This basically means that any disc image created with any microcode release earlier than 0x0027 (i.e. libdiscferret 1.4 or earlier) should be considered unreliable and not an accurate representation of the data on the disc. These images should be discarded and the discs re-imaged. To resolve this problem I have: 1) Re-engineered the data coding format and the disc-reader logic to prevent a counter overflow or index store from causing a missed transition 2) Completely rewritten the testbench to remove the stupid mistake which allowed these mistakes to slip through the net in the first place. 3) Changed Magpie (the disc image reader) and Merlin (the analyser) to create "DFE2" format files. Attempting to load a "DFER" image into Merlin will work, however it will warn you that the data may be inconsistent. I've screwed up bigtime here -- a tool designed for data preservation should most definitely NOT have had bugs like this. I can't believe I screwed up the design so badly, and I've been cursing at myself since the bug was reported on the DiscFerret IRC channel (#discferret on irc.freenode.net) last week. An even more subtle bug in the test bench code rendered all my tests pointless (basically: the test_fail() function would cause the testbench to abort with a 'success, tests passed' code). The aforementioned test benches have now been rewritten from scratch in a way which will hopefully prevent this kind of thing from happening again. Yes, I am doing both positive and negative testing, and testing the testbench framework. I've left the "torture test" testbench running for several hours with various types of input waveform, including some which would cause timing violations on other parts of the circuitry (specifically, the input filters). No timing violations or data errors were detected, even under these challenging (and in some cases outright impossible) scenarios. The output data matches the hardware model and my specification documents *perfectly*. No doubt some vendors of similar products will take this opportunity to take a dig at me and my product. Whether they choose to act in this highly unprofessional manner is entirely up to them. However, please bear in mind that my code is available for peer review, and I accept submissions of code from others (and bug/feature requests). The bug tracker (Mantis) is open to the public. How many other projects like DiscFerret operate with this level of transparency? The software update is available to download, free of charge, from the usual download source: http://www.discferret.com/ (click the Downloads link on the left hand side). As always, if you have any issues with your DiscFerret, please feel free to contact me -- either by email, the DiscFerret mailing list, or on IRC (philpem on irc.freenode.net). Thank you all for your time. - -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/