OpenMSX and BlueMSX debugger

Página 1/2
| 2

Por Daemos

Paragon (1954)

Imagen del Daemos

04-01-2015, 16:59

This post is intented not to rant or tell people that one of the both is better or worse. This is a epxression of my experiences so far with both emulators hoping to help both development teams on the both excellent emulators which I use with great pleasure. I like to list down the things I really like about both debuggers. I hope it will be of great use for you. It may be that I have missed features or never found them but again this is just a sum of experience:

OpenMSX:
-I can see about everything what happens on the VDP even the bitmapped content of the VRAM
-memory watchpoints
-active memory layout is shown, slots and segments
-selective breakpoints on slots and even memory segments
-step back!
-pauze and break are separated
-trottle F9
-set speed command
-step back in emulation with pgup and pgdown
-turbo LED
-runs on linux

BlueMSX:
-direct visual of command result. If I step forward in the opcode I see the results on screen in the emulator
-compile on the fly, if I leave the emulator open I can still compile the rom and all required is F12 reset. No restart of emulator required
-changes in memory are shown very well
-ability to save RAM content
-turbo-R works out of the box no extra roms required
-All RAM visible
-machine editor allows all kind of slot configs to be created for extensive testing with a nice GUI
-screen mode directly visible, no digging in VDP regs required

I hope this information is usefull for you.

Login sesión o register para postear comentarios

Por Louthrax

Prophet (2406)

Imagen del Louthrax

04-01-2015, 17:14

Must say the "step back" option (F12) in openMSX debugger is pure magic to find the root-cause of a crash or bug Smile

Por Vampier

Prophet (2386)

Imagen del Vampier

04-01-2015, 19:20

feedback received Smile

Por Grauw

Ascended (10135)

Imagen del Grauw

04-01-2015, 19:40

Video is not updated in openMSX because the VDP is emulated in sync with the CPU. So, if you step over one NOP instruction, it renders 7.5 pixels from wherever the beam currently is. Maybe not always handy for debugging though Smile.

For me, one thing I wished for in the openMSX debugger is that the code view could also inspect and set breakpoints on code in slots other than the currently selected ones. That’s especially useful when a ROM crashes somewhere on start-up, if I pause the emulator before the ROM’s paged in it’s tricky to set a breakpoint at the start of the program to step through.

Another thing is that when I quit the emulator and re-assemble the code, the debugger always asks me whether it should reload the symbols. Would be nice if there was a “never ask me again” checkbox on there Smile. Similarly, I always have to manually connect it to the emulator, would be nice if it could auto-connect.

Now here’s some tips for a TCL script to pass to openMSX (-script openmsx.tcl command line option)…

To improve iteration time:

set throttle off
after time 5 "set throttle on"

Keep an eye on a memory address:

ram_watch add 0xFC9E -desc line -type u16 -format hex

To detect and break on null dereferences once the ROM is executing:

debug set_watchpoint write_mem 0x0000 {([debug read ioports 0xA8] & 0x0C) == 0x04}
debug set_watchpoint read_mem 0x0000 {([debug read ioports 0xA8] & 0x0C) == 0x04}

Break the emulator when the code executes in a,(2EH), which I do at the start of my System_ThrowException routine (prints stack + di / halt) routine, called from various places whenever I receive some invalid input or state. Lets me easily step-back to the problematic code and debug the problem immediately:

debug set_watchpoint read_io 0x2E

Por Manuel

Ascended (18233)

Imagen del Manuel

04-01-2015, 21:35

That's some great feedback, thanks!

Here's a response from a purely openMSX perspective (I have never seen the blueMSX debugger), mostly trying to explain how you can get more out of openMSX.

Daemos wrote:

-direct visual of command result. If I step forward in the opcode I see the results on screen in the emulator

You can see it when the frame is finished indeed. Then the output window is updated. There's a way to quickly jump to the next frame if that helps.

Quote:

-compile on the fly, if I leave the emulator open I can still compile the rom and all required is F12 reset. No restart of emulator required

For openMSX you do not need to restart the emulator either. You can simply reinsert the ROM image and reset.

Quote:

-ability to save RAM content

You can do that too with openMSX, but not with the debugger GUI. You can still use the save_debuggable command in the openMSX console though.

Quote:

-All RAM visible

The same is in openMSX. Just add a debuggable viewer for it: View -> Add debuggable viewer and choose the debuggable in the drop down box.

Quote:

-screen mode directly visible, no digging in VDP regs required

In openMSX, try to open the console and type: toggle_info_panel (or open the OSD menu and select: Advanced -> Toys -> info_panel), or in the debugger open the VDP registers view: View -> VDP -> Registers where all/most VDP registers are decoded for your convenience.

Por Daemos

Paragon (1954)

Imagen del Daemos

05-01-2015, 12:51

Quote:

For openMSX you do not need to restart the emulator either. You can simply reinsert the ROM image and reset.

This one really doesn't work for me. First I tought it was linux but in windows the rom file is not overwritable by the compiler as well when the openmsx session is still open. So in order to recompile the rom I need to either close the session or eject the rom, compile the rom then reinsert the rom again. These are too many steps when hunting a hard to find bug.

Por Manuel

Ascended (18233)

Imagen del Manuel

05-01-2015, 14:50

This problem only occurs on Windows?

I can replace the ROM on Linux, but sometimes openMSX crashes if I do. See https://sourceforge.net/p/openmsx/bugs/564/

What happens on Windows? Is the file not writable, "Permission denied"? (As I assumed in the bug report.)

If you eject/insert in the console, it's quite easy:
- F10
- carta eject
or
- carta /path/to/your/rom
- F10

And you can use UP to get a previously entered command in the console, so you only have to type it once.

Por Daemos

Paragon (1954)

Imagen del Daemos

05-01-2015, 15:08

No crashes the assembler simply refuses to output the file.

Por Manuel

Ascended (18233)

Imagen del Manuel

05-01-2015, 15:32

On Linux? That's weird, on Linux there's no concept of file locking... so it should just overwrite it fine.

What is the error you get?

Por Daemos

Paragon (1954)

Imagen del Daemos

05-01-2015, 15:51

ohw wow

only happens in windows. In linux the emulator crashes...

I will check the exact error details at home. I have a windows VM there.

Por Manuel

Ascended (18233)

Imagen del Manuel

05-01-2015, 16:08

On Linux, do you get a Bus error? See https://sourceforge.net/p/openmsx/bugs/564/
It's not crashing all the time for me, by the way.

Página 1/2
| 2