Additional debugger features

[drhelius]

• Improve debugger scroll
• RAM search
• Memory watch
• Memory find
• Step Into / Out
• Audio debugger
• Logger (emu logs, state of CPU, current instruction)
• Break on cycles/instructions passed
• Run to address
• Address bookmarks in debugger and memory editor
• Simplify breakpoints (read, write, execute)
• Copy paste from memory
• Save disassembly to text file
• Add new debug symbols from debugger window
• Breakpoints for VRAM, palette, registers
• Editable registers
• Option to initialize memory, registers, MPRs, etc with 0x00, 0xFF or random

[ToughkidDev]

There doesn't seem to be a way to directly change register values ​​while debugging.
This would be very useful.

[drhelius]

Added to the list

[ToughkidDev]

Since I have decided to participate, I will actively share my opinions.
When saving code as a text file, it seems that the OPCODE is missing.
Could you add it? Including OPCODE as comments, as displayed in Windows, would be very useful when analyzing the text file.
Your emulator is a blessing even from a developer's perspective.

[drhelius]

Thanks for your comments.

Yes, it's very easy to add.

[ToughkidDev]

I'm really glad that it has been extremely useful.
Thank you.

[jbrandwood]

What .sym file format(s) do you support, from which assembler(s)?

This doesn't seem to be documented, and the source code for add_symbol() in gui_debug_disassembler.cpp doesn't contain any comments that would help.

[drhelius]

What .sym file format(s) do you support, from which assembler(s)?

This doesn't seem to be documented, and the source code for add_symbol() in gui_debug_disassembler.cpp doesn't contain any comments that would help.

Thanks for bringing this to my attention.
It supports PCEAS, wla-dx and vasm symbol files. Added it to the readme.
If you feel that anything is missing or not working properly let me know.

[jbrandwood]

Thanks for bringing this to my attention. It supports PCEAS, wla-dx and vasm symbol files. Added it to the readme. If you feel that anything is missing or not working properly let me know.

I'll try a test soon, I'm just writing a new test ROM to confirm some of the edge cases of the VDC's DMA behavior for Mesen2's author.

I don't know if you saw, but PCEAS's "classic" .sym file format changed slightly a few months ago, and it now also supports a modified form of wla-dx's .sym file format so that it can provide source-level-debugging information to Mesen2.

I don't know if you plan to add source-level-debugging to Geargrafx, but even if not, you may wish to support the new .sym format if only to be able to read things like the size or is-a-function information for the symbols.

Best wishes,

John

[drhelius]

I don't know if you saw, but PCEAS's "classic" .sym file format changed slightly a few months ago, and it now also supports a modified form of wla-dx's .sym file format so that it can provide source-level-debugging information to Mesen2.

Source-level debugging is not planned for now. As in my other emus this is just a project for fun and learning. I usually focus on the emulation part and Geargrafx still lacks a lot of work on it.

But I will check the changes in PCEAS .sym format. Could you point me to where it is discussed?

[jbrandwood]

Source-level debugging is not planned for now. As in my other emus this is just a project for fun and learning. I usually focus on the emulation part and Geargrafx still lacks a lot of work on it.

There are some small quirks in the VDC access timings and when and just how long the CPU is stalled that will break certain games if you don't get the VCE -> VDC -> CPU interactions just right. Good luck!

But I will check the changes in PCEAS .sym format. Could you point me to where it is discussed?

The details haven't been publicly discussed as such, only the results.

Here's a summary of the format that I'll clean up a bit more and add to the HuC/HuCC/PCEAS repository, as you'll see, it's basically inspired by wla-dx, but with all of the block names changed because the contents are just a little bit different ...

; Generated by PCEAS

[information]
version 1

[source-files]
0001 "sgx_test.lst" ; IgnoreColumns=30
0002 "sgx_test.s"
0003 "..\..\..\include\hucc\hucc.asm"
...

    i.e.
    <filenumber> <filename>


[definitions]
00000000 SUPPORT_ADPCM
00000001 USING_MPR7
00000010 SGX_VDC_OFFSET
...

    i.e.
    <value> <symbolname>


[symbols]
00:4000 80000000 0001:000001e2:00 core_boot
00:e021 80000000 0001:00000233:00 core_hw_reset
00:e18c 80000000 0001:000006cb:00 _farpeekw.1
00:eaf0 80000000 0001:0000309d:00 _sgx_spr_get_y
00:ff13 c0000000 0001:00003109:00 _load_map.6
00:fff4 00000002 0001:000001b6:00 core_version
...

    i.e.
    <bank:address> <size> <filenumber:linenumber:columnnumber> <symbolname>

    n.b.
    <size> is OR'd with $80000000 for CODE, or $c0000000 for FUNC


[bank-to-source]
00:4000 80000003 0001:000001e2:00
00:4003 00000003 0001:000001ef:00
00:e04b 80000001 0001:0000024e:00
00:ff4f c000000a 0001:0000220e:00
00:ff59 c000000a 0001:000022bd:00
01:6000 00000008 0001:00001f48:00
01:cd17 80000003 0001:00002f1f:00
...

    i.e.
    <bank:address> <size> <filenumber:linenumber:columnnumber>

    n.b.
    <size> is OR'd with $80000000 for CODE, or $c0000000 for FUNC

Please note that the "classic" PCEAS symbols use this format for symbols in Street Fighter II banks ...

1:40	6000	SAZ_VDC_DATA			
1:40	6000	saz_vdc				
2:7f	6000	SAZ_VCE_DATA			
2:7f	6000	saz_vce				

... where the first number before the ':' marks the 512KByte overlay number.

In the new Mesen2 .sym format, extra Street Fighter II 512KByte banks are just shown as banks >= $100, in blocks of 64 banks.

100:6000 00000000 0002:00000127:00 SAZ_VDC_DATA
100:6000 0000160b 0002:00000129:00 saz_vdc
17f:6000 00000000 0002:0000013e:00 SAZ_VCE_DATA
17f:6000 0000006a 0002:00000148:00 saz_vce

[drhelius]

Here's a summary of the format that I'll clean up a bit more and add to the HuC/HuCC/PCEAS repository

Thanks a lot for the information!

[ToughkidDev]

There is an inconvenience where the addresses displayed in the saved code from the debugger differ from the addresses pointed to by the opcodes. I would appreciate it if the addresses shown in the debugger could be added to the saved code's addresses. Also, I would like the symbols currently displayed in the debugger to be directly applied to the saved code. Ultimately, it would be best if the disassembler output from the debugger were applied exactly as it is to the saved code.

[drhelius]

There is an inconvenience where the addresses displayed in the saved code from the debugger differ from the addresses pointed to by the opcodes. I would appreciate it if the addresses shown in the debugger could be added to the saved code's addresses. Also, I would like the symbols currently displayed in the debugger to be directly applied to the saved code. Ultimately, it would be best if the disassembler output from the debugger were applied exactly as it is to the saved code.

Thanks for reporting I'll take a look

[drhelius]

There is an inconvenience where the addresses displayed in the saved code from the debugger differ from the addresses pointed to by the opcodes.

The current "save to file" dialog saves all disassembled code to file. Including the code that is not presented in the window because is in other (not selected) banks. It uses physical address for this, that's why you see it doesn't match.

I added a new option so in addition to that you can "save to file" the current view of the disassembler window.

[ToughkidDev]

The current "save to file" dialog saves all disassembled code to file. Including the code that is not presented in the window because is in other (not selected) banks. It uses physical address for this, that's why you see it doesn't match.

I added a new option so in addition to that you can "save to file" the current view of the disassembler window.

That’s a great idea.
Both types of disassembly files are beneficial to me and solve everything I need.
I sincerely appreciate it.

[ToughkidDev]

Hello, it seems that the currently saved memory data are missing addresses. If the dumped memory file does not contain the referenced addresses, it will be difficult to read.

Additionally, while storing memory as a text file is a good approach, saving it in binary format can also be useful for effectively utilizing the dumped memory. I would appreciate it if you could consider both options.

I pay my respects to you for your dedication to the advancement of the emulator.

[drhelius]

it seems that the currently saved memory data are missing addresses.

Can you elaborate? I can't see this issue. The disassembler works by translating each instr as soon as it is executed, in real time. It doesn't run ahead. If you save a dump and then execute more code, this new code will not be in the dump. Is that the case?

while storing memory as a text file is a good approach, saving it in binary format can also be useful for effectively utilizing the dumped memory.

I don't understand this. You can save a binary representation of the memory using the memory editor window, including the rom.

[ToughkidDev]

Could you please watch this video?
https://youtu.be/U-qnWdY5jOg?si=WLraF4Spek-w83-k

Build 1.0.0-23-g047ce82
Built on: Feb 11 2025 - 03:18:00
macOS build (Apple Silicon) Arm64 version

it seems that the currently saved memory data are missing addresses.

Can you elaborate? I can't see this issue. The disassembler works by translating each instr as soon as it is executed, in real time. It doesn't run ahead. If you save a dump and then execute more code, this new code will not be in the dump. Is that the case?

while storing memory as a text file is a good approach, saving it in binary format can also be useful for effectively utilizing the dumped memory.

I don't understand this. You can save a binary representation of the memory using the memory editor window, including the rom.

[ToughkidDev]

while storing memory as a text file is a good approach, saving it in binary format can also be useful for effectively utilizing the dumped memory.

I am asking whether it can be saved as a binary file, that is, a raw file.

[ToughkidDev]

I don't understand this. You can save a binary representation of the memory using the memory editor window, including the rom.

Let me summarize my point once again. As seen in the video I uploaded, GearGrafx saves memory dumps in a text file format. My suggestion is to add addresses, as shown in the window, to make it more convenient.

Additionally, I would like to suggest adding a feature to save memory dumps in a binary format (Raw). A Raw file saved in binary format can be useful in many ways

[drhelius]

@ToughkidDev There are two options now:

• Save as text file: mimics what is presented on the screen, number of columns, etc.
• Save as binary file: creates a binary with the memory dump.

[ToughkidDev]

I'm not sure if my opinion is generally a requirement for other users, but nonetheless, I sincerely appreciate your proactive response. Thank you.

@ToughkidDev There are two options now:

• Save as text file: mimics what is presented on the screen, number of columns, etc.
• Save as binary file: creates a binary with the memory dump.