BitBuster depack in VRAM

Paragon (1625)

05-09-2007, 23:28

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.

!login ou Inscrivez-vous pour poster

Par Arjan

Paladin (787)

05-09-2007, 23:58

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

Par dvik

Prophet (2200)

06-09-2007, 00:03

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.

Par jltursan

Prophet (2619)

06-09-2007, 01:10

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.

Par Edwin

Paragon (1182)

06-09-2007, 01:16

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.

Par Metalion

Paragon (1625)

06-09-2007, 08:50

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 ?

Par Arjan

Paladin (787)

06-09-2007, 09:09

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!

Par Metalion

Paragon (1625)

12-02-2008, 13:21

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

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

Par ARTRAG

Enlighted (6935)

12-02-2008, 13:24

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

Par Metalion

Paragon (1625)

12-02-2008, 13:31

There is no major algorythm difference between Pletter and BitBuster.

Par pitpan

Prophet (3155)

12-02-2008, 13:33

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.