Instruction focus bar isn't always on the correct instruction when stepping.

[TheStruggleForAntiSpaghetti]

When stepping through the code by using Step Into or Step Over in the code editor, the instruction focus bar is regularly not following along and highlighting the correct instruction. Next presses skip to the correct instruction all of a sudden.

Interestingly, when I use the application to make the screen recording (ScreenToGif) it is actually skipping much more instructions in succession.

[Dotneteer]

I can see this phenomenon in the recorded GIF. My only problem is that I cannot reproduce it on My Mac (with M1 ARM CPU), even when running in emulated Windows. I have ideas about what can be wrong. Would you help me with an experiment?

Please try the same scenario with the Z80 CPU and the Breakpoint panels hidden or collapsed. You can even hide the entire left sidebar by clicking on the blue-highlighted debug icon. Can you reproduce the same phenomenon?

Could you perhaps check the CPU usage with the Windows Task manager?

[TheStruggleForAntiSpaghetti]

With the Z80 CPU and the Breakpoint panels shown or hidden, it doesn't happen.

If I minimize the emulator window, it doesn't happen.

But with the emulator window visible, it happens. It doesn't make a difference if Instant Screen updates is on or not.

My CPU utilization isn't abnormally high in all scenarios - max 50%

[Dotneteer]

Thanks for the experiment; it has a lot of helpful information! The bottleneck is the refresh frequency I use to update the information in the CPU (250ms) and the Breakpoints panel (500ms). Such a refresh requires IPC communication between the emulator and IDE Windows (they run in different processes). Due to the Electron shell architecture, it can happen only through the main process (a third one). While it's pretty fast on specific machines (mine shows an average of 8.57% CPU usage with Klive), a usage of around 50% may cause missed refresh cycles. I suspect this issue is behind the phenomenon you mention.

I have ideas on how to fix it. First, I will allow setting selecting a refresh rate (such as 500ms, 1s, 2s). Of course, when the machine's state changes (e.g., it gets paused), the views will be immediately refreshed.

I will work on it, and hopefully, in a few days, I will have a private build for you.

[TheStruggleForAntiSpaghetti]

Don't know enough about how it's constructed, but could you set a flag in mem when pressing the button, and the other thread(s) repeatedly reading the flag and if set, update? This way it would not be timing dependent?

[Dotneteer]

I will find a way that refresh (automatic refresh) will work in a way that won't cause such issues.

[Pete-L-72]

Subbed. Also running on Windows - on a mediocre laptop.

[Dotneteer]

Here is the new private build (see v0.38.0): https://1drv.ms/f/c/79da757d3d2b5baa/QqpbKz19ddoggHlnPAkAAAAAyMaLSBXRXrYANw

This build contains fixes for these issues: #880, #875, and #839

I managed to find a way (without any additional settings you should change) to make the debugging resilient to heavier CPU usage. I also tried it on my wife's mediocre Windows laptop. I improved the debugging experience, breakpoints, and some debugger glyphs.

[Pete-L-72]

Tried this briefly this morning. It's definitely MUCH better but there were some instances where it didn't synch up correctly. When I have more time I'll try to figure out what works vs what doesn't.

[TheStruggleForAntiSpaghetti]

I'm not experiencing it any more, even under heavy load (as with the ScreenToGIF screen recording).

@Pete-L-72 Does it happen perhaps on HALT statements? As you have to Step Over them if you'd just like to continue with the next instruction instead.

[Pete-L-72]

From my brief testing it was on a jr. And I just reproduced the same thing again. So the PC is moving to the jump location but the screen isn't updating and I have to hit F10 a second time for the screen to update, at which point it'll be on the second line after the jump target.

[TheStruggleForAntiSpaghetti]

@Pete-L-72 Are you testing in the code editor view, or the disassembly?

@Dotneteer I do experience the phenomenon in the disassembly view.

[Pete-L-72]

In the code view. I may have narrowed this down. Or perhaps had the same coincidence play out several times.

If you create a new project - so the default hello world app - and insert a bunch of empty lines before the last two lines of the loop such that they are off the top of the screen, sometimes stepping will fail to move screen focus to show the line of code that "step over" jumped to. It's not specific to the jr at the end, sometimes the focus will fail to update when stepping from "rst 10" to "inc hl".
With the same sample project but without inserting the extra empty lines that cause the loop to span multiple screens high I haven't been able to upset the PC display, it seems to be working correctly.

So this is what I'm rambling about:

Start:
    .model Spectrum48
    .org #7C00
    ld a,2;	      ; upper screen
    call #1601    ; open the channel
    ld hl,Message ; HL points the the message string
NextCh:
    ld a,(hl)     ; get next character
    or a
    jp z,#12a9    ; jump back to main cycle when terminated
    rst #10       ; display character













; Inserting enough newlines to stretch
; the loop across multiple screens seems
; to cause the screen to stick displaying
; either the top or bottom half of the
; loop despite the PC moving to the
; other half.












    inc hl        ; next character
    jr NextCh     ; next loop

Message:
    .dm "\a\x0A\x06" ; AT 10, 6
    .dm "\p\x04"     ; PAPER 4
    .dm "Welcome to Klive IDE"
    .dm "\a\x0B\x08" ; AT 10, 8
    .dm "\p\x04"     ; PAPER 4
    .dm "\b\x01"     ; BRIGH 1
    .dm "(ZX Spectrum 48)"
    .db 0x00         ; terminate

[Dotneteer]

Thanks for examining this issue in details. I will try to reproduce it again (following your instructions). I will immediately notify you when I find something.