Omnimaga
Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: Iambian on March 28, 2011, 12:20:55 pm
-
Just to say. I'm in love with the idea of using pucrunch for just about everything that could be compressed. Bitmaps, tilemaps, text, it mattered not. I use it for just about everything. After messing around with it in CaDan and E:SoR, and after writing the Athena installer, I figured I might as well write an Axiom to do the decompression as well.
So here we have it. Something that decompresses pucrunch-compressed data. Useful for large games with tons of data files.
Contains two versions of the pucrunch decompressor, one for use in RAM and one for use as a Flash Application (Axe will automatically select the correct version).
Contains tools that you can use on the PC side of things to compress and package what you want.
-
I might be an enormous noob, but could you also provide a link to the compressor of Pucrunch (I have never heard of Pucrunch)
Cause this sounds quite interesting to me, but a link would be greatly appreciated ;)
-
I might be an enormous noob, but could you also provide a link to the compressor of Pucrunch (I have never heard of Pucrunch)
Cause this sounds quite interesting to me, but a link would be greatly appreciated ;)
It's in the archive.
DecompAx\pc\pucrunch.exe
Instructions are in the IgnoreMe.txt file.
Details regarding pucrunch can be found here: http://www.cs.tut.fi/~albert/Dev/pucrunch/
-
Nice, now I don't have to write my own routines for compression...
Just have to wait for Quigibo to reimplement big-endian nibble reads...
-
Could you put a way to compress with pucrunch in your Axiom ?
-
Q: When will you write a Pucrunch compression Axiom?
A: Short answer: I will not.
Seriously. Decompression is worlds easier than compression. I'm *SO* not
gonna write a compressor. And even if I do, it wouldn't do very well to
make an Axiom out of it. In all seriousness, it would have to be a
stand-alone utility. If you could just bone up on the theories used in
the making of pucrunch (just Google that name), you'd find out all the
information you could ever need. And once you find it out...
You ought to understand why I don't want to write it...
And DJ_O will be screaming at my as to why E:SoR isn't being updated.
It was already answered in the ReadME, but I understand the fact that many people might not even download the file and read it unless they're convinced that it's the right thing for them. Still, it was hard enough modifying the pucrunch decompresser to work as an Axiom. On the idea of compressors, there's probably a reason why the compressor is written in C (not assembly of any sort). If you could point me to a good C to Z80 cross-compiler, I might consider it only for writing a standalone compressor. If you tried to use it as an Axiom, I will guarantee you. The Axiom will end up eating more space than anything you could possibly code up.
Now... if I wanted a good exercise, I might just write a standalone compressor in Z80 ASM anyway. If DJ_O starts asking why E:SoR isn't getting anyone done, I'll start blaming everyone involved. Including the Nommer of Fishies.
-
Q: When will you write a Pucrunch compression Axiom?
A: Short answer: I will not.
Seriously. Decompression is worlds easier than compression. I'm *SO* not
gonna write a compressor. And even if I do, it wouldn't do very well to
make an Axiom out of it. In all seriousness, it would have to be a
stand-alone utility. If you could just bone up on the theories used in
the making of pucrunch (just Google that name), you'd find out all the
information you could ever need. And once you find it out...
You ought to understand why I don't want to write it...
And DJ_O will be screaming at my as to why E:SoR isn't being updated.
It was already answered in the ReadME, but I understand the fact that many people might not even download the file and read it unless they're convinced that it's the right thing for them. Still, it was hard enough modifying the pucrunch decompresser to work as an Axiom. On the idea of compressors, there's probably a reason why the compressor is written in C (not assembly of any sort). If you could point me to a good C to Z80 cross-compiler, I might consider it only for writing a standalone compressor. If you tried to use it as an Axiom, I will guarantee you. The Axiom will end up eating more space than anything you could possibly code up.
Now... if I wanted a good exercise, I might just write a standalone compressor in Z80 ASM anyway. If DJ_O starts asking why E:SoR isn't getting anyone done, I'll start blaming everyone involved. Including the Nommer of Fishies.
Perhaps this (http://sdcc.sourceforge.net/) could be a start? I think someone is using it over at Cemetech to make an OS for the 83+/84+ family...
-
Just have to wait for Quigibo to reimplement big-endian nibble reads...
This probably isn't going to be implemented as it was a mistake before. If you want a big-endian read though, all you have to do is flip the last bit of the doubled pointer:
nib{P*2}
becomes:
nib{P*2 xor 1}
and the endianness should switch.
-
I downloaded your Axiom and was looking at the ReadME for it, and I found that the program read from external files in archive. While it is still quite useful in this form, I have a feature request: could we read the compressed data inline so that we can package the whole program as a single file, under the 8811 byte limit? Thanks.
-
i feel like i will be (Ab)useing this in my correlation project...have to store that epic #omnimaga rpg text some how
that makes it a tibasic c3 axe correlation project now doesnt it....
/me goes back to hunting threw the cherry realm for inspiration
-
Wow, CalcGS support? Man, this is awesome! I may just use this in Graviter :P
-
Pucrunch is designed to be asymmetrical - the PC does the considerably-harder work of compressing the data so that the decompressor can be fairly simple. If you want to both compress and decompress on the calculator, you should probably think about using a simpler and more symmetrical algorithm.
-
Nice stuff Iambian. :O
-
I downloaded your Axiom and was looking at the ReadME for it, and I found that the program read from external files in archive. While it is still quite useful in this form, I have a feature request: could we read the compressed data inline so that we can package the whole program as a single file, under the 8811 byte limit? Thanks.
That's a pretty good suggestion. Funny thing is, that's the way the pucrunch decompressor was originally coded. I think it should be easy enough to add in. Just gotta find some time to do it.
-
If DJ_O starts asking why E:SoR isn't getting anyone done, I'll start blaming everyone involved. Including the Nommer of Fishies.
O.O
/me runs
-
On the TI-68k platform, Pucrunch has been used for many years in TIGCC and GCC4TI for compressed programs. The compression ratio is OK, and we have well-optimized decompressors made over the years by Greg Dietsche, myself, and later Samuel Stearley (who created the small/slow version and the fast/larger version).
Pucrunch has proven itself to be an excellent tradeoff between compression ratio and decompression speed. LZMA / XZ yields a better compression rate, but the C decompressor is huge and extremely slow (read: ~1 KB/s).
As FloppusMaximus wrote, it's an asymmetrical compression scheme, which won't work for on-calc compression on a TI-Z80 or a TI-68k, because compression requires way too much memory for those platforms. It could work on the Nspire, though.
-
The Nspire OS must include the zlib decompression routines; does it include compression routines as well?
-
ooh, wonderful!
thanks for your work. this shall definitely be put to use.
-
FloppusMaximus: in the lists of symbols for IDA, I see inflate*, deflate* and compress* functions.