[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 09:25

Krill

Registered: Apr 2002
Posts: 2980

Quote: I knew I wasn't on crack. :)

http://www.ontarioghosttowns.com/ccs8.jpg
(Dream Loader upon calling $8000)

My first time seeing IFFL was on Creatures 2 in 1992, right before I left the scene. It seems that different groups have designed their own versions since then which is very impressive.

Doesn't look like a loading/depack effect but just like the loader code relocated to screen memory. Not their fault :D

2006-02-16 09:39

Burglar

Registered: Dec 2004
Posts: 1101

wanderer, first of all, you need to understand how it really works.

the linker is just what it is a linker, it links files on disk to one file and afterwards offers a fast (1541 only!) scanner to save on disk.

so basically you need to do this:

- levelpack all files
- put all levelpacked files in order on a disk
- link them together and save the scanner

now, you save the loader/depacker to a location that won't be overwritten by any of the files.

finally you create a boot file which includes the scanner and the loader (and possibly a trainermenu + intro + game)

after scanning the file you can do the following to load+depack a file:

lda #$00
jsr $loader
for the 1st file

lda #$02
jsr loader
for the 3rd file

etc

my iffl is 100% ntsc/pal, but only works on 1541 drives (and emus with true drive emulation).

Burglar

PS: Not sure which version you have of my iffl routines, but presumably an old one, so I'm not sure what type of loader/depacker it has.

2006-02-16 09:43

cadaver

Registered: Feb 2002
Posts: 1160

Quote: Lasse, I don't think your 2-bit loader is stable. The handshaking is a little too barebones so sometimes it gets confused and transfers a garbage byte or locks up. If you do

ldx #0
loop:
txa
sta $0400,x
jsr loader_send
jsr loader_recv
sta $0500,x
eor $0400,x
sta $0600,x
inx
jmp loop

and put an echo server on the drive side (jsr drv_recv : jsr drv_send : jmp loop) you'll get errors quite quickly.

As for IFFL systems, in Ultima IV I put the scanning logic on the C64 side, mainly because there are over 800 files so you can't fit the t/s/o tables in drive ram. On the 1541/70/71/81 I use a fast read_track_links routine, and for the CMD FD and HD I use a readsector fallback that only xfers the first two bytes of every sector.

Hmm, can you specify the program that results in this (for example some of the loader examples I could modify to load over & over again)? The example seems a bit weird because I've only coded a time critical 1541->C64 transfer, other way round always uses MM's asynchronous & lazy protocol, and they most likely weren't tested mixed like that..

Though having a bug wouldn't be a surprise as I've always preferred 1-bit for leaving sprites on.

2006-02-16 10:22

MRT
Account closed

Registered: Sep 2005
Posts: 149

Please don't mind me for asking, but...

What's the use of IFFL? As far as I could read it has a lot of implementation problems and I couldn't find any reason why IFFL is better that just regular file loading.

What am I missing?

2006-02-16 10:31

MagerValp

Registered: Dec 2001
Posts: 1078

You save an average of 127 bytes per file (as filesizes aren't rounded up to the nearest block), you're not limited to 144 files, and there's no directory search time. Ultima IV is a perfect example of when IFFL is good to use: 850 files, many of them smaller than one block. Trackloader or IFFL are the only options, and trackloaders don't work on 1571/81 disks.

IFFL systems are really just trackloaders than initialize the track/sector/offset table at startup by scanning the disk.

2006-02-16 11:27

Krill

Registered: Apr 2002
Posts: 2980

Cadaver: best is 2bit+ATN. Allows arbitrary interrupts, such as sprites, badline, irq, nmi, etc. while being rather fast. Some days ago i have found out how to make it work with multiple drives on the bus, so i will update my loader soon.

2006-02-16 11:41

cadaver

Registered: Feb 2002
Posts: 1160

That's surely interesting (have tested 2bit+ATN, but abandoned it in fear of NTSC powerusers) :)

2006-02-16 13:49

MagerValp

Registered: Dec 2001
Posts: 1078

Quote: Hmm, can you specify the program that results in this (for example some of the loader examples I could modify to load over & over again)? The example seems a bit weird because I've only coded a time critical 1541->C64 transfer, other way round always uses MM's asynchronous & lazy protocol, and they most likely weren't tested mixed like that..

Though having a bug wouldn't be a surprise as I've always preferred 1-bit for leaving sprites on.

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.

2006-02-16 16:29

Wanderer
Account closed

Registered: Apr 2003
Posts: 478

Quote: wanderer, first of all, you need to understand how it really works.

the linker is just what it is a linker, it links files on disk to one file and afterwards offers a fast (1541 only!) scanner to save on disk.

so basically you need to do this:

- levelpack all files
- put all levelpacked files in order on a disk
- link them together and save the scanner

now, you save the loader/depacker to a location that won't be overwritten by any of the files.

finally you create a boot file which includes the scanner and the loader (and possibly a trainermenu + intro + game)

after scanning the file you can do the following to load+depack a file:

lda #$00
jsr $loader
for the 1st file

lda #$02
jsr loader
for the 3rd file

etc

my iffl is 100% ntsc/pal, but only works on 1541 drives (and emus with true drive emulation).

Burglar

PS: Not sure which version you have of my iffl routines, but presumably an old one, so I'm not sure what type of loader/depacker it has.

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.

2006-02-16 16:31

Wanderer
Account closed

Registered: Apr 2003
Posts: 478

Quote: Please don't mind me for asking, but...

What's the use of IFFL? As far as I could read it has a lot of implementation problems and I couldn't find any reason why IFFL is better that just regular file loading.

What am I missing?

In my case I simply would like to make it a single file, but it does seem to create some compatibility issues.

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

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

TheRyk/MYD!
Mibri/ATL^MSL^PRX
Mike
Alakran_64
MWR/Visdom
DanPhillips
Rub_0201
LKP/CFN
megasoftargentina
Kakka/Extend, Damone..
Francois Prijt/Audia..
wil
Laddh
tlr
psenough
Guests online: 111

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)

Top onefile Demos

1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)

Top Groups

1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)

Top Fullscreen Graphicians

1 Joe  (9.7)
2 Sulevi  (9.6)
3 The Sarge  (9.6)
4 Veto  (9.6)
5 Facet  (9.6)

Page generated in: 0.054 sec.