Skip to content

Support M64 extended format version 4 (Mupen 1.5.0-3) - #76

Open
frKieran wants to merge 1 commit into
FramePerfection:Developmentfrom
frKieran:fix/m64-extended-v4
Open

frKieran wants to merge 1 commit into
FramePerfection:Developmentfrom
frKieran:fix/m64-extended-v4

Conversation

@frKieran

@frKieran frKieran commented Oct 8, 2026

Copy link
Copy Markdown

Fixes #66.

Movies recorded on Mupen 1.5.0-3 can't be opened in the M64 tab: it shows "Unhandled exception has occurred… Specified argument was out of the range of valid values." and the movie isn't loaded. Movies with extended version 0 or 1 open fine.

Extended version 4 (1.5.0-3) added two doubles to the extended data, cpu_cf at 0x030 and rcp_lag_factor at 0x038 (CoreVCRExtendedMovieData in Mupen's Core/Types.hpp). M64Header.ToBytes still wrote 0x030..0x0C3 as zero padding, so the roundtrip check at the end of LoadBytes failed as soon as cpu_cf was set (1.0 is f0 3f at 0x036, so every 1.5.0-3 movie).

This PR:

  • reads and writes the two fields (shown under Main as "CPU Counter Factor" and "RCP Lag Factor");
  • writes the bytes M64Header doesn't model (0x01E, 0x040..0x0C3, 0x0EA..0x121) back from the loaded header instead of zeros, so the next extended-format addition doesn't break loading again.

Tested on Windows with a Release build of this branch (and the same change on v0.9.1): a 1.5.0-3 movie, an extended v1 movie and a v0 movie all open, and Save leaves each file byte-identical apart from the VI count ("Max Out VI Count"). Without the change, the 1.5.0-3 movie throws as above.

Related, on the Mupen side: with Mupen's "Extended Movie Format" option off, 1.5.0-3 still writes cpu_cf there, so turning it off doesn't avoid this. PR by Claude Code, take with a grain of salt.

Mupen 1.5.0-3 (extended version 4) stores cpu_cf and rcp_lag_factor as doubles at 0x030 and 0x038. ToBytes wrote
that area as zero padding, so the roundtrip check in LoadBytes threw on every movie recorded with 1.5.0-3.
Read and write both fields, and write back the bytes this class doesn't model from the loaded header instead of
zeros, so later additions to the format don't break loading.

Fixes FramePerfection#66

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@abart27 abart27 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@FramePerfection FramePerfection left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine to me, too.

A quick notice on merging this into Development though:
For fixes like this, it could be better to branch off the Release branch and PR into that one as a "hotfix" - it'll be merged into Development, too, of course, but it's easier to release a new fixed version (0.9.2 in this case) without the other stuff on Development (Wine support things currently, which I may not want to release just yet, because that'd definitely be a 0.10.0, and then there are other things I'd like to get into that, and so on.)

I'll leave this open until tomorrow or so if you want to do that @frKieran .

This branch has not been deployed

No deployments
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.

Update to latest M64 extended format

3 participants