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.

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)

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.

Last edited by Sour on Tue Oct 24, 2017 1:41 pm, edited 1 time in total.

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.

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.

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.

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.

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.

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.

Who is online

Users browsing this forum: No registered users and 6 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum