2001-10-03 17:10:38 +04:00
|
|
|
/////////////////////////////////////////////////////////////////////////
|
2011-02-25 01:05:47 +03:00
|
|
|
// $Id$
|
2001-10-03 17:10:38 +04:00
|
|
|
/////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
// Copyright (C) 2002-2023 The Bochs Project
|
2001-04-10 05:04:59 +04:00
|
|
|
//
|
|
|
|
// This library is free software; you can redistribute it and/or
|
|
|
|
// modify it under the terms of the GNU Lesser General Public
|
|
|
|
// License as published by the Free Software Foundation; either
|
|
|
|
// version 2 of the License, or (at your option) any later version.
|
|
|
|
//
|
|
|
|
// This library is distributed in the hope that it will be useful,
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
// Lesser General Public License for more details.
|
|
|
|
//
|
|
|
|
// You should have received a copy of the GNU Lesser General Public
|
|
|
|
// License along with this library; if not, write to the Free Software
|
2009-02-08 12:05:52 +03:00
|
|
|
// Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
2009-12-04 22:50:29 +03:00
|
|
|
/////////////////////////////////////////////////////////////////////////
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
// Define BX_PLUGGABLE in files that can be compiled into plugins. For
|
2008-01-27 01:24:03 +03:00
|
|
|
// platforms that require a special tag on exported symbols, BX_PLUGGABLE
|
2002-10-25 01:07:56 +04:00
|
|
|
// is used to know when we are exporting symbols and when we are importing.
|
|
|
|
#define BX_PLUGGABLE
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2004-06-19 19:20:15 +04:00
|
|
|
#include "iodev.h"
|
2008-12-29 23:16:08 +03:00
|
|
|
#include "cmos.h"
|
2012-05-15 21:03:45 +04:00
|
|
|
#include "virt_timer.h"
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
#include "utctime.h"
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
#define LOG_THIS theCmosDevice->
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
bx_cmos_c *theCmosDevice = NULL;
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-12-07 01:36:48 +03:00
|
|
|
// CMOS register definitions from Ralf Brown's interrupt list v6.1, in a file
|
|
|
|
// called cmos.lst. In cases where there are multiple uses for a given
|
|
|
|
// register in the interrupt list, I only listed the purpose that Bochs
|
|
|
|
// actually uses it for, but I wrote "alternatives" next to it.
|
|
|
|
#define REG_SEC 0x00
|
|
|
|
#define REG_SEC_ALARM 0x01
|
|
|
|
#define REG_MIN 0x02
|
|
|
|
#define REG_MIN_ALARM 0x03
|
|
|
|
#define REG_HOUR 0x04
|
|
|
|
#define REG_HOUR_ALARM 0x05
|
|
|
|
#define REG_WEEK_DAY 0x06
|
|
|
|
#define REG_MONTH_DAY 0x07
|
|
|
|
#define REG_MONTH 0x08
|
|
|
|
#define REG_YEAR 0x09
|
|
|
|
#define REG_STAT_A 0x0a
|
|
|
|
#define REG_STAT_B 0x0b
|
|
|
|
#define REG_STAT_C 0x0c
|
|
|
|
#define REG_STAT_D 0x0d
|
|
|
|
#define REG_DIAGNOSTIC_STATUS 0x0e /* alternatives */
|
|
|
|
#define REG_SHUTDOWN_STATUS 0x0f
|
|
|
|
#define REG_EQUIPMENT_BYTE 0x14
|
|
|
|
#define REG_CSUM_HIGH 0x2e
|
|
|
|
#define REG_CSUM_LOW 0x2f
|
|
|
|
#define REG_IBM_CENTURY_BYTE 0x32 /* alternatives */
|
|
|
|
#define REG_IBM_PS2_CENTURY_BYTE 0x37 /* alternatives */
|
|
|
|
|
2005-09-11 12:46:09 +04:00
|
|
|
// Bochs CMOS map
|
2003-04-26 01:48:11 +04:00
|
|
|
//
|
|
|
|
// Idx Len Description
|
2005-09-11 12:46:09 +04:00
|
|
|
// 0x10 1 floppy drive types
|
|
|
|
// 0x11 1 configuration bits
|
|
|
|
// 0x12 1 harddisk types
|
|
|
|
// 0x13 1 advanced configuration bits
|
|
|
|
// 0x15 2 base memory in 1k
|
|
|
|
// 0x17 2 memory size above 1M in 1k
|
|
|
|
// 0x19 2 extended harddisk types
|
|
|
|
// 0x1b 9 harddisk configuration (hd0)
|
|
|
|
// 0x24 9 harddisk configuration (hd1)
|
|
|
|
// 0x2d 1 boot sequence (fd/hd)
|
|
|
|
// 0x30 2 memory size above 1M in 1k
|
|
|
|
// 0x34 2 memory size above 16M in 64k
|
|
|
|
// 0x38 1 eltorito boot sequence (#3) + bootsig check
|
|
|
|
// 0x39 2 ata translation policy (ata0...ata3)
|
|
|
|
// 0x3d 1 eltorito boot sequence (#1 + #2)
|
2003-04-26 01:48:11 +04:00
|
|
|
//
|
2008-12-25 19:58:44 +03:00
|
|
|
// Qemu CMOS map
|
|
|
|
//
|
|
|
|
// Idx Len Description
|
|
|
|
// 0x5b 3 extra memory above 4GB
|
|
|
|
// 0x5f 1 number of processors
|
2003-04-26 01:48:11 +04:00
|
|
|
|
2005-09-11 12:46:09 +04:00
|
|
|
|
2021-01-31 13:50:53 +03:00
|
|
|
Bit8u bcd_to_bin(Bit8u value, bool is_binary)
|
2005-09-11 12:46:09 +04:00
|
|
|
{
|
2005-09-12 00:03:56 +04:00
|
|
|
if (is_binary)
|
|
|
|
return value;
|
|
|
|
else
|
|
|
|
return ((value >> 4) * 10) + (value & 0x0f);
|
2005-09-11 12:46:09 +04:00
|
|
|
}
|
|
|
|
|
2021-01-31 13:50:53 +03:00
|
|
|
Bit8u bin_to_bcd(Bit8u value, bool is_binary)
|
2005-09-11 12:46:09 +04:00
|
|
|
{
|
2005-09-12 00:03:56 +04:00
|
|
|
if (is_binary)
|
|
|
|
return value;
|
|
|
|
else
|
|
|
|
return ((value / 10) << 4) | (value % 10);
|
2005-09-11 12:46:09 +04:00
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2021-01-23 15:06:11 +03:00
|
|
|
PLUGIN_ENTRY_FOR_MODULE(cmos)
|
2002-10-25 01:07:56 +04:00
|
|
|
{
|
2021-02-07 19:16:06 +03:00
|
|
|
if (mode == PLUGIN_INIT) {
|
2021-02-26 23:37:49 +03:00
|
|
|
theCmosDevice = new bx_cmos_c();
|
|
|
|
bx_devices.pluginCmosDevice = theCmosDevice;
|
|
|
|
BX_REGISTER_DEVICE_DEVMODEL(plugin, type, theCmosDevice, BX_PLUGIN_CMOS);
|
2021-02-07 19:16:06 +03:00
|
|
|
} else if (mode == PLUGIN_FINI) {
|
2021-03-07 19:01:39 +03:00
|
|
|
delete theCmosDevice;
|
2021-02-26 23:37:49 +03:00
|
|
|
} else if (mode == PLUGIN_PROBE) {
|
2021-02-07 19:16:06 +03:00
|
|
|
return (int)PLUGTYPE_CORE;
|
2006-12-06 17:27:02 +03:00
|
|
|
}
|
2021-01-23 15:06:11 +03:00
|
|
|
return 0; // Success
|
2002-10-25 01:07:56 +04:00
|
|
|
}
|
|
|
|
|
2001-04-10 05:04:59 +04:00
|
|
|
bx_cmos_c::bx_cmos_c(void)
|
|
|
|
{
|
2002-11-26 00:48:22 +03:00
|
|
|
put("CMOS");
|
2012-02-05 14:08:56 +04:00
|
|
|
memset(&s, 0, sizeof(s));
|
2002-10-25 01:07:56 +04:00
|
|
|
s.periodic_timer_index = BX_NULL_TIMER_HANDLE;
|
|
|
|
s.one_second_timer_index = BX_NULL_TIMER_HANDLE;
|
2003-01-04 03:02:07 +03:00
|
|
|
s.uip_timer_index = BX_NULL_TIMER_HANDLE;
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
|
|
|
|
2006-09-10 21:18:44 +04:00
|
|
|
bx_cmos_c::~bx_cmos_c(void)
|
|
|
|
{
|
2006-09-16 18:47:40 +04:00
|
|
|
save_image();
|
|
|
|
char *tmptime;
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
if ((tmptime = strdup(ascutc(utctime(&(BX_CMOS_THIS s.timeval))))) != NULL) {
|
2006-09-16 18:47:40 +04:00
|
|
|
tmptime[strlen(tmptime)-1]='\0';
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
BX_INFO(("Last time: " FMT_LL "d tz=utc (%s)", get_timeval(), tmptime));
|
2006-09-16 18:47:40 +04:00
|
|
|
free(tmptime);
|
|
|
|
}
|
2012-08-19 12:16:20 +04:00
|
|
|
SIM->get_bochs_root()->remove("cmos");
|
2023-12-05 20:16:24 +03:00
|
|
|
bx_list_c *misc_rt = (bx_list_c*)SIM->get_param(BXPN_MENU_RUNTIME_MISC);
|
|
|
|
misc_rt->remove("cmosimage");
|
2006-09-10 21:18:44 +04:00
|
|
|
BX_DEBUG(("Exit"));
|
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
void bx_cmos_c::init(void)
|
2001-04-10 05:04:59 +04:00
|
|
|
{
|
2002-10-06 21:49:11 +04:00
|
|
|
// CMOS RAM & RTC
|
|
|
|
|
2003-07-31 19:29:34 +04:00
|
|
|
DEV_register_ioread_handler(this, read_handler, 0x0070, "CMOS RAM", 1);
|
|
|
|
DEV_register_ioread_handler(this, read_handler, 0x0071, "CMOS RAM", 1);
|
|
|
|
DEV_register_iowrite_handler(this, write_handler, 0x0070, "CMOS RAM", 1);
|
|
|
|
DEV_register_iowrite_handler(this, write_handler, 0x0071, "CMOS RAM", 1);
|
2008-01-27 01:24:03 +03:00
|
|
|
DEV_register_irq(8, "CMOS RTC");
|
2012-05-15 21:03:45 +04:00
|
|
|
|
|
|
|
int clock_sync = SIM->get_param_enum(BXPN_CLOCK_SYNC)->get();
|
|
|
|
BX_CMOS_THIS s.rtc_sync = ((clock_sync == BX_CLOCK_SYNC_REALTIME) ||
|
|
|
|
(clock_sync == BX_CLOCK_SYNC_BOTH)) &&
|
|
|
|
SIM->get_param_bool(BXPN_CLOCK_RTC_SYNC)->get();
|
|
|
|
|
2002-10-06 23:04:47 +04:00
|
|
|
if (BX_CMOS_THIS s.periodic_timer_index == BX_NULL_TIMER_HANDLE) {
|
|
|
|
BX_CMOS_THIS s.periodic_timer_index =
|
2002-10-25 01:07:56 +04:00
|
|
|
DEV_register_timer(this, periodic_timer_handler,
|
2002-12-07 01:37:37 +03:00
|
|
|
1000000, 1,0, "cmos"); // continuous, not-active
|
2002-10-06 23:04:47 +04:00
|
|
|
}
|
|
|
|
if (BX_CMOS_THIS s.one_second_timer_index == BX_NULL_TIMER_HANDLE) {
|
2014-10-19 12:54:16 +04:00
|
|
|
BX_CMOS_THIS s.one_second_timer_index =
|
|
|
|
bx_virt_timer.register_timer(this, one_second_timer_handler,
|
|
|
|
1000000, 1, 0, BX_CMOS_THIS s.rtc_sync, "cmos"); // continuous, not-active
|
|
|
|
if (BX_CMOS_THIS s.rtc_sync) {
|
|
|
|
BX_INFO(("CMOS RTC using realtime synchronisation method"));
|
|
|
|
}
|
2002-10-06 23:04:47 +04:00
|
|
|
}
|
2003-01-04 03:02:07 +03:00
|
|
|
if (BX_CMOS_THIS s.uip_timer_index == BX_NULL_TIMER_HANDLE) {
|
|
|
|
BX_CMOS_THIS s.uip_timer_index =
|
|
|
|
DEV_register_timer(this, uip_timer_handler,
|
|
|
|
244, 0, 0, "cmos"); // one-shot, not-active
|
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
if (SIM->get_param_num(BXPN_CLOCK_TIME0)->get64() == BX_CLOCK_TIME0_LOCAL) {
|
|
|
|
time_t tmptime;
|
|
|
|
struct tm *tmptm;;
|
|
|
|
|
2005-09-10 20:40:59 +04:00
|
|
|
BX_INFO(("Using local time for initial clock"));
|
2003-09-06 03:17:51 +04:00
|
|
|
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
tmptime = time(NULL); //Calculate which timeval will display the local time
|
|
|
|
tmptm = localtime(&tmptime);
|
|
|
|
BX_CMOS_THIS s.timeval = timeutc(pushtm(tmptm));
|
2005-09-10 20:40:59 +04:00
|
|
|
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
} else if (SIM->get_param_num(BXPN_CLOCK_TIME0)->get64() == BX_CLOCK_TIME0_UTC) {
|
|
|
|
BX_INFO(("Using utc time for initial clock"));
|
|
|
|
BX_CMOS_THIS s.timeval = (Bit64s)time(NULL);
|
2005-09-10 20:40:59 +04:00
|
|
|
} else {
|
2023-12-02 09:43:56 +03:00
|
|
|
time_t tmpintime;
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
struct tm *tmptmtime;
|
2005-09-10 20:40:59 +04:00
|
|
|
BX_INFO(("Using specified time for initial clock"));
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
tmpintime = SIM->get_param_num(BXPN_CLOCK_TIME0)->get64();
|
|
|
|
tmptmtime = localtime(&tmpintime);
|
|
|
|
BX_CMOS_THIS s.timeval = timeutc(pushtm(tmptmtime));
|
2003-09-06 03:17:51 +04:00
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
// load CMOS from image file if requested.
|
2020-10-11 21:47:21 +03:00
|
|
|
BX_CMOS_THIS s.use_image = SIM->get_param_bool(BXPN_CMOSIMAGE_ENABLED)->get();
|
|
|
|
if (BX_CMOS_THIS s.use_image) {
|
2001-04-10 05:04:59 +04:00
|
|
|
int fd, ret;
|
|
|
|
struct stat stat_buf;
|
|
|
|
|
2006-02-19 18:43:03 +03:00
|
|
|
fd = open(SIM->get_param_string(BXPN_CMOSIMAGE_PATH)->getptr(), O_RDONLY
|
2001-04-10 05:04:59 +04:00
|
|
|
#ifdef O_BINARY
|
2002-10-06 21:49:11 +04:00
|
|
|
| O_BINARY
|
2001-04-10 05:04:59 +04:00
|
|
|
#endif
|
2002-10-06 21:49:11 +04:00
|
|
|
);
|
2001-04-10 05:04:59 +04:00
|
|
|
if (fd < 0) {
|
2001-05-30 22:56:02 +04:00
|
|
|
BX_PANIC(("trying to open cmos image file '%s'",
|
2006-02-19 18:43:03 +03:00
|
|
|
SIM->get_param_string(BXPN_CMOSIMAGE_PATH)->getptr()));
|
2005-09-10 20:40:59 +04:00
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
ret = fstat(fd, &stat_buf);
|
|
|
|
if (ret) {
|
2001-05-30 22:56:02 +04:00
|
|
|
BX_PANIC(("CMOS: could not fstat() image file."));
|
2005-09-10 20:40:59 +04:00
|
|
|
}
|
2018-02-24 21:04:36 +03:00
|
|
|
if ((stat_buf.st_size != 64) && (stat_buf.st_size != 128) &&
|
|
|
|
(stat_buf.st_size != 256)) {
|
|
|
|
BX_PANIC(("CMOS: image file size must be 64, 128 or 256"));
|
|
|
|
} else {
|
2018-05-21 19:11:46 +03:00
|
|
|
BX_CMOS_THIS s.max_reg = (Bit8u)(stat_buf.st_size - 1);
|
2018-02-24 21:04:36 +03:00
|
|
|
if (BX_CMOS_THIS s.max_reg == 255) {
|
|
|
|
DEV_register_ioread_handler(this, read_handler, 0x0072, "Ext CMOS RAM", 1);
|
|
|
|
DEV_register_ioread_handler(this, read_handler, 0x0073, "Ext CMOS RAM", 1);
|
|
|
|
DEV_register_iowrite_handler(this, write_handler, 0x0072, "Ext CMOS RAM", 1);
|
|
|
|
DEV_register_iowrite_handler(this, write_handler, 0x0073, "Ext CMOS RAM", 1);
|
|
|
|
}
|
2005-09-10 20:40:59 +04:00
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2005-09-12 00:03:56 +04:00
|
|
|
ret = ::read(fd, (bx_ptr_t) BX_CMOS_THIS s.reg, (unsigned)stat_buf.st_size);
|
2005-09-11 12:46:09 +04:00
|
|
|
if (ret != stat_buf.st_size) {
|
2001-05-30 22:56:02 +04:00
|
|
|
BX_PANIC(("CMOS: error reading cmos file."));
|
2005-09-10 20:40:59 +04:00
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
close(fd);
|
2019-12-09 19:29:23 +03:00
|
|
|
BX_INFO(("successfully read from image file '%s'.",
|
2006-02-19 18:43:03 +03:00
|
|
|
SIM->get_param_string(BXPN_CMOSIMAGE_PATH)->getptr()));
|
2005-09-12 00:03:56 +04:00
|
|
|
BX_CMOS_THIS s.rtc_mode_12hour = ((BX_CMOS_THIS s.reg[REG_STAT_B] & 0x02) == 0);
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary = ((BX_CMOS_THIS s.reg[REG_STAT_B] & 0x04) != 0);
|
2006-02-19 18:43:03 +03:00
|
|
|
if (SIM->get_param_bool(BXPN_CMOSIMAGE_RTC_INIT)->get()) {
|
2005-09-12 00:03:56 +04:00
|
|
|
update_timeval();
|
|
|
|
} else {
|
|
|
|
update_clock();
|
|
|
|
}
|
2005-09-10 17:22:51 +04:00
|
|
|
} else {
|
2023-12-04 22:39:24 +03:00
|
|
|
BX_CMOS_THIS s.max_reg = 127;
|
2001-04-10 05:04:59 +04:00
|
|
|
// CMOS values generated
|
2002-12-07 01:36:48 +03:00
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_A] = 0x26;
|
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_B] = 0x02;
|
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_C] = 0x00;
|
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_D] = 0x80;
|
2001-09-19 21:29:07 +04:00
|
|
|
#if BX_SUPPORT_FPU == 1
|
2002-12-07 01:36:48 +03:00
|
|
|
BX_CMOS_THIS s.reg[REG_EQUIPMENT_BYTE] |= 0x02;
|
2001-09-19 21:29:07 +04:00
|
|
|
#endif
|
2005-09-12 00:03:56 +04:00
|
|
|
BX_CMOS_THIS s.rtc_mode_12hour = 0;
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary = 0;
|
|
|
|
update_clock();
|
2005-09-10 17:22:51 +04:00
|
|
|
}
|
2005-09-12 00:03:56 +04:00
|
|
|
|
|
|
|
char *tmptime;
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
while((tmptime = strdup(ascutc(utctime(&(BX_CMOS_THIS s.timeval))))) == NULL) {
|
2005-09-12 00:03:56 +04:00
|
|
|
BX_PANIC(("Out of memory."));
|
|
|
|
}
|
|
|
|
tmptime[strlen(tmptime)-1]='\0';
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
BX_INFO(("Setting initial clock to: %s tz=utc (time0=" FMT_LL "d)", tmptime, (Bit64s)BX_CMOS_THIS s.timeval));
|
2006-03-22 21:06:16 +03:00
|
|
|
free(tmptime);
|
2005-09-12 00:03:56 +04:00
|
|
|
|
|
|
|
BX_CMOS_THIS s.timeval_change = 0;
|
2012-05-12 11:27:49 +04:00
|
|
|
|
2023-12-05 20:16:24 +03:00
|
|
|
// init runtime parameters
|
|
|
|
bx_list_c *misc_rt = (bx_list_c*)SIM->get_param(BXPN_MENU_RUNTIME_MISC);
|
|
|
|
bx_list_c *cmos_rt = new bx_list_c(misc_rt, "cmosimage", "Save CMOS RAM to image file on exit");
|
|
|
|
cmos_rt->add(SIM->get_param(BXPN_CMOSIMAGE_ENABLED));
|
|
|
|
cmos_rt->add(SIM->get_param(BXPN_CMOSIMAGE_PATH));
|
|
|
|
cmos_rt->set_options(cmos_rt->SERIES_ASK);
|
|
|
|
|
2012-05-12 11:27:49 +04:00
|
|
|
#if BX_DEBUGGER
|
|
|
|
// register device for the 'info device' command (calls debug_dump())
|
|
|
|
bx_dbg_register_debug_info("cmos", this);
|
|
|
|
#endif
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
|
|
|
|
2005-12-04 20:43:09 +03:00
|
|
|
void bx_cmos_c::reset(unsigned type)
|
2001-04-10 05:04:59 +04:00
|
|
|
{
|
2002-10-06 21:49:11 +04:00
|
|
|
BX_CMOS_THIS s.cmos_mem_address = 0;
|
2017-04-15 23:31:07 +03:00
|
|
|
BX_CMOS_THIS s.irq_enabled = 1;
|
2002-10-06 21:49:11 +04:00
|
|
|
|
|
|
|
// RESET affects the following registers:
|
|
|
|
// CRA: no effects
|
|
|
|
// CRB: bits 4,5,6 forced to 0
|
|
|
|
// CRC: bits 4,5,6,7 forced to 0
|
|
|
|
// CRD: no effects
|
2002-12-07 01:36:48 +03:00
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_B] &= 0x8f;
|
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_C] = 0;
|
2002-10-06 21:49:11 +04:00
|
|
|
|
|
|
|
// One second timer for updating clock & alarm functions
|
2014-10-19 12:54:16 +04:00
|
|
|
bx_virt_timer.activate_timer(BX_CMOS_THIS s.one_second_timer_index,
|
|
|
|
1000000, 1);
|
2002-10-06 21:49:11 +04:00
|
|
|
|
|
|
|
// handle periodic interrupt rate select
|
|
|
|
BX_CMOS_THIS CRA_change();
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
|
|
|
|
2005-12-04 20:43:09 +03:00
|
|
|
void bx_cmos_c::save_image(void)
|
|
|
|
{
|
|
|
|
int fd, ret;
|
|
|
|
|
|
|
|
// save CMOS to image file if requested.
|
2023-12-04 22:39:24 +03:00
|
|
|
if (SIM->get_param_bool(BXPN_CMOSIMAGE_ENABLED)->get()) {
|
|
|
|
fd = open(SIM->get_param_string(BXPN_CMOSIMAGE_PATH)->getptr(), O_CREAT | O_WRONLY | O_TRUNC
|
2005-12-04 20:43:09 +03:00
|
|
|
#ifdef O_BINARY
|
|
|
|
| O_BINARY
|
|
|
|
#endif
|
2023-12-04 22:39:24 +03:00
|
|
|
, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP
|
2005-12-04 20:43:09 +03:00
|
|
|
);
|
2018-02-24 21:04:36 +03:00
|
|
|
ret = ::write(fd, (bx_ptr_t) BX_CMOS_THIS s.reg, BX_CMOS_THIS s.max_reg + 1);
|
|
|
|
if (ret != (BX_CMOS_THIS s.max_reg + 1)) {
|
2005-12-04 20:43:09 +03:00
|
|
|
BX_PANIC(("CMOS: error writing cmos file."));
|
|
|
|
}
|
|
|
|
close(fd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-05-27 19:54:49 +04:00
|
|
|
void bx_cmos_c::register_state(void)
|
|
|
|
{
|
2012-02-12 22:43:20 +04:00
|
|
|
bx_list_c *list = new bx_list_c(SIM->get_bochs_root(), "cmos", "CMOS State");
|
2006-05-28 22:43:01 +04:00
|
|
|
BXRS_HEX_PARAM_FIELD(list, mem_address, BX_CMOS_THIS s.cmos_mem_address);
|
2017-04-15 23:31:07 +03:00
|
|
|
BXRS_PARAM_BOOL(list, irq_enabled, BX_CMOS_THIS s.irq_enabled);
|
2015-10-05 21:09:58 +03:00
|
|
|
new bx_shadow_data_c(list, "ram", BX_CMOS_THIS s.reg, 128, 1);
|
2006-05-27 19:54:49 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void bx_cmos_c::after_restore_state(void)
|
|
|
|
{
|
|
|
|
BX_CMOS_THIS s.rtc_mode_12hour = ((BX_CMOS_THIS s.reg[REG_STAT_B] & 0x02) == 0);
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary = ((BX_CMOS_THIS s.reg[REG_STAT_B] & 0x04) != 0);
|
|
|
|
BX_CMOS_THIS update_timeval();
|
|
|
|
BX_CMOS_THIS CRA_change();
|
|
|
|
}
|
|
|
|
|
2005-12-04 20:43:09 +03:00
|
|
|
void bx_cmos_c::CRA_change(void)
|
2001-04-10 05:04:59 +04:00
|
|
|
{
|
2005-09-10 20:40:59 +04:00
|
|
|
Bit8u nibble, dcc;
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
// Periodic Interrupt timer
|
2002-12-07 01:36:48 +03:00
|
|
|
nibble = BX_CMOS_THIS s.reg[REG_STAT_A] & 0x0f;
|
2005-09-10 20:40:59 +04:00
|
|
|
dcc = (BX_CMOS_THIS s.reg[REG_STAT_A] >> 4) & 0x07;
|
|
|
|
if ((nibble == 0) || ((dcc & 0x06) == 0)) {
|
2001-04-10 05:04:59 +04:00
|
|
|
// No Periodic Interrupt Rate when 0, deactivate timer
|
|
|
|
bx_pc_system.deactivate_timer(BX_CMOS_THIS s.periodic_timer_index);
|
|
|
|
BX_CMOS_THIS s.periodic_interval_usec = (Bit32u) -1; // max value
|
2005-09-10 20:40:59 +04:00
|
|
|
} else {
|
2001-04-10 05:04:59 +04:00
|
|
|
// values 0001b and 0010b are the same as 1000b and 1001b
|
|
|
|
if (nibble <= 2)
|
|
|
|
nibble += 7;
|
|
|
|
BX_CMOS_THIS s.periodic_interval_usec = (unsigned) (1000000.0L /
|
2005-09-10 20:40:59 +04:00
|
|
|
(32768.0L / (1 << (nibble - 1))));
|
2001-04-10 05:04:59 +04:00
|
|
|
|
|
|
|
// if Periodic Interrupt Enable bit set, activate timer
|
2005-09-10 20:40:59 +04:00
|
|
|
if (BX_CMOS_THIS s.reg[REG_STAT_B] & 0x40)
|
2001-04-10 05:04:59 +04:00
|
|
|
bx_pc_system.activate_timer(BX_CMOS_THIS s.periodic_timer_index,
|
2005-09-10 20:40:59 +04:00
|
|
|
BX_CMOS_THIS s.periodic_interval_usec, 1);
|
2001-04-10 05:04:59 +04:00
|
|
|
else
|
|
|
|
bx_pc_system.deactivate_timer(BX_CMOS_THIS s.periodic_timer_index);
|
2005-09-10 20:40:59 +04:00
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
// static IO port read callback handler
|
|
|
|
// redirects to non-static class handler to avoid virtual functions
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
Bit32u bx_cmos_c::read_handler(void *this_ptr, Bit32u address, unsigned io_len)
|
2001-04-10 05:04:59 +04:00
|
|
|
{
|
|
|
|
#if !BX_USE_CMOS_SMF
|
2002-10-06 21:49:11 +04:00
|
|
|
bx_cmos_c *class_ptr = (bx_cmos_c *) this_ptr;
|
2006-05-28 22:43:01 +04:00
|
|
|
return class_ptr->read(address, io_len);
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
Bit32u bx_cmos_c::read(Bit32u address, unsigned io_len)
|
2001-04-10 05:04:59 +04:00
|
|
|
{
|
|
|
|
#else
|
2002-10-06 21:49:11 +04:00
|
|
|
UNUSED(this_ptr);
|
2001-04-10 05:04:59 +04:00
|
|
|
#endif
|
2002-10-06 21:49:11 +04:00
|
|
|
Bit8u ret8;
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2009-04-23 22:28:17 +04:00
|
|
|
BX_DEBUG(("CMOS read of CMOS register 0x%02x", (unsigned) BX_CMOS_THIS s.cmos_mem_address));
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
switch (address) {
|
2002-11-26 00:48:22 +03:00
|
|
|
case 0x0070:
|
2018-02-24 21:04:36 +03:00
|
|
|
case 0x0072:
|
2005-09-11 12:46:09 +04:00
|
|
|
// this register is write-only on most machines
|
2018-02-24 21:04:36 +03:00
|
|
|
BX_DEBUG(("read of index port 0x%02x returning 0xff", address));
|
|
|
|
return 0xff;
|
|
|
|
|
2001-04-10 05:04:59 +04:00
|
|
|
case 0x0071:
|
|
|
|
ret8 = BX_CMOS_THIS s.reg[BX_CMOS_THIS s.cmos_mem_address];
|
|
|
|
// all bits of Register C are cleared after a read occurs.
|
2002-12-07 01:36:48 +03:00
|
|
|
if (BX_CMOS_THIS s.cmos_mem_address == REG_STAT_C) {
|
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_C] = 0x00;
|
2017-04-15 23:31:07 +03:00
|
|
|
if (BX_CMOS_THIS s.irq_enabled) {
|
|
|
|
DEV_pic_lower_irq(8);
|
|
|
|
}
|
2005-09-11 12:46:09 +04:00
|
|
|
}
|
2018-02-24 21:04:36 +03:00
|
|
|
return ret8;
|
|
|
|
|
|
|
|
case 0x0073:
|
|
|
|
return BX_CMOS_THIS s.reg[BX_CMOS_THIS s.cmos_ext_mem_addr];
|
2001-04-10 05:04:59 +04:00
|
|
|
|
|
|
|
default:
|
2006-05-28 22:43:01 +04:00
|
|
|
BX_PANIC(("unsupported cmos read, address=0x%04x!", (unsigned) address));
|
2018-02-24 21:04:36 +03:00
|
|
|
return 0;
|
2006-05-28 22:43:01 +04:00
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
// static IO port write callback handler
|
|
|
|
// redirects to non-static class handler to avoid virtual functions
|
|
|
|
void bx_cmos_c::write_handler(void *this_ptr, Bit32u address, Bit32u value, unsigned io_len)
|
2001-04-10 05:04:59 +04:00
|
|
|
{
|
|
|
|
#if !BX_USE_CMOS_SMF
|
2002-10-06 21:49:11 +04:00
|
|
|
bx_cmos_c *class_ptr = (bx_cmos_c *) this_ptr;
|
|
|
|
class_ptr->write(address, value, io_len);
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
void bx_cmos_c::write(Bit32u address, Bit32u value, unsigned io_len)
|
2001-04-10 05:04:59 +04:00
|
|
|
{
|
|
|
|
#else
|
2002-10-06 21:49:11 +04:00
|
|
|
UNUSED(this_ptr);
|
2001-04-10 05:04:59 +04:00
|
|
|
#endif // !BX_USE_CMOS_SMF
|
|
|
|
|
2005-09-10 17:22:51 +04:00
|
|
|
BX_DEBUG(("CMOS write to address: 0x%04x = 0x%02x", address, value));
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
switch (address) {
|
2001-04-10 05:04:59 +04:00
|
|
|
case 0x0070:
|
|
|
|
BX_CMOS_THIS s.cmos_mem_address = value & 0x7F;
|
|
|
|
break;
|
|
|
|
|
2018-02-24 21:04:36 +03:00
|
|
|
case 0x0072:
|
|
|
|
BX_CMOS_THIS s.cmos_ext_mem_addr = value | 0x80;
|
|
|
|
break;
|
|
|
|
|
2001-04-10 05:04:59 +04:00
|
|
|
case 0x0071:
|
2005-09-10 17:22:51 +04:00
|
|
|
switch (BX_CMOS_THIS s.cmos_mem_address) {
|
|
|
|
case REG_SEC_ALARM: // seconds alarm
|
|
|
|
case REG_MIN_ALARM: // minutes alarm
|
|
|
|
case REG_HOUR_ALARM: // hours alarm
|
|
|
|
BX_CMOS_THIS s.reg[BX_CMOS_THIS s.cmos_mem_address] = value;
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
if(BX_CMOS_THIS s.rtc_mode_12hour) {
|
|
|
|
if(BX_CMOS_THIS s.rtc_mode_binary) {
|
|
|
|
BX_DEBUG(("alarm time changed to %02u:%02u:%02u %s", BX_CMOS_THIS s.reg[REG_HOUR_ALARM] & 0x7F,
|
|
|
|
BX_CMOS_THIS s.reg[REG_MIN_ALARM], BX_CMOS_THIS s.reg[REG_SEC_ALARM],
|
|
|
|
(BX_CMOS_THIS s.reg[REG_HOUR_ALARM] & 0x80)?"pm":"am"));
|
|
|
|
} else {
|
|
|
|
BX_DEBUG(("alarm time changed to %02x:%02x:%02x %s", BX_CMOS_THIS s.reg[REG_HOUR_ALARM] & 0x7F,
|
|
|
|
BX_CMOS_THIS s.reg[REG_MIN_ALARM], BX_CMOS_THIS s.reg[REG_SEC_ALARM],
|
|
|
|
(BX_CMOS_THIS s.reg[REG_HOUR_ALARM] & 0x80)?"pm":"am"));
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if(BX_CMOS_THIS s.rtc_mode_binary) {
|
|
|
|
BX_DEBUG(("alarm time changed to %02u:%02u:%02u", BX_CMOS_THIS s.reg[REG_HOUR_ALARM],
|
|
|
|
BX_CMOS_THIS s.reg[REG_MIN_ALARM], BX_CMOS_THIS s.reg[REG_SEC_ALARM]));
|
|
|
|
} else {
|
|
|
|
BX_DEBUG(("alarm time changed to %02x:%02x:%02x", BX_CMOS_THIS s.reg[REG_HOUR_ALARM],
|
|
|
|
BX_CMOS_THIS s.reg[REG_MIN_ALARM], BX_CMOS_THIS s.reg[REG_SEC_ALARM]));
|
|
|
|
}
|
|
|
|
}
|
2005-09-10 17:22:51 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case REG_SEC: // seconds
|
|
|
|
case REG_MIN: // minutes
|
|
|
|
case REG_HOUR: // hours
|
|
|
|
case REG_WEEK_DAY: // day of the week
|
|
|
|
case REG_MONTH_DAY: // day of the month
|
|
|
|
case REG_MONTH: // month
|
|
|
|
case REG_YEAR: // year
|
|
|
|
case REG_IBM_CENTURY_BYTE: // century
|
|
|
|
case REG_IBM_PS2_CENTURY_BYTE: // century (PS/2)
|
|
|
|
BX_CMOS_THIS s.reg[BX_CMOS_THIS s.cmos_mem_address] = value;
|
|
|
|
if (BX_CMOS_THIS s.cmos_mem_address == REG_IBM_PS2_CENTURY_BYTE) {
|
|
|
|
BX_CMOS_THIS s.reg[REG_IBM_CENTURY_BYTE] = value;
|
|
|
|
}
|
|
|
|
if (BX_CMOS_THIS s.reg[REG_STAT_B] & 0x80) {
|
|
|
|
BX_CMOS_THIS s.timeval_change = 1;
|
|
|
|
} else {
|
|
|
|
update_timeval();
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case REG_STAT_A: // Control Register A
|
|
|
|
// bit 7: Update in Progress (read-only)
|
|
|
|
// 1 = signifies time registers will be updated within 244us
|
|
|
|
// 0 = time registers will not occur before 244us
|
|
|
|
// note: this bit reads 0 when CRB bit 7 is 1
|
|
|
|
// bit 6..4: Divider Chain Control
|
|
|
|
// 000 oscillator disabled
|
|
|
|
// 001 oscillator disabled
|
|
|
|
// 010 Normal operation
|
|
|
|
// 011 TEST
|
|
|
|
// 100 TEST
|
|
|
|
// 101 TEST
|
|
|
|
// 110 Divider Chain RESET
|
|
|
|
// 111 Divider Chain RESET
|
|
|
|
// bit 3..0: Periodic Interrupt Rate Select
|
|
|
|
// 0000 None
|
|
|
|
// 0001 3.90625 ms
|
|
|
|
// 0010 7.8125 ms
|
|
|
|
// 0011 122.070 us
|
|
|
|
// 0100 244.141 us
|
|
|
|
// 0101 488.281 us
|
|
|
|
// 0110 976.562 us
|
|
|
|
// 0111 1.953125 ms
|
|
|
|
// 1000 3.90625 ms
|
|
|
|
// 1001 7.8125 ms
|
|
|
|
// 1010 15.625 ms
|
|
|
|
// 1011 31.25 ms
|
|
|
|
// 1100 62.5 ms
|
|
|
|
// 1101 125 ms
|
|
|
|
// 1110 250 ms
|
|
|
|
// 1111 500 ms
|
|
|
|
|
|
|
|
unsigned dcc;
|
|
|
|
dcc = (value >> 4) & 0x07;
|
|
|
|
if ((dcc & 0x06) == 0x06) {
|
|
|
|
BX_INFO(("CRA: divider chain RESET"));
|
2005-09-10 20:40:59 +04:00
|
|
|
} else if (dcc > 0x02) {
|
2005-09-10 17:22:51 +04:00
|
|
|
BX_PANIC(("CRA: divider chain control 0x%02x", dcc));
|
|
|
|
}
|
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_A] &= 0x80;
|
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_A] |= (value & 0x7f);
|
|
|
|
BX_CMOS_THIS CRA_change();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case REG_STAT_B: // Control Register B
|
|
|
|
// bit 0: Daylight Savings Enable
|
|
|
|
// 1 = enable daylight savings
|
|
|
|
// 0 = disable daylight savings
|
|
|
|
// bit 1: 24/12 hour mode
|
|
|
|
// 1 = 24 hour format
|
|
|
|
// 0 = 12 hour format
|
|
|
|
// bit 2: Data Mode
|
|
|
|
// 1 = binary format
|
|
|
|
// 0 = BCD format
|
|
|
|
// bit 3: "square wave enable"
|
|
|
|
// Not supported and always read as 0
|
|
|
|
// bit 4: Update Ended Interrupt Enable
|
|
|
|
// 1 = enable generation of update ended interrupt
|
|
|
|
// 0 = disable
|
|
|
|
// bit 5: Alarm Interrupt Enable
|
|
|
|
// 1 = enable generation of alarm interrupt
|
|
|
|
// 0 = disable
|
|
|
|
// bit 6: Periodic Interrupt Enable
|
|
|
|
// 1 = enable generation of periodic interrupt
|
|
|
|
// 0 = disable
|
|
|
|
// bit 7: Set mode
|
|
|
|
// 1 = user copy of time is "frozen" allowing time registers
|
|
|
|
// to be accessed without regard for an occurance of an update
|
|
|
|
// 0 = time updates occur normally
|
|
|
|
|
2005-09-11 12:46:09 +04:00
|
|
|
if (value & 0x01)
|
|
|
|
BX_ERROR(("write status reg B, daylight savings unsupported"));
|
2005-09-10 17:22:51 +04:00
|
|
|
|
|
|
|
value &= 0xf7; // bit3 always 0
|
|
|
|
// Note: setting bit 7 clears bit 4
|
|
|
|
if (value & 0x80)
|
|
|
|
value &= 0xef;
|
|
|
|
|
|
|
|
unsigned prev_CRB;
|
|
|
|
prev_CRB = BX_CMOS_THIS s.reg[REG_STAT_B];
|
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_B] = value;
|
2008-02-16 01:05:43 +03:00
|
|
|
if ((prev_CRB & 0x02) != (value & 0x02)) {
|
2005-09-10 17:22:51 +04:00
|
|
|
BX_CMOS_THIS s.rtc_mode_12hour = ((value & 0x02) == 0);
|
|
|
|
update_clock();
|
|
|
|
}
|
2008-02-16 01:05:43 +03:00
|
|
|
if ((prev_CRB & 0x04) != (value & 0x04)) {
|
2005-09-12 00:03:56 +04:00
|
|
|
BX_CMOS_THIS s.rtc_mode_binary = ((value & 0x04) != 0);
|
|
|
|
update_clock();
|
|
|
|
}
|
2005-09-10 17:22:51 +04:00
|
|
|
if ((prev_CRB & 0x40) != (value & 0x40)) {
|
|
|
|
// Periodic Interrupt Enabled changed
|
|
|
|
if (prev_CRB & 0x40) {
|
|
|
|
// transition from 1 to 0, deactivate timer
|
|
|
|
bx_pc_system.deactivate_timer(BX_CMOS_THIS s.periodic_timer_index);
|
|
|
|
} else {
|
|
|
|
// transition from 0 to 1
|
|
|
|
// if rate select is not 0, activate timer
|
|
|
|
if ((BX_CMOS_THIS s.reg[REG_STAT_A] & 0x0f) != 0) {
|
|
|
|
bx_pc_system.activate_timer(
|
|
|
|
BX_CMOS_THIS s.periodic_timer_index,
|
|
|
|
BX_CMOS_THIS s.periodic_interval_usec, 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if ((prev_CRB >= 0x80) && (value < 0x80) && BX_CMOS_THIS s.timeval_change) {
|
|
|
|
update_timeval();
|
|
|
|
BX_CMOS_THIS s.timeval_change = 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case REG_STAT_C: // Control Register C
|
|
|
|
case REG_STAT_D: // Control Register D
|
|
|
|
BX_ERROR(("write to control register 0x%02x ignored (read-only)",
|
|
|
|
BX_CMOS_THIS s.cmos_mem_address));
|
|
|
|
break;
|
|
|
|
|
|
|
|
case REG_DIAGNOSTIC_STATUS:
|
|
|
|
BX_DEBUG(("write register 0x0e: 0x%02x", value));
|
|
|
|
BX_CMOS_THIS s.reg[REG_DIAGNOSTIC_STATUS] = value;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case REG_SHUTDOWN_STATUS:
|
|
|
|
switch (value) {
|
|
|
|
case 0x00: /* proceed with normal POST (soft reset) */
|
|
|
|
BX_DEBUG(("Reg 0Fh(00): shutdown action = normal POST"));
|
|
|
|
break;
|
|
|
|
case 0x01: /* shutdown after memory size check */
|
|
|
|
BX_DEBUG(("Reg 0Fh(01): request to change shutdown action"
|
2002-10-06 21:49:11 +04:00
|
|
|
" to shutdown after memory size check"));
|
2005-09-10 17:22:51 +04:00
|
|
|
break;
|
|
|
|
case 0x02: /* shutdown after successful memory test */
|
|
|
|
BX_DEBUG(("Reg 0Fh(02): request to change shutdown action"
|
2002-10-06 21:49:11 +04:00
|
|
|
" to shutdown after successful memory test"));
|
2005-09-10 17:22:51 +04:00
|
|
|
break;
|
|
|
|
case 0x03: /* shutdown after failed memory test */
|
|
|
|
BX_DEBUG(("Reg 0Fh(03): request to change shutdown action"
|
2002-10-06 21:49:11 +04:00
|
|
|
" to shutdown after successful memory test"));
|
2005-09-10 17:22:51 +04:00
|
|
|
break;
|
|
|
|
case 0x04: /* jump to disk bootstrap routine */
|
|
|
|
BX_DEBUG(("Reg 0Fh(04): request to change shutdown action "
|
2002-10-06 21:49:11 +04:00
|
|
|
"to jump to disk bootstrap routine."));
|
2005-09-10 17:22:51 +04:00
|
|
|
break;
|
|
|
|
case 0x05: /* flush keyboard (issue EOI) and jump via 40h:0067h */
|
|
|
|
BX_DEBUG(("Reg 0Fh(05): request to change shutdown action "
|
2002-10-06 21:49:11 +04:00
|
|
|
"to flush keyboard (issue EOI) and jump via 40h:0067h."));
|
2005-09-10 17:22:51 +04:00
|
|
|
break;
|
|
|
|
case 0x06:
|
|
|
|
BX_DEBUG(("Reg 0Fh(06): Shutdown after memory test !"));
|
|
|
|
break;
|
|
|
|
case 0x07: /* reset (after failed test in virtual mode) */
|
|
|
|
BX_DEBUG(("Reg 0Fh(07): request to change shutdown action "
|
2002-10-06 21:49:11 +04:00
|
|
|
"to reset (after failed test in virtual mode)."));
|
2005-09-10 17:22:51 +04:00
|
|
|
break;
|
|
|
|
case 0x08: /* used by POST during protected-mode RAM test (return to POST) */
|
|
|
|
BX_DEBUG(("Reg 0Fh(08): request to change shutdown action "
|
2002-10-06 21:49:11 +04:00
|
|
|
"to return to POST (used by POST during protected-mode RAM test)."));
|
2005-09-10 17:22:51 +04:00
|
|
|
break;
|
|
|
|
case 0x09: /* return to BIOS extended memory block move
|
2002-10-06 21:49:11 +04:00
|
|
|
(interrupt 15h, func 87h was in progress) */
|
2005-09-10 17:22:51 +04:00
|
|
|
BX_DEBUG(("Reg 0Fh(09): request to change shutdown action "
|
2002-10-06 21:49:11 +04:00
|
|
|
"to return to BIOS extended memory block move."));
|
2005-09-10 17:22:51 +04:00
|
|
|
break;
|
|
|
|
case 0x0a: /* jump to DWORD pointer at 40:67 */
|
|
|
|
BX_DEBUG(("Reg 0Fh(0a): request to change shutdown action"
|
2002-10-06 21:49:11 +04:00
|
|
|
" to jump to DWORD at 40:67"));
|
2005-09-10 17:22:51 +04:00
|
|
|
break;
|
|
|
|
case 0x0b: /* iret to DWORD pointer at 40:67 */
|
|
|
|
BX_DEBUG(("Reg 0Fh(0b): request to change shutdown action"
|
2002-10-06 21:49:11 +04:00
|
|
|
" to iret to DWORD at 40:67"));
|
2005-09-10 17:22:51 +04:00
|
|
|
break;
|
|
|
|
case 0x0c: /* retf to DWORD pointer at 40:67 */
|
|
|
|
BX_DEBUG(("Reg 0Fh(0c): request to change shutdown action"
|
2002-10-06 21:49:11 +04:00
|
|
|
" to retf to DWORD at 40:67"));
|
2005-09-10 17:22:51 +04:00
|
|
|
break;
|
|
|
|
default:
|
2020-10-11 21:47:21 +03:00
|
|
|
if (!BX_CMOS_THIS s.use_image) {
|
|
|
|
BX_ERROR(("unsupported shutdown status: 0x%02x!", value));
|
|
|
|
} else {
|
|
|
|
BX_DEBUG(("shutdown status register set to 0x%02x", value));
|
|
|
|
}
|
2005-09-10 17:22:51 +04:00
|
|
|
}
|
|
|
|
BX_CMOS_THIS s.reg[REG_SHUTDOWN_STATUS] = value;
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
BX_DEBUG(("write reg 0x%02x: value = 0x%02x",
|
|
|
|
BX_CMOS_THIS s.cmos_mem_address, value));
|
|
|
|
BX_CMOS_THIS s.reg[BX_CMOS_THIS s.cmos_mem_address] = value;
|
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
break;
|
2018-02-24 21:04:36 +03:00
|
|
|
|
|
|
|
case 0x0073:
|
|
|
|
BX_CMOS_THIS s.reg[BX_CMOS_THIS s.cmos_ext_mem_addr] = value;
|
|
|
|
break;
|
2005-09-10 17:22:51 +04:00
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
void bx_cmos_c::checksum_cmos(void)
|
2001-04-10 05:04:59 +04:00
|
|
|
{
|
2006-05-28 22:43:01 +04:00
|
|
|
Bit16u sum = 0;
|
|
|
|
for (unsigned i=0x10; i<=0x2d; i++)
|
2001-04-10 05:04:59 +04:00
|
|
|
sum += BX_CMOS_THIS s.reg[i];
|
2002-12-07 01:36:48 +03:00
|
|
|
BX_CMOS_THIS s.reg[REG_CSUM_HIGH] = (sum >> 8) & 0xff; /* checksum high */
|
|
|
|
BX_CMOS_THIS s.reg[REG_CSUM_LOW] = (sum & 0xff); /* checksum low */
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
void bx_cmos_c::periodic_timer_handler(void *this_ptr)
|
2001-04-10 05:04:59 +04:00
|
|
|
{
|
2002-01-26 13:00:08 +03:00
|
|
|
bx_cmos_c *class_ptr = (bx_cmos_c *) this_ptr;
|
|
|
|
class_ptr->periodic_timer();
|
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
void bx_cmos_c::periodic_timer()
|
2002-01-26 13:00:08 +03:00
|
|
|
{
|
|
|
|
// if periodic interrupts are enabled, trip IRQ 8, and
|
|
|
|
// update status register C
|
2002-12-07 01:36:48 +03:00
|
|
|
if (BX_CMOS_THIS s.reg[REG_STAT_B] & 0x40) {
|
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_C] |= 0xc0; // Interrupt Request, Periodic Int
|
2017-04-15 23:31:07 +03:00
|
|
|
if (BX_CMOS_THIS s.irq_enabled) {
|
|
|
|
DEV_pic_raise_irq(8);
|
|
|
|
}
|
2006-05-28 22:43:01 +04:00
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
void bx_cmos_c::one_second_timer_handler(void *this_ptr)
|
2001-04-10 05:04:59 +04:00
|
|
|
{
|
2002-01-26 13:00:08 +03:00
|
|
|
bx_cmos_c *class_ptr = (bx_cmos_c *) this_ptr;
|
|
|
|
class_ptr->one_second_timer();
|
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
void bx_cmos_c::one_second_timer()
|
2002-01-26 13:00:08 +03:00
|
|
|
{
|
2003-12-27 16:43:41 +03:00
|
|
|
// divider chain reset - RTC stopped
|
|
|
|
if ((BX_CMOS_THIS s.reg[REG_STAT_A] & 0x60) == 0x60)
|
|
|
|
return;
|
|
|
|
|
2002-01-26 13:00:08 +03:00
|
|
|
// update internal time/date buffer
|
|
|
|
BX_CMOS_THIS s.timeval++;
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-01-26 13:00:08 +03:00
|
|
|
// Dont update CMOS user copy of time/date if CRB bit7 is 1
|
|
|
|
// Nothing else do to
|
2002-12-07 01:36:48 +03:00
|
|
|
if (BX_CMOS_THIS s.reg[REG_STAT_B] & 0x80)
|
2001-04-10 05:04:59 +04:00
|
|
|
return;
|
|
|
|
|
2003-01-04 03:02:07 +03:00
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_A] |= 0x80; // set UIP bit
|
|
|
|
|
|
|
|
// UIP timer for updating clock & alarm functions
|
2006-05-28 22:43:01 +04:00
|
|
|
bx_pc_system.activate_timer(BX_CMOS_THIS s.uip_timer_index, 244, 0);
|
2003-01-04 03:02:07 +03:00
|
|
|
}
|
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
void bx_cmos_c::uip_timer_handler(void *this_ptr)
|
2003-01-04 03:02:07 +03:00
|
|
|
{
|
|
|
|
bx_cmos_c *class_ptr = (bx_cmos_c *) this_ptr;
|
|
|
|
class_ptr->uip_timer();
|
|
|
|
}
|
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
void bx_cmos_c::uip_timer()
|
2003-01-04 03:02:07 +03:00
|
|
|
{
|
2002-01-26 13:00:08 +03:00
|
|
|
update_clock();
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-01-26 13:00:08 +03:00
|
|
|
// if update interrupts are enabled, trip IRQ 8, and
|
|
|
|
// update status register C
|
2002-12-07 01:36:48 +03:00
|
|
|
if (BX_CMOS_THIS s.reg[REG_STAT_B] & 0x10) {
|
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_C] |= 0x90; // Interrupt Request, Update Ended
|
2017-04-15 23:31:07 +03:00
|
|
|
if (BX_CMOS_THIS s.irq_enabled) {
|
|
|
|
DEV_pic_raise_irq(8);
|
|
|
|
}
|
2006-05-28 22:43:01 +04:00
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-01-26 13:00:08 +03:00
|
|
|
// compare CMOS user copy of time/date to alarm time/date here
|
2002-12-07 01:36:48 +03:00
|
|
|
if (BX_CMOS_THIS s.reg[REG_STAT_B] & 0x20) {
|
2001-04-10 05:04:59 +04:00
|
|
|
// Alarm interrupts enabled
|
2021-01-31 13:50:53 +03:00
|
|
|
bool alarm_match = 1;
|
2006-05-28 22:43:01 +04:00
|
|
|
if ((BX_CMOS_THIS s.reg[REG_SEC_ALARM] & 0xc0) != 0xc0) {
|
2001-04-10 05:04:59 +04:00
|
|
|
// seconds alarm not in dont care mode
|
2002-12-07 01:36:48 +03:00
|
|
|
if (BX_CMOS_THIS s.reg[REG_SEC] != BX_CMOS_THIS s.reg[REG_SEC_ALARM])
|
2006-05-28 22:43:01 +04:00
|
|
|
alarm_match = 0;
|
|
|
|
}
|
|
|
|
if ((BX_CMOS_THIS s.reg[REG_MIN_ALARM] & 0xc0) != 0xc0) {
|
2001-04-10 05:04:59 +04:00
|
|
|
// minutes alarm not in dont care mode
|
2002-12-07 01:36:48 +03:00
|
|
|
if (BX_CMOS_THIS s.reg[REG_MIN] != BX_CMOS_THIS s.reg[REG_MIN_ALARM])
|
2006-05-28 22:43:01 +04:00
|
|
|
alarm_match = 0;
|
|
|
|
}
|
|
|
|
if ((BX_CMOS_THIS s.reg[REG_HOUR_ALARM] & 0xc0) != 0xc0) {
|
2001-04-10 05:04:59 +04:00
|
|
|
// hours alarm not in dont care mode
|
2002-12-07 01:36:48 +03:00
|
|
|
if (BX_CMOS_THIS s.reg[REG_HOUR] != BX_CMOS_THIS s.reg[REG_HOUR_ALARM])
|
2006-05-28 22:43:01 +04:00
|
|
|
alarm_match = 0;
|
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
if (alarm_match) {
|
2002-12-07 01:36:48 +03:00
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_C] |= 0xa0; // Interrupt Request, Alarm Int
|
2017-04-15 23:31:07 +03:00
|
|
|
if (BX_CMOS_THIS s.irq_enabled) {
|
|
|
|
DEV_pic_raise_irq(8);
|
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
2006-05-28 22:43:01 +04:00
|
|
|
}
|
2003-01-04 03:02:07 +03:00
|
|
|
BX_CMOS_THIS s.reg[REG_STAT_A] &= 0x7f; // clear UIP bit
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
void bx_cmos_c::update_clock()
|
2001-04-10 05:04:59 +04:00
|
|
|
{
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
struct utctm *time_calendar;
|
2002-10-06 21:49:11 +04:00
|
|
|
unsigned year, month, day, century;
|
2005-09-10 17:22:51 +04:00
|
|
|
Bit8u val_bcd, hour;
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
Bit64s mintvalset=-62167219200,maxtvalset[2]={253402300799, 745690751999};
|
2001-04-10 05:04:59 +04:00
|
|
|
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
while(BX_CMOS_THIS s.timeval>maxtvalset[BX_CMOS_THIS s.rtc_mode_binary?1:0]) {BX_CMOS_THIS s.timeval-=(maxtvalset[BX_CMOS_THIS s.rtc_mode_binary?1:0]-mintvalset+1);}
|
|
|
|
while(BX_CMOS_THIS s.timeval<mintvalset) {BX_CMOS_THIS s.timeval+=(maxtvalset[BX_CMOS_THIS s.rtc_mode_binary?1:0]-mintvalset+1);}
|
|
|
|
time_calendar = utctime(& BX_CMOS_THIS s.timeval);
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
// update seconds
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
BX_CMOS_THIS s.reg[REG_SEC] = bin_to_bcd(time_calendar->tm_sec, BX_CMOS_THIS s.rtc_mode_binary);
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
// update minutes
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
BX_CMOS_THIS s.reg[REG_MIN] = bin_to_bcd(time_calendar->tm_min, BX_CMOS_THIS s.rtc_mode_binary);
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
// update hours
|
2005-09-10 17:22:51 +04:00
|
|
|
if (BX_CMOS_THIS s.rtc_mode_12hour) {
|
|
|
|
hour = time_calendar->tm_hour;
|
|
|
|
val_bcd = (hour > 11) ? 0x80 : 0x00;
|
|
|
|
if (hour > 11) hour -= 12;
|
|
|
|
if (hour == 0) hour = 12;
|
2005-09-12 00:03:56 +04:00
|
|
|
val_bcd |= bin_to_bcd(hour, BX_CMOS_THIS s.rtc_mode_binary);
|
2005-09-11 12:46:09 +04:00
|
|
|
BX_CMOS_THIS s.reg[REG_HOUR] = val_bcd;
|
2005-09-10 17:22:51 +04:00
|
|
|
} else {
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
BX_CMOS_THIS s.reg[REG_HOUR] = bin_to_bcd(time_calendar->tm_hour, BX_CMOS_THIS s.rtc_mode_binary);
|
2005-09-10 17:22:51 +04:00
|
|
|
}
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
// update day of the week
|
|
|
|
day = time_calendar->tm_wday + 1; // 0..6 to 1..7
|
2005-09-12 00:03:56 +04:00
|
|
|
BX_CMOS_THIS s.reg[REG_WEEK_DAY] = bin_to_bcd(day,
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary);
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
// update day of the month
|
|
|
|
day = time_calendar->tm_mday;
|
2005-09-12 00:03:56 +04:00
|
|
|
BX_CMOS_THIS s.reg[REG_MONTH_DAY] = bin_to_bcd(day,
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary);
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
// update month
|
|
|
|
month = time_calendar->tm_mon + 1;
|
2005-09-12 00:03:56 +04:00
|
|
|
BX_CMOS_THIS s.reg[REG_MONTH] = bin_to_bcd(month,
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary);
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
// update year
|
|
|
|
year = time_calendar->tm_year % 100;
|
2005-09-12 00:03:56 +04:00
|
|
|
BX_CMOS_THIS s.reg[REG_YEAR] = bin_to_bcd(year,
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary);
|
2001-04-10 05:04:59 +04:00
|
|
|
|
2002-10-06 21:49:11 +04:00
|
|
|
// update century
|
|
|
|
century = (time_calendar->tm_year / 100) + 19;
|
2005-09-12 00:03:56 +04:00
|
|
|
BX_CMOS_THIS s.reg[REG_IBM_CENTURY_BYTE] = bin_to_bcd(century,
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary);
|
2002-12-07 01:22:32 +03:00
|
|
|
|
2008-01-27 01:24:03 +03:00
|
|
|
// Raul Hudea pointed out that some bioses also use reg 0x37 for the
|
2002-12-07 01:36:48 +03:00
|
|
|
// century byte. Tony Heller says this is critical in getting WinXP to run.
|
2008-01-27 01:24:03 +03:00
|
|
|
BX_CMOS_THIS s.reg[REG_IBM_PS2_CENTURY_BYTE] =
|
2002-12-07 01:36:48 +03:00
|
|
|
BX_CMOS_THIS s.reg[REG_IBM_CENTURY_BYTE];
|
2001-04-10 05:04:59 +04:00
|
|
|
}
|
2002-12-07 18:53:02 +03:00
|
|
|
|
2006-05-28 22:43:01 +04:00
|
|
|
void bx_cmos_c::update_timeval()
|
2002-12-07 18:53:02 +03:00
|
|
|
{
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
struct utctm time_calendar;
|
|
|
|
Bit16s val_yr;
|
2005-09-10 17:22:51 +04:00
|
|
|
Bit8u val_bin, pm_flag;
|
2003-01-04 03:02:07 +03:00
|
|
|
|
|
|
|
// update seconds
|
2005-09-12 00:03:56 +04:00
|
|
|
time_calendar.tm_sec = bcd_to_bin(BX_CMOS_THIS s.reg[REG_SEC],
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary);
|
2003-01-04 03:02:07 +03:00
|
|
|
|
|
|
|
// update minutes
|
2005-09-12 00:03:56 +04:00
|
|
|
time_calendar.tm_min = bcd_to_bin(BX_CMOS_THIS s.reg[REG_MIN],
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary);
|
2003-01-04 03:02:07 +03:00
|
|
|
|
|
|
|
// update hours
|
2005-09-10 17:22:51 +04:00
|
|
|
if (BX_CMOS_THIS s.rtc_mode_12hour) {
|
|
|
|
pm_flag = BX_CMOS_THIS s.reg[REG_HOUR] & 0x80;
|
2023-12-03 14:34:03 +03:00
|
|
|
val_bin = bcd_to_bin(BX_CMOS_THIS s.reg[REG_HOUR] & 0x7f,
|
2005-09-12 00:03:56 +04:00
|
|
|
BX_CMOS_THIS s.rtc_mode_binary);
|
2005-09-10 17:22:51 +04:00
|
|
|
if ((val_bin < 12) & (pm_flag > 0)) {
|
|
|
|
val_bin += 12;
|
|
|
|
} else if ((val_bin == 12) & (pm_flag == 0)) {
|
|
|
|
val_bin = 0;
|
|
|
|
}
|
2005-09-11 12:46:09 +04:00
|
|
|
time_calendar.tm_hour = val_bin;
|
2005-09-10 17:22:51 +04:00
|
|
|
} else {
|
2005-09-12 00:03:56 +04:00
|
|
|
time_calendar.tm_hour = bcd_to_bin(BX_CMOS_THIS s.reg[REG_HOUR],
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary);
|
2005-09-10 17:22:51 +04:00
|
|
|
}
|
2003-01-04 03:02:07 +03:00
|
|
|
|
|
|
|
// update day of the month
|
2005-09-12 00:03:56 +04:00
|
|
|
time_calendar.tm_mday = bcd_to_bin(BX_CMOS_THIS s.reg[REG_MONTH_DAY],
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary);
|
2003-01-04 03:02:07 +03:00
|
|
|
|
|
|
|
// update month
|
2005-09-12 00:03:56 +04:00
|
|
|
time_calendar.tm_mon = bcd_to_bin(BX_CMOS_THIS s.reg[REG_MONTH],
|
|
|
|
BX_CMOS_THIS s.rtc_mode_binary) - 1;
|
2003-01-04 03:02:07 +03:00
|
|
|
|
|
|
|
// update year
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
val_yr = bcd_to_bin(BX_CMOS_THIS s.reg[REG_IBM_CENTURY_BYTE],
|
2005-09-12 00:03:56 +04:00
|
|
|
BX_CMOS_THIS s.rtc_mode_binary);
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
val_yr = (val_yr - 19) * 100;
|
|
|
|
val_yr += bcd_to_bin(BX_CMOS_THIS s.reg[REG_YEAR],
|
2005-09-12 00:03:56 +04:00
|
|
|
BX_CMOS_THIS s.rtc_mode_binary);
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
time_calendar.tm_year = val_yr;
|
2003-01-04 03:02:07 +03:00
|
|
|
|
Porting #SF patch #565 Real Time Clock /CMOS fix (#4)
by Michele Giacomone
Detailed description:
-Observed issues
Due to some limitations only dates between 1980 and 2038 can be
used in a reliable way.
Also, bochs incorrectly assumes a linear correspondence between
the data returned by the <time.h> functions localtime() and
mktime(), and isn't setting the latter properly.
Bochs keeps its internal time value dependent to these functions
after setup, assuming that their internal settings won't change
on the go - which is not the case.
In my OS, and in my timezone, this leads to incorrect startup values
for 5 months each year and unreliable values if the simulation is
kept going for a long time. (a feedback between localtime() and
mktime() is created which keeps shifting back the time)
Also, the RTC simulation is not realistic since the clock fixes
itself across DST changes, without updating any DST related flag,
a behavior that no guest OS expects.
-Proposed fix
This is implemented in such way that no bochs' previous behavior
is changed, a part from the broken ones, with legacy in mind
== the user can keep using bochs exactly as before knowing nothing
of this patch
+Make the internal s.timeval variable a Bit64s, so it can fit all
values that the cmos can correctly represent, reported below:
MIN setting -62167219200 => 0000/01/01 SAT 0:00:00
MAX BCD setting 253402300799 => 9999/12/31 FRI 23:59:59
MAX BIN setting 745690751999 => 25599/12/31 FRI 23:59:59
And then fix each reference to these so it can handle such values
And make bochs correctly wrap around for under/overflows, so that
only the most significant bits of the century are lost.
+Do the same thing to the bochs time0 parameter, so all the above
values can be chosen at startup (despite being now legal values,
1 and 2 will still be treated as "local" and "utc"). Note that
normally only BCD settings are valid since bochs' CMOS defaults
to such operating mode - the only way to use the binary range
is by loading a cmos memory map.
+Make the internal s.timeval variable independent from external
factors. This means providing a small set of time handling
functions, contained in "iodev/utctime.h", which must work in
any environment in which bochs compiles, accessing no external
resource. This also means that after startup, s.timeval will only
be changed internally, and no call to the OS time functions will
be made.
+Make the internal s.timeval variable timezone independent, to
have a linear correlation between its values and valid CMOS
settings. To make it easier, s.timeval is gonna be treated as
if the current timezone was UTC: so,
- if the user selects UTC as time0, s.timeval will become current
time(NULL)
- if the user selects localtime, s.timeval will be computed as
the value which will display the same broken down time as
localtime(&now)
- if the user inputs a time formatted string the proper s.timeval
to displayed will be easily calculated,
- if the user inputs a starting time value, s.timeval will be
computed as the value which will display the same broken down
time as localtime(&user_input) to ensure the same operation as
before.
A "tz=utc" is displayed when bochs prints out the current time
value, to warn users about the difference in meaning between the
internally kept time value and the value they can set through
the "time0=" parameter. This might be changed to communicate
instead the time value they can input to get the same setting,
but performing such calculation (except for the startup time)
suffers from all the mktime()/localtime() problems listed above
so I did not do it.
The range of "time0" is automatically adjusted so all users in
all time zones can set any legal value despite "time0=" having a
local meaning.
A thorough explanation of what I did and why can be found in the
"iodev/utctime.h" library header.
---------
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
2023-12-02 00:55:35 +03:00
|
|
|
BX_CMOS_THIS s.timeval = timeutc(& time_calendar);
|
2002-12-07 18:53:02 +03:00
|
|
|
}
|
2012-05-12 11:27:49 +04:00
|
|
|
|
|
|
|
#if BX_DEBUGGER
|
|
|
|
void bx_cmos_c::debug_dump(int argc, char **argv)
|
|
|
|
{
|
|
|
|
int i, j, r;
|
|
|
|
|
|
|
|
dbg_printf("CMOS RTC\n\n");
|
|
|
|
dbg_printf("Index register: 0x%02x\n\n", BX_CMOS_THIS s.cmos_mem_address);
|
|
|
|
r = 0;
|
|
|
|
for (i=0; i<8; i++) {
|
|
|
|
dbg_printf("%04x ", r);
|
|
|
|
for (j=0; j<16; j++) {
|
|
|
|
dbg_printf(" %02x", BX_CMOS_THIS s.reg[r++]);
|
|
|
|
}
|
|
|
|
dbg_printf("\n");
|
|
|
|
}
|
|
|
|
if (argc > 0) {
|
|
|
|
dbg_printf("\nAdditional options not supported\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|