The debugger is the main part of the debugging tools available in Mesen. This window displays the disassembled code, allows you to configure breakpoints, labels and watch values. It also contains a large number of options and smaller features – all of which are described below.
Most elements in the debugger’s interface have right-click menu options - make sure you explore the right-click options available in each list and window.
Watch expressions, breakpoints and labels are automatically saved on a per-rom basis in a Workspace.
You can completely reset the workspace for a specific rom by using the File→Workspace→Reset Workspace command.
There are a number of different tools that can be used to search/navigate the code:
All keyboard shortcuts can be customized in Options→Customize Shortcut Keys
The font used in the code window can be customized in Options→Font Options→Select Font
The colors used for syntax highlighting can be changed in Options→Configure Colors
Various portions of the debugger can be hidden/shown via Options→Show
The code window displays the disassembled code and contains a number of features and options.
Set Next Statement
command to change the next instruction to be executed.Disassemble…:
Show…:
Display OP codes in lower case: When enabled, OP codes are displayed in lowercase letters
Show Effective Addresses: When enabled, the resulting address of indirect addressing modes (e.g LDA $3321, Y
) will be displayed next to the instruction in blue. e.g: @ $3323
Show Memory Values: When enabled, every line of code that refers to a specific address in memory will display that address’ current value on the right.
Byte Code Display: When enabled, the byte code matching the instructions will be displayed next to them (either on the left, or on the line below based on your selection)
PRG Address Display: When enabled, the address matching the actual position of an instructions in PRG ROM will be displayed next to the CPU address (or replace it entirely, based on your selection)
This section of the debugger window displays the CPU and PPU’s current state.
While execution is paused, most fields are editable. Altering the value of any field will change its corresponding value in the emulation core. To undo any edits you have done by mistake, click the “Undo Changes” button.
This section lets you force certain buttons to be held down on the NES’ controller. This is often useful when trying to debug input-related code.
Clicking on a button on the mini NES controllers will toggle its state - green buttons are currently being held down.
The watch window and watch list allow you to evaluate expression and see their value. The Watch Window
is a standalone window that can be resized and moved independently from everything else, whereas the Watch List
is a part of the main debugger window for quick access to watch expressions.
To add a new watch expression, click on the last empty line in the list to enter edit mode.
To edit a watch expression, double-click on it to enter edit mode.
You can use the right-click context menu to delete or move entries, as well as select formatting options.
An import and export feature is also available to save/load watch expressions from a plain text file.
The syntax is identical to C/C++ (e.g &&
for AND, ||
for OR) and uses the same operator precedence as well.
Use the $ prefix to denote hexadecimal values (e.g: $FF
) or the % prefix for binary values (e.g: %1101
)
The following operators are supported (same usage/precedence as C):
*
, /
, %
, +
, -
, <<
, >>
, <
, <=
, >
, >=
, ==
, !=
, &
, ^
, |
, &&
, ||
, ~
, !
, (
, )
Additionally, the following special operators exist:
[$8000]
will read the value at address $8000 and return it.{myLabel}
will read 2 bytes of memory at the address represented by the myLabel
label and return its value:
before an address/label will return the offset of the corresponding address within that memory type. If an address is not mapped to any type of memory, -1
will be returned.
:$8000
will return the offset in PRG ROM of the byte currently mapped at the CPU address $8000.The following “variables” can be used in both the watch window and contional breakpoints to check the state of specific portions of the emulation core.
Numeric values
Flags
It is possible to customize the format of each entry by adding a suffix to the expression. Suffixes contain a single letter and are optionally followed by a number indicating the number of bytes expected in the return value (up to 4).
The available suffixes are:
S
- Signed decimal valueU
- Unsigned decimal valueH
- HexadecimalB
- BinaryFor example, suffixing an expression with:
, H2
will display the result as a 2-byte hexadecimal value (e.g: 26, H2
will display as $001A
), B
will display the result as a binary value (e.g: 141,B
will display as %10001101
), S2
will display the result as a 16-bit signed decimal value (e.g: $FE4F, S2
will display as -433
), U
will display the result as an unsigned decimal value (e.g: 180, U
will display as 180
)You can select the default format to use for entries without prefixes by right-clicking and choosing between:
S4
to all entries - displays the result as 32-bit signed decimal values)H1
to all entries)B1
to all entries)
[$10] //Displays the value of memory at address $10 (CPU)
a == 10 || x == $23
scanline == 10 && (cycle >= 55 && cycle <= 100)
x == [$150] || y == [10]
[[$15] + y] //Reads the value at address $15, adds Y to it and reads the value at the resulting address.
{$FFFA} //Returns the NMI handler's address.
[$14] | ([$15] << 8), H2 //Display the value of the 2-byte variable stored at $14 in hexadecimal format.
Using labels
Any label defined in the debugger can be used in watch expressions (their value will match the label’s address in CPU memory).
For example, if you have a label called “velocity” that points to 1-byte value at address $30 in the CPU’s memory, you can display its value in the watch using the following syntax: [velocity]
Displaying arrays
The watch window allows you display several consecutive memory values on the same row using a special syntax. e.g:
[$30, 16] //This will display the values of addresses $30 to $3F
[MyLabel, 10] //This syntax can also be used with labels
Breakpoints define conditions under which the execution of the game’s code will be suspended. Any number of breakpoints can be defined.
You can also make a breakpoint appear as a mark on the Event Viewer by checking the M
column.
To add a breakpoint, right-click the breakpoint list and select Add.
To edit a breakpoint, double-click on it in the list.
To disable a breakpoint, uncheck it.
To delete a breakpoint, right-click on it and select Delete
To view the breakpoint in the code, right-click on it and select Go to location
Breakpoints can be set to trigger based on CPU/PPU memory accesses at specific memory addresses.
Breakpoint Type
Select the type of memory for which you want to set a breakpoint. The valid range of addresses for the breakpoint will vary based on the selected memory type.
Break On
Select which types of accesses (read, write or execute) should trigger the breakpoint.
Address
Select which address or address range this breakpoint should apply to.
It is also possible to specify no address at all by selecting Any - in this case, breakpoints will be evaluated on every CPU cycle.
Condition (optional)
Conditions allow you to use the same expression syntax as the one used in the Watch Window to cause a breakpoint to trigger under specific conditions.
Process breakpoint on dummy reads/writes
When enabled, the breakpoint will be processed for dummy reads and writes (only available for read or write breakpoints). When disabled, the debugger will never break on a dummy read or write for this breakpoint.
Mark on Event Viewer
When enabled, a mark will be visible on the Event Viewer whenever this breakpoint’s conditions are met. This can be used to add marks to the event viewer based on a variety of conditions by using conditional breakpoints.
Break Execution
This enables the breakpoint - if this is disabled, the execution will not break when the breakpoint is hit.
Examples
To break when the sum of the X and Y registers is 5:
x + y == 5
To break when the value at memory address $10 is smaller or equal to $40:
[$10] <= $40
To break when the CPU writes the value $60 to any address:
IsWrite && Value == $60
The call stack displays the currently executing function, and all functions that are below it on the stack. The top of the list is the current function, while the row below it is the location that the code will return to once the current function executes the RTS instruction. The call stack also displays NMI and IRQ routine handlers and processes calls to RTI in the same manner as calls to JSR and RTS.
Note: Rows shown in gray and italic represent portions of the call stack that are currently not inside the CPU’s memory (e.g because the PRG banks were changed since that point in the execution).
Labels: When labels are defined for the PRG ROM offset matching the function’s entry point, that label is shown as the function’s name in the call stack.
To view the code at any location in the call stack, double-click on the row.
Labels can be used to simplify debugging. They allow you to give names to variables and functions which will be used instead of numeric addresses when viewing the code in the debugger. Labels can also be used to display single and multi-line comments to the code.
The label list displays every label defined in alphabetical order.
To add a label, right-click in the label list and select Add
.
To edit a label, right-click in the label list and select Edit
.
To delete a label, right-click in the label list and select Delete
.
To add a breakpoint to a label, right-click in the label list and select Add breakpoint
.
To add the label to the watch, right-click in the label list and select Add to watch
.
To find where a label is used, right-click in the label list and select Find Occurrences
.
To view the code at the label’s location, double-click on the label in the list.
To view the label in the hex editor, use any of the View in CPU memory
/View in PRG ROM
/View in Save RAM
/View in Work RAM
options.
Show Comments
controls wheter or not code comments that are not labelled are shown in the label list.
Show Automatic Jump Labels
determines whether or not the labels that are automatically generated by the Auto-create jump labels
option are shown in the label list.
Note: Labels shown in gray color and italic font are currently not mapped in CPU memory.
Various types of labels can be defined:
There are some restrictions on what a label can contain – in general, they must begin with a letter or an underscore and cannot contain spaces or most non-alphanumeric characters. Labels can also contain a comment which is shown in the code window as well as in the tooltips that are displayed when putting your cursor over a label in the code window.
Multi-byte labels can be defined using the Length
setting. This can be used to define multi-byte values, arrays or pointers in the code. Multi-byte labels will be shown with a +X offset modifier when referred to in the code window (e.g: MyArrayLabel+2
)
The function list is similar to the label list and allows you to easily add or edit the name of functions (which are also labels).
Unlike the label list, which only displays labels, the function list displays all known functions, including those with no labels. This is useful to quickly check an unnamed function’s code (by double-clicking on it) and give it a name. This can help when attempting to reverse-engineer code.
The CPU and PPU memory mappings are visual aids that display information about the currently selected PRG/CHR banks and the nametable configuration.
The banking configuration represents Mesen’s internal representation of the mapper in use, which may not exactly match the mapper’s specs. For example, a mapper with 2x 8 KB + 1x 16 KB PRG banking is emulated as 4x 8 KB internally, so it will appear as four 8 KB banks.
The Show...
submenu contains a number of options to show/hide various elements on the UI.
Specifically, the toolbar, CPU/PPU memory mappings, function/label lists, watch list, breakpoint list and the call stack window.
A number of tooltip-related options are available here:
The Break Options
submenu contains a number of options to configure under which conditions the debugger will break (even when no breakpoint is hit):
Enable OAM RAM decay
option is enabled in the Emulation Settings
.Enable sub-instruction breakpoints: This option allows Mesen to process breakpoints in the middle of CPU instructions. This was the default up to version 0.9.7. When this option is disabled, the debugger will break at the beginning of CPU instructions only (and will only break once per instruction). This option is disabled by default as of 0.9.8.
Additionally, you can configure whether or not the debugger window gets focused when a break or pause occurs.
These options configure which portions of the code is copied into the clipboard when copying code from the code window.
L#####
, where #####
is the label’s location in PRG ROM.Draw Partial Frame
, the previous frame’s data will be shown behind the current frame.R
is read, W
is write, X
is execution, DR
is a dummy read, and DMC
is an APU DMC readDebugger “workspaces” are used to store information specific to each ROM you debug. This includes watch expressions, breakpoints and labels.
By default, Mesen setups labels for the NES’ PPU and APU registers. These can be disabled using the Disable default labels
option.
Additionally, it’s possible to setup your own set of default labels by creating a file called DefaultLabels.Global.mlb
in the Debugger
folder (where the workspace and CDL files are stored). When Mesen finds this file, it will ignore the its own default labels and use the ones contained in that file instead, for all ROMs.
You can also setup default labels for specific mappers by creating a file called DefaultLabels.[mapper number].mlb
(e.g, for MMC3 games: DefaultLabels.4.mlb
).
For FDS and NSF ROMs, DefaultLabels.FDS.mlb
and DefaultLabels.NSF.mlb
can be used, respectively.
If both a global and mapper-specific mlb
is found, both of them will be used (with the mapper-specific file having priority in case of conflicting labels).
.mlb
files are a Mesen-specific file format to define labels/comments in the code. They are written in a simple text format and can also be created by using the debugger’s Export Labels
feature.
From the code window, you can right-click on an address and activate the “performance tracker”. This feature will track when the selected address is executed by the CPU on each frame, and display a CPU/FPS chart overlay based on those statistics.
By setting the performance tracker to the part of the code that most games use to wait for vertical blank after the next frame’s logic is done processing, you can get an estimate of how much extra CPU time remains on each frame.
From the code window, you can select code (via click and drag, or shift+arrow keys) and use the “Edit Selected Code” command to open the Assembler and edit that section of code. The assembler recognizes labels and allows you to define temporary labels as well. If the new code is smaller (in terms of bytes) than the original code, the extra bytes will be replaced by NOPs. If the new code is larger, it will override whatever comes next in the code – a warning will be shown beforehand in this case. When you’re ready to apply your modifications, press the Apply button.
If you want to save your code modifications to a .nes file, or as an IPS patch, you can use the File→Save or File→Save edits as IPS commands.