charlietunaz Posted February 24, 2021 Share Posted February 24, 2021 (edited) I ran the code below in Classic 99 and I opened the debugger to watch and learn about breakpoints and reading register values. The program places the ball in the middle of the screen, then moves it down and wraps around to row 1 when it reaches the bottom row. I placed two breakpoints in A092 (mov R4,R0) and A09C (ai R2,>0001). A092 is right before updating the position of the ball, and A092 is comparing the current position to check if it went past row 24. I notice the position at R2 is updating fine, however, when I click the Normal Speed option sometimes the program skips one of the breakpoints, and the ball moves two rows at once. I'm not sure if this is a debugger glitch or there's something in the code that is not right. I've been clicking carefully using the keyboard and the mouse to make sure I'm not double clicking. I think the skipping happens in the same places all the time, so it's not random either. * CSL 02/22/2021 * BOUNCING BALL * DEF BBALL REF VSBW,VMBW,VWTR MYREG BSS >20 BALL DATA >3C7E,>FFFF,>FFFF,>7E3C *BALL PATTERN * BALL INITIAL POSITION ROW EQU >C COL EQU >10 * BBALL LWPI MYREG * PROGRAM START * CLEAR SCREEN LI R0,>0 * START OF VDP RAM LI R1,>2000 * PLACE SPACE (>20) CLEAR BLWP @VSBW INC R0 * NEXT SCREEN POSITION CI R0,>0300 * CK IF LAST POSITION (768) JNE CLEAR * IF NOT, CONTINUE * CHANGE SPACE BACKGROUND COLOR TO BLACK LI R0,>0384 * COLOR ADDRESS FOR SPACE LI R1,>B100 * COLOR YELLOW (B) ON BLACK (1) BLWP @VSBW * CHANGE SCREEN COLOR BORDERS LI R0,>0711 BLWP @VWTR * DEFINE BALL CHAR LI R0,>0C00 * PATTERN ADDR FOR CH >80 LI R1,BALL * DATA LI R2,8 * NUMBER OF BYTES BLWP @VMBW * SET BALL COLOR LI R0,>0390 * COLOR ADDRESS LI R1,>B000 * COLOR YELLOW (B) ON TRANSP (0) BLWP @VSBW * DISPLAY BALL LI R2,ROW MBALL LI R3,>20 MPY R2,R3 * R4 = (ROW * 32) AI R4,COL * + COL MOV R4,R0 * ROW & COL ADDRESS LI R1,>8000 * PLACE BALL CHAR (>80) BLWP @VSBW CLR R8 * DELAY INC R8 CI R8,>05DC JNE DELAY * MOV R4,R0 LI R1,>2000 BLWP @VSBW * ERASE BALL FROM CUR POS AI R2,>01 * GO DOWN ONE ROW CI R2,>17 * CHECK IF BOTTOM ROW JLE MBALL LI R2,>00 JMP MBALL END BBALL I added a video demonstrating what I wrote above. Please watch closely at 1:30 and 2:10 how the debugger goes from A092 and skips the breakpoint at A09C. Then the ball moves twice. Desktop 2021.02.23 - 22.39.07.04.mp4 Edited February 24, 2021 by charlietunaz Added video. 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted February 24, 2021 Share Posted February 24, 2021 Have you tried to use F1 to resume the program instead of selecting Normal speed? 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 24, 2021 Share Posted February 24, 2021 Yeah, use F1,F2,F3 for operating the debugger, the speed controls are for the running emulation. It's probably still in the process of updating the system when the breakpoint is bypassed. 1 Quote Link to comment Share on other sites More sharing options...
charlietunaz Posted February 24, 2021 Author Share Posted February 24, 2021 Yup, I realize now that F1 is a pause/continue toggle. Still the same result; I was just curious about the debugger's operation/behavior, to feel more comfortable with it in case I have to trace a more complex program in the future. The program as it is, seems to be running normally at regular speed. Thanks! Quote Link to comment Share on other sites More sharing options...
Asmusr Posted February 25, 2021 Share Posted February 25, 2021 Maybe you get an interrupt at that point? Try turning off interrupts with LIMI 0. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 25, 2021 Share Posted February 25, 2021 For what it's worth, I too have found that when break points are really close together, the second one is often skipped. There seems to be neither rhyme nor reason to it: If I tap F1 really fast it will sometimes break; if I hold down F1 it sometimes breaks; but many other times it just goes past the second break point without stopping. It could be my equipment: an old Dell rescued from the trash; the old keyboard which in Classic99 sometimes registers a double keypress; or Wndows XP running in a virtual box on a linux OS which is badly in need of updating. I have learned to live with it, adjusting the break points as needed so it will stop where I want it to. 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted February 25, 2021 Share Posted February 25, 2021 3 hours ago, senior_falcon said: For what it's worth, I too have found that when break points are really close together, the second one is often skipped. There seems to be neither rhyme nor reason to it: If I tap F1 really fast it will sometimes break; if I hold down F1 it sometimes breaks; but many other times it just goes past the second break point without stopping. It could be my equipment: an old Dell rescued from the trash; the old keyboard which in Classic99 sometimes registers a double keypress; or Wndows XP running in a virtual box on a linux OS which is badly in need of updating. I have learned to live with it, adjusting the break points as needed so it will stop where I want it to. Yea the problem is Keypress is repeated so it skips it. Here is the GPL code to look for Break Key and check it: [2608] 9138 8E,80,84 G9138 CZ @RAMTOP If ERAM exist then [2609] 913B 71,40 BS G9140 [2610] 913D 06,91,79 CALL GRMLST Fake it : move each line to t [2611] * CRUNCH buffer form ERAM [2612] 9140 06,6A,74 G9140 CALL LLIST List the current line [2613] 9143 03 SCAN Test for a break key [2614] 9144 51,4E BR LISTZ3 No key [2615] 9146 D6,75,02 CEQ BREAK,@RKEY [2616] 9149 71,5F BS LISTZ4 [2617] 914B 03 LISTZ5 SCAN [2618] 914C 51,4B BR LISTZ5 [2619] 914E 8E,80,84 LISTZ3 CZ @RAMTOP If ERAM exists [2620] 9151 71,56 BS G9156 [2621] 9153 BD,2E,58 DST @FAC14,@EXTRAM Restore the @EXTRAM [2622] 9156 A7,2E,00 G9156 DSUB 4,@EXTRAM Pointer to next line 9159 04 [2623] 915A C5,0E,2E DCH @EXTRAM,@CURINC Display all lines in range [2624] 915D 51,38 BR G9138 [2625] 915F 8E,17 LISTZ4 CZ @DSRFLG Device I/O -> output last rec [2626] 9161 51,6D BR G916D [2627] 9163 06,96,A5 CALL OUTREC Output the last record [2628] 9166 06,97,5E CALL IOCALL Close the device properly [2629] 9169 01 BYTE CZCLOS [2630] 916A 05,60,1A B TOPL10 [2631] 916D 05,60,12 G916D B TOPL15 Restart the variable too Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 25, 2021 Share Posted February 25, 2021 Classic99 is a windows program. I am quite sure it does not use the TI keyscan to detect F1 to break or restart the program. Quote Link to comment Share on other sites More sharing options...
RXB Posted February 25, 2021 Share Posted February 25, 2021 29 minutes ago, senior_falcon said: Classic99 is a windows program. I am quite sure it does not use the TI keyscan to detect F1 to break or restart the program. Yea Windows does buffer the keys so thus is terrible at detection of keys and gets it wrong constantly. Example have to stand on the Print Screen key to get it to work on some applications thanks to windows sucks at how it checks for keys. Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 26, 2021 Share Posted February 26, 2021 Weird. I do occasionally see missed breakpoints, but usually after some kind of branch. I've never had problems with the keypresses. The keys are tracked as an active state via the windows key messages, and special keys like the debugger keys clear that state whether the key is still down or not... so unless you are holding long enough to trigger auto-repeat, I'm surprised that you are having such behaviour. Remember that F1 is Run/Stop, and F2 is step. Don't use F1 to step. Dunno what else you might be seeing. Quote Link to comment Share on other sites More sharing options...
charlietunaz Posted February 26, 2021 Author Share Posted February 26, 2021 6 minutes ago, Tursi said: Weird. I do occasionally see missed breakpoints, but usually after some kind of branch. I've never had problems with the keypresses. The keys are tracked as an active state via the windows key messages, and special keys like the debugger keys clear that state whether the key is still down or not... so unless you are holding long enough to trigger auto-repeat, I'm surprised that you are having such behaviour. Remember that F1 is Run/Stop, and F2 is step. Don't use F1 to step. Dunno what else you might be seeing. The problem with stepping using F2 is that when it goes through the delay loop it takes forever. F1 stops when it reaches the breakpoints. I guess I could comment the delay just to try it out though. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted February 26, 2021 Share Posted February 26, 2021 I have tried to assemble the code, and I'm seeing the same issue as charlietunaz (also with LIMI 0). Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted February 26, 2021 Share Posted February 26, 2021 On 2/23/2021 at 9:07 PM, charlietunaz said: * CSL 02/22/2021 * BOUNCING BALL * DEF BBALL REF VSBW,VMBW,VWTR MYREG BSS >20 BALL DATA >3C7E,>FFFF,>FFFF,>7E3C *BALL PATTERN * BALL INITIAL POSITION ROW EQU >C COL EQU >10 * BBALL LWPI MYREG * PROGRAM START * CLEAR SCREEN LI R0,>0 * START OF VDP RAM LI R1,>2000 * PLACE SPACE (>20) CLEAR BLWP @VSBW INC R0 * NEXT SCREEN POSITION CI R0,>0300 * CK IF LAST POSITION (768) JNE CLEAR * IF NOT, CONTINUE * CHANGE SPACE BACKGROUND COLOR TO BLACK LI R0,>0384 * COLOR ADDRESS FOR SPACE LI R1,>B100 * COLOR YELLOW (B) ON BLACK (1) BLWP @VSBW * CHANGE SCREEN COLOR BORDERS LI R0,>0711 BLWP @VWTR * DEFINE BALL CHAR LI R0,>0C00 * PATTERN ADDR FOR CH >80 LI R1,BALL * DATA LI R2,8 * NUMBER OF BYTES BLWP @VMBW * SET BALL COLOR LI R0,>0390 * COLOR ADDRESS LI R1,>B000 * COLOR YELLOW (B) ON TRANSP (0) BLWP @VSBW * DISPLAY BALL LI R2,ROW MBALL LI R3,>20 MPY R2,R3 * R4 = (ROW * 32) AI R4,COL * + COL MOV R4,R0 * ROW & COL ADDRESS LI R1,>8000 * PLACE BALL CHAR (>80) BLWP @VSBW CLR R8 * DELAY INC R8 CI R8,>05DC JNE DELAY * MOV R4,R0 LI R1,>2000 BLWP @VSBW * ERASE BALL FROM CUR POS AI R2,>01 * GO DOWN ONE ROW CI R2,>17 * CHECK IF BOTTOM ROW JLE MBALL LI R2,>00 JMP MBALL END BBALL ...was going to have at it for a moment ...but this code seems terribly misaligned ...don't have the time or patience to fiddle with the keyboard that much! I think I like it a tad better this way(above). Sorry. 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted February 26, 2021 Share Posted February 26, 2021 Here's the object file. BBALL-O 1 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 26, 2021 Share Posted February 26, 2021 As I noted, I've seen missed breakpoints around branch instructions. Your second breakpoint is right after the BLWP. Try moving it down one instruction and see if that is more reliable. Let me know. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted February 26, 2021 Share Posted February 26, 2021 Thanks, mine seems to skip as well. >A092 three times in a row, three times out of 20. >A09c twice in a row. Only once, did both instructions trap! This is also a mystery... I created the .jpg seen in the post, at 2:08pm. definitely not 12 hours ago! Since the post I'm responding to, wont be available for another 1 1/2 Hrs... ...If your reading this before 4pm, you're probably seeing a mirage. P.S. I really aught to stop jaunting from post-to-post.? 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted February 26, 2021 Share Posted February 26, 2021 (edited) 40 minutes ago, Tursi said: As I noted, I've seen missed breakpoints around branch instructions. Your second breakpoint is right after the BLWP. Try moving it down one instruction and see if that is more reliable. Let me know. I thought the same and tried that, but it didn't help in my case. For me it misses something like 3 out of four of the second breakpoint. Edited February 26, 2021 by Asmusr Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 26, 2021 Share Posted February 26, 2021 So I dug into this a bit, since it does hit me sometimes too, and my theory about branches holds no water. I found it and fixed it - there was a race with the Windows message pump. Basically, hitting F1 to continue would update the internal emulation state, resume the CPU, etc, and send a message off to update the Window menu state. If you breakpointed again before Windows processed the message, the CPU would be stopped correctly, then Windows would receive the "hey, we're playing again" message, and start the CPU back up. The fix was to differentiate between command messages and visual update messages, already done in a few places. The next update is nearly ready and should be out this weekend, hopefully. 6 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted February 26, 2021 Share Posted February 26, 2021 1 hour ago, Tursi said: So I dug into this a bit, since it does hit me sometimes too, and my theory about branches holds no water. I found it and fixed it - there was a race with the Windows message pump. Basically, hitting F1 to continue would update the internal emulation state, resume the CPU, etc, and send a message off to update the Window menu state. If you breakpointed again before Windows processed the message, the CPU would be stopped correctly, then Windows would receive the "hey, we're playing again" message, and start the CPU back up. The fix was to differentiate between command messages and visual update messages, already done in a few places. The next update is nearly ready and should be out this weekend, hopefully. Great you found it. I rarely had the need for multiple breakpoints, so I guess that's why I haven't seen this before. The reason I mentioned interrupts (besides the point that you should never access the VDP with interrupts turned on) is that I have a vague idea that sometimes I have missed a breakpoint if I continued execution at the same time as there was an interrupt, but I really don't know. 1 Quote Link to comment Share on other sites More sharing options...
charlietunaz Posted February 26, 2021 Author Share Posted February 26, 2021 1 hour ago, Tursi said: So I dug into this a bit, since it does hit me sometimes too, and my theory about branches holds no water. I found it and fixed it - there was a race with the Windows message pump. Basically, hitting F1 to continue would update the internal emulation state, resume the CPU, etc, and send a message off to update the Window menu state. If you breakpointed again before Windows processed the message, the CPU would be stopped correctly, then Windows would receive the "hey, we're playing again" message, and start the CPU back up. The fix was to differentiate between command messages and visual update messages, already done in a few places. The next update is nearly ready and should be out this weekend, hopefully. That's great, thank you for looking into this! 1 Quote Link to comment Share on other sites More sharing options...
charlietunaz Posted February 26, 2021 Author Share Posted February 26, 2021 14 hours ago, HOME AUTOMATION said: ...was going to have at it for a moment ...but this code seems terribly misaligned ...don't have the time or patience to fiddle with the keyboard that much! I think I like it a tad better this way(above). Sorry. Well, apparently another glitch, but on this page maybe? because my code looks aligned from here. I copied and pasted it straight from Notepadd++ using the <code> tag on this page. 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted February 26, 2021 Share Posted February 26, 2021 Likely, it is the use of the tab character which will not translate to a specified number of spaces. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 26, 2021 Share Posted February 26, 2021 1 hour ago, Asmusr said: Great you found it. I rarely had the need for multiple breakpoints, so I guess that's why I haven't seen this before. The reason I mentioned interrupts (besides the point that you should never access the VDP with interrupts turned on) is that I have a vague idea that sometimes I have missed a breakpoint if I continued execution at the same time as there was an interrupt, but I really don't know. Yeah, I can't see any evidence for that. I wouldn't rule it out, but interrupts are triggered on the same thread as the breakpoints, so it SHOULD be okay. 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.