Implement fake RTC showing "time since boot"

[dansanderson]

Is your feature request related to a problem? Please describe. The Real Time Clock is dedicated hardware that provides date and time values to registers, and these registers are used by BASIC 65 as the values of the TI$ and DT$ variables. R3 boards are shipping with a 25% failure rate in RTC chips for the time being; an "external" RTC workaround is available via the Grove connector but core support is not yet complete (issue #591) and requires users to acquire, assemble, and modify appropriate hardware.

It would be easy to ignore the RTC except for three things: the BASIC start-up banner, SD card FAT16 timestamps, and the TI$ variable. https://github.com/MEGA65/mega65-rom-public/issues/24 proposes and includes a patch for removing the display of the date and time from the BASIC start-up banner.

The TI$ variable sticks in my craw a bit because it is available in all previous Commodores as a string representation of the time since boot. A MEGA65 with a broken RTC behaves as a stuck or slow clock, not a zero'd working one, despite the TI variable advancing correctly. This feels like a regression against Commodore BASIC. (One could argue that we've already redefined TI$ by adding colons to the time value.)

Describe the solution you'd like I propose that the MEGA65 Hypervisor have a configuration option to replace the RTC registers with a time-from-boot clock: "Enable RTC: yes/no." The new "RTC disabled" mode would set the clock to 00:00:00 2000-01-01 on hard boot, and advance the clock via the CPU similar to how TI is advanced.

This new mode would allow these registers to be written by software, which is not currently possible with the RTC. This would prepare the clock for a future case where we might support setting the clock on boot from a networked time server. BASIC 65 could be enhanced to allow assignment to TI$ similar to BASIC 2 and 7. Software that uses a real-time clock value can prompt the user to confirm or set the time.

This provides a useful value everywhere the RTC value is available, and helps 25% of MEGA65 owners feel less like they own a broken or incomplete machine. I believe this would be welcome even with a fully functional external RTC option.

Describe alternatives you've considered

Alternative: Rewrite the RTC implementation in the core such that it only uses RTC hardware to set a CPU-managed clock at boot, instead of hard-wiring the registers to the RTC hardware. Allow writing to CPU clock registers. Broken RTCs would set the clock incorrectly, but the clock would advance and could be set from BASIC or from software. No changes to config.

Alternative: Complete the external RTC implementation and help affected users acquire and install RTCs. Offer no other solution.

Alternative: Disable the time in the BASIC banner (as is already being considered), and do nothing else. In affected cases, only software that uses RTC values or the TI$ variable have incorrect behavior. Remove the vector clock demo app from the demo disk.

Alternative: Do nothing at all. In affected cases, BASIC banner displays an incorrect time and cannot be fixed.

Additional context

GO64
ARE YOU SURE? YES

READY.
?TI$
000002

READY.
TI$="001001"

READY.
?TI$
001003

[dansanderson]

Issue #591 is fixed in the latest RC2 test core that will become the batch 2 factory core and recommended upgrade core for batch 1 users. I still think this is a compelling feature request but I would now consider it lower priority, to the extent that an external RTC is an option to repair the original functionality.

Of the 25% of owners affected by the broken internal RTC issue, not all of them can or will pursue an external RTC fix. Disable RTC or Alternative 1 gives these owners a way to restore functionality up to the C64's capability.

Disable RTC or Alternative 1 might be useful for all owners, as a way to set a soft clock during a session that overrides the hard clock.

[dansanderson]

I'm satisfied with the R3 RTC workaround and the R6 overhaul of the RTC. BASIC programmers can live without a writeable TI$ variable, and ML programmers can use KERNAL routines to set and read the CIA TOD clock.