I was testing different compression methods, maybe useful to someone.
LZSA A2(what the cx-16 uses in kernal)
LZSA A1
LZ4 (used -12 so it's "HC")
RLE - just a standard run length
SAL/ZX0 - used the salavdor compressor
From the screenshot....Times are in jiffies cause i'm not sure about another timing method on the cx16 yet
Load - lower is better, how long to load the data
Size - file size
CRC - of the packed data
Unpack - lower is better, how long did it take to unpack
Check - crc of the unpacked data, should match the "IMAGE.BIN" (60408)
*Screenshot is using sdcard, so should match close to real hardware
Included source code (Prog8), and sdcard version
LOAD"TEST.PRG",8,1
RUN
Links to the great projects this is testing:
LZSA
https://github.com/emmanuel-marty/lzsa/tree/master
LZ4
https://github.com/lz4/lz4
Salavdor
https://github.com/emmanuel-marty/salvador
Compression Unpackers (Prog8)
Compression Unpackers (Prog8)
- Attachments
-
- UNPACKTEST.ZIP
- (168.6 KiB) Downloaded 405 times
-
- cx16_unpack_test.png (39.5 KiB) Viewed 5191 times
- desertfish
- Posts: 1096
- Joined: Tue Aug 25, 2020 8:27 pm
- Location: Netherlands
Re: Compression Unpackers (Prog8)
- the LZSA decompression is that using the kernal routine or did you write a decompressor for that as well?
- wow that Salvador is super tiny compressed size and very fast decompression!
- I don't see the prog8 source code in the zip file...
- wow that Salvador is super tiny compressed size and very fast decompression!
- I don't see the prog8 source code in the zip file...
Re: Compression Unpackers (Prog8)
Yes that is the kernal routine, why I decided to do these tests, so slow!!
I just downloaded to test, it's in a folder called "PROG8_SRC" ?
yes I should say salvador is the packer, the method is called ZX0
I just downloaded to test, it's in a folder called "PROG8_SRC" ?
yes I should say salvador is the packer, the method is called ZX0
- desertfish
- Posts: 1096
- Joined: Tue Aug 25, 2020 8:27 pm
- Location: Netherlands
Re: Compression Unpackers (Prog8)
I was dumb, somehow I glossed over the src folder, dunno why that happened. thanks.
why is the ZX0 one so fast though? in this graph it is only average
https://introspec.retroscene.org/compre ... 210128.png
why is the ZX0 one so fast though? in this graph it is only average
https://introspec.retroscene.org/compre ... 210128.png
Re: Compression Unpackers (Prog8)
I'm not sure really this was a 1 sample test, just to test the compressor and unpack some data
if you do some tests make sure you use the "-classic" flag, I missed that and the unpacker was trying to unpack v2
Edit- Give me a few minutes, I'll post all my setting used so we are on the same page....
if you do some tests make sure you use the "-classic" flag, I missed that and the unpacker was trying to unpack v2
Edit- Give me a few minutes, I'll post all my setting used so we are on the same page....
Re: Compression Unpackers (Prog8)
here are the parameters for each packer I used for testing:
lzsa -f2 -r -m5 image.bin IMAGE.LZA
lz4 -12 image.bin IMAGE.LZ4
lzsa -f1 -r -m5 image.bin IMAGE.LZ1
salvador -classic -v image.bin IMAGE.SAL
lzsa -f2 -r -m5 image.bin IMAGE.LZA
lz4 -12 image.bin IMAGE.LZ4
lzsa -f1 -r -m5 image.bin IMAGE.LZ1
salvador -classic -v image.bin IMAGE.SAL
Re: Compression Unpackers (Prog8)
revisiting some compression tests...
I compressed some 64x64 @4bit sprite frames trying to decompress real time
Original: 2048 bytes per frame or 16K for all
most frames compressed to under 600 bytes
16384 to 3704 bytes for all frames
Decompress seems to take about 1/2 a frame for a single sprite
note:
I modified the decompress routine to also write to vera memory for the sprite
Since we don't have random access to video memory, a ram buffer is required for the decompressed size
as the buffer is filled, it also fills vera memory
Demo shows 3 sprites animated only using 2K instead of 16K for all frames loaded to VRAM
*You can press ESC to exit demo
Try It Now!
I compressed some 64x64 @4bit sprite frames trying to decompress real time
Original: 2048 bytes per frame or 16K for all
most frames compressed to under 600 bytes
16384 to 3704 bytes for all frames
Decompress seems to take about 1/2 a frame for a single sprite
note:
I modified the decompress routine to also write to vera memory for the sprite
Since we don't have random access to video memory, a ram buffer is required for the decompressed size
as the buffer is filled, it also fills vera memory
Demo shows 3 sprites animated only using 2K instead of 16K for all frames loaded to VRAM
*You can press ESC to exit demo
Try It Now!
- Attachments
-
- SourceCode.zip
- (117.42 KiB) Downloaded 54 times
-
- SPRITECOMPRESSION.ZIP
- (6.53 KiB) Downloaded 59 times
- desertfish
- Posts: 1096
- Joined: Tue Aug 25, 2020 8:27 pm
- Location: Netherlands
Re: Compression Unpackers (Prog8)
in the sprite code above, why is there a custom written decompression routine? Can't it use the one built into rom ?
Re: Compression Unpackers (Prog8)
Speed, LZSA1-m5 is alot faster to unpack and I wanted to test the fastest I currently have.
The ROM routine would work fine, just not the fastest option.
The ROM routine would work fine, just not the fastest option.
- desertfish
- Posts: 1096
- Joined: Tue Aug 25, 2020 8:27 pm
- Location: Netherlands
Re: Compression Unpackers (Prog8)
aha it's a different compression format, I didn't notice that.