I'm not very busy today -- and I think I may be in the mood to take a gander at this.

A savestate for the ending would be nice.  In the meantime I'll look at the font's compression in the likely event that the game uses the same compression scheme for the graphics in question.

*me takes a piss, then opens the ROM*

EDIT --

The graphics compression routine I found (looks like it starts at offset 0x1D855) looks like it is a form of basic RLE with various control codes.  $99, $AA, $BB, $CC, $DD and $EE are control codes indicating the decompressor to do something special (like output a run of bytes).  Other bytes are stored normally.

This is probably why you were having trouble before -- you probably had one of those control codes in your image and it was borking the works.  I've deciphered what all the control codes do but one of them still puzzles me so I'm going to look at it further before giving details.

More to come.


EDIT 2 --

I couldn't figure this last bit out from the intro sequence, so it doesn't look like it applies to text decompression.  I find it unlikely that it applies to ending graphic questions -- but you never know.  Anyway here's what I have so far:

$99, $AA, $BB, $CC, $DD, $EE are control codes.  Following the control code is one or more bytes indicating additional info for the control.  Other bytes not part of the control code are output normally (not compressed).

$99:  output a byte normally.  "99 63"  would output "63".  This is so you can output bytes that are normally control codes.

$AA:  run of byte at address $93.  I don't know what is put at $93 (this is what I couldn't figure out).  At any rate, "AA 05" will output the byte at $93 five times (so if $93 contained, say, $11, this would output 11 11 11 11 11)

$BB:  run of $00.  "BB 05" would output five 00's

$CC:  run of $FF.  As you'd expect

$DD:  run of specified value.  "DD 43 05" outputs $43 five times

$EE:  termination marker.  Marks end of compressed data (decompression routine exits upon reaching this byte).


A run length of 00 would actually be a run of 256


I did not bother locating any actual compressed text or pointer tables, so I don't know how they're constructed.


Other misc notes you probably don't care about:

Looks like the routine starts at 0x1D81C.  X and Y are backed up on routine entry and restored on routine exit.  If $1A is nonzero, the game seems to jump to a seperate routine which does something pretty weird instead of the normal decompression routine.

Input for routine is:
$0010,$0011 -> source address (CPU address) -- ie:  pointer to start of text graphics placed here
$0012,$0013 -> destination address (PPU address) -- ie:  where to put decompressed graphics in PPU space
$001A -> determines whether to do the RLE routine or the wacky routine


Wacky routine ($1A nonzero) skips over the usual RLE decompression and simply reads exactly $60 bytes from the given source pointer.  It outputs the first $20 at the dest address, the next $20 at dest address + $0100, and the last $20 at dest+$0200.  Data is a straight copy -- no compression involved.  I have no idea what this routine would be for -- it seems kind of ridiculous.  It might be for some nametable drawing crap or something.

This?  Awesome.  Saves me the trouble of writing a compressor.  :thumbsup:

In that event I'm going to stop putting time into this.  InVerse -- if you want that titlescreen arrangement and that other stuff you talked about you'll have to find it yourself.  Now that the compression issues are solved I lack the interest to do any more fiddling.

-necrobump to save a thread from the great board prune of 2009-