Bee52: Crashes depend on CHRRAM data

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

griever
Posts: 39
Joined: Thu Apr 05, 2007 1:34 pm

Bee52: Crashes depend on CHRRAM data

Post by griever »

As I've said before this game has masterpiece compression for gfx, so I was lucky enough to expand ROM itself and overwrite uncompression code, so it could load plain data. As a result, I've got this. As you can see This patch changes Font loading part, so uncompressed font is now at 0x4D in ROM, so I've began to repaint it, of course... And BANG! Game Crashes! I couldn't believe it - I thought it was impossible. Arright - just open ROM in tile moelester or something and delete blank red(second color) tile(I mean, make it black) - you'll see. So, as far as I can say, the problem somewhhere near code:

Code: Select all

$E6CF:2C 02 20  BIT $2002 = #$20
$E6D2:50 FB     BVC $E6CF
$E6D4:A9 81     LDA #$81; this command is never executed
Strange thing, cause the difference only in GFX data loaded... :?: [/url]
bunnyboy
Posts: 449
Joined: Thu Oct 27, 2005 1:44 pm
Location: CA
Contact:

Post by bunnyboy »

That code is waiting for a sprite 0 hit. If you changed the graphics then the right pixels may no longer be overlapping so the hit never happens. You will have to check out the original game to see which pixels can't be changed.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

What's so special about the compression used in this game?
griever
Posts: 39
Joined: Thu Apr 05, 2007 1:34 pm

Post by griever »

That code is waiting for a sprite 0 hit.
D'oh! I've read about it hundred times! Thanks a lot!
What's so special about the compression used in this game?
Dunno... I've never senn something like this before. I tried to ask 'bout it here. There I've also included IDA Lising. I just couldn't figure out what it as by myself, so I've also asked at couple of forums - and nothing... Plus even if i could write unpacker, it would be much harder (impossible? =)) to write the actual packer.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

griever wrote:Dunno... I've never senn something like this before. I tried to ask 'bout it here.
Yeah, I remember that...
There I've also included IDA Lising. I just couldn't figure out what it as by myself, so I've also asked at couple of forums - and nothing... Plus even if i could write unpacker, it would be much harder (impossible? =)) to write the actual packer.
Compression is something that really interests me... but I don't have the patience to trace the decompression code... it seems like too much work! =) But, just for curiosity, since you seem to think the compression in this game is very efficient, can you give me an idea of how good it is? Do you have any compression ratios to share?
griever
Posts: 39
Joined: Thu Apr 05, 2007 1:34 pm

Post by griever »

Do you have any compression ratios to share?
Well... As far as I know from Code/Data Logger:

start screen GFX: Comp-0x584 bytes; UnComp-0x9D0 bytes; Ratio- 1,78
font GFX:Comp- 0x13F bytes; UnComp- 0x290 bytes; Ratio- 2,06

Don't know... Is it good or bad?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

I spent some time yesterday trying to figure something of this compression scheme out... but that's just too boring! I saw they had a function to load 1 bit from the input data, and another to read 2 bits. And depending on the values read they's read something from a table... but I got bored easily, and though I was just wasting precious time I could be working on my game.
griever wrote:start screen GFX: Comp-0x584 bytes; UnComp-0x9D0 bytes; Ratio- 1,78
I think my LZ compressor did better than that most of the time. EDIT: I think I was wrong about this. It usually did worse than that. Of course it really depends on the data...
font GFX:Comp- 0x13F bytes; UnComp- 0x290 bytes; Ratio- 2,06
Fonts should be easy to compress because usually they use only one of the bitplanes. I'm not sure about Bee52, but with such a good compression ratio I'd guess this is the case.

EDIT: I just noticed the link is dead. If you are interested I can upload again, as soon as I find the exact file...
Last edited by tokumaru on Sun Nov 25, 2007 2:43 am, edited 1 time in total.
griever
Posts: 39
Joined: Thu Apr 05, 2007 1:34 pm

Post by griever »

I saw they had a function to load 1 bit from the input data, and another to read 2 bits. And depending on the values read they's read something from a table...
That's the VERY beginning of the hell =)
I think my LZ compressor did better than that most of the time.
Maybe. BTW how about kirby's adventure tile map compression scheme? Have you seen it? Well, It's easy
It uses seven different kinds of compression techniques, which includes the common LZ-Copy,RLE, and uncompressed data methods. The remaining types are simply variations of LZ-Copy and RLE.
But quite effective (sorry, but I don't have ratios). And I've never seen working packer for ths game.
I just noticed the link is dead. If you are interested I can upload again, as soon as I find the exact file...
Why not? It's interesting...
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Fact: RLE is nothing more than the special case of LZ with a 1-byte window.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

griever wrote:That's the VERY beginning of the hell =)
Yeah, I gave up because it was getting hard to keep track of all the branches... maybe looking at a log of the executed instructions would make it easier to understand... as we could see exactly what happens for each bit read...
Maybe. BTW how about kirby's adventure tile map compression scheme? Have you seen it? Well, It's easy
It uses seven different kinds of compression techniques, which includes the common LZ-Copy,RLE, and uncompressed data methods. The remaining types are simply variations of LZ-Copy and RLE.
Sounds like what's used in SMW and many other SNES (and even the Pokemon games on the Game Boy, I think) games... is this it? This was pretty well documented. This seems hard to encode efficiently, as you'd have to try every type of compression for each byte and see what works best.

The compression schemes used in Sonic games are also very interesting (the Mega Drive ones, as the SMS ones just seem to use simple RLE). They have 3 or 4 different formats, each used in differenttypesof data (level maps, graphics, music, etc). The most interesting one is some sort of LZSS optimized to encode small runs ofrepeated bytes, IIRC. gotta check that out again.
Why not? It's interesting...
I'll upload it to a more permanent place in a few minutes... The compression ratio for the CHR I tried was about 1.5 to 1.6... The decompressor written in 6502 assembly will output the data to $2007, but I should probably make a version that outputs to regular RAM.
tepples wrote:Fact: RLE is nothing more than the special case of LZ with a 1-byte window.
You are right. The cool thing about LZ is that, being a step up from RLE, it has built-in RLE support.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Get the LZSS compressor/decompressor here. The host does not allow ZIP files, so change the extension from JPG to ZIP.

I tested it a bit, and I'm not so sure it performs that well anymore... This is just a generic compression algorithm, so it'd be no surprise if it didn't do very well with NES tiles.

I'm still thinking of a way to make better use of the 2D redundancy present in the tiles... generic compression algorithms are 1D, and will ignore that.

If I have the time I'll take another look at that Bee52 code.
griever
Posts: 39
Joined: Thu Apr 05, 2007 1:34 pm

Post by griever »

Get the LZSS compressor/decompressor here.
Arright, thanks a lot.
If I have the time I'll take another look at that Bee52 code.
OK, also you can try this (sorry for shitty colors, but I have net problems, so just had to compess image).
Last edited by griever on Sun Nov 25, 2007 6:18 am, edited 1 time in total.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

griever wrote:OK, also you can try this (sorry for shitty colors, but I have net problems, so just had to compess image).
What is this? I only see a very tall image with a white-ish rectangle at the top...
griever
Posts: 39
Joined: Thu Apr 05, 2007 1:34 pm

Post by griever »

What is this?
Ah, sorry... As I said, that I have net problems =)
Here it is
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

griever wrote:Here it is
Cool! Is everything here? This sure makes things easier!
Post Reply