Mesen - Emulator

[Sour]

Would it work if I did something like this?
I'm not familiar with the Mesen source code, so I'm not particularly clear on how to handle the CPU-only "Back-up RAM" (particularly since you can't write to BRAM if $3033.0 is reset), but I've made a stab at it... or does Mesen already handle that somewhere? It doesn't look like it...

It looks like I've somehow forgotten to ever implement this - the flag exists, but does nothing at the moment. I'll try to take a look at this bit soon.

If you need to use both the CPU-only cart ram and GSU+CPU cart ram, you can get the handlers for the CPU-only cart ram via "_console->GetCartridge()->GetSaveRamHandlers()" and use that to map them wherever you want/need. GetSaveRamHandlers should already be the correct size if the header specifies a "regular" save ram size, I think.

This will cause conflicts with the .srm save files though (both rams will try to save to the same file, and only one of them will be saved properly), so the code for this would eventually need to get tweaked for it to work properly.

The mappings you listed would map the first 2mb of rom to gsu+cpu as usual, then 2mb to 4mb would be at 80-BF:8000-FFFF, and the next 4mb would be at C0-FF:0000-FFFF. So that probably sounds correct, depending on what you want.

[93143]

It looks like I've somehow forgotten to ever implement this - the flag exists, but does nothing at the moment. I'll try to take a look at this bit soon.

If you need to use both the CPU-only cart ram and GSU+CPU cart ram, you can get the handlers for the CPU-only cart ram via "_console->GetCartridge()->GetSaveRamHandlers()" and use that to map them wherever you want/need. GetSaveRamHandlers should already be the correct size if the header specifies a "regular" save ram size, I think.

This will cause conflicts with the .srm save files though (both rams will try to save to the same file, and only one of them will be saved properly), so the code for this would eventually need to get tweaked for it to work properly.

Okay, thanks.

You may have to implement separate GPRAM and BRAM anyway if you're revisiting $3033.0, since that flag seems to apply specifically to the latter.

The mappings you listed would map the first 2mb of rom to gsu+cpu as usual, then 2mb to 4mb would be at 80-BF:8000-FFFF, and the next 4mb would be at C0-FF:0000-FFFF. So that probably sounds correct, depending on what you want.

Yes, that's what I want. I'll have to pad the first two segments of the ROM to 2 MB before there's content to fill them, but that's no big deal.

[OmbraRD]

Hi Sour,

I found a couple bugs on the Snes emulation:

1. Crash when clicking on "View in Tile Viewer" from Mode 7 Tilemap Viewer. Ex: Illusion of Gaia. From the main menu go into the tilemap viewer, right click any tile and click on "View in Tile Viewer". The crash only happens if grayscale palette option is not selected.

2. When viewing Mode 7 Tilemap, pausing the execution will garble the output.

[RiddleSnowcraft]

I can't seem to be able to use a controller if SGB/Super Game Boy is selected as a GB model

Additionally I've been testing the dumped roms from "Yu-Gi-Oh Early Days Collection", dunno if the following problems are because these games are technically new (and not meant to be played in an actual gameboy) but thought I'd share anyway:

Both "Yu-Gi-Oh! Duel Monsters II: Dark duel Stories" and "Yu-Gi-Oh! Monster Capsule GB" present garbled text in it's translated versions (text shows up fine in the japanese versions)

[tepples]

Mesen's Super Game Boy support is low-level emulation. Have you configured bindings for the Super NES controller?

[RiddleSnowcraft]

Mesen's Super Game Boy support is low-level emulation. Have you configured bindings for the Super NES controller?

I have now and now it applied to SGB games lmao

Thanks

[yeerk16]

Hi Sour,

Is there a way to use FFI with Mesen's Lua implementation?

I'm trying to get an external speech library working with Mesen:
https://github.com/dkager/tolk
(to vocalize aspects of NES games as they run -- accessibility project I'm working on)

I did enable 'Allow access to I/O and OS functions' in the settings, but still when I do
local ffi = require "ffi"
I get a list of errors that ffi.lua cannot be found.

I did successfully get the library to work using luagit and FFI on Windows, but am not sure what to do to get it to work with Mesen's lua implementation.

Thank you!

[jummiummi]

There seems to be a bug with RTC where it's not properly keeping track of the day. It is most noticeable in the Pokemon games. Although time seems to be being tracked okay, after deleting the .rtc file and both resetting the time via the button combination on the title menu. It will work for a while, but if you are to check after about an hour or so, you will see that the day has changed and will say either "Monday" or "Sunday", i'm not sure, it might pick days sequentially in some way, but that is what i have noticed. I have attached my .srm and .rtc file for Pokemon Crystal. I am using the first revision of the game which has the SHA256 hash of "fdcc3c8c43813cf8731fc037d2a6d191bac75439c34b24ba1c27526e6acdc8a2".

[Sour]

1. Crash when clicking on "View in Tile Viewer" from Mode 7 Tilemap Viewer. Ex: Illusion of Gaia. From the main menu go into the tilemap viewer, right click any tile and click on "View in Tile Viewer". The crash only happens if grayscale palette option is not selected.

Thanks, this crash is fixed. Pausing displaying "garbage" is most likely normal. This is because when you pause, the viewer displays data based on the scanline/cycle at which you pause the emulation - it's likely that the point at which you paused the screen is not in mode 7, etc.

I can't seem to be able to use a controller if SGB/Super Game Boy is selected as a GB model

Like tepples said, when you're playing games in SGB mode, you're actually playing a SNES "game", so you need to configure the SNES controller buttons.
Re: the Yu-Gi-Oh games, I'm not sure, I've never heard of them until now. It's possible that they don't work in accurate emulators? Have you tried any other GB emulator to see if it works? SameBoy is probably the best to compare against. If it works there, then it's probably a bug in my code.

Is there a way to use FFI with Mesen's Lua implementation?

I'm not familiar with this, but as far as I can tell, FFI is a LuaJIT-specific library which is not available in Lua itself. Mesen does not use LuaJIT, it uses Lua 5.4, so it's likely that using FFI might not be possible in Mesen.

There seems to be a bug with RTC where it's not properly keeping track of the day. It is most noticeable in the Pokemon games.

Thanks for the report!
I haven't been able to reproduce the exact problem you mentioned, but I did find and fix a couple of problems with the RTC (one of which was caused by a fix for a RTC-related crash from a couple of months ago). Hopefully this should fix the problems you were getting - please grab the latest build and let me know if it works better on your end.

[jummiummi]

Thanks for the report!
I haven't been able to reproduce the exact problem you mentioned, but I did find and fix a couple of problems with the RTC (one of which was caused by a fix for a RTC-related crash from a couple of months ago). Hopefully this should fix the problems you were getting - please grab the latest build and let me know if it works better on your end.

Thank you for the quick update, Sour! I just updated and so far it seems okay, booted up Pokemon crystal and it seemed to remember that it's still tuesday, i'll check it out later and see if it successfully changes the day as well after midnight. Also, i'm new to Mesen and enjoying it so far, but the built-in updater didn't seem to recognize that there's a new update out, so i had to download it from github and then move my saves and firmware over. Does the updater check only for specific type of updates, stable of sorts?

I also have another issue to report, though i am unsure if this is a byproduct of Mesen's accuracy because all other emulators i've tried show me otherwise. In Grand theft auto advance, it seems like as if the game is running about 30% slower than it should, even though the game is running at full speed, there's no sound stuttering of sorts, and Mesen likewise reports a normal 60 fps. I have tried running the game in Skyemu, Nanoboyadvance and mGBA, and they seem to be running at a more playable speed.

[Sour]

Does the updater check only for specific type of updates, stable of sorts?

The updater is intended for updates that change the version number, but I've been lazy for the past couple of years and haven't released a proper "stable" 2.1 release, so updates need to be done manually at the moment. You should be able to overwrite the previous .exe with the new one without having to manually copy saves/etc. to a new folder.

Re: Grand Theft Auto on GBA, I tried walking around in 2 emulators at once (testing Mesen, mGBA, NanoBoyAdvance and GBAHawk) and looking at which emulator moves faster, and I do see that mGBA is a bit faster, maybe a ~5-10% gap in distance traveled compared to Mesen when pressing the D-pad for the same amount of time). NBA and GBAHawk both seem pretty similar to Mesen (which is what I would expect based off test rom results). Although it does seem like NBA tends to maybe be slightly faster than Mesen, too? I'm sure not - it's hard to judge because the game itself seems to lag based on how many people/cars/etc. are on the screen, so the time it takes to travel back and forth between the same locations seems to vary constantly.

Someone wrote a test rom recently that runs through a bunch of automated scenes and calculates how fast/slow the emulator ran the code compared to real hardware. At the moment, for that specific test, the results are (assuming I calculated this properly):
-mGBA is ~2.7% too fast
-NBA is 0.12% too fast
-GBAHawk is 0.00075% too fast
-Mesen is 0.0006% too slow

These results are only for this specific test rom, but this gives you a rough idea of how timings could also potentially vary in actual games, too.

[jummiummi]

Re: Grand Theft Auto on GBA, I tried walking around in 2 emulators at once (testing Mesen, mGBA, NanoBoyAdvance and GBAHawk) and looking at which emulator moves faster, and I do see that mGBA is a bit faster, maybe a ~5-10% gap in distance traveled compared to Mesen when pressing the D-pad for the same amount of time). NBA and GBAHawk both seem pretty similar to Mesen (which is what I would expect based off test rom results). Although it does seem like NBA tends to maybe be slightly faster than Mesen, too? I'm sure not - it's hard to judge because the game itself seems to lag based on how many people/cars/etc. are on the screen, so the time it takes to travel back and forth between the same locations seems to vary constantly.

Someone wrote a test rom recently that runs through a bunch of automated scenes and calculates how fast/slow the emulator ran the code compared to real hardware. At the moment, for that specific test, the results are (assuming I calculated this properly):
-mGBA is ~2.7% too fast
-NBA is 0.12% too fast
-GBAHawk is 0.00075% too fast
-Mesen is 0.0006% too slow

These results are only for this specific test rom, but this gives you a rough idea of how timings could also potentially vary in actual games, too.

I see, so that means Mesen is emulating the game correctly compared to other emulators if I am reading this correctly, I have underestimated how laggy the game really is because it seems a lot smoother on mGBA in comparison which I believed was on a similar level of accuracy to Mesen.

That's interesting because another really hardware intensive game such as Payback, runs similarly on Mesen as all the other emulators, but that game already naturally is even laggier than GTA Advance even on original hardware, I can only guess, but perhaps Payback is limiting the framerate internally while GTA Advance doesn't. Thank you anyway for looking into it!

[Yave Yu]

I also feel mGBA's CPU emulation is a bit faster than other GBA emulator, I just see some situation in various Pokemon hacks (with BW soundfont, it usually take lots of CPU usage), mGBA is always faster one (less lagging)

[Sour]

I see, so that means Mesen is emulating the game correctly compared to other emulators if I am reading this correctly, I have underestimated how laggy the game really is because it seems a lot smoother on mGBA in comparison which I believed was on a similar level of accuracy to Mesen.

There's a test rom comparison of most common GBA emulators here: https://emulation.gametechwiki.com/index.php/GBA_Tests
Not all of these tests would necessarily affect the emulated game's performance, but a lot of them could to some extent.

For example, alyosha (GBAHawk's author) has done a lot of research on the GBA's "prefetcher" over the past couple of years and has written a lot of test roms to validate some edge cases. Only GBAHawk & Mesen pass all of these prefetcher tests at the moment, and the effect can be non-negligible, depending on how the game's code is written, etc.

So 2 different games that are laggy on GBA might end up running the same in emulators, or faster, depending on what exactly is slowing down the game's code in the first place, etc.

Having noticed how laggy GTA is, I added an overclocking option similar to what's available on the NES & SNES cores - it's in the GBA -> Emulation -> Overclocking. Setting the number of additional scanlines to ~150 seems to remove all the lag (at least in the little section I test on the map) and makes the game run much faster/smoother than before. Setting it anything beyond ~150 doesn't seem to have much of an impact, though.

Advance Wars (USA) (Rev 1).gba
broken black line in window dialog

This is fixed now and matches what a GB Player shows on this screen.
This fix does cause very minor glitches to appear on the left side in Fire Emblem The Sacred Stones' menu, but similar glitches also appear on GB Player.

[jummiummi]

Having noticed how laggy GTA is, I added an overclocking option similar to what's available on the NES & SNES cores - it's in the GBA -> Emulation -> Overclocking. Setting the number of additional scanlines to ~150 seems to remove all the lag (at least in the little section I test on the map) and makes the game run much faster/smoother than before. Setting it anything beyond ~150 doesn't seem to have much of an impact, though.

Thank you for adding a workaround for this, considering this is how the game seems to run on original hardware, i'm grateful you decided you add this feature. Will there be anyway to apply this only to specific games? Chances are that this could break some games if left overclocked, but if not, it's a nice feature anyway.