Gfx9000 Library

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

By msd

Paragon (1472)

msd's picture

21-01-2004, 16:56

Thanxs for testing it guys.. Not only the size is importend but also how fast is the decompression on MSX? Any ideas on that?

By anonymous

incognito ergo sum (116)

anonymous's picture

21-01-2004, 16:56

Yeah well.. F-kernel wasn't designed for 64K RAM, was it...

About speed.. now that Bitbuster is more optimized, I think TCF is takes about the same time to decompress. The decompressor is 153 bytes, no additional memory required.

By msd

Paragon (1472)

msd's picture

21-01-2004, 16:59

That sounds very interresting GuyveR800. just 153 bytes

By ro

Scribe (4667)

ro's picture

21-01-2004, 17:12

Yeah well.. F-kernel wasn't designed for 64K RAM, was it...

About speed.. now that Bitbuster is more optimized, I think TCF is takes about the same time to decompress. The decompressor is 153 bytes, no additional memory required.

Yeah, it can run on 64k. (although min 128k. is advised)
Oh, well. RT was written almost 10 year ago and has proven to be a great tool. But, remember, this is not a competition. It's to find out which compressor fits best on MSD's lib

By ro

Scribe (4667)

ro's picture

21-01-2004, 17:14

Yeah well.. F-kernel wasn't designed for 64K RAM, was it...

About speed.. now that Bitbuster is more optimized, I think TCF is takes about the same time to decompress. The decompressor is 153 bytes, no additional memory required.

Hmm, do you read 1 byte at the time from disk if no mem. required? What does it do with speed? I'm curious, sounds cool.

By anonymous

incognito ergo sum (116)

anonymous's picture

21-01-2004, 17:29

Just the standard DOS 128 byte block size.

By Grauw

Ascended (10560)

Grauw's picture

21-01-2004, 17:32

#0080?

~Grauw

By ro

Scribe (4667)

ro's picture

21-01-2004, 17:39

figures (technically it DOES require additional mem. since you can't just figure that every body uses DOS.. but hell)
We decided to use a buffer of 16k. sinces we allready had this (temp) map available in the kernel. A small buffer is cool, but slowes down the decomp. time on the other hand (more diskaction) (tho, RT has a 'templen' byte which tells him the bufferlenght, so it could be downsized, but then you also need to compress it with that buflen)

Well, MSD build in a comp.type.id a user can decide for him/her self which to use... there are a vast amound of great comps out there (we just proved it)

By anonymous

incognito ergo sum (116)

anonymous's picture

21-01-2004, 17:46

Everybody that has a diskdrive has DOS (or BDOS at least, and that's what counts here). Anyway, a different sized buffer could be used, there's no recompression needed. There's no difference in fileformat compared to RAM, VRAM or direct from disk data.

By Grauw

Ascended (10560)

Grauw's picture

21-01-2004, 18:24

Anyways, though multiple compression schemes could ofcourse be used in G9B, it would be kinda 'ok' if TCF is the default one, if you ask me Smile. The decompressor being only 153 bytes, it could be added easily, and there is a (PC-)compressor already available...

So, ah, well... I dunno. Maybe before TCF is finalized someone else will come up with even better compression Smile. And there's still the speed issue we didn't measure.

~Grauw

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