So what is IFFL?

IFFL is the technique to link disk data. Since the drive allocates a full sector as a minimum, the last sector is statistically only half full. So if you merge several files into a bigger one, you statistically win half a block per file you add to the merged file.

Variants

It’s also fair to say that IFFL exists in two versions;

Version 1: This one is merely merging the files of a level into one bigger, where they are always meant to be loaded all at the same time. Here it is not possible to load only one of the segments without loading (and possible discarding) the segments preceding the one you are after, but if you package segments to be loaded at the same time, this is no restriction. A merit of this type is also that it doesn’t need any code in the drive and you can hence use standard Kernal load and save routines in parallel. So this is simple and straight forward, has no constraints on the compatibility.

Version 2: The concept matured and people added a routine to scan the IFFL file, to generate a table containing track, sector and offset of the different segments (this as the file can be copied and the track/sector part can be different every time the game is run). Using this technique, it’s possible to load an arbitrary segment. This is really handy, but it comes with a price; there must be code in the drive that handles the tables. And not all drive units have any drive RAM (SD2IEC for starters). And supporting a plethora of units, you need drive code that works in as many as possible. (Having said this, Uload does have the tables in computer RAM but I’d say it’s not really common to have memory enough to store the scan tables in computer RAM).

History

The term was to the best of my knowledge coined by Snacky when he released Another World in 1989 (or by OMG if you read the interview with Snacky). This was a version of IFFL version 1. It’s quite interesting that Gollum had used the same technique before, but just not given it any special name – see RoadBlasters from 1988. So Snacky didnt invent it – GP just coined the term.

Why should we use IFFL?

Size

Cracking games on the c64 has always involved two types of competitions – speed (first release) and quality when the size and number of files have been a key aspects. Triad’s magazine Gamer’s Guide was the leading force, driving people to perfect the release in the size and number of files aspect. Today GG doesn’t exist, and the only thing we have is the release rules maintained by Jazzcat. In these rules, the competition is all about speed and all the rules does to address quality is to set a minimum standard for when the release is counted. So striving for shaving off a few blocks is a dead craft, and this is today a really weak argument.

Disk search

A directory spanning multiple sectors will cause the drive to search for the file it wants to load. Even if you have a fastloader, this aspect is typically not any faster. So loading a file in a later part of the directory using a fastloader, will still be a bit slow even if the speedloader makes the load rather fast.

Why shouldn’t we use IFFL?

Incompatibility

The key aspect is that it breaks compatibility with a number of devices. We want the crack to have a working fallback to standard Kernal if possible, and this basically rules out IFFL.

Save becomes really complex

If you have the IFFL routine in the drive, and then also the scan tables, then you have filled drive ram. Any feature you add will eat the available ram, and that will restrict the number of files you can have in your tables. Save is such a feature. This is why the save functions in the IFFL context are quite restrictive. Some allow you to save an exact size file inside the actual IFFL. Some allow you to save exact size file(s) outside of the IFFL itself. There are none that support proper save or save with replace. Being clearly in favour of plain and unrestricted save, this is a real disadvantage.

Conclusion

Balancing the pros and cons, my clear conclusion is that IFFL is obsoleted. The priority should be on compatibility. Fewer blocks is nice, but people putting this forward and having 50 block intros have lost their sense of direction in the argument. You can’t argue in favour of killing compatibility in exchange for fewer blocks, and then wasting the same amount of blocks and more on something else. It doesn’t compute.

The only valid argument today is the search time for files in the latter part of the directory, but balancing this against compatibility – then compatibility wins for me.

Thanks for rating this! Now tell the world how you feel - .
How does this post make you feel?
  • Excited
  • Fascinated
  • Amused
  • Bored
  • Sad
  • Angry