Enjoying your froyo?

[Stef]

Yes but not by much ,6 cycles/byte for the 6280 vs 7 for 65816, but the CPU's frequency makes the difference .

Yeah of course the CPU speed make the difference, still i would have expected to see the cycles the other way and the 65816 having the better block move instruction

Yes but this is not a technical one, i myself limited to 2 banks for each side (source/dest), i think 16 kb to work with is enough for a "real time" decompressor (i cannot do more) .
But ican be a limititation in some case (large compressed files) .

Honestly i don't plan to use very large data block as well, i will use it mainly for sprite tile data. When i was speaking about limitation, i was mainly referring the fact that using TAI instruction can be a problem for the interruption.

[TOUKO]

i was mainly referring the fact that using Txx instructions can be a problem for the interruption.

yes it can be, but i'll see if it really is in a real use (AKA in a game condition) ..

But the big difference is that i can decompress directly in VRAM .

[Stef]

I don't know if that is the same for MVx instruction on 65C816 but i guess it is, it probably can't interrupt it and restore the internal state.

[tepples]

GARTHWILSON says MVN is interruptible.

[Sik]

Original: 9216 bytes
APLIB: 3968 bytes (43%)
LZ4HC: 4577 bytes (49%)
LZ4W : 5972 bytes (64%)

Huh, and I thought SLZ was doing bad due to the smaller one performing awful (but it's simple, so I guess I can't expect much either). I need to get around implementing that XSLZ idea I had around (SLZ isn't the most efficient thing out there), the problem is that I'm too lazy to make a compressor for it. Also SLZ is slow anyway, although I haven't measured it in a while =P

Anyway, with SLZ:
Smaller file: 1536 → 1096 bytes (71.35%)
Larger file: 9261 → 4861 bytes (52.49%)

These files seem to compress awfully in general though. How come nothing can make it shrink to around 30%?

[Revenant]

The larger file, with my implementation of HAL's SNES-era compression:
9216 -> 4467 bytes (48.5%)

Exomizer:
9216 -> 3682 (40%)
9216 -> 3663 (39.7%) when crunching backwards

I have no idea what the performance for decompressing them would be like compared to the other algorithms mentioned so far, though.

[93143]

I just tried 7zip in Ultra mode with LZMA2 and I got 39.6% (3650 bytes) on the 9 KB file and 62.4% (959 bytes) on the 1.5 KB file. Apparently it's not just '90s-friendly methods that have trouble with this data...

[TOUKO]

With LZ4:
9216 -> 5044 (54,73%)
1536 -> 1097 (71,42%)

I have no idea what the performance for decompressing them would be like compared to the other algorithms mentioned so far, though.

Exomizer is like pucrunch, not fast because of a good ratio as oposite to Lz variants .
If you want the better ratio available exomiser is a good choice, if you want something fast for on the fly decompression, the better choice is LZx .

[Stef]

GARTHWILSON says MVN is interruptible.

Oh, that is definitely a nice advantage over the Hu6280 TAI instruction, that can explain the extra cycle as well.

About the compression, there is unfortunately no way to obtain good compression ratio for gfx data when you are using lossless compression (except for simple or cartoonish style gfx). 50% rate is already nice for me, and if you can obtain 50% with a very fast unpacking then you are done

[TOUKO]

Oh, that is definitely a nice advantage over the Hu6280 TAI instruction, that can explain the extra cycle as well.

Yes is a good advantage, but it's Txx, TAI is only one block transfert instruction, the Hu6280 has 5 .
TII
TDD
TAI
TIN
TIA

50% rate is already nice for me, and it you can get 50% with a very fast unpacking then you are done

I agree .