No IFFL on the market supports real native save (ULoad might - haven't dug into it).

groups have 1 year to fix bugs and shit

@hedning

What's with this obsession over IFFL? [...]
And IFFL plus save is also a mess. [...]
So again; why this constant moaning over IFFL?

My wishlist is;
* Option for file and IFFL [...]
<some detailed IFFL requirements>

IFFL would made sense on this release, first it would shortened it down a bit... and there are up to 10(?) dirpages it need to process when seeking a file. An IFFL would not had the seek times and the IFFLscan is done once... all depending of course how often it needs to load.

As for dir buffering, this doesn't make any sense when space is often limited, and there is no room for such things. You know that krill.

Also please don't start an IFFL bashing thing, different loaders for different purposes. Demo loaders are mostly useless for cracks and you know it.

I guess "demo loader" was ment in terms of "linear loading" from start to end instead of "randomly" loading depending fe. where the player decides to go.

By "demo loader" I meant that they are tailored specifically for demos, built for pure speed, and not for space constraints.

They also tend to want to unpack after loading and that's often just impossible with a game due to there being no buffer space for that, although newer crunchers are being able to support in place unpacking, but sacrifice some ratio, which is paramount in a quality crack.

Also demo loaders can be overly complex and you have to make multiple versions to support multiple drives, where something like n0sd0s is all in one and supports everything via detection and/or menu choice.

I look at it like people are buying inferior hardware (sd2iec) that will not work with 90% of software released for the c64, so that's on them if things don't work and we shouldn't automatically want to support something like that. I would prefer to encourage people to buy a proper drive emulator like pi1541.

Pro [of IFFL] is faster Dir search (and I agree with Krill that the scan table is basically a dir cache).

Since scanning takes some time with IFFL.

Seems like on-the-fly scanning hasn't been invented yet? =)

@krill Well the disk should be file copyable and if you do that, the track and sector cannot be assumed. It needs to be scanned to generate the table.

Quoting Bacchus

@krill Well the disk should be file copyable and if you do that, the track and sector cannot be assumed. It needs to be scanned to generate the table.

What Krill suggests is making the game files copyable, but not packing multiple files into one like IFFL. That way you only have to read and cache track 18 to get the T/S of every file, you don't have to scan the sector links like with IFFL.

I know of several IFFL loaders that support SD2IEC.

@burglar How do you do it if you don't scan?

You scan to the required file on demand, building the track/sector/offset table piece-wise, which is what Burglar did (if i got him right).

fully-random file access in some hypothetical malicious game

Quoting Krill

fully-random file access in some hypothetical malicious game

That's really just your average rpg or adventure game :)

IRQ will be lacking

With the SD2IEC seek, you must port the scan table back to the computer.

I think the part where Krill gets it a bit wrong is that you rarely have any memory to play with. Squeezing in loader, depacker and the buffers they both need is normally quite a challenge. Adding a cache (scantable of just a cached scan result) is not really feasible.

Memory available for directory caching. It becomes relevant only after you have a number of pages of files, and by that time the memory needed just isn't available.

/Bacchus

The only key drawback is that, for EVERY release, Hedning feel an unstoppable urge to ask why I don't do IFFL as I "have N0SD0S". :-P

If SD2IEC supports SEEK, the offset table can just be used directly with some math

it would never work with IRQ without some modifications and it would only support things such as music and no rasters/sprites which isn't a real IRQ loader anyways.

In general I see IFFL as too much hassle still. You'd need one more special path for IDE64 if you want to support that too.

I don't see it as any more complex than any other loader. Krill's loader is way more complex imo to implement or understand the code with the ifdef hell it has. ;)

I view this "too complex" thing as just nonsense tbh.

Also the thing with "scanning" taking some inordinate amount of time is also nonsense, the scanner takes less than 5 seconds for a 680 block file on a 1541, on CMD devices etc it's even faster. If it's slow, you're doing it wrong.

I foresee sd2iec support being added to n0sd0s in the future when GRG is free to do so. However it will have the drawbacks of being slow as balls even with jiffy/jaffy and no real IRQ-loading/saving support. Native support would indeed be great.

And a five vote for a fully working crack of one of the platforms most difficult games is meanly cheap.

SD2IEC/IDE64 IFFL support has been around for over ~2 years with support for 15x1 drives + save inside IFFL.

You will get automatic support for IDE64 since it use same code as SD2IEC.

as dead as James Brown