Allow branches to take full addresses

[MarioFanGamer]

That one is a more situational suggestion, being only useful for hijacks, but still proves to be useful in my eyes.

The idea is that for hijacks, you sometimes want to skip certain code. The most sane method would be this in my eyes:

org $00802A
BRA $008041

However, Asar will only take the last byte and treat it as a BRA $41 instead of BRA $17 as one would like. You can work around this limit with either

BraDestination = $008041

org $00802A
BRA BraDestination

or

org $00802A
BRA BraDestination 

org $008041
BraDestination:

but both of them clutter the code a little bit.

Obviously, this works the best if this syntactic sugar only supports the whole address with the bank and not just a 16-bit value to avoid confusion with BRL which does take a 16-bit parameter and instead throw an error if someone attempts to put a 16-bit value for any other branch.

[RPGHacker]

I think it's a reasonable suggestion, as long as we can make it work reliably, without any ambiguity and without breaking compatibility. The latter aspect is what has me slightly worried, since I could totally see some people using math on a BRA, which with this change Asar might misinterpret as an absolute rather than a relative address.

I don't know how likely that is, but if we can implement this without any compatibility issues, I think it'd be useful enough to have.

[randomdude999]

i added BRA.a and BRA.r (which also work on all other branch instructions) which allow specifying whether the given number is an absolute target or a relative jump distance. in your example you can now do org $00802a : bra.a $008041, which assembles to 80 15. i think this is a nice compromise, and it doesn't make the syntax more ambiguous at least.

[Alcaro]

counterproposal:

bra $00f606 - subtracts pc bra #$01 - emits 80 01

don't know which is better, but it's worth considering

[RPGHacker]

I kinda prefer the #$01 suggestion from a usability perspective (feels consistent with other opcodes, where # refers to a constant), but prefer the bra.a suggestion from a backwards compatibility perspective, since it's just an extension rather than a behavioral change.

Of course we could throw deprecation warnings in Asar 1.x and introduce solution 1 in Asar 2.0, though I'm not quite sure how. Just throw warnings on every single use of "bra [number]"?