Commander X16

So.. I switch to version r43 to be able to use the new scan code mechanics, and while that is working great... I needed to use the debugger (The one activated by using -debug in the emulator command line.) and it seems to let me set a breakpoint, but now displays it as 6 digits and when I press F5 and run the program, it doesn't stop at the breakpoint.

The most recent update made breakpoints bank-specific, so I presume the extra two digits are the bank number when the target address is within a bankswitched area.

That's a reasonable assumption. Both of the extra digits are 0, which I would expect as I'm not using banks nor am I anywhere near that address range.

I tested the debug breakpoint in R43, and it worked when I started the emulator with x16emu -debug 1100, that is a breakpoint at $1100.

It also worked when I started the emulator with x16emu -debug 3a000, a breakpoint in bank 3, address $a000.

Looking at the emulator source code, it parses the number after -debug as follows:

• The number is interpreted as a HEX value
• If number is less than a000, the breakpoint is set to that address with no bank
• If the number is equal to or greater than a000, bits 0..15 are the breakpoint address and bits 16... are the breakpoint bank

I've never used the breakpoint like that, I run the emu without having it start the program, then hit F12 to open the debugger, set the debug point with "d 1234", press F9 to set the breakpoint, then hit F5 to run, type RUN to start the program. The breakpoint then hits.

So I changed the makefile to do it through the command line... look at that! That worked, but it displayed the breakpoint as 4 digits after it stopped. I would prefer not to have to be constantly editing the makefile for this, but it's certainly better than not having breakpoints.

Daedalus wrote: ↑Fri May 26, 2023 8:33 pm I've never used the breakpoint like that, I run the emu without having it start the program, then hit F12 to open the debugger, set the debug point with "d 1234", press F9 to set the breakpoint, then hit F5 to run, type RUN to start the program. The breakpoint then hits.

So I changed the makefile to do it through the command line... look at that! That worked, but it displayed the breakpoint as 4 digits after it stopped. I would prefer not to have to be constantly editing the makefile for this, but it's certainly better than not having breakpoints.

I just tested that and it seems to work for me. If you could give an exact example of what you're doing and how it's not working I'd like to know. I'm the one who made the change, so I really want to make sure it's working.

Ender wrote: ↑Sat May 27, 2023 12:16 am

Daedalus wrote: ↑Fri May 26, 2023 8:33 pm I've never used the breakpoint like that, I run the emu without having it start the program, then hit F12 to open the debugger, set the debug point with "d 1234", press F9 to set the breakpoint, then hit F5 to run, type RUN to start the program. The breakpoint then hits.

So I changed the makefile to do it through the command line... look at that! That worked, but it displayed the breakpoint as 4 digits after it stopped. I would prefer not to have to be constantly editing the makefile for this, but it's certainly better than not having breakpoints.

I just tested that and it seems to work for me. If you could give an exact example of what you're doing and how it's not working I'd like to know. I'm the one who made the change, so I really want to make sure it's working.

Ok. But it will have to wait until tomorrow. I'll zip up the project I'm working on and give precise instructions. It's perfectly repeatable, at least as far as I can tell. Is there an email address I can send that to, or can I use the "Private message"? I also have no problem with just posting it as a download that can then be removed or whatever.

Wait. I'm an idiot. I have a github account. I'll just make a public repo for it. Doh! I'm so used to working by myself.

Down to me. When i wrote it, the emulator was in a very alpha state, so it is deliberately not deeply integrated into the emulation to minimise risk.

One of the issues is you have one source of keys (the PS/2 scan codes) but two targets - the emulator & debugger and the target application. What this means in practice is that debugging the keyboard stuff by "normal" means is difficult.

Ok, I think I narrowed down the culprit a bit.

First, I'm using the x16emu_linux-x86_64-r43.zip from the github page. All ways through the site seem to go to the same page and the same list of downloads. It's also the same one this morning as I downloaded earlier this week.

Next, my computer is a Ryzen 5800 running Linux Mint Cinnamon version 21.1 with all the latest updates. I use Linux Mint pretty much bone stock, with only some UI adjustments like putting the dock on the side.

I use cl65 to compile .asm files and link them into an executable with a .PRG extension. Everything is in assembly, No C code.

Earlier this week, I started a new project that's a "Command Shell" that presents a unix like terminal interface for VERA systems, the first step was to throw a program together consisting of components from other projects that were leading up to the Command Shell, namely a sprite, tile and palette editor and it's UI and interrupt code.

Ok, that gets us to yesterday. Things are going great. The scan code stuff goes in without a hitch, the interrupt handler is modified to handle tracking the Shift, Alt, and Ctl states, upper and lower case characters are all mapped in. Everything is great. I haven't even had to use the debugger yet in this entire process. (Ominous fore-shadowing.)

So then, Oh Noes! There is a minor bug in the UI control system that breaks it. I need to set a breakpoint in the program's start up code so it will hit after the program runs, but before I can interact with it through the mouse or keyboard. This happens all the time, and I have a process to do this:

First, I run the makefile to do a full compile so my .sym list is up to date, then look at that to find the breakpoint I want to set. It's this one:
al 001AE5 .term_create_line

Next, I rerun the makefile again (I don't really have to do this, but occasionally I'll be ready at the debugger and only then realize the breakpoint I wanted wasn't in the .sym list.) In the makefile, the last command is to run the emulator. It uses this command line:
../x16emu -prg xsh.prg -scale 2 -debug

That loads the program, but doesn't run it. So the X16 starts up in BASIC mode with the program loaded.

Before I type RUN, I use F12 to show the debugger, then:
d 1ae5
F9
F5

That gets me back to the BASIC screen so I can type RUN and start the program. It should hit the breakpoint right away.
Instead, the programs just runs normally and never breaks to the debugger. Well poo. And things were going so well.

It is suggested on the forum that it works if I set the breakpoint in the command line itself. So I edit the makefile so the final command is:
../x16emu -prg xsh.prg -scale 2 -debug 1ae5

That works fine! The breakpoint hits and all is right with the world. I fix my laughably stupid "off by 1" bug and go home.

This morning, I think: "Hmm. What if the problem is the part where I have to go back the the BASIC screen and run the program?"

So I find another breakpoint that I can hit in the normal execution of the program. I compile, and instead of setting up a breakpoint BEFORE running the program, I just type RUN in the BASIC screen to run the program.

Then I hit F12, enter d 1a6a to set the breakpoint that will then hit when I try to type a character into the command line, F9 to set the breakpoint and finally F5 to continue the program.

Type a key and Pop! The breakpoint hits in the spot I set it.

So if works if you put the breakpoint in the command line, and it works if you add the breakpoint AFTER you run the program, but it fails if you set the breakpoint while still in the BASIC screen.