XRoar 0.31 released

[pser1]

Hello,
in my PC, with Windows7, the 'Alt Gr' key always behaves exactly like the 'Ctrl' key.
I have tried older versions and 031 and 030 behave the same way.
Concerning Windowsland, the option menus do react at first try ... until now for me.

As promised, I have been trying GDB to debug a simple machine code program compiled in XRoar emulation at $4000
When GDB starts, XRoar freezes and from GDB I see that the debugger has intercepted Dragon, but at ROM area, because Dragon is waiting for a command to be entered.
I have not found any way to change the PC register in order to jump to the program I wanted to debug. It seems that I cannot change registers while the remote machine is running(?)
Could anyone tell me what am I missing in order to start my program in XRoar under GDB control?
Maybe there is a mandatory sequence of orders that I am not doing ...
Any advice will be greatly appreciated
thanks a lot
pere

[tormod]

After you have started gdb and it has halted the execution, you typically set a breakpoint at the place where you want it to stop, then let it continue:

Code: Select all

hbreak *0x4000
cont

Now it will stop at $4000 (after you have entered EXEC&H4000 for example). You can set the PC using "set $pc=0x4000", but that is not what you are normally supposed to do. From here on you can check register values with "info reg", dump memory with e.g. "x/16xb 0x4080", or set new breakpoints. The most useful command is maybe "stepi" to step execution one instruction at a time, combined with "layout asm" which gives you a split window with the disassembly of the running code. There are many gdb tutorials around, and most things work with XRoar as well.

[pser1]

thank you very much Tormod,
now I have found that the GDB quick reference pdf file contains this info too, but I didn't catch it when I first read it, sorry.
So no problems from now on, just would like to mention that under Windows 7 it seems that "layout" is not accepted:
This is the result I get everytime I try:
===============================================================
(gdb) target remote localhost:65520
Remote debugging using localhost:65520
0x0000bbc8 in ?? ()
(gdb) hbreak *0x4000
Hardware assisted breakpoint 1 at 0x4000
(gdb) cont
Continuing. Now I make EXEC&H4000 on the Dragon side, and it comes back immediately:
Breakpoint 1, 0x00004000 in ?? ()
(gdb) layout asm
Undefined command: "layout". Try "help".
(gdb)
==================================================================
I have read that gdb can be started with the -tui option, but when I do that, the DOS windows closes itself.
Sentence written: m6809-gdb -tui
The other option: Ctrl+x and later 'a', doesn't seem to work for me (?)
Maybe, again, I have misread something and there is an easy way to open the assembler window . . .
Do you know how to get this on a Windows environment?
thanks beforehand
pere

[Alastair]

I have read that gdb can be started with the -tui option, but when I do that, the DOS windows closes itself.
Sentence written: m6809-gdb -tui
The other option: Ctrl+x and later 'a', doesn't seem to work for me (?)
Maybe, again, I have misread something and there is an easy way to open the assembler window . . .
Do you know how to get this on a Windows environment?
thanks beforehand
pere

There is a problem in ncurses which prevents TUI from working in Windows. See this thread for the trials and tribulations that Ciaran and myself had in trying to get TUI to work.

[pser1]

Hello Alastair,

Despite I cannot use the -tui option, it seems to me a very good debugging tool. I will try to practice with it!
Just one question about this text windows (-tui), do they appear if you are working, let's say, with Linux?
thanks for you help
pere

PS. By the way, I heard that someone got GDB working and so debugging a real Dragon ...
what is needed to do that?

[pser1]

Hello Ciaran,
I have found, by hazard, the new snapshot 18589 and a bit later the newer 19157. I have downloaded them immediately.
Much to my surprise, the exe files are much bigger than prior ones. The 64 is double and the 32 is three times greater.
Were these snaps a so deep change?
It seems it involves mostly file formats ...
thanks
pere

[sixxie]

Hello Ciaran,
I have found, by hazard, the new snapshot 18589 and a bit later the newer 19157. I have downloaded them immediately.
Much to my surprise, the exe files are much bigger than prior ones. The 64 is double and the 32 is three times greater.
Were these snaps a so deep change?

The .exe is larger, but you'll notice no SDL.dll or libsndfile.dll distributed in the .zip: I've statically linked them, so the .exe contains any relevant code from those DLLs now.

It seems it involves mostly file formats ...

Today's main update is mostly for NitrOS-9 users: the disk images they distribute don't have header information to indicate geometry, and heuristics get it wrong (or they'd get other common images wrong instead). Now XRoar will look for geometry information in the OS-9 filesystem if there doesn't seem to be a header.

[pser1]

OK, clear!
I saw this but thought it was just because you hadn't changed them.
I have the old dlls in the same folder by now, I was thinking they were mandatory as with older versions ...
This makes it simpler!
Thanks Ciaran
pere

[sixxie]

BTW, after Tormod Volden alerted me to a problem with the GDB patch, I've fixed it up. I also looked into building a Windows binary against pdcurses, which seems to have gone well - it works in wineconsole, at least! m6809-gdb.exe in the usual dumping ground...

[pser1]

yes! Now "layout asm" opens up a window with some disassembled lines.
And the cursor there moves with every program step (stepi for instance)
The only 'con' I see is that the DOS window reserved for the GDB instructions is too reduced (about just six lines), it doesn't matter if you first maximized the window ...
Maybe this is just A windows side-effect (DOS is emulated)
thanks again, Ciaran
I will do some more tests ... tomorrow
regards
pere