Mesen - NES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

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

Re: Mesen - NES Emulator

Post by Sour »

unregistered wrote:p.s. Sour, is controller 1's input displayed on screen directly affected by values read from $4016? I doubt it is, but if it is that would make sense and provide less $4016 checking for me in the future. :)
The overlay shows the state of the controller when the input was polled by the emulator (on scanline 241) - it will update itself regardless of whether or not you read $4016, though.

And your issue is caused by the fact you're (I'm assuming) using a DirectInput gamepad. When the game is reset, Mesen tries to find new gamepads, and since the DirectInput API is pretty horrible (or because I don't know it in depth, either of these!), it has to "guess" what the default state for the gamepad is, and since you're holding down a button, it assumes that that's the default state for that button. Just tested on a 8bitdo SNES controller and I have the same issue. I can probably fix it, though. But for the record, this shouldn't happen with the keyboard or XInput devices (e.g xbox controllers)
Skadiet wrote:However, the NES appears to have used the attributes from $23C0 when it displayed the nametable data in $2400.
The nametable RAM should be somewhat random on power on, but it will keep those values between resets. Were you testing from a power on each time? Either case, though, it's likely to just be a coincidence.. there's no reason parts of $2000 would be automatically copied to $2400 (unless the mirroring isn't wired up properly, for example)

Like gauauu said, keeping on all the options for randomized state/ram/oam decay should help you avoid initialization-related issues on hardware, though.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Sour, glad you discovered the exact problem :D ...thought this didn't happen in a past Mesen, but just attempted with every old Mesen I have and the "problem" has always existed, but you know that (I didn't). :)

edit: It would have been much better if I hadn't asserted you know about that "problem" always existing... Mesen is so complex to imagine, for me at least, and bugs can go unnoticed for a long time. I'm sorry about my assertation Sour. :(
Last edited by unregistered on Fri Jan 18, 2019 5:12 pm, edited 1 time in total.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

Maybe you could copy whatever state the buttons are initialized too to the "nes"... then just invert the relevant initial state when detecting a button change... :?: :)
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

Fiskbit wrote:I've been using Mesen for my development more lately and have been keeping a list of issues and wants as I encounter them.
[...]
Some more additions:
-Nametable/Sprites viewers now have a "selected tile" overlay like the CHR viewer (along with a new overlay displaying information about the tile, similar to what is shown on the right - this is mostly meant for the new "compact" view for the PPU windows)
-Added a "Display outline around all sprites in preview" option to the sprite viewer
-Added a number of new flags/values that can be used in the watch/breakpoints: PreviousOpPc, Sprite0Hit, SpriteOverflow, VerticalBlank, Branched
These should let you do most of the things you were asked for. e.g to break on a sprite 0 hit, you can create a CPU breakpoint on "any address" and set "sprite0hit" as its condition (you'll need to disable the breakpoint after it first hits, otherwise it'll keep hitting on every instruction until the end of the frame, though)
PreviousOpPc is the value of the previous instruction's PC
Branched is true when the current instruction was reached by a branch (jmp, bpl, jsr, etc.)

This isn't as simple as a "Break on Sprite 0 Hit" option in the debugger, but the "Break on ..." is starting to be rather long, so I'm trying to avoid adding every single option possible under there, if possible.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

unregistered wrote:Sour, glad you discovered the exact problem :D ...thought this didn't happen in a past Mesen, but just attempted with every old Mesen I have and the "problem" has always existed, but you know that (I didn't). :)

edit: It would have been much better if I hadn't asserted you know about that "problem" always existing... Mesen is so complex to imagine, for me at least, and bugs can go unnoticed for a long time. I'm sorry about my assertation Sour. :(
This should be fixed in the latest appveyor build, I've tweaked a number of things with the directinput logic to fix this issue (and hopefully another issue that had been posted on GitHub)

And no need to apologize! (I hadn't even noticed your edit until now..)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Mesen - NES Emulator

Post by unregistered »

^Thank you so much Sour! This works extremely great now! I'm so happy! :D
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

In the current build, I notice when I'm in a procedure (foo) all the local branch and jump instructions end up changing the address into the procedure name with an offset (foo + 85). This makes it kind of impossible to understand where the branch is going to go to. I can't really count 85 bytes into a function to figure that out.

I guess these should show an address if they don't point to an actual label.

I am guessing this is an accident from trying to show +1 etc. for multibyte variable/array access, though maybe it would be nice if there was an option to always append the target address (for all instructions, not just JMP/Bxx) when a label has replaced it, maybe in a similar apperance to how calculated address already show for indexed instructions.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

That's odd - is this a CA65 project? It looks like the label for the function was incorrectly imported as a multi-byte label when it shouldn't have. Looking at my usual CA65 project, it looks like this sometimes does occur, not quite sure why/when at first glance - will have to check when I have a chance.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

It should be fixed as of the latest commit - looks like the ".scope" and ".proc" statements were throwing off the logic I was using and ended up creating massive multi-byte labels for the entire block (which could end up overwriting all the other labels contained inside of it, etc.)

Let me know if you're still getting the problem on your end.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

Looks like it's fixed, thanks!

Noticing a lot of the ones that were a problem were CC65 generated labels (i.e. L###) that were masked by the offset label that was replacing them. I dunno if it was just from C generated code, or if all .proc was subject to this problem. Oh well, seems good now!

One thing I'm wondering is if there's any easy way to "reload" the automatically loaded DBG files? It seems I can "reset labels" but that clears all of them out, and the only way I can think to get them back is either to use the import to manually find the file and import it, or reopen Mesen?
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

One thing I've been wondering... there is a watch list in the debugger, which updates whenever execution breaks. Being able to use symbols for this is great.

There is also the memory view, which updates continually, but you can't put together a list of things you want to inspect there, nor can you search/use symbolic names for anything.

Is there anything equivalent to the "Ram Watch" view that FCEUX/Bizhawk has that would let you look at a custom set of data updated once per frame? Like say I want to keep an eye on 3 different values that are at different places in memory, but while playing and not having to break on every frame.

I guess ideally it would just be a separate window version of the debugger's watch panel that just updates more often.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

rainwarrior wrote:One thing I'm wondering is if there's any easy way to "reload" the automatically loaded DBG files?
Power cycling should reload the .dbg, but only if the timestamp on it has changed (originally did this to speed up power cycling, but it doesn't behave properly if you manually delete the labels and then do this to try to reload them). Closing all debugger windows & reopening them should also reload the .dbg file.

You can set the watch window to update every frame (Options -> Refresh UI while running), actually. You can search the memory tools using symbols by using the new "Go To All" feature (Ctrl+,), from there you can right-click on the byte and do "Add to watch".
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

Sour wrote:You can set the watch window to update every frame (Options -> Refresh UI while running), actually. You can search the memory tools using symbols by using the new "Go To All" feature (Ctrl+,), from there you can right-click on the byte and do "Add to watch".
Ah, Go To All is good! Telling the watch window to update helps, but it would be really useful to have a dedicated watch window.

Currently there is only space for a few lines in it, and I can't expand it vertically very much. The sizing seems to restrict it so that the disassembly panel has to be a minimum size above it.

So... what I'd request is a dedicated watch window, maybe duplicating what's inside the debugger, but separate so it can be taller to fit more stuff. Other options: select unsigned, signed, hex display per-line instead of just the two global options there is now. Being able to save and load the current watch list is also very good for switching between tasks. Also some ability to rearrange the watch list would help organize it.

I'm basically just describing FCEUX or BizHawk's "Ram Watch" window, if you want something to compare against. Though the integration with symbolic names and expressions makes Mesen's a lot more powerful... if I could fit more lines into it. ;)
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

The height is limited by the console status portion (which can't be smaller than X otherwise the contents would be cut off).

Adding a standalone watch window shouldn't be too hard, but I've also been pondering rewriting the watch window with a custom control recently because it's plagued with usability issues, and trying to fix one always seems to cause another. The built-in inline edit feature of the C# listview isn't great, and trying to add a way to reorder the items would probably end up being hard to use at best.

I'll take a look into rewriting that and making it into a standalone window when I get a chance.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

Sour wrote:The built-in inline edit feature of the C# listview isn't great, and trying to add a way to reorder the items would probably end up being hard to use at best.
If I could right click on an entry and choose "move up" or "move down" that would be enough. It's just to prevent having to recreate the whole list to accommodate adding a new one anywhere but the bottom. (I don't think something fancier like drag and drop is necessary. FCEUX just does it with two arrow buttons. Bizhawk has two buttons and a right click menu.)
Post Reply