additionally: what's typical compression? I'd say stringfinding. What if you put these strings raw in ROM and use them directly? MML music is like this. Technically it's the same practical effect as having comprsssion. E.g. there's no way you can ban compression! Not by restricting RAM, not by forbidding it..

Decompressing data doesn't really cost much time. Bitbuster's decompressor can decompress (output) about 45KB per second. Plus, if that extra second annoys you, some interrupt based effect (for example, the text 'GAME START' blinking when starting a new game) can mask the delay.

And there are Bitbuster Xtreme and Pletter.

Not sure what's different. But they are for free.

Bitbuster Extreme has an extremely small depacker.
Pletter is a compression scheme based on bitbuster, it has somewhat better compression and it supports variable offset lengths (ranging from 8 to 14 bit), which really helps on smaller data.

And today I have seen a very nice ROM -> VRAM bitbuster decompressor. It does not use a RAM buffer, just one additional variable in RAM. Not very fast, but good enough for full screen still images. Very interesting, I should say. Until now, I was a poor ROM -> RAM -> VRAM believer!

So, in a nutshell, when using comperssion I only see benefits for everyone.. can't be that bad, .. rite?

First have to make it work ourselves then I agree. Until then......

hmm, for a ROM->VRAM bitbuster decompressor it can be worth while to use a small buffer (say, 64bytes) to store strings in. This will improve decompression speed dramatically, as the vram pointer doesn't have to be changed for each byte anymore.

Quote:

And today I have seen a very nice ROM -> VRAM bitbuster decompressor. It does not use a RAM buffer, just one additional variable in RAM. Not very fast, but good enough for full screen still images. Very interesting, I should say. Until now, I was a poor ROM -> RAM -> VRAM believer!

Hi. You can download this routine from Karoshi forum (Snippets)

http://www.msxgamesbox.com/karoshi/index.php?topic=427.0

Single example to use only 1 byte of Ram.

Bye!

JJ: Thanks.

@JJ: I don't suppose you could make a faster version which uses a small buffer and can use the V9938 as well? Now that'd be *really* handy!

OK, I will tell you a secret I am working on a turn-based strategy game for MSXdev '06 (hopefully I will finish!)

I chose to work with a 48KB ROM. This way it is easy to test it on my own MSX. A game that uses 32/48KB ROM and 16KB RAM can be loaded and run from RAM on any MSX with 64KB right? For a 128KB ROM you need a RAM expansion or flash cart or something. How many people have only MSX1 but have the hardware needed to play a 128KB ROM?

I think 48KB+16KB is a good limit for the contest because that would probably allow the most people to play it on their MSX (or am I wrong?) Or how about this for MSXdev '07... you can make a 48KB ROM - OR - you can make a megaROM but then you also have to make a disk-based version

I also would like to see a separate compo for MSX2 games.

Quote:

@JJ: I don't suppose you could make a faster version which uses a small buffer and can use the V9938 as well? Now that'd be *really* handy!

For no repeat in two forums same words, please, this questions in new thread or the best, in the thread of Karoshi forum, ok?

About compression...
more ram allows to compress also the code with a very brute force approach...

Actually, with 64K ram one could use high level languages like C, compiling the code with a very simple memory layout (say 48Krom + 16Kram), pack all the stuff and store the result in a in a single rom page (say 16Krom).
At the moment of the need , you unpack and run it in ram (64Kram needed).
Do the procedure 2-3 times (for example for 2-3 levels of the game that should work independently) and you get a 48K packed rom that is:
1) written in C, (easy to develop and manage)
2) equivalent to a megarom

I know that this is crappy programming, but also those shortcuts can help to develop faster....

I vote that somewhere in the msxdev we should allow 48Krom + 64Kram :-)