Mesen - NES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

NewRisingSun
Posts: 1068
Joined: Thu May 19, 2005 11:30 am

Re: Mesen - NES Emulator

Post by NewRisingSun » Tue Jul 03, 2018 9:42 am

Of course it's not relevant for emulation, unless you are dealing with a ROM that should be mapper 206.

My interest is purely in having unambiguous NES headers. Given that iNES and NES 2.0 do not explicitly denote mapper-controlled mirroring, what should the mirroring bit be for those games? I don't like "Whatever, doesn't matter", because it means that the same game can have two different headers that are both correct.

I can live with either "Mapper-controlled mirroring means that Mirroring is not fixed to Vertical, so the bit must be zero" or "The mirroring bit should reflect the initial state of the mapper-controlled mirroring"; just pick one and make it official.

lidnariq
Posts: 8792
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Mesen - NES Emulator

Post by lidnariq » Tue Jul 03, 2018 9:53 am

I would personally prefer the former.

Obviously there's a small fear that somewhere some hardware could possibly exist where manufacturers made two different otherwise-identical bits ICs that differ only in their mirroring powerup state and people released games that depend on this difference, but ... like I said, I really want to believe we won't find that.
Last edited by lidnariq on Tue Jul 03, 2018 11:37 pm, edited 1 time in total.

Sour
Posts: 739
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour » Tue Jul 03, 2018 6:57 pm

Forcing the value to be 0 for mapper-controlled hardware in NES 2.0 sounds fine to me. At the very least, it imposes a single valid header for each game and seems better than forcing a default that might be incorrect.

User avatar
GradualGames
Posts: 1107
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Re: Mesen - NES Emulator

Post by GradualGames » Wed Jul 04, 2018 9:46 am

Sour, does Mesen disallow running a previously recorded movie if the rom for which the movie was recorded has changed? I was able to capture a really rare bug (in my game) with a mesen movie, and I want to play the same movie again with a patch applied. I know Nestopia just pops up a warning when the rom changes; wondering if that's possible with Mesen or not.
Last edited by GradualGames on Wed Jul 04, 2018 9:57 am, edited 2 times in total.

Sour
Posts: 739
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour » Wed Jul 04, 2018 9:54 am

GradualGames wrote:Sour, does Mesen disallow running a previously recorded movie if the rom for which the movie was recorded has changed? I was able to capture a really rare bug (in my game) with a mesen movie, and I want to play the same movie again with a patch applied. I know Nestopia just pops up a warning when the rom changes; wondering if that's possible with Mesen or not.
It's not an option, but it probably should be one :p I added a similar option for save states a little while ago, that option should probably be changed to apply to movies as well as save states.

.mmo files are .zip files - you can edit the GameSettings.txt file inside the .mmo file and replace the SHA1 tag with the SHA1 hash for your new rom file (the entire file, including the header) and it should allow you to run the movie on the new rom.

Edit: If your movie contains a save state (rather than starting at power on), you will probably also need to enable the "Allow save states to be loaded on modified roms" option in Preferences->Save Data
Last edited by Sour on Wed Jul 04, 2018 9:57 am, edited 1 time in total.

User avatar
GradualGames
Posts: 1107
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Re: Mesen - NES Emulator

Post by GradualGames » Wed Jul 04, 2018 9:57 am

Sour wrote:
GradualGames wrote:Sour, does Mesen disallow running a previously recorded movie if the rom for which the movie was recorded has changed? I was able to capture a really rare bug (in my game) with a mesen movie, and I want to play the same movie again with a patch applied. I know Nestopia just pops up a warning when the rom changes; wondering if that's possible with Mesen or not.
It's not an option, but it probably should be one :p I added a similar option for save states a little while ago, that option should probably be changed to apply to movies as well as save states.

.mmo files are .zip files - you can edit the GameSettings.txt file inside the .mmo file and replace the SHA1 tag with the SHA1 hash for your new rom file (the entire file, including the header) and it should allow you to run the movie on the new rom.
Regardless of whether this is possible (looks like it is), I was able to find this rare bug using Mesen's debugger. I'm either going to give you a donation or a free copy of my new game when it's out, your choice. :beer: :beer: :D :D

User avatar
GradualGames
Posts: 1107
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Re: Mesen - NES Emulator

Post by GradualGames » Wed Jul 04, 2018 10:04 am

Sour wrote:
GradualGames wrote:Sour, does Mesen disallow running a previously recorded movie if the rom for which the movie was recorded has changed? I was able to capture a really rare bug (in my game) with a mesen movie, and I want to play the same movie again with a patch applied. I know Nestopia just pops up a warning when the rom changes; wondering if that's possible with Mesen or not.
It's not an option, but it probably should be one :p I added a similar option for save states a little while ago, that option should probably be changed to apply to movies as well as save states.

.mmo files are .zip files - you can edit the GameSettings.txt file inside the .mmo file and replace the SHA1 tag with the SHA1 hash for your new rom file (the entire file, including the header) and it should allow you to run the movie on the new rom.

Edit: If your movie contains a save state (rather than starting at power on), you will probably also need to enable the "Allow save states to be loaded on modified roms" option in Preferences->Save Data
Hmm, tried updating the sha1 hash...changed that setting...still wouldn't play for me.

Sour
Posts: 739
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour » Wed Jul 04, 2018 10:21 am

GradualGames wrote:Hmm, tried updating the sha1 hash...changed that setting...still wouldn't play for me.
I'll have to test/fix this on my end after work, shouldn't be hard.
GradualGames wrote:Regardless of whether this is possible (looks like it is), I was able to find this rare bug using Mesen's debugger. I'm either going to give you a donation or a free copy of my new game when it's out, your choice.
Always nice to hear people are finding Mesen useful! (it justifies the 2-3 thousand hours it took to code it :p)
I'm actually unsure either one of my NES consoles is still in working condition (haven't used them in a good 10+ years I'd say..), though, but I'll take whichever works better for you (and nothing at all is fine, too!)

Sour
Posts: 739
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour » Wed Jul 04, 2018 5:16 pm

I just pushed a small change that should allow your use case to work.
With this change, if the "Allow save states to be loaded on modified roms" is turned on and the currently loaded ROM has the same filename as the rom originally used to record the movie, it will ignore the hash check & playback the movie using the current rom.

An appveyor dev build with the change should show up here in a few minutes: https://ci.appveyor.com/project/Sour/Me ... /artifacts

This is mostly a temporary solution, I'll have to come up with a less cryptic solution (e.g actually adding a UI to start movie playback with an option to use the current rom, regardless of its name or hash, rather than trying to find & load a rom with the correct hash)

User avatar
GradualGames
Posts: 1107
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Re: Mesen - NES Emulator

Post by GradualGames » Thu Jul 05, 2018 10:13 am

Sour wrote:I just pushed a small change that should allow your use case to work.
With this change, if the "Allow save states to be loaded on modified roms" is turned on and the currently loaded ROM has the same filename as the rom originally used to record the movie, it will ignore the hash check & playback the movie using the current rom.

An appveyor dev build with the change should show up here in a few minutes: https://ci.appveyor.com/project/Sour/Me ... /artifacts

This is mostly a temporary solution, I'll have to come up with a less cryptic solution (e.g actually adding a UI to start movie playback with an option to use the current rom, regardless of its name or hash, rather than trying to find & load a rom with the correct hash)
That was fast! Thank you sir. I'll get a chance to try this out in a couple days.

I thought of something today which I might really like. Or, if there are lua scripting hooks for it, that'd be more than enough for me:

I want to launch Mesen with my rom playing and recording a movie with a given name, every time (probably a time stamp as well as the rom name).

There are many times I've noticed something odd happening in my game and I wrote it down in text but wasn't able to get back to it for a few weeks; and when I get back to it, found the bug hard to reproduce. If I had a movie for EVERY emulator session testing my game, then ANY time anything odd happened I could archive a copy of the current rom, git hash, and mesen movie so I could easily go back and reproduce it.

I guess all I'd need to accomplish this is a command line argument to Mesen saying to start recording a movie to a given file right away. Maybe there already is, I'll RTFM after this post. :D

User avatar
NovaSquirrel
Posts: 374
Joined: Fri Feb 27, 2009 2:35 pm
Location: Fort Wayne, Indiana
Contact:

Re: Mesen - NES Emulator

Post by NovaSquirrel » Thu Jul 05, 2018 2:14 pm

GradualGames wrote:If I had a movie for EVERY emulator session testing my game, then ANY time anything odd happened I could archive a copy of the current rom, git hash, and mesen movie so I could easily go back and reproduce it.

I guess all I'd need to accomplish this is a command line argument to Mesen saying to start recording a movie to a given file right away. Maybe there already is, I'll RTFM after this post. :D
Go all the way and have a hotkey that saves the last 30 seconds as a movie, like a game console "share" button. :p
Though, that would require the emulator to be keeping a buffer all the time if that feature is enabled, but it's already going to have to do something similar when rewind is enabled.

I don't know if this has been asked for yet but when I was developing Nova the Squirrel I would have found it helpful to break when attempting to display uninitialized OAM after OAM has been left to decay, but of course then you need to decide on an amount of time to have the "OAM decay" kick in after.

Sour
Posts: 739
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour » Thu Jul 05, 2018 3:25 pm

GradualGames wrote:I want to launch Mesen with my rom playing and recording a movie with a given name, every time (probably a time stamp as well as the rom name).
NovaSquirrel wrote:Go all the way and have a hotkey that saves the last 30 seconds as a movie, like a game console "share" button. :p
My todo list actually has had a "Record movie from rewind data" bullet point in it for the past 1+ year. It's probably not all that hard to implement, either. I'll try to take a look when I get the chance. (There's no way to record a movie from the command line or from Lua at the moment, either)
NovaSquirrel wrote:I would have found it helpful to break when attempting to display uninitialized OAM after OAM has been left to decay, but of course then you need to decide on an amount of time to have the "OAM decay" kick in after.
There is an option to emulate OAM decay in Emulation->Advanced. This option sets OAM bytes to $FF if the byte (or specifically if that particular group of 4 bytes) hasn't been read/written to in over 3000 CPU cycles (~1.7ms), which means the sprites disappear from the screen. I could add an option to break whenever a read to OAM occurs after that 1.7ms delay (it would require enabling the OAM decay feature though)

lidnariq
Posts: 8792
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Mesen - NES Emulator

Post by lidnariq » Thu Jul 05, 2018 3:42 pm

sets OAM bytes to $FF if the byte [...] hasn't been read/written to in over 3000 CPU cycles (~1.7ms), which means the sprites disappear from the screen.
At least for my personal NES, all the bytes seem to decay to $10 instead of $FF, moving them blatantly into the visible portion of the playfield.
Sour wrote:specifically if that particular group of 4 bytes
Should be a group of 8 bytes.

User avatar
NovaSquirrel
Posts: 374
Joined: Fri Feb 27, 2009 2:35 pm
Location: Fort Wayne, Indiana
Contact:

Re: Mesen - NES Emulator

Post by NovaSquirrel » Thu Jul 05, 2018 4:58 pm

lidnariq wrote:At least for my personal NES, all the bytes seem to decay to $10 instead of $FF, moving them blatantly into the visible portion of the playfield.
My own NES puts decayed OAM entries on-screen too, so when I intended to clear OAM (but didn't run OAM DMA at the right time) I had an occasional single frame of glitchy sprites which Mesen wouldn't have helped me find even with that option. That's why I think a notice or break would be good.

Sour
Posts: 739
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour » Fri Jul 06, 2018 3:07 pm

lidnariq wrote:Should be a group of 8 bytes.
Thanks!
Changed this to be based on groups of 8 bytes, and it gets set to $10 instead of $FF, which makes the sprites visible (assuming sprite $10 isn't empty).

Also added a "Break on decayed OAM read" option in the debugger. This option requires the "Enable OAM decay" option to be enabled (otherwise it will be grayed out). Between that and the break on uninit memory option, it should be able to catch most memory initialization issues. Additionally, the sprite viewer now takes into account OAM decay when displaying the sprites (previously it would show the contents of sprite RAM as if it hadn't decayed).

These changes are in my temporary VS Dualsystem branch at the moment, but all of this should get merged to master sometime today or tomorrow.

And I'm starting to feel like I need to add some sort of log that explains why the execution breaks, etc. It's easy to think the debugger is broken when it starts breaking on every other PPU cycle due to OAM decay.

Post Reply