NIB files write support

Have an idea how to make KryoFlux even better? Let us know...
Post Reply
Posts: 2
Joined: Mon Apr 01, 2013 7:04 pm

NIB files write support

Post by Comos » Tue Apr 16, 2013 11:54 am

Greetings everyone,

just want to ask, is it possible to incorporate also a write feature for the NIB file format please?
IMHO, for me it would be better in the future to write (or dump) with one device instead of two, lots of stuff is already preserved in NIB format.



User avatar
Posts: 2634
Joined: Mon Nov 08, 2010 2:42 pm

Re: NIB files write support

Post by IFW » Tue Apr 16, 2013 12:26 pm

No, it's not planned.
Please convert the files to g64 using nibtools and write th g64 file instead.
Please be aware that artificially changed g64 files that are "made to work" under specific emulator releases (e.g. changing sync counts, track sizes etc until they get to work...) will fail on real hardware as well as up-to-date emulator versions as they did not reflect how the real hardware worked, they just worked around incomplete emulation.
I recommend using the extended g64 files converted by DTC (image type -i22a) from stream files, as those contain all the information that is necessary for mastering and verification.
Verification during writing is only possible if such information is available, normal g64 files do not hold the required data.

Posts: 2
Joined: Mon Apr 01, 2013 7:04 pm

Re: NIB files write support

Post by Comos » Tue Apr 16, 2013 9:17 pm

OKay, thanks for the tips.Yes, I know that you have to update the existing G64 format due to the mastering.

Posts: 65
Joined: Mon Nov 21, 2011 5:21 pm

Re: NIB files write support

Post by rcade » Wed Apr 24, 2013 11:35 pm

Agree 100%... and I wrote nibtools. :)

To set the record straight a little, I never modify any NIB file directly- only the G64's made from them, and they are marked as "patched" in my collection. Also, a lot of the G64's from Gamebase have "parameters" applied, so they are more heavily modified. You don't want those if you are going for original unmodified disks.

The reasons that G64's had to be patched:

1) Protections that measure sync length used to be inaccurate in emulation. They should be correct in VICE now thanks to SPS' recent additions.

2) Many people slowed their drive motor down to 297/298 in order to write long tracks (in the old days this was needed with Maverick, Supercard, etc.) When imaging disks with the drive set to the lower speed, syncs end up a bit longer since that "stretches" the bit cells. We can only count cycles to estimate sync length inside the drive code, so if the drive speed is set too wrong, we can sometimes even mis-detect the density. That makes the sync lengths *very* wrong.

3) Most CBM drives are belt driven except the 1541-II and 1571, and there is also a 1-2 cycle wobble using BIT/BVC code in the drive. We can only count cycles to estimate sync length, and it will be a bit off here and there even with everything else perfect.

With all these things against us using the 1541 hardware and emulation, sync lengths had to be adjusted sometimes to pass protection. Kryoflux-read G64's on modern VICE releases should no longer have this problem.

For track length issues:
This code was changed in VICE (and the 1541 Ultimate firmware) to where the bit rate is based on the total track size which isn't really 100% correct, but this is a good compromise for emulation and G64 limitations. nibtools does not handle bit rate changes within a track, or multiple speed zones, so those would never even be possible from a NIB file. If nibtools cannot find the track cycle (such as the case with some custom protection tracks) it creates a very long track (max G64 size, to avoid truncation of data) that is detected by the new VICE as a track with a very wrong bit rate. You can work around this in some cases by specifying -C to simulate a 300RPM disk rotation speed at the detected density, but that will truncate any data that doesn't fit in one revolution. This may truncate needed data, since we never detected the true track cycle.

You should be able to remaster most G64's from converted NIB files properly, but not ones with heavier protection that required bit-level accuracy in the length of sync and "weak bit" (absense of flux change) areas. For that, you need a KF with -i22a images.
Pete Rittwage
C64 Preservation Project

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest