#201 Show the frame in progress while debugging for accuracy=pixel
When openMSX is running on step-by-step mode, the acuracy=pixel doesn't seem to work properly. The screen is updated with an enormous lag from the CPU writes. It feels like the frameskip is set to a high value, even if maxframeskip is set to zero. This is very bad for debugging, as one would hope the excellent accuracy=pixel should work as good as it does when the emulation isn't debug-breaked.
Curiously enough, the accuracy=pixel works fine even with set speed=1 (which means 1% of the real emulation speed). So I wonder why doesn't it work correctly when using "debug break" and "debug step"
Tested with:
open0.7.2-dev11023
Mac OS-X v10.5.8
renderer=SDLGL-PP
maxframeskip=0
z80_freq_locked=on
r800_freq_locked=on
Emulated machines tested: Panasonic FS-A1ST, Panasonic FS-A1WSX, Sony HBD-F1XDJ, Panasonic FS-A1F
The rendering, regardless of the accuracy setting, happens to an in-memory buffer. Only when a full frame is finished, this buffer is made visible. This means that if you pause openMSX, you will be looking at the last completed frame.
I can imagine that while debugging, it is useful to see the frame in progress being displayed instead of the last completed frame. Therefore I'm moving this item from the bugs tracker to the feature requests.
Hummm Then were probably talking about two different situations here then:
a) Even on accuracy=pixel the buffer is only made visible after a full-frame is finished. This would be a feature request.
b) The "buffer is made visible" routine suffers from a great lag while the emulator is on debug-step mode. This would be a bug-report, and it's what I called "screen update lag".
Here are the steps to reproduce the "screen update lag while on debug-step mode":
Be sure that z80_freq_lock is on and cmdtiming=real.
1) Select the Panasonic FS-A1WSX, with FireHawk disk-A on drive, and boot openMSX
2) Open the openMSX-Debugger and connect it to openMSX.
3) Wait until the 1st menu appears and break the emulation
4) Insert a breakpoint: address=0x4FAA, slot=3, subslot=0, segment=2
5) Press F9 on the debugger and leave the game alone. The intro cutscene will load. The breakpoint will be activated on the scene that Arthur appears running to the left side of the screen.
6) Issue a set speed=20
7) Go back to the debugger. It will be stopped at 0x4FAA, which is a djnz loop with 3 CALLs inside it.
8) Run over each CALL using F8 on the debugger. You'll notice that the screen is updated accordingly. The on CALL 4FF0h Arthur will go up on the screen and on CALL 4FD5h Arthur will go down. Repeat the process for two iterations of the loop so you get used with how it works. There's no lag on the screen when you do this.
9) Now the screen lag: When PC=4FABh again, use F7 to enter the CALL 4FF0h in step-by-step
10) You'll notice that 4FF0h itself is another djnz loop, with 8 iterations. Run thru it using F7 and issue an F8 only on 4FFFh to step over the CALL 5A47h. You'll run all the 8 iterations in step-by-step this way. After finishing the djnz, the routine will RET on 500Ah.
11) Notice that the screen wasn't updated not even once. The PC will be back on 4FAEh and the screen is still showing the same image when the PC was on 4FABh. Remember that on (8) the PC did the same path and the screen was updated correctly.
12) Now enter the CALL 4FD5 in step by step and the screen update will still lag more and more. Up to this point it will be more than 1 second lagging behind the emulation.
13) Proceed inside the CALL 4C12h using only F7 (debug-step), and continue stepping until the PC=4FABh again. You'll notice the screen will still lag without any updates.
14) Now the PC=4FABh. No screen updates haven't happened yet. Just use the F8 key to step over both the CALLs 4FF0h and 4FD5h. You'll notice that the screen will update again normally, and all intermediary frames were just not seen and got lost.
For the partial-screen-update-while-debugging feature request: It's will be really cool to have it, but please fix the current update-when-frame-complete routine on debug-step mode until there, please. :)
I can't reproduce this :(
I followed your detailed step-by-step instructions (thanks, it was very useful). On step 10, when i press F8 on 0x4FFF, I DO see the screen get updated. And similar to the later steps.
Can you confirm that both minframeskip and maxframeskip are set to 0?
Wouter
Wouter,
I found what was causing the situation (b). Nekolauncher was overriding my maxframeskip setting with it's own. Nekolauncher is great for common "just to play" use, but I'll resort to barebones launched-by-my-own-shellscript aproach when debugging to avoid this kind of interference.
Let's keep only the feature request as suggested by mthuurne: "Show the frame in
progress while debugging for accuracy=pixel".