Expanded palette hack

interesting.  yep, that's suggesting to me that plain and Esper Terras aren't sharing (and thus overwriting) a dataset here.  and in that case, is it possible that the sprite/palette cache simply doesn't include Esper Terra?  can it be expanded to do so?

---

so i decided to optimize the patch code:
http://assassin17.brinkster.net/forum-po...s-opt1.asm

*nothing* relates specifically to the issue at-hand here; it's just general speed-up attempts.  and very little of the changes demonstrate any grasp of graphics, so it's hardly an overhaul -- just based on experience with 65816 asm, and looking for redundancies and other opportunities.

main things changed:
- dropping unnecessary "REP #$20"s and "SEP #$20"s and such.  Eggers tended to put these right after A LOT of labels, almost like he wanted to readily say what the CPU mode would be at key points just to retain his sanity (it's a giant patch, after all), but then never went back to cull them.
- i don't think he was aware of the TSB instruction.
- nor CPY/CPX and BIT.
- weird stuff where he'd do:
1. enter 8-bit A mode
2. do 16- or 32- bits worth of memory storages
3. switch back to 16-bit A mode.
:O
- converting JMPs to BRAs, admittedly some enabled by my previous optimizations shrinking branch distances.
- in no particular category, i did overhaul the "lbg_palette_check_fill_with_ones" loop nicely.

---------------

someone let me know whether that .asm file assembles and runs properly.  if so, does it speed anything up?

the website with the assembler Eggers uses is down, and i'd be too lazy to download and run it anyway.

EDIT: okay, found the author has another website:
http://www.obelisk.me.uk/6502/downloads.html

---------------

what i'm focused on going forward are two things in the section from "lbg_replace_done" to "lbg_done_replacement_colors":

1. as you can see, i'm mulling optimizations from "EOR / STA" to TSB and to TRB.  it looks like i put each of those in the right spot based off his comments, but based on his actual code (there and at "lbg_find_unused_color" and "lbg_find_expanded_color"), i think i've got the instructions switched.  thoughts?

2.

Code:

JMP lbg_find_unused_color_pre        ; Return to the beginning of the loop

i half-think he wanted to do "JMP lbg_find_unused_color" there, based on:
a. the nature of most loops (e.g. not re-initializing an index to its starting value)
b. the way he preserves X right before looping
c. how he never branches to "[label_name]_pre*" -titled labels from below.  they're for loop setups as opposed to loop contents, apparently.

if i'm right, changing this one line could save as much time as my other dozens of optimizations put together!

thus, more scrutiny on "lbg_calculate_replacement_colors" through "lbg_done_replacement_colors" would be much appreciated.