| Author: | Womo (guest: search) |
|---|---|---|
| Date: | Tue, Nov 16th, 2010 @ 16:46 ( . ) |
Hi there, although I missed to place an order for the first batch of Kryoflux device I'm probably able to get one of these _before_ chrismas. Did anyone of you around here already make some experiences with Kryoflux and with interpreting the STREAM raw data format (will later be consolidated into the proposed DRAFT format)? Womo [link] [link] [link] [link] |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Tue, Nov 16th, 2010 @ 17:01 ( . ) |
I tried, but I couldn't see how it could have been done with a stand-alone tool like they wanted it to be. It would have to link their code/libraries, from what I saw. |
| Author: | Womo (guest: search) |
|---|---|---|
| Date: | Thu, Nov 18th, 2010 @ 04:49 ( . ) |
Hi Pete, so it still needs to be discovered, if the Kryoflux if of some use for the project. Let's see what's the outcome of some tests, when I got one of these into my hands. I expect to get some enlightments as with my o'scope tests, although the Kryoflux device does not work on an analogue basis. Womo |
 | 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. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Dec 01st, 2011 @ 14:55 ( . ) |
This is great news, Markus! I've recently got a loaner KF and drive that will do the step-8 for side 2 imaging and was disappointed there was no conversion yet. It sounds like you have solved that problem. nibconv/nibtools searches for the track cycle using several methods based on a byte-aligned $2000 byte track when converting to G64 (more from NBZ) so we already have overlap. If we could get just any $2000 bytes in a row from the 5 copies of decoded flux stream, you could use my code. -Pete |
| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Thu, Dec 01st, 2011 @ 18:02 ( . ) |
Apparently somebody else also did a STREAM to G64 conversion before: [link] Is there some documentation on the NIB format? Some example files that I've got look like after the $10 bytes header there's a $f0 bytes large table with two-byte entries denoting track number * 2 (I guess any odd number is an half track) and speed zone with some kind of flag ($40?). And then for each stored track $2000 bytes of GCR data. I've come over one NB2 file which looks similar but is much larger. And NBZ files look like some kind of compression applied to NIB/NB2 data which I don't understand from a quick view. It seems to make sense to convert KryoFlux stream files to NIB/NB2/NBZ first, then use nibconv to convert them to G64. Once I know one of these formats it shouldn't be a problem to provide a runnable .jar file for converting stream files to that format, at least for fixed speed zone tracks. Anything else can be done later, after we have a good starting point. Oh, I almost forgot one disadvantage of KryoFlux: Unmodified drives are not able to seek to track -8 and are therefore not capable of dumping flipsides of C64 disks, i.e. the first 4 tracks are always missing and in some cases there's no data stored so it doesn't matter. Not all drives can be modified and not all people can modify drives, me included. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Dec 01st, 2011 @ 18:35 ( . ) |
NIB is the simplest. NBZ is just NIB with LZ-alike compression applied. NIB files are: 0x100 header 1st 13 bytes ID = MNIB-1541-RAW Then 2 bytes for each track in the file, first is track number (always starts with 2 (track 1 is not accessible on 1541) and almost always ends with 82 unless file is truncated. The second byte is the detected density in the 4 MSB bits, and the sync flags in the 4 LSB. You can ignore the sync flags as they will be re-detected in the conversion anyway. Starting at 0x100, it is simple $2000 byte dumps of each track. This contains about 1.2-1.5 revolutions of overlap. That way the cycle can be detected and stitched back together. It would be nice to have the option to start data at the index signal... |
 | Author: | Nate (guest: search) |
|---|---|---|
| Date: | Mon, Dec 05th, 2011 @ 10:49 ( . ) |
I thought the -j flag to nibread did this -- wait for IHS before reading. This should also be done on the 1571. Then you can just use a header bit in .nib to indicate an IHS was active for this read. Why can't you just make that the default if people use a 1571? That way we can get alignment info, even if it isn't necessary for a given scheme. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Dec 05th, 2011 @ 12:05 ( . ) |
Nate, IHS doesn't work for SRQ in the current ZF release. I think Arnd fixed it with some timing changes, but it didn't make it in your release. There is a flag set in the NIB file if IHS was used- I think. I'll double check. |
| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Mon, Dec 05th, 2011 @ 11:25 ( . ) |
I hope to get a simple converter finished and tested this week. The last days I've been digging into details of the KryoFlux stream data. In my code index signal positions have been calculated incorrectly - whenever a multi-byte samples or NOPs occurred the next index signal was off by the amount of bytes not directly representing a sample. Furthermore I'll change the code to work with cell-widths instead of track lengths to determine the speed zone / density used on a track. By the way: Does nibtools detect the track cycle on a bit basis or if e.g. a track has a length of 7600 bytes plus 7 bits will it have problems with the following data being shifted by one bit, i.e. appearing not as a byte-wise duplicate of the beginning? |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Mon, Dec 05th, 2011 @ 18:47 ( . ) |
G64 was developed based on data on byte-boundaries, so there is no way to represent a track length with leftover bits. I assume this is because that's how we can read it from the shift-register- it's always a byte. I am sure the track length is not always that way, so all further bytes will be out of framing until the next sync mark. |
| Author: | Womo (guest: search) |
|---|---|---|
| Date: | Sat, Dec 24th, 2011 @ 18:00 ( . ) |
Hey Pete, when I remeber correctly to the G64 design discussions back in 1998 or so we already thought about track lengths not dividable by 8 bits exactly. I believe the discussion ended with the opinion that this can be simulated well enough by writing SYNC marks with the speed zone value increased or decreased by one step. To my knowledge no one tested until now, if a native 1541 will ever recognise such "overspeed" or "underspeed" SYNC marks. Furthermore, if you ever are able to detect either a weak bits zone or a write slice within a track you can easily utilise this area and either remove some of the zero bits or add some and write the resulting 0-bits area with a completely different speed zone value. This should also fix the issue. One drawback I could think of: Protections that utilise the floppy's internal 6522 timers may be able to measure out SYNC lengths and also weak bits zones very exactly. Such checks may be able to reveal those manipulations, if not calculated very carefully. Therefore for some protections a virtual disk representation still needs to be remastered manually. As long as all the common C64/1541 emulators are not able to parse G64 track lengths and even don't make use of the speed zone bitmaps optionally includable within a G64 along with a very precise reconstruction of the flux change data stream, all these considerations don't make much sense. Womo |
| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Tue, Jan 03rd, 2012 @ 16:07 ( . ) |
Okay, some days have passed since the last status update but it's those nasty little details which are consuming time and are causing delays. I finally decided to use a histogram to determine two threshold values which delimit the sample values for bit sequences 0, 01 and 00... from each other. A histogram is built from the raw sample values, after that it is smoothed until we have at most three local maxima and two minima and the maxima positions are releated to each other like bands with the factors 1, 2 and 3 are. The threshold values used for decoding are the two minima and the first maximum must be in the range from 3.25us (-10% tolerance) to 4.00us (+10% tolerance). For the case that there are less than three maxima the 'missing' values are calculated from the available ones. For example on Rainbow Arts v1 protection we only have sample values for the bit sequences 1 and 01. In that case the threshold for 00.. sequences is irrelevant but still needed for the decoder as a parameter. This is still not sufficient for tracks which contain data written at multiple densities, but anyway it's a start and support for variable density might be added later. The next obstacle which had to be taken are tracks which contain critical data on (and around) the index hole position (obviously those weren't mastered according to index signals). When decoding such tracks the index signal timings from the KryoFlux dump have to be slightly aligned so that the bytes of two consecutive rotations are equal (and not shifted by one or two bits because e.g. the index signal on the second rotation occurred one sample too late). After that we end up with a bit sequence representing the decoded track and starting at a index signal. As this cannot be written 1:1 to a G64 or NIB file due to possible leftover bits data has to be extended to the next byte boundary. At the moment I'm searching for the longest run of 01 bit sequences and extending that run by the amount of bits missing to match a byte boundary. This works for CSS64 3.8 and VICE 2.3 although sector data wraps around the track border, but for some purposes someone might need a different strategy as the current strategy changes length of the track gap or might affect the length of the first sync after the gap. So at some point of time multiple strategies will be offered for usage with different tracks. Tomorrow I'll start to clean up the code and I hope to be able post a very early runnable STREAM to G64/NIB converter at the end of this week. Sorry for another delay, but I didn't want to release a version not working for at least 50% of all common titles. |
| Author: | Nate (guest: search) |
|---|---|---|
| Date: | Fri, Jan 06th, 2012 @ 14:36 ( . ) |
I assume you're using a histogram (frequency count) to determine timings for the 4 density options? If so, that's a reasonable approach. One thing you can use is that even protection schemes that used variable density within a track didn't use the scheme for every track. So you can just collect a single histogram for all tracks and you should see 4 peaks. For vmax, I think it didn't use all density values so you might just have 3 peaks. Another thing you can use is that you don't need all the peaks, just the distance (time delta) between two of them. Then you can fit this to the predicted other values, based on the divider circuit. If you have an RPM measurement, all of that is unnecessary. You could also perform the above testing once on a "normal" disk image, then use it as a stored drive profile. As long as its speed didn't vary too much, it could be used to analyze other protected images, even those with variable-density in a track. Finally, you can detect variable density easily by just looking for the shortest bit transitions in the track (a run of 1's or a sync, usually). Match those to your histogram to figure out which density setting it was. Now, run a window across your track, starting with that value and a prediction for where 0's will occur (no transition). Once you find that none of the samples in the window fits your profile, the density has changed. Find the shortest time between transitions in the window and fit to the histogram to see the new density selection. Repeat. I'm interested in hearing more about your findings on this. Thanks. |
| 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 |
 | Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sun, Jan 08th, 2012 @ 23:45 ( . ) |
Hi there. remember that disk emulation still is not perfect, so it's possible that you'll still get some freezes and crashes even though the protection is fully intact and has been written the right way in the g64. Cheers |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Tue, Jan 10th, 2012 @ 20:18 ( . ) |
Hi Markus, Thanks, but I can't figure out how to run it. I try: java -cp "d:devnibtoolskfdtoolskfdtools.jar" KFDTools c -i "%1track" -o "%1img_s0.g64" >"%1img_s0.g64.log" But get: Exception in thread "main" java.lang.NoClassDefFoundError: c Caused by: java.lang.ClassNotFoundException: c at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) Could not find the main class: c. Program will exit. Do I have to alter some Java security? D:devnibtoolskfdtools>java -version java version "1.6.0_29" Java(TM) SE Runtime Environment (build 1.6.0_29-b11) Java HotSpot(TM) Client VM (build 20.4-b02, mixed mode, sharing) |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Tue, Jan 10th, 2012 @ 20:19 ( . ) |
And sorry my BBS software filters out slashes... :) |
| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Wed, Jan 11th, 2012 @ 00:29 ( . ) |
"KFDTools" should be the main class and not "c", so I guess the command line in messed up in an inivisible way (possibly no-break space). Short java.exe parameter explanation: -cp "d:devnibtoolskfdtoolskfdtools.jar" ==> where to find the code (class-path) KFDTools ==> main class c -i "%1track" -o "%1img_s0.g64" ==> arguments passed to the main class I additionally attached a .zip file with my .cmd files and hope this helps. If not, I'll update to the java version you use and look if it has anything to do with it. |
Attachments: |
| 1326259631_cmdfiles.zip |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Wed, Feb 15th, 2012 @ 19:34 ( . ) |
Hi Markus, I've tried this and did a simple test image of CBM-DOS formatted Space Taxi. kf2g64 and kf2nib give no errors, but the resulting image is non-standard. It has bad sector headers (error 2). When read with nibtools, all is fine. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Wed, Feb 15th, 2012 @ 19:40 ( . ) |
I see the problem- the images it creates are not byte-aligned to the syncs like the 1541 sends us. I'll have to craft a way to fix these images if you don't do it on your end. |
| 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. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Feb 16th, 2012 @ 12:56 ( . ) |
No apologies necessary! I appreciate your work. I have a Kryoflux myself and have started submitting images. I don't think it would be a problem to re-align to the syncs on these images, so I will come up with a routine that does it on the nibtools-end. -Pete |
| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Thu, Feb 16th, 2012 @ 13:25 ( . ) |
That would be great in that it could be used for error-scanning of generated .nib or .g64 files then. By the way, I guess you solved the problem with running Java / the converter now? I'm keen to know what has been the problem... |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Feb 16th, 2012 @ 13:28 ( . ) |
Hi markus, There was no problem except my BBS software stripping the commands out when you posted them. I modified your scripts you attached to my own local paths and it worked fine. The only limitation to them (which is easily fixed) is they also assume the images are prefixed with "track_" which SPS hates in their submissions... as I said that is easily fixed in script also. |
 | Author: | RJMcInty (registered user: 2 posts ) |
|---|---|---|
| Date: | Mon, Mar 05th, 2012 @ 23:33 ( . ) |
Markus, can you share the latest bits? (or a download location for them?) Thanks! Robert |
| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Wed, Apr 11th, 2012 @ 19:59 ( . ) |
If I can't find enough time to care about the converter anymore, I will clean up the current code and release the source - I promise to do so. But currently I'm working on it and ran into new problems, namely Rainbow Arts V1. Pete said that the protection checks for a sync of 1024 bits. On my Spherical disks there are exactly 1000 bits instead. The resulting .g64 image won't pass in CCS64 and Vice, but passes in Hoxs 64 and micro64. Interesting. So I took the .g64 from GB64 (sync of 1008 bits) and tried to run it in these four emulators. The surprising result is, that it passes in Vice, but in no other emulator. After thinking about it and doing some calculations I hoped to generate a .g64 that would run in all emulators - and I partly succeeded, as I couldn't convince CCS64 to let the protection pass. But the image runs fine in Vice, Hoxs 64 and micro64. From the KryoFlux dump conversion I knew there is 1000 one-bits in a row on track 36 and it has a total length of 6914 bytes, which corresponds to a cell width of roughly 3.61 µs. The track was just mastered this way and the same "odd" density applies to all other tracks with density $02 (normally corresponds to 3.5 µs), too. This means that the sync mark of 1000 bits would take 3610 µs to fully pass by. How many bits would be needed to make up 3610 µs with 3.5 µs cells? 1031 bits, and that is somewhat nearer to 1024. I remember having had success with running Defender of the Crown with full copy protection intact on micro64 which involved density-checks on side 2 which would pass on no other emulator. That was a first hint at micro64 obviously being taking track lengths into account instead of (or additional to) the densities defined in the .g64 header. 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. Knowing that micro64 most probably derives the actual density from the track length, we now can calculate how long the sync mark takes in its emulation: 3.15 µs (derived from track length) * 1008 bits = 3175 µs (remember we need 3610 µs). This just cannot pass. Guess what I did then: Put 1030 one-bits as a sync mark into the track with HxD (hex editor) and set the track length to 7142 bytes which is closest to 3.5 µs. Works fine for Vice which obviously ignores track lengths for density calculations (and ignores the densitiy values in the .g64 header aswell) and also works fine in Hoxs 64 and micro64 which both probably do some calculations with the track length. But... do you understand the problem with this? This only works because the protection scheme is time-based and not counting single bits (I'm just guessing, but how else would it work?). But what happens if the routine additionally would count the bits (just imagine it was a repetitive data pattern and not one-bits) and expect them to be 1000? Then the density normalization trick would not work... 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. I think that this is the main problem with .g64 and emulators. It all depends on a check being either time-based or bit-counting or even a mixture, but the .g64 format and emulators certainly have their limits and we can only try to make .g64 as compatible as possible, even if this, what was logic once, more and more becomes magic now. ;-) |
| 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... |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Wed, Apr 11th, 2012 @ 23:37 ( . ) |
I have a sync-byte-align option working, it just causes a little corruption in the image, or else I have a bad example. I'll test it some more in the next days.. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Thu, Apr 12th, 2012 @ 21:31 ( . ) |
OK, sync-byte align routine is now working in nibtools using the (currently undocumented) -$ switch... |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Sun, Apr 15th, 2012 @ 20:03 ( . ) |
Hi there. If you have trouble trying to create a Rainbow Arts track 36 that will work under every emulator, it shouldn't be much of a concern, because not all emulators are up to the same standard. At least kryoflux is able to ascertain what the actual contents of the track are, and it's actual size, rather than having nibtools take a rough guess at what it is. |
| Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Apr 15th, 2012 @ 20:42 ( . ) |
A "rough guess"? Haha- it's a little better than that. We see what the 1541 hardware sees, which is almost all the matters except for extreme cases. |
 | Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, Dec 01st, 2011 @ 23:16 ( . ) |
Another benefit is exact reproduction of sync lengths. This was a major weakness when using a 1541 to read disks, although with some special routines it would be possible. |
 | Author: | IFWSPS (guest: search) |
|---|---|---|
| Date: | Fri, Dec 02nd, 2011 @ 12:56 ( . ) |
Hi All, 1, You can dump the flipside of a disk, if you don't care about the original alignment (e.g. demo, scene, work etc disks) using a fake index signal, that's a very simple circuit. You obviously need to flip the disks though. For authentic imaging you do need a modified drive that can seek to track -8. The disk does not have to be flipped, it can be imaged in a single pass automatically. This is exactly how the games were duplicated in the first place. This is not a limitation of KryoFlux, it is how PC drives work - the index signal is required to regulate the drive speed, detect that a disk is inserted (after two index signals passed within a period) and enable the output on the READ gate. 2, You may use the existing tool coded for g64 conversion (I don't have or use it, but I am sure the author would be happy to post it), or if there is enough interest I'll add g64 output to the official host software - but right now I have a very busy schedule :) 3, The KryoFlux host software can detect modified c64 disks and fully verify a lot of formats during dumping - and more is being worked on. Cheers, IFW |
| Author: | RJMcInty (registered user: 2 posts ) |
|---|---|---|
| Date: | Fri, Dec 23rd, 2011 @ 23:10 ( . ) |
IFW (as if you didn't already know this): I'm keenly interested in STREAM -> .G64 conversion. :^) I'm going to try to reach out to the person (Zer0-X) on c64.org to see if I can get a copy of their conversion utility, but, ideally, I'd love to see it be part of DTC. I'm happy to test out any other solutions people come up with as well. Cheers! Robert |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Thu, Jan 12th, 2012 @ 00:34 ( . ) |
Hey Markus. Could you attach all the disks you've done with kryoflux in .nib format? Thanks. |