CMOS cell 6 - day of the week (weekday)

[James Harris]

I am having/had an intriguing discussion with Rod in another thread
(CMOS safe register - was Stuck with loading to high memory) about CMOS
cell 6. In the original (MC146818) chip datasheet it is annotated as

Dav of the Week Sunday= 1

There is the same designation in the Dallas Semiconductor DS12887
datasheet.

Presumably that would mean that today, which is Friday, would be 6. But
I've just booted two machines to a bit of test code and found that say
that the current weekday is 5.

Any idea why it would show 5 instead of 6?


--
James Harris

[James Harris]

Having run some tests I think the answer is: Coincidence!

I pulled a number of test laptops out of storage and put them on test.
Two think it's Saturday. One thinks it's Tuesday. And the other thinks
it's Thursday.

And to be clear they all know it's 1 March 2020 (which is a Sunday) so
they are all wrong!


--
James Harris

[James Harris]

I should make special mention of the Dell Latitude C600 in two respects.

1. Its normal and CMOS batteries had lost power while it was in storage
and it began by reporting the day as zero (which is not in the valid
range). It has since incremented the weekday each time the clock has
ticked over midnight - and kept the number in the range 1 to 7 as expected.

2. What's more important the BIOS itself knows the correct weekday for
any date which the user sets. I know that because it shows the day name
in the screen where the user sets the date. BUT when the user changes
the date that laptop does not set CMOS cell 6 to match. For example, at
the moment the BIOS setup screen correctly says that today is Sunday but
when I set the date to today the BIOS does not make the CMOS weekday
field Sunday. It seems always to leave it whatever it was before.

I think this all confirms, if nothing else, that the BIOS weekday cell
is completely unreliable and should be ignored on read. An OS which
wants to identify the day of the week can, instead, determine it by
calculation.

https://en.wikipedia.org/wiki/Determination_of_the_day_of_the_week


--
James Harris

[Scott Lurndal]

Pulls down "The Undocumented PC", and opens to chapter 15:

"Unfortunately, reading the clock values is a bit more tricky than changing
them. Why make our lives as programmers easy? The RTC chip has an internal
update cycle once every second which takes about 2ms. During this internal
update, reads from the time, date and alarm registers will get unpredictable
data!".

Under Register 06h (Day of Week):

This location indicates the day of the week. Even though the day of the week can
be determined from the date, this register can be incorrectly set to the wrong
day of the week. Generally, the operating system ignores this byte and performs
its own determination of the day of week from the date. See above restrictions
about reading and writing to this location.

[wolfgang kern]

On 01.03.2020 13:10, James Harris wrote:
...

> I think this all confirms, if nothing else, that the BIOS weekday cell
> is completely unreliable and should be ignored on read. An OS which
> wants to identify the day of the week can, instead, determine it by
> calculation.

Yes, I actually set DOW in the CMOS after calculation during boot-up.

>   https://en.wikipedia.org/wiki/Determination_of_the_day_of_the_week

there are many different algorithm possible for this, I use a two LUT
variant which is fast and short, of course :)
__
wolfgang

[James Harris]

On 01/03/2020 11:40, James Harris wrote:

Here's another interesting one. My Jetway NC91

https://www.jetwaycomputer.com/NC91.html

It told me yesterday that the day of the week (which should be in range
1 to 7) was, in fact, 130 (0x82)!

This morning it told me the weekday was 238 (0xEE).

Then on a further power up in the afternoon it said the weekday was 190
(0xBE).

Even after I set the date in the BIOS setup screens the BIOS did not
change the weekday byte.

I think these cases (the Dell and the Jetway) well show that the weekday
byte is unreliable and useless to read - and, hence, is a good cell
(much better than the formerly recommended Register D) to leave the CMOS
address register (0x70) pointing at, which was the point of the earlier
discussion which led to this thread.


--
James Harris

[James Harris]

On 03/03/2020 12:15, wolfgang kern wrote:
> On 01.03.2020 13:10, James Harris wrote:

> ....

>
>> I think this all confirms, if nothing else, that the BIOS weekday cell
>> is completely unreliable and should be ignored on read. An OS which
>> wants to identify the day of the week can, instead, determine it by
>> calculation.
>
> Yes, I actually set DOW in the CMOS after calculation during boot-up.

That makes sense. But do you correct it for any reason? I can't see any
reason why you would read from it later.

Just out of curiosity do you include code to set it correctly if the
machine is booted up in the few milliseconds across midnight...? (I.e.
if the date changes between reading the date and when you would set the
weekday.)



AFAICS there are three potential OS responses to the issues surrounding
the weekday byte:

1. Correct the weekday byte on bootup (as you chose to do).

2. Never read, never write the weekday byte; ignore it completely, which
is what some BIOSes seem to do.

3. On bootup and at midnight set the weekday byte to some /invalid/
value so that there's less chance of some other [ lesser :-) ] OS
booting on the same machine confusing it with something useful.

I am not sure which is best but option 3 is tempting. It depends on the
test written into the tick-over-at-midnight CMOS RTC code. If it is '>='
as in

if weekday >= 7 then
set weekday to 1

then I think I might either go for option 2 (ignore it completely) or
maybe set the byte to 0xff because the RTC will soon set it to a valid
range. But if the RTC code uses '=' in its comparison as in

if weekday = 7 then
set weekday to 1

then I'd be tempted to set it to 8. That way the PC could be switched
off for over 245 days (over eight months) before the weekday would
naturally tick over into a valid range.

Of course, we don't know what test a certain chip will apply as AFAIK we
don't know what has been written in any RTC's internal code. I've seen a
disassembly of a keyboard controller (KBC)

http://www.halicery.com/8042/8042_1503033.TXT

but I've never seen a disassembly of a CMOS/RTC chip.

All rather academic of course, but ho hum.


--
James Harris

[James Harris]

On 02/03/2020 21:12, Scott Lurndal wrote:
> James Harris <james.h...@gmail.com> writes:
>> I am having/had an intriguing discussion with Rod in another thread
>> (CMOS safe register - was Stuck with loading to high memory) about CMOS
>> cell 6. In the original (MC146818) chip datasheet it is annotated as
>>
>> Dav of the Week Sunday= 1
>>
>> There is the same designation in the Dallas Semiconductor DS12887
>> datasheet.
>>
>> Presumably that would mean that today, which is Friday, would be 6. But
>> I've just booted two machines to a bit of test code and found that say
>> that the current weekday is 5.
>>
>> Any idea why it would show 5 instead of 6?
>
> Pulls down "The Undocumented PC", and

Good choice. That's an excellent book.


--
James Harris

[wolfgang kern]

On 05.03.2020 16:24, James Harris wrote:
...
>>> I think this all confirms, if nothing else, that the BIOS weekday
>>> cell is completely unreliable and should be ignored on read. An OS
>>> which wants to identify the day of the week can, instead, determine
>>> it by calculation.

>> Yes, I actually set DOW in the CMOS after calculation during boot-up.

> That makes sense. But do you correct it for any reason? I can't see any
> reason why you would read from it later.

I do it not just in case. The OS read whole RTCL when the day changed.

> Just out of curiosity do you include code to set it correctly if the
> machine is booted up in the few milliseconds across midnight...? (I.e.
> if the date changes between reading the date and when you would set the
> weekday.)

mmh? I never checked on such :)
but my code seem to block (aka delay) RTCL-update for one full second
anyway, so it got more than enough time for calculation and write-back.

> AFAICS there are three potential OS responses to the issues surrounding
> the weekday byte:
>
> 1. Correct the weekday byte on bootup (as you chose to do).
>
> 2. Never read, never write the weekday byte; ignore it completely, which
> is what some BIOSes seem to do.
>
> 3. On bootup and at midnight set the weekday byte to some /invalid/
> value so that there's less chance of some other [ lesser :-) ] OS
> booting on the same machine confusing it with something useful.

...
I respond to DOW values out of range with LOW_CMOS_Battery alarm.
__
wolfgang

[James Harris]

On 06/03/2020 04:01, wolfgang kern wrote:

...

> I respond to DOW values out of range with LOW_CMOS_Battery alarm.

I guess, because you correct DOW, you mean at boot time. Last night I
noticed CMOS cell 0xE, which I had forgotten. Could it be a more
reliable guide to CMOS battery issues?


--
James Harris

[wolfgang kern]

On 16.03.2020 10:49, James Harris wrote:

>> I respond to DOW values out of range with LOW_CMOS_Battery alarm.

> I guess, because you correct DOW, you mean at boot time. Last night I
> noticed CMOS cell 0xE, which I had forgotten. Could it be a more
> reliable guide to CMOS battery issues?

Sure, but I prefer the one less item to check on... :)
__
wolfgang