RESET_RUN mode 3 doesn't work with current Etherload accommodation #230
Description
Test Environment (required)
You can use MEGAINFO from within FREEZER to obtain this information
(long press RESTORE to enter FREEZER, then press HELP to start MEGAINFO)
- Platform: MEGA65
- ROM Release: 920416
Describe the bug
In ROM 920416, I added a new KERNAL call RESET_RUN $FF32 that resets the computer in one of several reset modes, selected with the accumulator. This is backwards compatible with the MEGA65 reset vector, which now performs the reset with mode 0 (warm boot). After I released ROM 920416, I noticed that mode 3 (Hyppo reset followed by RUN) wasn't working: it's behaving like mode 1 (Hyppo reset, no RUN)—or, more accurately, a Hyppo reset followed by mode 0.
To Reproduce
10 PRINT "HI"
SYS $FF32,3
Expected: Hyppo reset; ROM prints BASIC 65 banner, prints "HI", then "READY."
Actual: Doesn't print "HI", program space NEW'd.
Additional context
RESET_RUN works by storing the reset mode in $0.2000, then recognizing and performing the mode during BASIC 65 cold boot. Memory at this address survives both a KERNAL warm boot and a Hyppo reset.
As part of this feature, I added a change to the GO64 KERNAL reset vector to force mode 0 (no RUN). Without this, any code path that used the GO64 KERNAL reset vector might accidentally set the mode variable to an arbitrary value written to address $0.2000. This was happening consistently with Etherload, which uses the GO64 KERNAL reset vector after a file transfer, and was also triggering a "RUN" mode with non-BASIC data in BASIC memory ("syntax error").
Hyppo's boot sequence also uses the GO64 KERNAL reset vector, and so with this vector forcing mode 0, mode 3 (RUN after Hyppo reset) is inaccessible. This wasn't an issue before I added the GO64 logic because a cold boot would initialize the value to 0, and a Hyppo reset would remember the variable's setting. However, I think this design would have the same problem as Etherload when the user presses the reset button with non-BASIC data in this memory location. Merely changing Etherload wouldn't be a complete solution.
Solution A: Drop hyppo reset from this feature. I added it because I thought it would be easy and useful. If it's not needed for the target use cases of Etherload, Xemu, and Intro Disks, then maybe we don't need it. The goal is to allow a program to launch another program with something as close to the boot state as possible. I don't know if a simple KERNAL warm boot is sufficient.
Solution B: Make reset-and-run a Hyppo feature. A new Hyppo call takes a reset mode and performs a reset. Another Hyppo call accesses the last-set reset mode. BASIC cold boot uses this feature to read the reset mode and decide what to do. The reset mode can be set and read, survives the reset, and can't be written to accidentally by programs that don't know about it. Cold boot, existing software, and the reset button all use the original hyppo_reset behavior.
Solution C: Add a GO64 jump table entry to a version of the start logic that doesn't force the variable to zero. Create a new Hyppo entry point that performs the reset and uses the new entry point (or perhaps an arbitrary entry point) instead of the reset vector.