to revisit the surprising success of my first Quick fix, because that's less depressing than the second:
a change being mulled is only skipping the relocated code on Quick's final turn.
with a little testing, skipping versus not skipping it on the first Quick turn doesn't seem to change anything. and since its job seems to be keeping the gauge from resetting, just running it once after the second X-Magic turn makes more sense, as there should be no need between those turns. (and i'm not just saying that because it avoids adding more code.)
---------
i had thought that C2/093D would run 4 times: between X-Magic turns on first Quick turn, at end of first Quick turn, between X-Magic turns on second Quick turn, and at end of second Quick turn.
in reality. that last one doesn't happen, because C2/0100 has already detected the end of Quick and nulled $3404 by then. but what does happen instead is that C2/093D runs right after the Quick casting turn.
this shouldn't change the patch, but it's further amusement from how i had no idea what was going on while somehow making a working patch. :P
---------
inspecting Square's code shows the space-consuming Variable $EE usage can be avoided, letting me fit the patch inline:
http://assassin17.brinkster.net/forum-posts/quick-gembox-try-fix1-shrink.asmi don't see any callers looking at $EE results (it's usually just a local scratch variable), so not saving to it should be fine. but that stretch of code is inefficient by Bank C2 standards, almost making me wonder whether Square had something more complex planned there. who knows; pending other Quick remedies, maybe it'll have to be added back.
the new way clobbers Y. but that gets clobbered anyway sometimes by C2/095C, and the recent C2/09D2 call could've put various things in it as well. iow, should be safe.
--------
does one of Leet Sketcher's patches alter Function C2/091F? that seems vaguely familiar -- unless it was just C2/08nn -- but i wouldn't recall where to start looking.
