I have pretty much the exact same impression.
This:
Code:
.org $C000
met16header:
.dw met16sets_bank00
met32header:
.dw met32sets_bank00
metscreenheader:
.dw metscreensets_bank00
metlevelheader:
.dw metlevelsets_bank00
ended up as:
Code:
LC000:
DC.B $08,$C0,$12,$C0
LC004:
DC.B $1A,$C0
LC006:
;3102 bytes
DC.B $1E,$C0,$22,$C0,$50,$C0,$7E,$C0,$AC,$C0,$DA,$C0,$08,$C1,$45
DC.B $C1,$82,$C1,$BF,$C1,$FC,$C1,$4C,$C2,$75,$CB,$79,$CB,$00,$FE
DC.B $80,$84,$87,$FE,$84,$FE,$FE,$87,$00,$89,$8A,$FE,$8D,$00,$FE
(Removed for brevity)
I'm puzzled by the how the header labels ended up being divided. Absolutely everything past that is read through at least one layer of indirect indexed, so I didn't expect it to be picked up and separated.
Relevant code to the header labels.
Code:
;"reserved" variables are zero page temp RAM.
lda met16header
sta reservedE
lda met16header+1
sta reservedF
In another location:
Code:
lda met16header
sta reserved0
lda met16header+1
sta reserved1
Code:
lda met32header
sta reservedE
lda met32header+1
sta reservedF
Code:
lda metscreenheader
sta reserved0
lda metscreenheader+1
sta reserved1
Code:
lda metlevelheader
sta reserved0
lda metlevelheader+1
sta reserved1
After each I read indirectly, but some of them set y in various ways before the read. I could imagine if the whole thing was one giant block, or if it was each header's two bytes, then a solid block, or if it was single a label per each byte of the header. How it is now with the first two headers together, then one more, then the last in the block totally puzzles me.
I haven't
really dived in to see how close it got with the rest of my data in this game, but I'm pretty impressed.
I never posted, but I tried the old version with a smaller game (since then it didn't support this one's size) and read through a lot more than this one and it did extremely well with what I checked.
Last note: I get an unhandled exception every time I minimize the program with a disassembly open. It minimizes fine before it opens a rom, though.