- 11111.PNG (75.76 KiB) Viewed 1003 times
nrvpack — Executable Compressor (Beta)
Background
nrvpack is an executable compressor designed for 68000 with 68030 compatibility — so it covers the full ST/STE/Mega/TT/Falcon range. The decompressor is small, position-independent, so a packed PRG runs anywhere a stock ST does.
Both the packer and the decompression stub were written from the ground up. No code was taken from UPX or any other existing packer. The format is inspired by the NRV family of algorithms (the same general lineage UPX draws from), but the parser, probe-set logic, arithmetic coder, and 68k decompression routine are all original work.
The goal was simple: squeeze the most out of typical 68k executables without paying a runtime decompression cost that would matter on stock hardware.
A great deal of testing has gone into this — several different compression algorithms have been benchmarked against real PRG files, with different coder configurations compared head-to-head and a long list of ideas tried and discarded along the way. The packer offers a choice of algorithms so the user can pick the trade-off that suits them: higher compression ratios come at the cost of slower decompression, while the lighter algorithms decode faster but pack less tightly. Which one to use is up to you — for a program that loads once and runs for hours, maximum compression makes sense; for something launched repeatedly, a faster-decoding format may feel better in use.
On typical executables the stronger formats land at roughly 2.75:1.
Availability
The packer is available to logged-in forum users only. You'll need to be signed in to use it.
Beta Status
This is a beta release and needs more thorough testing by the community before it can be considered stable. If you run packed PRGs and hit anything unexpected — crashes, corrupted output, programs that misbehave only when packed, weird interactions with TSRs or accelerators, anything at all — please post in this thread with as much detail as you can (file, machine config, TOS version, what happened). The more variety of hardware and software it gets exercised against, the sooner any remaining bugs can be flushed out.
Thanks in advance to anyone who takes the time to give it a run.
https://www.exxosforum.co.uk/nrvpack/
Edit / clarification:
To be clear about the workflow: AI wrote much of the code under my direction. I've mentioned this elsewhere on the forum and in the atariscne.org article (which has been updated to state it explicitly), but it's worth saying here too so the context isn't missed.
The design of the format, choice of algorithms, parser strategy, probe-set tuning, 68k decompression stub conventions, experimentation, debugging, and the web frontend were all my work. The conversation log alone runs to over 200 pages. AI handled a lot of the typing; the engineering and design decisions were mine.
Honestly, I didn't expect this to be much of an issue in 2026 — AI is part of how most developers work now, in one form or another.
But the pushback reminds me of the old arguments about games being "cheating" if they were written in BASIC instead of assembly, or rows over whether using prebuilt libraries counted as your own work. Same shape every time: a new tool turns up, a faction decides it's illegitimate, and a few years later it's just how things are done. I'd rather not see the scene fall into another round of that. Use the best tools available, be open about it, and judge the work on what it does.
I just wanted to put together something cool and different for the community, the way I've been doing for the past 30+ years.