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 Expand


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 Expand

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 Expand

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 Expand

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.

[krusty_benediction]

a tiny patch that would be great to apply to the archive https://github.com/askeksa/Shrinkler/issues/6 (I hit the issue using gcc on github machines)

[roudoudou]

a tiny patch that would be great to apply to the archive https://github.com/askeksa/Shrinkler/issues/6 (I hit the issue using gcc on github machines)

The version i provided is compiling fine + executables are already compiled, what will be the point?

[krusty_benediction]

No idea why, but there is such kind of error when recompiling from scratch (only needed if you don't care of the executable, of course) with gcc for windows on github machines:

Shrinkler4.6NoParityContext//doshunks.h:65:32: error: narrowing conversion of '-2147483648' from 'long int' to 'unsigned int' [-Wnarrowing]

[roudoudou]

i saw blueberry add a "no parity context" option a year and a half after my version so...

i guess my version will remains like this

[GUNHED]

It's great. I was able to put 37 KB (machine code + text) into a 16 KB ROM... 
However, 63 seconds of decompression is fairly something for 'tea time'