exxos's Atari, Amiga & retro forum

L-packer is said to beat UPX all settings on the same data.

alexh wrote: 20 Apr 2026 14:20 L-packer is said to beat UPX all settings on the same data.

I will look into it later. Currently my compression is like 2% larger then UPX, but my depack time is like 3x faster than UPX. I consider that a good trade off.

L-packer results. As expected really.


I could only test GB6, SYSINFO 2 bombs with L-packer. L-packer depack is very fast though on GB6 which is good. My higher compression results will increase the depack time.. It's why I output multiple packed files and let the user decide compression vs depack speed. Its like 2 seconds to 6 seconds depack for the extra compression. UPX ultra brute can beat my compression easily, but its depack time is dreadful. It's just how things are.

The demo coder packers are better suited for what they do. They are small and fast and compress code well. I'm not looking to beat that. My packer will work better on various programs. Its compression is more complicated to cope, so its just going to be slower on some things. But really, its not doing to bad and I am still tweaking things yet anyway.

Added STrinkler to my script.. GB6 tests below.


UPX's LZM,BUR,UBR seem pretty redundant at this point. N2E is good, but my version or N2E beats it on time and compression. More compression and slower depack times again. I might as well just drop UPX at this point. It is just not doing well in my tests.

STrinkler beats them all, but again, slower depack time. Currently I am trying to find why it bombs on SYSINFO. But its probably just not designed for larger files. Ironically, my 2E2 compression compresses actually more then STrinkler, but STrinkler's depacker is very small, so overall it beats my 2E2 compression. It's certainly a excellent packer that's for sure. Also considering how small the depack routine is , its done very well indeed.

oops :P


There seems to be a 128 KB is an architectural ceiling for STrinkler :shrug:

Trying to see if I can patch it. Had to do some fixes already due to various odd problems. I've given up trying to understand what the AI is doing now :P

OK so its just highly optimized for small code and thats it. Its very good at small files, likely the best, though larger files need more complex handling which is what ive been doing for the past few days.

exxos wrote: 20 Apr 2026 23:23 There seems to be a 128 KB is an architectural ceiling for STrinkler :shrug:

IIUC it was written for 4KB competitions. I think 128KB of normal data would never compress down to 4KB?

Full webpage almost working :)

First compression tests :)

Output tested on real hardware ST536 030 CPU :) All my other tests were done on STeem (68000) .


Bit quicker than loading from floppy uncompressed as well :thumbup:

I used LONGs where I could. Useless on a 68000 really, but gives speed bump when there 32bit 030 CPU is used !

Could do with some testers to try the new packer page. It's just a matter of uploading some PRG's and wait for compress, download and test basically.