Appears to be working well when I tested running xemu from my 220-uartmon-update branch against m65.exe for this example case:
Xemu:
build/bin/xmega65.native -uartmon :4510
M65:
bin/m65.exe -l tcp -S
This created a somewhat successful screenshot of the xemu screen:
I also tried running bin/mega65_ftp.exe -l tcp. This managed to do the GO64, but stalled after that.
So while the conversation with xemu doesn't work as well as with real hardware, this appears to be due to xemu presently not supporting some of the io-registers used by tools like m65 to perform their remote-io tricks.
See this discord thread for further discussion on that:
Appears to be working well when I tested running xemu from my 220-uartmon-update branch against m65.exe for this example case:
Xemu:
build/bin/xmega65.native -uartmon :4510
M65:
bin/m65.exe -l tcp -S
This created a somewhat successful screenshot of the xemu screen:![xemu m65 screenshot](http://gurce.net/Logs/images/img_2021_05_18_6_02_16.png)
I also tried running
bin/mega65_ftp.exe -l tcp
. This managed to do theGO64
, but stalled after that.So while the conversation with xemu doesn't work as well as with real hardware, this appears to be due to xemu presently not supporting some of the io-registers used by tools like m65 to perform their remote-io tricks.
See this discord thread for further discussion on that:
So given as the goal of the card was to provide tcp connection capabilities, I believe this goal has been achieved.
For xemu-specific matters on missing io-registers, we can raise cards on xemu to sort these matters out later