Home Page Forums Other Emulator Message Boards Nestopia Nestopia 1.41 unofficial release

Nestopia 1.41 unofficial release:

Binaries: http://c0d3h4x0r.0catch.com/Nestopia-1.41-unofficial-x86.zip

Source: http://c0d3h4x0r.0catch.com/Nestopia-1.41-unofficial-x86-src.zip

NESTOPIA RELEASE NOTES

-------------------------------
1.41 for Win32 (March 29, 2010)
-------------------------------
This is an unofficial maintenance release I created to fix an annoying joystick lag issue. This lag was particularly bad when VSync was enabled. The original Nestopia author (Martin
Freij) appears to have abandoned the official Nestopia project on SourceForge and has not responded to any of my e-mails, so I am left with no choice but to provide this unofficial release as a public service to the emulation community.

Changes:

1. Removed manual option to set priority of Nestopia's main emulation loop thread. Instead, Nestopia now boosts its own process base priority AND its own main emulation thread priority whenever it is the active foreground window (and/or running in full-screen mode). This brings Nestopia much closer to real-time performance and responsiveness.

2. Removed some screwy input polling logic, and added some calls to input.Poll(), to ensure that the input devices are always polled immediately before the input state is utilized. This was the key change that got rid of most of the lag.

3. Removed some screwy input timing logic that was causing input polling to work only on certain clock intervals, rather than allowing it to work every time it was called.

(As far as I can tell on my own hardware configuration, these three changes taken together have completely eliminated the lag problems that have been present in Nestopia for several releases. Your mileage may vary.)

4. Updated the Visual Studio solution/project to build successfully under Visual C++ 2008 Express Edition.

5. Added this releasenotes.txt file and bumped the version number to 1.41.

- Keith Kelly (c0d3h4x0r@hotmail.com)

brilliant! this is why i love open source projects; they can never truly die!

Very true. I just registered here to say thank you for fixing these issues and releasing your work. It even compiles fluidly now! The difference is remarkable.

That said, I wonder if you'd be so kind to perhaps look at another issue which is particularly galling for Win7 and Vista users: It's the choppy sound as reported both on the ZSNES board (scrolling way down to FireBrandX's post: http://board.zsnes.com/phpBB2/viewtopic.php?t=11629&start=0) and here, too (http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=56805#Post56805).
Both Nintendulator and FCEUX sound fine, which, aside from your work here, are the only recent still-developed NES emus, I believe. Could it be connected to the higher latency of Vista's and 7's DirectSound implementation? Or might it be a problem of the timing thread having issues with refresh rate syncing? Vista and 7 are known to confuse some badly programmed games in VSync with its more exact monitor refresh rate determination (59 vs. 60 Hz, though I've tried various refresh rates, even exact NTSC [59.94], and it doesn't work). Or a funny combination of both?
Hardware differences don't seem to affect it and no setting fixes it completely. Setting the latency to 1 in the sound options merely reduces it. It appears that audio and video go out of sync and Nestopia's timing thread snaps the audio thread back into place, producing clicking sounds every 2-3 seconds. Setting both Windows and Nestopia to use the same sampling rate does not work and neither does setting them both to a lower value. Otherwise, that's a commonly known workaround for this kind of problem for both video playback and regular games.

I've tried everything I know and I'm at my wits' end. I'm a novice in C++ and not familiar at all with Nestopia's extremely complex-looking codebase. Perchance you'd like to give it a try?

Thanks again for your time.

I wish Marty would start working on his emulator again. Such a great program to just forget about.

Does anyone know if there's a way to have the cheat files automatically load into the cheat window when a game is loaded? Maybe by using it's SHA? Can't be CRC, because they vary.

I haven't experienced any issues with choppy sound on any of my three Win7 x64 machines using my unofficial 1.41 build.

FireBrandX's issue sounds like either a bad audio driver or something wrong with his particular hardware. It wouldn't surprise me if the other Nestopia users reporting this problem have the same faulty audio driver or hardware.

Anyway, for anyone reporting this issue (or any other issue) in the future, it's incredibly important that you provide detailed repro steps (including all your Nestopia settings, running fullscreen or not, what ROM(s) you are using, and your hardware configuration) so that developers like me can actually reproduce the problem. If you don't provide enough information and we can't reproduce your problem, then there's nothing we can do to investigate it or fix it.

Just for the record, I am playing NTSC roms on an NTSC PC with the monitor refresh set to 60fps, VSync enabled, fullscreen, timings set to "synchronize to screen refresh", and sound latency set to "1". This is using my 1.41 unofficial release.

My primary desktop hardware:
Windows 7 amd64 RTM + all latest Windows Updates
Gigabyte GA-X58A-UDR3 motherboard (Intel X58 chipset)
HPET (High-Precision event timer) enabled and set to "64-bit mode" in the BIOS
Intel Core i7-920 CPU overlocked to 3.2 GHz
8GB RAM
ATI Radeon HD 4890
Integrated Realtek HD Audio
all latest drivers/firmwares/BIOSes installed

I'm sorry for not providing those details. As I said in my original post, hardware differences seemed not to matter during my testing with three different machines here. I am indeed surprised that you do not experience this. It seems there's more going on than I originally thought. I better stop assuming for now

Okay, this happens on the following systems, playing NTSC-U ROMs, monitor refresh rate forced or set to 60 Hz (it originally registered as 59 on one monitor here, which is a known "problem" with 7, as I detailed above -- though it doesn't make a difference whether I use other monitors or whether I force it to 59 or 60 Hz) via the NV control applet or otherwise, VSync plus triple buffering enabled, timings set to "synchronize to refresh rate" and sound latency to "1", fullscreen or not makes no difference:

Win7 x64 RTM plus all updates
ASUS Rampage II Extreme on AHCI mode, Intel ICH10R chipset
Intel Core i7-920 down-voltmodded & overclocked to 3.6 GHz
6GB OCZ DDR3-1600 RAM at 1443 GHz
NVIDIA Geforce GTX 295 (w/ 3D profile overclocked & VBIOS-down-voltmodded to decrease heat generation)
Creative SB X-Fi PCIe Titanium Fatal1ty Pro
All the latest drivers/firmwares/BIOSes through Station Drivers et al.
Everything's stress-tested and stable.
(ASUS provides no HPET option in their R2E BIOS. The device manager thus lists it but says that "no drivers are installed for this device." I guess that means I'm still on RTC?)

Next was on a laptop:
Win7 x64 RTM plus all updates
CLEVO M570RU-U, Intel ICH8R chipset
Intel Core2Duo T-9300, 2.5 Ghz
4GB DDR2-600 RAM
NVIDIA Geforce 8800M GTX VBIOS-modded to 9800GT (w/ 3D profile overclocked)
Integrated Realtek HD Audio
All the latest drivers/firmwares/BIOSes through Station Drivers et al.
(Of course, no HPET option here either. Phoenix TrustedCore BIOS options are notoriously sparse.)

And another desktop:
Win7 x64 RTM plus all updates
ASUS P5B Deluxe, Intel ICH8R chipset
Intel Core2Duo E6400, 2.1 Ghz overclocked to 3.01 Ghz
4GB DDR2-800 RAM
Sapphire ATI Radeon HD 5870 Vapor-X, Rev. 2
SoundMAX Integrated Digital HD Audio (AD1989)
All the latest drivers/firmwares/BIOSes through Station Drivers et al.
(No HPET option here either.)

New Forceware drivers finally curbed the latency issues on my laptop. DPC Latency Checker now shows no latency abnormalities on all of them.

I typically use Megaman 2 to test this, as its intro's long notes demonstrate it quite well, though it happens on all of them. As I said, setting sound latency to "1" merely reduces the problem. The ROMs themselves are known good ROMs. This is all done using your 1.41 release. CPU usage on the C2Ds never exceeds 8% and my Core i7 registers 4,5% maximum as reported by the newest Process Explorer 12.01.

So there you go. Let me know if you need any further help tracking this down. I'm willing
Thank you for the taking the time to help!

I had a similar problem using my Acer Aspire One netbook, the problem turned out to be Stardock's CursorFX. It's a kind of mouse pointer skin thing. If I disable it Nestopia runs fine but while it's enabled Nestopia runs really choppy, very slow frame rate and choppy unsynchronized sound.

Just my 2 cents.

For what it's worth, it also does not appear to matter whether Aero is activated or not. Normally, I run with it disabled, since it causes tearing for me in a number of non-DWM-compliant applications (mostly emulators requiring high precision in hitting VBlanks and MPC-HC's syncing code).

Buzbard:
In Stardock's forums, there is talk of a bug or something causing extremely high CPU usage or maybe your netbook's just not powerful enough to run a skinning program besides something rather demanding like Nestopia.
What OS do you run? XP like most Aspire Ones? Then you might not encounter this particular peculiarity as described by me. Does the music in games otherwise sound in any way choppy? If not, consider yourself lucky
Thanks to c0d3h4x0r, Nestopia's pretty much close to perfect now for my needs. I'm very glad he's decided to help

Yea, I'm running XP. My netbook does run Nestopia fine, just not while CursorXP is enabled, I've stopped using it anyway.

I see you're running Win7, did you know that Microsoft has a free download that gives you WinXP mode for Win7? So you can run older software.

Here's the link: http://www.microsoft.com/windows/virtual-pc/default.aspx

You might give that a try.

And yes, thank you c0d3h4x0r for the update, well done!

Thank you gummybear for the detailed error report. I will look into this sometime over the next week or two and let you know if I am able to reproduce the issue and maybe find out what's causing it.