#2264 - cosmic4z - Fri Jan 31, 2003 10:40 pm
Hello,
My first posting here ...
I think I have found a BUG in the LZ77 uncompression GBA ROM function ... uncopressing to VRAM ... (LZ77UnCompVram)
I have some tile data that I compressed.
When I decompress to WRAM (using LZ77UnCompWram) then DMA to VRAM ... it works perfect.
When I decompress the same data direct to VRAM (using LZ77UnCompVram) ... the data is corrupt!
WHAT IS GOING ON !!! ?
Jamie
#2273 - tepples - Fri Jan 31, 2003 11:55 pm
| cosmic4z wrote: |
When I decompress to WRAM (using LZ77UnCompWram) then DMA to VRAM ... it works perfect.
When I decompress the same data direct to VRAM (using LZ77UnCompVram) ... the data is corrupt! |
Corrupt in what way? Are the pixels lined up properly, but garbage replaces some of the pixels that were originally of color 0 or color 0x20? In that case, you may have run into a bug in the LZ77 compressor floating around on the Internet, which causes the compressed data stream to refer to data before the start of the file. Here's a way to test whether or not you're seeing this:
1. Fill the first 32 bytes of a buffer with random data.
2. Use LZ77UnCompWram(), starting the decompression immediately after the random data.
3. Copy to VRAM.
If you can reproduce the corruption this way, you have an invalid LZ77 data stream, and you might be interested in my corrected compressor. E-mail me if you want it.
If you can't reproduce the corruption this way, make sure that both source and destination buffers start on addresses that are a multiple of four bytes. The *UncompVram() functions are a lot pickier about the destination starting address than the *UncompWram() functions.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#2288 - cosmic4z - Sat Feb 01, 2003 1:38 pm
Thanks for your suggestion Tepples.
I believe (*know*) that the data has been compressed correctly and that the problem lays with the decompression.
I tried compressing the data using both AGBComp.exe and also the LZ77 compression source. I get exactly the same results.
When I decompress the data direct to VRAM it is corrupt. If I decompress (the exact same compressed data) to WRAM first, and then DMA it to VRAM, it works perfectly fine.
Both source and destination address are a multiple of 4 bytes !!.
I guess it's just one of those unresloved mysteries (how I hate those !!).
I will just have to work around it.
Is there any source for GBA huffman compression ?
Thanks,
Jamie.
#2292 - ZoneGN - Sat Feb 01, 2003 2:48 pm
Your uncompressed & your compressed file must be also a multiple of 4
if you have for example un compressed file 3877 octets, you must add 3 octets (anything you want) to have 3880 octets.
i think that fix the problem.
#2436 - Paul Shirley - Mon Feb 03, 2003 10:50 pm
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 9:39 pm; edited 1 time in total
#2437 - Splam - Mon Feb 03, 2003 11:06 pm
Well it's the BIOS VRAM specific decompression routine so I presume Nintendo know what they're doing ;)
#2438 - cosmic4z - Mon Feb 03, 2003 11:37 pm
Paul:
Yes ... all data (source and dest) is aligned to 4 bytes and multiples of 4 bytes in length.
Splam:
Nintendo know what they are doing do they? I am not convinced ... I am convinced there is some kind of fault in the BIOS LZ77 VRam decompression routine.
#2440 - Splam - Tue Feb 04, 2003 12:26 am
I'm sure someone would have noticed it by now if there was a bug ie a game developer or someone at Nintendo. If you'd ever had to go through the Nintendo submission process for a game the stuff they put you through (which is like torture sometimes) must be trivial compared to to their hardware testing. Still I suppose theres always the chance that a certain ordering of data could produce an error and you just happen to be the lucky guy to stumble across it.
Have you tried (and this is just a stab in the dark) using the vram call to decompress to wram then dma it? or is that what you meant when you said you'd tried it to wram already? or did you use the wram specific call for that?
Oh yeah, are you testing this on hardware or an emu? and if an emu are you using a bios file? if so which one? there are pre-release versions around which supposedly have bugs from some of the early devkits.
#2451 - Splam - Tue Feb 04, 2003 8:34 am
One other thought, you said you used agbcomp to compress the data, did you make sure to set the search size to 2 or greater?
#2463 - cosmic4z - Tue Feb 04, 2003 1:02 pm
Hi Splam.
Some interesting points you make.
I am actually a 'professional GBA developer' and YES ... I have had the pleasuse of going through Nintendo's wonderfull submission process !!! ... (the joys or getting link up mode working).
I tried it both on Hardware and on the Visualboy Advance emulator ... same results.
I tried uncompressing to WRAM and then DMA'ing to VRAM ... when I do this the data comes out fine / no problem. I uncompress the exact same data direct to VRAM and it's like garbage city !!!
AHH !!! ... just read your post again ... when I uncompressed to WRAM I did infact use the WRAM specific call ... will try with the VRAM specific call ... decompress to WRAM then DMA to VRAM ... nice idea :-)
I actually tried using some LZ77 compression source to compress the data ... and also AGBComp ... made no difference in all cases / permutations.
I will also have a look at your suggestion re: search size of 2 +
Thanks for your suggestions Splam.
#2464 - cosmic4z - Tue Feb 04, 2003 1:38 pm
Oooops !!!
Just tried uncompressing to WRAM unsing both LZ77UnCompWram() and LZ77UnCompVram() ... then DMA'ing to VRAM.
Results were not the same (WRAM specific function was fine ... VRAM specific function garbaged the data).
Had a look at the docs for AGBComp ...
-l search (>0)
Outputs using LZ77 compression. Use LZ77UnCompVram() or LZ77UnCompWram() to decompress.
Specify 2 or more for search for data decompressed using LZ77UnCompVram().
Guess who wasn't setting a value for the search size .... DOH !!!.
Sorry bout that guys.
- Jamie
#2475 - tepples - Tue Feb 04, 2003 4:36 pm
Without even looking at a disassembled BIOS, I can see how the decompressor might screw up when trying to read 1 byte back while writing 2 bytes at a time. It would read a byte that hasn't even been written yet (the VRAM functions write two bytes at a time). I can also think of a simple workaround that Nintendo could have used while writing the BIOS, special casing all matches of offset 1, which could actually have sped up the decompressor. Therefore, it's a bug. And it probably won't be fixed in the next BIOS revision because BIOS revisions have to remain bug-for-bug compatible with programs that exploit BIOS bugs for performance.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.