diff options
| author | Miquel Sabaté Solà <mssola@mssola.com> | 2026-02-05 18:48:04 +0100 |
|---|---|---|
| committer | Miquel Sabaté Solà <mssola@mssola.com> | 2026-02-05 18:48:04 +0100 |
| commit | d36e0de313aa65192eba108dd75135991a42685e (patch) | |
| tree | 2771ba0b181725682e3ac25ab5c88cf91de85e73 /tests/variable_names.s | |
| parent | d57b99e3970fbf51ed4a77031ebcbab977b17e08 (diff) | |
| download | tools.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 'tests/variable_names.s')
0 files changed, 0 insertions, 0 deletions
