| 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... |
--- 0 Users Online --- 0 Recent Unique Posters |