Wrong century on 64bit pc

[Dex4u]

I have about 20 test 32bit PC and they give the right century (20), when getting date.
But on the two 64bit PC i own, they give (99) when getting century

Code: Select all

mov   al,32h                         
out   70h,al
in    al,71h                          
mov   [century],al

Does anyone eles get any thing like this for date.
Note in xp the the century is right, it only in my OS.

[Brendan]

Hi,

The century in the CMOS doesn't use a standard location - it could be anywhere (locations 0x32 and 0x37 are the most common).

AFAIK the only reliable way to find out which CMOS location it is in is to use the ACPI FADT table...


Cheers,

Brendan

[Dex4u]

Thank Brendan, but as the rest of the date info is right, i assumed i had the right location, i will investigate it some more.

[Brendan]

Hi,

Thank Brendan, but as the rest of the date info is right, i assumed i had the right location, i will investigate it some more.

The rest should be right, as the other time and date values are all at standard locations (except for the "day of week" setting, which is at a standard location but often isn't set correctly).

It's only the century field that is dodgy (BIOS's probably started supporting it in 1999, and each BIOS manufacturer did it differently)...

To be honest, checking for ACPI and then finding the FADT is a pain in the neck if all you need is the century...

AFAIK DOS used to guess. For example, "if year is > 70 then century = 19, else century = 20". This would've worked for the years between 1971 and 2070, and it could've been updated with each release of the OS (for example, software released today could use "if year is > 05 then century = 20, else century = 21"). As long as someone upgrades the OS every 100 years this approach is flawless...

Also, on old motherboards you might not have a choice anyway (the hardware itself might not keep track of the century).


Cheers,

Brendan

[kernel64]

As long as someone upgrades the OS every 100 years this approach is flawless...

Ha! Imagine that... some kid in the year 3000 discovers ancient OS on unused portion of Internet abandoned in year 2010. Hacks it, boots on his 10,000-core laptop with 300TB DDR-10-gazillion RAM, runs into Y3K bug... d'oh! Accidentally generates press release announcing discovery of "Linux 2.6.16.2" released some time in March of 3005...

[GLneo]

kernel64 has a point, in a century none of our current OS will even run on future hardware, so just guess 20

p.s. AMD in 2099 releases: AMD AM4 socket (forget 64bit)14Kbit 9600+ infinit Hz (no clock, as fast as speed of light electricety though the cpu's wires)

[Kemp]

Heh, the speed you can shove electrons down a wire is already a major limiting factor for our CPUs, that's one of the reasons they keep moving to smaller processes, the larger ones are simply unable to use the higher speeds.

[GLneo]

are you saying there is a limit? i am hesitating to buy a new computer becouse 5 min later 10x faster will come out not to be more off topic but what is the limit you think?

[Kemp]

I think they once quoted a maximum theoretical speed of 3GHz given the technology we have available, and to be honest I wouldn't surprised if this is true. Just remember that raw clock speed means very little these days anyway, so even if they can't pump that up they'll still find other things to improve.

[Candamir]

Hey, that speed thing unlocked a long-since forgotten topic in my head: Quantum computation! Has anyone ever thought about a Quantum Computation OS? ;D Wouldn't be faster, but you can do more things at the same time...

[Candy]

Just a fyi, in a 3ghz processor the maximum cycle distance, not including charge/discharge times(!) is 10 cm or 4 inches. (speed of light = 2.997*10^8 m/s, 3ghz = 3.000 * 10^9 /s)

[Kemp]

Yeah, I'd imagine the problem is that those charge/discharge times (plus any other such things to keep everything running reliably) make sure that distance is reduced substantially.