Any accurate emulator with good debug features?

Or am I forced to use FCEUX?

FCEUX has great debug features; it's my goto emulator out of habit.

Also check out https://www.mesen.ca/ and Nintendulator / NintendulatorDX

I know FCEUX has good debug capabilities, but it's not very accurate when it comes to emulation. It's SNES9x of nes emulation. It's THAT inacurrate.

I use FCEUX for Windows in Wine for debugging (because the SDL version doesn't have a debugger) and a PowerPak for accuracy.

Do you need the accuracy and the debug features to be active at the same time?

FCEUX seems to have a poor reputation but I don't think it deserves it, and it's improved quite a lot in the past few years. (This commonly consulted table is several years out of date now.)

If you use the New PPU setting, FCEUX is very accurate in most respects. The CPU emulation is very good, and the PPU emulation is good more or less up until you want to do something very specific (e.g. anything using the phrase "horizontal blanking").

Nintendulator is better, but it's really rare that I'm doing something that's requires the specific things where it matters (and the better debugger is more than enough reason for me to stick with FCEUX). ...and to be honest, any time I'd be compelled to check Nintendulator, I'm going to be checking against real hardware as well, because ain't nothing perfect.

What issues do people have with FCEUX? I'd like to hear specifics.

It's my go-to emulator for testing due to its features, debugger, and helpful key button mappings, with Nintendulator helping out only if I need visual feedback on the OAM table. For accuracy and low input lag gameplay testing I use Nestopia.
If you're making something so unique that it won't work on FCEUX (I'm guessing we're talking super accurate timing related issues here??), but it works on a real NES or other more accurate emulators, are you sure there isn't a "better" way to do it?

To be honest, the only stuff I've been able to pinpoint in practice with "more accurate" emulators, has been poorly initialized memory or registers, which was absolutely only my own fault (most recently, only one emulator was able to remind me that I needed to manually disable MMC3's write lock on the SRAM address space)

BTW tokumaru wrote a really nice Lua script for inspecting sprites in FCEUX: https://forums.nesdev.com/viewtopic.php?p=181008#p181008

I also added OAM to the hex viewer, though I think it was after the last stable release, so you'd need an interim build to use it.

That's good to know. The poor sprite debugging is one of the things that often pushes me to use other emulators.

That said, I also use it as my primary debugger (like tepples, using the windows version in linux with wine), but I have run into a few places where it's not 100% accurate. But like Frankengraphics said, I also find mesen to be pretty good (I acutally prefer the UI of Mesen to fceux)

At this point, I'd like to think Mesen has pretty much caught up with FCEUX in terms of debugging tools (and Mesen also offers a number of tools that FCEUX is missing) - if people still have things they can't get done in Mesen's debugger that works in FCEUX, I'm more than happy to take a look and fill in any gaps that remain.

Yeah, I really like the look of Mesen so far, but I haven't yet spent too much time with it yet mainly because I've got so much inertia with FCEUX (i.e. years of daily use, and a lot of familiarity with it from the inside). Have been meaning to give it a thorough test after I finish my current project.

Nintaco also provides debugging tools as seen here.

I was thinking of a more visual approach. Tokumaru's script is really nice! And painfully obvious, too...
I actually completely forgot, that Lua scripting is also one of the primary reasons I use FCEUX, it really helps out a lot with live debugging. That said, it's become less useful after I started defining variable addresses by using CA65's ".res" command, making them much more likely to move around between builds.
If I could somehow make my script read from the assembler's .dbg file to figure out variable locations, that would be really awesome.

Yeah, I have my python script that generates .NL files also spit out a header file for my lua script to reference addresses. For a long while I was doing it manually though, because I had arranged my ROM layout in a way that most of the addresses I cared about seldom changed.

Actually, on a related note I wish FCEUX breakpoints could reference debug symbols so they'd stay up to date between builds.

I never added support for .nl files because (as far as I know) they don't support bank switching properly (e.g 2 different bytes in the rom can end up mapped to the same "address" in the .nl file) - correct me if I'm wrong, though. Mesen does support loading CC65's .dbg files directly, though.

Adding breakpoints based on debug symbols is an interesting idea, and does make a lot of sense for homebrew dev. Adding support for it should be relatively easy on my end.

Banking and .NL files kinda sucks, especially since they're based around iNES 16k "banks" rather than actual banking capabilities. The mapping conflict you're talking about can come up with <=8k banking mappers, though in practice it's probably not that hard to avoid or work around?

I'd rather just have one big file that maps ROM addresses to memory addresses than this mess of separate files for every 16k hunk. Direct support for .DBG is a much nicer idea. I wish it had a specification, though; it's been a bit volatile as a format, but maybe it's settled down at this point.

Yea, the issues with .nl files aren't hugely problematic, importing them probably wouldn't be that hard ([nl file number] * $8000 + label address - $8000 = prg rom offset, I think?). I'm not sure there's any real reason to support the format since Mesen can already integrate with CC65 & ASM6 - are there any other common tools that generate .nl files?

This is pretty much what the ".mlb" format I added to Mesen does, e.g:Where the first letter is a label "type": R (internal ram), P (prg rom), S (save ram), W (work ram) or G (cpu address, $0000-$FFFF)
All labels are offsets starting from 0 for that specific memory type (so "P:$30000" corresponds to byte $30010 in the .nes rom).
It's not perfect when it comes to ram variables that are reused for different purposes at different points in the code, but for anything else, it works and is simple to parse. Mesen can import/export this format, and freem was kind enough to merge my modifications to ASM6 into his branch (ASM6f), so ASM6f can export a .mlb file to import into Mesen.

The .dbg support in Mesen is based off a bunch of regexes and only supports what I actually needed, but it shouldn't break from minor file format changes (though from what I can tell, CC65's code for this has not changed since 2014). I just didn't want to use CC65's code directly (8000 lines) when the relatively small subset of features I needed fits in ~300 lines of C# code.

Yeah if you need both accuracy and good debugging tools, Mesen is the way to go. I still use FCEux a lot for quick testing as it's quicker to start (and on my laptop it's much quicker) though.

I guess a proof of concept might be to make a ROM map in .mlb format for MLB.

As far as 'accuracy' goes, nesicide's emulator is fairly so. But it's been a few years since I checked or cared about accuracy.
As far as 'good' debug features go, depends on what you need. Full visibility into all memories. Full visualization of nametable, pattern table, sprites. Fully enumerated bit-field visibility into all register details of CPU, PPU, APU, and [some, not all] mappers. Code profiler. Execution visualizer (where is my code executing in the TV frame). Symbol inspector with watch. Assembly view. Code/data logger. Breakpoints on an ungodly amount of events within the CPU, PPU, APU, or mapper. Controller logging for test suites.
I'm presently working on automated distro for Win/OSX/Linux of the nesicide package so hopefully that helps.

I love Nesicide mostly for providing live debugging that points me directly to the code, but I think it has quite a few issues. I don't know if this is the correct thread to bring it up, but it always bothered me that breakpoints are directly bound to PC addresses - I feel it would be nicer to stick them directly to a line number in the text editor (so the breakpoint also moves when you add code above it, etc.), and then it updates the emulator with actual PC breakpoints "behind the scenes" whenever you load the rom into the emulator.
This would also help with a lot of other issues such as old breakpoints becoming useless, and old "garbage" breakpoints still showing, when they are suddenly somewhere else.

Another slightly minor issue is that clicking a breakpoint disables it instead of removing it, adding one extra step to cycle between compared to the standard for most IDEs. It makes sense in the breakpoint overview window, but on the actual text editor I would prefer that a click just creates/removes the breakpoint entirely. Maybe it's a setting somewhere that I overlooked?

More on topic to this thread, though, my main reason for rarely using the Nesicide emulator when I can avoid it, is that it runs extremely slowly on every computer I've tried it. It both skips frames and runs the game much slower than intended. How slow it is seems to be strangely variable though - some times it will run almost full speed (but still with frameskips?) while at other times it's absurdly slow. I'm not sure what makes the difference, but if you have any idea, that would be nice to know.
Also, a speed up key and savestates would be pretty nice for testing gameplay stuff. I almost exclusively use FCEUX and Nestopia for this purpose as it is.

Indeed.

I will look into this.

There are four options for debug level. The first is the bug in the toolbar. If not selected, no debugging features are enabled [not even breakpoints]. The other debug level options are in NESICIDE->Environment Settings->Nintendo Entertainment System->Debugging. You can select between updating only on pause, at frame rate, or once per second. That should help with performance issues. Also, if you're using a build that somehow got released but is a debug build, those are incredibly slow. That is another reason why I am trying to automate the distro since sometimes I forget when building to switch to "Release" configuration.

I'll see if I can build a new version for myself, I had no idea my version was so out of date - I actually just thought you hadn't been working on the probject for a long time, so I'll try that out before commenting any more on how it works.

As for my settings now, the debugger is already set to only update on pause, so that's definitely not the issue. The emulator's performance is the same even if I disable debugging - that's pretty much the first thing I tried.

I honestly haven't been *continually* working on it. I am having a bit of a resurgence in motivation.

What OS do you need? I might just go ahead and upload Win/Lin/OSX builds now since I happen to have all three in front of me.

Windows.

I'm actually in the process of installing QT now just for the purpose of building Nesicide... it's a pretty damn heavy dependency, both downloading an installing is taking forever, and I'll probably delete it immediately afterwards

It may be heavy but it's *nothing* compared to a completely different Eclipse-based IDE that I am currently trying to build.
I should be able to upload Windows builds in the next couple hours. Will report back.

Thanks a lot, cause I'm giving up on this. The shell scripts are giving me all kinds of errors, and I have no idea where to look to fix it

I hadn't had a chance yet to debug the win-deploy.sh script. Turns out it was bollocks. I've got it building now but I'm having DLL issues.