| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Wed, Apr 11th, 2012 @ 19:59 ( . ) |
If I can't find enough time to care about the converter anymore, I will clean up the current code and release the source - I promise to do so. But currently I'm working on it and ran into new problems, namely Rainbow Arts V1. Pete said that the protection checks for a sync of 1024 bits. On my Spherical disks there are exactly 1000 bits instead. The resulting .g64 image won't pass in CCS64 and Vice, but passes in Hoxs 64 and micro64. Interesting. So I took the .g64 from GB64 (sync of 1008 bits) and tried to run it in these four emulators. The surprising result is, that it passes in Vice, but in no other emulator. After thinking about it and doing some calculations I hoped to generate a .g64 that would run in all emulators - and I partly succeeded, as I couldn't convince CCS64 to let the protection pass. But the image runs fine in Vice, Hoxs 64 and micro64. From the KryoFlux dump conversion I knew there is 1000 one-bits in a row on track 36 and it has a total length of 6914 bytes, which corresponds to a cell width of roughly 3.61 µs. The track was just mastered this way and the same "odd" density applies to all other tracks with density $02 (normally corresponds to 3.5 µs), too. This means that the sync mark of 1000 bits would take 3610 µs to fully pass by. How many bits would be needed to make up 3610 µs with 3.5 µs cells? 1031 bits, and that is somewhat nearer to 1024. I remember having had success with running Defender of the Crown with full copy protection intact on micro64 which involved density-checks on side 2 which would pass on no other emulator. That was a first hint at micro64 obviously being taking track lengths into account instead of (or additional to) the densities defined in the .g64 header. And exactly here lies the reason for the .g64 not to pass the protection in Hoxs 64 and micro64. Because in that image (GB64), track 36 length is 7928 bytes which is far more than 110% of what's really on disk. As this is the absolute maximum a Vice-compatible .g64 track may contain, I guess a bug in nibconv or wrongly used settings are responsible for this. Knowing that micro64 most probably derives the actual density from the track length, we now can calculate how long the sync mark takes in its emulation: 3.15 µs (derived from track length) * 1008 bits = 3175 µs (remember we need 3610 µs). This just cannot pass. Guess what I did then: Put 1030 one-bits as a sync mark into the track with HxD (hex editor) and set the track length to 7142 bytes which is closest to 3.5 µs. Works fine for Vice which obviously ignores track lengths for density calculations (and ignores the densitiy values in the .g64 header aswell) and also works fine in Hoxs 64 and micro64 which both probably do some calculations with the track length. But... do you understand the problem with this? This only works because the protection scheme is time-based and not counting single bits (I'm just guessing, but how else would it work?). But what happens if the routine additionally would count the bits (just imagine it was a repetitive data pattern and not one-bits) and expect them to be 1000? Then the density normalization trick would not work... Does the .g64 contain those bits that really exist on disk or those bits returned by the 1541? But syncs aren't really bits when detected by a 1541? And what about weak bits? Vice expects weak bits to be present in the .g64 as on the disk surface (i.e. no flux traversals - no one-bits - zero bytes) but at the same time expects sync mark bits to represent the output (sync duration) of the drive instead of the bits really present on disk. I think that this is the main problem with .g64 and emulators. It all depends on a check being either time-based or bit-counting or even a mixture, but the .g64 format and emulators certainly have their limits and we can only try to make .g64 as compatible as possible, even if this, what was logic once, more and more becomes magic now. ;-) |
--- 0 Users Online --- 0 Recent Unique Posters |