no$gba - nocash gameboy advance / nintendo ds debugger
Source Level Debugging and Profiling The no$gba disassembler displays any labels that are used in source code (and of course, that labels are also recognized in user input). Mixed Thumb and Arm opcodes are automatically disassembled as such. Additionally, your source code can be displayed in stacked view mode, that is, the associated disassembled opcodes are displayed below of each line of source code. For better legibitly, the source lines are drawn by light blue background color, moving the cursor onto a source line displays the corresponding line number and source filename in status bar. No$gba supports debug info in .ELF, DWARF2, and .SYM formats. No$gba displays the execution time in clock cycles each time when starting and stopping the emulation, eg. after executing a sub-routine. The power gauge displays the current CPU load (assuming that unused CPU time is spent in low power state). The nocash clock cycle comments display the execution time for each disassembled opcode, different view modes are available - it can display formulas (eg. "1N+3S+1I") (optionally split into separate code and data cycles), and it can resolve that formula into actual number of clock cycles (by automatically recursing the current address and waitstate configuration, etc. - the results are kinda interesting: some opcodes take only 1 cycle, others may eat up about 100 cycles). And, it can calculate the sum of cycles for a sequence of instructions. Profiling and clock cycle counting allows to make faster and smoother software, and to free up more CPU time - either for battery power saving, or for additional effects.
Conditional Breakpoints & Automatic Warnings The debugger covers a wide range of breakpoints, which are able to 'freeze' the emulation - even when debugging interrupt handlers. Aside from normal 'stop' breaks, it also supports conditional breaks (for example when writing a specific value to specific address, or when writing or changing a value inside of a specified memory area). Also, there's possibilty to define breakpoints (and text messages) in source code. Of course, basic operations like tracing (either single opcodes, or complete sub-routines) and stopping when reaching the currently selected line are supported as well. Aside from user configured breaks, the debugger also includes built-in warning messages which are (optionally) notifying the user of suspicious operations, such like writes into ROM, accesses of invalid or mis-aligned memory addresses, etc. These features are helpful to locate both 'obvious crashes' as well as 'hidden bugs' which may show up only in certain situations, or only in later builts - or not until the game is released (in fact, no$gba finds bugs in most distributed commercial titles). NB. Such features are likely to be found only in software debuggers - which are more flexible than hardware debuggers.
