I was thinking and I am beginning to believe that this could have nothing really to do with the debugger nor the emulator, but with the msx itself. Maybe the reconstruction of the screen is too slow that there is time to make several printfs before a new vertical retrace begins. I've notice that sometimes while debugging the screen seems split, not reconstructed in full, thus having half top part updated and bottom one still with the old pixel values. That is what makes me think that could be a retrace issue.

So before bringing headaches please first take this into account.

Thanks.

So, if I understand correctly (please confirm), you made a program that prints text on the MSX screen and you have a breakpoint set. Where is it set? Before or after the routine? I guess just after.

Anyway, you are right: the MSX screen writes the screen only at 50 or 60 times per second, so, so will openMSX. If you have the breakpoint right after the routine, it is possible that the (emulated) cathod ray beam has not drawn the new VRAM data yet... Exactly as you describe.
And indeed, you can pause emulation (in break mode or in pause mode) at any time, even when a frame is only half written. Most of the time you can't really see this, though.

So, can we conclude: no bug, and not really something we can do something about?

Well, I really think that the z80 is faster enough to do several printfs before the screen is updated. The only thing I can test is to proof that this is something related to the retrace is adding before the printf that is inside a while statement a call to a waitvsync function that waits for the retrace to end and then put the breakpoint just before that point. That way every printf should be shown. But I don't know if I'll have time because I have to prepare my holidays (tomorrow at last!).

So just you can forget this and do other things you have pending because I am pretty sure that this can be a retrace issue.

Thanks for your interest.

Thank *you* for your interest. And I think we agree

Hi again Manuel. I am back again. (Short holidays... ).

Well, I've found out some interesting things while debugging my test program. First of all, the issue of updating the screen each 4 frames was due that openmsx value of maxframeskip was 3. I set it to 0 and every time I wait the vblank a full screen update is done.

But I've noticed something. Openmsx updates on a frame basis, not on a realtime basis. Let me explain. I am waiting several times for hblank and then I change the foreground color by complementing the value, so there are shown black and white strips along the sides of the screen. But those lines are only updated when the vertical retrace has been finished. Is there any way of forcing openmsx to update the state of the video output every cpu step or something while debugging?


And now some ideas about the debugger. Do you have seen how Win32 debugger works? It uses a "project" system. Every debugging session is a project, and in that project information about the executable path, the breakpoints, the searches, etc. is saved. It would be nice to have something like that in order to continue the debugging from one session to another, not having to search each time the same CPU addresses to put there breakpoints. Also there can be saved memory watches and some other data used in every debugging session that is done during the development of an application.

Regards.

Quote:

Well, I've found out some interesting things while debugging my test program. First of all, the issue of updating the screen each 4 frames was due that openmsx value of maxframeskip was 3. I set it to 0 and every time I wait the vblank a full screen update is done.

It's the max skip, which will only be used if there's no time to render all frames and stay in sync with real time.

Quote:

But I've noticed something. Openmsx updates on a frame basis, not on a realtime basis. Let me explain. I am waiting several times for hblank and then I change the foreground color by complementing the value, so there are shown black and white strips along the sides of the screen. But those lines are only updated when the vertical retrace has been finished. Is there any way of forcing openmsx to update the state of the video output every cpu step or something while debugging?

Can you confirm this only happens when debugging? Normally openMSX renders pixel-accurately if the 'accuracy' setting is set to 'pixel'. I wouldn't expect this to be different when debugging. I'd have to ask Wouter about this to understand it better.

Quote:

And now some ideas about the debugger. Do you have seen how Win32 debugger works? It uses a "project" system. Every debugging session is a project, and in that project information about the executable path, the breakpoints, the searches, etc. is saved. It would be nice to have something like that in order to continue the debugging from one session to another, not having to search each time the same CPU addresses to put there breakpoints. Also there can be saved memory watches and some other data used in every debugging session that is done during the development of an application.

That sounds like something useful indeed. Will put it on the TODO list. Thanks!

Quote:

Quote: Well, I've found out some interesting things while debugging my test program. First of all, the issue of updating the screen each 4 frames was due that openmsx value of maxframeskip was 3. I set it to 0 and every time I wait the vblank a full screen update is done. It's the max skip, which will only be used if there's no time to render all frames and stay in sync with real time. Quote: But I've noticed something. Openmsx updates on a frame basis, not on a realtime basis. Let me explain. I am waiting several times for hblank and then I change the foreground color by complementing the value, so there are shown black and white strips along the sides of the screen. But those lines are only updated when the vertical retrace has been finished. Is there any way of forcing openmsx to update the state of the video output every cpu step or something while debugging? Can you confirm this only happens when debugging? Normally openMSX renders pixel-accurately if the 'accuracy' setting is set to 'pixel'. I wouldn't expect this to be different when debugging. I'd have to ask Wouter about this to understand it better.

Maybe when the debugger stops the emulator, the internal timer that the emulator uses for synchronizing is not stopped (for example it polls system timer), thus making that the time used in stepping through the debugger to be counted as time that has really passed.
I'll try to explain myself a little more. A frame must be built in less than 1/60 seconds. But when the emulator is paused by the debugger time is passing. Imagine that I have used the debugger 30 seconds and there is time to openmsx to update. Ase he polls again the system timer, 30 seconds have past, more than 1/60, so he cannot make the sync and skips the frames.

This could explain why always I have a frameskip when maxframeskip was different from 0.

Does this make some sense?

Hi yakumo,

You're right, after a breakpoint openmsx will skip frames. So set min/maxframeskip=0 if you want to see every frame during debugging.

Rendering in openMSX is pixel accurate, but the window content is still only updated when a complete frame is finished. Doing otherwise would be rather slow, especially in combination with scalers.

Also thanks for your list of suggested features. Unfortunately development of the openMSX debugger is progressing rather slow (hint: we could use some help). So it could take a while before they're implemented. However if you want a feature NOW there is a big chance you can relatively easily implement it yourself as a Tcl script. For example saving/restoring of breakpoints and watchpoints would only take a couple of lines.

Thanks wouter_. Would be also possible to modify openmsx in order to activate a special mode of pixel update? It would be nice if in the communication of the debugger with the emulator this mode could be activated in order to see changes for each horizontal scan line, to debug split modes or some special effects.

I think that everything is possible, so I am really asking for a non complicated way of doing it, and this will depend of opemsx implementation and debugger-openmsx communication.

Thank you very much in in advance and for the reply. I don't really need nothing to be implemented in a hurry, I just wanted to see how the debugger was going while I am try to learning some programming for msx ad the same time, and also to collaborate and suggest some features that may be needed to be considered in advance to make the further development the more easy and extending possible. A good design of a set of features can be of much help in developing any application.

Anyway if I have time I'll may take a look at TCL and try to mess with the scripts.

Here is a recent (new) snapshot of the openMSX debugger. Only use it if you give us feedback! The abovementioned TODO list is also updated.

Please give us feedback about it!

Quote:

Here is a recent (new) snapshot of the openMSX debugger. Only use it if you give us feedback! The abovementioned TODO list is also updated. Please give us feedback about it!

Hi, manuel. I've played a little with the debugger. It's very good. Only few things in my mind:
- A viever for the current VDP-scanline, VRAM read write PTR, CPU cycle counter (for time critical demos)
- the watchpoint conditions, should include the ability to break where a certain memory location is accessed (R/W) even on VRAM.

the challenge is how to give all the flexibility allowed by the internal openMSX debugger, (that is marvellous) in a graphical way.

I did once put in a request for retrace information in openmsx as well. Not there at the moment though. The only good way to determine CPU cycles is to use the debugdevice, which outputs z80 cycles as well as values.

Other things will come. At some point. When I either feel like coding it or need it desperately.

PingPong, I checked those things with wouter and here is his reply:
- all debuggables we have atm return an array of bytes, those thing require a single bigger integer. It's probably not difficult but we lack some infrastructure for it.
- will be bad for performance; for z80 watchpoints it was possible without overhead because of the very special cpu memory access system, but not for vram or any debuggable in general.

You can always join the discussion on http://openmsx.sf.net/mibbit.php

Quote:

- will be bad for performance; for z80 watchpoints it was possible without overhead because of the very special cpu memory access system, but not for vram or any debuggable in general. You can always join the discussion on http://openmsx.sf.net/mibbit.php

for the second one, i mean "for every time memory is accessed" not the access performed by vdp only the read and writes from z80. I think in this case is not more bad for performance.

Wouter says: once we have the 'vdp vram read/write pointer' available as a debuggable (some new sort of debuggable) it's possible to set a conditional breakpoint of io port 0x98 read/writes. In the condition you check the value of the vram pointer. This will have the same effect as watchpoints on vram read/writes.