[CSDb] - User Forums

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > IFFL

2006-02-15 21:42

Wanderer
Account closed

Registered: Apr 2003
Posts: 478

IFFL

Before I begin, let me say that I *have* tried without asking for help. I've downloaded a variety of IFFL programs and all have failed. I have read up on IFFL and understand it, I just can't do it :)

*ahem* Okay, now then...

I am in the midst of writing a game with multiple levels. It features an intro, levels, end page and high score page. Each page loads the next page through KERNAL load routines, so it consists of standalone files for now.

What I would like to do is to one-file them into an IFFL version. I don't mind if it features a loader file, I'd just like to pack the various files into one.

First, each file is not just level data... that is to say, they begin at $0801 and execute, so it isn't just loading data into upper memory. Each file needs to be executed as a standalone program. Due to wanting to use all available RAM, linking them together is not feasable because this reduces the amount of free memory available to me.

Now then.. I have tried to download Burglar's IFFL program as well as many others. The process seems quite simple enough. Link them through a "linker" which makes it one file. However in the case of Burglar's program, there is no depacker in the linker. The standalone depacker doesn't advise you what filename to use, but it DOES begin with a STA $xxxx which means you just load the Accumulator with the file # and run his depacker.

I have tried at least 6 other IFFL linkers and while some of them do create a single file, the depacking portion (normally written to disk after it links) results in just filling the RAM with garbage every time.

Keep in mind IFFL is new to me, it had only just begun to come out when I left the scene so I don't know how to use it. I understand the linking concept (make a single IFFL file), I understand the depack concept (you load the accumulator with the file, JSR, it unpacks from the IFFL file according to the track and sector). I have seen IFFL packers as well which I *think* crunches the IFFL one file even more.

To say the least I am confused and I'm asking for help. I'm not keen on asking for help but I need it...

So essentially what I require is:

- a way to link approximately 6 files that begin at $0801 into one file and that can be called one by one as I need them. I understand each file will need a copy of the unpacker code and the proper LDA #$xx before calling the routine.

- it must work on NTSC

- not only a way to link the files into one, but a proper depacker as well. The best program I could find would pack them but then gave you a Turbo Assembler code for a depacker which gave errors when trying to compile it.

- I know this can be done because my game Jailbreak consisted of 4 files that were done with ECA Linker, and made into a single file. As it needed to, it would unpack the next file necessary.

Any help, suggestions of a POSITIVE nature would be appreciated. I have tried everything under the sun and I really would prefer it to be a single file.

... 43 posts hidden. Click here to view all posts....

2006-02-16 16:57

cadaver

Registered: Feb 2002
Posts: 1160

Quote: Yes, the problem is related to mixing the 1-bit fully handshaked protocol with the timed 2-bit transfer. There are a couple of people out there who have been trying to use your 2-bit loaders though, and AFAIK they have all had stability problems.

In my 2-bit loader I ended up just your 2-bit 1541->C64 xfer routine, with added handshaking. For C64->1541 I used the same handshaking procedure and the 2-bit xfer routine from Krill's 2-bit irqsaver. As far as I can tell it's stable (and reasonably fast :), but I'm going to see if I can test on a few different drives at the St Lars meeting this weekend.

As for 2-bit+ATN, that's a bit of a pain unless someone comes up with a stable way of disabling the other devices on the bus.

Rants & code were updated. Now C64 always begins transfer in either way, and drive responds. Stresstested with the loop you described & it seemed to work..

+ added buffering to the IFFL loader for better performance, especially if a depacker is added.

2006-02-16 23:08

Mason

Registered: Dec 2001
Posts: 461

Quote: Thanks for the reply. I read your post and I understand all of that, the linking process and how to call the loader. Your linker works well but the depacker doesn't mention what the filename should be. I've looked at the code for where it sets the filename and can't seem to find it.

I realize I'm new to the whole IFFL thing, but have enough of a grasp of it that I should be able to get it to work :)

I'm using the one from Onslaught's site
http://www.atlantis-prophecy.org/onslaught/php/c64misc.php

As I said, yours seems to be the closest to success as it has an easy to understand loader and linker but without the filename, aarrghh... and the scanner, I don't know where to even find that unless the linker makes it for you.

Well in many situations the scanner already set the filename, but to be sure its always wise to set the vector and then a $ffbd. In some cases the games cleared the zeropage where its stored the length of file, lo-byte and hi-byte - I reckon it $b7, $bb and $bc.

2006-02-17 03:25

Wanderer
Account closed

Registered: Apr 2003
Posts: 478

Burglar's program doesn't tell you what the filename is though, so the 1541 flashes a file not found error. This is more encouraging though than the other IFFL loaders that DO load the files only to fill the entire RAM with the same byte, thus crashing.

Also, isn't level packing simply packing data that can be loaded and extracted using a depack routine, such as character data for games? Aren't level packers totally different than IFFL and therefore you wouldn't need to level pack anything if the intention was to IFFL?

To expand on that... say a game had 10 levels that had data from $4000-6000 you would not use Cruel Crunch on it, but you would use a Level Cruncher, right? So to make an IFFL would you just use an IFFL linker and not even touch a Level Packer, yes? I'm confused by an earlier comment about having to level crunch when wanting to IFFL too.

I hate being clueless when it comes to aspects of the 64 but asking questions is a necessary evil :)

2006-02-17 05:33

cadaver

Registered: Feb 2002
Posts: 1160

The IFFL loader may be expecting your files to be packed with a certain (level)packer, so that they can be depacked correctly when loading.

Now how to know what that is, is another question..

2006-02-17 06:42

Wanderer
Account closed

Registered: Apr 2003
Posts: 478

I'm going to give it one last shot with Burglar's IFFL packer/loader and linker.

Ironically I did write a similar program on the PC. It was a one-file demo that consisted of files linked together and the loader would depack the files it needed, run them, then delete them from the drive afterwards, while leaving the one-file untouched. It worked by using a routine similar to the track/sector scanning method. It was quite crude but worked similar to IFFL, and was done in C++.

Re-edit: I level crunched two music files, ran the IFFL linker (seems to me you shouldn't need to level pack what you intend to IFFL link). Loaded the scanner, executed it and then executed the loader with a LDA #$00. The scanner gave me a BASIC error message, and then proceeded to fill the screen up with carriage returns. Tried IFFL linking two files that were in raw format (not crunched). Again the scanner barfed.

Fuck the fucking concept! I'm sticking with Kernal loads.

2006-02-17 09:25

MagerValp

Registered: Dec 2001
Posts: 1078

Quote: Rants & code were updated. Now C64 always begins transfer in either way, and drive responds. Stresstested with the loop you described & it seemed to work..

+ added buffering to the IFFL loader for better performance, especially if a depacker is added.

Nice!

2006-02-17 10:33

soci

Registered: Sep 2003
Posts: 480

Nostalgia has a really nice IFFL system coded by GRG, which supports 1541, 1570, 1571, 1581, CMD FD-2000, CMD FD-4000, CMD-HD and IDE64 (IDEDOS v0.90+). But I think it's for their high quality cracks only. It can even save highscores and gamestates right into the file.

I've done an IDE64 compatible loader for Cadaver's IFFL system in last August, but now I cannot find this on the site. (maybe it's updated meanwhile, but I could not directly check the *.c64.org one because this domain is filtered here...)

2006-02-17 10:44

Burglar

Registered: Dec 2004
Posts: 1101

Quote: I'm going to give it one last shot with Burglar's IFFL packer/loader and linker.

Ironically I did write a similar program on the PC. It was a one-file demo that consisted of files linked together and the loader would depack the files it needed, run them, then delete them from the drive afterwards, while leaving the one-file untouched. It worked by using a routine similar to the track/sector scanning method. It was quite crude but worked similar to IFFL, and was done in C++.

Re-edit: I level crunched two music files, ran the IFFL linker (seems to me you shouldn't need to level pack what you intend to IFFL link). Loaded the scanner, executed it and then executed the loader with a LDA #$00. The scanner gave me a BASIC error message, and then proceeded to fill the screen up with carriage returns. Tried IFFL linking two files that were in raw format (not crunched). Again the scanner barfed.

Fuck the fucking concept! I'm sticking with Kernal loads.

heh, well, I dunno which version you have, but I only used the loader present in my iffl package a few times, decades ago. the newer loaders were just done in tasm, and never made it to the public.

2006-02-17 11:07

cadaver

Registered: Feb 2002
Posts: 1160

Quote: Nostalgia has a really nice IFFL system coded by GRG, which supports 1541, 1570, 1571, 1581, CMD FD-2000, CMD FD-4000, CMD-HD and IDE64 (IDEDOS v0.90+). But I think it's for their high quality cracks only. It can even save highscores and gamestates right into the file.

I've done an IDE64 compatible loader for Cadaver's IFFL system in last August, but now I cannot find this on the site. (maybe it's updated meanwhile, but I could not directly check the *.c64.org one because this domain is filtered here...)

Hmm sorry, it most likely has been lost or was never added to the site.

2006-02-17 11:38

soci

Registered: Sep 2003
Posts: 480

No problem, also happens with me sometimes ;) I've resent it to you.

Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next

Refresh

Subscribe to this thread: