Alternative Glitch Beam Fix

[aquanight]

An alternative Glitch Beam fix which restores vanilla cursor behavior when moving between boots and beams but prevents simultaneous selection of Spazer+Plasma (and also fixes excess tiles appearing).

Simultaneous press of Left+A from the boots will once more move to and select Plasma but Spazer will now be correctly deselected.

This fix uses no extra space in bank $82 - all changes fit within the space that is replaced or dummied out of the original routines involved.

"What about the VAR thing?"

The appearance of "VAR" was due to a tilemap over-copy due to the boots (suit/misc uses the same tilemap size) code wanting to transfer tiles that are "boots-item" size (8 tiles) despite this being 4 tiles larger than the "beams item" tiles. Thus it grabs 4 extra tiles from "somewhere" (it overruns the PLASMA tilemap at $BF5A by 4 bytes, which means the first 4 tiles for VARIA SUIT) and copies it to the right of the "PLASMA" label.

This patch also corrects the wrong tilemap-size by use of a data table selected during the "button response" function, rather than relying on it being passed in from the "main function" handlers.

An edge case occurs in that if Left+A moves to the reserve tank (from a SUIT or MISC item), a $12 tile copy occurs, but my analysis of the routine is that this is harmless (it seems to result in just copying $12 bytes over themselves starting at $0000), and it would have happened the same way in Vanilla and in the current Glitch Beam patch.

[aquanight]

Further analysis of the reserve tank shows that what happens is that 8 words starting at $7E:0C02 get OR'd with $0C00. The RAM map says this section relates to:
0C02: bomb Y velocity
0C04 .. 0C0C : beam directions (Suggesting a value of 0Cxx will delete the beam)
0C0E, 0C10 : bomb directions

In testing I didn't see any effect on an active beam. Bomb spread... I couldn't see any difference in the bomb movement. I would not be surprised if the relevant parts of vanilla code are AND'ing off the high byte anyway (will need to confirm this).

[blkerby]

So after playing around with this a bit, one thing I'm realizing is that if you're trying to set your reserves to an exact value (e.g. for a g-mode setup), this new approach may interfere a bit. Namely, if you have a beam, a Boots item, but no Suit or Misc, then when pressing down+right to transfer 1 energy, it will go to the Boot, but then pressing left will go to a beam instead of back to Supply. I think this is probably manageable and that getting closer to the vanilla behavior is still overall better; it's just something to keep an eye out for.