This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Mesen - Debugger Feedback?

Mesen - Debugger Feedback?
by on (#183843)
EDIT (March 2017): See page 3+ for a lot of recent additions to the debugger.

For the past couple of weeks I've been working on Mesen's debugger and added a fair amount of features.
I still have a few features I want to add (e.g editing memory values, displaying APU state, etc.), but I've implemented the vast majority of what I set out to do.
At this point, I think it combines most of the features of other NES debuggers, and probably adds a few features that aren't available in other debuggers.

I'm hoping to get some feedback from people that actually have a use for a debugger (which is why I'm posting this to NESdev instead of NESemdev)
e.g: Is is user-friendly? Are there features that are missing that you'd want/need? etc.

Here's a build containing the latest debug features: download (Still Windows-only, for now)

Screenshots of what it looks like:
Debugger Window: Screenshot #1 #2 #3
PPU Viewer: Screenshot #1 #2 #3
Memory Viewer: Screenshot #1 #2

And here's a mostly complete list of features: feature list

If you decide to give it a try, please let me know what you think! (And if you find anything that looks like a bug, please tell)
Thanks!

P.S: I know a lot of people here seem to be using Linux - at the moment there is no way to run Mesen on it, but I'm hoping to fix that in the next couple of months or so (hopefully.)
Re: Mesen - Debugger Feedback?
by on (#183847)
Can't test (since linux and even with a VM I can't run ≥DX10), but one question: do the tooltips change according to the emulated machine?
e.g. does the tooltip for $2001 swap the red and green emphasis bits when emulating PAL/Dendy ?
Re: Mesen - Debugger Feedback?
by on (#183867)
Yea, I did the pretty silly choice of using DX11 when I started this a few years ago - probably would have made more sense to use DX9 instead.

The tooltips are based on user-defined labels, so they can be changed at any time. The one in the screenshot is part of the default labels that are automatically added to the debugger.
They're currently hardcoded as is, but I could definitely alter the defaults based on the region to give more accurate info when running in PAL/Dendy mode, etc.
Re: Mesen - Debugger Feedback?
by on (#183872)
Feedback:

Debugger window looks great (warning: it's very hard to impress me with debuggers, I nitpick heavily). Things that caught my attention:

* Uppercase opcodes may annoy some people -- if what's on the left is actual source code (I have a feeling it is), then no problem
* Don't use instruction aliases/mneumonics like cpa (it's cmp) -- but again, if that's actual source code then no problem
* "Draw left Spr" should use the expanded word "Sprite" (it'll fit -- and if it doesn't, you have enough room to shift the other "column" of checkboxes over to the right)
* Be consistent with spelling. Ex: the word is either greyscale or grayscale (e vs. a) (the latter is more common in American English, the former everywhere else). I see "Grayscale" in the UI, while "greyscale" in the tooltips (and while there, just describe bit 0 as "Display type: (0: color, 1: greyscale)
* Column of checkboxes (Vertical Write, NMI on vBlank, etc.) need proper spacing (vertically/space between each one). It's not consistent. If it's difficult to do while keeping alignment with the fields on the left, then split the column into two "sections": Vertical Write, NMI on vBlank, and Large Sprites, followed by some empty space, followed by Grayscale, etc.
* Call stack is two words
* The call stack looks confusing to me. What is the address in parenthesis after the label? (ex: RenderLevel32Wide ($80CA))? It looks like it's the address of the label/function itself, but then there's the "CPU Addr" field that says something different? This could be me not understanding the tool (highly likely!), but I don't find this intuitive at first glance. Hence: take my view on this one with a grain of salt :-)
* Why do the CPU Addr fields start with an @ symbol?
* Why are the ROM Addr fields surrounded in [] brackets?
* It should be "ROM Addr" not "ROM Addr." (note the period)
* It should be "CPU Addr" not "Cpu Addr"
* Labels/checkboxes need to use consistent casing (there are probably other cases than "Cpu Addr" above)
* If this is purely for NES/Famicom/Dendy, then there is no decimal mode CPU flag. I'd suggest "Unused" as a description
* Needs display of RESET, NMI, and IRQ/BRK vectors

Nametable viewer tab needs a grid toggle/checkbox.

Memory viewer needs display of actual (potential) ASCII data on the far right. HOWEVER, before implementing this... well... it's complicated. I can talk at great length about this later on, and it relates to romhacking/translation (as it stands right now, no good debugger offers a feature that's highly sought after). For simplicity/default, you just want to display anything outside of the ASCII 0x20-0x7e range as a dot/period, otherwise show it. Hit me up in a forum post here when you want to tackle the bigger issue (trust me: it's a big undertaking).

Memory viewer needs way to view raw OBJ/OAM memory (not sure if it's in the pulldown). I know the Sprite Viewer tab can display this indirectly, but there are cases where people want to tinker with just OBJ/OAM.
Re: Mesen - Debugger Feedback?
by on (#183875)
Gave it a bit of a test. Looks pretty good so far. Some thoughts/suggestions:


I like the sprite tool. Sprites don't seem to be drawn in its "Screen Preview" with the correct priority though. (Are they being drawn 0-63 instead of reverse order?)

The memory map with bank numbers is cool.

The palette tool takes up a lot of screen space despite only using a small portion of it.

Is there an option to disable the "default" labels for stuff in the debugger? I find them difficult to read vs just the regular numbers of registers.

The debugger has a lot of important keys that do different things if you are accidentally in the wrong window. E.g. F5 is resume vs stavestate, F11 is step vs fullscreen. The savestate conflict especially bugs me (savestates are very helpful when debugging), and you need to go back to the player window frequently to make player input. I think it would be better if keys were global, maybe add a ctrl/alt/shift modifier to most debugger keys?

F5 only resumes, but wouldn't an execution toggle be more useful? The corresponding break is a 3 key combination Ctrl+Alt+Break, which you have to switch windows to do- couldn't the pause/break key do both break and resume? (Why ctrl+alt as well? There doesn't seem to be any existing thing that uses that key.) I notice the regular emulator already has escape to do pause/unpause, but couldn't this be unified with the debugger? Why is pausing the emulator different from breaking in the debugger? You can't break while the emulator is paused, apparently, and pressing "escape" is the most sensible way to stop the emulator quickly when trying to enter input, so there should be a way to go from "paused" to "break". (At least I can still use the PPU debug windows with the emulator paused.)

Is there an option to not make the debugger break when a ROM is opened? Especially if you only want to look at PPU stuff, I'd want the debugger minimized, and since F5 doesn't work in any window but the debugger I have to switch back to it to resume. If I don't minimize the debugger window it automatically pops up over top of the PPU windows whenever I switch back to the emulator window for some reason.

Finally, this is not a debugging issue, but I have very erratic drops in framerate. The FPS indicator will pretty much always say 60/60 but the actual displayed frames seems to drop down to maybe 15fps about half the time (changing every few seconds). Doesn't seem to be a CPU usage issue (it's not using a full core of the CPU), nor a vsync issue (vsync is off by default).
Re: Mesen - Debugger Feedback?
by on (#183876)
koitsu wrote:
Memory viewer needs display of actual (potential) ASCII data on the far right. HOWEVER, before implementing this... well... it's complicated. I can talk at great length about this later on, and it relates to romhacking/translation (as it stands right now, no good debugger offers a feature that's highly sought after). For simplicity/default, you just want to display anything outside of the ASCII 0x20-0x7e range as a dot/period, otherwise show it. Hit me up in a forum post here when you want to tackle the bigger issue (trust me: it's a big undertaking).

FCEUX supports hex-to-character mapping through a table file in its hex editor, and has an additonal "text hooker" tool that uses the same for translating text currently in the nametables directly.
Re: Mesen - Debugger Feedback?
by on (#183877)
The mention of "Ctrl+Alt+Break" worried me. Make sure it's usable on laptops that lack a full complement of special keys, especially the Print Screen, Scroll Lock, Pause/Break, and number pad, or laptops that make the F keys hard to reach because they default to media keys (such as volume, screen brightness, WLAN enable, external monitor enable) unless Fn is held.

I'd recommend Ctrl+S for quick save state and Ctrl+R for quick load, as those are similar to in word processors (Ctrl+S) and web browsers (Ctrl+R).
Re: Mesen - Debugger Feedback?
by on (#183878)
It would be useful if the debugger showed hex bytes for everything, to the left of the instruction maybe, or in its own column? It's very helpful to know what the bytes are, especially when the disassembly has misidentified stuff.

With "unknown block", where nothing at all is displayed. Just showing the hex bytes would be much more useful.

What does the debugger show if you're currently executing an illegal opcode? (I don't think the debugger needs to show illegal opcodes, necessarily, but it should show the bytes that are currently being executed at least.)
Re: Mesen - Debugger Feedback?
by on (#183881)
Thanks to the both of you for the feedback!

(Warning: wall of text below)

@koitsu:
The left part is actually a rom's disassembly (+ symbols from a DBG file), not the actual code.
The opcodes are in uppercase because FCEUX/Nintendulator have them in uppercase - is it typical to write them in lowercase when writing the code? Could definitely add an option for this.
Also didn't realize I had a non-standard opcode name in there - but you're right about CMP. I'll fix that and make sure the rest is standard.

Call stack: I'll fix the name, never realized it had a space despite seeing the word all the time!
As for how it works:
RenderLevel32Wide ($80CA) $80CE [$240CE]

$80CA is the sub's entry point
@ $80CE is the current active instruction in that function (so for the top of the stack, it's the PC, for everything else, it will be the address of the JSR instruction)
[$240CE] is the active instruction's location in the PRG ROM - this probably doesn't need brackets (esp. since the function list & label list do not use brackets for the same case)

So it's meant to be read "In function $80CA, at (@) address $80CE" - but I agree it might not be incredibly obvious. Not sure how to make it more intuitive though.

The IRQ/NMI/Reset handlers (and their addresses) are in the Search->Go To menu.
I agree with the points you bring up about labels/layout, so I'll fix those too.

For the NT viewer, you mean a 8x8 grid? Or would 16x16 and 8x8 both make sense due to attributes?

Memory Viewer vs text: This is actually on my list of things to do as well. My original idea was to have a default config that displays ascii like you said, and then be able to customize what value maps to what character. As for the bigger issue, are you referring to how Japanese games like to separate ゛ and ゜ from the actual character and combine them at runtime? (Just a wild guess - I imagine there's also some pretty complex stuff with the Chinese games as well)

The memory viewer lets you view: CPU, PPU, Palette, OAM, Secondary OAM, PRG ROM, CHR ROM, CHR RAM, Work RAM, Save RAM, Internal RAM (the built-in 2k)


@rainwarrior:
You're absolutely right about the sprite preview - I'll fix that.
I agree about the palette tool, but I'm not sure where else I could fit it, there isn't that much space remaining in the other tabs.

I could add an option to disable the default labels - or you can just select all of them in the label list and hit delete too (this could be annoying if you need to do it often though)

The debugger's keys are mostly made to mimic visual studio since this is what I always use.
To be fair, Ctrl+Alt+Break is mostly useless as hitting F11 (step into) will have the exact same effect.
I agree about F5 vs load state though - I end up doing that mistake myself relatively often.
The "pause" screen for the emulator can only be triggered at the end of a frame to avoid the overhead of checking a flag on every single instruction, so it might be tricky to make "break" and "pause" the same - I'll see if I can find anything that makes sense. (for debugger shortcuts in general as well)

I'll add an option to not automatically break when the debugger is opened, good idea. As for the debugger popping over the PPU windows, I actually meant to fix that before posting this morning, but completely forgot about it.

Mesen only disassembles code that has actually been run, or would have been run if the result of a conditional branch had been different (i.e branch taken or not) - so it will never display code that is not nearly 100% sure to be actual code.
Also, if you right-click in the code window, you can turn on "Show byte code" to display the byte code for all instructions below the assembly (makes each line slightly taller).
All the illegal opcodes that Mesen supports are disassembled and are marked with a * next to the opcode. Opcodes that completely crash the CPU will show up as "invalid opcode"

Unknown blocks: If you uncheck "Show only disassembled code" in "Options", they will turn into .db statements.

As for your FPS problem, I'm not quite sure what might be causing it - The first number is the number of frames generated by the emulation, the 2nd is the number of frames sent to the video card.
I haven't had anybody else complain about this before I think, it could be an issue with the directx code (I'm far from being a DX expert) - I'll try to take a look at the code and see if anything looks suspicious.


@tepples:
There are actually laptops that default to not having the keys work as F1-F12? ..That must be a lot of fun to work with.
At the moment some of the keys for Mesen are hardcoded and some can be customized - I plan on allowing users to customize all of them at some point, so this should be fixed eventually.
Thanks for the info, though, I haven't used too many laptops over the years, so I never noticed!
Re: Mesen - Debugger Feedback?
by on (#183882)
A few more:


A "jump to PC" button would be useful for when you scroll the disassembly view somewhere else and need to get back.

Why is there an "apply state" button? If you're changing register states / etc. it should apply immediately, IMO. However, if you change it into an "undo state" button (grey until you make changes) that resets the state to what it was after the last executed instruction would probably be useful. This is in the category of: let the user undo a mistake rather than require a confirmation every time.

Of the spelling preferences koitsu listed, I definitely agree with CMP (have never seen CPA before).

Being able to set a breakpoint from a right click in the the debugger's disassembly pane would be nice. (You can can do watch but not breakpoints this way, which seems the opposite of which of those two is useful on the disassembly view-- set watch is useful from hex editor, set breakpoint is useful from disassembly.)

A breakpoint seems to hit on the instruction before as well as the instruction it is set on sometimes. (In this case putting a breakpoint on the DEX of ROR, DEX hits on both.)

The watch field needs [] around memory addresses. This was tricky to figure out; not sure what use literals in the watch area is, like if I type $300, what use is it to tell me its value is $300? (Maybe instead of [] for lookup, make all numbers lookup memory, and a # prefix would specify "immediate"? That way the watch could display literals, and they would be entered similar to assembly convention.)

Breakpoint addresses can only be hex. This is fine, I think, but the notation is weirdly inconsistent (no $ in the editor). I don't really like having to type extra $ anyway, maybe a $ to the left of the entry field would make this clear.

Address ranges are extremely important with breakpoint reads and writes. Think of a question like "does this ROM make any writes to WRAM", kind of impossible if each breakpoint only operates on a single byte. (It feels like I should be able to do this with conditional breakpoints, but I couldn't get it to work: see next suggestion...)

It seems like I can type garbage text into the breakpoint condition and it will still hit. There should be some diagnostic here from accidentally using bad syntax.

I love that the breakpoint condition field has a tooltip though. Very good feature!
Re: Mesen - Debugger Feedback?
by on (#183885)
You can jump to the PC with "Show Next Statement" in the code window's right-click menu (Alt-* .. which is a terrible shortcut, I think I also took that from visual studio)

The Apply State vs Undo is a good point.

You can set a breakpoint on any line by clicking on the left end side of the margin (or pressing F9)
The breakpoint hitting on the wrong instruction is odd - are you sure you didn't have a global breakpoint with a condition setup or something akin? Could be a bug though.

The main issue with using # instead of [] is that the watch shares the same expression engine as the breakpoint conditions, so you would have to write "cycle == #$10" for example in the breakpoint conditions - not very user friendly in my opinion. Plus the watch also uses {} to read word values instead of byte values (this is all explained in the "?" popup next to the watch window's title). I agree that # would make sense in the watch window, though.. Not quite sure what solution would work best overall.

Technically you can set ranges with conditions, but it is not that obvious: Set address to "Any" and then set "Address >= $6000 && Address < $8000" as a condition.
Not very ideal, though. Adding ranges to the regular breakpoints would probably be fairly easy and make more sense considering it's a pretty common use case.

I'll add a validation for breakpoint conditions like it does for watch values.
Re: Mesen - Debugger Feedback?
by on (#183886)
Hmm, well maybe ignore the # suggestion. The ability to fetch 8 vs 16 bit values is a good thing to have. The tooltip does make it clear, I guess, but I didn't notice how to do it right away.

The breakpoint on wrong instruction thing seems to happen any time there is a 1 byte instruction before the breakpointed instruction (e.g. DEX, TAX, etc.).

Question: how to make the emulator do a hard reset (i.e. power off / on) vs soft reset? I see only "reset" and also "stop" which unloads the ROM entirely.
Re: Mesen - Debugger Feedback?
by on (#183887)
Sour wrote:
if you right-click in the code window, you can turn on "Show byte code" to display the byte code for all instructions below the assembly (makes each line slightly taller).
All the illegal opcodes that Mesen supports are disassembled and are marked with a * next to the opcode. Opcodes that completely crash the CPU will show up as "invalid opcode"

Unknown blocks: If you uncheck "Show only disassembled code" in "Options", they will turn into .db statements.

These are good, though I find the disassembly window gets very cramped by this second line, and the text is small and hard to read (partly because i turned the text size down because the debugger window is so small).

For me the disassembly is the most important thing in the debugger; i want to see lots of it. In this debugger everything else takes up so much space it is crowded away- I can resize the debugger's window to make it bigger, but it's starting from a pretty small space to begin with. If I make the window wider, the instruction bytes and even ROM address could fit on the left easily, though at this point the debugging window is very large on the screen. I don't know what to suggest here; if I could hide/show the "functions/labels" column it might help? That's probably a pain to do though.

Oh wait, I just noticed I can hide those already! Wow. Ha ha. Yeah, so that's really cool.


I really like the automatic code-data logging, finding functions etc. That's really neat. I think I'd rather it show "attempted disassembly", maybe in a special colour, than data bytes, at least where it's not known to be data at this point. (Sometimes data is code, though, so most useful would be an option for all bytes to display an attempted disassembly.)

Since it's already identifying functions etc. maybe it could do profiling too, count the number of times executed, the number of cycles spent in each function, etc. ? (I actually wrote some text parsing tools to do this with FCEUX trace logs, but it's a lot of logs to process-- would be really cool to have a profiler built into an emulator. That's kinda next level stuff though.)
Re: Mesen - Debugger Feedback?
by on (#183895)
Sour wrote:
@koitsu:
The left part is actually a rom's disassembly (+ symbols from a DBG file), not the actual code.

Gotcha. I'm not familiar with .dbg files (are these .deb files FCEUX uses?).

What is turning NES MMIO registers into names? In FCEUX I believe these are accomplished through .nl files. Is this contained within the .dbg? If not (i.e. Mesen is doing the register name conversions itself), then the ability to toggle that would be useful. Most of the time I cannot tools converting such values into arbitrary names which I may/may not recognise.

Sour wrote:
The opcodes are in uppercase because FCEUX/Nintendulator have them in uppercase - is it typical to write them in lowercase when writing the code? Could definitely add an option for this.

It's a matter of programmer style and preference. I've varied over the years in my style, but for quite some time I've resorted to lowercase opcodes, leaving uppercase or mixed-case things for variables, labels, or whatever else. So, to answer your question: yes it's typical, just as it's typical for someone to write opcodes in uppercase. :-) A toggle option would be great (and should be incredibly easy to implement code-wise, assuming you have an uppercase/lowercase string conversion function in the PL you're using).

Sour wrote:
Call stack: I'll fix the name, never realized it had a space despite seeing the word all the time!

Yeah, "callstack" isn't an actual word, it's "call stack". I think some people just like compounding words into a single one to make it sound cool; superHipsterCrapNameWithCamelCase2.0Bro! ;-)

Sour wrote:
As for how it works: {explanation of syntaxes shown in call stack}

Got it -- makes sense. Now that you've described it, it clicks. So here's how you could help clarify the subroutine entry point with very little code: change the field name from "Function" to "Function (Entry Addr)". Bam, clarified. :-) But assuming you're writing documentation for this, yeah, please describe it much like you did to me in the docs. Different debuggers implement call stack syntaxes/conventions differently.

Sour wrote:
The IRQ/NMI/Reset handlers (and their addresses) are in the Search->Go To menu.

Well that's not an intuitive place for it at all. :-) Can they be placed in a small box/section to the left of Labels and below PPU Status?

Sour wrote:
For the NT viewer, you mean a 8x8 grid? Or would 16x16 and 8x8 both make sense due to attributes?

Excellent question (and not something I thought of). I was thinking 8x8, but now that you mention the attribute table, yeah, I think 16x16 would be useful too. Make it a checkbox for toggling the grid on/off, and when the checkbox is enabled, provide a pulldown for Grid Size that's 8x8 or 16x16.

Sour wrote:
Memory Viewer vs text: This is actually on my list of things to do as well. My original idea was to have a default config that displays ascii like you said, and then be able to customize what value maps to what character. As for the bigger issue, are you referring to how Japanese games like to separate ゛ and ゜ from the actual character and combine them at runtime? (Just a wild guess - I imagine there's also some pretty complex stuff with the Chinese games as well)

Sort of. I think rainwarrior touched base on this one, but it's basically that games don't necessarily (bad wording coming up, my apologies) correlate alphabets/text tiles with ASCII location with actual PPU tile offsets. Meaning: "A" in ASCII is at 0x41, but nothing stops a developer from putting their A-Z tiles at PPU address $0020. There are files that are called .tbl (table) files which provide a kind of mapping (e.g. $20 -> "A", etc.). See the FCEUX documentation for "Text Hooker" to get an idea of what I'm talking about. Many Japanese games use offsets that are EUC-JP, but again, you could have $F2 -> "A", $25 -> "B", etc. -- and many games do this too, since for many title or text screens, they only add the CHR for the letters they actually use on-screen (i.e. you don't have an ASCII-compatible full alphabet, because all they show is "CONGRATURATIONS" (note the missing L) which only needs 10 tiles (ACGINORSTU).

I should warn you up front, however. As Walter from The Big Lebowski said: "you're entering a world of pain". The situation is complicated by fonts and character sets. Ideally everyone would use UTF-8, but then you have to deal with that, BOM vs. non-BOM, blah blah, and most of the table-generating tools *do not* use UTF-8. I'm trying very hard right now to avoid the subject, LOL. It's just something you need to keep in mind. That's why I said don't worry about this for now, deal with it down the road.

I've attached a screenshot demonstrating the pain in NO$NES, at least with regards to font usage when printing characters. I've seen this in more programs than I care to count, often in hex editors, but it's never limited to just those.

Sour wrote:
There are actually laptops that default to not having the keys work as F1-F12? ..That must be a lot of fun to work with.

There are actual desktop keyboards like this (they're commonplace too, including some from Microsoft (I use one!)), where the F-keys are either few (F1-F10), or have default scancodes changed to crap like F1=Help, F2=Undo, F3=Redo, F4=New, F10=Spell, etc.. The Microsoft Natural keyboards have an "F-Lock" key (which has no scancode -- it's a modifier key for the keyboard itself (think Fn on a laptop)) that toggles this behaviour, but some older Microsoft and Logitech keyboards did it weirdly -- I could talk for 30 minutes on all that, but will hold off. Laptops are notorious for removing keys though, and I've heard of some which even lack a Fn key. So, in short, I sympathise with tepples -- let's hope he never runs FreeBSD (console framebuffer scrollback requires you to hit Scroll Lock to enter scrollback mode, and again to exit it -- different from Linux console where you use Alt-Arrow or Alt-PUp/PDown (or is it Left Shift?) ;-) ). For keyboards that default to non-classic-F-key mode: this isn't your problem. DO NOT try to solve it in your program: honest! Just stick with standard scancodes/values for function keys and don't worry.

I would, though, suggest trying to limit the F-key usage to F1-F10 if at all possible. Also, some keyboards lack a Pause/Break key entirely, so if you plan on using that key: don't! :-)
Re: Mesen - Debugger Feedback?
by on (#183900)
Got this message when loading the DBG file for STREEMERZ, although debugging worked quite well regardless of the errors:
Code:
---------------------------
Mesen
---------------------------
Import completed with 3969 labels importedand 25379 errors - please file a bug report and attach the DBG file you tried to import.
---------------------------
OK   
---------------------------

Unfortunately I don't want to share the DBG file at the moment (maybe later).

The Flip/Priority checkboxes in Sprite Viewer should probably be disabled so that the user doesn't think they can actually switch their state in OAM.

The Sprite Info view could also display the sprite index that the user is currently hovering the mouse over.
Re: Mesen - Debugger Feedback?
by on (#183917)
Thanks again for all the feedback/bug reports!

Link to latest build: download
Picture with most of the new changes visible: screenshot

I did the following fixes/changes since the last build:
-Added "break on reset/power" & "break when debugger is opened" options
-Added a "Disable Default Labels" option in File->Workspace
-Added options for 8x8 and 16x16 grids in NT viewer (both can be shown at once, or independently)
-Added "Sprite index" to sprite viewer, prevented users from changing the checkbox states, and fixed the draw order for the preview
-Added an option to display op codes in lower case
-Added validations on BP conditions - it will now display a warning icon when the syntax is incorrect, and prevent the user from adding the breakpoint.
-Added a "Toggle breakpoint" option in the right-click menu for the code window
-Added a "Address Range" option for breakpoints
-Changed the display options for PRG addresses & byte code in the code window. It is now possible to display the byte code on the left side of the code (in a slightly different colored margin)
-Added a "Goto" button/dropdown in the main window to give easy access to NMI/IRQ/Reset subs
-Fixed UI labels/layout and instruction names (CPA->CMP, and some discrepancies with unofficial opcodes)
-Fixed debugger window popping up over other windows when clicking on the main emulation window
-Fixed the incorrect breakpoints after 1-byte instructions - this was due to the dummy read these instructions perform on the next instruction's first byte.

Not done yet:
Profiler: Good idea, and should be easy to implement, I'll probably get this done in the next few days
Disassembling everything: Might take a bit of time to get done, but should be easy enough.
Shortcuts and the like: I'll give it some more thought before I change anything here.


@rainwarrior:
There is no "hard reset" button - typically I just do File->Recent Files->First in list to hard reset. I wanted to add one, but as stupid as it may sound, I had no clue how to translate the Soft/Hard reset distinction to French & Japanese, so I ended up not adding it.


@koitsu:
DBG files are the files generated by CC65 when compiling a project - they contain symbols and references to the original code, etc.
The NES registers turning into names is part of the default labels added to the workspace when you start debugging - you can remove them like any other label or customize them however you like, nothing is forced. (And I just added an option to not add these labels by default)
I mostly added them for myself since I do not know most of the registers by heart and it helps me figure out what code does faster.

Mesen's UI is built in C#/Winforms, so typically, displaying non-ascii stuff is typically not a problem (currently works fine when adding japanese characters to comments).
Reading text files in UTF8/Shift-JIS/etc is also usually pretty straightforward, the .NET framework does most of the heavy lifting.
I'll take a look at FCEUX's documentation and see what it supports when I get the chance.


@thefox
Thanks for testing!

That amount of errors is pretty impressive! If you had labels in the debugger, then my guess is that it was unable to load the source files.
This would probably be due to the path in the "name" tag for the "file" directives.
Currently the regex I'm using only allows the following characters in paths:
0-9, a-z, A-Z ( ) _ . - : / \
Any chance the paths you have in your DBG file (should be at the very top) contain something outside of these?
Re: Mesen - Debugger Feedback?
by on (#183921)
Sour wrote:
as stupid as it may sound, I had no clue how to translate the Soft/Hard reset distinction to French & Japanese, so I ended up not adding it.

Do these languages have a convenient word for a "power cycle"?

Quote:
This would probably be due to the path in the "name" tag for the "file" directives.
Currently the regex I'm using only allows the following characters in paths:
0-9, a-z, A-Z ( ) _ . - : / \
Any chance the paths you have in your DBG file (should be at the very top) contain something outside of these?

Space (U+0020), for one, because space in the username, username in the user's profile path, and no write privileges outside the user's profile without elevating. Or a Windows 7 installation that was upgraded from Windows XP, where all profiles were inside "Documents and Settings" instead of the "Users" used for new installations.
Re: Mesen - Debugger Feedback?
by on (#183924)
Sour wrote:
I wanted to add one, but as stupid as it may sound, I had no clue how to translate the Soft/Hard reset distinction to French & Japanese, so I ended up not adding it.


I've seen these referred to as "warm boot" (soft reset) and "cold boot" (hard reset/power cycle); not sure how well those will translate to French and Japanese, however.

(If I get some free time soon, I'll check the debugger out; I do appreciate the work you've put into it, so thanks for doing so.)
Re: Mesen - Debugger Feedback?
by on (#183926)
Wow, that was a quick turnaround on changes!

Sour wrote:
There is no "hard reset" button - typically I just do File->Recent Files->First in list to hard reset. I wanted to add one, but as stupid as it may sound, I had no clue how to translate the Soft/Hard reset distinction to French & Japanese, so I ended up not adding it.

The NES had two buttons labelled "POWER" and "RESET" which perform the two functions I was talking about. The Japanese Famicom also used these same terms in English to label them, and I believe the various European NES systems still used the English terms on these buttons as well?

I don't know what to translate them into, but for the NES I consider POWER and RESET to be standard input buttons (alongside A, B, START, SELECT) so whether or not you want to provide a translated description, I think showing those two words is appropriate.
Re: Mesen - Debugger Feedback?
by on (#183932)
Unfortunately, my laptop has a max resolution of 1366x768, which makes the GUI look like this.

I'm also pretty sure that 'power' and 'reset' are safe labels, at least in here in Europe.
One thing that can be frustrating is when Microsoft (for example) think they have to invent new words in swedish (and probably any other language) for just about everything, so you can't find what you're looking after, any time you're using a localized installation, at least not without having to play a game of deduction, term for term. I strongly recommend against localizing expressions and labels.
Re: Mesen - Debugger Feedback?
by on (#183933)
rainwarrior wrote:
Wow, that was a quick turnaround on changes!
That's the nice part of the UI being in C#/Winforms - it is far easier and faster to add/modify these sorts of things compared to just about any other way of building Windows applications.

I guess I'll just add a "Power" option in the menu and have that work as a hard reset.


@tepples I actually have spaces in the regex too, but that got lost in translation when I pasted the regex into my message and reformatted it!

@freem No problem, let me know what you think if you do try it out!

@WheelInventor
You should be able to get a reasonable setup if you:
-Hide the label/function lists (from the Options menu)
-Hide the cpu/ppu memory mapping (also in the Options menu)
-Reduce the font size (Ctrl+Minus) of the code window

Not ideal, but unfortunately there is only so much information that can be shown in 1366x768 before you fill up the screen :(
Re: Mesen - Debugger Feedback?
by on (#183977)
Sour, thanks for taking the time to point to these things. :beer:
I was wondering if there could be collapse buttons/boxes on the cell lines (collapse one cell to expand the other cells in that column or row), but that's really just a nice thing, if even possible.
Re: Mesen - Debugger Feedback?
by on (#183996)
I had a HUGE THOROUGH POST written up to cover several things, links and all, and OH HEY YEAH WHOOPS YOU CLICKED THE [X] IN THE TAB, ENJOY. So now I'm SUPER pissed off. I am quickly reminded why I loathe tabs so much. So yup, now everyone gets Angry Koitsu Post.

You need to offer two modes: "Power Cycle" (alternates include "Power On/Off" or "Power Toggle" (latter sounds corny)), and "Reset" (alternates include "Soft Reset"; don't bother with "Hard Reset": AFAIK, in NestopiaUE, what that actually means is "Power Cycle" -- it just saves the person having to manually pick Power off, then Power on). You may want to offer separate "Power On" and "Power Off" options (and grey out the one which isn't relevant to the current system state), but it's your choice.

Power Cycle = equivalent to physically pressing NES/Famicom POWER button/switch, letting the system sit for about 5 seconds, then powering it back on. This affects ZP/RAM contents, PPU state, and CPU state. Pre-initialised ZP/RAM contents I will cover at the end of this post. PPU state is documented here: http://wiki.nesdev.com/w/index.php/PPU_power_up_state while CPU state is documented here: http://wiki.nesdev.com/w/index.php/CPU_power_up_state -- then JMP to RESET vector, etc..

Reset = equivalent to pressing NES/Famicom RESET button. ZP/RAM contents are untouched, but PPU and CPU state will be (but it varies -- keep reading). JMP to RESET vector, etc. -- you know.

Regarding both PPU and CPU states on power on and reset: READ THE PAGES THOROUGHLY! ALL THE BULLET POINTS! Otherwise you will miss quirks such as: "The Reset button on the Control Deck resets the PPU only on the front-loading NES (NES-001). On top-loaders (Famicom, NES-101), the Reset button resets only the CPU."

Now for the ZP/RAM situation... actually, I don't need to talk about it, because we've already had it! The option to select which pre-init model is super useful. I would also recommend you add a "User-defined value" pulldown option and let the person enter a value in hex (this is helpful for debugging and general use). But references for all of that because certainly someone will come across this again somewhere on the Internet:

https://forums.nesdev.com/viewtopic.php ... 99#p177999 -- read from this post onward (READ, NOT SKIM :-) )

That's all! Okay, now I feel less pissed off. :-)
Re: Mesen - Debugger Feedback?
by on (#184008)
koitsu wrote:
I had a HUGE THOROUGH POST written up to cover several things, links and all, and OH HEY YEAH WHOOPS YOU CLICKED THE [X] IN THE TAB, ENJOY.

Sometimes Ctrl+Shift+T recovers up to the last click of Preview. But now you understand one reason why I often compose long posts in a text editor. (The other is that I'm often offline on my laptop while writing, and then I post it once I get to a WLAN.)

Quote:
Power Cycle = equivalent to physically pressing NES/Famicom POWER button/switch, letting the system sit for about 5 seconds, then powering it back on. This affects ZP/RAM contents, PPU state, and CPU state.

And you can make the power cycle visually distinct by incorporating the same effect you'd get when power cycling an NES connected through RF: about 10 frames of monochrome snow and loud white noise, then about a second of slow panning across a random panel from Pepper&Carrot (simulating the cartoon that was showing on channel 3), then the game comes back with RAM cleared. List this as a bullet point: "We even emulate the RF switch!"
Re: Mesen - Debugger Feedback?
by on (#184151)
I updated the download link with a new build: download
Screenshot of changes: screenshot

-Added option to disassemble everything as code (and also an option to disassemble everything EXCEPT data). Disassembled code that is not verified as code (based on the CDL file) is shown with a light red background.
-Replaced the "Apply changes" button with an "Undo" button - Changes made to the state are applied automatically when the execution is resumed.
-Replaced the "Stop" button with "Power Cycle" instead, which does what it says!
-The bottom panel (watch/breakpoints/call stack) and the right panel (function/label lists) are now both resizable and collapsible panels. Double-clicking on the splitter will collapse the panel and uncheck the corresponding option from the Options menu. (this means the bottom panel can now be hidden)

@rainwarrior
Haven't had the chance to work on a profiler yet, but will probably get that done next.
Are the options to disassemble everything/everything except data what you would except them to do? Is the background color annoying or do you think it's fine that way?

@WheelInventor
I'm not 100% sure what I implemented is what you meant, but hopefully the collapsible panels help with your screen resolution.

@koitsu
I took a look, and there are some things that aren't implemented in Mesen (e.g PPU ignoring register writes at the start)
No major discrepancies though, most of the behavior is correct (assuming a front-loading NES) - I'll try to validate and fix the remaining stuff when I get the chance.
Re: Mesen - Debugger Feedback?
by on (#184180)
Quote:
I'm not 100% sure what I implemented is what you meant, but hopefully the collapsible panels help with your screen resolution.


Not exactly, but not to worry: those handles work perfectly for me and my low-res situation. Thanks!


Here's another suggestion:
Make an item for the new undo function in the dropdown menu and hotkey it to ctrl+z.
Since there's no "edit" menu, i guess it could go under "debug". But you might want to add other items under "edit" eventually.
Re: Mesen - Debugger Feedback?
by on (#184275)
Haven't made a new build yet, but here's what the profiler looks like (using thwaite with symbols imported):
Image
Re: Mesen - Debugger Feedback?
by on (#184311)
Awesome work! Two items for me:

1. Would it be possible to set a relative path for loading files? My use case is I have the following dir structure:

src/
obj/
assets/

The .nes file and all other build output goes into obj (including the .dbg file). When I load the .dbg file with the debugger:

Attachment:
obj1.png
obj1.png [ 19.72 KiB | Viewed 2747 times ]


My current workaround is to just copy over the src dir into the obj dir; although, I still get a few problem paths:

Attachment:
obj2.png
obj2.png [ 5.66 KiB | Viewed 2747 times ]


2. Would it be possible to set a custom transform for label names? This is something I have been meaning to implement with FCEUX. My use case is:

I use modules in CA65 like so:

Code:
; physics.h
.ifndef _PHYSICS_
   _PHYSICS_ = 1
 
  .import _physics_init
  .proc physics
    init = __physics_init
  .endproc
.endif

; physics.s
.export __physics_init
.proc __physics_init
  ...
   rts
.endproc

; in some other .s file
.include "physics.h"
jsr physics::init


and want to transform labels like this "__physiscs_init" into "physiscs::init" for viewing in the debugger.
Re: Mesen - Debugger Feedback?
by on (#184318)
dullahan wrote:
Code:
; physics.h
.ifndef _PHYSICS_
   _PHYSICS_ = 1
 
  .import _physics_init
  .proc physics
    init = __physics_init
  .endproc
.endif

Unrelated note: .scope is probably a better choice here than .proc. .proc creates an unnecessary label physics.
Re: Mesen - Debugger Feedback?
by on (#184319)
Quote:
but as stupid as it may sound, I had no clue how to translate the Soft/Hard reset distinction to French & Japanese, so I ended up not adding it.

Quote:
I've seen these referred to as "warm boot" (soft reset) and "cold boot" (hard reset/power cycle); not sure how well those will translate to French and Japanese, however.

ホットリセット (hot reset) and コールドリセット (cold reset) are in Jisho; given that it has a dedicated source for computer terminology I'm inclined to trust these.

Best I could find for French is also in the hot/cold metaphor, but wasn't in official dictionaries I could find: reset à chaud, reset à froid. This has a number of translations, including just loanwording "soft reset" or putting the adjective after "reset soft". «[Re]démarrage à chaud/froid» also seem to be an option.

Interglot (though I've never used it before, so don't know its reputation) goes for réinitialisation matérielle with the alternative being réinitialisation logicielle.

Of course, we might ask some of our actual resident French speakers…
Re: Mesen - Debugger Feedback?
by on (#184322)
furrykef in #nesdev ran them through Google Translate, got "démarrage à froid" (cold boot) and "démarrage à chaud" (warm boot), and then confirmed their usage in Google Search and in a French Wikipedia article.
Re: Mesen - Debugger Feedback?
by on (#184323)
@dullahan
I've fixed the path finding issue - the code will now go up the path looking for the files until it reaches the drive's root folder.

As for transforming the labels, I guess the simplest way would be to allow the user to setup regular expressions to parse & replace portions of the text?
It's not the most user friendly method, but it is a debugger and all..


@Myask & @tepples
I probably should have mentioned this earlier, but I'm a French native.
To be honest, while "Démarrage à froid" and "Démarrage à chaud" are probably the correct terms technically speaking, I don't believe I've ever heard anybody using them in my life. (To be fair, I am from Quebec - people from France and the like may very well use these).
For the moment, I've settled on "Arrêt & redémarrage" (litt. Stop & restart), which I feel conveys the meaning, and should be understandable for anybody, whether or not they know the technical term for it.

I also ended up using the same logic for Japanese - 停止と再起動 - which is also just "stop and restart".
Re: Mesen - Debugger Feedback?
by on (#184328)
Sour wrote:
@thefox
Thanks for testing!

That amount of errors is pretty impressive! If you had labels in the debugger, then my guess is that it was unable to load the source files.
This would probably be due to the path in the "name" tag for the "file" directives.
Currently the regex I'm using only allows the following characters in paths:
0-9, a-z, A-Z ( ) _ . - : / \
Any chance the paths you have in your DBG file (should be at the very top) contain something outside of these?

Nope, the paths are very normal. Also, I think it was able to load some of the source files at least (can't bother to test again now, but I think I saw some of my source code).
Re: Mesen - Debugger Feedback?
by on (#184389)
thefox wrote:
Nope, the paths are very normal. Also, I think it was able to load some of the source files at least (can't bother to test again now, but I think I saw some of my source code).
Alright, thanks. Either way, I've changed the import's code slightly in the release I just did (0.6.0) which might fix this (no promises though).

There are still some suggestions that were given in this thread that haven't been added to 0.6.0, I have them written down and will get to them eventually.
I've been working on the debugger for dozens of hours over the past few weeks and need to take a break from it!

Thanks again for all the feedback, and if anyone has any other suggestions, don't hesitate to post them!
Re: Mesen - Debugger Feedback?
by on (#190069)
I just spent most of the day on this and am mostly finished rewriting the memory viewer tool in Mesen.
Preview build: download
Note: This build is Windows-only, because making a Linux+Windows package takes a lot more time - Linux users can compile from the latest source code on GitHub, it includes all the changes. (note: I did not test Linux at all yet)

The memory viewer is now a proper hex editor - everything can be edited:
-NES built-in 2k RAM
-PRG ROM, Work RAM, Save RAM
-CHR ROM & RAM
-Palette RAM
-Primary/secondary OAM
-Nametable memory (via the PPU Memory dropdown option)
Note: Attempting to write to addresses mapped to registers or not mapped at all has no effect.

It's now also possible to display a text representation of the binary data.
It supports TBL files, and defaults to ASCII conversion when no TBL file is loaded.
The TBL mappings are saved in the debugger's workspace (independent for each rom debugged)

Example with AllPads rom (which contains ascii encoded text):
Attachment:
hexedit1.png
hexedit1.png [ 65.81 KiB | Viewed 3307 times ]

Example with FF3 (J) with a TBL file loaded to convert to kana:
Attachment:
hexedit2.png
hexedit2.png [ 69.86 KiB | Viewed 3307 times ]

It's possible to search for hex values, or text.
When searching for text, the TBL values are used to produce the corresponding binary data, so you can search for a Japanese string and find it in FF3's text.

The text column supports variable-width characters (and multiple characters per byte) and highlights the right text based on the hex selection:
Attachment:
hexedit3.png
hexedit3.png [ 87.79 KiB | Viewed 3307 times ]

This is one of the main features that was still lacking from Mesen's debugger at this point.
Anyone have any feedback and/or suggestions to improve it?
And please let me know if you get any crashes or find any bugs, too.

PS: Main things left on my todo list at this point:
-A simple visual CHR editor
-Ability to save edited PRG/CHR ROM back to a .nes file
-"Jump list" (i.e like the callstack tool but for all jumps, useful to trace back the execution)
-Scripting
-Add some way to compile/run assembly code, or edit the existing code
Re: Mesen - Debugger Feedback?
by on (#190071)
Sour wrote:
-A simple visual CHR editor
-Ability to save edited PRG/CHR ROM back to a .nes file

This would be killer, particularly if you were to make an oldskool UI reminiscent of Genecyst.
Re: Mesen - Debugger Feedback?
by on (#190082)
I see this continues the gui spaghetti debugger trend ;)

The Debugger code view seems to get confused easily
Attachment:
debug1.png
debug1.png [ 92.96 KiB | Viewed 3271 times ]
here the unknown block is
Code:
                        CPX #$50
                        BNE bC60B
                        RTS

pltXYtoPPU              STX a00
                        STY a01
                        JMP plt_p00_toPPU

clearNMIFlags           LDA #$00
                        STA NMIDoneFlag
                        STA NMIDoVRAMUpdates

Then latter you get to
Attachment:
debug2.png
debug2.png [ 115.26 KiB | Viewed 3271 times ]

Which is really
Code:
                        BNE bF82F
bF826                   JSR sF383
                        LDX #$C0
                        LDY #$C0
                        BNE bF836
bF82F                   JSR sF383
                        LDX #$86
                        LDY #$86
bF836                   JSR sF3D0
                        LDA #$00
                        STA aE4
                        JMP jF40F

bF840                   LDY #$09
                        LDA #$EF
                        BNE bF826
fF846                   .BYTE $0A
fF847                   .BYTE $13
fF848                   .BYTE $1C
fF849                   .BYTE $25
fF84A                   .BYTE $2E
fF84B                   .BYTE $37
fF84C                   .BYTE $40
fF84D                   .BYTE $49
fF84E                   .BYTE $52,$5B,$07,$C3,$F8,$E2,$F8,$08
                        .BYTE $F9,$1B,$F9,$07,$2F,$F9,$60,$F9
                        .BYTE $A1,$F9,$CC,$F9,$07,$AF,$FA,$CA
                        .BYTE $FA,$E4,$FA,$F5,$FA,$07,$DA,$F9


The problem with having the auto magical code on the side is, when it gets confused there is nothing you can do. For example when you have inlined data with code ala
Attachment:
debug3.png
debug3.png [ 115.26 KiB | Viewed 3271 times ]
Code:
$CCA9: A5 31       sCCA9                   LDA BirdEntFSMIndex
$CCAB: 20 5E C3                            JSR jmpA
$CCAE:                                     .WORD JustRTS,setupDogEnt,setDogAnimWalk,dogUpdWalk,setDogAnimSniff
$CCB8:                                     .WORD updHoldFrame,setDogAnimShock,updHoldFrame,setDogAnimStartJump,dogUpdJump
$CCC2:                                     .WORD dogSetupLaugh,updHoldFrame,dogSetupShowDucks,updHoldFrame,setupForNextDuck
$CCCC:                                     .WORD aCE18,aCE2E,updHoldFrame,aCE40
$CCD4: A2 1F       setupDogEnt             LDX #$1F
$CCD6: BD 6E E7    bCCD6                   LDA fE76E,X
$CCD9: 95 30                               STA f30,X
$CCDB: CA                                  DEX
$CCDC: 10 F8                               BPL bCCD6
$CCDE: A9 03                               LDA #$03
$CCE0: 85 BA                               STA NumShotsLeft
$CCE2: A9 01                               LDA #$01
$CCE4: 85 BE                               STA RedrawBulletsFlag
$CCE6: 85 AD                               STA NeedUpdDuckShotRow
$CCE8: A9 02                               LDA #$02                     ;game palllete
$CCEA: 85 23                               STA NextPallete
$CCEC: A5 25                               LDA a25
$CCEE: C9 07                               CMP #$07
$CCF0: D0 05                               BNE bCCF7
$CCF2: A9 10                               LDA #$10
$CCF4: 85 31                               STA BirdEntFSMIndex
$CCF6: 60                                  RTS


Having a Monitor mode would really help with these issues and be nice in general(IMHO). That way I can D CCD4 and see the code I want. or doing the debug display in a live window so I can move up and down a few bytes and it disassembles from the address at the top of the screen.
If you have a monitor that lets you specify labels, breakpoints, watches then you can put a custom file on the the command line params, which then lets you open Mesen, add a bunch of labels, breakpoints etc from an external tool.
Having an option to open the debugger on BRK would be nice also, so I can add a BRK into code and then have the debugger fire on it from my code editor. Also assemblers will pad unused areas with 00, so if the code hits lala land it will stop.
CPU history command is the nectar of the gods. What it does is, it keeps a trace of the last N instructions the CPU performs, so if you code goes bad and you end up in lala land, you can type CHIS and it will show you exactly how it got to lala land - for example this is what it looks like
Code:
** Monitor 177 035
(C:$0c4f) chis
1431  A5 34      LDA $34             :A$16 X$02 Y$00 SP$f2   -
1433  10 01      BPL $1436           :A$02 X$02 Y$00 SP$f2   -
1436  A5 14      LDA $14             :A$02 X$02 Y$00 SP$f2   -
1438  29 08      AND #$08            :A$f7 X$02 Y$00 SP$f2 N -
143a  F0 48      BEQ .mainGameHitDetect_C64VICTriggerSystem__checkRelease :A$00 X$02 Y$00 SP$f2   -   Z
1484  A9 00      LDA #$00            :A$00 X$02 Y$00 SP$f2   -   Z
1486  85 36      STA $36             :A$00 X$02 Y$00 SP$f2   -   Z
1488  85 37      STA $37             :A$00 X$02 Y$00 SP$f2   -   Z
148a  60         RTS                 :A$00 X$02 Y$00 SP$f2   -   Z
091a  20 F1 12   JSR .HUD_updateCurrBird :A$00 X$02 Y$00 SP$f4   -   Z
12f1  24 32      BIT $32             :A$00 X$02 Y$00 SP$f2   -   Z
12f3  10 1C      BPL .HUD_updateCurrBird__exit :A$00 X$02 Y$00 SP$f2 N -   Z
12f5  24 23      BIT $23             :A$00 X$02 Y$00 SP$f2 N -   Z
12f7  10 18      BPL .HUD_updateCurrBird__exit :A$00 X$02 Y$00 SP$f2 N -   Z
12f9  E6 31      INC $31             :A$00 X$02 Y$00 SP$f2 N -   Z
12fb  A0 00      LDY #$00            :A$00 X$02 Y$00 SP$f2   -
12fd  A5 31      LDA $31             :A$00 X$02 Y$00 SP$f2   -   Z
12ff  29 0F      AND #$0F            :A$4b X$02 Y$00 SP$f2   -
1301  D0 0E      BNE .HUD_updateCurrBird__exit :A$0b X$02 Y$00 SP$f2   -
1311  60         RTS                 :A$0b X$02 Y$00 SP$f2   -
091d  20 DF 09   JSR .GFSM_dispatchBirdFunction :A$0b X$02 Y$00 SP$f4   -
09df  A6 24      LDX $24             :A$0b X$02 Y$00 SP$f2   -
09e1  BD F0 09   LDA .BirdFSMLUT_hi,X :A$0b X$01 Y$00 SP$f2   -
09e4  48         PHA                 :A$0a X$01 Y$00 SP$f2   -
09e5  BD EA 09   LDA .BirdFSMLUT_lo,X :A$0a X$01 Y$00 SP$f1   -
09e8  48         PHA                 :A$69 X$01 Y$00 SP$f1   -
09e9  60         RTS                 :A$69 X$01 Y$00 SP$f0   -
0a6a  20 53 0D   JSR .bird_updateBirdAnim :A$69 X$01 Y$00 SP$f2   -
0d53  C6 1B      DEC $1B             :A$69 X$01 Y$00 SP$f0   -
0d55  30 01      BMI $0D58           :A$69 X$01 Y$00 SP$f0   -   Z
0d57  60         RTS                 :A$69 X$01 Y$00 SP$f0   -   Z
0a6d  20 8F 0D   JSR .bird_updateBirdMovement :A$69 X$01 Y$00 SP$f2   -   Z
0d8f  A6 1C      LDX $1C             :A$69 X$01 Y$00 SP$f0   -   Z
0d91  BD AD 33   LDA .BirdYXDeltas,X :A$69 X$09 Y$00 SP$f0   -
0d94  C9 AA      CMP #$AA            :A$ff X$09 Y$00 SP$f0 N -
0d96  D0 07      BNE $0D9F           :A$ff X$09 Y$00 SP$f0   -    C
0d9f  18         CLC                 :A$ff X$09 Y$00 SP$f0   -    C
0da0  65 17      ADC $17             :A$ff X$09 Y$00 SP$f0   -
0da2  85 17      STA $17             :A$97 X$09 Y$00 SP$f0 N -    C
0da4  E8         INX                 :A$97 X$09 Y$00 SP$f0 N -    C
0da5  BD AD 33   LDA .BirdYXDeltas,X :A$97 X$0a Y$00 SP$f0   -    C
0da8  F0 19      BEQ .bird_updateBirdMovement__endAdd :A$01 X$0a Y$00 SP$f0   -    C
0daa  30 0C      BMI .bird_updateBirdMovement__sub :A$01 X$0a Y$00 SP$f0   -    C
0dac  18         CLC                 :A$01 X$0a Y$00 SP$f0   -    C
0dad  65 15      ADC $15             :A$01 X$0a Y$00 SP$f0   -
0daf  85 15      STA $15             :A$50 X$0a Y$00 SP$f0   -
0db1  90 10      BCC .bird_updateBirdMovement__endAdd :A$50 X$0a Y$00 SP$f0   -
0dc3  E8         INX                 :A$50 X$0a Y$00 SP$f0   -
0dc4  86 1C      STX $1C             :A$50 X$0b Y$00 SP$f0   -
0dc6  60         RTS                 :A$50 X$0b Y$00 SP$f0   -
0a70  20 C7 0D   JSR .bird_checkClipEntityXandY :A$50 X$0b Y$00 SP$f2   -
0dc7  A5 15      LDA $15             :A$50 X$0b Y$00 SP$f0   -
0dc9  A6 16      LDX $16             :A$50 X$0b Y$00 SP$f0   -
0dcb  D0 06      BNE $0DD3           :A$50 X$00 Y$00 SP$f0   -   Z
0dcd  C9 18      CMP #$18            :A$50 X$00 Y$00 SP$f0   -   Z
0dcf  F0 23      BEQ .bird_checkClipEntityXandY__offLeftScreen :A$50 X$00 Y$00 SP$f0   -    C
0dd1  D0 04      BNE .bird_checkClipEntityXandY__checkY :A$50 X$00 Y$00 SP$f0   -    C
0dd7  A5 17      LDA $17             :A$50 X$00 Y$00 SP$f0   -    C
0dd9  C9 19      CMP #$19            :A$97 X$00 Y$00 SP$f0 N -    C
0ddb  F0 05      BEQ .bird_checkClipEntityXandY__aboveTopY :A$97 X$00 Y$00 SP$f0   -    C
0ddd  C9 92      CMP #$92            :A$97 X$00 Y$00 SP$f0   -    C
0ddf  F0 07      BEQ .bird_checkClipEntityXandY__belowBottomY :A$97 X$00 Y$00 SP$f0   -    C
0de1  60         RTS                 :A$97 X$00 Y$00 SP$f0   -    C
0a73  20 4F 0C   JSR .bird_setBirdXY :A$97 X$00 Y$00 SP$f2   -    C
(C:$0c4f)

While you have the logger, you have to set it up and it starts to eat RAM and file space and then you have to wade through it all to get what you want, just having a last 64/128 commands on a single command is enough to save the day.

With the hex editor, showing Blue - execute, Green - Read, Red - Write, Yellow Read/Write and being able to turn off decay and then Mark the areas already highlighted. This way you can play game for bit, mark access, do new thing. Immediately see which bit of code was run when you did the thing and which memory locations it accessed to do it. Also handy for finding if code indexes over an array boundary.

Having HardReset/ColdBoot/ColdStart also reloading the ROM file would be worth its weight in gold. I.e see bug, change code, assemble, then ColdStart, where WarmStart just keeps the current code. FYI VICE has the terms RESET > HARD SOFT and its translated into a stupid number of languages so you could look at what they have. I think the way it gets away with it, is it has a parent menu Reset then then opens to options for Hard, Soft, Drive 8, Drive 9, Drive 10, Drive 11 so it doesn't have to translate or show Hard Reset, Soft Reset.

Uppercase opcodes is the CBM standard, mainly because the PET and other computers of the era that followed, TRS-80, Apple ][ only had uppercase character sets so the monitors and assmeblers of the day also did uppercase, once we got to the C64 era where we did have upper and lower case modes, it was such a standard and BASIC was done in all uppercase it just stuck. Although on a PC I type all my code lowercase.
Re: Mesen - Debugger Feedback?
by on (#190085)
Oziphantom wrote:
The Debugger code view seems to get confused easily
I'm not sure what you mean - the debugger keeps track of what it knows to be code. If it cannot tell with certainty that something is code, it is displayed in an unknown block until it can be certain that it is in fact code (e.g usually after it has been executed at least once). The more code you run, the more accurate it becomes.

Oziphantom wrote:
If you have a monitor that lets you specify labels, breakpoints, watches then you can put a custom file on the the command line params, which then lets you open Mesen, add a bunch of labels, breakpoints etc from an external tool.
You can already import labels from CC65 - I'm not sure what you would import breakpoints & watches from?

Quote:
Having an option to open the debugger on BRK would be nice also, so I can add a BRK into code and then have the debugger fire on it from my code editor.
Adding breakpoints on specific instructions should be easy, I'll see what I can do.

Quote:
What it does is, it keeps a trace of the last N instructions the CPU performs
This should be easy to add as well.

Quote:
With the hex editor, showing Blue - execute, Green - Read, Red - Write, Yellow Read/Write and being able to turn off decay and then Mark the areas already highlighted.
This should be much easier to implement than before with the new hex editor.

Quote:
Having HardReset/ColdBoot/ColdStart also reloading the ROM file would be worth its weight in gold.
Hard resets already reload the rom.

Thanks for the feedback!
Re: Mesen - Debugger Feedback?
by on (#190137)
Sour wrote:
Oziphantom wrote:
The Debugger code view seems to get confused easily
I'm not sure what you mean - the debugger keeps track of what it knows to be code. If it cannot tell with certainty that something is code, it is displayed in an unknown block until it can be certain that it is in fact code (e.g usually after it has been executed at least once). The more code you run, the more accurate it becomes.

Well the code highlighted I'm 95% sure had run by the time I took the screenshot, but then later when it has the data which it shows as code with illegals LAX, SLO etc, would have been accessed but defiantly not executed, looking at the code you can see it would crash the system if it had. BTW it is Duck Hunt(world).nes ROM

Sour wrote:
Oziphantom wrote:
If you have a monitor that lets you specify labels, breakpoints, watches then you can put a custom file on the the command line params, which then lets you open Mesen, add a bunch of labels, breakpoints etc from an external tool.
You can already import labels from CC65 - I'm not sure what you would import breakpoints & watches from?


A text editor. What you can do if your IDE doesn't have it own system, is make special labels so for example if we look at this code
Code:
birdUpdate
   jsr mainGameHitDetect_C64VICTriggerSystem
   jsr HUD.updateCurrBird
   jsr GFSM_dispatchBirdFunction
   lda BirdEnts.alive
   beq _noFlyAway
   #ISAEqualTo SkyColour,#kHud.Colours.FlyAwaySky,_noFlyAway
   #ISAMinus HasFirstBirdCrossedActiveLine,_doFlyAwayCheck
   #ISAGTE BirdEnts.y,#160,_noFlyAway
   #STN HasFirstBirdCrossedActiveLine
_doFlyAwayCheck
   #ISAMinus CurrentShot,_doFlyAwayNoShots
   lda FrameCounter
    lsr a
    bcc _noFlyAway
   #DecToHoldFF FlyAwayTimer
   bpl _noFlyAway
   bmi _doFlyAway
_doFlyAwayNoShots
   lda #0
   jsr bird.setBirdToNewDir
_doFlyAway   
   ; need to show dialog here   
   #STAB #kHud.Colours.FlyAwaySky,SkyColour   
   #STAB #kGFSM_Bird_index.updateFlyAway,BirdEnts.functionIndex
   jsr HUD.setupFlyAwaySprites
_noFlyAway   
   #ISANotEqualTo BirdEnts.functionIndex,#kGFSM_Bird_index.empty,_exit
   ; either shot of flew away
   ;#STAB #kMG_FSM_index.endBird,MainGameFSMIndex
   #STAB #kHud.Colours.Sky,SkyColour
   #STAB #kMG_FSM_index.dogShowCatch,MainGameFSMIndex
   #ISAZero NumBirdsShot,_laugh
   #STZ BirdEnts.functionIndex
   jsr HUD.clearFlyAwayBitmapData
   rts
_laugh
   #STAB #kDogShowBirdFSMIndex.SetupLaugh,BirdEnts.functionIndex
;   #STAB #kMG_FSM_index.dogLaugh,MainGameFSMIndex
_exit
   rts
Which has a lot of sub branches and some of the paths don't have convenient labels to latch onto.
Say I want to break after the 'lda BirdEnts.alive beq _noFlyAway' check up the top. I would normally set a break point to the parent function 'birdUpdate' then when it fires, search through the code till I find the part I want then move the breakpoint. What I can do instead is
Code:
birdUpdate
   jsr mainGameHitDetect_C64VICTriggerSystem
   jsr HUD.updateCurrBird
   jsr GFSM_dispatchBirdFunction
   lda BirdEnts.alive
   beq _noFlyAway
_BREAK_
   #ISAEqualTo SkyColour,#kHud.Colours.FlyAwaySky,_noFlyAway

Then I have a script that parses the label file the assembler spits out. I should at this point mention how VICE works. The Label file runs Commands, where the AddLabel command ( abbreviated to al) is used as
Code:
al .birdUpdate $0a9e
al .birdUpdate__doFlyAwayCheck $0ab6 (note I just made the addr up )
....

but you can put any monitor commands in the file. So I scan for file for _BREAK_ which in this case will be al .birdUpdate__BREAK_ $0aa9 to which I then append a
'break $0aa9' to the labels file. When the LoadLabels(ll) is executed ( as a command line argument ) it then adds all the labels then adds the break points. This way I can set breakpoints from my code editor, they are set before the code runs, and I don't have to keep setting and adjusting every time. Also when I change the code and shift everything down as I added some code, the breakpoints get reset in the correct position by me just doing the 'll' command again.
You can also set up watches. Given a variable is defined as, you can then do
Code:
*=$02 ; ZP
CurrentLevel .byte ?
WATCH_LOAD_STORE_CurrentLevel = CurrentLevel
or
WATCH_LOAD_CurrentLevel = CurrentLevel
or
WATCH_STORE_CurrentLevel = CurrentLevel

Where this then finds an appends a 'watch load/store address' command to the labels file. Load = watch read, Store = watch load allowing me to track watches on variables from the text editor as well. Given the variables are assigned dynamically by the assembler it lets me easily set them without having to look it up live in the emulator.
VICE also exposes a TELNET interface to the monitor, so you can "remote debug", however IDE's such as CBM Studio use the telnet to allow dynamic breakpoints. I.e you run code then click on the line you want to break on, since it has its own internal assembler it can work out where it is in RAM, then via the telnet connection it will send a 'break ADDR' command to running VICE to add the break point, VICE then send back what number breakpoint it is, so when you click the breakpoint to remove it, the IDE can send 'delete NUM' to remove it. Although I personally don't use the IDEs ( as their internal assemblers are too weak for my tastes ) a lot of newbies and people returning to the scene head straight for them as they are comfy and help get them back up to speed quickly and let them get things happening.

Probably not something you can really do for CC65 but CA65 should be able to support it.
Sour wrote:
Quote:
Having HardReset/ColdBoot/ColdStart also reloading the ROM file would be worth its weight in gold.
Hard resets already reload the rom.

NICE!!! :D
Re: Mesen - Debugger Feedback?
by on (#190469)
Some more updates: download preview build

PPU viewer: Added a lightweight tile editing tool in the CHR viewer. The selected tile (select by clicking on it in the left-side view) is drawable, can press 1-4 to select palette for left button, right button is color 0. Changes are "live" and can be done while the emulator is running.
Attachment:
tileeditor.png
tileeditor.png [ 68.57 KiB | Viewed 3192 times ]

Hex Editor:
-Ability to highlight read/write/exec bytes and have them fade after X frames
-Ability to freeze memory values to prevent the rom from changing them (right-click on hex editor)
-Added context menu shortcuts (add label, breakpoints, watch)
-Ability to de-emphasize (make semi-transparent) read/written/executed/unused bytes
Attachment:
hexeditor.png
hexeditor.png [ 60.14 KiB | Viewed 3192 times ]

Trace Logger: This now shows recently executed instructions (keeps the last 30k instructions in memory) - this works even if the trace logger window is not opened (but the debugger window must be opened for the instructions to be logged)
Attachment:
tracelogger.png
tracelogger.png [ 60.76 KiB | Viewed 3192 times ]

Debugger:
-Added "break on unofficial opcodes" and "break on BRK" options (breaking on other OP codes is possible via conditional breakpoints)
-Added a "Save ROM as..." option to save ROM file containing any modifications done to PRG ROM or CHR ROM (including via the tile editor tool). (Only works on .nes files for now)
-Conditional breakpoints: Greatly improved performance - can still run at well over 60fps with several conditional breakpoints executing on every CPU instruction

tepples wrote:
This would be killer, particularly if you were to make an oldskool UI reminiscent of Genecyst.
Sorry, it doesn't look very oldskool!

Oziphantom wrote:
Well the code highlighted I'm 95% sure had run by the time I took the screenshot
The debugger needs to be opened while the code runs for it to be properly registered as code - that's probably what happened.
As for importing breakpoints/watch values, I can probably come up with a fairly simple format for it - though I don't expect to go much further than that (e.g: telnet, a console, and the like would take far too much time to add - there are a lot of other things I still want to add to Mesen that would take priority over this)
Re: Mesen - Debugger Feedback?
by on (#190983)
I just finished adding an assembler tool

Features:
-Edit existing code in PRG ROM (or anywhere)
You can multi-select lines in the code window and right-click"Edit selected code" to start editing it.
(I also added a small feature to copy the selected code to the clipboard.)

-Allows you to assemble and add new code anywhere (ram, rom)
-Supports labels & comments (but they are not kept once the code is updated)
-Automatically assembles as you type
-Validates syntax and warns you of errors (as you type the code)
-Any change done to PRG ROM will be saved to the ROM file if you save it (File->Save ROM as)

I've also added a feature that lets you type code in the assembler and run it right away on the CPU ("Execute" button in the screenshot below).
Whatever code you execute ends up being mapped to $3000-$3FFF (it steals the address range from the PPU temporarely) and executes until a write to $3000 is done (or the last list of the code is reached)
After the write to $3000, execution returns to wherever the PC was before.
Registers and the like are not restored, so it's up to the code you use to save/restore values/registers you don't want to alter.
This basically lets you alter the state of anything by using 6502 assembly.

Attachment:
assembler.png
assembler.png [ 38.62 KiB | Viewed 3146 times ]

Attachment:
codewindow.png
codewindow.png [ 40 KiB | Viewed 3146 times ]
Re: Mesen - Debugger Feedback?
by on (#191145)
I took the last preview for a quick spin, good stuff.

Code editing. NICE!!!!

If you could add some nice Syntax Sugar, delete on a row, NOPs it. Handy for removing a JSR line when hunting or trying to figure out what makes something go wrong. Having a restore from ROM option would be nice as well.
Re: Mesen - Debugger Feedback?
by on (#191154)
Oziphantom wrote:
If you could add some nice Syntax Sugar, delete on a row, NOPs it.

I remember the SN Systems debugger for PS3 had this feature. It was pretty handy sometimes.
Re: Mesen - Debugger Feedback?
by on (#191192)
rainwarrior wrote:
Oziphantom wrote:
If you could add some nice Syntax Sugar, delete on a row, NOPs it.

I remember the SN Systems debugger for PS3 had this feature. It was pretty handy sometimes.

Perfect for getting rid of an Assert that is somebody else's problem - and is firing 5 times a frame ;)

With the Trace history could you expand the P from being a hex byte to show the flags, it is really obtuse. Also is it in 6502 silicon order or 6502 Datasheet order?
If you are worried about space you could only show active signals ie.

N--I0-- or NzcI0vb -> NI for negative and Interrupt
Re: Mesen - Debugger Feedback?
by on (#191309)
Thanks for the feedback - I've added an option to select the output format for the status register: "Hexadecimal", "Text" or "Text (Active only)" - which corresponds to the original format + the 2 suggested alternatives (I didn't update the download yet though)

The removed code is already turned into NOPs - deleting a line will add a corresponding number of NOPs at the end of the edited block. It would be relatively complex to insert the NOPs where the deletion(s) occurred, considering you can also delete/insert/modify other portions of the code as well.
As is, you can already re-edit the code, delete the NOPs at the bottom & add the line you had deleted back. You do have to remember the erased code's exact location to be able to do this, though.

I'll also add "Discard PRG changes" and "Discard CHR changes" when I get a chance (to reset code/graphic modifications done with the hex/chr/code editors)
Re: Mesen - Debugger Feedback?
by on (#193844)
It is really hard to get the debugger to stop based upon an input and sequence of inputs, as I can't invoke the functions from the emulator window. Ctrl + Break will stop code flow but only the debugger is the focus window. Also Ctrl + break, can't just have break?
Then I'm trying to set the joypad input data to something, and step in over etc in code, but oh no the wrong window has focus and I press F8 and it loads a save state trashing my debug session as the main window not the debugger had focus so I can press Up. Is it possible when in the debugger to lock the Debuggers function keys to be trapped by the debugger and not do "emulator" based tasks? Or even have the ability to directly manipulate the controller in the debug screen so I can step through code with specific joypad data?
Re: Mesen - Debugger Feedback?
by on (#194051)
Yea, this is something rainwarrior had mentioned before, and something I find annoying at times too.
I think the main problem is just the F1-F12 key shortcuts - maybe those specifically could be ignored in the main window and redirected to the debugger window when it is active? It would prevent loading save states by mistakes, which is really the number 1 problem. I could add break as a shortcut on the main window, too.

Having a way to "force" the controller input in the debugger is not a bad idea, I'll add it to the list.
Re: Mesen - Debugger Feedback?
by on (#194745)
I've just updated to 0.8.1 and stepping in the debugger is erratic. Sometimes I do step over and then after 4 or 5 steps it just runs until it hits another breakpoint, or steps into the end of a function that is called a couple of code lines down. Sometimes step into also just ends up running.
Re: Mesen - Debugger Feedback?
by on (#194767)
This is something I noticed and fixed yesterday, actually - the call stack is also bugged because of it.
What version were you using before? As far as I can tell, I broke this when I implemented the option to break on "BRK" and unofficial opcodes, in 0.8.0.

It'll be fixed in the next release - the meantime you can use the older version if you need it (you can download it on the releases page on GitHub)
Re: Mesen - Debugger Feedback?
by on (#194809)
Probably 0.8.0 but before I was mostly hit break points and run, with my debugging, rather than stepping through the logic.
Re: Mesen - Debugger Feedback?
by on (#195751)
The step over/into issues in the debugger are fixed in 0.9.0 - sorry for the wait!
Let me know if you find any other issues.