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 ;)
@roudoudou (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1714) : Thank you very much! Awesome!! :) :) :)
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?
Quote from: teopl on 19:00, 14 May 20
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
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...)
void decompress(u8* source, u8* target) __z88dk_callee __naked {
__asm
pop af
pop ix
pop de
push af
call SHRINKLER_DECRUNCH
ret
__endasm;
}
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.
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.
I don't know how Z88DK works. But when I see non-symmetrical PUSH/POP, I hear a huge WARNING alarm in my head.
I guess the first pop af is the ret address, so it's properly pushed back once the registers have been picked.
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 ?
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 ?
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)
A question, is a lot of modifications to remove the mandatory aligned address for probs ? :D
SDCC ASZ80 doesn't like :
probs=($+256)&#FF00
You may solve the issue aligning the routine then
probs=getnumber+#100
Hi,
here a Shrinkler version for CPCTelera with an example.
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.
@Arnaud (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1424) 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.
Quote from: teopl on 11:16, 17 May 20
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 ?
Quote from: GUNHED on 14:03, 17 May 20
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
Thanks a lot Arnaud, this was actually what did interest me. The time to decompress a ROM. Well 34 seconds - that's ... long.
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)
Quote from: krusty_benediction on 21:53, 09 January 24a 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?
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]
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 ;D
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' ;) :)