JimDrew wrote:As I said in my PM, you don't need to delay anything to duplicate weakbits with a single rev. During the decoding of the track, you will know if the last MFM bits are an even MFM byte. If not, then by wrapping back around to the start of the track data will automatically introduce a different result every virtual revolution. If the track data does decode to an even MFM byte, you can repeat the first bitcell for either even or odd virtual revolutions. Of course, any bitcell time that is outside of the normal clocking window (<3.5us or >8.5us) is a weakbit and you can take the next bitcell value (if also invalid), add them together, and then divide by a random divider and use both of those values for decoding. This is exactly how a real data separator behaves when an invalid bitcell time is encountered.
NFA over index is easy with .scp images. You will see a NFA at the start of the track and at the end of the track. So, when a NFA is encountered at the end of the track, the start has to be checked to see if the NFA continues. You only need a single revolution here too.
These methods are used with the Amiga emulators, and because of this 100% of every type of copy protection can be loaded without any "hacks" required.
Nice job. Can't wait to do more testing!
there was some talks lately with MAME regarding its license. From what I read, redistribution and modifications can only be made if you include the *whole* source tree (which is very big). And even so, I'm not sure the MAME license is compatible with GPL and allows to include MAME code in some other projects.
This is certainly boring stuff, and I don't know if MAME really tries to enforce its trademark, but maybe you'd better write your own decoder from scratch with Jim's help.
Apart from that, nice work in MFM support.
Steven Seagal wrote:Yes, and when you play a game using MAME you must certify that you legally own the original rom. Which we all do, of course. I have thousands of roms in the attic.
You're right, I'll write my own decoder. It will look a bit like MAME's, but with different variable names.
And so there's no reason to thank MAME in the release notes.
Steven Seagal wrote:Maybe I don't get it right. Aren't weak bits possible because of some sort of drive jitter, that slightly changes delays from rev to rev?
Steven Seagal wrote:And doesn't a sync mark like in Dungeon Master sector 0-7 realign the controller on the right bit?
Steven Seagal wrote:In the current dev build, the 1-rev version of DM doesn't work anymore, but the 4-rev version works, even if we use only rev 1.
The 1-rev version decodes to $60, $70 or some garbage instead of $68, $E8. I don't say the image is wrong, might be Steem.
No, that is a myth that came from those that don't understand how the drive's magnetic pickup system works. When a magnetic flux transition is shorter than 1/2 of the smallest value (4us in our case with 3.5" DSDD drives) or 50% larger than the largest value, then the current clock (which is not not available as reference) is used as the bitcell time that is passed on the RDData line. This process repeats as long as the magnetic flux is not valid. When the magnetic flux is valid, the clock is reset. The result is that if you take a weakbit area and add all of the times together, it will equal the same time that normal valid bitcells would be. Because the internal clock runs and is used as a reference, the value will be different for each revolution when an invalid value is found. This is why the data changes on each pass.
Atari Floppy Disk Copy Protection
By Jean Louis-Guérin (DrCoolZic) Revision 1.3a – November 2014
4.3 WD1772 Detection of Border Bits
With the above information it is now easy to understand that if a bit reversals happens close to the border of an inspection window (also called Ambiguous area) it will be detected into the first or the next inspection window based on small variation of the drive rotation speed between two read-sector commands and this will therefore result in pseudo random values returned (fuzzy bits).
For example having a reversal 5μs apart from the previous one can be interpreted as a reversal after 4μs or a reversal after 6μs based on small frequency fluctuation of the rotation speed between two reads. One might argue that it is not possible to make sure that these “marginal reversals” will be positioned correctly due to the fact that the rotation’s speeds of different drives are somewhat different and therefore precise reversals timing on a floppy diskette cannot be guaranteed. But in practice this is where the frequency and phase correction of the WD1772 DPLL comes into play. As explained above the inspection window will have it size (i.e. frequency) and position corrected based on the input reversals stream after reception of only a few reversals. Therefore the DPLL of the FDC automatically adjust the frequency of inspection windows for any acceptable (about 10%) variation of drive speed and adjust the phase so that a “normal reversal” will be perfectly in the middle of the inspection window and a “marginal reversal” will be perfectly at the border of the inspection window.
This also explains why, in most cases, “fuzzy bits” are used in “compensating pair”: for every two subsequent fuzzy bits the first reversal is placed at one extreme (e.g. at the beginning) of the inspection window and the “compensating reversals” of the next fuzzy bit at the other extreme (e.g. at the end) of the inspection window. By using this kind of “compensating bits” we guarantee that the frequency and the phase of the inspection windows are (almost) not affected.
Steven Seagal wrote:Good news indeed, better than expected.
Just to clarify, a beta will soon be "released" but Jim got first look as SuperCard author.
JimDrew wrote: I am going to make an option to strip additional revolutions in image files so that the size of the files can be reduced dramatically. If I can get Steven to support compressed files, we can get the file size down under 2MB.
JimDrew wrote:I made a disk from the Power Drift image file and it works fine in my ST. So, that protection check really is failing under Steem.
Steven Seagal wrote:One version fails, one works, like Dungeon Master. Again it might be a problem in Steem.
People with hardware and good will could confirm this...
Users browsing this forum: No registered users and 1 guest