fix(memory): return the Game Pak address pattern beyond the ROM chip
CPU and DMA reads past the supplied image returned Unmapped and stopped the machine; a second game's boot code reads 0x09fe20f8 past a 16 MiB image. The Game Pak shares data lines with the low address lines, so where no chip drives the bus a read returns the halfword address, (A >> 1) & 0xffff, per lane (GBATEK; mGBA uses the same pattern). The chip is the image size rounded up to a power of two. Bytes between a trimmed image's end and that boundary are unknown and stay diagnostic, as do host reads and instruction fetches. Two truncation fixtures move into that gap. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HhfHfHEuzv2AUTd6erW1gU
This commit is contained in:
parent
32eaffa0fe
commit
4e4dde742d
11 changed files with 120 additions and 11 deletions
|
|
@ -92,7 +92,8 @@ a deliberate policy decision against the explicit-error convention. See
|
|||
[the usability roadmap](../usability-roadmap.md) for sequencing.
|
||||
|
||||
Update: emulated writes to the `0x08`–`0x0c` ROM windows are now ignored, which removes the
|
||||
`0x09fe2ffe` store diagnostic. Reads past the end of the image remain explicit errors.
|
||||
`0x09fe2ffe` store diagnostic. CPU reads beyond the 16 MiB chip, such as `0x09fe20f8`, now return the
|
||||
Game Pak halfword-address pattern instead of faulting.
|
||||
|
||||
## References
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue