Remote control via ethernet to make development faster and easier

[gardners]

Is your feature request related to a problem? Please describe.

When developing for the MEGA65, if you don't have a serial adapter, its a bit of a pain to pull the SD card out all the time to put your program on. Even with the serial cable, its a bit slow if you have large slabs of memory to load.

Describe the solution you'd like It would be great to have an option to remote control the MEGA65 via Ethernet, so that you can immediately reset the machine, and push stuff into memory wherever you like, and then set it running.

Describe alternatives you've considered Do nothing.

Additional context N/A

[gardners]

Setting dip switch 4 will enable this feature. Resurrecting the old etherload program as the MEGA65-side end of it. Will make an "e65" command to go with "m65" that will take broadly similar arguments, but do everything via ethernet, instead of serial. Will require MEGA65 to be on the local network, i.e., no router support. Layer 2 switches will be ok, including transparent wifi APs.

[gardners]

@lydon42 correctly pointed out that sw 4 is the core 1/2 select. Using sw 2 instead, which was DVI audio disable, but which can be done in the configure program.

[gardners]

User guide updated to reflect this.

[gardners]

HYPPO side of things now works. 2nd dip switch enables ethernet hyperrupts, and tells eth controller to make ack stale frames so that hyperrupt trigger frames can always be received.

Things to improve:

1. make ethernet scan the hyperrupt frames, even if buffers are full, without needing to store the frame, and thus not having to change the behaviour of the ethernet controller's handling of all buffers full.
2. Modify etherload.c in mega65-tools to relocate the ethload routine from $C000 to somewhere in a higher memory bank or in the tape buffer area or somewhere where it is generally less likely to be stomped on when loading large programs.
3. Modify etherload.c to allow loading multiple segments in different parts of RAM.
4. Modify etherload.c to allow setting entry point address.
5. Modify etherload.c to allow setting up c64 or c65 memory map for exiting to BASIC programs
6. Modify etherload.c so that it confirms reception of every data frame (modify data frame routine to trigger a TX of the received frame back to the sender as simple confirmation scheme)

[gardners]

7. Save PC to $C0FE/FF before launching ETHLOAD
8. Have ETHLOAD save all regs (including stack pointer and location), so that previous prog can be resumed.
9. Document in manual

[ki-bo]

Split feature to resume running programs after launching etherload into own issue #784

[ki-bo]

7. Save PC to $C0FE/FF before launching ETHLOAD
8. Have ETHLOAD save all regs (including stack pointer and location), so that previous prog can be resumed.

These will be done in #784