| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sat, Jan 28th, 2012 @ 17:23 ( . ) |
This one doesn't work due to a non-standard density within a sector. 1. Seeks to track 35, sector 1 2. Reads 41 GCR bytes after the sync mark, they must all be $5A. 3. Changes to highest density. 4. Read 3 GCR bytes, remembering the 3rd byte. 5. The next 10 GCR bytes must all be the same as that 3rd byte. The image is easily fixed for emulators by making those 11 bytes all the same (ie. $65). Fixing this for writing back to real diskette requires a special writing routine that can write this sector with the required non-standard density. |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Jan 29th, 2012 @ 12:07 ( . ) |
Thanks for looking at it... I'll change the database entry. |
 | Author: | Womo (guest: search) |
|---|---|---|
| Date: | Wed, Feb 01st, 2012 @ 19:16 ( . ) |
Oh yes, and will you also create a custom G64 file that contains this special in-track bitrate change with the help of the speed zone area? Have a look at: [link] Bytes: 015C to 02AB and the following sections with the definition when a 4-byte entry of that table stores a value greater than 4 ("file offset referencing a speed zone block for the track"). Of course, most current emulators will not be able to interprete this G64 correctly, so the resulting G64 will become something of a test case file. Womo |
 | Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Fri, Feb 24th, 2012 @ 21:21 ( . ) |
Vice, well, the last new version that was released seems to handle the patched g64 quite well, there's still the matter designing some method to specify which part of the track is in the custom density and which part is the standard one so it can be written back out. |