| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Feb 16th, 2012 @ 13:28 ( . ) |
Hi markus, There was no problem except my BBS software stripping the commands out when you posted them. I modified your scripts you attached to my own local paths and it worked fine. The only limitation to them (which is easily fixed) is they also assume the images are prefixed with "track_" which SPS hates in their submissions... as I said that is easily fixed in script also. |
 | Author: | RJMcInty (registered user: 2 posts ) |
|---|---|---|
| Date: | Mon, Mar 05th, 2012 @ 23:33 ( . ) |
Markus, can you share the latest bits? (or a download location for them?) Thanks! Robert |
 | 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. ;-) |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Wed, Apr 11th, 2012 @ 21:30 ( . ) |
On 04/11/2012 @ 19:59, Markus Benko wrote :
: 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. : : 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. : Hi Markus, Not really a bug exactly, but just a limitation. The 1541 doesn't send us byte-ready signal while reading sync, so we can only estimate the actual sync length by cycle-counting the time we aren't seeing the signal. It is pretty close, but gets a little off easily if the drive motor is fast or slow, flutter, or other factors. The same thing happens with weak-areas (no flux transition) but in that case we do get byte-ready but it's not "real" it's a logic overflow instead. With Kryoflux we know the exact time between the bits and we could never get that from a 1541 through the interface we have... |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Wed, Apr 11th, 2012 @ 23:37 ( . ) |
I have a sync-byte-align option working, it just causes a little corruption in the image, or else I have a bad example. I'll test it some more in the next days.. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Apr 12th, 2012 @ 21:31 ( . ) |
OK, sync-byte align routine is now working in nibtools using the (currently undocumented) -$ switch... |
 | Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sun, Apr 15th, 2012 @ 20:03 ( . ) |
Hi there. If you have trouble trying to create a Rainbow Arts track 36 that will work under every emulator, it shouldn't be much of a concern, because not all emulators are up to the same standard. At least kryoflux is able to ascertain what the actual contents of the track are, and it's actual size, rather than having nibtools take a rough guess at what it is. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Apr 15th, 2012 @ 20:42 ( . ) |
A "rough guess"? Haha- it's a little better than that. We see what the 1541 hardware sees, which is almost all the matters except for extreme cases. |