[kfox]

A serial command to set the real-time clock. Until now the clock could only be set from NTP, which needs Ethernet, or stepped an hour, minute or second at a time from the menu. GEOS 64 (#70) starts with the TR's time, so this is how a board without Ethernet gets it right.

SetRTCToken (0x6474, "dt") takes UTC seconds since 1970, 4 bytes big endian, and answers AckToken or FailToken. Away from the menu it is refused with "Busy!", like SetColorToken, and its 4 time bytes are read and dropped so none of them runs as a command of its own. The time zone setting still applies when the TR shows or hands on the time. docs/ControlComms.md documents it.

tools/bench/setclock.py sends this computer's clock, or a given ISO 8601 time (UTC unless it carries an offset).

Tested on a TR+:

• At the menu, the clock set this way matched the host to the second after a menu reset.
• With GEOS 64 running, times whose low byte is e, b and d (the EEPROM-reset, bus-analysis and command-prefix bytes) were refused with "Busy!", nothing else ran, and the board kept answering.
• On an original TR: set at the menu, the time is right after a menu reset.
• On a TR+ with a working battery: the time set this way was still right after the C64 was off for over a minute.
• test_protocol.py checks the token against the firmware.

[SensoriumEmbedded]

Thanks for the bench script and the clock check.

Memory: RAM1 is unchanged on both targets; flash grows 320 B on the TR+ and 296 B on the TR. No changes needed.

Hardware testing still to do: for one of us to possibly get to before release

Your test covers setting the clock at the menu and reading it back.

• the time surviving a power-off on a TR+ with the battery (as you noted)
• the command while the TR isn't at its menu: it should answer Fail/"Busy!", and the next command should still work, since the 4 time bytes are left in the input as with SetColorToken's payload
• a plain TR

[kfox]

Thanks for the approval, and for spotting the payload bytes a refused command leaves behind.

A refused setclock now reads and drops its 4 time bytes, in the main and minimal images. Left in the input, each would run as a command of its own, and a time whose low byte is e would reset the EEPROM.

Tested since:

• the command while GEOS 64 runs, with times whose low byte is e, b and d: "Busy!", nothing else ran, and the next command worked;
• a plain TR;
• a TR+ with a working battery: the time set this way was still right after the C64 was off for over a minute.

Follow-ups, outside this PR:

• SetColorToken still leaves its 2 bytes in the input when refused (SerUSBIO.ino:619). Valid color values and indexes don't match any one-byte command, so it's harmless from a correct host, but the same drain would close it.
• The menu doesn't redraw its clock after a set until the menu restarts; ControlComms.md says so.