mupen64plus-core
mupen64plus-core copied to clipboard
mupen64plus
Fix incorrect maximum ROM size
This allows ROMs larger than 64MiB to work in mupen64plus.
Tested with the following ROMs:
You can find documentation about the console limitations here:
- https://n64brew.dev/wiki/Memory_map
- https://n64brew.dev/wiki/FAQ
Fixes #997 Fixes #1101
This is much better than the previous attempt #685
Looking at your latest modifications, there seems to be a lot more "limits" to change... I can't be of much help in that regard.
Add this ROM to your tests, in my case it always soft freeze (my ParaLLEl RDP/RSP forks are too old =P) on the same part... I don't know if it works with Ares or some other emulator. The ideal would be to test it with EverDrive or something similar.
I would also make sure to check that Paper Mario still works (and that it can save). I remember it did something where it wrote outside the cart address space, but maybe I'm remembering wrong
I would also make sure to check that Paper Mario still works (and that it can save). I remember it did something where it wrote outside the cart address space, but maybe I'm remembering wrong
Just tested, saving works fine.
This is much better than the previous attempt #685
Looking at your latest modifications, there seems to be a lot more "limits" to change... I can't be of much help in that regard. Add this ROM to your tests, in my case it always
soft freeze(my ParaLLEl RDP/RSP forks are too old =P) on the same part... I don't know if it works with Ares or some other emulator. The ideal would be to test it with EverDrive or something similar.
It does work with Angrylion (fine) and Parallel RDP (glitches), but only with Parallel RSP. Other RSP plugins just freeze on boot.
It pass with this build: https://github.com/Rosalie241/RMG/actions/runs/12344405888
But the same build fails with the CI cores: https://github.com/mupen64plus/mupen64plus-core/actions?query=branch%3Afix-romsize
That ROM seems to be extremely sensitive to compiler optimizations...
It pass with this build: https://github.com/Rosalie241/RMG/actions/runs/12344405888
But the same build fails with the CI cores: https://github.com/mupen64plus/mupen64plus-core/actions?query=branch%3Afix-romsize
That ROM seems to be extremely sensitive to compiler optimizations...
It plays back fully for you without issues? on Fedora it hangs eventually for me when built locally sadly, though now that you mention compiler optimizations, I've had issues with that before while working on improving FPU accuracy, which is extremely frustrating.
It plays back fully for you without issues?
Only on Windows and Wine with this configuration...
Thank you, I can confirm it plays fully with paraLLEl RSP and angrylion-rdp-plus on Windows
I can also confirm it works on Linux:
I can also confirm saving in Paper Mario works fine still.
Thanks to the help of @GhostlyDark, we managed to find a solution to the unreliable behavior, it was a mistake I made.
@Jj0YzL5nvJ can you test it again with the latest changes? It works for GhostlyDark and me fine now.
This seems to break loading roms in init_mem_base on a linux aarch64 device with only 2 GB of ram I assume due to MB_MAX_SIZE_FULL being bumped way up
This seems to break loading roms in
init_mem_baseon a linux aarch64 device with only 2 GB of ram I assume due to MB_MAX_SIZE_FULL being bumped way up
Interesting, I suppose I'll add a compile option called ACCURATE_ROM_RANGE so by default mupen64plus-core will still work on low end systems.
I know mupen64plus copies the ROM to RAM, but mapping and reserving the maximum possible ROM size to RAM seems a bit excessive even for machines with more than 8 GiB of RAM. Perhaps it would be better to reserve a cache of 128 MiB and if the ROM really is 4 GiB, copy the rest to that cache as required...
I'll make changes once these changes have been reviewed, because I'm not sure what the best course of action is at the moment, cc @richard42
mapping and reserving the maximum possible ROM size to RAM seems a bit excessive even for machines with more than 8 GiB of RAM
Just because the process asks for 4 GiB of memory doesn't mean that it will suddenly consume that much RAM. Virtual memory is silly like that - modern OSes should assign physical RAM only when the virtual memory actually gets accessed.
That being said this is a concern on 32 bit platforms where you can't just reserve the entire address space worth, or possibly OSes that aren't as smart with their memory management
mapping and reserving the maximum possible ROM size to RAM seems a bit excessive even for machines with more than 8 GiB of RAM
Just because the process asks for 4 GiB of memory doesn't mean that it will suddenly consume that much RAM. Virtual memory is silly like that - modern OSes should assign physical RAM only when the virtual memory actually gets accessed.
That being said this is a concern on 32 bit platforms where you can't just reserve the entire address space worth, or possibly OSes that aren't as smart with their memory management
it wont run without kernel overcommit enabled (default off in kernel iirc)
I've updated the patch to use a separate rom pointer which is dynamically allocated in open_rom, this should solve the memory requirements of lower end systems, the compressed memory is also smaller now due to that.