a2stuff
New DA: No-Slot Clock control
Good First Bug notes:
An ambitious approach would be extend the Date & Time (see #11) DA:
- If the system has no realtime clock, just set the ProDOS date/time
- Otherwise, determine which type of clock (NSC, Thunderclock, Dclock, Cricket, ...) and use appropriate code to set it.
A less ambitious approach would be to just make a control panel specific to the NSC, and let users figure it out. No shame!
Added complication: some of the clock detection routines rely on trying to read the time and failing if the time is not valid. That would be a challenge if the goal of the DA is to let you initialize the RTC, rather than just adjust the time. The Cricket! driver works that way at any rate.
For The Cricket! and NSC a dedicated DA for setting the date/time with an explicit "pick the clock" option might make sense.
For reading the NSC, wouldn't it be simpler to install the .SYSTEM driver? Seems to work for other prodos system disks.
For reading the NSC, wouldn't it be simpler to install the .SYSTEM driver? Seems to work for other prodos system disks.
A multi-clock CLOCK.SYSTEM driver is already included. But that's for reading the clock, not setting it, which is what this issue is about.
To clarify: if the goal of a DA is to set the clock, we first need to detect it. But the current detection logic in most drivers is to try to read the clock and get a valid time. If the time is not yet set, that would fail.
I will have to look at the CLOCK.SYSTEM source, as it fails to detect the one in my emulator, which I've plonked on slot 1 -- it's detected by the NS.CLOCK.SYSTEM "Official driver" tho, so there must be a difference in probing. I've put it there because the driver probe looks there first! To detect it should be fairly easy, even with the clock not set, it will still return 64 bits of uninitialized clock I suppose, so will change the LSB of any ROM byte that is read to do the probe...?
A2D includes the "jumbo" driver from https://github.com/a2stuff/prodos-drivers
Isn't this something that ought to be in the driver? Ie currently the clock probes and install the clock reader routine, but there isn't a vector for a 'set' --- perhaps we'd need one somehow? That way the DA could look to see if there is a 'set', enable editing, and call the driver handler when done?
In an ideal world, yes. But in practice, the driver is restricted to 125 bytes and ProDOS only defines reading the time, not setting it. There's no established practice for setting the time outside of bespoke utilities that shipped with each clock.