> Anyway, it seems to be a bit complex solution, maybe it's even similier and > faster to extend remote monitor protocol for quering information returned > in raw byte stream, it's still true that SHM memory is faster to use, but > since you need to know mapping information etc, I am not sure it will be > faster than, and at least it's quite complex task then ... At the moment it's only slow because I have not made it as fast as I can. Once I get to the point of a)having all the logic in place to support updating the debugger displays, and b)have made said logic as fast as I can without having other options [SHM], then I think it'd be a good time to approach this. When I run "m $0 $ffff" in a telnet session connected to the remote monitor the response is quite fast, so it's obvious to me that the problem is on my end at the moment. As I stated, I'm using blocking calls...and I'm being rather "dumb" about how I'm doing it because at present I only care about the data not the expediency. If there are extensions to the monitor that can be made to make memory-regions query/set-able then I'd ask that those take priority over this if they're not already there. ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Wed Mar 28 16:00:33 2012
This archive was generated by hypermail 2.1.8 : 2012-03-28 16:00:36 CEST