Save states on ST-V were broken on master: a loaded state, a run-ahead rewind or a netplay resync did not continue the emulation the same way. Model 2 was almost right (hpyagu98 differed after a rewind). Core: - SH-2: each CPU registers its own state (both used to register the boot buffer), and the rest of the CPU is saved: delay slot, divider, interrupt queue and lines, on-chip registers, FRT, DMA timers. - Memory banks are registered after the driver init, where the drivers point them (ST-V work RAM was saved from the wrong buffer). - cpu_spinuntil_time / cpu_yielduntil_time trigger counters are saved. - The crosshair idle timer is saved (the crosshair hid at another frame after a load or a rewind). ST-V: - SMPC, SCU registers and interrupts, SCU DSP, I/O, sound CPU control, CD block scalars, VDP1 clipping, CRTC line counter are saved. - The RTC starts from the host date and time at boot and then follows the emulated time (it read the host clock at every query, so two runs from the same state could read different times). SH-2 recompiler: the polling loop skip counted a whole chain of blocks that came back to the loop start as one loop iteration, skipping the writes and calls in between. It now only skips when the block ran one turn of the loop. Results with a warm or a cold block cache are now the same. Model 2: the polygon count of the last display list is saved. SCSP (issue #2194, regression of #2198): a key off on a slot that had already stopped (a one-shot sample past its end) left its envelope at the level it stopped at, because a stopped slot no longer updates it. The monitor register (0x408) then showed the slot as still sounding, the sound drivers took it for busy and, after a while, put every new note on the one slot left. Cotton Boomerang lost all but the drums at the first boss, Winter Heat's voices cut each other from the first attract demo on. Such a slot now ends its release at once. Claude-Session: https://claude.ai/code/session_013Vje3pEtpLHubqCGwCgoQX Co-authored-by: Claude Opus 5.5 <[email protected]>
What is MAME 2003-Plus?
MAME 2003-Plus (also referred to as MAME 2003+ and mame2003-plus) is a libretro arcade system emulator core with an emphasis on high performance and broad compatibility with mobile devices, single board computers, embedded systems, and similar platforms.
In order to take advantage of the performance and lower hardware requirements of an earlier MAME architecture, MAME 2003-Plus began with the MAME 2003 codebase which is itself derived from xmame 0.78. Upon that base, MAME 2003-Plus contributors have backported support for an additional 350 games, as well as other functionality not originally present in the underlying codebase.
What games are supported?
View our live compatibility table built using datmagic, a tool created by the MAME 2003-Plus team. Datmagic auto-generates a compatibility table based on the latest XML DAT file. See an incorrect entry? Create a new issue to let us know! This allows us to keep the compatibility table as accurate as possible by fixing it at the source.
Authors: MAMEdev, MAME 2003-Plus team, et al (see LICENSE.md and CHANGELOG.md)
Documentation
User documentation for MAME 2003-Plus can be found in the libretro core documentation library.
Developer documentation can be found in the MAME 2003-Plus wiki.
Development chat
#programming channel of the libretro discord chat server.
Romsets and how to build them for this core
mame2003-plus was originally built from the MAME 0.78 codebase, meaning that 95% or more of MAME 0.78 romsets will work as-is in mame2003-plus, where they immediately benefit from its bugfixes and other improvements. In order to play the new games and games which received ROM updates in mame2003-plus, you will need to find or build the correct romsets.
Read more about rebuilding romsets in the libretro core documentation for mame2003-plus.