BitBuster depack in VRAM

Page 2/8
1 | | 3 | 4 | 5 | 6 | 7

By Metalion

Paladin (900)

Metalion's picture

12-02-2008, 13:39

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

By sjoerd

Hero (593)

sjoerd's picture

12-02-2008, 13:46

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? Question

By Metalion

Paladin (900)

Metalion's picture

12-02-2008, 14:26

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? Question
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.

By jltursan

Prophet (2058)

jltursan's picture

12-02-2008, 15:43

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.

By sjoerd

Hero (593)

sjoerd's picture

12-02-2008, 15:57

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 Tongue

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.

By Metalion

Paladin (900)

Metalion's picture

12-02-2008, 16:55

jltursan said :
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.

Hey ... Nice one LOL!
I'll take a a look at it and see if it is more suitable.

sjoerd said:
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

That is roughly my conclusion, also.
I tried to see if another algorythm was better suited to that purpose.
Unfortunately, most compression algorythms are based on a "sliding window" and a a length/distance copy of the already decompressed data. So a copy of the existing data is almost always needed.

By Metalion

Paladin (900)

Metalion's picture

12-02-2008, 17:09

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.

By SLotman

Paragon (1188)

SLotman's picture

12-02-2008, 17:25

I would love a bitbuster that could depack to vram... even slowly... could be great for static screens, or even to "load things once"...
I also tried to do that, changing LDI to LDIR, but with no success either Tongue

By jltursan

Prophet (2058)

jltursan's picture

12-02-2008, 17:51

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 Smile. Of course I'm talking about common MSX1 VRAM data sizes, to unpack a SC8 page could take a bit more Tongue

By Metalion

Paladin (900)

Metalion's picture

12-02-2008, 19:04

@jltursan : Do you mean you already converted aPLib to MSX ?

Page 2/8
1 | | 3 | 4 | 5 | 6 | 7
My MSX profile