Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user eightbitswide ! (Registered 2024-12-24) 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 04:34
Jazzcat

Registered: Feb 2002
Posts: 1044
Dishy: sounds real cool! Yeh I remember Satan real well, was trading with him (snail rulez) in the early 90s. Regarding focus on cracking scene - Vandalism News still has a first release list and coverage of all aspects of C64 cracking. Check the latest issues! Some oldschool emphasis in the new publication RECOLLECTION which will come out later this or next month.

Check the IFFL loader used in Devious Designs. Should work on most things. ;)

2006-02-16 06:53
Mason

Registered: Dec 2001
Posts: 461
Quote: Talking about IFFL cracks reminds me of all the great quality cracks that I´ve got in my archive from Satan&Ray/G*P/VSN/F4CG. Vision had in my opinion a real cool IFFL-system. Actually one of the best in the scene! It was made by Zagon/Vision, which Satan and Ray used quite a lot and were some of the best active topquality crackers left in Denmark in 1993. I´ve uploaded a few of them in here at CSDb! Those versions rocks, I think - and damn do I miss those days in the crackingscene, when I see old cracks like these, also with so great tunes in the intros!

Mega Starforce +3 cracked by Ray for GenesisProject
Mega Starforce +3
(Big fans of Crossfire/EPIC, shouldn´t read this scroll,hehe;)

Eon +5 cracked by Ray for GenesisProject
Eon +5

Fred's Back +3 Ray for GenesisProject (Not IFFL but LM-packed! Best version around, that I´ve seen!)
Fred's Back +3

IFFL versions rules!

Maybe I should call Satan or Ray and here if they still have Zagon´s IFFL system. Mayby that could help you Wanderer:)

And actually I think CSDb should have a special topic for IFFL versions, when you upload cracks! CSDb V2 should focus a little more on the crackingscene too;) Otherwise I will probably - as an old member of CHROMANCE - have to make the old crakingmag ARE WE THE BEST, so we can get some more focus on the old illegal-scene! AWTB-online or GamersGuide-online in cooperation with CSDb and C64heaven.com... Heh, why not? ;) Would love that part of the C64-internet-scene... :)

...off to sleep!:)


*****Once A Scener - Always A Scener*****


Well Well - Ray of Genesis Project wasnt the only one who did a single file version of Fred's Back. I did it for the first one under Mechanix: Fred's Back +2

Also did it with Fred's Back 2 for Epic: Fred's Back II +2
2006-02-16 09:21
MagerValp

Registered: Dec 2001
Posts: 1078
Quote: You could check the IFFL tutorial from covertbitops, that has material ..ahem.. "learned" from several sources. It doesn't integrate a depacker by default but shouldn't be hard to add.

http://covertbitops.c64.org/rants/iffl.htm

Btw. IFFL files are (IMO) not so nice for copying flexibility, compatibility (since custom drivecode has to be used or fast scanning & loading will be practically impossible) etc.


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.
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) :)
Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next
RefreshSubscribe 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
Knight Rider/TREX
Skate/Plush
Magic/Nah-Kolor
Guests online: 115
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 The Demo Coder  (9.6)
6 Edge of Disgrace  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 X-Mas Demo 2024  (9.5)
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 Swappers
1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Violator  (9.7)
4 Acidchild  (9.7)
5 Cash  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.046 sec.