Going back to my installation notes herehttps://www.exxosforum.co.uk/atari/last/ ... lation.pdf, I wrote:PaulJ wrote: ↑Fri Sep 11, 2020 7:21 pm @rubber_jonnie , it canbe made to work with 2.06 but the app is pretty bad. Most of the time when I try and set the date it complains about the day being invalid for the month. This a totally a bs error possibly caused by what I suspect is patch on top of path in the app. I did look at the chip and what is required to program it. Its actually bit banged so you need to shift the bits into the chip and re-assemble them when read out. Guess I'll let it run and see if holds time and date reliably and if so it will fall to the bottom of the priority task list. Also a thought is to use exxos's clock and a gal to decode the clock address. I have a working setup program for that chip which has a much more advanced interface that doesn't require bit banging.
The issue between 2.06 and EmuTOS is somewhat strange... one reads the time from the chip and makes the call to set the machine time which I would guess is the same between 2.06 and EmuTOS.. maybe EmuTOS wants to correct the date? Don't know. I haven't tried EmuTOS 1.00 yet. Thirty years off doesn't make a lot of sense.
"If FMCII.PRG or FMCII_9F.PRG say the clock is not running, or that you have the incorrect
number of days for the month, it usually indicates the clock has never been set. This might
be after a battery change. Set the date to something like 1/1/99, and the time to anything
other than what is shown when the software boots. Hit the set button, and it should take
this. Hit reread, and you should see the seconds increment. You can now set to the correct
time."
In the same notes I also say the battery must be present and good, or clock setting won't work, and may drive you insane.
Question? Did you load the DALLRTC.PRG file at boot from the auto folder under TOS 2.06? If the clock is unset, or you wish to change it, you cannot set it if this PRG is loaded first, as per my instructions:
"When using TOS 2.06, I encountered some odd behaviour when setting the clock as above. I found
it was first necessary to boot without loading DALLRTC.PRG, so you may as well boot with an empty
AUTO folder.
It was then necessary to use FMCII.PRG to set to the correct time, but a date below Y2K, such as 99
(1999).
From there, it was possible to use FMCII_9F.PRG to set a date of 116 (2016) successfully.
After that you can happily boot with DALLRTC.PRG and AUTOFMC.PRG in your AUTO folder.
Don’t forget, the DS1315 is Y2K compliant, so setting it isn’t really the issue with the right
combination of software, but reading the clock and passing the data through to TOS is where the
Y2K fix is needed in order for everything to behave correctly."
First you clean boot, then use FGMCII.PRG to set the clock to 1999. Then use FGMCII_9F.PRG to set to a current year, 118=2018, 119=2019, 120=2020 etc. Once done you can set the time/day/month too.
Once the clock is set in that manner the date/time will hold just fine and you can boot with DALLRTC.PRG and AUTOFGMC.PRG in the Auto folder and all will be fine. I tested up to TOS 1.62 and this process was only necessary when it came to 2.06.
It is a reverse engineered circuit from a ForgetMeClock II, so unfortunately we are in the situation of having the ghastly mess that is the clock setting software for that, unless somebody is able to write something new. This is the same case if you were using one of exxos RTC clock cards, which are based on the same design, and was what was built into the H4.
The Mega clocks are way better, based on a Ricoh chip if memory serves, and can be easily set from the control panel. My Mega STE is a little different in that it gets the time set by my CosmosEx That way I can bin off the battery and not worry about battery goo all over my nice pristine mainboard!
If I recall, and I might recall wrong as my hard disk isn't what it once was, the trick to getting around Y2K is to set the date in the past and then the DALLRTC.PRG adds something like 20 or 30 years years on to kludge the year into being correct.
Try loading DALLRTC.PRG and AUTOFGMC.PRG under EmuTOS if you haven't already tried, see what it reads back.