-
Notifications
You must be signed in to change notification settings - Fork 32
(#425) Add missing 'f', 'w' uart monitor commands (and a few repairs) #426
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- added of 'f' (fill) and 'w' (watch) commands - repair of 'r' (registers) command to match output of hardware more closely
| m65mon_show_regs(); | ||
| paused = 1; | ||
| } | ||
| if (watchpoint_addr != -1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recall from past PRs, you were sensitive to adding extra logic into the main loop, understood.
This is just the first implementation approach that came to mind. If you feel this isn't a good way to go, no problem. If you can think of another/better way, ok, let's try that. If not, no worries, let's skip 'w' and save it for another time.
| #ifdef HAS_UARTMON_SUPPORT | ||
| if (XEMU_UNLIKELY(breakpoint_pc == cpu65.pc)) { | ||
| DEBUGPRINT("TRACE: Breakpoint @ $%04X hit, Xemu moves to trace mode after the execution of this opcode." NL, cpu65.pc); | ||
| m65mon_show_regs(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gardners made a change in the hardware uartmon so that whenever a breakpoint or watchpoint hits, it spits out the register information.
Not only that, he injects an extra "comma" in this output, to help his m65 tooling detect when a breakpoint was hit.
I'll point out the location of that extra 'comma' in another comment...
So what you see here is me trying to replicate his new 'r' output, to enough of an extent to fool his 'm65' tool into thinking it's talking to real hardware.
| umon_printf( | ||
| "\r\n" | ||
| "PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO\r\n" | ||
| "PC A X Y Z B SP MAPH MAPL LAST-OP P P-FLAGS RGP uS IO\r\n" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MAPH and MAPL ordering were wrong (compared to hardware)
| ((map_mask & 0x0F) << 12) | (map_offset_low >> 8), | ||
| ((map_mask & 0xF0) << 8) | (map_offset_high >> 8), | ||
| ((map_mask & 0xf0) << 8) | (map_offset_high >> 8), | ||
| ((map_mask & 0x0f) << 12) | (map_offset_low >> 8), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Swaped to suit changed order of MAPH followed by MAPL
| "%04X %04X %02X %02X %02X " // from MAPL to P | ||
| "%c%c%c%c%c%c%c%c ", // P-FLAGS | ||
| "%c%c%c%c%c%c%c%c \r\n" // P-FLAGS | ||
| ",0777%04X\r\n", // TODO: single line of disassembly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's the line with the extra comma.
Normally, on hardware, 'r' command would show output like this:
<dbg>r
PC A X Y Z B SP MAPH MAPL LAST-OP In P P-FLAGS RGP uS IO ws h RECA8LHC
E1AF FF 00 FD 00 00 01F4 B300 E300 6C4A03 00 A4 N.E..I.. ...P 46 - 00 - ..c..l.c
,0777E1AF B0 31 BCS $E1E2
One of our tools (I think 'm65') is very sensitive in looking for that comma, to indicate that a breakpoint was hit.
| umon_printf(":%08X:", addr); | ||
| while (n--) | ||
| umon_printf("%02X", debug_read_linear_byte(addr++)); | ||
| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why I chose to implement it this way over what you had previously is because if you see how the hardware does it, when you type something like: "M 777d000" you see in the output an address of "0777xxxx":
<dbg>M 777d000
:0777D000:00000000000000000000000000000000
:0777D010:001BA8000000C9002460E10000000000
...but in xemu presently, it would output with an address of "000xxxx":
<dbg>M 777d000
:000D000:00000000000000000000000000000000
:000D010:001B00000000C9002470F10000000000
| m65mon_dumpmem16(par1); | ||
| else | ||
| m65mon_dumpmem28(par1); | ||
| for (int k = 0; k < 16; k++) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it's true that the old 'M' command would spit out 32 lines, the latest 'M' command on hardware only spits out 16 lines.
…hings over from mega65.c to uart_monitor.c
| Author: Gurce Isikyildiz <[email protected]> |------------------------------------------------------------------------- | This is PR #426 from Gurce to handle issue #425 - thanks!! | I (LGB) had to squash the commits and apply them locally because of the | fact that I had already two non-pushed commits in my local repository | also with some already modified files and such ... Original commits in PR: Date: Mon Feb 17 10:20:02 2025 +1100 repairs made to get cherry-picked commands working. Also moved some things over from mega65.c to uart_monitor.c Date: Mon Feb 17 04:34:19 2025 +1100 underway with some cleanup Date: Mon Feb 17 02:16:34 2025 +1100 - minor repairs to how m/M commands are presented (to match hardware) - added of 'f' (fill) and 'w' (watch) commands - repair of 'r' (registers) command to match output of hardware more closely See: #426 Note: Regardless of the PR status there, it was merged directly by me (LGB).
|
Already merged! Just not via this interface but using git CLI. Thus I close this now. |
The commit message describes the gist of it: