#80 More variables for debugger

[TK Fan]

There are some variables in debugger which value can be assigned or used in expressions: Z80 registers or register pairs, IM, IFF1 and IFF2. Same behavior could have the last byte sent to a peripheral (ULA, AY, 128Mem); their values are already listed in debugger window. Other useful variables are: last byte sent to/received by data bus; last address put onto address bus; T-states since last reset; number of frames generated since last reset.

[TK Fan]

I am interested to detect 128K program that uses secondary video. It'd be done very easily with:
br p w 32765 if 128Mem&8

[Sergio Baldoví]

Here is a patch which adds more registers:

Setters and getters:
- 128Mem: last byte sent to the 128K port
- 3Mem: last byte sent to the +3 port
- AY: AY's current register
- tstates: T-states elapsed since the last interrupt

Only getter:
- ULA: last byte sent to ULA

[Philip Kendall]

Rather than hard-coding things in the debugger, I'd like to move to a system where modules can register "variables" into the debugger, similarly to how they register events at the moment. For example, the AY code could call something like

debugger_register_variable( "ay", "current", get_current_register, set_current_register );

static int get_current_register( void )
{
return machine_current->ay.current_register;
}

static void set_current_register( int value )
{
machine_current->ay.current_register = value;
}

which would then make "ay:current" (or some similar syntax) available as a variable in the debugger.

Ideally all the current registers etc could move to this scheme as well, although we may need a bit of plumbing to keep backwards compatibility.

Does this seem like a stupid idea to anyone?

[Fredrick Meunier]

I think registering this stuff would be good.

[Philip Kendall]

I've pretty much got code to do this, but it got to 1am last night and I decided going to bed was the best course of action at that stage rather than messing around with SVN to create a new branch and stuff like that :-)

I'll try and commit what I've got sometime in the next couple of days.

[Fredrick Meunier]

Accidentally from patch #349:

OK, first cut of code now committed - I'm not particularly happy with the syntax, but it was easy to implement in the debugger and enough to prove that things work. Any suggestions appreciated...

Code is under [r5527]

[Fredrick Meunier]

I don't really use the debugger, but I can say that I could use the registration functions usefully in peripheral code as they exist now.

Looking at the branch, I think you've forgotten to add debugger/system_variable.c? It would also be nice for the debugger to only have events and displays for the current machines/perhipherals so things can be watched without getting unmanageable though that isn't needed for a first cut.

Are you aiming to get this in for 1.2?

[Philip Kendall]

Whoops, system_variable.c added in [r5533].

I'm not happy enough with the syntax yet that I'd want to put this in for v1.2, as I don't want to put it in, have people use it and then change the syntax in v1.3. But if I get time to do some more work on this and come up with a better syntax, or work out that the current syntax is the best I can do then it might be worth getting in for v1.2. But not the end of the world if it doesn't.

[Fredrick Meunier]

For 1.2, I think the most important thing is to get it out the door and focus on a 1.2.x or 1.3 a month or so following the release, so based on your description I think that we should aim to get this in the next release unless it is finished very quickly.

[Philip Kendall]

OK, think this branch is now pretty much ready to merge. I managed to remove the need to specify "%" for system variables, so (to take TK90XFan's example above) the syntax would just be

break port write 0x8002:0 if ula:mem7ffd & 0x08

The Z80 registers etc are exposed via the same syntax (z80:af, z80:bc, etc). I suggest removing the "bare" syntax (break 0xa000 if bc == 0x1234) in Fuse 1.4.

Any thoughts / comments etc before I merge? Other variables can be added in other patches :-)

[Fredrick Meunier]

It looks like a pretty clear step-up from what we have at the moment. At a quick look there seem to be a few calls to debugger_system_variable_register() longer than 80 characters :)

It would be nice to have some enhancements to only register variables for active hardware and to limit the debugger UI to only show information for active hardware but that can be stuff for someone to tackle in the future.

[TK Fan]

I'm glad to see active development in this feature request. I think debugger is going to be more useful with this.

[Philip Kendall]

Unless anyone objects, I'll merge this in the next few days.

[Philip Kendall]

And now merged.