pouët.net

PackFire v1.6 by Rebels & Neural [web]
[nfo]
screenshot added by hitchhikr on 2010-04-14 02:02:56
platform :
type :
release date : april 2010
  • 20
  • 6
  • 0
popularity : 67%
 67%
  • 0.77
alltime top: #4267
added on the 2010-04-14 02:02:56 by hitchhikr hitchhikr

popularity helper

increase the popularity of this prod by spreading this URL:

or via: facebook twitter pinterest tumblr bluesky threads

comments

Interesting release :) I guess it has nothing to do with the ancient FIRE Packer?
added on the 2010-04-14 08:43:17 by ltk_tscc ltk_tscc
Any chance of sourcecode so one could compile it for Atari ?
added on the 2010-04-14 09:08:26 by evil evil
Totally nuked UPX in a random set of programs (even by 500k in one test), so I can only give a big thumbs up! Also, magnitutes faster than UPX. Only tested 1 4k intro and it chopped ~150 bytes more than UPX, which is most impressive :)

Evl: given that the packer allocates about 1Gb of buffers while packing, I doubt it'd be any useful!

Lotek: That was Pack-Fire, not PackFire ;)
rulez added on the 2010-04-14 10:32:43 by すすれ すすれ
Does it beat Atomik and Ice packer?
added on the 2010-04-14 10:36:39 by ltk_tscc ltk_tscc
ggn, UPX is not good for 4k's, that's well known. Does it work with 060 caches (UPX does)?

And sources would be welcome anyway, to compile for something else than Windows.
added on the 2010-04-14 11:13:49 by evil evil
Lotek, upx already beats atomik and ice packer (at least in the cases I tried). Evil surely has more experience in 4ks than me, so I guess more testing is required there. I'd be certainly be giving it a spin in my stuff.

060 caches - is that the xbios call that upx does?
added on the 2010-04-14 11:39:49 by すすれ すすれ
now i must install wine :)
rulez added on the 2010-04-14 13:05:49 by tobé tobé
did I get it right? This is a *.prg (Atari executable) packer on windows? ... krass!

even untested by me a big thumb up :)
rulez added on the 2010-04-14 22:07:22 by slippy slippy
impressive packing ratio. Could I get in touch with you to get the ATARI source code depacker? So I can improve my demo system using your depacking routine?
I see there is 32bits MUL instructions, are you using kind of arithmetic packer? (instead of classic LZ+Huffman stuf) ?
rulez added on the 2010-04-14 23:26:58 by leonard leonard
v1.1 released with better compression ratio for small files (like 4k intros).
leonard: it's a stripped down version of lzma.
added on the 2010-04-15 01:02:50 by hitchhikr hitchhikr
striped down LZMA with only one MUL? wow pretty cool. Waht about the depacking speed on ATARI ST? (with LZH or ARJ I depack almost the same speed as the floppy is loading, that is, 15Kb/sec). What speed do you think LZMA is on 8mhz machine?
added on the 2010-04-15 01:26:39 by leonard leonard
Too slow for realtime depacking.
added on the 2010-04-15 15:35:31 by hitchhikr hitchhikr

Rulez for sure !
What about datapack-option ?
Depack 68000 source available ?
That would be even more great !

rulez added on the 2010-04-15 17:53:18 by lsl lsl
>Too slow for realtime depacking.

But how? 1Kb/s ? 0.5Kb/s ? 0.001 Kb/s ? Do you have an idea of the time to depack, say, 50Kb of packed stream?
added on the 2010-04-15 18:42:58 by leonard leonard
V1.2 released with binary output switch & the possibility to specify an absolute address to depack at. I also included the depackers so you can measure the speed youself.
added on the 2010-04-15 22:58:45 by hitchhikr hitchhikr
Thanks for that version with depacker source code, really great stuff!
Btw, could you told me the difference between the "Tiny" and "Large" depacker? "Tiny" seems to be a classic LZ-like algorythm. How can I specify the packing method with PackFire.exe (tiny or large deapck?)
added on the 2010-04-16 09:58:53 by leonard leonard
BB Image Second thumb up for the depacker source code :)
added on the 2010-04-16 11:03:27 by tobé tobé
Alright, i added a new switch (-l) so the packer will always output large model data, otherwise it's automatic and the packer selects the smallest of the two outputs.
added on the 2010-04-16 11:59:12 by hitchhikr hitchhikr
the -l option is great, but in some case you need to force the "tiny" mode. In my case I will try the tiny routine inside a bootsector, so I have to patch tiny depacker a bit, and use tiny binary. Should be terrific if I can force "tiny" way :-) ( "-t" ? :-))
added on the 2010-04-16 12:31:35 by leonard leonard
No need because for such small file the packer will select tiny output (by comparing the size of the data & the depackers).
v1.2c released, i've stripped down 16 bytes from the tiny depacker.
added on the 2010-04-16 21:44:53 by hitchhikr hitchhikr
>No need because for such small file the packer will select tiny output

You're right in the general case, but believe me, I *need* that option :-) in my special case a tiny depacker is located in the bootsector. Currently I use ARJ mode 4 (not mode 7) for boot sector depacking routine, it takes only 112 bytes. You tiny depacker takes 152 bytes, and I WANT to test the packing ratio of your tiny mode. Please add a '-t' option so I can compare your small version with the ARJ4. 't' option for next release will be fantastic ! :-)
added on the 2010-04-16 23:50:21 by leonard leonard
Ok here it is but you could compare both raw data output by using the -b switch.
added on the 2010-04-17 00:22:55 by hitchhikr hitchhikr
thanks! it's almost perfect :-) Why -t is "if possible" ? I want to try to pack my complete demo directory structure (LZMA seems a bit slow) with tiny mode, and some files append to be 0 bytes! could you change that if you specify -t, it output a tiny model file, even if -l would have produce smaller result?

(btw: my program crash with some files when trying to use large model. In the depacker you specifiy A2 should point on probs, is it only a 15980bytes buffer large? or is there something else to worry about?)
added on the 2010-04-17 00:48:31 by leonard leonard
Nope, because there's nothing to output as there's no compression if the file is too big anyway.

If the same routine is re-used the variables range & repx should be re-initialized again at -1 and 1:

Code: moveq #-1,d7 move.l d7,Range-var(a5) neg.l d7 move.l d7,rep3-var(a5) move.l d7,rep2-var(a5) move.l d7,rep1-var(a5)
added on the 2010-04-17 01:04:19 by hitchhikr hitchhikr
you got it! thanks, it works now like a charm. LZMA is really amazing. My latest ATARI sound demo disk is now about 700Kb instead of 820kb!!! The drawback is that depacking is really, really slow (but you have to pay to get such packing ratio :-))
added on the 2010-04-17 01:14:04 by leonard leonard
tiny depacker o_o
rulez added on the 2010-05-01 00:45:41 by T$ T$
Hi, me again :-) The package include the 68000 source code of LZMA depacking routine. The routine is really small compared to the original C version of the official LZMA SDK. So my question:
Is that depacker the same version as the latest LZMA sdk? And if yes, could you point me to the "small" C version? Did you get it somewhere, or did you extract it from original source code?
thanks!
added on the 2010-06-22 16:01:32 by leonard leonard
Tiny mode looks a lot like apLib, but usually gives better compression ratios.

I've ported the tiny depacker to the Hitachi SH2 (Sega 32X/Saturn). Assembly code + C prototype can be found here: http://jiggawatt.org/badc0de/unpackfire_tiny_sh2.zip
rulez added on the 2010-06-22 19:39:10 by mic mic
tiny mode is a classic LZ stuff. I mean the "large" depacker (the one with two MUL instructions). Did the 68000 version come from a small C version?
I'm interested by the small C version.
added on the 2010-06-22 22:07:15 by leonard leonard
@leonard: my comment wasn't directed at you, so sorry if it caused you any confusion :T

Anyway, I found some stuff in my SH2 code that could be optimized, so now it's 236 bytes instead of 264 (same URL as before).
That's still considerably larger than the 68k version, but I blame that on the SH2's limited ISA :P
added on the 2010-06-23 11:57:29 by mic mic
I decided to port the tiny mode depacker to the 65816 (SNES) as well: http://jiggawatt.org/badc0de/decrunch/

Keep in mind that this is crazy slow on a SNES :P
added on the 2010-06-26 21:26:18 by mic mic
I've ported the tiny depacker to the HuC6280 (PC-Engine): http://jiggawatt.org/badc0de/decrunch/

With some minor changes the same code could be used on a standard 65C02 and (with a few more changes) on the 6502/6510.
added on the 2010-10-16 15:49:27 by mic mic
Impressive!
I was intersted in a z80 port (Amstrad CPC), but the results of Tiny version is the same that Exomizer v2.0 by Magnus Lind (and the z80 routine already exist). So, do you planed to improve your Tiny method? (which is of course already very accurate!)
rulez added on the 2011-01-05 13:45:06 by Hicks Hicks
Hi! Me again!
Could you please add a "force tiny mode" option in the packer? In my case, for my ATARI-ST demo system, I use ARJ-7 or PAckFire to packe screens. PackFire "LZMA" is useless on ATARI because it's too slow. So when my toolchain pack binaries, I run ARJ and PackFire, and I select the best result for each binary. Unfortunatly, as the "LZMA" model is generally smaller, I never get a valid "tiny" packed file.
Please add an option "force tiny packing, even if LZMA mode is smaller"
Do you think it's possible?
added on the 2011-06-19 15:45:11 by leonard leonard
Wait...

Leonard are you doing a new demo? :D
added on the 2011-06-19 16:02:06 by rez rez
So if I understand this right, it's faster and more has a higher packing rate than the usual ones? For Atari executables? Cook, thanks! :)
rulez added on the 2011-06-19 16:12:25 by fiveofive fiveofive
leonard: did you try the "-t" switch ?
added on the 2011-06-19 16:17:27 by hitchhikr hitchhikr
hitchhikr: yes I try "-t" switch. It almost work but with some files (even smaller than 64Kb) I get that error message: "Packing binary file... no tiny mode available for that file". Do you know how I can fix this?"

fiveofive: the LZMA version is really better than any other packer (about 20%) but it's too slow to be used on a demo. The Tiny mode is very similar to standard atari packers such as speekpacker or Ice. A bit better than ARJ sometimes for small files.

rez: no :-) I just update my ATARI demo toolchain. (available here: http://pouet.net/prod.php?which=56952 )
added on the 2011-06-21 10:52:12 by leonard leonard
rooooooolz. Can the depack routine do in-place depacking ?
rulez added on the 2011-06-24 14:59:20 by zerkman zerkman
just used it for our latest 4k-tro..
great packer!

but why can't I pack large files in tiny mode ?
would be great to do so.

added on the 2011-11-10 15:24:31 by lsl lsl
Really good compression ratio!
rulez added on the 2012-04-09 14:08:43 by RA RA
hitchhikr, I just tried the small packer model (latest version of pack fire of course) on a 4k, and the produced program gives a "illegal program" error when run from GEM. Upon investigation it seems like the code starts from within the TOS header (to be precise, at offset 0x1c, where normally there should be a pointer to the TEXT segment). I've seen this problem with other people's 4ks, so is there a chance you could fix this?
added on the 2013-06-16 13:02:57 by すすれ すすれ
Indeed, a fixed version would be highly appreciated :)
added on the 2013-11-05 13:27:11 by britelite britelite
Okay, disregard what I wrote above, I think I have a fix for this:

Firstly, most of the times the "TOS error #35" bug happens when you run the .PRG from floppy.

Anyway, the problem (I think!) is that the pointer to the relocation table is wrong. From here (GEMDOS Processes) I saw that the relocation (AKA 'fixup') offset is calculated like this: PRG_tsize + PRG_dsize + PRG_ssize + 0x1C. PRG_dsize and PRG_ssize are zero for PackFire programs, so this is simplified to PRG_tsize + 0x1C. This should point at the last longword of the binary (which is 0.L). Sometimes this offset does not point there, but 2 or 4 bytes after. For a lot of cases this isn't a big problem since the memory is zeroed, but for some cases (for example running from floppy - no idea why this happens!) the memory is dirty so GEMDOS tries to do relocation (and fails).

tl;dr open your problematic .prg in a hex editor and check the longword at offset 2. If this value + 28 doesn't point to the last longword of the file, adjust so it does :).
added on the 2013-11-06 17:20:35 by すすれ すすれ
Bug should be fixed. Thanks to ggn for having investigated this bug.
added on the 2013-11-07 16:18:37 by hitchhikr hitchhikr
Great, just what I needed!
rulez added on the 2014-12-30 19:41:39 by Sdw Sdw
I tried it on Elefantastic and while it dropped the size to something like 50% of my original, the depack time is very long (90+ seconds).
Not a problem in itself, but I think many could be fooled into thinking that the demo has locked up, a simple depacking effect like flashing the background color or something would be nice to have as an option, just to inform the viewer that "yes, I'm still working on something... hang on"
added on the 2014-12-30 21:57:11 by Sdw Sdw
Fantastic packer ! I made a C version of the "tiny" depacking routine, converted straight from the 68k asm version. http://onorisoft.free.fr/win/depackfire_tiny.c
rulez added on the 2015-03-01 12:41:04 by Orion_ Orion_
Great.
rulez added on the 2017-02-15 20:46:47 by Buckethead Buckethead
Hi!
I just download latest 1.2j and when I pack the kernel of my demo using 1.2j, I can't use tiny mode anymore! It says: "Packing binary file... no tiny mode available for that file."
If I pack the same file using 1.2i, it works in tinymode!

I need the tiny mode for the kernel ( I use the tiny depacker in the demo bootsector)

Do you have a workaround? I always dreamed of a "-ft" (force tiny mode) option...
added on the 2017-03-29 20:41:25 by leonard leonard
My bad. Should be fixed now, download again (or revert to 1.2i).
added on the 2017-03-29 21:30:26 by hitchhikr hitchhikr
I liked to download 1.2i. Any link?
Quote:

a simple depacking effect like flashing the background color or something would be nice to have as an option, just to inform the viewer that "yes, I'm still working on something... hang on"


1.2k released:

- Background decrunch color for files packed with large model.
- Interruptions disabled during decrunching of large model files (therefore the depacking should be faster).

Buckethead: Don't have it anymore, sorry.
added on the 2017-03-29 22:45:57 by hitchhikr hitchhikr
I forgot:

- Tiny model can now pack up to 40kb files.
- Passes and offsets of tiny model are now adapted to the size of the file (the smaller the file, the more the passes).

BucketHead: spoke too fast: http://franck.charlet.pagesperso-orange.fr/temp/PackFire_v1.2i.zip
added on the 2017-03-29 22:59:58 by hitchhikr hitchhikr
- Mouse was frozen when returning to the GEM.
added on the 2017-03-29 23:43:06 by hitchhikr hitchhikr
Thank you Hitchhikr. Great job!
Nice nice...
rulez added on the 2017-03-30 00:41:25 by Frequent Frequent
I will test the new version tonight. By curiosity, why the tiny model is limited to 40kb? for instance I can't use large on a multi-part demo because depacking is way too slow (that's normal). why can't I use tiny model even for a 300Kb screen? is there a technical issue?
added on the 2017-03-30 17:38:43 by leonard leonard
Hi, I'd like to leave here a couple of feature requests:

a) when packing a program that contains a symbol table, please display the size of the program minus the symbol table (which is junked by the packer anyway)
b) don't output a .prg when the packed binary is larger than the original. At least when packing a program with symbol table, the whole prg size is assumed, so the program can get bigger than the original and the packer will happily announce that the binary was packed.
added on the 2018-07-18 14:00:44 by すすれ すすれ
Very impressive compression ratio, at least on the small files relevant to me (always <64K in size, motivated by the needs for 8-bit coding). In -l mode it seems to consistently beat Shrinkler in this case.
rulez added on the 2018-10-23 00:13:37 by introspec introspec
Any chance for a linux compile of the packer?
added on the 2019-06-19 00:59:37 by patrikax patrikax
Atari XL/XE decompressor :-) https://xxl.atari.pl/packfire-decompressor/
rulez added on the 2021-04-05 01:22:46 by xxl xxl
That's interesting, I was trying to pack a prg, but then it seems to not work when running the packed prg. Stays long in the white screen. But that was PRG made from VBCC C code, that runs normally unpacked, but why packer breaks it? I have to try with a tiny assembly example compiled to PRG and see if it works there. I could be doing something dirty after the unpacked with the system I don't know.
added on the 2023-02-24 10:53:33 by Optimus Optimus
Probably doing something wrong on the VBCC code, that crashes it after (but not if unpacked). I tried another prg from pure assembly code, it does work and packs a lot.
added on the 2023-02-24 10:56:59 by Optimus Optimus
Not sure what happens with VBCC C code produced PRG then packed, even a simple int void() return 0 would give bombs back if packed. Maybe something with the different execution address in the PRG header (also relative/absolute, I don't know)

But anyway, this is going to be mostly useful for the pure assembly intros 512-1k, an over 1k test went down to 600 bytes here.
rulez added on the 2023-02-24 11:28:08 by Optimus Optimus
V1.3 released and githubified.
added on the 2024-05-26 19:18:21 by hitchhikr hitchhikr
hmmm, v1.4 released, it can now pack X68000 executables.
added on the 2024-05-27 00:52:50 by hitchhikr hitchhikr
v1.5: can now pack Nintendo DS ROMS files (without DLDI).
added on the 2024-05-29 02:37:46 by hitchhikr hitchhikr
v1.6:

- Shortened packed NDS files.
- Faster 68000 depacker.
- Shouldn't produce bogus Atari ST files anymore.
added on the 2024-07-10 15:30:03 by hitchhikr hitchhikr
Thanks!
rulez added on the 2024-07-10 15:43:49 by sachy sachy

submit changes

if this prod is a fake, some info is false or the download link is broken,

do not post about it in the comments, it will get lost.

instead, click here !

[previous edits]

add a comment