lgblgblgb
commented
2 years ago @ki-bo Current monitor capabilities in Xemu is halted to be developed since the VIC-IV merge since so much re-invent the main emulation loop was needed, so currently - I guess - it's an unknown working state and I don't even care, since it would made impossible other things to develop so much tight integration is needed. I mean "not care" in the sense that I have/had to prioritize other things. I meant this as a kind of explanation that indeed TONS of things missing and/or works differently as should or buggy like hell in this regard of uartmon capabilities. It's already a miracle at all if it still works to any extent, as with the mentioned merge, I thought I totally brake it. My current plan is to replace the whole uartmon. Some parts are already in Xemu just cannot be used now because of being incomplete. The theory behind: the actual handler for the I/O of the uartmon protocol itself is moved into a thread so it can be much more finer than a per-frame uartmon processing. Things which needs sync interaction (and not async, like from thread directly) will be passed through lock protected structures / FIFO or something between the uartmon connection handler and the main emulation thread (which will be higher frequency to be executed, ie at every scanline versus the current per frame).
Gurce (from Discord) already made lot of work on uartmon and I always tell him as well that it does not worth to commit too much things (or do PR) now as it's by will that I cannot accept anything at this stage of always reorganized method used for the main emulation loop and the reorganization of the uartmon as well.
But to make it clear, of course I am interested, it's not that I refuse to have it, it's just realistically it's not so much "the time" for it. Xemu is still not mature enough I need to put all my energies to have correct emulation at all, debugging is just another level after we have acceptable emulation at all, otherwise it does not even worth to debug anything if emulation itself is not good enough yet. Hopefully you see my point here.
I really have the hope that the finished current project of new hyppo, HDOS virtualization etc, can be followed (if no other major project arise meanwhile ....) I can continue my abandoned work on the new uartmon framework though!
Btw, this is the beginning of the thread / connection handler itself in Xemu (not used so much currently):
https://github.com/lgblgblgb/xemu/blob/master/xemu/emutools_umon.c
One interesting thing with it that it's TCP/IP only (no more UNIX domain socket support, as some arch like Windows does not support it) also it's a dual-mode stuff, ie Xemu can emulate being a http server, and provide a protocol over http optionally if it detects the request being http. My intent with this, that other than the standard m65dbg client and similar stuff, some can even implement a platform independent JS/HTML based client with very advanced features like decoding screen content as real display or virtually anything. This would require in case of a native client for each archs (like win, macos, linux ...) since the native GUI of these OSes are too different (or some cross platform UI widget library which then already almost a project comparable in size and complexity with Xemu itself). While developing a client "in web framework" is network/web transparent, OS independent etc. But even if you don't like the idea, the old protocol still will work of course! Nothing forces anybody to use any web bullshit, if they treat my idea as a BS ;)
ki-bo
The MEGA65 serial monitor supports a load command to inject a binary data stream directly at a given load address. This feature is still missing in Xemu
I'd like to have this implemented so my own debug tools are working in a similar way with both Xemu as well as a real HW target.
I created a branch in my Xemu fork and implemented it in part_monitor.c. Just let me know if you would be interested to have this as a PR.