On 27/02/12 15:54, Johannes Schontman wrote:
http://www.fpgarelated.com/usenet/fpga/show/105048-1.php
To me this looks Discferret has a problem with either race condition
(pulse lost) or ambiguity (two encodings meaning same) and to me this
looks this problem is valid for all dumps already made. I talked to
other guys from engineering classes and one suggest using 12bits
(instead of 8) for counter but this would mean having to few RAMs on
the board. Does that mean to better not get a Discferret? Has anyone
heard of problems with Kyroflux? Want to start making images soon.
OK, I'm going to stay out of the Kryoflux argument -- I'm the lead
developer for DiscFerret, and developed the entire hardware design,
microcode, and a good sized chunk of the software. My commenting on a
competitor's product would be extremely unprofessional. There was a
discussion about this on-list a few months ago --
First message:
http://www.classiccmp.org/pipermail/cctech/2011-October/127396.html
Rest of the thread:
http://www.classiccmp.org/pipermail/cctech/2011-November/thread.html#127525
The bug you mention was a timer ambiguity error which was detected and
rectified in.. I think it was Release 0028 of the microcode image. All
current versions of the DiscFerret C API and Microcode image have this fix.
Basically, what happened was that if a data pulse immediately followed a
carry, a zero value would be stored in the RAM. Zero was a special value
used to signify a carry. If a pulse landed right on top of a carry, the
pulse would be missed completely -- you'd get the carry, but no timing
value would be stored.
To fix this:
* The entire disc reader engine was torn apart and rewritten.
* The data storage format has been changed completely to allow the
storage of index position to 10ns resolution (previously the state of
the index line was stored with each timing or carry store). These
changes also remove the carry ambiguity.
* The carry ambiguity issue was completely resolved.
* A testbench was written. This is run every time a change is made to
the read logic, and makes sure that all count values from 0 to 65535
generate the correct data streams. This includes several "impossible"
data streams which shouldn't be able to get past the DiscFerret's I/O
buffer hardware.
I've done extensive testing on this, and I'm going to be absolutely
honest here: I can't prove that there aren't any bugs, but I can prove
that *the bugs I know about* aren't present.
If a bug is found, a testbench is written. ALL testbenches have to pass
before a release is made. Commits to the Mercurial (SCM) repositories
don't follow this rule and should be considered to be alpha quality at
best. Final releases on the Discferret website (on the downloads page)
HAVE been run through the testbenches and can be considered production
ready.
If you have any further questions, please feel free to ask.
Cheers,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/