Also on latest version of openMSX many keys in my keyboard seems to be totally dead (like Ö,Ä,Å) regardless of my kbd_mapping_mode... Unfortunately this week I have no possibility to do testing / give you proper error rapports... Sorry. (64bit Win10)
The second thing, is that different than the break point functionality? You can let openMSX execute any TCL code when a break point or watch point is hit.
Did this change compared to older versions? Did you also try the new POSITIONAL mode?
No, but this seems something I can live with, thanks!
The CHARACTER-mode has newer worked for me... There is AltGr/Kana lock conflict, the keys get stuck to bottom position etc. etc really weird problems that are also partly related to keyboard ghosting. I could not even describe all the problems and that is why I sent the Finnish keyboard to one of your team members in the past... but I guess no solution was found. I was anyway blaming too fast. I don't think it has changed after all. I just tried it in wrong MSX machines.
The KEY-mode has how ever changed. I can't say now exactly how, but I'm very sure that I have not had before 8 dead keys in my keyboard. This is such a big percentage that you can't get along with it without using type-command in console or do something similar... Earlier this was no problem.
Now this POSITIONAL-mode seems to be the new working version. This seems to have a physical key mapped for each MSX-keyboard key so that you can actually write any command you like.
Generating lists of executed addresses as part of a debug session? To support the code coverage feature of Dezog?
Generate messages through the socket when certain addresses are hit? To support the Logpoint feature of Dezog?
As Manuel already said: you can execute arbitrary Tcl code when a breakpoint is hit. So that seems a good fit for your second question. Type help debug and help debug set_bp in the openMSX console for more details.
It's also possible to run arbitrary Tcl code after every executed (Z80) instruction by using 'debug conditions'. Type help debug set_condition for more details. Here's a concrete example: debug set_condition "" {puts stderr [format %04x [reg pc]]}
Note that this will slow down the emulation speed _a_lot_. It may be better to, instead of sending every address, collect the addresses in Tcl and then only send the aggregated data on demand. But of course executing Tcl code after every instruction will always be fairly slow.
There's also the 'cputrace' setting (try executing set cputrace on). This is faster because it's directly implemented in openMSX rather than as a Tcl script, but slower because it generates more data than just the program counter. Though this is more of an internal debugging feature (never meant to be used by external programs). Currently it always prints on stdout, I don't think it's (currently) possible to send this data over the socket connection.
@wouter, thx for the tips. So it looks like I can run any Tcl but if I’m connected as a debugger through the socket how can I see the stderr output of such a script? Or the cputrace output?
Is there a way to trigger an just like when a breakpoint is hit.
