I use setjmp() to save the context just before calling
bx_continue_after_config_interface(). Then, in
bx_real_sim_c:quit_sim, I use longjmp() to jump back to that context.
This happens in main.cc and in gui/wxmain.cc (wxWindows only).
I haven't tested with the debugger yet. Possibly with debugger
the quit longjmp() should jump back to the debugger prompt loop
instead of actually quitting the program.
- clean up BX_ASYNC_EVT_LOG_MSG implementation by creating a different,
synchronous event called BX_SYNC_EVT_LOG_ASK. The async event
could be used to simply tell the CI that an event has occurred,
for example if the user wanted to view the events on screen
(not implemented). The sync event is used when you want the user
to respond before the simulation can continue, such as a for the
"panic=ask" behavior.
- in wxmain.cc, move the updates to the Start,Stop,Pause,Resume menu
items into a separate method simStatusChanged(). This makes the code that
does important stuff more readable.
- remove wxMutexGuiEnter()/Leave() from MyFrame::OnSim2CuiEvent().
This method is an event handler called in the gui thread, so it
already has the gui lock. This call caused thread lock on my linux
box.
bx_do_text_config_interface() to make it clear that it's not used
with wxWindows. Before, it was around only the line of that function that
failed to compile.
the terminology a bit. In particular, the term "gui" has started
to mean different things in different contexts, so I've defined
some more specific names for the parts of the user interface, and
updated comments and some variable names to reflect it. See
siminterface.h for a more complete description of all of these.
VGAW: VGA display window and toolbar buttons, the traditional Bochs
display which is ported to X, win32, MacOS X, etc. Implemented
in gui/gui.* and platform dependent gui/*.cc files.
CI: configuration interface that lets the user change settings such
as floppy disk image, ne2k settings, log options. The CI consists
of two parts: configuration user interface (CUI) which does the
actual rendering to the screen and handles key/mouse/menu events,
and the siminterface object.
CUI: configuration user interface. This handles the user interactions
that allow the user to configure Bochs. To actually change any
values it talks to the siminterface object. One implementation of
the CUI is the text-mode menus in gui/control.cc. Another
implementation is (will be) the wxWindows menus and dialogs in
gui/wxmain.cc.
siminterface: the glue between the CUI and the simulation code,
accessible throughout the code by the global variable
bx_simulator_interface_c *SIM;
Among other things, siminterface methods allow the simulator to ask the
CUI to display things or ask for user input, and allows the CUI
to query and modify variables in the simulation code.
GUI: Literally, "graphical user interface". Until the configuration menus
and wxWindows came along, everyone understood that "gui" referred to the
VGA display window and the toolbar buttons because that's all there
was. Now that we have the wxWindows code, which implements both the VGAW
and the CUI, while all other platforms implement only the VGAW, it's not
so clear. So, I'm trying to use VGAW, CI, and CUI consistently since
they are more specific.
control panel: This has been used as another name for the configuration
interface. "control panel" is also somewhat unspecific and it sounds
like it would be graphical with buttons and sliders, but our text-mode
thing is not graphical at all. I've replaced "control panel" with
"configuration interface" wherever I could find it. In configure script,
the --disable-control-panel option is still supported, but it politely
suggests that you use --disable-config-interface instead.
- clean up comments in siminterface,wx* code
- add comments and examples for bx_param_* and BxEvents
- remove some obsolete stuff: notify_*_args,
bx_simulator_interface_c::[sg]et_enabled() methods
- in siminterface.cc, move a few bx_real_sim_c methods to where they belong,
with the rest of the methods. No changes to the actual methods.
- remove some DOS ^M's which crept in and confused my editor.
mirrored the use of enable_control_panel exactly. This should not cause
any change in behavior, and it lets me eliminate these methods which
don't make much sense anymore.
- loading default bochsrc for the wx gui no longer necessary
- the wx gui version of bochs now accepts the same command line arguments as
the other guis
to "*_ENABLED"
- bx_serial_options for all 4 ports moved into an array com[4]
- serial port com1 is enabled by default
- detection of com2, com3 and com4 config options disabled for now
- new parameter "enabled" added to the serial bochsrc options
- error handling for serial and parallel bochsrc options changed. The unhandled
BX_PANICs are replaced by BX_ERRORs.
- new function bx_write_serial_options() added
- serial destructor restores original terminal settings only when serial port
is enabled and the tty_id is valid
parport1 with the new option "enabled". The old option "enable" only
controlled the output. The parport1 is enabled with no output by default.
Changes:
* bochrc option "enable" replaced by "enabled"
* parport option "Oenable" replaced by "Opresent"
* bx_parport_options par1 and par2 replaced by an array par[2]
* initialize parport1 resources only when enabled
* renamed variable "parport_init_list" to "par_ser_init_list" since it
contains parport and serial options
* documentation and bochsrc updates
- the parport variables "output" and "initmode" now belong to the bx_par_t
structure
- TODO: add parport2 (disabled by default), parport detection in the bios
installation dependent values in a global configuration file. If you are
including such a file, you only need to define the disk images and other
guest OS dependent stuff.
- new command line option '-q' (quickstart) added (the same as '-nocp')
- new command line option '-qf' (quickstart + config file) added (the same as
'-nocp -f')
- missing initialization of Ouser_shortcut in bx_options added
the guest OS. The shortcut can be defined in the bochsrc or in the config
interface. It is possible to change it at runtime.
These shortcuts are currently recognized:
ctrlaltdel, ctrlaltesc, ctrlaltf1, alttab
Here is the list of changes:
* userbutton.h and userbutton.xpm added in gui/bitmaps
* config options for the userbutton shortcut added
* initialize the new button in the gui.cc
* the new userbutton handler generates keypresses and relaeses depending on
the shortcut keyword
* the gui stops adding buttons to the headerbar if not enough space is left.
This can happen when the screen width is 320 pixels (done for X11 only).
* TODO: build a dialog box for the wxWindows gui
more work in the floppy and bios code.
- floppy and cdrom entries in the runtime config menu can be disabled if the
drive wasn't defined in bochsrc or start menu
- floppy variable "initial_status" and cdrom variable "inserted" renamed to
"status"
- unused variable *ips in function build_runtime_options_prompt() disabled
* new floppy type 360k can be used in .bochsrc and the config interface
* media type and geometry can be set for the floppy type
* BIOS changes to make 360k floppy drives work
* bximage can create 360k images now
'-nocp' option
- reverted latest changes in function bx_do_text_config_interface()
- removed unnecessary forward declaration of function bx_print_header()
- replace the loglevel ACT_ASK by ACT_FATAL only when compiled without control
panel
- detection of the config file fixed - fopen returns NULL if the function fails
to describe the format of the log prefix. This option can be any string
with special tokens being replaced at run time :
# %t : 11 decimal digits timer tick
# %i : 8 hexadecimal digits of cpu0 current eip
# %e : 1 character event type ('i'nfo, 'd'ebug, 'p'anic, 'e'rror)
# %d : 5 characters string of the device, between brackets
the default is "%t%i%d", so the logprefix is the same as before.
New tokens can be easily added or changed if needed.
Modified Files:
.bochsrc bochs.h logio.cc main.cc gui/control.cc
gui/siminterface.h gui/siminterface.cc
patches/patch.logfilefmteip
floppy_bootsig_check: disabled=[0|1]. It is not disabled by default.
Sorry for any inconvenience it could cause
- changed the default (if cmos reg is 0) behavior for the floppy boot signature
check, so the new bios is compatible with older bochs binaries (useful if we
want to use the new bios when we release 1.4.1) :
1 : disabled
0 : enabled
- added info at launch time about the boot device and the floppy boot signature
check
- added a "LBA capable" flag in the ata controller
if you turn the delay down to 0, but it doesn't actually paste any
faster so there's no point. I will try to be satisfied with only
1000 chars per second. :)
* don't change the device state to "not present" at runtime if the path is
changed to "none" - simply eject the media if inserted
* don't change the device state to "present" at runtime if the previous state
is "not present"
* eject and re-insert the media if the current media state is "inserted"
* changing the media state in the config interface works now
* TODO: don't do anything if the path is unchanged
- bx_write_cdrom_options(): writing media state fixed
Here are the patches (without the serial name fix). Let me know if you want
me to change that. Oh, FYI, my changes also open up the com1 terminal in raw
mode, which makes the emulation much more accurate. You'll also notice that
I added infrastructure for com2->4 in the option parsing. I didn't add it to
the serial code, as I think a bunch of things need to be untangled before
that can work.
interface menus. Parallel port #1 is implemented, and I left stubs for
parallel port #2 in case we want to ever add it. If the parallel port
is enabled, the init method of parallel.cc does an fopen() on the output
file. If disabled, or if the fopen fails, the file handler remains
NULL and no characters are printed. There is no attempt to enable/disable
the operation of the parallel port, only the output to a file.
removed! I used this trick sometimes to check that a function returned
what I expected, like assert (func () == 0), but this caused the
func() to never get called. Oops.
- rework the order of initialization with and without the control panel.
The thing that was bothering me most was the command line options were
being processed after the user had set everything in the control panel.
This is clearly not what's expected--the command line options should
affect the startup defaults of the control panel, but whatever the user
chooses in the cpanel menus is the final choice.
- if the control panel (config interface) is not wanted, the user can
put "-nocp" or "-nocontrolpanel" as the FIRST argument on the command
line. Also, the "-psn" option which is automatically passed in by
MacOS X when you doubleclick the application causes the control panel
to be disabled. In this case, the order of operations is:
1. read bochsrc
2. parse command line options.
- if the control panel is enabled (default), the command line options are
parsed to provide the startup defaults for the control panel, but the
control panel settings are the final answer. So the order is:
1. parse command line options
2. run control panel (if user chooses, he can read bochsrc from menus)
- I haven't tested command line options with the debugger yet.
media status to 0 then 1 (equivalent to removing then inserting a disk).
Then it calls the UI function bx_gui.update_floppy_status_buttons()
if the interface has been initialized already.
cylinders, heads, and spt of each hard disk to be 1 instead of 0. This
caused the BIOS to report the existence of the hard disks, even when
they were never configured. The most obvious symptom of this problem
was "read multiple issued to non-disk" when a cdrom was enabled, which
happened because the BIOS tried to send hard disk commands to the CDROM.
which notifies them that the mouse_enabled bit has changed. Now that
mouse_enabled can be initialized or modified by parameter events in
addition to GUI events, the guis must be prepared for it. I have pasted
empty method definitions into mouse_enabled_changed_specific for all
guis except for X11, which I did the right way. The implementation
of this function must use the argument "val" rather than reading the
parameter.
control panel are all implemented as bx_list_c, and look much like
they did before.
- removed many hardcoded UI functions from control.cc, since the
much more general "text_ask" methods have replaced them.
- add range checking on integer parameter values. This exposed several
cases where my initial value for an integer parameter was not in range.
- cleaned up behavior of get/set methods. The get/set methods allow the
handler to override the value that is returned/set, or perform side
effects.
- the title parameter of a bx_list_c now defaults to the name.
- now bx_param_c fields that used to be private are protected instead
- removed references to bx_any
- moved definition of set_handler from siminterface.h to siminterface.cc.
I was considering with doing a "set" of the old value when the
handler is first installed, but that remains commented out.
- BX_BOOT_DISKA and BX_BOOT_DISKC are now 0,1 so that they can correspond
with the values of a bx_param_enum_c. For a while they were 0x00 and 0x80
corresponding to the numbering convention of the bios, but it didn't
really matter.
been converted into parameters temporarily have the letter "O" appended
to their name. I don't want to keep it this way, but it has helped
in the conversion process because the compiler refuses to compile the
old uses of the name. Before I started using the "O" trick, there were
many bugs like this: if (bx_options.diskc.present) {...}
This was legal with the new parameters, but it was testing whether the
parameter structure had been created, instead of testing the value of
the present parameter. Renaming present to Opresent turns this into
a compile error, which points out the incorrect use of the param.
- the "--disable-control-panel" no longer works, I'm afraid. I can no
longer support this and continue progress.
data structures, see bx_init_options in main.cc. The implementation
of this menu and all its choices is 17 lines long, see do_mem_options_menu
in gui/control.cc.
now the whole "Bochs Memory Options" menu uses new style parameters.
The next step is to remove the hardcoded stuff that generates and runs
this menu, and replace it with general menu building code. All you should
need to create this menu is the string "Bochs Memory Options", and the
IDs of the bx_param_c options that should appear on the menu. The
bx_param_c structure for each parameter tell what type it is, how to
display it, constraints on the value, what to do when the parameter
changes.
declared as bx_param_c * types in the bx_options structure. They are
initialized in main.cc (bx_init_options) with default values.
Access to parameters of this type should always be like this:
bx_options.mouse_enabled->get ();
bx_options.mouse_enabled->set (newval);
Eventually I will be transferring all options to this format.
when main.cc no longer had one. Now compiling with debugger is working
with the control panel. To get the control panel, you have to click
the snapshot button, and to get the debugger, you have to press ^C.
These should be better integrated (maybe a control panel menu choice
that jumps into the debugger and a debugger command that starts the
runtime control panel...)
BX_SUPPORT_APIC were used. To follow the pattern used by other
names like this, I changed them all to BX_SUPPORT_APIC.
Thanks to Tom Lindström for chasing this down!
panel. It gives the user the option of continue this time, continue
and never ask again for this type of log message, or die.
- the communication between control.cc and siminterface.cc is still
somewhat crude. I'm trying to implement it so that a network
protocol based on this interface will be simple. I'll get this cleaned
up soon.
writes a bochsrc for you.
- since there were two options related to logging, I moved them both
into a new struct called bx_log_options. This follows the pattern
used by other devices.
- in control.cc: removed option 1 from main menu, the one that said
"Read options from bochsrc.txt." This was identical to choosing
the next option, "Read options from..." and only saved you one
keystroke, so I removed it.
BX_CPU_C bx_cpu;
BX_MEM_C bx_mem;
and when more than one processor, use
BX_CPU_C *bx_cpu_array[BX_SMP_PROCESSORS];
BX_MEM_C *bx_mem_array[BX_ADDRESS_SPACES];
The changeover is controlled by BX_SMP_PROCESSORS, but there are only
a few code changes since nearly all code uses the BX_CPU(n) and BX_MEM(n)
macros.
- This turns out to make a 10% speed difference! With this revision,
the CVS version now gets 95% of the performance of the 3/25/2000
snapshot, which I've been using as my baseline.
is the first attempt to regain the performance of pre-SMP bochs
(1.1.2). When simulating only one processor, stay in cpu_loop forever
as pre-SMP versions did. The overhead of returning from cpu_loop over
and over was slowing us down.
in BRANCH-smp-bochs revisions.
- The general task was to make multiple CPU's which communicate
through their APICs. So instead of BX_CPU and BX_MEM, we now have
BX_CPU(x) and BX_MEM(y). For an SMP simulation you have several
processors in a shared memory space, so there might be processors
BX_CPU(0..3) but only one memory space BX_MEM(0). For cosimulation,
you could have BX_CPU(0) with BX_MEM(0), then BX_CPU(1) with
BX_MEM(1). WARNING: Cosimulation is almost certainly broken by the
SMP changes.
- to simulate multiple CPUs, you have to give each CPU time to execute
in turn. This is currently implemented using debugger guards. The
cpu loop steps one CPU for a few instructions, then steps the
next CPU for a few instructions, etc.
- there is some limited support in the debugger for two CPUs, for
example printing information from each CPU when single stepping.
- change Makefile.in to "cvs-snapshot" information rather than printing
the release number, since in fact it's not the same as the release anymore
- use #defines to give the actions names (ACT_IGNORE, ACT_REPORT, ACT_FATAL)
- register all logfunctions as they call setio, and keep a list so that
we can change their settings more easily. I admit I used a static-sized
array to store them. Sorry.
- instead of printing a prefix [GEN ] for generic messages, just leave the
prefix blank [ ]. Otherwise you start wondering what does gen stand
for.
- avoid reentry into fatal, since fatal can call BX_INFO and friends.
This avoids a potential infinite recursion.
- now that files other than .bochsrc can be the rc file, print the
actual name of the file in error messages.
what action to take on panic, error, info, and debug. The lines don't
have any effect quite yet because of an initialization order problem
with the logfunctions.
To see the commit logs for this use either cvsweb or
cvs update -r BRANCH-io-cleanup and then 'cvs log' the various files.
In general this provides a generic interface for logging.
logfunctions:: is a class that is inherited by some classes, and also
. allocated as a standalone global called 'genlog'. All logging uses
. one of the ::info(), ::error(), ::ldebug(), ::panic() methods of this
. class through 'BX_INFO(), BX_ERROR(), BX_DEBUG(), BX_PANIC()' macros
. respectively.
.
. An example usage:
. BX_INFO(("Hello, World!\n"));
iofunctions:: is a class that is allocated once by default, and assigned
as the iofunction of each logfunctions instance. It is this class that
maintains the file descriptor and other output related code, at this
point using vfprintf(). At some future point, someone may choose to
write a gui 'console' for bochs to which messages would be redirected
simply by assigning a different iofunction class to the various logfunctions
objects.
More cleanup is coming, but this works for now. If you want to see alot
of debugging output, in main.cc, change onoff[LOGLEV_DEBUG]=0 to =1.
Comments, bugs, flames, to me: todd@fries.net
signal. First, selection of the GUI should cause BX_GUI_SIGHANDLER to
be defined in config.h.in. Then, the GUI should define member functions
Bit32u get_sighandler_mask ();
void sighandler (int sig);
The mask function returns a bitfield where one bit corresponds to each
signal. For any signal whose bit is set to 1 in the return value of
get_sighandler_mask, the gui will control that signal. When the signal
arrives, bx_gui.sighandler(sig) will be called by bx_signal_handler,
instead of the default behavior of that signal.
since at present there's no way to actually manage this. To use both,
we will need to put the cdrom (or diskd) onto second ide controller with
a different IRQ.
