aboutsummaryrefslogtreecommitdiff
path: root/lib/xixanta/src/lib.rs
diff options
context:
space:
mode:
authorMiquel Sabaté Solà <mssola@mssola.com>2026-02-05 18:48:04 +0100
committerMiquel Sabaté Solà <mssola@mssola.com>2026-02-05 18:48:04 +0100
commitd36e0de313aa65192eba108dd75135991a42685e (patch)
tree2771ba0b181725682e3ac25ab5c88cf91de85e73 /lib/xixanta/src/lib.rs
parentd57b99e3970fbf51ed4a77031ebcbab977b17e08 (diff)
downloadtools.nes-d36e0de313aa65192eba108dd75135991a42685e.tar.gz
tools.nes-d36e0de313aa65192eba108dd75135991a42685e.zip
Fix the arithmetic on indexed addressing modes
In instructions like: lda address + 1, x The assembler was picking the size from the "+ 1" side, making this part of a one-byte size and, hence, assuming it was zeropage indirect addressing instead of an absolute one. This meant that one byte was cut off the end binary, and the address was wrong altogether. Fix this by telling the assembler to assume a .size = 2; for variables which have been defined as addresses. Then, the operation evaluation can take that as an indication to set the size to 2 as well and, hence, assume absolute indirect addressing. Moreover, this bug was intertwined with another one, where arithmetic could be borked when both operands were of an unexpected size. For example: lda #(300 - 260) Here the size would've been resolved to 2 as well, but it would have also reported an error because both operands were 2-bytes long, despite the end result fitting on a single byte. Since this is an explicit immediate addressing, then it would have assumed the programmer to try that with a 16-bit value, which is wrong. This commit also fixes this bug as it was deeply intertwined to how numbers are computed on operations and how sizes are evaluated. Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
Diffstat (limited to 'lib/xixanta/src/lib.rs')
0 files changed, 0 insertions, 0 deletions