- Using the special value of 0 enables this feature. In that case the vertical
frequency is used for the display updates. The update() method is called at
the "vertical retrace end" time and sets the time of the display start. This
value is used to set the vertical retrace indicator in VGA register 0x03da.
- This feature is not yet enabled if Voodoo support is present. The Voodoo device
has it's own vertical timer and needs some more testing and possibly some changes.
This parameter defines the file name for the flash BIOS config space loaded
startup if existing and saved on exit if modified. The Bochs BIOS doesn't
use this feature yet. Updated 'romimage' option documentation.
If the last char of an argument is a colon, equal sign or comma and there is
at least one more argument, then concatenate these arguments to one and pass
it to parse_line_unformatted().
- Added CMOS image options to runtime menu (except RTC init).
- Fixed default size of Bochs CMOS RAM (s.max_reg).
- Fixed bochsrc parse to make 'rtc_init' parameter work.
- In textconfig now using SERIES_ASK for CMOS image options.
- Show message box while restoring hardware state.
- Set modeless message box handle to NULL after destroying it.
- Reset all config options to default before restoring config.
- Fixed CMOS RTC value after restore if in 12-hour-mode.
- Fixed possible segfault in the plugins code caused by Voodoo plugin in VGA mode
(found at restore code testing).
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>
This improves and enhances the floppy emulation.
This adds the ability to specify a controller type.
This adds all but one, known, controller command.
This fixes the format command. Issue #123
This fixes the error with older Windows guests.
This PR adds the ability to choose which companion controller the EHCI
uses.
`#usb_ehci: enabled=1, companion=uhci`
`#usb_ehci: enabled=1, companion=ohci`
UHCI is enabled by default:
`#usb_ehci: enabled=1`
This breaks up `usb_ohci.cc/h` into `usb_ohci.cc/h` and `ohci_core.cc/h`
to be like the existing `usb_uhci.cc/h` and `uhci_core.cc/h`.
This adds the ability to define a Port Routing string in the
`HcspPortRoute` register, and is optional via the `EHCI_PORT_ROUTE`
define.
Currently `EHCI_N_CC` and `EHCI_N_PCC` must remain as currently set (3
and 2 respectively), however with a little more work, I think these can
be modified and have up to 7 companion controllers with more ports per
companion, as long as the combined total is <= 15 total ports.
Please verify the `Makefile.in` changes. I do not use GCC and can not
verify it is correct.
refactoring of port_e9_hack configuration options
do not allow port e9 access for all rings if port_e9_hack is not enabled
Co-authored-by: Stanislav Shwartsman <sshwarts@users.sourceforge.net>
This catches (possible) errors in the Bochrc file when declaring USB
port options.
The first catches when the user defines a port twice. This will PANIC.
```
usb_ohci: port1=mouse, options1="speed:low, model:m228"
usb_ohci: port1=keyboard, options1="speed:low"
```
The second catches a possible error if the user copy/pastes a line and
forgets to update the options# part as in the example below.
```
usb_ohci: port1=tablet, options1="speed:low"
usb_ohci: port2=disk, options1="speed:full, path:hdd.img"
```
However, this will not PANIC since the following is completely legal:
```
usb_ohci: port2=disk
usb_ohci: options2="speed:full"
usb_ohci: options2="path:hdd.img"
```
This will simply display an error on the Bochs console window.
This PR is for "I/O Interface to Bochs Debugger" from ring3 (port range:
**0x8A00 - 0x8A01**)
PR #64 was for E9 HACK (port **0xE9**)
By enabling the iodebug's 'all_rings' option, you can utilize the port
I/O Interface to Bochs Debugger from ring3. This PR allows the code
running inside Bochs (ring3) to monitor memory ranges, trace individual
instructions, and observe register values during execution.
https://bochs.sourceforge.io/doc/docbook/development/debugger-advanced.html
IMO very useful for:
- user-mode sandbox (ex Cuckoo)
- malware analysis
- API/SYSCALL hook/monitor from ring3
- automation + instrumentation from user mode code
...
A complement for PR #64
**This PR is 100% backward compatibility**
btw, @stlintel I'm not certain about:
- if misc is the ideal location for this.. should I create a new
iodebug-option for this?
- should I remove the #if in 'new bx_param_bool_c'?
- the new .bochsrc entry makes sense for you?
By enabling the 'all_rings' option, you can utilize the port e9 hack
from ring3
IMO very useful for:
- user-mode sandbox (ex Cuckoo)
- malware analysis
- API/SYSCALL logger with a simple hook from ring3
- automation + instrumentation from user mode code
- ...
So yes, from this PR a user-mode-sandbox can display on the console of
the system running Bochs anything that is written to 0xE9 port
**This PR is 100% backward compatibility**
btw, @stlintel I'm not certain if **bochs/config.cc** is the ideal
location to define **bool port_e9_hack_all_rings** (unmapped io/dev is
better?)
This adds over-current signaling to the USBs four host controllers.
To signal an OC, use the runtime configuration and set the checkbox (GUI) or text config's parameter to 1.
This pull request also adds USB documentation to user.dbk.
- Added check in config.h whether or not Bochs is configured and compiled for
the same target platform (WIN32 / WIN64).
- Fixed some warnings that occur in the MSVC WIN64 case.
- Added helper function get_floppy_devtype_from_type().
- The floppy type option now accepts the value "none".
- Added parameter handler for "devtype" to handle the BX_FDD_NONE case.
- Cleaned up floppy options parser code.
"none" the dependent parameters cannot be set. That's why the bochsrc parser
needs to set device type first.
- Set initial device type of first floppy to '3.5" 1.44M'.
- Detect device type along with image type if necessary.
- TODO: fixes for media types like "1_44" and some more cleanup.
- Moved serial and parallel config parameter list creation to the corresponding
device code.
- Unregister serial and parallel bochsrc options in PLUGIN_FINI mode.
- Moved USB config and runtime parameter list creation to bx_init_usb_options().
- textconfig.cc: Small fixes in the optional plugin control.
