Since the last release, I've spent some time adding new features and improving existing stuff in Mesen's debugger. At this point, I think I've implemented the vast majority of ideas I could come up with. I made a similar thread a couple of years ago and got some really nice feedback which helped improve the debugger quite a bit, so I'm hoping to get some more feedback now that the debugging tools have matured.

Any feedback is welcome - whether it's new tools you would find useful, or missing information/features in the existing tools (or even good old bug reports). I'm also trying to make Mesen as easy to integrate as possible from a development point of view (e.g compile with cc65/asm6 => import labels/etc => debug). But I don't actually develop anything for the NES, so if there's anything missing that would make this sort of workflow easier, someone needs to tell me :p

And here's a partial list of debugger changes/additions since 0.9.4:-Improved breakpoint management, including (among other things) being able to set breakpoints on work ram, save ram, palette ram, chr ram/rom-Syntax highlighting in the code window & trace logger (colors are customizable)-Added a tooltip popup for the opcodes which displays a short summary, shows which flags are affected, the addressing mode and the number of cycles the instruction takes.-Added an "APU Viewer" tool to display the values of most of the APU's internal state-Added a custom-built scrollbar for the code window which displays the location of breakpoints, etc.-The new scrollbar will also display a popup preview of the code at the mouse cursor's location when the mouse is over the scrollbar-Added an option to display the value stored at the memory address used by an instruction (e.g: LDA $44 = $FF). It should be identical to FCEUX's behavior (I think)-The PPU viewer was fixed to work properly for MMC5 games that use extended attributes-Added an option to the CHR viewer to display each tile with the last palette it was displayed with (which makes it a lot easier to recognize tiles vs displaying the entire thing in the same palette)

Disclaimer: I haven't actually tried mesen yet, and am away-from-my-computer ATM, so it could already have this feature... but as I haven't seen it in any emulator I've tried, I'd assume it isn't. So here goes:

A debugging feature I've always thought would be useful would be to actually be able to view the full 340/341 pixels of a scanline including hblank, outputting either a blank colour (or BG0 if screen is off).

(I know this might actually not be 100% correct (as the PPU most likely doesn't output any colour in hblank, hence its name). But it would really make aligning your register writes within the hblank period a lot easier, and because you would only be viewing hblank in such a special debug mode I think accurate emulation is a bit of a moot point.)

And speaking of register writes, a visualisation that shows this would be pretty awesome too. My current workflow is replacing my actual PPU register writes (to $2005/$2006) with PPU register writes that take the exact same amount of cycles but actually change the rendering, such as setting the monochrome bit along with one of the colour emphasis bits.

But this obviously requires me to switch back-and-forth between my debug code and tve actual code. It'd be great if this process of seeing a blended colour in the PPU output to visualise the time of the PPU register writes could be achived without having to change my code. Perhaps by making the output between the start/finish of a PPU register write result in a red/green/blue/other-distinct-colour-depending-on-which-register-is-written blended overlay.

And speaking of register writes, a visualisation that shows this would be pretty awesome too.

... oh, man, it would have been awesome if something had automatically been able to make this image rather than exactingly play with Nintendulator's debugger and breakpoints and marking up the screenshot in Gimp.

(Actually, I know that that image is inaccurate because there should be a bunch more pixels of that pinkish palette entry 0 on both left and right and the bottom too)

—

Is there a "breakpoint on write that would cause a bus conflict for those mappers that sometimes have bus conflicts " ? Maybe there's already enough rope to do that with breakpoint conditions?

This is easily the most complete set of debugging features I've ever seen in any emulator, so, good job! That being said, I can think of a few things that I personally would consider improvements:

- Put buttons for controlling the program flow in the debugger window itself: I have trouble remembering keyboard shortcuts (I'm much more of a mouse guy, really), and having to repeatedly go through the menu every time I need to run, break, step, etc. can be very tiresome. I know that the interface is already pretty cramped as it is, but if you could find a spot where to put these buttons, that'd make my day. It looks like there's some room left where the "Undo changes" and "Go To" commands are, so that's an idea... This is what I miss the most when comparing Mesen to FCEUX.

- Don't alternate the dot crawl pattern when drawing partial frames: I don't know how the NTSC filters integrate with the emulator, but would it be possible to alternate the dot crawl pattern only when an entire frame has been rendered, as is the case during normal gameplay? I get very distracted by the NTSC artifacts wobbling around when I'm stepping through the code trying to time raster effects and such. Plus it's not a very good representation of what happens with the real hardware.

- Add an option to show the previous frame under partial frames: This would help us know when the PPU is about to render an area of interest when we're stepping through the code, and would also make it easier to compare frame to frame changes (e.g. how much a raster effect jitters). The old frame could be dimmed, tinted, desaturated or something, so we could clearly see what's new and what's old.

- Add more options to the "Break in..." window: Frames, scanlines and CPU cycles would all be welcome additions. Of course we can convert those into PPU cycles manually, but it's much more convenient to have the program do it for us. A "break on scanline" option would be great too, but I guess we can just use a "scanline == XX" condition in a normal breakpoint already if we really need that.

I'm gonna say this again: What you currently have is already awesome, and I find it particularly cool that you're willing to hear from other developers and consider implementing the things that would improve their workflow. Keep up the great work!

Looking forward to trying this emulator out. By the way, does it have feature parity between the Windows and Linux veraions? FCEUX's lack of debugging features in the Linux version is one of the big reasons I'm still on Windows. (Pro Motion is the other one, need to see how well Wine handles that nowadays...)

A bit short on time to reply at the moment but:-Adding ppu register writes to the picture should be easy, but I'm not sure how easy showing hblank would be (and then you might also want to show any register change occurring during vblank, too). I could probably add another tool that displays a 341x261 image showing dots (+ optional text?) for all register writes, though.-Bus conflicts break: I haven't tested it, but I think something like this would probably work: "IsWrite && (Value & [Address]) != Value". So if the value written & the value stored at the address are not the same, the condition is true.-Buttons in the debugger window: Would a toolbar at the top with most of the frequently used actions be good enough? This would allow me to easily add a toggle to hide/show the toolbar for people that wouldn't want it.-Alternate ntsc dot pattern w/ draw partial frame: That's actually a bug, didn't realize it did that, should be simple to fix.-Show previous frame under current frame (with dimming/etc): I think this might be possible, I'll check.-More options in "Break in..": Sure, that's an easy change

Regarding Mesen under Linux: The debugger is identical in both versions - but the Linux version does require Mono to run. Beyond that, except for the lack of support for exclusive fullscreen, the Linux version should be identical to the Windows version.

Thanks again for the feedback, if anybody has anything else they'd like to see added, feel free to chime in!

-Adding ppu register writes to the picture should be easy, but I'm not sure how easy showing hblank would be (and then you might also want to show any register change occurring during vblank, too). I could probably add another tool that displays a 341x261 image showing dots (+ optional text?) for all register writes, though.

Is it extending the image width that's posing the problem?

Thinking further, I could think this feature could come in two variants:1) A separate window that shows a blank 341x261 image, with register writes in various colours (like the image lidnariq linked to), like you suggested2) An ability to overlay this window on top of the usual rendered output, with some sort of simple blending

Now, if feature number 2 is restricted to the usual 256x240 output that's not a big problem, if you can view the hblank/vblank-specific parts using feature 1. And perhaps a merged view would be possible in a later version, when more people have tried it out in practice and can provide their own feedback.

I find I spend way too much time aligning my writes manually to fit in hblank when writing raster loops, and finally seeing a feature like this in a NES emulator would be pretty awesome.

-Buttons in the debugger window: Would a toolbar at the top with most of the frequently used actions be good enough? This would allow me to easily add a toggle to hide/show the toolbar for people that wouldn't want it.

Sure, sounds great! Anything that allows running/breaking/stepping with single clicks will work well IMO.

Quote:

-Show previous frame under current frame (with dimming/etc): I think this might be possible, I'll check.

It makes sense to make this optional as well, right? Maybe via a check box right after the one that enables the display of partial frames?

BTW, here's one more vote for the PPU write visualizer. Sounds like an incredibly useful feature!

One thing that I'd love to have built-in to a debugger (which I admit can currently be done with a lua script), is to have an option to log all writes to a certain address. I often want to figure out what all things are writing to a variable, and what they're writing, but if that variable gets used in a ton of places, it can be really inefficient to put a breakpoint on it and manually watch it -- instead I'd love to have a log of the writes, similar to running a trace, but limited to only writes to that one address.

So the ability to flag an address to log writes, and get a report like this (if I'm watching $0400)

$8023 : $FF$8027 : $F0$8347 : $00...etc

Where each line is a write to $0400, and tells the address of the command that wrote to $0400, and the value written to $0400

Does that make sense? Like I said, I can do this already using lua scripts, but I'd love to see it built-in to something. (or maybe it already is, and I've missed it)

Sooner a request for adding a feature to run half-cycle and show up all the results. Why? Are you really taken all those things into account for massive debugging sessions, or a non-stop 48 hours journey of coding a new game? Nope, you are NOT.

ANYWAY, a cool feature is the ability to run arbitrary code. You type the code and push RUN. You open an ASM file (proprietary format) and push RUN. You load a CHR bank(s) file(s) and hit RUN. Plus, the ability to save your code.

Sooner a request for adding a feature to run half-cycle and show up all the results. Why? Are you really taken all those things into account for massive debugging sessions, or a non-stop 48 hours journey of coding a new game? Nope, you are NOT.

Apparently it is possible to advance the emulation with PPU cycle accuracy, meaning you can in fact run franctions of CPU cycles. Please correct me if I'm long.

Quote:

ANYWAY, a cool feature is the ability to run arbitrary code. You type the code and push RUN. You open an ASM file (proprietary format) and push RUN. You load a CHR bank(s) file(s) and hit RUN. Plus, the ability to save your code.

Now I can't tell whether you're joking, but there is in fact an assembler where you can write/paste arbitrary code. FCEUX also has a debugged that can assemble code and patch the ROM with the results, that you can save to disk.

Yes, extending the 256x240 resolution is probably not something that can be done easily. I can easily draw the whole frame in another window & then add the writes over it, though. I'll give this a go later tonight, shouldn't be too hard to get done.

@gauauu You should already be able to do this in the trace logger using conditional logging. Try this condition: "IsWrite && Address == $400" - it should only log instructions that write to $400

@Zepper Like tokumaru said, Mesen can already step through the emulation on a ppu tick level. The built-in assembler can also be used to run arbitrary assembly code, edit any existing code in PRG ROM and save the modifications as a new rom or as an IPS patch, too. The CHR data can be edited in the PPU viewer and saved to a rom/ips file, too. There is no way to load assembly code or CHR data from external sources/other tools, though.

lidnariq's picture ended up being a great way of checking that it's working properly! The Sprite DMA is displayed as a series of writes to $2004, though.

Things I want to add:-Mouse over tooltip on the dots to get precise info (cycle, scanline, register and value written)-Ability to customize the colors (since it's impossible to pick colors that would be visible for all games)-Maybe a list of all the writes and their info (e.g same as tooltip), but I want to avoid making the ppu viewer's window any bigger, so not too sure.

Maybe it should show the left/right margins as the color from the expansion port (i.e. color 0) in concordance with the timing on the scanline timing page? (i.e. 11 columns of backdrop immediately to the right of the visible field and 15/16 on the far right edge of the window)

What's the colorspace for the surface here? In RGB, XORing any number of component with 0x80 is guaranteed to be visible. Not certain what an equivalently useful metric would be in other colorspaces... and not that making it configurable is bad.

It looks like you've marked all the cycles a little to the right of my version. Did I forget to account the 10ish pixels of delay from when the STx abs starts and when the write happens? Does the game vary from boot to boot? Are there subtle timing differences here between Nintendulator and Mesen?

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