BitBuster depack in VRAM

It can be MSX1 compatible if the VRAM to VRAM copy is done thru the VRAM read/write access.

Why not come up with some scheme that doesn't need to read the VRAM?
Because it would mean using a new compression/decompression algorythm.
I am no expert in compression algorythms, I just modify an existing source.
As I said earlier it could be done using a small RAM buffer, but I am not sure it would be efficient.

And pletter always compresses better than BitBuster, so why not use that?
Because I started to work with the BitBuster algorythm ... It's like that.
And because Pletter is an "improved" BitBuster, what can be done with BitBuster will be certainly applicable to Pletter later on.

Well, I looked at the possibility to include a direct-to-vram unpacker with pletter, and I do not think the bitbuster/pletter algorithm is very suitable to do this. When using a buffer to read from and write to vram, one of the problems is when the part to copy overlaps with the part to copy to. So I concluded it was not worth the trouble, but don't let me stop you

If I would need a direct-to-vram unpacker, I would take pletter4, force the offsets to 8 bit, and use a circular buffer of 256 bytes in ram to keep track of the bytes written to vram.

Well, you can always use aPLib. It's as good as bitbuster/pletter and also unpacks directly to VRAM at a very reasonable speed. The source code is available and it can be easily improved, specially the VRAM dump loop.
I took a look at the source, and it is the same algorythm as BitBuster/Pletter.

There is a SEGA VRAM depack subroutine and they used a VRAM read/write thru INs and OUTs to perform the data copy. So they choosed that solution over the buffer one. It might be interesting to compare speed with such a solution implemented for MSX.

I'll try to do it with BitBuster/Pletter.

There is a SEGA VRAM depack subroutine and they used a VRAM read/write thru INs and OUTs to perform the data copy. So they choosed that solution over the buffer one. It might be interesting to compare speed with such a solution implemented for MSX.

After some little optimization and as far as I've been using it, it's fast enough to unpack typical VRAM initialization data and even to dump in the visible screen without too much fuss, no need to use "Please wait..." messages . Of course I'm talking about common MSX1 VRAM data sizes, to unpack a SC8 page could take a bit more