The way I usually work (more or less) with the BlueMSX debugger is :

1) Edit with ConTEXT (or whatever fancy windows editor)
2) Launch the program from the editor (by means of some scripts that create dsk or rom and runs emu)
3) Launch the debugger and set breakpoint at desired address.
4) Reset the emu to be sure that the breakpoint is reached
5) BlueMSX debugger stops in the selected address

That's what I'm trying to do with OpenMSX:

1) Edit with ConTEXT (or whatever fancy windows editor)
2) Launch the debugger and set breakpoint at desired address (no need to connect, just keep in memory the breakpoint address).
3) Launch the program from the editor (by means of some scripts that create dsk or rom and runs emu)
4) From debugger, connect and reset the emu to be sure that the breakpoint is reached
5) OpenMSX debugger stops in the selected address

Maybe there's an easy way to do it; but I'm used to do so...

Any ideas?

Maybe something like this:

1) Edit with ConTEXT (or whatever fancy windows editor)
2) You already had the debugger launched, the emulator running and set breakpoint at desired address (no need to unconnect, just keep in memory the breakpoint address from last time you set it).
3) Eject the disk image or ROM image in openMSX.
4) Create new disk or ROM image with your scripts
5) Insert it in the still running MSX machine.
6) Reset the emulated MSX to be sure that the breakpoint is reached
7) OpenMSX debugger stops in the selected address

So, step 2) you only do once. Step 3-5 could be automated by using openMSX remote controlling, but that might be a bit too tricky The Gedit plugin does something like it IIRC.

Anyway, thanks for the feedback. Maybe we can make this scenario easier, e.g. by indeed remembering breakpoints over sessions. Edwin, what do you think?

Anyway, it would be good to have some more comments/ideas on this beta of the openMSX debugger. Anything else, folks?
Huey, did you try it out yet?

Hello?

I updated the snapshot with the latest version, which should have some bugs fixed. Please try it out and post comments here.

I have read some post about that there was need of cleaning the registry key.

May I give an advice? Please, don't use the windows registry, for God's sake. Use .ini files, .xml configurations files, whatever, but never do these two things:

1.- Save configurations in the registry
2.- Release self-install .exe instead of .zip

I hate that every application needs to mess with the registry or insert itself into the add/remove programs list, windows programs menu, etc.


I have downloaded latest openmsx, I'll try to see how the debugger works... Thanks though for the effort, and keep going.

I've tested the latest version, and I have had no problems for debugging apart of the lack of edit menu to obviously use a search function. Apart from a hang on openmsx in one of the debug sessions, all others run without problem, not hanging, not crashing. Anyway it lacks much shortcuts to functions like step into, step over, etc. If I may give an advice, please, choose the correct accelerator keys, and when I refer to correct, I refer to most used for debuggers, like f8, f7, or whatever. See debuggers like turbodebugger, or others in IDEs like code::blocks, so that usual programmers don't have to learn a new set of keys for each debugger.
Or BETTER than that!!! Just make it configurable in a xml file or something. You could have some xml files for shortcut pressets, one of them 'a la' turbo debugger, other like Visual Studio .Net, etc. And the possibility of creating a new configuration for shorcuts.

Also it keep in mind that all windows in debugger can be detached, but not attached again .

Well, I wish I have been constructive.

Thanks a lot for the feedback!

All windows can be attached again, by dragging them on the main window. But you can't drag them by the window border, only by the 'inside'.
I'll put the short cuts suggestion in the TODO list.

openMSX comes in both a ZIP and an EXE distribution, so that you can decide for yourself what you use.

About the registry: the whole point of the registry is that you can store data in it, that's why many UI toolkits (also the ones we use: wxWidgets and Qt) use it to store userdata in. We cannot control it, we use the abstract 'settings data' classes, which are implemented differently on different platforms. In Windows, they happen to use the registry, which is (again) really normal and not harmful at all. Stuff is stored in the local user registry only, this can never break your system, no matter how crappy M$'s stuff is.

The hang up is a known problem on dual core Windows systems. We fixed that and openMSX 0.6.3 should work a lot better in that respect.

You are right, the windows can be attached again, but is a little tricky to find an anchor point, and as the blue transparent panel remains always with the same arrow cursor, you have to watch very carefully to notice when it has found a dock point.

About the configuration file, if you use the setting classes of wxWidgets and Qt I can say nothing. I was thinking more the way that code::blocks or notepad++ does, using their own xml, with their own Setting save/load classes, as I have done many times in my own applications. Is not as comfortable as having already the classes made for you, but its more portable.

I was not saying that the registry configurations could crash the system, but loading a bigger registry is always slowest than loading a little one. And about the ZIP and EXE, just I tried to say that never remove the possibility of the ZIP file.

About the hang: Yes, I have a core 2 duo.

It's nice that I have been of some use.

It took me hours of listening to Vampire Killer to pinpoint that dualcore bug..

The settings solutions from Qt and wx are also very portable
Does loading those few settings (there are really few, it's only Catapult's settings) make a difference, you think?

We have quite some ZIP downloads (especially just after release), so we will certainly not stop distributing those.

And yes, you give very useful feedback. Keep it up! Soon we will have a 0.6.3 beta. I hope you'll help us to test it before we release the final one.

When I talk about portability I am not referring to application platform independence. Imagine that I am working with the debugger, and I set a custom layout, and a custom configuration. This all is saved in the windows registry. How I am supposed to copy the entry of Vista registry to an older Windows registry? Maybe there would be some incompatibilities, and not to talk about the difficulties to find the correct keys to export along the registry, with tend to be very BIG.

But there is more. Imagine that now I am switching to linux, where there is no registry. Then I have to configure my debugger from scratch again. With an xml file you could save that file, copy it in another directory, make a backup or modify it in a text editor if something may go wrong.

Think about that seriously. There are only advantages for the user, with is the first target of an application.

Regards.

Another think that I want to ask. Although I can debug, I cannot see the emulator changes while debugging. For example no console output is seen. Is this normal?

Portability: ah, I see what you mean. I'm not sure if the Qt platform takes such scenarios into account. I'll investigate it.

EDIT: I just checked, it's possible to use INI files for all platforms. See http://doc.trolltech.com/4.3/qsettings.html

What kind of console output do you mean? Can you describe a scenario and tell me what you expect to happen?

Well, I just was making some text only output (some printfs), that's why I called it "console". I am debugging that output, but when a printf is done I still don't see any output on the screen, I need to "run" to see the output. Seems as if the emu screen is not updated, just only the state.

Correction: It is updating, but not in "real time". I need to do several printfs in order to make the emu output one of them. If you want I could sent you the rom and the address where you have to put a breakpoint. That address is the address of a printf that prints the value of a variable that is changed in a HTIMI interrupt routine.

About the ini files, I think they would fit well, although care should be taken because of the cr/lf in windows and the lf only in linux. I expect that Qt will handle it well.