| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Thu, Dec 01st, 2011 @ 11:41 ( . ) |
I've dumped some C64 disks with the KryoFlux device and currently I'm working on STREAM to G64 conversion in Java. First, the flux traversal times must be converted to bit streams. I'm currently using a self-adjusting timer with a virtual clock derived from histogram values for a specific track. The self-adjustment is done to overcome slight speed variations. Obviously, speed zone changes within a track cannot be handled this way and write splices would cause problems. Having converted the flux timings to a bit stream, my code tries to find a track cycle (KryoFlux stores data from >5 track revelations). I guess this is a point where conversion to NIB instead of G64 would come in handy - or index signals should be taken into account (still needs to be coded, will make things easier). However, you can derive single speed zone bit streams from each track's STREAM file without bigger problems, but the resulting bit stream might have a length so it does not fit into byte boundaries (a few bits too much or too less). But track lengths in G64 files are given in number of bytes, not in number of bits. So you'll have to either truncate the data or perform padding. But with which bits you would pad? And at which position? You cannot just "insert" some bits at the end just because the end of the bit stream might be in the middle of sector data. Analyzation and alignment is a big problem here. But the advantages of KryoFlux dumps are the following: 1. Index signals. Track-to-Track alignment shouldn't be a problem anymore as this can be derived from the STREAM data. 2. Variable speed zones in a track. With proper flux traversal timing interpretation it should be possible to detect areas using different speed zones and generate proper speed zone information to be stored in a G64. Distinguishing those from write splices will be a difficult thing, although such splices shouldn't occur that often in original disks. |
12/01/2011 @ 18:02----Markus Benko 12/05/2011 @ 11:25--------Markus Benko 1/06/2012 @ 14:36--------------Nate 2/15/2012 @ 19:34----------------------Pete Rittwage 2/16/2012 @ 12:11--------------------------Markus Benko 2/16/2012 @ 13:25------------------------------Markus Benko 3/05/2012 @ 23:33----------------------------------RJMcInty --- 0 Users Online --- 0 Recent Unique Posters |