-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add remote control of the core and menu (via UART and/or Ethernet) #41
Comments
This does sound cool in the sense of remote controlling menus and remote desktopping in, though part of me wonders about the ability to step debug issues on the c64 via a uart monitor too. If it is of a similar nature (same commands) to the mega65's uart monitor, then it could mean we could make use of existing tooling like m65dbg too. But anyways, I won't get in the way of your immediate plans if the more exciting goal is the remote control/desktop experience 🙂 |
I've found the following documentation of m65dbg: https://github.com/MEGA65/mega65-core/blob/development/docs/monitor.md |
Some additional thoughts on existing uart monitor implementation within mega65-core in this discord thread: https://discord.com/channels/719326990221574164/1222391068453244959/1222618515593494712 |
This is part 1 of issue #41 To enable the UART, set the constant ENABLE_UART to true in CORE/vhdl/globals.vhd
Part 1 is now implemented in commit e21f3e5. The feature is default disabled and uses no extra resources in this configuration. To enable the UART, set the constant ENABLE_UART to true in CORE/vhdl/globals.vhd. The keyboard mapping is the same as for the XEMU: |
The use case is to be able to control the core and menu without needing physical access to the MEGA65. This could either be done over the serial (UART) port or over Ethernet.
This feature can be implemented in several stages of progressing usability and complexity.
Note: I already have a proof-of-concept developed for another project on the Nexys4DDR board (https://github.com/MJoergen/nexys4ddr/tree/master/c64).
I expect stages 1-4 to be do-able with very modest resource requirements in the FPGA, and also modest development resources, given that there is already a working POC.
Stage 5 is much more complex: TCP is usually implemented in software, not hardware, so this will likely involve the QNICE CPU, perhaps only after interrupt support and/or DMA support is implemented.
The text was updated successfully, but these errors were encountered: