'Any Kryoflux experiences made yet'
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


REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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.




REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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.


REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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.


REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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


REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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...


REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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.


REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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


REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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. ;-)


REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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...



REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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..


REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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...


REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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.


REPLY: [With No Quote] --- [With Quoted Text]

'Any Kryoflux experiences made yet'
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.


REPLY: [With No Quote] --- [With Quoted Text]


--- 0 Users Online --- 0 Recent Unique Posters

Q398=1670109808 - Threads: / 1670109808