| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Thu, Feb 16th, 2012 @ 12:11 ( . ) |
I have been in correspondence with hyper active and he pointed out a track alignment issue. Currently the program does not try to byte-align data after syncs and does not try to performs any form of alignment for whole track data which leads to problems when writing .g64 or .nib files back to disk for those cases, where the index signal occurrs in the middle of vital data (which depends on how the disk has been mastered). Most emulators don't have a problem with non-byte aligned sector headers or data and with micro64 and HOXS I even got Defender of the Crown running (including secondary checks relying on slightly non-standard density - I guess both emulators try to simulate it through calculations with track length and the denoted density). The only modification the program performs is either enlarging a sync mark or the track gap (preferrably) to make the data a multiple of 8 bits so that there is no gap between the last bit and the first bit of the track data within a .g64 file. The more I worked on details like these the more problems I found. It seems that at least my drive has problems with flux transitions being more than about 12-13 microseconds apart, e.g. two consecutive zero bits at lowest density or three zero bits at any density as occurs in V-MAX! track 20 data. In those cases it seems that something similar to the "phantom" bits from a 1541 happens: The drive reports flux transitions where there are none with arbitary timings which are in some cases uniform across the five revolutions DTC / KryoFlux samples from a disk. I still need to solve those problems before I will get into alignment strategies, most probably I'll need help from Softpres people. For getting Defender of the Crown running I had to verbosely log and afterwards modify some bits in the .g64 image to get the V-MAX track readable. What also is an issue is the fact that for disks in relatively bad condition DTC is still able to decode CBM sectors from it while my program is not capable of producing GCR data which results in error-free sectors. I guess the decoding capabilities of DTC are way more reliable than those of my program - another thing I might ask the Softpres people for. So after all my program will have to categorize flux transitions as follows: 1) data with a particular density, 2) data in bad condition where timings could lead to ambigous bit sequences, 3) a larger pause between two flux transitions which my drive produces phantom transitions for (V-MAX!), 4) a non-formatted area / weak bits (Cyan Loader). Some test routines for the latter cases produced runnable .g64 images for e.g. Cyan Loader (newest VICE with weak bit support) but I still couldn't glue something together that works well for all combinations as it's very difficult to distinguish cases 2 to 4 from each other. Another beautiful thing would be detection of the write splice. It seems most tracks are mastered beginning with writing $55 bytes, then all sectors headers, data and intra-sector gaps, after that another run of $55 bytes so that some of the later $55 bytes overwrite some of the already written ones, producing a single flux transition with an arbitrary timing. As you can see, unluckily more and more things get known to be worked out to make the program reliable for most cases. I personally wouldn't want to use the tool for producing .g64 images for archiving at the current stage. At the moment you simply can't be sure to get even standard CBM sector data of a good condition disk decoded correctly - you'd have to scan the resulting .g64 file for errors which NIBTOOLS does refuse due to being not able to find the directory sector (I guess because of the data not being byte-aligned). Say 80% of the .g64 made from disks in very good condition do work and 20% do not. I'll let you know when I managed to almost finish those really important things and this will not be done in just a few days, I'm sorry. |
2/16/2012 @ 13:25----Markus Benko --- 0 Users Online --- 0 Recent Unique Posters |