Expanded palette hack

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?

did so.  my TSB and TRB were in the right place, because Eggers' comments were correct.  (weird how i'd been reasonably confident otherwise.  and i'm not talking about those coding sessions where i've been up too long and the brain is running on fumes; it's a given that those produce failure often.  i mean where i'm plenty alert, looking right at the code, and somehow conclude the wrong thing.  [see also: two drafts of my bit reversal optimization, where i stored results to the wrong bytes.])

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.

yeah, i've since gotten confident enough to incorporate this one.  though instead of a jump to "lbg_find_unused_color" , i added a new label shortly after that to avoid a pointless read.

note that this 2nd optimization switches the order of the blocks discussed in #1, for space/speed reasons -- not because anything was wrong with them.

i'm considering further optimizing this section by also picking up where we left off in the inner, "lbg_find_expanded_color_pre" loop.  probably by writing X to Variable $10, which is temporarily free.  admittedly, there's less urgency to this tweak, because expanded palettes have at most 4 slots that are pointlessly repeated currently, versus up to 12 for the non-expanded ones.

both the existing optimization and the considered one work on the knowledge that:
- unused main palette entries and used expanded ones are each claimed first-come, first-serve, in ascending order.
- code can mark main entries as used and expanded as unused, but never the reverse.  so lower-numbered entries won't suddenly become candidates for a switch midway through.

the two combined mean that if we're replacing Expanded Palette M with Main Palette N, we'll never need to go back and look at Expanded < M or Main < N.

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

probably an overstatement, in retrospect, but it should still be a significant help.