• Please review our updated Terms and Rules here

How does DOS detect the presence of an RTC?

Well, again, all you need is a program to read the RTC set the time of day and date through Int 1ah. You can go away after that. If the date rolls over, I think the date adjustment is handled in CLOCK$--I haven't checked, but it seems reasonable. As to what happens if the PC sits idle for two days--I think that may be a problem.

FWIW, I personally never have my XT on for more than a few hours at a time so… yeah, I don’t think I’m ever going to worry much if DOS’es built-in timekeeping starts drifting from the battery clock’s take on it, it’s going to get reset in AUTOEXEC.BAT on every reboot.

Of course the homemade DS1215 phantom clock I built itself drifts by about 5-10 minutes a month so on a whole accuracy is a relative thing. My fix is I set up the “netstart” bat file I use to initialize my Ethernet card with mTCP so it automatically syncs up the DS1215 with an NTP server. Overkill!
 
I‘ve only skimmed it, but are you sure that hard-coded cmos routine in there is used for the simple case of just reading/setting the clock? It seems like most of the routines for that are making the INT 1A function call. The comments around the direct CMOS read/write routines read like it’s there for some kind of edge case?
I think youre right, there do appear to be plenty of calls to int 1A.

There is mention of fixing up some kind of issue related to a tick/interrupt generated by the RTC that could slow down disk access, so maybe those were being used to change the divisor for that tick/interrupt. It was late and I didnt thoroughly read through it all. 😇
 
My fix is I set up the “netstart” bat file I use to initialize my Ethernet card with mTCP so it automatically syncs up the DS1215 with an NTP server. Overkill!
Ive also got an ethernet card in this thing, and the mTCP suite as well, but I havent quite gone down the NTP route just yet. I have done some IRC from it though. 😊
 
If you have used IRC then NTP is not going to be a big deal. The worst part of it is setting your TZ environment variable correctly, so that the SNTP client can know what time zone you are in and when Daylight Savings Time is in effect. That's all in the PDF documentation.
 
One of the interesting issues with a Linux+windows dual-boot system is the difference in timekeeping. Linux keeps time in UTC; Windows is local time. I think it can be resolved with the Windows registry setting.
 
I am looking forward to the day that the EU scraps DST. Ive never been a fan of it. Too much effort. 😋

A previous project of mine was a Z80 based clock that displays 3 timezones. The RTC is configured to run on UTC, and then I have a series of timezone records with their respective offsets from UTC, and when they change in to and out of DST. It was a pain to write all of that in assembly.
 
One of the interesting issues with a Linux+windows dual-boot system is the difference in timekeeping. Linux keeps time in UTC; Windows is local time. I think it can be resolved with the Windows registry setting.
Was never an issue for me. Always accepted that DOS/Windows=localtime RTC.

hwclock --hwtosys --localtime at boot and hwclock --systohc --localtime at shutdown fixed the "RTC is local" issue, usually invoked by setting a config flag which added "--localtime" to the commands in rc.whatever

Systemd probably has the same functionality implemented by some whackadoodle background process that permanently consumes 1MB of memory, but I digress...
 
Was never an issue for me. Always accepted that DOS/Windows=localtime RTC.
Heh, I should have expected such a post from someone who is locally on GMT. Here, I'm GMT-8, while you're having your morning kippers, I'm just getting to sleep.

Any any rate, it's a simple systemd command:


All in all, the Linux scheme seems to be more common-sense. Keep everything in UTC and apply an offset when localtime is desired.
 
According to Google "[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001" is how to set Win7 to use UTC for the BIOS clock. I have a PC that dual boots Win7/Linux that I set up using this years ago.
 
That's the registry setting I was thinking of. Haven't abused myself with regular Windows use for several years now. I have one system with Win7 installed, just in case....and it's triple boot (98SE, 7, Buster).
 
Heh, I should have expected such a post from someone who is locally on GMT.
The UK has daylight savings, which GMT has not. So it is an issue for them as well, although particularly serious. :)

I know of three ways to deal with the issue:
A: Have the BIOS use localtime, and configure Linux accordingly. However, this breaks when DST is involved, as all systems may change the time when booted first.
B: Have the BIOS use UTC, and configure Windows accordingly. However, this requires changing the registry, which is a barrier. (It also seems to break because Windows Internet Time Service apparently ignores the key.)
C: Have the BIOS use localtime, and configure all systems to be in UTC(!). However, this requires you to change the clock manually for DST (unless at least one system uses NTP or similar).

There seems to be no universally great solution, but - as always - there are a lot of tools out there handling this.
 
Personally, I don't bother--because I don't use WIndows much. I'm willing to put up with the "wrong time" issue on the rare occasion that I'm running it. How about a separate hardware RTC for each OS? :)
 
My current idea (and part implementation) is simply a small utility which you can tell what IO address(es) the RTC is located at (and some jumpers on the board to configure its address, since it cant live at address 0x70/71 on a PC/XT as those addresses are decoded for another peripheral) and it will then be able to read it at boot to set the DOS time via int 21 (and maybe system time via int 1A), and write back to it to set the time. That could simply be called from autoexec.bat or some such with a flag. But I suppose I was hoping that there was some way to tell DOS where it was located so that maybe it could all be more tightly integrated and "automagic".

Wow, reading this is kind of funny because I just wrote an option ROM that does exactly that! Hadn't seen this thread until now. I assume you found the answers you were looking for?

What I found was that (on DOS 3.3 and up) implementing INT 1Ah AH=2-5 is sufficient to provide that "automagic" clock with a non-cmos RTC. DOS probably does read 70h/71h cmos directly in some cases, but it's either a fallback with INT 1Ah or just used for other AT+ purposes (I'm not sure exactly, haven't read through that source). The only other thing you "have to" do during POST is set the BIOS time ticks (via INT 1A AH=1) to the correct value by calculating the number of ticks since midnight (this is actually one of the less simple parts of this) based on the time you read from the clock. That's because in DOS's clock, the time portion is kept by the BIOS in the BDA, but the date portion is kept by DOS... go figure!

But all of the hardware details I already know (different chips, addresses etc etc). Im building my own board with an RTC (MC146818A) for my XT, and looking at the software side of things and how to integrate it. Ive made the hardware as analog as possible to the AT implementation (down to the same dual IO port scheme to write the register address and read/write data).

So here's the link to my project: https://github.com/640-KB/GLaTICK. It does support the MC146818A/DS12x85 on ports 70H, 240H and 2C0H ("out of the box") so if your RTC adapter does use the standard "CMOS" type interface it may just work for you straightaway.

I was wondering about the idea of an ISA clock card like that with the RTC and a ROM so something like this could be installed together and the clock is completely self-supporting. Is that what yours is going to do? If so, maybe these two projects could work together? :)

640KB
 
My board is going to include a few things, including a socket that can be used for option ROM development.

But I was hoping to avoid needing to go the option ROM route (at least initially, but my ambitions will probably change) for the RTC, and just go with a small companion app, and after that a DOS clock driver.

It would also be interesting to see it be compatible with other software that is out there already, so in that respect Im fully open to a collab of some kind. For learning and "for the fun of it" purposes Im committed to writing my own software tools as well. :)
 
Back
Top