| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Tue, Jan 03rd, 2012 @ 16:07 ( . ) |
Okay, some days have passed since the last status update but it's those nasty little details which are consuming time and are causing delays. I finally decided to use a histogram to determine two threshold values which delimit the sample values for bit sequences 0, 01 and 00... from each other. A histogram is built from the raw sample values, after that it is smoothed until we have at most three local maxima and two minima and the maxima positions are releated to each other like bands with the factors 1, 2 and 3 are. The threshold values used for decoding are the two minima and the first maximum must be in the range from 3.25us (-10% tolerance) to 4.00us (+10% tolerance). For the case that there are less than three maxima the 'missing' values are calculated from the available ones. For example on Rainbow Arts v1 protection we only have sample values for the bit sequences 1 and 01. In that case the threshold for 00.. sequences is irrelevant but still needed for the decoder as a parameter. This is still not sufficient for tracks which contain data written at multiple densities, but anyway it's a start and support for variable density might be added later. The next obstacle which had to be taken are tracks which contain critical data on (and around) the index hole position (obviously those weren't mastered according to index signals). When decoding such tracks the index signal timings from the KryoFlux dump have to be slightly aligned so that the bytes of two consecutive rotations are equal (and not shifted by one or two bits because e.g. the index signal on the second rotation occurred one sample too late). After that we end up with a bit sequence representing the decoded track and starting at a index signal. As this cannot be written 1:1 to a G64 or NIB file due to possible leftover bits data has to be extended to the next byte boundary. At the moment I'm searching for the longest run of 01 bit sequences and extending that run by the amount of bits missing to match a byte boundary. This works for CSS64 3.8 and VICE 2.3 although sector data wraps around the track border, but for some purposes someone might need a different strategy as the current strategy changes length of the track gap or might affect the length of the first sync after the gap. So at some point of time multiple strategies will be offered for usage with different tracks. Tomorrow I'll start to clean up the code and I hope to be able post a very early runnable STREAM to G64/NIB converter at the end of this week. Sorry for another delay, but I didn't want to release a version not working for at least 50% of all common titles. |
1/08/2012 @ 13:26----Markus Benko 1/10/2012 @ 20:18------Pete Rittwage 1/11/2012 @ 00:29--------Markus Benko 2/15/2012 @ 19:40------------Pete Rittwage 2/16/2012 @ 12:56----------------Pete Rittwage 2/16/2012 @ 13:28--------------------Pete Rittwage 4/11/2012 @ 19:59------------------------Markus Benko --- 0 Users Online --- 0 Recent Unique Posters |