| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Sun, Jan 08th, 2012 @ 13:26 ( . ) |
I'm glad to release the first preview, pre-alpha or whatever-it-should-be-called version of the STREAM -> G64/NIB converter. Unfortunately no sources yet (or by request only), these will be hosted in some days on SourceForge.net. Basic instructions: 1. Save the JAR file somewhere on your drive. 2. java -cp path/kfdtools.jar c -i path/track -o path/image.g64 (JAR files is not runnable directly, Java 5+ is needed, if unsure use Java 6) Example batch file content (Windows), which KryoFlux STREAM dump folders can be dragged on for conversion to G64 format with generation of a log file instead of showing progress on the console: java -cp "C:Program FilesCLkfdtools.jar" KFDTools c -i "%1track" -o "%1img_s0.g64" >"%1img_s0.g64.log" If conversion to NIB is preferred just name the output file accordingly (with .nib extension) and NIB format content will be written. The examples assume that the track files in the KryoFlux dump directory are named track00.0.raw to track82.0.raw. If they are named differently, just substitute the "track" occurrences in the examples accordingly, i.e. "mygame" if the files are named mygame00.0.raw etc. The current version does not use a histogram-based algorithm by default. Instead it uses a new brute-force-like algorithm which works clock-based. On modern machines it should decode one disk side in about 5 to 10 seconds. Now some explanation of the algorithm: 1. Minimum and maximum are specified for the base band (3.25us and 4.00us) and adjusted by 20% tolerance. 2. These values are converted to their integer i.e. raw sample representations as they would occur in the STREAM data. 3. Each possible integer value in this range is taken as the initial clock value (duration between "ticks") and decoding is "simulated" for each complete revolution of a track (there are 5 revolutions saved in track dump files by default) measuring decoding quality and calculating a checksum for decoded data. 4. For the data checksum that appeared most often (at least 2 times, number appears as "confidence" on the console) one initial clock value / revolution number pair is taken and real decoding is performed. 5. If the same decoded data did not appear for at least two times, the parameters that lead to the longest run of "strong" bits are taken to perform real decoding. 6. If track quality is below 10% (that means very roughly that not even 10% of the track could be decoded to "strong" bits) the track is considered completely unformatted. Some short explanation of the term "strong" used in this context: Whenever the timing of the next flux transition is more than 5% off the expectations the resulting data is considered "weak" (not exactly in the sense of "weak bits" often in this context). If it is within the -5%/+5% range it is considered "stong", i.e. even small changes to density, RPM or clock would not lead to different decoded data. The more the initial clock value is not conforming the sampled data the more "weak" bits will occur during decoding and the more unreliable the resulting bits will be. Btw: To make the data fit byte boundaries track gaps are extended by some bits. If no gap of at least 200 bits is found, the first sync is extended. I have tested the converter with the following protections schemes successfully (in either CCS64 or VICE 2.3): 1. Track skew checking (Red LED) 2. Rainbow Arts V1 / sync length check (Blue Angel 69) 3. GMA / signature (International Karate, Arac) For the following protection schemes it did not work: 1. Vorpal later (hangs during load) 2. Vorpal early (hangs during load) 3. V-MAX! V2 (Dig Dug, hangs on track 20) 4. CYAN loader (Turbo Outrun) 5. $AC byte check on track 41 (Quedex, Power Pack) Turbo Outrun works in VICE 2.3 when some bytes in the resulting G64 according to the unformatted area in the scatter view (KryoFlux) are patched to $00. As soon as detection of unformatted areas and generation of $00 bytes for those is implemented, this kind of "weak bits" protection will work. The $AC byte check fails when there are not really $AC bytes in the G64 file. The data needs to be bit-shifted by hand to make $AC bytes appear. After that it will work. The track has no sync so maybe it's an emulation problem that the data will always come as non-$AC and won't be shifted randomly. Just a quick guess. I compared track 20 of Dig Dug (V-MAX! V2) of my converted dump with that contained in GameBase and found that somewhere in the EORed data there are one or two extra bits. There is a short unformatted area and widely spread bad GCR (0001 bit-sequence runs), maybe that's and some 1541 internals are the reason for the difference - I'll have to do further investigations. Meanwhile I'd like to hear about your experiences with the converter (maybe a new thread in this forum?) and as my English is not that good any corrections for some unlucky or ambiguous terms used here is appreciated. :-) |
Attachments: |
| 1326047110_kfdtools.zip |
1/10/2012 @ 20:18--Pete Rittwage 1/11/2012 @ 00:29----Markus Benko 2/15/2012 @ 19:40--------Pete Rittwage 2/16/2012 @ 12:56------------Pete Rittwage 2/16/2012 @ 13:28----------------Pete Rittwage 4/11/2012 @ 19:59--------------------Markus Benko --- 0 Users Online --- 0 Recent Unique Posters |