OpenMSX debugger: We have high level block commands like "showmem"/"cpu regs". Do raw (not beautified) block commands exist ?

Page 2/4
1 | | 3 | 4

By friguron

Expert (82)

friguron's picture

30-05-2019, 20:27

Manuel wrote:

help debug read_block?

________________________
help debug read_block

debug read_block <name> <addr> <size>

Read a whole block at once. This is equivalent with repeated invocations of the 'read' subcommand, but using this subcommand may be faster. The result is a Tcl binary string (see Tcl manual).
The block is specified as size/offset in the debuggable. The complete block must fit in the debuggable (see the 'size' subcommand).
________________________
This is what that help command yields. It speaks about debuggables (?), and about some <name> parameter that you should know beforehand. If not you're lost... Just adding a small usage example at the end of the explanation would be real useful for the newbees like me Smile ) A help line should be autoexplainative, with no need to go to some other parts of the manual (if possible).
But as I said, it's just a suggestion.

My original doubt is now solved anyway, and as soon as I add some new .tcl script on my openmsx I'll get the intended behaviour for my needs. BTW, if I add/create new commands inside the .tcl share folder, can this commands be added to openmsx for the big audience ? Is this the intended function of this folder?

Greetings.

By friguron

Expert (82)

friguron's picture

30-05-2019, 21:03

BTW, this made me think...

You're telling me that all the available commands inside the console/debugger are just the reflection of the many local files you might have inside the share folder of an openmsx installation?

If so, is there an official .tcl files set list? I mean, my needs are the ones I asked for at the begining of this thread, but if I need to add an extra .tcl file to that folder to meet my requirements (to enhance a console/debugger command), then my PoC won't work against the official distribution of openmsx another user might have installed on their computer...

Or are there some hard-coded commands inside the debugger/console also?

By Manuel

Ascended (15529)

Manuel's picture

30-05-2019, 21:04

What do you mean with 'for the big audience'?

If you create a script that may be interesting, you can post it here and tell that you're OK to include it in openMSX. Or you can make a pull request on openMSX GitHub.

The name is the name of the debuggable. Check debug list (and its help) and do not forget the TAB key in the console. If the command expects a debuggable, it will show a list of them if you press TAB.

By Manuel

Ascended (15529)

Manuel's picture

30-05-2019, 21:05

There are both built-in (internal) commands and commands in the .tcl files.

What do you mean with 'official'?

By friguron

Expert (82)

friguron's picture

30-05-2019, 22:27

Ok, I just thought the process of adding scripts needed more thorough supervision by the project main coordinators Smile Of course it will be ruminated and so, but you get what I mean.

By "official" I mean I might create some external tool that requires my (futurible) new script to be also installed and properly running on openmsx... Maybe that script will appear in the official commited version 0.16.0 (once we all decide is ok). Whatever.

What does it happen if my new (futurible) external PoC/tool is run against a 0.15.0 official release which doesn't have my (futurible) new script in the shared folder? My tool wouldn't work...

But hey, I'm more happy knowing I just have to create "my new" tcl scripted command, add it into the shared folder, and then a new debugger command will appear in a futurible 0.16.0 version of openmsx.

My concern is I find adding and letting the users edit scripts is powerful, but it's also prone to users potentially "breaking" their functionality (of course, it's a really strange case).
I suppose I imagined a core set of internal debugger/console commands, not editable, being considered the core of debugger commands. Somewhat frozen in some internal document: "these are the commands, those are the scripts"...

By friguron

Expert (82)

friguron's picture

30-05-2019, 23:50

BTW, I think I've already created my script (so easy altogether)... I'll contact you in private so you can add it into the .tcl shared folder in the exact place, as a new .tcl file, or as a part of an already existing .tcl script...
Thanks.

By Manuel

Ascended (15529)

Manuel's picture

31-05-2019, 00:03

Thanks for contributing. But at the moment I have no clear idea what it will do... (I didn't read the full thread yet...) but we'll have a good look Smile

The debug command is completely implemented in the openMSX core, as far as I know. Many supportive commands in the tcl files are using it.

By friguron

Expert (82)

friguron's picture

31-05-2019, 00:30

My pleasure... No hurries whatsoever, really, as now I have my script locally and I can work with it...

Of course I only hope it finally gets integrated into openmsx some day, or else my future tool won't work...

By turbor

Champion (424)

turbor's picture

31-05-2019, 00:39

Your future tool can also launch openmsx with an extra '-script' commandline to read the script from the same directory as your tool. It doesn't need to be integrated into openmsx for that.
Or you can load your tcl script into openmsx using any of the pipe or stdio methods that you would be using anyway to communicate with openMSX...

By Manuel

Ascended (15529)

Manuel's picture

31-05-2019, 01:32

What the openMSX debugger does is what turbor also suggests at the end: it defines a command (that it sends to openMSX) to format the data in a safe way. See https://github.com/openMSX/debugger/blob/master/src/Debugger...
When reading a block, it prepends that command to encode the data: https://github.com/openMSX/debugger/blob/master/src/OpenMSXC...

Page 2/4
1 | | 3 | 4