Skip to content

Fix load16bit boundary check when reading across RAM/mapper boundary#554

Merged
bfirsh merged 1 commit intomainfrom
bfirsh/fix-load16bit-boundary
Feb 15, 2026
Merged

Fix load16bit boundary check when reading across RAM/mapper boundary#554
bfirsh merged 1 commit intomainfrom
bfirsh/fix-load16bit-boundary

Conversation

@bfirsh
Copy link
Owner

@bfirsh bfirsh commented Feb 15, 2026

Summary

  • Fix off-by-one boundary check in load16bit() that caused incorrect behavior when reading 16-bit values across the RAM/mapper boundary at $2000
  • Both low byte in RAM ($1FFF) and high byte in PPU register space ($2000) are now correctly routed through loadDirect()
  • Fix identical boundary bug in JMP indirect (case 12) addressing mode by using load() for proper PPU register handling

Testing

  • All 445 tests pass (0 failures)
  • No performance regression (1807 fps baseline maintained)

Fixes #285

The load16bit method had an off-by-one boundary check (addr < 0x1fff instead
of addr < 0x2000) that caused incorrect behavior when reading a 16-bit value
where the low byte is in RAM ($1FFF) and the high byte is in PPU register space
($2000). Also fix the same bug in JMP indirect (case 12) addressing mode.

Both are now fixed by routing each byte through load(), which correctly handles
RAM, PPU registers, APU, and cartridge addresses.

Fixes #285

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
@bfirsh bfirsh force-pushed the bfirsh/fix-load16bit-boundary branch from f15dc12 to 67ff70c Compare February 15, 2026 00:05
@bfirsh bfirsh merged commit 5f98035 into main Feb 15, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

load16bit implement

1 participant