Pletter (or other compression tools) performance

I did once a comparison on all Z80 compression tools, but it was a virtual one. Meaning I was only comparing theoritical values on decompression code size, compression ratio and decompression speed. The best of them all was zx0. Pletter was in 45th position (there was a lot of tools variations, each of them taking a position). But, of course, performance largely depends on your specific need, and the data you're compressing. I would still do a test with zx0, though.

Decompressing directly the image to VRAM is feasible, but not all tools are offering this possibility (specifically the code to do it). I know zx0 does, I've seen the VRAM version in GitHub. The problem is that good compression tools use a "data string dictionnary", which is stored in the decompressed data as it goes along. Meaning that if you store the data in VRAM, it will have to read back data in VRAM to complete decompression. Which in turn will slow the whole process.

In conclusion, it's feasible, but you might have to adapt the code to do it, and it will be sensibly slower than a RAM decompression.

When creating the MSXBAS2ROM compiler I chose to use pletter to compress the image files when they are loaded via the BLOAD command on the MSX BASIC code.

This compression is done in blocks of 256 bytes of the raw image, that is saved each one inside the compiled ROM file in a way that facilitates the decompression in RAM of these blocks and later copying one by one to VRAM.

You can get an idea of the load time when unpacking via pletter format by looking at the DEMO5 from this link. The time to load the image in VRAM is faster than BLOAD's used by ROM BASIC, but the delay is still noticeable.

I think, however, that a direct assembly program can speed up a little more this load time via pletter, but not by a direct decompression byte to byte to VRAM. The tests that I had made before gave me the result that a decompression of blocks in RAM (and after that copy it to VRAM) is better to speed up this process.

Thanks for all help.
For my specific case (SC 11 bitmap data) I have one unused bit (bit 3 means YJK or palette, but I never use palette), so I can use this bit as flag for repetition in a simple RLE encoding.

Code would be like this (untested):

; Input
;   HL: pointer to encoded data
	ld	b, 0 			; 256 repetitions
	ld	c, PORT

.init_1:
	ld	a, 0000 1000b		; mask for the repetition flag
.loop:
	and	(hl)
	jp	nz, .decodeRLE
	outi
	djnz	.loop
	jp 	.exit

.decodeRLE:
	ld	a, (hl)		; read byte that will be repeated
	and	1111 0111b	; clear repetition flag
	ld	e, a
	inc	hl
	ld	d, (hl)		; number of repetitions
	; b = b - d
	ld	a, b
	sub	d
.loop_decodeRLE:
	out	c, e
	dec	d
	jp	nz, .loop_decodeRLE
	
	inc	hl
	jp	.init_1

I was revisiting this issue here...

Is there a way to unpack pletter (or other) compressed stuff by chunks of 256 decompressed bytes?

For example: I have a 16kb data file, compressing it with pletter it turns into a 4,5kb file.

Is there a way to decompress the first 256 bytes now, the next 256 bytes on the next frame, and so on, until all the 16kb be decompressed?

Ok, using this feature of ZX0 still requires a lot of work preparing all the files so you can compress each block individually, but at least the compression ratio will be not much worse compared to compressing the whole file in one go.

I just remembered my own tool now Bitbuster 2 has a block mode. Of course the compression ratio is much worse than ZX0 because each block will be compressed individually but at least it's easy to use.