Mesen - NES Emulator
Moderator: Moderators
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Mesen - NES Emulator
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.
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.
Re: Mesen - NES Emulator
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-identicalbits 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.
Obviously there's a small fear that somewhere some hardware could possibly exist where manufacturers made two different otherwise-identical
Last edited by lidnariq on Tue Jul 03, 2018 11:37 pm, edited 1 time in total.
Re: Mesen - NES Emulator
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.
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
Re: Mesen - NES Emulator
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.
Re: Mesen - NES Emulator
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.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.
.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.
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
Re: Mesen - NES Emulator
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.Sour wrote: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.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.
.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.
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
Re: Mesen - NES Emulator
Hmm, tried updating the sha1 hash...changed that setting...still wouldn't play for me.Sour wrote: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.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.
.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
Re: Mesen - NES Emulator
I'll have to test/fix this on my end after work, shouldn't be hard.GradualGames wrote:Hmm, tried updating the sha1 hash...changed that setting...still wouldn't play for me.
Always nice to hear people are finding Mesen useful! (it justifies the 2-3 thousand hours it took to code it :p)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.
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!)
Re: Mesen - NES Emulator
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)
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)
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
Re: Mesen - NES Emulator
That was fast! Thank you sir. I'll get a chance to try this out in a couple days.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)
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.
- NovaSquirrel
- Posts: 483
- Joined: Fri Feb 27, 2009 2:35 pm
- Location: Fort Wayne, Indiana
- Contact:
Re: Mesen - NES Emulator
Go all the way and have a hotkey that saves the last 30 seconds as a movie, like a game console "share" button. :pGradualGames 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.
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.
Re: Mesen - NES Emulator
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).
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:Go all the way and have a hotkey that saves the last 30 seconds as a movie, like a game console "share" button. :p
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)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.
Re: Mesen - NES Emulator
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.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.
Should be a group of 8 bytes.Sour wrote:specifically if that particular group of 4 bytes
- NovaSquirrel
- Posts: 483
- Joined: Fri Feb 27, 2009 2:35 pm
- Location: Fort Wayne, Indiana
- Contact:
Re: Mesen - NES Emulator
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.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.
Re: Mesen - NES Emulator
Thanks!lidnariq wrote:Should be a group of 8 bytes.
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.