It is currently Tue Nov 20, 2018 4:09 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 583 posts ]  Go to page Previous  1 ... 33, 34, 35, 36, 37, 38, 39  Next
Author Message
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue Aug 21, 2018 5:46 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6959
Location: Canada
Sour wrote:
rainwarrior wrote:
One more thing about NSFs: if using PAL region the INIT should have 1 passed for X, not 0.
It looks like I broke this a long time ago when fixing the playback speed when Dendy timings are selected. Haven't fixed it just yet since I was wondering, what should this return for Dendy timings? Would returning 1 like for PAL be good enough? Or would it make more sense to have another value for Dendy (e.g X = 2)?

NSF has never had a Dendy spec. 2 is "undefined behaviour"... however...

I did actually decide yesterday that I should add a nes NSFe chunk to address this:
http://wiki.nesdev.com/w/index.php/NSFe#regn

If unspecified, I think "normal" expected Dendy behaviour is X=0 but use PAL speed. (i.e. NTSC version of tunes played too slowly). That's really what most Dendy games would do.

(Most NSF rips are single platform only and ignore X as a parameter anyway. With homebrew, especially Famitracker, X does often matter, though, and there an unexpected X=2 may cause problems. Better to use X=0 by default there than throw something new they weren't written for.)

The added NSFe chunk will accomodate stuff made specifically for Dendy, though, in which case if that's specified pass X=2.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue Aug 21, 2018 10:39 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6959
Location: Canada
Another bug report: I get a division by zero error when I open the debugger for this one.

Edit: Ah! The problem is I have no CHR-ROM but used iNES 2 header to specify 0 CHR-RAM. So, I made a bad header, but it does crash the emulator too.

The ROM itself doesn't do anything visible at the moment (should just display the blank screen), but the source code is here if useful: github link (once again, a bit convoluted to build it though, not recommended unless needed, ask me if you need more intermediary files from it)

Attachment:
mesen_divzero.png
mesen_divzero.png [ 27.94 KiB | Viewed 2748 times ]


As far as I can tell this error doesn't have to do with the DBG file? It seems to have this problem even if I clear the workspace and get rid of the DBG.

Also, to follow up on the previous changes (since I'm trying the latest appveyor build): the FDS example seems like it's working very well! NSFe also appears to work. The INIT and PLAY gotos are appreciated.


Attachments:
nes_and_dbg.zip [53.52 KiB]
Downloaded 92 times
Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 22, 2018 11:52 am 
Offline

Joined: Tue Jun 28, 2011 2:39 pm
Posts: 192
What can I do as an user to improve Mesen's performance? My computer is Asus UX32VD, i5 version, but Mesen barely uses my CPU (there's free cpu time and by no means it's hitting 100%). The problem I'm facing is that emulator randomly drops to 40-58 FPS range (most of the time it's 55fps) which leads to audio screeching. I've tried to increase audio buffer, but it had no effect. This happens even when I'm using no filters whatsoever.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 22, 2018 12:33 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3693
Location: Mountain View, CA
Important fact: Asus UX32VD is a laptop. It also contains two GPUs: Intel HD 4000 (i.e. IGP / integrated graphics into the CPU), and an NVIDIA GT 620M. I don't know which of those GPUs is actually handling the graphical drawing, but it likely matters. Neither GPU is particularly "powerful" compared to a desktop, but that brings into question what DX11 features are being used by Mesen (I have to assume you're using Windows 7 Home, which is the default OS that the laptop comes with).


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 22, 2018 12:44 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6959
Location: Canada
A suggestion: the current PC should always be assumed to be the start of an instruction for disassembly.

Here's a screenshot where a data table appearing right before a function breaks the disassembly of that function:
Attachment:
debugger_pc_not_disassembled.png
debugger_pc_not_disassembled.png [ 101.08 KiB | Viewed 2699 times ]

So, I guess the "correct" display in my view would break up the previous instruction (and show its disassembly as data), and begin a new instruction where the PC is.

There's also a defined symbol on the line at that PC too, which is being hidden because of this. (I might even suggest as an option that all defined debug labels should cause the disassembly to realign on that point.)

Though, being able to realign the disassembly manually is very useful on its own, like if I want to go browsing other areas of the code (especially if looking at a game I don't have debug symbols for). In FCEUX you can manually set the starting address of the top of the disassembly window, but the current PC is always placed there as well, which is kind of two birds with one stone, but it's a bit of a simpler implementation (seeing code above and below in MESEN is definitely a good feature).

The code in question looks like this:
Code:
sprite_title_cursor: .byte    0,   -1, $0C, $00
                     .byte  7*8,   -1, $0C, $40, 128

title_redraw:
   jsr sprite_begin
   lda title_pos
   asl
...


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 22, 2018 2:17 pm 
Offline

Joined: Tue Jun 28, 2011 2:39 pm
Posts: 192
koitsu wrote:
Important fact: Asus UX32VD is a laptop. It also contains two GPUs: Intel HD 4000 (i.e. IGP / integrated graphics into the CPU), and an NVIDIA GT 620M. I don't know which of those GPUs is actually handling the graphical drawing, but it likely matters. Neither GPU is particularly "powerful" compared to a desktop, but that brings into question what DX11 features are being used by Mesen (I have to assume you're using Windows 7 Home, which is the default OS that the laptop comes with).


I'm on Win10. And GPU doesn't matter for a NES emu. I'd rather worry about other settings related to emulation itself. I have no such issues with other emulators such as FCEUX or Nestopia. Again, Mesen barely uses my CPU/GPU and I've disabled integrated GPU, so it's uses nVidia chip.

//edit: Haven't looked into sources yet, but if debugger is active even when you don't open it (i.e. when just playing games and not using debug functions), that may be a slow down factor.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 22, 2018 2:52 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 526
darkhog wrote:
WMy computer is Asus UX32VD, i5 version, but Mesen barely uses my CPU (there's free cpu time and by no means it's hitting 100%)
If you set the emulation to "maximum speed", how fast can it go? If it can go above 60fps at maximum speed but drops below 60fps when set to 100% speed, something is wrong.
Are you running off the battery, or plugged in? Is Windows set to use one of the "low battery usage" performance profiles (e.g Balanced, etc.), or one of the high performance ones?

Like you guessed, the video card doesn't really matter, and Mesen doesn't make much use of DX11 features, DX11 is required mostly because I use Microsoft's Direct Toolkit library to simplify a few things.

The debugger is disabled unless one or more of the debugging tools are opened (opening any of them will typically drop performance by 20-40%).

rainwarrior wrote:
Ah! The problem is I have no CHR-ROM but used iNES 2 header to specify 0 CHR-RAM. So, I made a bad header, but it does crash the emulator too.
Thanks, seems to be linked to the changes I did to improve the CPU/PPU memory mapping display at the bottom, I'll take a look.

For the disassembly issue, this shouldn't ever happen, unless the CDL log is invalid (e.g parts that are not code have been marked as code). I'm assuming this is with a .dbg file loaded? I'm using the data from .dbg files to generate proper CDL data when they are loaded (which in turns means all the code is disassembled properly from the start), but it's possible that in this case the logic I'm using is flawed. If you can send me the .dbg file, I might be able to fix it.

Realigning the disassembly would be a nice thing to have, but I can't see a simple way of doing this at the moment, given the way the disassembly works. Essentially, the disassembly relies on the CDL info entirely, and the entire memory space is disassembled on every step. Using labels to force the disassembler to realign itself is definitely something worth exploring though.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 22, 2018 3:21 pm 
Offline

Joined: Tue Jun 28, 2011 2:39 pm
Posts: 192
It goes to about 200fps on maximum speed. I'm plugged in (using the computer as a workstation rather than a laptop as I can't afford a real pc at the moment) and not in power saving mode.

//edit: Do you plan adding support for the .deb files (debug symbols used by fceux)?


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 22, 2018 4:00 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 526
darkhog wrote:
It goes to about 200fps on maximum speed. I'm plugged in (using the computer as a workstation rather than a laptop as I can't afford a real pc at the moment) and not in power saving mode.

//edit: Do you plan adding support for the .deb files (debug symbols used by fceux)?
I think I may know what's causing it to run slower than 60fps at times. Essentially if your PC wakes up too late from the sleep calls used to regulate the speed, it never tries to make up for that lost time and the code can end up running at less than 60fps. If that's what's causing the issue, this build should hopefully fix it: https://www.mesen.ca/MesenRunSpeedFix.zip Let me know if this build changes anything on your end.

As for .deb files, I had never actually taken a look at them before, but they appear to be binary files, and only contain the breakpoints/bookmarks and a few other options - none of these can really be imported into Mesen reliably. The labels are in the .nl files, which can't be imported either, but it might be possible to add support for those, but I'm not sure they can be perfectly mapped to Mesen's way of managing labels, I'll take a another look at this when I get a chance.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 22, 2018 6:06 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3693
Location: Mountain View, CA
Sour wrote:
Essentially if your PC wakes up too late from the sleep calls used to regulate the speed, it never tries to make up for that lost time and the code can end up running at less than 60fps.

Now I *have* to ask how this is implemented. My face right now is pretty much :shock: . This doesn't sound right at all, but at the same time, there are several things in my head that see the need for sleeping.

Maybe separate thread material...


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 22, 2018 7:05 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 526
There isn't much to say really - Mesen uses high resolution timers to keep track of time and sleeps between each frame to limit the FPS to 60.1 or 50.0 depending on NTSC/PAL.
Looking at it again now (4+ years after I initially wrote this), there's a tweak or 2 I should probably make to make it more robust/precise, but it's better than trying to rely on vertical sync (especially since the rendering is completely detached from the emulation core), etc.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 22, 2018 7:33 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3693
Location: Mountain View, CA
Syncing off of actual/real VSync (i.e. monitor VSync) I don't think would work any more, especially considering 120Hz, 144Hz, and 240Hz monitors. Some monitors even advertise via EDID a sync rate of 59.94Hz and Windows 7 in its infinite wisdom and glory rounds that *down* to 59Hz. I don't get the impression anything can do that reliably any more in Windows-land. :\

A common technique used to be to sync off of an audio rate (don't ask me how this works, but it's used in several major SNES emulators), otherwise things like A/V could get out of sync somehow.

James, the guy who did nemulator, talked for a while here about how he did his synchronisation. He ran into problems with his initial approach due to things like CPU frequency throttling (ex. Intel SpeedStep), C1-C4 CPU-level sleep states, etc. (also see blargg's responses!) -- and rather than do the awful thing of changing people's Power Profile Settings in their OS, he reinvented his method described here, and it seems to work remarkably well. He did it in SDL as well.

I guess using sleeps works (you certainly should not keep the CPU running at 100% all the time! Yes some emulators do that, gahhh!), but I was always under the impression that in Windows, like other OSes, you could essentially tell the kernel "I want you to execute this thing (pointer to code) at an interval of N {milliseconds,microseconds,some interval}".


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 22, 2018 8:25 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6959
Location: Canada
Sour wrote:
For the disassembly issue, this shouldn't ever happen, unless the CDL log is invalid (e.g parts that are not code have been marked as code). I'm assuming this is with a .dbg file loaded? I'm using the data from .dbg files to generate proper CDL data when they are loaded (which in turns means all the code is disassembled properly from the start), but it's possible that in this case the logic I'm using is flawed. If you can send me the .dbg file, I might be able to fix it.

Realigning the disassembly would be a nice thing to have, but I can't see a simple way of doing this at the moment, given the way the disassembly works. Essentially, the disassembly relies on the CDL info entirely, and the entire memory space is disassembled on every step. Using labels to force the disassembler to realign itself is definitely something worth exploring though.

An NES + DBG file is attached. (github source) A similar example to above can be found at the label "menu_title_redraw".

I also tried to see if I could "manually" realign by right clicking and trying to assign code vs. data but couldn't really work out how to change anything. Lines got highlighted differently but the disassembly never changed. (Is manual CDL editing possible?)

Another unrelated thought: should F9 breakpoints on banked ROM maybe add a bank condition by default?


Attachments:
misdentified_data.zip [61.18 KiB]
Downloaded 93 times
Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 22, 2018 9:28 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 526
rainwarrior wrote:
An NES + DBG file is attached. (github source) A similar example to above can be found at the label "menu_title_redraw".
Thanks - it's actually an issue when turning on the options to disassemble verified data and/or unknown data/code. Without those enabled, I get this:
Attachment:
debug.png
debug.png [ 10.79 KiB | Viewed 2583 times ]
In this case, if you turn off the "disassemble verified data" option, it should fix itself. It shouldn't be too hard to force the disassembly to realign itself with the verified code when it transitions from one type to the other, though - I'll take a look tomorrow.
Quote:
Is manual CDL editing possible?
It is, with the "mark selection as" options (in either the code window or hex editor), but in your case, since you've set it to disassemble everything, I think it'll end up with the exact same disassembly either way. (Also, when using .dbg files, any changes you'd do to the CDL log would be overwritten the next time the .dbg file is loaded)
Quote:
Another unrelated thought: should F9 breakpoints on banked ROM maybe add a bank condition by default?
It does already, in a way. Pressing F9 adds a breakpoint to a specific offset in PRG ROM (assuming you do it on a row that's currently mapped to PRG ROM, that is), not to a specific CPU memory address, so the breakpoint will only trigger for that specific bank.

koitsu wrote:
A common technique used to be to sync off of an audio rate [...]
Syncing to the audio has some benefits (such as easily avoiding audio pops and crackling), but then your actual FPS will end up varying from one system to the other, and NTSC filters will flicker more if the FPS is too far away from the monitor's refresh rate, etc.
Mesen does do something similar to nemulator (changing the audio's sample rate to keep the video/audio in sync) - I'm not too sure what nemulator syncs itself against, though (e.g vsync or a timer). The only thing Mesen does at the moment is force the Windows-wide timer resolution to 1ms (only while the emulation is actually running), to help reduce the chances of sleeps being way off target (default resolution is 16ms, which is pretty horrible).

It's possible there are some reliable ways to setup a periodic callback, but I'm not overly familiar with the Win32 API (I'm more of a Javascript/C# person :p) - but using something like that wouldn't technically result in any tangible benefit, I think, the OS would probably end up doing something very similar to what I'm currently doing with sleeps.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Aug 23, 2018 2:58 am 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 414
Funny A/V sync story: my laptop misreports both video and audio rates. The former is permanently locked at 59.837 hz no matter what the OS says it is (I can make it claim 120 hz if I want) and the latter actually provides 44060 kHz instead of 44100 kHz for CD audio. Yes, really. I wrote a lot of code to figure those out. The only thing capable of stutter-free playback on my machine is the movie player I wrote myself.

I could write a book on the subject, but it wouldn't help anyone but me. :roll: Bottom line is, assume nothing. If you want stutter-free play, the only sure-fire solution is to sync to vsync and variable-rate-resample the audio, with no external clock. For odd framerates or vsync off, throw in a frame timer, but don't turn off audio autoadjustement, or make that a seperate option.

I got fancy and added a judder DDA as well, duplicating or dropping frames in a fixed integer ratio (double every frame for 60 -> 120, every sixth for 50 -> 60, etcetera), but then I have to support every input and output framerate under the sun. Probably feature creep for you, but it's a lot smoother than the timer-based approach if you really can't change your display framerate.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 583 posts ]  Go to page Previous  1 ... 33, 34, 35, 36, 37, 38, 39  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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