readline Keyboard shortcuts in breakpoint files

[TheNameOfTheGame]

The debugger manual has a section at the end regarding Keyboard shortcuts in the debugger, one of them being Control-L (clear screen and redraw line).

I am trying to get that functionality to work with a breakpoint file, i.e. to clear the screen before any option command output each time the breakpoint is reached.

ex) trace break every time the ikbd interrupt handler gets run and output the ikbd info:

Code: Select all

b pc = ($118).l :trace :quiet :file ikbd.bkp

and in the ikbd.bkp file:

Code: Select all

info ikbd

This works but scrolls the output in the debugger window. I would like to use the Control-L clear screen function to clear the screen before the "info ikbd" is executed.

Reading the readline man page it is suggesting "\C-L" but the debugger doesn't accept this. I also tried "C-L" and "^L". What is the way to clear the screen on a breakpoint? Thanks.

[Eero Tamminen]

Screen redraw with Ctrl-L is functionality of the optional readline library dependency, not of the Hatari debugger.

When built with readline support, Hatari just calls "readline()" to get command line from user, and whatever readline does (see "man readline") is completely opaque to Hatari.

Whereas commands in debugger input files (read by breakpoints) are directly parsed from those files, there's no readline library involvement.

While in theory Hatari could optionally link with ncurses and provide some terminal specific commands with ncurses, like "cls", I'm not really fan of optional commands. Another problem with such commands would be their output being terminal specific. If one saves debugger output, it may not look same on another machine.

But maybe it would make sense to add "echo" command to debugger, which would support escape sequences. On terminals supporting ANSI escape codes (like most Unix ones), one could then use those to clear screen:

Code: Select all

echo -e "\ec"

[TheNameOfTheGame]

That would be a good solution. An 'echo' would be very useful. And maybe a command to suppress the output of the command prompt until the breakpoint file was finished like 'noprompt' which would be helpful when printing successive memory areas from structures without the 'noise' of the command prompt between lines?

[TheNameOfTheGame]

Btw, would it be possible to add a command like 'screen <address>' to temporarily display another screen address from the debugger?

When reverse engineering game code, it is always a problem not being able to see the logbase screen as it is being built before swapping to physbase.

So I could break on, for example, the tile drawing routine, set the 'screen' and then 's', 'n' or breakpoint and watch the logbase being drawn. Then when I enter 'c' it would switch back to physbase and continue on. That would be a very useful feature.

[Eero Tamminen]

Could you send proposal mail for these to the Hatari mailing list (with a link to here), to get a bit more discussion on them?

It's good to get others' opinion on them before implementation, so that all angles / details are considered before implementation...

(There's currently also discussion on proposal for a "struct" command for outputting structure values without extra noise.)

That would be a good solution. An 'echo' would be very useful. And maybe a command to suppress the output of the command prompt until the breakpoint file was finished like 'noprompt' which would be helpful when printing successive memory areas from structures without the 'noise' of the command prompt between lines?

Sounds reasonable. I think its scope should be limited to a file in where that command is given, or given debugger session, so that prompt is back again when debugger file parsing ends, or one enters debugger again.

Another possible syntax would be "prompt <on/off>", in case one wants prompt back before the scope ends...

Btw, would it be possible to add a command like 'screen <address>' to temporarily display another screen address from the debugger?

When reverse engineering game code, it is always a problem not being able to see the logbase screen as it is being built before swapping to physbase.

So I could break on, for example, the tile drawing routine, set the 'screen' and then 's', 'n' or breakpoint and watch the logbase being drawn. Then when I enter 'c' it would switch back to physbase and continue on. That would be a very useful feature.

Hatari screen drawing is quite complicated as it supports different ST/STe, TT & Falcon modes, and Spectrum512 mode with per-line palettes.

SDL2 supports multiple windows. While it would be quite a bit of work, now that Hatari dropped SDL1 support, another window could be used to draw such things.

Because rest of Hatari code is not prepared for interaction from multiple windows, it should probably be something that pauses Hatari until user closes the new window.

With a separate window, any size graphics could be shown from memory, and while it should default to current Atari screen settings, it could also allow specifying bit-depth and palette address for that gfx area:

Code: Select all

window <address> <width> <height> [bits] [palette address]

That's quite a bit of stuff to code though, and while I could look into echo, prompt, and struct commands, screen/window/gfx command would probably require somebody else contributing support for that. Discussing the matter on hatari-devel could get somebody interested into contributing such a thing...

[TheNameOfTheGame]

Could you send proposal mail for these to the Hatari mailing list (with a link to here), to get a bit more discussion on them?

It's good to get others' opinion on them before implementation, so that all angles / details are considered before implementation...

(There's currently also discussion on proposal for a "struct" command for outputting structure values without extra noise.)

Ok, will do. Yes, I agree it is good to get others' thoughts on these matters before changes.

That would be a good solution. An 'echo' would be very useful. And maybe a command to suppress the output of the command prompt until the breakpoint file was finished like 'noprompt' which would be helpful when printing successive memory areas from structures without the 'noise' of the command prompt between lines?

Sounds reasonable. I think its scope should be limited to a file in where that command is given, or given debugger session, so that prompt is back again when debugger file parsing ends, or one enters debugger again.


Another possible syntax would be "prompt <on/off>", in case one wants prompt back before the scope ends...

Yes, I would think such a command would have to limit the scope to the breakpoint file as you say so that user could always be assured to get a prompt back even in the case of breakpoint file error.. It was inside the breakpoint file itself where it might be useful to have prompt on/off as you say.

Btw, would it be possible to add a command like 'screen <address>' to temporarily display another screen address from the debugger?

When reverse engineering game code, it is always a problem not being able to see the logbase screen as it is being built before swapping to physbase.

So I could break on, for example, the tile drawing routine, set the 'screen' and then 's', 'n' or breakpoint and watch the logbase being drawn. Then when I enter 'c' it would switch back to physbase and continue on. That would be a very useful feature.

Hatari screen drawing is quite complicated as it supports different ST/STe, TT & Falcon modes, and Spectrum512 mode with per-line palettes.

SDL2 supports multiple windows. While it would be quite a bit of work, now that Hatari dropped SDL1 support, another window could be used to draw such things.

Because rest of Hatari code is not prepared for interaction from multiple windows, it should probably be something that pauses Hatari until user closes the new window.

With a separate window, any size graphics could be shown from memory, and while it should default to current Atari screen settings, it could also allow specifying bit-depth and palette address for that gfx area:

Code: Select all

window <address> <width> <height> [bits] [palette address]

That's quite a bit of stuff to code though, and while I could look into echo, prompt, and struct commands, screen/window/gfx command would probably require somebody else contributing support for that. Discussing the matter on hatari-devel could get somebody interested into contributing such a thing...

Ah, I see. I was thinking that when entering the debugger, the 'screen' command could temporarily 'borrow' the screen drawing routine and use it to show another video address. As you describe it with the per line capabilities, a separate window for it where it paused emulation would be best. Well, I'll ask on the mailing list and see what people think. Thanks for the information.

[TheNameOfTheGame]

Could you send proposal mail for these to the Hatari mailing list (with a link to here), to get a bit more discussion on them?

That's quite a bit of stuff to code though, and while I could look into echo, prompt, and struct commands, screen/window/gfx command would probably require somebody else contributing support for that. Discussing the matter on hatari-devel could get somebody interested into contributing such a thing...

I sent a message to the mailing about the prompton, promptoff idea. I don't think anyone will mind, but will see if there are any objections.

Good news is that a struct command isn't needed anymore. I sent a patch to the dev list with the corrections to the 'm' memory command. It now properly respects the count and range values. So structures are possible now just with a breakpoint file and a series of 'm' lines that reflect the structure. Only needs that command prompt turned off . Have a good one!

[TheNameOfTheGame]

That's quite a bit of stuff to code though, and while I could look into echo, prompt, and struct commands, screen/window/gfx command would probably require somebody else contributing support for that. Discussing the matter on hatari-devel could get somebody interested into contributing such a thing...

Had a go at implementing the promptoff command this evening (don't think a prompton is required). Not too complicated it turns out and only active if a breakpoint file is processed. Could you take a look and see what you think? Attached are the diff files involved. Just a few changes thankfully .

hatari-promptoff.zip

[TheNameOfTheGame]

And one more patch if you could try. This adds ''echo' and a 'cls' commands to the debugger console.

diff file is set to apply to debugui.c after the previous promptoff patches above. If you want to add to the original debugui.c it is no problem, of course you can see in the diff what to add.

debugui.c.diff.zip

[Eero Tamminen]

Thanks for the patches, and sorry for the late reply!

Had a go at implementing the promptoff command this evening (don't think a prompton is required). Not too complicated it turns out and only active if a breakpoint file is processed. Could you take a look and see what you think? Attached are the diff files involved. Just a few changes thankfully .

I did did not realize you were adding it as breakpoint option instead of debugger command.

You do not need to add new option for that, there's already the "quiet" option for that, it just needs to be passed on.

Here's patch doing that:

0001-Breakpoint-quit-option-inhibits-extra-output-also-fo.patch.txt

Could you try it? If it works fine, I'll push it to repo.

[Eero Tamminen]

I sent a message to the mailing about the prompton, promptoff idea. I don't think anyone will mind, but will see if there are any objections.

I saw mail on the emutos-devel, but not on hatari-devel?

Quiet option expansion and echo command seem straightforward so not discussing them is fine, but screen thing should definitely be discussed on hatari-devel...

And one more patch if you could try. This adds ''echo' and a 'cls' commands to the debugger console.

"echo" command would need to output all of its arguments and parse escape sequences (\e, \t, \r, \n, \\...).

And "cls" would need to support any terminal, not assume that it's ANSI one, otherwise it's no-go (IMHO that's a lost cause).

[Eero Tamminen]

"echo" command would need to output all of its arguments and parse escape sequences (\e, \t, \r, \n, \\...).

Attached is quick implementation, with few relevant escape sequences handled:

0001-Add-echo-command-to-debugger.patch.txt

Does it work OK for you?

[TheNameOfTheGame]

Thanks for the patches. Yes, they are working so far here .

The only thing is with the 'm' command which doesn't respect the count and range passed.

For example:

Code: Select all

m b 400 1

and

Code: Select all

m b 400-401

will print a whole line instead of byte. This is not good for outputting structures.

But I made a patch to correct the routine in debugcpu.c to respect the count and range given. Could you take a look? Patch is attached.

debugcpu.c.diff.zip

[Eero Tamminen]

Thanks for the patches. Yes, they are working so far here .

Ok, thanks, I pushed them.

(Some texts were improved slightly i.e. you need to drop my patches from your repo before pulling, or you get merge conflicts.)

The only thing is with the 'm' command which doesn't respect the count and range passed.
...
But I made a patch to correct the routine in debugcpu.c to respect the count and range given. Could you take a look? Patch is attached.
debugcpu.c.diff.zip

I remembered a mention about a patch. but I could not find it from the list. I'll take a look at the attached diff, but not today (and I'll probably be away for the weekend).

I think separate "struct" command could be still useful. It could take e.g. <address> and args in "[name]:<type>:<count>" format, where types could be b (byte), w (word), l (long), a (ASCII), and except for ASCII, their values would be shown in hex. If name is missing, offset from the address would be shows instead.

For example:

Code: Select all

> r d0
  D0 00002304   D1 00010018   D2 00000013   D3 00000000 
...
> struct "d0" :w:1 name:a:4 version:w:1 data:b:2 :b:8
$2304:
+ $00: 20FF
+ name: ATOS
+ version: 0162
+ data: 00 FF 
+ $10: 00 00 FF FF AA BB CC DD

How does that look like?

[TheNameOfTheGame]

The only thing is with the 'm' command which doesn't respect the count and range passed.
...
But I made a patch to correct the routine in debugcpu.c to respect the count and range given. Could you take a look? Patch is attached.
debugcpu.c.diff.zip

I remembered a mention about a patch. but I could not find it from the list. I'll take a look at the attached diff, but not today (and I'll probably be away for the weekend).

I think separate "struct" command could be still useful. It could take e.g. <address> and args in "[name]:<type>:<count>" format, where types could be b (byte), w (word), l (long), a (ASCII), and except for ASCII, their values would be shown in hex. If name is missing, offset from the address would be shows instead.

For example:

Code: Select all

> r d0
  D0 00002304   D1 00010018   D2 00000013   D3 00000000 
...
> struct "d0" :w:1 name:a:4 version:w:1 data:b:2 :b:8
$2304:
+ $00: 20FF
+ name: ATOS
+ version: 0162
+ data: 00 FF 
+ $10: 00 00 FF FF AA BB CC DD

How does that look like?

Absolutely, a struct command would be very convenient and helpful . I think your idea is good. Maybe be able to name the structure like instead of (or in addition to) "d0" be able to enter structname:<reg, address, symbol> which would show the name and address. If structname was missing then just the address.

Code: Select all

> r d0
  D0 00002304   D1 00010018   D2 00000013   D3 00000000 
...
> struct structname:"d0" :w:1 name:a:4 version:w:1 data:b:2 :b:8
structname: $2304
+ $00: 20FF
+ name: ATOS
+ version: 0162
+ data: 00 FF 
+ $10: 00 00 FF FF AA BB CC DD

But outside of that, the 'm' command patch is still needed since the count and range values are not respected in the current form so thank you for looking at it!

[TheNameOfTheGame]

Since we're talking about structures...

Some structure fields are better represented by decimal, hex, binary or ascii depending on their use.

Would it be possible to specify the value representation in the struct line? Default would be hex if nothing specified.

hex and binary would have a 'h' or 'b' appended respectively. Or could be preprended with "0x" or "$" for hex and "%" for binary if you think that would be clearer.

i.e.

Code: Select all

> r d0
  D0 00002304   D1 00010018   D2 00000013   D3 00000000 
...
> struct structname:"d0" :w:1:d name:b:4:a version:w:1:h data:b:2:b :b:8
structname: $2304
+ $00: 8447
+ name: ATOS
+ version: 0162h
+ data: 00000000b 11111111b 
+ $10: 00 00 FF FF AA BB CC DD

I did something similar when I enhanced the 68000 assembler hatari natfeats interface code and it works good. I've been using it quite a bit in my reverse engineering and it is very helpful to be able to specify the value representation. The code is over at viewtopic.php?t=43588 if you want to take a look.

[Eero Tamminen]

But I made a patch to correct the routine in debugcpu.c to respect the count and range given. Could you take a look? Patch is attached.

It was a bit too complicated, I made simpler version. Does the attached change work as you'd expect?

Code: Select all

$ cat > memdump-test.ini 
m b pc -1
m b pc 32
m b pc 16
m b pc 8
m b pc 2
m w pc 16
m w pc 8
m w pc 4
m w pc 2
m l pc 8
m l pc 4
m l pc 2
m l pc 1
quit 0
^D
$ ./src/hatari --parse memdump-test.ini
Reading debugger commands from 'memdump-test.ini'...
> m b pc -1
Invalid count -1!
> m b pc 32
00000000: 60 2e 02 06 00 e0 00 30 00 00 00 00 00 00 00 00   `......0........
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> m b pc 16
00000000: 60 2e 02 06 00 e0 00 30 00 00 00 00 00 00 00 00   `......0........
> m b pc 8
00000000: 60 2e 02 06 00 e0 00 30   `......0
> m b pc 2
00000000: 60 2e   `.
> m w pc 16
00000000: 602e 0206 00e0 0030 0000 0000 0000 0000   `......0........
00000010: 0000 0000 0000 0000 0000 0000 0000 0000   ................
> m w pc 8
00000000: 602e 0206 00e0 0030 0000 0000 0000 0000   `......0........
> m w pc 4
00000000: 602e 0206 00e0 0030   `......0
> m w pc 2
00000000: 602e 0206   `...
> m l pc 8
00000000: 602e0206 00e00030 00000000 00000000   `......0........
00000010: 00000000 00000000 00000000 00000000   ................
> m l pc 4
00000000: 602e0206 00e00030 00000000 00000000   `......0........
> m l pc 2
00000000: 602e0206 00e00030   `......0
> m l pc 1
00000000: 602e0206   `...
> quit 0

[TheNameOfTheGame]

Yes, thanks, that is working good. Well, I think mine was a little more complicated partly because I was aligning the ascii bytes so they weren't ragged-edged. Here is from your patch:

Code: Select all

m b 512a 16
0000512A: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> m b 512a 15
0000512A: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ...............
> m b 512a 17
0000512A: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0000513A: 00   .
> m w 512a 8
0000512A: 0000 0000 0000 0000 0000 0000 0000 0000   ................
> m w 512a 10
0000512A: 0000 0000 0000 0000 0000 0000 0000 0000   ................
0000513A: 0000 0000   ....

and here is with the alignment from my patch:

Code: Select all

> m b 512a 16
0000512A: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
> m b 512a 15
0000512A: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ...............
> m b 512a 17
0000512A: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0000513A: 00                                                .
> m w 512a 8
0000512A: 0000 0000 0000 0000 0000 0000 0000 0000   ................
> m w 512a 10
0000512A: 0000 0000 0000 0000 0000 0000 0000 0000   ................
0000513A: 0000 0000                                 ....

Just a small difference, I like the neater look with the right-aligned ascii, but hey, no biggie, I'm super happy to see this change get in to the next release ! Thanks so much for your help and advice.

[Eero Tamminen]

Yes, thanks, that is working good. Well, I think mine was a little more complicated partly because I was aligning the ascii bytes so they weren't ragged-edged.
...
Just a small difference, I like the neater look with the right-aligned ascii, but hey, no biggie, I'm super happy to see this change get in to the next release !

I was dithering a bit about this, and after trying it decided the extra few lines of calculations were not worth making straightforward code harder to read.

EDIT: I've pushed it to Hatari repo now.

Since we're talking about structures...

Some structure fields are better represented by decimal, hex, binary or ascii depending on their use.

Would it be possible to specify the value representation in the struct line? Default would be hex if nothing specified.

hex and binary would have a 'h' or 'b' appended respectively. Or could be preprended with "0x" or "$" for hex and "%" for binary if you think that would be clearer.

Sounds reasonable. For consistency with the other Hatari output, prefixes would be used instead of h/b suffixes.

Should struct syntax have some support for aligning addresses/labels and their values? If yes, any suggestions what it should look like?

(I don't think I'll have time to look into struct command before the release, but having spec / help text ready will help.)

[TheNameOfTheGame]

EDIT: I've pushed it to Hatari repo now.

Good to hear! Thanks again.

Sounds reasonable. For consistency with the other Hatari output, prefixes would be used instead of h/b suffixes.

Should struct syntax have some support for aligning addresses/labels and their values? If yes, any suggestions what it should look like?

(I don't think I'll have time to look into struct command before the release, but having spec / help text ready will help.)

Hmm, haven't thought about that tbh. My first impression is that when defining a structure, the alignment would be the responsibilty of the user as they should know what they want? But you probably have some insight I am lacking . What would be the use case condition for considering alignment support in the syntax?

[Eero Tamminen]

Consider original proposal:

Code: Select all

$2304:
+ $00: 20FF
+ name: ATOS
+ version: 0162
+ data: 00 FF 
+ $10: 00 00 FF FF AA BB CC DD

Versus value aligned one:

Code: Select all

$2304:
+ $00:     20FF
+ name:    ATOS
+ version: 0162
+ data:    00 FF 
+ $10:     00 00 FF FF AA BB CC DD

Versus right aligned labels:

Code: Select all

$2304:
    $00: 20FF
   name: ATOS
version: 0162
   data: 00 FF 
    $10: 00 00 FF FF AA BB CC DD

PS. Default output number format will what user has set (see "nNumberBase" option in your Hatari config and "help setopt").

[TheNameOfTheGame]

Yes, some alignment would be good considering those options. Otherwise it becomes more difficult to read the structure values.

Imo, value-aligned or right-aligned are both better than the original one.

[Eero Tamminen]

Yes, some alignment would be good considering those options. Otherwise it becomes more difficult to read the structure values.

I pushed initial implementation of "struct" command.

(And fixed "memdump" ASCII columns alignment.)

[TheNameOfTheGame]

Oh wow, nice surprise! Thank you so much.

[Eero Tamminen]

Oh wow, nice surprise! Thank you so much.

With the added number bases support, it should be now complete. Please tell if you notice any problems with it, or if it works fine for you!

PS. When I next have time, I'll probably look into memory find/search functionality: https://www.atari-forum.com/viewtopic.php?p=459570

If you have suggestions for the syntax of such command, please comment on that thread too!