LakeSnes: snes_loadState keeps the old memory access time table (FastROM) #64

Closed
opened 2026-11-06 02:44:17 +00:00 by Gatchan · 0 comments
Owner

snes_loadState restores fastMem (MEMSEL) but not the access time table built by build_accesstime, so a machine loaded from a state runs FastROM code (banks $80+/$C0+) at the speed of its previous history: a fresh core (or the shadow clone, which never ran) runs FF6 at slow-ROM speed after a load.

Found by #37: the clone of a waiting port fell 19 lines behind the original inside BattleNMI and diverged (every btlgfx/WaitVblank call mismatched).

Workaround in core/hw (no LakeSnes patch, no revision bump): hw_sync_memory_speed writes MEMSEL twice after every snes_loadState (hw_state_load, shadow clone) and restores the open bus. Power-on movies are unaffected; timing after a state load is now the original's. An upstream fix would rebuild the table in snes_handleState.

`snes_loadState` restores `fastMem` (MEMSEL) but not the access time table built by `build_accesstime`, so a machine loaded from a state runs FastROM code (banks $80+/$C0+) at the speed of its previous history: a fresh core (or the shadow clone, which never ran) runs FF6 at slow-ROM speed after a load. Found by #37: the clone of a waiting port fell 19 lines behind the original inside BattleNMI and diverged (every btlgfx/WaitVblank call mismatched). Workaround in `core/hw` (no LakeSnes patch, no revision bump): `hw_sync_memory_speed` writes MEMSEL twice after every `snes_loadState` (hw_state_load, shadow clone) and restores the open bus. Power-on movies are unaffected; timing after a state load is now the original's. An upstream fix would rebuild the table in `snes_handleState`.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Gatchan/FF6Portage#64
No description provided.