It is currently Tue Oct 16, 2018 5:32 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 580 posts ]  Go to page Previous  1 ... 25, 26, 27, 28, 29, 30, 31 ... 39  Next
Author Message
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue Jul 03, 2018 9:42 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 672
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue Jul 03, 2018 9:53 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7648
Location: Seattle
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.

Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue Jul 03, 2018 6:57 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 523
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Jul 04, 2018 9:46 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
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.

Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Jul 04, 2018 9:54 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 523
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.

Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Jul 04, 2018 9:57 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
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


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Jul 04, 2018 10:04 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Jul 04, 2018 10:21 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 523
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!)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Jul 04, 2018 5:16 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 523
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)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Jul 05, 2018 10:13 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
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


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Jul 05, 2018 2:14 pm 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 294
Location: Fort Wayne, Indiana
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Jul 05, 2018 3:25 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 523
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)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Jul 05, 2018 3:42 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7648
Location: Seattle
Quote:
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Jul 05, 2018 4:58 pm 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 294
Location: Fort Wayne, Indiana
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Fri Jul 06, 2018 3:07 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 523
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 580 posts ]  Go to page Previous  1 ... 25, 26, 27, 28, 29, 30, 31 ... 39  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group