Change in behaviour for jr @+constant

[mattcurrie]

Source:

    jr @+$50

In 0.3.5 this is assembled as these bytes:

    $18 $4E

In 0.3.6 this is assembled as these bytes:

    $18 $4F

Is this an intentional change? I'm guessing its related to the "Allow JR between sections." change in 0.3.6.

[AntonioND]

No, that's not intentional.

[Sanqui]

Anecdotally, I also noticed that jr @ no longer caused the game to freeze.

[AntonioND]

What game?

[Sanqui]

I was testing while writing homebrew. I thought it was my fault though and it wasn't critical so I just ignored it.

[AntonioND]

This is actually quite bad, it doesn't even work with constants. It only works when the result has to be calculated by the linker (labels, for example). In short, it works pretty much always, except when using @ or numeric constants.

I'll fix it and add it to the release notes of 0.3.6. I don't think that many people will be affected, though.

[mattcurrie]

Thanks Antonio.

In my disassembler I generate these type of instructions when there is a jr to an address that was not disassembled as the start address of an instruction (so there isn't a label to jump to). I believe this is nearly always due to it disassembling some data bytes as code.

[AntonioND]

I've found a problem when fixing this.

ld bc,@
jp @
jr @

dw @

I can only fix one of the 2 groups with the current code, so I'll have to do some more serious modifications to it...

[obskyr]

Perhaps while you're fixing this, you can allow jr to function with absolute addresses too?

While disassembling, I frequently find myself wanting to write placeholders like jr $0350, but that's currently not allowed. Instead of special-casing jr @+[...], how about simply having @+[...] expand to an absolute address and have jr handle those too?

[AntonioND]

rgbasm doesn't evaluate @, it passes the reference to rgblink, and that's the one that actually evaluates it.

The problem is that @ is evaluated at the position of the patch. For a DW, the position is the same place where @ was in the source code. For any instruction, the @ has to evaluate to the byte of the instruction, but it evaluates to the position of the offset byte (or the immediate). That's why it is off by one, and why it only happens with @, while labels still work.

The crash with constants is another issue, and that is easy to fix.

[AntonioND]

I've created a pull request that should take care of both problems.