KryoFlux Support Forums

You might have noticed it's gotten a bit quiet after adding write support to KryoFlux last summer. The reason is that behind the scenes the next big thing has been prepared. We always felt that the C64 community was lacking a format that would give them the opportunity to feed raw data more or less reliably into emulation. It turned out that G64, a format we had been discussing earlier, was in fact capable of working for an estimated 95% of all scenarios out there, but implementation in many emulators is so bad that things the format has to offer simply don't work in emulation.

It's been a while since we said we'd not touch G64 as G64 was "bad", "not working" and "giving people a false impression about preserving things". While we stand firm that G64 is not the grail of a preservation format, we must apologize for being stubborn in regard to supporting it. Gladly many of you were stubborn, too, requesting G64 being supported, which finally led to the decision to do it right and correct things as needed.

We turned to Pete Rittwage and his C64 Preservation Project. We in fact had been in touch for years and we were happy Pete shared the vision we had and decided to not let us have the fun on our own: "I am more than happy to help push technology forward. I knew the limitations of what I was doing with the old 1541 hardware and was excited to hear that work was being done on the 64 with Kryoflux. I was glad to fill a gap until more high-resolution disk imaging was available." While this is flattering, it would be an understatement to call Pete's work a gap filler - his NibTools are very much appreciated among the C64 community. Another helping hand came from Robert McIntyre who already had helped modifying 5.25" drives to allow for one-pass dumping of flippy disks.


The following months were spent on research and getting things done, which finally led to a few conclusions:

a. C64 preservation is still possible today, but results largely depend on media quality and storage.

b. About 90% of games can be imaged with a 1541, 95% can be imaged with KryoFlux and the last 5% can be imaged with KryoFlux as well, but representation will need a more sophisticated format like our own IPF.

c. Nearly all emulators are "broken" in regard to G64 image support. While some will go beyond the limit of 7928 bytes per track (which seems to be the maximum track size chosen by many programmers), some even don't support half tracks. This protection technique utilises the fact that the 1541 has a head designed for a 40 track drive, but features a stepping mechanism that can address 80 tracks. VICE, the most popular, has several flaws in the floppy support code which makes it impossible to use such images unaltered.


If you take the time to read Pete's pages (http://www.c64preservation.com/) you will find many details on how to modify or alter images to make them work in emulation. While some changes are needed because the 1541 alters data before handing it over to the host computer (which means this also happens with other devices that work directly with it) the other half of changes are needed to work around flaws present in certain emulators.
We decided it would not make much sense to release KryoFlux with capabilities that would go beyond those of the emulators around which is why we decided to also update VICE and give it extended G64 support to load many images properly without any user interaction. While Softpres' István Fábián worked on creating an intelligent conversion algorithm for DTC that would transform stream data into meaningful G64 representations, Robert focussed on exorcising VICE and fix/add the features needed to make the 1541 in VICE behave like the real device. To give the emulation the precision needed to also run the most advanced protection methods, the trio even delved into the schematics and created a logic model that was verified shortly after by Pete by writing special test files back to disk with modified versions of Nibtools and then comparing results. Luckily, the data was seen as predicted.

So, after many months of research and hard work, about 1,000 C64 games dumped, and many many emails later, we are proud to present:

1. DTC with enhanced G64 export. We already released a beta with very simple G64 support. Rated in percent, the preview published had a success rate of 40%, the one published today should be good for 85%. Please make sure to not toss your stream files (which are mandatory for generating G64 files) - you might need them to fix images that won't work when we release the next version. If you get an error telling you there was a problem converting to G64 - be sure there was and the image is bad. DTC will refuse to convert to G64 directly from a floppy disk. You must create STREAM files first, to avoid unnecessary stress applied to the ageing medium. Please read the manual (especially page 19 and 20) about how this new exciting feature works.

2. PREVIEW version of VICE with enhanced G64 support. This is our special gift to the community, and we're sure many users will appreciate it. You won't need a KryoFlux to benefit from it, many images that are floating around and needed to be fixed will now work right away. We'll hopefully be working with the VICE team to get our updates included in the official sources, but until that happens we'll continue to provide a second fork (W32 build as of today) on our site which will have extended G64 support. Please note that this preview does not yet enable half-track support, which will come in an update within the next month. We will also be releasing the source for this modified version at the same time. Please see the README file included with the builds for further limitations, this still is a PREVIEW version.

Attached is a picture of a game that for sure won't run on an unmodified version of VICE: "Defender Of The Crown" by Cinemaware. It features V-MAX! v2 protection and perform a precise density check on the disk as soon as the player goes raiding. This image will not run in the current official build of VICE. To give you a chance to try this new feature, the G64 for "Defender Of The Crown", courtesy of CW Holdings, Inc., is included with the VICE build on our website. The new build of VICE will also run many other G64 files now that did fail before. If you ever tried some of the early Rainbow Arts or Magic Bytes titles (so called BetaSkip protection by MWS), like Giana Sisters, Turrican or Blue Angel 69... all of these should work flawlessly now.

All of the above is available as of today. Just head over to http://www.kryoflux.com and grab the download of your choice. We'd love to hear your thoughts on this.

For those interested:
The new circuitry simulation code allows VICE to read data recorded at a certain bitcell density to be read back at a different bitcell density. e.g. data recorded at 3.5us to be read back at 3.5us correctly as well as get the expected results when reading at say 3.25us timing setting.
Surely nobody would do that, right...? Wrong.
All RapidLok protected titles rely on this to be working

Of course, the protection method used by some Software Toolworks titles relying on the same effect - such as The Fidelity Chessmaster 2100 or Beyond the Black Hole - works perfectly now.
Plus many games that only ever worked if the disk image was patched/protection partially or fully bypassed.

There is just one thing left to say: If you use existing G64 files for Rainbow Arts tiles or other games that incorporate sync length checks, the protection might not pass in this preview version of VICE although it does work in the latest unmodified version.

This is due to the tracks being mastered with a bitcell density which is not used when reading back with a 1541, e.g. 3.6us (as on Spherical C64 disk). When reading those disks with nibtools it would calculate how many 1 bits would be needed to make up the determined sync duration at 3.5us (or whatever read density is selected) and this number of 1 bits is then written to the G64 file, which then does not closely enough represent what's really on disk. These images tend to work in unmodified Vice versions but -for a good reason- won't necessarily work in this preview version.

To keep it short: This is not a bug in the new drive emulation but it's a problem with the data in the G64 files.

Just a question... is this a temporary measure until the IPF libraries have been extended to fully cover GCR coding? Or are you saying, "For Commodore stuff, G64 is the way to go and IPF is not"?

Oh and thanks for the great work, much appreciated.

It's already outlined above. If you don't care about certain things, and can live with 95% compatibility (also losing the option to write such an image back under several conditions, g64 does not record track splice position etc.), you are ok with G64. Since the very same stream files can be turned into g64 and IPF, why not do a first convert to g64, and then let us do IPF when tech is ready?

Thanks... it's just that I kinda feared you might have "given up" on IPF for platforms not yet fully supported by it, or lowered your standards. I'm a believer in a fully universal format so to speak, and not really happy with the current jungle of emulator formats.

No, we just wanted to support a feature that was requested by many users. IPF will come to C64 and other platforms for sure.

G64 files can't be compared; the content is not separate from the context; gap is not separated from data; they hold no information on write splice; bitcell width can only be guessed; there is no information on track geometry; there is no way of telling about recording artefacts; they store raw flux transitions (actually... processed flux transitions as the 1541 hardware alters them...) as a single stream instead of the context telling about encoding and geometry so on...
G64 was meant to be a way of storing raw data exactly how a 1541 sees it during reading - at the time of its creation nothing like KryoFlux was even foreseeable; reading via 1541 was the only solution -, and it serves that's purpose well.
No more, no less.

Also keep in mind that it's a one-way, lossy conversion, not to mention it relies on very complex logic that may change with subsequent releases of DTC producing different files - just like imaging the same thing twice on your 1541 would never yield the same file twice. Although this public release is fairly stable, so it's more likely that only well known, specific problems would be addressed which might change a track or two in an image rather than the whole lot.

Always keep your stream files.
They are the only authentic source of creating either a G64 or IPF file.
If you are serious about preservation please get in touch so your collection could be properly preserved, using a flippy drive.

Creating a G64 is not a manual process like creating an IPF and unlike IPF does not require any sort of knowledge to just use DTC or the GUI to create a G64.
G64 is good for casual use when one would expect to play his favourite game without going through a lengthy process of creating a gold master for that purpose
You (I guess...) wouldn't take a low res jpg to a printer to create A3 posters, but it looks nice on your screen anyway, until you need a higher resolution version for a family album or printing or whatever else.

The G64 support is good for having fun with emulators software or hardware based, it's not good for long term preservation or if you want more than just playing.

Updating G64 support in VICE also helps with IPF support when that will be available, as running IPFs usually requires more precise emulation - patching IPFs to make them work in specific emulators is not the solution; which is very common and in fact has become the norm for existing G64 images.
DTC would never produce an altered image to make it work in any specific emulator - including VICE to keep the competition fair -; if something does not work (and is not an issue of DTC) tough; the emulator should be improved as it acts like an incompatible hardware.
I believe that fixing inaccuracies or bugs in emulators, and making them work closer to how the original hardware works should be the way for the future for both emulation and preservation.

EDIT: changed some wording in my description above for clarification.

Additionally, as Feltzkrone said before making the emulation more accurate has the side effect that specifically altered G64 images that work around emulation inaccuracies (usually timing and bitcell width related problems) that used to work before would no longer work as they don't represent the real data that was on the disk.