VICE Debugging Not Working
Closed this issue · 7 comments
Extension v2.5.9 and VS Code v1.91.1. I set up a project and try to debug an acme assembler program with VICE. It worked a couple of times for testing yesterday, but today no joy. The emulator launches, but the VS Code debugger waits not doing anything, and I would see a "RUN:" error in the emulator. After some analysis, I noticed it was loading my program at $1001 even though the source code and the .PRG) starts at $1200. I added the +basicload switch to the emulator args and now it loads at the correct address with no "RUN:" error, but it doesn't execute. If I manually SYS my start address ($1200) from the emulator BASIC prompt then my debugger breakpoint is hit.
Why isn't the debugger starting execution? I was going to try the moncommands switch, but before I do it seems like this should be working and I just have something configured incorrectly.
Hmm. I need to think and look into it a bit - don't have a quick answer...
That .PRG, what's the encoded load address in the first two bytes? Is there a way for me to reproduce super quick?
Anything you can send to me (maybe even the packed project folder) would be very appreciated.
(PS. Are you running VICE on Linux or Windows or MacOS?)
This is on Windows.
Ok, I repro'ed from scratch, and the first part acts the way I expected, i.e. it loads at the correct address without +basicload. I suspect that misbehaves if I've been fiddling with the settings too much. Onto to execution...
-
File...Add Folder to Workspace and create/add a new folder.
-
View...Command Palette...VS64:Create ACME Assembler Project
-
Change main.asm to this:
*=$1200- inx
jmp -
- inx
-
Set breakpoint on inx instruction (F9)
-
Run...Start Debugging (F5)
Emulator shows "RUN:" with no error.
VS64 output shows
"D/Debug.ViceProcess.stdout: AUTOSTART: Injecting program data at $1200 (size $0004)"
(This is better than I was getting.) -
Stop debugging
-
Go into the emulator monitor (ALT+H)
-
Disassemble at 1200 (d 1200)
Yes, the program did get loaded.
Does this extension require that the code be started from BASIC? Maybe there needs to be an extension setting for ML people to issue a binary monitor command to execute the load address after everything is loaded successfully.
Problem understood. Thanks for the detailed description.
What you're trying to do is currently unsupported with the VICE integration - simply because I could not find out what command line args to set to directly jump to the start address (or as you do, initiate a "SYS **" call) after auto-loading a PRG to the destination address. So, indeed, loading a PRG and auto-running it with vs64/VICE does require you to provide a BASIC header (which again is nothing else then the automatic execution of a SYS call taken from the start of the BASIC memory).
A limited workaround is to use the build-in 6502 CPU emulator, which properly detects the start address and jumps straight to the beginning of your program.
As soon as I learn (or get told) how to inject PRGs and jump to their custom start address, I can give it another try - until that, the only way I could think of is to patch a SYS call to BASIC using the monitor protocol, but that could be limited by synchronization difficulties between emulator reset, injection of the PRG and patching memory - which all happens along asynchronous requests/responses.
Simpler solution is (what I do in the examples as well) to simply add a BASIC header to your program.
*=$0801
!byte $0c,$08,$b5,$07,$9e,$20,$34,$36,$30,$38,$00,$00,$00
*=$1200
ldx #1
stx $400
rts
Kind regards,
Roland
How about "Registers set (0x32)" to set the program counter after the emulator is running?
Yes, I can rig it. In this example, if I want to run at $1200 using BASIC then I have a blank 1K region in the .PRG just to have the ML positioned correctly.
- Rod
Yes, setting the PC with the "Registers set" request was my idea as well. Will give it a try, but as said before - could get us down a terrible rabbit hole of async behaviours (well, maybe not).
Well, actually, you answered my question; it's working as designed. Let me try moncommands first, and otherwise try discovering some other hacks.
Thanks.
Tried out patching memory before and after AUTOSTART. Unfortunately, it is what I expected: RESET is getting triggered, and then the monitor interface just goes on (while the machine actually performs the reset routines). For the debugger, it is not possible (at least not easily and without hacks) to detect end of reset - so, what happens is that my patched memory will randomly be wiped out or overwritten by reset. VICE somehow internally knows better how to handle, because the AUTOSTART monitor command correctly awaits end of reset and then injects the .PRG to RAM, then starts.
The option to not performa a reset might be kind of risky as it keeps the machine in a completely undefined state when restarting the debugger.