modified Shrinkler without parity context

[roudoudou]

Hi
I modified Shrinkler v4.6 to avoid using parity context because Z80 is not a 68000
You may expect approx 0.5% gain on the total
New executables for Linux64 / Win32 / Win64
New decrunch routine a little smaller 202 bytes
Enjoy 

[GUNHED]

@roudoudou : Thank you very much! Awesome!! 

[teopl]

Thanks, I always wanted to try this compressor.

I am interested in greater compression and decompression speed is not relevant (as long as it's not in seconds).

I see there are several options for the compressor - does someone have some optimal settings for compression of some standard amstrad game assets (1-2K of graphics, song, texts, levels...)?

Or maybe default one is ok?

[roudoudou]

I see there are several options for the compressor - does someone have some optimal settings for compression of some standard amstrad game assets (1-2K of graphics, song, texts, levels...)?

use " -d -9 " for raw data and maximum compression, everything else is useless for us. Option  " -p " to avoid shittext with windows

[teopl]

I have trouble converting this z80 decompressor to SDCC compatible asm.

I used Arkos2 Disark tool and compiled it but the cpc crashed when decompressing and now I am not sure if the source is not coverted ok or I am making another error.

Does someone have a SDCC compatible asm?

Ideally I would like to call it like this: (please correct me if I am doing it wrong...)

Code: [Select]

void decompress(u8* source, u8* target) __z88dk_callee __naked {

    __asm

        pop af

        pop ix
        pop de

        push af

        call SHRINKLER_DECRUNCH

        ret

    __endasm;
}

[Targhan]

Mmmh, it is normal that you don't POP the register that you PUSHed???
I don't know what the three first POP are doing here, maybe something related to how to retrieve parameter from C?

Anyway, a PUSH af / CALL / RET will crash for sure. At least, a POP AF must be done before the RET.

[teopl]

If I understand correctly, the ret address must be last on stack when you leave __z88dk_callee function, the other similar functions work fine this way.

[Targhan]

I don't know how Z88DK works. But when I see non-symmetrical PUSH/POP, I hear a huge WARNING alarm in my head.

[m_dr_m]

I guess the first pop af is the ret address, so it's properly pushed back once the registers have been picked.

[Arnaud]

I am not sure to understand this part of code.
It reserved at next aligned position from end of code 0x100 + 0x400 + 0x200 (+ 0x100 ?) = 0x700 (or 0x800) Bytes ?

Code: [Select]

probs=($+256)&#FF00
;+#200: for odd context
probs_ref = probs+#400 ; one word
probs_length = probs_ref ; starts at +1
probs_offset = probs_length + #200 ; could be + #40 by changing test
That means Shrinkler needs a array of 0x800 Bytes to work ?

[roudoudou]

yep!
should probably work with #600 buffer as there is no more odd context changing probs_ref=probs+#200 (and LD H,6*...   / LD B,6 at init)

[Arnaud]

A question, is a lot of modifications to remove the mandatory aligned address for probs ?

SDCC ASZ80 doesn't like :

Code: [Select]

probs=($+256)&#FF00

[roudoudou]

You may solve the issue aligning the routine then

probs=getnumber+#100

[Arnaud]

Hi,
here a Shrinkler version for CPCTelera with an example.

Code: [Select]

void shrinklerDecrunch(const u8* source, u8* destination, u8* buffer)
- source : compressed data aligned
- destination : destination data
- buffer : free memory of 0x600-Bytes aligned

The alignment is only for speed optimisation ? With SDCC it's hard to have something aligned.

[teopl]

@Arnaud  thanks, this worked but that 2K buffer is a little too much for me now, maybe if I organize things differently.

But the compression did free additional ~700 bytes compared to exomizer2.

And the speed is really problematic meaning it is measured in seconds Anyway, great to have it working and maybe use it smart some day.

[GUNHED]

And the speed is really problematic meaning it is measured in seconds Anyway, great to have it working and maybe use it smart some day.

Could you please give an rough estimate how much seconds for a KB ?

[Arnaud]

Could you please give an rough estimate how much seconds for a KB ?

It decompress 7.5KB (17KB screen) in 34s -> 4.5 KB/s

[GUNHED]

Thanks a lot Arnaud, this was actually what did interest me. The time to decompress a ROM. Well 34 seconds - that's ... long.