Mesen - NES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - NES Emulator

Post by lidnariq »

Fiskbit wrote:Since there are 3 dots per CPU cycle, I think this is specifically about the alignment of whole dots and whole cycles (which dot a CPU cycle begins on), rather than which of 4 positions within a dot a CPU cycle begins on.
Last night I was digging around old posts and found some tests done by ulfalizer and blargg about this-

https://forums.nesdev.com/viewtopic.php?f=3&t=10029

https://wiki.nesdev.com/w/index.php/Use ... ing_charts
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

Thanks! The breakpoint crash should be fixed. As far as I can tell, it looks like it's been this way for over half a year or so, so I'm surprised it's never been reported before (although I guess it's hard to report since your breakpoints are lost by the crash). It occurred when mixing breakpoints with conditions and breakpoints without conditions for the same type of breakpoint (e.g write breakpoints in this case)

The add breakpoint option for the nametable viewer now correctly sets the address value in the popup and I also added an option for adding a breakpoint on the attribute byte (along with a matching shortcut configuration).

There's no way to see mapper-related config at the moment (although from Lua you can check the current memory mappings, e.g what's displayed at the bottom of the debugger window). It might be feasible to add mapper-specific information, e.g for the most common mappers, but there's no (easy) way to do this for all mappers (if only C++ supported reflection...).

A good way to track down something like this might be by using the trace logger's conditional logging option to log only writes to the registers that you suspect is causing the issue (e.g "IsWrite && Address == $8000"), that should make it fairly obvious where/when the write occurs.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Sour, great to see and benefit greatly from your continued success with Mesen! :D


There is this one miniscule visual Mesen change you may make. My suggestion ('*' represents dark pixels, ' ' represents transparent pixels):

The second controller in the debugger's Input Button Setup section is labeled

Code: Select all

***
  *
 * 
*  
***
^that looks like a Z to me; how about:

Code: Select all

** 
  *
 * 
*  
***
? :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Sour, in Mesen's debugger there is a checkmark box next to NMI on vBlank in the "Control & Mask" section. If that box is checked does that cause NMIs to occur regardless of the value of the Interrupt Disable flag? While debugging, and while that flag was set, my vblank function was processed all of a sudden. The screen is drawn incorrectly and think this vblank running while it isn't supposed to run is the cause. (I remember checking that box after seeing that it was checked on your mesen.ca site. And I couldn't find a page describing the "Control & Mask" section.)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

NM, YOU HAVE ALREADY FIXED THIS BUG REPORTED BELOW; THANK YOU! :D I WASTED MORE SPACE IN YOUR THREAD :(
Sour, there's a weird bug in Mesen's information overlay within its Nametable Viewer inside the PPU Viewer. If you set the PPU Viewer to "Normal View" and move your mouse down over the top of Nametable 2, and then move it up to Location (x, 29) of Nametable 0, and then move back to Nametable 2's Location (x, 0)... the Location numbers are always correct in the right side section that is viewable during "Normal View"; but, within information overlay, those Location y values are sometimes really incorrect (i.e. Nametable 2's Location (x, 0) may be shown unchanged (x, 29)) or, when moving back and forth between the lowest, relative to the screen, two Nametable 0 tiles or the highest two Nametable 2 tiles, those tiles' y values are swapped (like tile (x,0) of Nametable 2 is shown as tile (x,1)).

Hope that was written clearly. :) Note: I'm using Mesen Version: DevWin-0.9.7.64; it was released on 1/20/2019 and after reviewing relevant posts in this thread it doesn't seem like this has been addressed. I'm in the middle of a debug and so I don't want to try this with the newest Mesen right now.


EDIT.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

unregistered wrote:If that box is checked does that cause NMIs to occur regardless of the value of the Interrupt Disable flag?
That box (along with every other box in that section) is one of the PPU's flag set through one of the registers. When enabled, the PPU will trigger an NMI on scanline 241. NMIs are always processed by the CPU, regardless of the I flag.

RE: The controller number, I'll take a look when I have some time, if it looks better/more readable, I'll change it.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Sour wrote:
unregistered wrote:If that box is checked does that cause NMIs to occur regardless of the value of the Interrupt Disable flag?
That box (along with every other box in that section) is one of the PPU's flag set through one of the registers. When enabled, the PPU will trigger an NMI on scanline 241. NMIs are always processed by the CPU, regardless of the I flag.
Thank you! So the I flag disables NMIs on scanline 241... but everywhere else NMIs can occur? It is called the Interrupt disable flag, at least in the MOS Technology manual's appendices, for some reason, I bet. :) Would unchecking that box restore the I flags usefulness? I will visit nesdev's wiki.

edit: ooh, it's set with one of the registers... END EDIT

edit2: ahhh <-wiki | So I need to clear bit7 of $2000. Thank you Sour for your generous help! :D ... END EDIT2
Sour wrote:RE: The controller number, I'll take a look when I have some time, if it looks better/more readable, I'll change it.
Cool! :D That's just an idea... will be ok if you don't change it. :)
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Mesen - NES Emulator

Post by koitsu »

To clarify what Sour was saying (because your response is a bit confusing):

The 6502's i flag (controlled with instructions like sei/cli or plp) does not affect NMI. NMI stands for "non-maskable interrupt", which in this case means it's an externally-generated hardware interrupt. The i bit can only be used to inhibit what's coming on the IRQ line/wire. (You should be familiar with this from the fact that the 6502 provides an NMI vector as well as an IRQ/BRK vector. If you want to know more about the later, just ask.)

Don't confuse IRQ and NMI. They're separate things (physically separate pins on the 6502 CPU, thus physically separate traces/wires). The confusion lies in the fact that both are types of interrupts. :-)

Like many video games systems, the NES ties/wires PPU VBlank to NMI, and provides an MMIO register to control that behaviour: bit 7 of $2000. It sounds like what Mesen is showing you in the info box is just whether or not bit 7 of $2000 is set or not.

Mesen generates an NMI when the emulator reaches/hits scanline 241 (which is when VBlank starts on the NES; see PPU rendering).

If you're programming on the NES or trying to figure it out: be aware that if you write to $2000, you are also affecting some very critical internal PPU addressing bits (particularly through bits 1 and 0 of $2000), which can affect scrolling, despite not being immediately obvious. That brings into focus this document which will cause you to pull your hair out in confusion. :)

(Related-yet-not: the one thing I've seen several emulators offer, which I've never understood the purpose of, is what Mesen has under Debug -> PPU Viewer -> When emulation is running, show PPU data at scanline X and cycle Y where you can select X and Y yourself, defaulting to 241 and 0. I don't know what "show PPU data" means in this context. FCEUX has something under Debug -> PPU Viewer called Display on scanline: X where X defaults to 0. It also has the same thing under Name Table Viewer.)
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

koitsu wrote:(Related-yet-not: the one thing I've seen several emulators offer, which I've never understood the purpose of, is what Mesen has under Debug -> PPU Viewer -> When emulation is running, show PPU data at scanline X and cycle Y where you can select X and Y yourself, defaulting to 241 and 0. I don't know what "show PPU data" means in this context.
This specifies when the PPU viewer is updated when the emulator is running - so by default it shows you the state of the nametables at cycle 0, scanline 241. For SMB3, for example, this shows you the status bar correctly, but the screen is garbage. If you set it to scanline ~180, the screen will be visible, but the status bar will be garbage. The cycle setting is less useful, but can be used in stuff like punch out which switches the CHR banks once or twice per scanline (iirc?)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

koitsu wrote:To clarify what Sour was saying (because your response is a bit confusing):

The 6502's i flag (controlled with instructions like sei/cli or plp) does not affect NMI. NMI stands for "non-maskable interrupt", which in this case means it's an externally-generated hardware interrupt. The i bit can only be used to inhibit what's coming on the IRQ line/wire. (You should be familiar with this from the fact that the 6502 provides an NMI vector as well as an IRQ/BRK vector. If you want to know more about the later, just ask.)

Don't confuse IRQ and NMI. They're separate things (physically separate pins on the 6502 CPU, thus physically separate traces/wires). The confusion lies in the fact that both are types of interrupts. :-)
Thank you. Yes, I was confused but reading the wiki page section that I linked to cleared the two types of interrupts confusion that I was experiencing.
koitsu wrote:Like many video games systems, the NES ties/wires PPU VBlank to NMI, and provides an MMIO register to control that behaviour: bit 7 of $2000. It sounds like what Mesen is showing you in the info box is just whether or not bit 7 of $2000 is set or not.
I meant to say that what Mesen is showing me in the info box just really made sense to me after I reread Sour's reply, by my first edit:
unregistered wrote:edit: ooh, it's set with one of the registers... END EDIT
I need to work on my clarity.
koitsu wrote:Mesen generates an NMI when the emulator reaches/hits scanline 241 (which is when VBlank starts on the NES; see PPU rendering).

If you're programming on the NES or trying to figure it out: be aware that if you write to $2000, you are also affecting some very critical internal PPU addressing bits (particularly through bits 1 and 0 of $2000), which can affect scrolling, despite not being immediately obvious. That brings into focus this document which will cause you to pull your hair out in confusion. :)
Yes, the wiki was written differently, or at least that page looks different now, and I spent a very long time getting scrolling to work in our game. But, that process was possible for me partly because of tepples' crucial visible_left/valid_left post at the very bottom of page 69 of my lengthy thread. And partly because of tokumaru's you-should-have-a-camera response-motif. Kasumi helped so much too! :) Our game only scrolls horrizontally so it wasn't insane like most of the page you linked to describes. :)

I hadn't worked on disabling NMIs in a long time and so I was really confused. But, Sour's and your response, Koitsu, have eased me back into understanding what needs to be done. Thank you both so much! :D
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Mesen - NES Emulator

Post by koitsu »

Sour wrote:This specifies when the PPU viewer is updated when the emulator is running - so by default it shows you the state of the nametables at cycle 0, scanline 241. For SMB3, for example, this shows you the status bar correctly, but the screen is garbage. If you set it to scanline ~180, the screen will be visible, but the status bar will be garbage. The cycle setting is less useful, but can be used in stuff like punch out which switches the CHR banks once or twice per scanline (iirc?)
Ah ha! Makes sense. I knew on a general level "what" the options were referring to, but "show PPU data at scanline" made me think "...what PPU data? What is it showing at a scanline or cycle point? A snake?" LOL :D Thank you!
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Mesen - NES Emulator

Post by tokumaru »

Instead of "show PPU data at" you could say "sample PPU state at" or something, but I'm not sure that's any clearer.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Sour, after some quick forum searching I think this hasn't been discussed... on my Mesen DevWin-0.9.7.97 debugging screen there are sometimes many "sub start" lines in the middle of some of the functions. (I think the purpose of "sub start" is to help me to know where unlabeled functions start.) And it seems to me this problem has occurred bc of my moving functions around/adding or subtracting bytes/inserting new code/rewriting parts of old code... however, I am continuing to fail to find a way to reset the "sub start" labels. Can you please teach me how to clean the pointless "sub start"s away? :)
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

The information about function start points is stored in the CDL file that it saves in the Debugger subfolder.
You can reset it in Tools->Code/Data Logger or by deleting the CDL file (note that this will make the disassembly lose track of which parts of the ROM is code vs data (until those parts of the rom are run again), but that's probably a good thing if you've changed the code a lot.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: Mesen - NES Emulator

Post by Banshaku »

I didn't use the recent build since I use the current version daily on linux but is the latest build version usable in that environment? When should we expect 0.98? ;)
Post Reply