pouët.net

Interesting release :) I guess it has nothing to do with the ancient FIRE Packer?

Any chance of sourcecode so one could compile it for Atari ?

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 ;)

Does it beat Atomik and Ice packer?

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.

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?

now i must install wine :)

did I get it right? This is a *.prg (Atari executable) packer on windows? ... krass!

even untested by me a big thumb up :)

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) ?

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?

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

>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?

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?)

Second thumb up for the depacker source code :)

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" ? :-))

>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 ! :-)

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?)

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 :-))

tiny depacker o_o

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!

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

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.

@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

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

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.

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!)

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?

Wait...

Leonard are you doing a new demo? :D

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! :)

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 )

rooooooolz. Can the depack routine do in-place depacking ?

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.

Really good compression ratio!

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?

Indeed, a fixed version would be highly appreciated :)

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 :).

Great, just what I needed!

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"

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

Great.

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...

I liked to download 1.2i. Any link?

Thank you Hitchhikr. Great job!

Nice nice...

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?

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.

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.

Any chance for a linux compile of the packer?

Atari XL/XE decompressor :-) https://xxl.atari.pl/packfire-decompressor/

seems this is Z80 decompressor for tiny mode:

https://www.cpcwiki.eu/forum/programming/dumb-question-15839-bitbuster-1-2/msg32069/#msg32069

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.

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.

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.

Thanks!