Hold down shift at boot-time to skip autoexec.txt

[stevesims]

Acorn systems would allow you to skip running the boot file if you held down shift at boot time. It would be nice if we could do this too.

NB this may require changes to the VDP to support this behaviour, since it is the VDP that interfaces with the keyboard.

(Acorn systems could be configured to not boot - holding shift would actually invert the boot behaviour.)

[sijnstra]

I've had a bit of a look at the code and was wondering if as an interim approach that didn't require VDP behaviour changes, how about reading the status of the keyboard LEDs prior to running autoexec.txt, and if <Caps lock> is lit up, don't run autoexec.txt Could even make it a think if any LED returns "on".
I think there's enough time between the VDP turning on, and MOS seeking autoexec.txt to allow you to press the caps lock (or num lock or scroll lock) to prevent the EXEC.
Noting that the current behaviour is to reset the status of those LEDs as part of the VDP power up sequence, so pressing any of those lock keys would be a deliberate and timed move.

[stevesims]

part of the general problem with this idea is the separation of the VDP and MOS. Each processor can potentially be (re)booted independently of the other.

the VDP also doesn't send over to MOS the current keyboard state at boot-up time. so MOS can't currently know that a machine has been powered on with a key held down.

whilst it is potentially possible for the VDP to detect a new MOS boot-up (which it could probably do via the "poll" command), and then send packets to reflect the current keyboard state, this may not be the most sensible option. the main issue with this is that this may result in the VDP sending several packets of info, and as comms from the VDP to MOS has no flow control this could result in missing data. it would not be completely reliable. any mechanism to send a dump of keyboard info packets would not be reliable.

our current keyboard handling code inside the VDP is a relatively simple wrapper over keyboard code we inherited from fab-gl. currently we basically only ever ask for the "next virtual key" and if any such data is found the VDP will send a "keycode" data packet to MOS.

there is an isVKDown API that could be used to allow the VDP to prepare and send a specific "keycode" data packet related to a specific key. so we could add a VDP command to explicitly ask if a "shift" key has been pressed. the difficulty with this idea is detecting that we're running with a VDP that supports such a command. (it's working out that the VDP does not support such a feature that's the problem)

if we implement proper flow control from the VDP to MOS (which we will likely need for some other features) then this could let us just automatically send info packets on current "shift" key status after flow control has been negotiated.

for a potential solution to flow control see breakintoprogram/agon-mos#126 and breakintoprogram/agon-vdp#146 NB it's not clear to me at this time whether the approach taken in these PRs is backwards compatible, specifically whether a MOS compiled with such changes will work correctly with a VDP that does not have them.

[sijnstra]

I do like the idea of using proper flow control - it causes some weird issues not having it, but I think there's another way to detect shift without the multiple packets.

I agree that the response back from the VDP effectively needs to be atomic to ensure that you are making the sync and not missing anything.

It's interesting to work out which use case would be a problem. What if we modified the general poll to return the poll value XOR 0x80 if the shift key is held down? I think the impact would be very minimal. The packet itself seems to have little purpose outside general poll during boot, and the boot could detect if the top bit is flipped to set a flag for ignoring autoexec.

At that stage, the main risk would be if you did hold shift down during boot, a MOS that didn't know about the feature would hang rather than respond appropriately.

[stevesims]

I think it's simplest to just add a new "update key info" command to the VDP that's a wrapper over the isVKDown API. MOS can call that at boot time, immediately after it has done it's "wait for ESP32" thing. as there is already a call to read screen mode information in that sequence which waits for a response, if the "update" call is called before that then the keyboard info will be properly updated by the time the boot file is about to be run

running that on a machine that doesn't support the "update key info" command on the VDP would be safe - we won't be hanging around waiting for a response, we just wouldn't have received an updated "key code" VDP protocol packet

yes, this involves sending one more command to the VDP at boot time, and one more response - however that's a grand total of 4 bytes sent and 6 bytes received

this way there's no modifying of existing functionality, just a new thing, and something is guaranteed to be compatible

[stevesims]

this has been implemented, and will be included in MOS 3