kelli217 wrote: ↑Thu May 08, 2025 2:33 pm
BruceRMcF wrote: ↑Thu May 08, 2025 1:08 pm
kliepatsch wrote: ↑Thu May 08, 2025 9:31 am Is it just the F9 key that is not working?
(Haven't tried that myself yet)
Just wanted to mention there is a register in the memory map which disables emulator key shortcuts: $9FB7. Just an idea if that flag might be set, although admkttedly it's unlikely to happen on accident
https://github.com/x16community/x16-emu ... -registers
Just the F9 key ... the function keys in the debugger aren't alternatives for command line commands, they are the only way to do their actions, so F12 starts the debugger when the Monitor has hit a break point, I think F5 goes back, F10 and F11 single step (I normally have the emulator Doc open in a tab to double check which is the single step that doesn't passes over subroutine calls and returns).
The only function keys I use otherwise use regularly are F2 and F4 for Excel, so it could just be a bad key.
This is a stupid suggestion because it relies on other software packages being installed, but... run DOSBOX with GW-BASIC, and try hitting the F9 key in that environment. It should come up with
KEY when you press it.
Oh, it's not a stupid suggestion for the most common sense of "stupid" -- if I was keen to be able to set breakpoints inside the debugger, I might well do that, so thanks for the suggestion. Indeed, if I am ever using a different program and
its F9 isn't working, I hope I remember that. Nothing wrong with having another excuse to install DOSBOX (indeed, if I ever return to my back burner project of implementing a 65C02 Forth-79, having DOSBOX and F79 would be a good way to confirm that what I implement matches the most common "Forth79" system people would have experienced back in the day).
However, I'm an old man with old eyes, and even if the lenses have been updated to man-made materials, the debugger display gives me eyestrain if I use it for an extended period. So I'm fine with setting breakpoints the old fashioned way with BRK instructions in my source code, doing most of my debugging in the Monitor, and saving my use of the debugger for the single-stepping that the Monitor can't do.
And in any event, VICE's debugger/monitor has spoiled me with the ability to set multiple breakpoints, to check in at several steps in the routine being debugged ... so hard BRK points in the source fits better with the debugging workflow I am transitioning from.