Hi,

I used for the first time recently the BitBuster compression tool. I was amazed at what it could do for a SCREEN5 picture : it reduced it size almost 6 times !! Congratulations to the Team Bomba developpers !

Anyway, I used the BitBuster depack source code in ASM to load the picture in a program. The way I did it is to depack the picture in RAM and then load it in VRAM.

But did someone developped a variation of the BitBuster depack source code to depack data directly in VRAM ?

I thought at first it would simply involve replacing all LDI and LDIR ops by OUTI and OTIR, but it is a little bit more complicated, as the LDIR are based on the BC register, while OTIR only works with the B register. There is also quite a bit of preparation before to allow those OUTI and OTIR to do their job with the VDP. Not to mention the mandatory check on VDP r#2 before continuing the data transfer ...

So before doing it myself, I just wanted to check if I was not going to do something that had already been done before.

original developer speaking here

I don't know if somebody has done that before, but I know there are some people who would like to have such version.
I tried to do it myself and got something working in NLMSX, but real MSX doesn't seem to allow VRAM reads and using a HMMC (?? not sure if it's this one) copy to write new data to VRAM

I was looking into it at one point but felt that it was too much work (at least for me at that time). If someone makes a VRAM version I hope it will be available to the public. At least I would be very interested in it.

Once upon a time it really existed a VRAM bitbuster decompressor; but now is dissapeared. It really uses only a byte of RAM to make the transfer to VRAM and IIRC it was obviously very slow.

It is indeed very slow as it has to setup the read pointer, read a byte, set up the write pointer and then write the byte for every byte it needs to copy. Takes bloody ages. Better unpack in ram and copy the whole thing in vram at once.

It does work nicely on g9k though because it has a separate read and write pointer.

OK ... It means I will put on my "to do" list the coding a ROM->VRAM version of the BitBuster depack routine then. When it will be done, I'll make it available to everyone ... If the developers agree with that, of course

Still on the subject of dumping data in VRAM, is it necessary to reset the r#17 register to zero after using the indirect access to the VDP ?

To avoid having to set the read/write pointer for each byte in a string copy, you could use a small buffer (say 256 bytes) to speed up things. It will still be slow, but I guess it could be really helpful for MSXDEV entries.

Metalion, bitbuster has been released under the MIT license, so feel free to modify & release your own version!

Well, I did not have the time until now but I started developping a direct VRAM depack subroutine version of BitBuster these last few days. What I did basically is :

1. setup VDP for direct VRAM access
2. replace LDI and LDIR instructions with equivalent code blocks in which the data transfer is carried out by OUT (98h),A

In the end, I must conclude that it is not an easy task : the decompression algorythm uses the stream of decompressed data as a database, so that it can copy parts of the file onto itself. Impossible to do on VRAM data, unless :

a) using a RAM buffer, and in this case, maybe it's easier to go the classic [RAM depack - VRAM transfer] route

or

b) re-writing completely the algorythm in order to allow VRAM to VRAM copy, but it will probably slow down the decompression process

Why BitBuster and not pletter that usually goes better than BitBuster ?

There is no major algorythm difference between Pletter and BitBuster.

It'll be cool if the final version is MSX1 compatible, though. Of course, this means sequential access to VRAM

I've also seen a working version from ROM to VRAM using just 1 byte of RAM, but it was sluggish.

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?

And pletter always compresses better than BitBuster, so why not use that?

Quote:

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.

Quote:

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, 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.