My guess would be defining it via a custom pre-compensation table, but it could have been just an additional function after the track buffer was ready.
In either case, it's an effect that is applied later, so an IPF file would store it as such; whether it will be marked as an algorithmic change in bitcell widths or something else will have to be decided.
Isn't there a more generic way of handling fuzzy bits that would apply to more copy protection schemes?
I submitted some dumps last week (along with other versions for Japanese systems, Apple IIGS), but I wonder which versions and languages I should be tracking down to make sure all of them are preserved.
I will also get back on your question about the fuzzy bits (would like also to better understand how it is handled in IPF). I have a new experimental version that show the decoded bytes as well as the transitions. Quite interesting! But I have something I do not understand so I want to further investigate before I release ...
There is, but DM is the only game with this type of protection so deserves to be stored correctly.Gothmog wrote: Isn't there a more generic way of handling fuzzy bits that would apply to more copy protection schemes?
Here is my understanding - correct me if I am wrong:
Normally fuzzy bits are just used to create a "fuzzy sector" i.e. a sector that will have a different content each time you read it. To check you read multiple times (usually 3 to be safe) and compare the content to check that they are different. With this kind of fuzzy bits it is usually sufficient to store the fact it is "fuzzy sector" with eventually the location of the first byte that differ.
What is unique to DM is the fact that the "border bits" are used to change the bytes 68 into bytes E8. So my guess is that DM not only test the fact that some bytes are different from read to read but also that some byte 68 are turned into byte E8.
I have attached a picture of a section of sector 7 analyzed with an experimental KFAnalyze version. On the plot I have added at the bottom the combined clock/data stream and the resulting extracted clock byte and data byte (from bottom to top). The next line contains a scattered plot of the flux transition spacing where dots in green are "border bits". As can be seen the 68 are changed to E8 in region where are the border bits
You will also notice that "border bits" seems to perturb the DPLL clock
- Section of DM sector 7 (KFAnalyze v1.2 alpha)
- dm.jpg (175.53 KiB) Viewed 2619 times
The ST version can only check for the data bits (the Amiga one does check the clock bits), but does not matter, in principle the result is deterministic weak bits.
As for checking for weak bits some games do a little bit of more work than you'd expect: most notably a protection scheme used by Thalion checks weak bits 50 times in a row, and if any of the reads match any of the existing samples, the protection fails...!
You mean all the amiga games with weak bits do it through unformatted or out-of-alignment zones?mr.vince wrote:There is, but DM is the only game with this type of protection so deserves to be stored correctly.Gothmog wrote: Isn't there a more generic way of handling fuzzy bits that would apply to more copy protection schemes?