2001-10-03 17:10:38 +04:00
|
|
|
/////////////////////////////////////////////////////////////////////////
|
2006-12-27 18:21:03 +03:00
|
|
|
// $Id: siminterface.h,v 1.205 2006-12-27 15:21:03 vruppert Exp $
|
2001-10-03 17:10:38 +04:00
|
|
|
/////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
2005-07-31 18:49:45 +04:00
|
|
|
// Intro to siminterface by Bryce Denney:
|
|
|
|
//
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// Before I can describe what this file is for, I have to make the
|
|
|
|
// distinction between a configuration interface (CI) and the VGA display
|
|
|
|
// window (VGAW). I will try to avoid the term 'GUI' because it is unclear
|
|
|
|
// if that means CI or VGAW, and because not all interfaces are graphical
|
|
|
|
// anyway.
|
|
|
|
//
|
|
|
|
// The traditional Bochs screen is a window with a large VGA display panel and
|
|
|
|
// a series of buttons (floppy, cdrom, snapshot, power). Over the years, we
|
|
|
|
// have collected many implementations of the VGAW for different environments
|
|
|
|
// and platforms; each implementation is in a separate file under gui/*:
|
|
|
|
// x.cc, win32.cc, beos.cc, macintosh.cc, etc. The files gui.h and gui.cc
|
|
|
|
// define the platform independent part of the VGAW, leaving about 15 methods
|
|
|
|
// of the bx_gui_c class undefined. The platform dependent file must
|
|
|
|
// implement the remaining 15 methods.
|
|
|
|
//
|
|
|
|
// The configuration interface is relatively new, started by Bryce Denney in
|
|
|
|
// June 2001. The CI is intended to allow the user to edit a variety of
|
|
|
|
// configuration and runtime options. Some options, such as memory size or
|
|
|
|
// enabling the ethernet card, should only be changed before the simulation
|
|
|
|
// begins; others, such as floppy disk image, instructions per second, and
|
|
|
|
// logging options can be safely changed at runtime. The CI allows the user to
|
|
|
|
// make these changes. Before the CI existed, only a few things could be
|
|
|
|
// changed at runtime, all linked to clicking on the VGAW buttons.
|
|
|
|
//
|
|
|
|
// At the time that the CI was conceived, we were still debating what form the
|
|
|
|
// user interface part would take: stdin/stdout menus, a graphical application
|
|
|
|
// with menus and dialogs running in a separate thread, or even a tiny web
|
2002-08-29 18:59:37 +04:00
|
|
|
// server that you can connect to with a web browser. As a result the
|
|
|
|
// interface to the CI was designed so that the user interface of the CI
|
|
|
|
// could be replaced easily at compile time, or maybe even at runtime via
|
|
|
|
// a plugin architecture. To this end, we kept a clear separation between
|
|
|
|
// the user interface code and the siminterface, the code that interfaces with
|
|
|
|
// the simulator. The same siminterface is used all the time, while
|
|
|
|
// different implementations of the CI can be switched in reasonably easily.
|
|
|
|
// Only the CI code uses library specific graphics and I/O functions; the
|
|
|
|
// siminterface deals in portable abstractions and callback functions.
|
|
|
|
// The first CI implementation was a series of text mode menus implemented in
|
2005-07-10 13:02:30 +04:00
|
|
|
// textconfig.cc.
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
//
|
2002-08-29 18:59:37 +04:00
|
|
|
// The configuration interface MUST use the siminterface methods to access the
|
|
|
|
// simulator. It should not modify settings in some device with code like
|
|
|
|
// bx_floppy.s.media[2].heads = 17. If such access is needed, then a
|
|
|
|
// siminterface method should be written to make the change on the CI's behalf.
|
|
|
|
// This separation is enforced by the fact that the CI does not even include
|
2005-07-31 18:49:45 +04:00
|
|
|
// bochs.h. You'll notice that textconfig.cc includes osdep.h, textconfig.h,
|
2005-07-10 13:02:30 +04:00
|
|
|
// and siminterface.h, so it doesn't know what bx_floppy or bx_cpu_c are.
|
|
|
|
// I'm sure some people will say is overly restrictive and/or annoying. When I
|
|
|
|
// set it up this way, we were still talking about making the CI in a seperate
|
2002-08-29 18:59:37 +04:00
|
|
|
// process, where direct method calls would be impossible. Also, we have been
|
2005-07-31 18:49:45 +04:00
|
|
|
// considering turning devices into plugin modules which are dynamically
|
2002-08-29 18:59:37 +04:00
|
|
|
// linked. Any direct references to something like bx_floppy.s.media[2].heads
|
|
|
|
// would have to be reworked before a plugin interface was possible as well.
|
|
|
|
//
|
|
|
|
// The siminterface is the glue between the CI and the simulator. There is
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// just one global instance of the siminterface object, which can be referred
|
2005-07-31 18:49:45 +04:00
|
|
|
// to by the global variable bx_simulator_interface_c *SIM. The base class
|
2002-08-29 18:59:37 +04:00
|
|
|
// bx_simulator_interface_c, contains only virtual functions and it defines the
|
|
|
|
// interface that the CI is allowed to use. In siminterface.cc, a class
|
|
|
|
// called bx_real_sim_c is defined with bx_simulator_interface_c as its parent
|
|
|
|
// class. Bx_real_sim_c implements each of the functions. The separation into
|
|
|
|
// parent class and child class leaves the possibility of making a different
|
|
|
|
// child class that talks to the simulator in a different way (networking for
|
2002-09-20 21:39:07 +04:00
|
|
|
// example). If you were writing a user interface in a separate process, you
|
|
|
|
// could define a subclass of bx_simulator_interface_c called
|
|
|
|
// bx_siminterface_proxy_c which opens up a network port and turns all method
|
|
|
|
// calls into network sends and receives. Because the interface is defined
|
|
|
|
// entirely by the base class, the code that calls the methods would not know
|
|
|
|
// the difference.
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
//
|
2002-08-29 18:59:37 +04:00
|
|
|
// An important part of the siminterface implementation is the use of parameter
|
|
|
|
// classes, or bx_param_*. The parameter classes are described below, where
|
2006-03-01 20:14:36 +03:00
|
|
|
// they are declared. Search for "parameter classes" below for details.
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
//
|
2002-08-29 18:59:37 +04:00
|
|
|
// Also this header file declares data structures for certain events that pass
|
|
|
|
// between the siminterface and the CI. Search for "event structures" below.
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
|
2001-06-08 11:20:07 +04:00
|
|
|
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
//////////////////////////////////////////////////////
|
2004-01-29 21:50:33 +03:00
|
|
|
// BX_USE_TEXTCONFIG should be set to 1 when the text mode configuration interface
|
2002-04-18 04:22:20 +04:00
|
|
|
// is compiled in. This gives each type of parameter a text_print and text_ask
|
2004-01-29 21:50:33 +03:00
|
|
|
// method (defined in gui/textconfig.cc) so that you can call text_ask() on any
|
2002-04-18 04:22:20 +04:00
|
|
|
// kind of parameter to ask the user to edit the value.
|
|
|
|
//
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// I have been considering whether to use the same strategy for the
|
2005-01-05 22:54:32 +03:00
|
|
|
// wxWidgets interface, but I'm not sure if I like it. One problem is
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// that in order to declare member functions that are useful for
|
2005-01-05 22:54:32 +03:00
|
|
|
// wxWidgets, the wxWidgets header files would have to be included
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// before the param object definitions. That means that all the
|
2005-01-05 22:54:32 +03:00
|
|
|
// wxWidgets headers would have be included when compiling every
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// single bochs file. One of the things I like about the separation
|
2002-08-29 18:59:37 +04:00
|
|
|
// between the simulator and CI is that the two parts can be
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// compiled without any knowledge of the other. Bochs doesn't include
|
2005-01-05 22:54:32 +03:00
|
|
|
// <wx.h>, and the wxWidgets CI (wxmain.cc) doesn't need to include <bochs.h>.
|
2002-08-29 18:59:37 +04:00
|
|
|
// Aside from making compiles faster, this enforces the use of the siminterface
|
|
|
|
// so it keeps the interface clean (important when we may have multiple UI
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// implementations for example). This argues for keeping UI-specific
|
2002-08-29 18:59:37 +04:00
|
|
|
// structures out of the simulator interface. It certainly works ok for the
|
|
|
|
// text interface, but that's because FILE* is standard and portable.
|
2001-06-18 18:11:55 +04:00
|
|
|
|
|
|
|
//////////////////////////////////////////////////////
|
2001-06-16 03:52:34 +04:00
|
|
|
|
2002-04-18 04:22:20 +04:00
|
|
|
// list of possible types for bx_param_c and descendant objects
|
|
|
|
typedef enum {
|
|
|
|
BXT_OBJECT = 201,
|
|
|
|
BXT_PARAM,
|
|
|
|
BXT_PARAM_NUM,
|
|
|
|
BXT_PARAM_BOOL,
|
|
|
|
BXT_PARAM_ENUM,
|
|
|
|
BXT_PARAM_STRING,
|
2006-04-15 18:05:18 +04:00
|
|
|
BXT_PARAM_DATA,
|
2002-04-18 04:22:20 +04:00
|
|
|
BXT_LIST
|
|
|
|
} bx_objtype;
|
|
|
|
|
2006-02-18 01:27:38 +03:00
|
|
|
// define parameter path names. These names give the location in the
|
|
|
|
// parameter tree where each can be found. The names correspond to
|
|
|
|
// the old BXP_* enum values, which have been eliminated.
|
2006-10-08 14:18:51 +04:00
|
|
|
#define BXPN_SEL_CONFIG_INTERFACE "general.config_interface"
|
|
|
|
#define BXPN_BOCHS_START "general.start_mode"
|
|
|
|
#define BXPN_RESTORE_FLAG "general.restore"
|
|
|
|
#define BXPN_RESTORE_PATH "general.restore_path"
|
|
|
|
#define BXPN_DEBUG_RUNNING "general.debug_running"
|
2006-02-18 19:53:18 +03:00
|
|
|
#define BXPN_CPU_NPROCESSORS "cpu.n_processors"
|
|
|
|
#define BXPN_CPU_NCORES "cpu.n_cores"
|
|
|
|
#define BXPN_CPU_NTHREADS "cpu.n_threads"
|
|
|
|
#define BXPN_IPS "cpu.ips"
|
2006-06-22 00:42:26 +04:00
|
|
|
#define BXPN_SMP_QUANTUM "cpu.quantum"
|
2006-02-18 19:53:18 +03:00
|
|
|
#define BXPN_RESET_ON_TRIPLE_FAULT "cpu.reset_on_triple_fault"
|
2006-02-18 01:27:38 +03:00
|
|
|
#define BXPN_MEM_SIZE "memory.standard.ram.size"
|
|
|
|
#define BXPN_ROM_PATH "memory.standard.rom.path"
|
|
|
|
#define BXPN_ROM_ADDRESS "memory.standard.rom.addr"
|
|
|
|
#define BXPN_VGA_ROM_PATH "memory.standard.vgarom.path"
|
|
|
|
#define BXPN_OPTROM1_PATH "memory.optrom.1.path"
|
|
|
|
#define BXPN_OPTROM1_ADDRESS "memory.optrom.1.addr"
|
|
|
|
#define BXPN_OPTROM2_PATH "memory.optrom.2.path"
|
|
|
|
#define BXPN_OPTROM2_ADDRESS "memory.optrom.2.addr"
|
|
|
|
#define BXPN_OPTROM3_PATH "memory.optrom.3.path"
|
|
|
|
#define BXPN_OPTROM3_ADDRESS "memory.optrom.3.addr"
|
|
|
|
#define BXPN_OPTROM4_PATH "memory.optrom.4.path"
|
|
|
|
#define BXPN_OPTROM4_ADDRESS "memory.optrom.4.addr"
|
|
|
|
#define BXPN_OPTRAM1_PATH "memory.optram.1.path"
|
|
|
|
#define BXPN_OPTRAM1_ADDRESS "memory.optram.1.addr"
|
|
|
|
#define BXPN_OPTRAM2_PATH "memory.optram.2.path"
|
|
|
|
#define BXPN_OPTRAM2_ADDRESS "memory.optram.2.addr"
|
|
|
|
#define BXPN_OPTRAM3_PATH "memory.optram.3.path"
|
|
|
|
#define BXPN_OPTRAM3_ADDRESS "memory.optram.3.addr"
|
|
|
|
#define BXPN_OPTRAM4_PATH "memory.optram.4.path"
|
|
|
|
#define BXPN_OPTRAM4_ADDRESS "memory.optram.4.addr"
|
2006-02-19 18:43:03 +03:00
|
|
|
#define BXPN_CLOCK_SYNC "clock_cmos.clock_sync"
|
|
|
|
#define BXPN_CLOCK_TIME0 "clock_cmos.time0"
|
|
|
|
#define BXPN_CMOSIMAGE_ENABLED "clock_cmos.cmosimage.enabled"
|
|
|
|
#define BXPN_CMOSIMAGE_PATH "clock_cmos.cmosimage.path"
|
|
|
|
#define BXPN_CMOSIMAGE_RTC_INIT "clock_cmos.cmosimage.rtc_init"
|
2006-02-20 00:35:50 +03:00
|
|
|
#define BXPN_I440FX_SUPPORT "pci.i440fx_support"
|
2006-02-21 00:29:13 +03:00
|
|
|
#define BXPN_PCIDEV_VENDOR "pci.pcidev.vendor"
|
|
|
|
#define BXPN_PCIDEV_DEVICE "pci.pcidev.device"
|
2006-02-22 00:35:09 +03:00
|
|
|
#define BXPN_SEL_DISPLAY_LIBRARY "display.display_library"
|
|
|
|
#define BXPN_DISPLAYLIB_OPTIONS "display.displaylib_options"
|
|
|
|
#define BXPN_PRIVATE_COLORMAP "display.private_colormap"
|
|
|
|
#define BXPN_FULLSCREEN "display.fullscreen"
|
|
|
|
#define BXPN_SCREENMODE "display.screenmode"
|
|
|
|
#define BXPN_VGA_EXTENSION "display.vga_extension"
|
|
|
|
#define BXPN_VGA_UPDATE_INTERVAL "display.vga_update_interval"
|
2006-02-22 22:18:29 +03:00
|
|
|
#define BXPN_KBD_TYPE "keyboard_mouse.keyboard.type"
|
|
|
|
#define BXPN_KBD_SERIAL_DELAY "keyboard_mouse.keyboard.serial_delay"
|
|
|
|
#define BXPN_KBD_PASTE_DELAY "keyboard_mouse.keyboard.paste_delay"
|
|
|
|
#define BXPN_KBD_USEMAPPING "keyboard_mouse.keyboard.use_mapping"
|
|
|
|
#define BXPN_KBD_KEYMAP "keyboard_mouse.keyboard.keymap"
|
|
|
|
#define BXPN_USER_SHORTCUT "keyboard_mouse.keyboard.user_shortcut"
|
|
|
|
#define BXPN_MOUSE_TYPE "keyboard_mouse.mouse.type"
|
|
|
|
#define BXPN_MOUSE_ENABLED "keyboard_mouse.mouse.enabled"
|
2006-02-24 01:48:57 +03:00
|
|
|
#define BXPN_BOOTDRIVE1 "boot_params.boot_drive1"
|
|
|
|
#define BXPN_BOOTDRIVE2 "boot_params.boot_drive2"
|
|
|
|
#define BXPN_BOOTDRIVE3 "boot_params.boot_drive3"
|
|
|
|
#define BXPN_FLOPPYSIGCHECK "boot_params.floppy_sig_check"
|
|
|
|
#define BXPN_LOAD32BITOS_WHICH "boot_params.load32bitos.which"
|
|
|
|
#define BXPN_LOAD32BITOS_PATH "boot_params.load32bitos.path"
|
|
|
|
#define BXPN_LOAD32BITOS_IOLOG "boot_params.load32bitos.iolog"
|
|
|
|
#define BXPN_LOAD32BITOS_INITRD "boot_params.load32bitos.initrd"
|
2006-02-25 01:35:46 +03:00
|
|
|
#define BXPN_FLOPPYA "floppy.0"
|
|
|
|
#define BXPN_FLOPPYA_DEVTYPE "floppy.0.devtype"
|
|
|
|
#define BXPN_FLOPPYA_PATH "floppy.0.path"
|
|
|
|
#define BXPN_FLOPPYA_TYPE "floppy.0.type"
|
|
|
|
#define BXPN_FLOPPYA_STATUS "floppy.0.status"
|
|
|
|
#define BXPN_FLOPPYB "floppy.1"
|
|
|
|
#define BXPN_FLOPPYB_DEVTYPE "floppy.1.devtype"
|
|
|
|
#define BXPN_FLOPPYB_PATH "floppy.1.path"
|
|
|
|
#define BXPN_FLOPPYB_TYPE "floppy.1.type"
|
|
|
|
#define BXPN_FLOPPYB_STATUS "floppy.1.status"
|
2006-02-26 22:11:20 +03:00
|
|
|
#define BXPN_ATA0_RES "ata.0.resources"
|
|
|
|
#define BXPN_ATA1_RES "ata.1.resources"
|
|
|
|
#define BXPN_ATA2_RES "ata.2.resources"
|
|
|
|
#define BXPN_ATA3_RES "ata.3.resources"
|
|
|
|
#define BXPN_ATA0_ENABLED "ata.0.resources.enabled"
|
|
|
|
#define BXPN_ATA1_ENABLED "ata.1.resources.enabled"
|
|
|
|
#define BXPN_ATA0_MASTER "ata.0.master"
|
|
|
|
#define BXPN_ATA1_MASTER "ata.1.master"
|
|
|
|
#define BXPN_ATA2_MASTER "ata.2.master"
|
|
|
|
#define BXPN_ATA3_MASTER "ata.3.master"
|
|
|
|
#define BXPN_ATA0_SLAVE "ata.0.slave"
|
|
|
|
#define BXPN_ATA1_SLAVE "ata.1.slave"
|
|
|
|
#define BXPN_ATA2_SLAVE "ata.2.slave"
|
|
|
|
#define BXPN_ATA3_SLAVE "ata.3.slave"
|
2006-03-01 20:14:36 +03:00
|
|
|
#define BXPN_USB1_ENABLED "ports.usb.1.enabled"
|
|
|
|
#define BXPN_USB1_PORT1 "ports.usb.1.port1"
|
|
|
|
#define BXPN_USB1_OPTION1 "ports.usb.1.option1"
|
|
|
|
#define BXPN_USB1_PORT2 "ports.usb.1.port2"
|
|
|
|
#define BXPN_USB1_OPTION2 "ports.usb.1.option2"
|
2006-03-02 23:13:14 +03:00
|
|
|
#define BXPN_NE2K "network.ne2k"
|
|
|
|
#define BXPN_NE2K_ENABLED "network.ne2k.enabled"
|
|
|
|
#define BXPN_PNIC "network.pnic"
|
|
|
|
#define BXPN_PNIC_ENABLED "network.pnic.enabled"
|
2006-03-03 23:29:50 +03:00
|
|
|
#define BXPN_SB16 "sound.sb16"
|
|
|
|
#define BXPN_SB16_ENABLED "sound.sb16.enabled"
|
|
|
|
#define BXPN_SB16_MIDIFILE "sound.sb16.midifile"
|
|
|
|
#define BXPN_SB16_WAVEFILE "sound.sb16.wavefile"
|
|
|
|
#define BXPN_SB16_DMATIMER "sound.sb16.dmatimer"
|
|
|
|
#define BXPN_SB16_LOGLEVEL "sound.sb16.loglevel"
|
2006-03-04 15:43:47 +03:00
|
|
|
#define BXPN_TEXT_SNAPSHOT_CHECK "misc.text_snapshot_check"
|
|
|
|
#define BXPN_GDBSTUB "misc.gdbstub"
|
2006-03-05 13:24:29 +03:00
|
|
|
#define BXPN_LOG_FILENAME "log.filename"
|
|
|
|
#define BXPN_LOG_PREFIX "log.prefix"
|
|
|
|
#define BXPN_DEBUGGER_LOG_FILENAME "log.debugger_filename"
|
|
|
|
#define BXPN_MENU_DISK "menu.disk"
|
|
|
|
#define BXPN_MENU_MEMORY "menu.memory"
|
|
|
|
#define BXPN_MENU_RUNTIME "menu.runtime"
|
2006-04-16 14:12:32 +04:00
|
|
|
#define BXPN_WX_KBD_STATE "wxdebug.keyboard"
|
|
|
|
#define BXPN_WX_CPU_STATE "wxdebug.cpu"
|
|
|
|
#define BXPN_WX_CPU0_STATE "wxdebug.cpu.0"
|
|
|
|
#define BXPN_WX_CPU0_EFLAGS_IOPL "wxdebug.cpu.0.IOPL"
|
2006-02-19 18:43:03 +03:00
|
|
|
|
|
|
|
// base value for generated new parameter id
|
|
|
|
#define BXP_NEW_PARAM_ID 1001
|
2006-02-18 01:27:38 +03:00
|
|
|
|
2001-06-16 03:52:34 +04:00
|
|
|
typedef enum {
|
2002-04-18 04:22:20 +04:00
|
|
|
BX_TOOLBAR_UNDEFINED,
|
|
|
|
BX_TOOLBAR_FLOPPYA,
|
|
|
|
BX_TOOLBAR_FLOPPYB,
|
|
|
|
BX_TOOLBAR_CDROMD,
|
|
|
|
BX_TOOLBAR_RESET,
|
|
|
|
BX_TOOLBAR_POWER,
|
2006-06-07 23:40:15 +04:00
|
|
|
#if BX_SUPPORT_SAVE_RESTORE
|
|
|
|
BX_TOOLBAR_SAVE_RESTORE,
|
|
|
|
#endif
|
2002-04-18 04:22:20 +04:00
|
|
|
BX_TOOLBAR_COPY,
|
|
|
|
BX_TOOLBAR_PASTE,
|
|
|
|
BX_TOOLBAR_SNAPSHOT,
|
|
|
|
BX_TOOLBAR_CONFIG,
|
2002-08-09 10:16:43 +04:00
|
|
|
BX_TOOLBAR_MOUSE_EN,
|
|
|
|
BX_TOOLBAR_USER
|
2002-04-18 04:22:20 +04:00
|
|
|
} bx_toolbar_buttons;
|
|
|
|
|
|
|
|
// Log level defines
|
|
|
|
typedef enum {
|
|
|
|
LOGLEV_DEBUG = 0,
|
|
|
|
LOGLEV_INFO,
|
|
|
|
LOGLEV_ERROR,
|
|
|
|
LOGLEV_PANIC,
|
2002-12-17 06:36:53 +03:00
|
|
|
LOGLEV_PASS,
|
2002-04-18 04:22:20 +04:00
|
|
|
N_LOGLEV
|
|
|
|
} bx_log_levels;
|
|
|
|
|
2002-08-30 10:06:36 +04:00
|
|
|
// types of reset
|
|
|
|
#define BX_RESET_SOFTWARE 10
|
|
|
|
#define BX_RESET_HARDWARE 11
|
|
|
|
|
|
|
|
//cdrom
|
|
|
|
#define BX_EJECTED 10
|
|
|
|
#define BX_INSERTED 11
|
|
|
|
|
2004-10-16 19:44:00 +04:00
|
|
|
// boot devices (using the same values as the rombios)
|
|
|
|
#define BX_BOOT_NONE 0
|
|
|
|
#define BX_BOOT_FLOPPYA 1
|
|
|
|
#define BX_BOOT_DISKC 2
|
|
|
|
#define BX_BOOT_CDROM 3
|
2002-08-31 08:57:21 +04:00
|
|
|
|
2003-08-24 14:08:49 +04:00
|
|
|
// loader hack
|
|
|
|
#define Load32bitOSNone 0
|
|
|
|
#define Load32bitOSLinux 1
|
|
|
|
#define Load32bitOSNullKernel 2 // being developed for plex86
|
|
|
|
#define Load32bitOSLast 2
|
2002-08-31 08:57:21 +04:00
|
|
|
|
2002-04-18 04:22:20 +04:00
|
|
|
///////////////////////////////////////////////////////////////////
|
2002-08-29 18:59:37 +04:00
|
|
|
// event structures for communication between simulator and CI
|
2002-04-18 04:22:20 +04:00
|
|
|
///////////////////////////////////////////////////////////////////
|
2002-08-29 18:59:37 +04:00
|
|
|
// Because the CI (configuration interface) might be in a different
|
|
|
|
// thread or even a different process, we pass events encoded in data
|
|
|
|
// structures to it instead of just calling functions. Each type of
|
|
|
|
// event is declared as a different structure, and then all those
|
|
|
|
// structures are squished into a union in BxEvent. (BTW, this is
|
|
|
|
// almost exactly how X windows event structs work.)
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
//
|
|
|
|
// These are simple structs, unblemished by C++ methods and tricks.
|
|
|
|
// No matter what event type it is, we allocate a BxEvent for each
|
|
|
|
// one, as opposed to trying to save a few bytes on small events by
|
|
|
|
// allocating only the bytes necessary for it. This makes it easy and
|
|
|
|
// fast to store events in a queue, like this
|
|
|
|
// BxEvent event_queue[MAX_EVENTS];
|
|
|
|
//
|
|
|
|
// Events come in two varieties: synchronous and asynchronous. We
|
2002-08-29 18:59:37 +04:00
|
|
|
// have to worry about sync and async events because the CI and the
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// simulation may be running in different threads. An async event is
|
|
|
|
// the simplest. Whichever thread originates the event just builds
|
|
|
|
// the data structure, sends it, and then continues with its business.
|
|
|
|
// Async events can go in either direction. Synchronous events
|
|
|
|
// require the other thread to "respond" before the originating thread
|
|
|
|
// can continue. It's like a function with a return value; you can't
|
|
|
|
// continue until you get the return value back.
|
|
|
|
//
|
|
|
|
// Examples:
|
|
|
|
//
|
2005-01-05 22:54:32 +03:00
|
|
|
// async event: In the wxWidgets implementation, both the CI and the
|
|
|
|
// VGAW operate in the wxWidgets GUI thread. When the user presses a
|
|
|
|
// key, wxWidgets sends a wxKeyEvent to the VGAW event handler code in
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// wx.cc. The VGAW handler then builds a BxEvent with
|
|
|
|
// type=BX_ASYNC_EVT_KEY, and fills in the bx_key and raw_scancode
|
|
|
|
// fields. The asynchronous event is placed on the event_queue for
|
2005-01-05 22:54:32 +03:00
|
|
|
// the simulator, then the VGAW handler returns. (With wxWidgets and
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// many other graphical libaries, the event handler must return
|
|
|
|
// quickly because the window will not be updated until it's done.)
|
|
|
|
// Some time later, the simulator reaches the point where it checks
|
|
|
|
// for new events from the user (actually controlled by
|
|
|
|
// bx_keyb_c::periodic() in iodev/keyboard.cc) and calls
|
|
|
|
// bx_gui.handle_events(). Then all the events in the queue are
|
|
|
|
// processed by the simulator. There is no "response" sent back to
|
|
|
|
// the originating thread.
|
|
|
|
//
|
|
|
|
// sync event: Sometimes the simulator reaches a point where it needs
|
|
|
|
// to ask the user how to proceed. In this case, the simulator sends
|
|
|
|
// a synchronous event because it requires a response before it can
|
|
|
|
// continue. It builds an event structure, perhaps with type
|
|
|
|
// BX_SYNC_EVT_ASK_PARAM, sends it to the user interface
|
|
|
|
// using the event handler function defined by set_notify_callback(),
|
|
|
|
// and pauses the simulation. The user interface asks the user the
|
|
|
|
// question, and puts the answer into the BxEvent.retcode field. The
|
|
|
|
// event handler function returns the modified BxEvent with retcode
|
|
|
|
// filled in, and the simulation continues. The details of this
|
2002-08-29 18:59:37 +04:00
|
|
|
// transaction can be complicated if the simulation and CI are not
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// in the same thread, but the behavior is as described.
|
|
|
|
//
|
2002-04-18 04:22:20 +04:00
|
|
|
|
|
|
|
///// types and definitions used in event structures
|
|
|
|
|
|
|
|
#define BX_EVT_IS_ASYNC(type) ((type) > __ALL_EVENTS_BELOW_ARE_ASYNC__)
|
|
|
|
|
|
|
|
typedef enum {
|
|
|
|
__ALL_EVENTS_BELOW_ARE_SYNCHRONOUS__ = 2000,
|
2002-08-29 18:59:37 +04:00
|
|
|
BX_SYNC_EVT_GET_PARAM, // CI -> simulator -> CI
|
|
|
|
BX_SYNC_EVT_ASK_PARAM, // simulator -> CI -> simulator
|
|
|
|
BX_SYNC_EVT_TICK, // simulator -> CI, wait for response.
|
|
|
|
BX_SYNC_EVT_LOG_ASK, // simulator -> CI, wait for response.
|
- add infrastructure for sending commands from the wxWindows interface to the
Bochs debugger. The Bochs debugger calls SIM->debug_get_next_command() which
does not return until a debugger command is found. The siminterface sends an
synchronous event to the wxWindows thread with a blank to be filled in with a
debugger command. wxWindows fills in the blank and sends the synchronous
event back, and the Bochs debugger interprets it as if it was typed on
the command line. For the long term I haven't decided whether to stick with
sending text strings vs. some other method.
- so far the wxWindows debugger consists of one big dialog box that shows
all the standard registers, and a working Continue, Stop, and Step button.
- modify ParamDialog so that it is more useful as a base class, by moving
some things to protected members&fields, separating out functionality
that is most likely to be replaced into virtual functions, and making it
generally more flexible. The new CpuRegistersDialog is based on
ParamDialog.
- in wxdialog.cc, continue the convention of using wxID_HELP, wxID_OK,
wxID_CANCEL, etc. for the id's of buttons, instead of wxHELP, wxOK, etc.
which are intended to be ORred together in a bit field.
- cpu/init.cc: put ifdefs around DEFPARAMs for flags in configurations
where they don't exist. Add an eflags shadow parameter that represents all
of the bits of eflags at once. There are also boolean shadow params for
each bit.
- modified files: cpu/init.cc debug/dbg_main.cc debug/debug.h
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h
2002-09-13 23:39:38 +04:00
|
|
|
BX_SYNC_EVT_GET_DBG_COMMAND, // simulator -> CI, wait for response.
|
2002-04-18 04:22:20 +04:00
|
|
|
__ALL_EVENTS_BELOW_ARE_ASYNC__,
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
BX_ASYNC_EVT_KEY, // vga window -> simulator
|
|
|
|
BX_ASYNC_EVT_MOUSE, // vga window -> simulator
|
2002-08-29 18:59:37 +04:00
|
|
|
BX_ASYNC_EVT_SET_PARAM, // CI -> simulator
|
|
|
|
BX_ASYNC_EVT_LOG_MSG, // simulator -> CI
|
- add Debug Log dialog, which shows all the text output that is normally
printed to stderr in the text debugger. Also allows the user to
type (text) debugger commands directly, which also appear in the log.
- all text output in the debugger now passes through dbg_printf()
(used to be fprintf to stderr) so that in wxWindows I can redirect
it all to the wxWindows debug log screen. Added debug_fputs to
siminterface which actually sends the text to the GUI by creating
a BX_ASYNC_EVT_DBG_MSG event.
- changed prefix and msg fields of BxLogMsgEvent to const char *,
and also in args of logmsg method of siminterface.
- don't trap SIGINT in wxWindows. There are other ways to stop execution.
Also, signal handling with multiple threads is very strange and different
on different platforms.
- minor changes to fix gcc -Wall warnings in dbg_main.cc
- add a new boolean parameter BXP_DEBUG_RUNNING that tells if the debugger is
running freely or not. This is used by the wxWindows GUI to enable or
disable certain choices.
- CpuRegistersDialog has continue,stop,step buttons. When the sim is running
freely, I disable continue and step, and enable stop. When the sim stops
to wait for the user, I disable stop and enable continue and step. The
change of enables used to be triggered by actually pressing the button,
but then if you started/stopped the simulation in some other way (typing
in debug log window) the enables were never changed. Now the enables are
controlled by the value of BXP_DEBUG_RUNNING, which is set by the debug code
itself, and the buttons are enabled at the right time.
- ParamDialog::Refresh() is now virtual so that child classes can redefine
its refresh behavior.
- in safeWxStrcpy, force the last element of the array to be a 0, since
I noticed that strncpy is not guaranteed to terminate the string!
- modified: debug/dbg_main.cc debug/debug.h gui/siminterface.cc
gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
gui/wxmain.h
2002-09-15 15:21:35 +04:00
|
|
|
BX_ASYNC_EVT_DBG_MSG, // simulator -> CI
|
2002-08-29 18:59:37 +04:00
|
|
|
BX_ASYNC_EVT_VALUE_CHANGED, // simulator -> CI
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
BX_ASYNC_EVT_TOOLBAR, // CI -> simulator
|
|
|
|
BX_ASYNC_EVT_REFRESH // simulator -> CI
|
2002-04-18 04:22:20 +04:00
|
|
|
} BxEventType;
|
|
|
|
|
|
|
|
typedef union {
|
|
|
|
Bit32s s32;
|
|
|
|
char *charptr;
|
|
|
|
} AnyParamVal;
|
|
|
|
|
|
|
|
// Define substructures which make up the interior of BxEvent. The
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// substructures, such as BxKeyEvent or BxMouseEvent, should never be
|
|
|
|
// allocated on their own. They are only intended to be used within
|
|
|
|
// the union in the BxEvent structure.
|
2002-04-18 04:22:20 +04:00
|
|
|
|
|
|
|
// Event type: BX_SYNC_EVT_TICK
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
//
|
2002-04-18 04:22:20 +04:00
|
|
|
// A tick event is synchronous, sent from the simulator to the GUI. The
|
|
|
|
// event doesn't do anything visible. Primarily it gives the GUI a chance
|
|
|
|
// to tell the simulator to quit, if necessary. There may be other uses
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// for the tick in the future, such as giving some kind of regular
|
|
|
|
// status report or mentioning watched values that changed, but so far
|
|
|
|
// it's just for that one thing. There is no data associated with a
|
|
|
|
// tick event.
|
2002-04-18 04:22:20 +04:00
|
|
|
|
|
|
|
// Event type: BX_ASYNC_EVT_KEY
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
//
|
|
|
|
// A key event can be sent from the VGA window to the Bochs simulator.
|
|
|
|
// It is asynchronous.
|
2002-04-18 04:22:20 +04:00
|
|
|
typedef struct {
|
|
|
|
// what was pressed? This is a BX_KEY_* value. For key releases,
|
|
|
|
// BX_KEY_RELEASED is ORed with the base BX_KEY_*.
|
|
|
|
Bit32u bx_key;
|
2002-10-25 15:44:41 +04:00
|
|
|
bx_bool raw_scancode;
|
2002-04-18 04:22:20 +04:00
|
|
|
} BxKeyEvent;
|
|
|
|
|
|
|
|
// Event type: BX_ASYNC_EVT_MOUSE
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
//
|
|
|
|
// A mouse event can be sent from the VGA window to the Bochs
|
|
|
|
// simulator. It is asynchronous. Currently unused because mouse
|
2005-01-05 22:54:32 +03:00
|
|
|
// events aren't implemented in our wxWidgets code yet.
|
2002-04-18 04:22:20 +04:00
|
|
|
typedef struct {
|
|
|
|
// type is BX_EVT_MOUSE
|
2002-09-19 03:17:47 +04:00
|
|
|
Bit16s dx, dy; // mouse motion delta
|
2002-04-18 04:22:20 +04:00
|
|
|
Bit8u buttons; // which buttons are pressed.
|
|
|
|
// bit 0: 1=left button down, 0=up
|
|
|
|
// bit 1: 1=right button down, 0=up
|
|
|
|
} BxMouseEvent;
|
|
|
|
|
|
|
|
// Event type: BX_SYNC_EVT_GET_PARAM, BX_ASYNC_EVT_SET_PARAM
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
//
|
2002-08-29 18:59:37 +04:00
|
|
|
// Parameter set/get events are initiated by the CI, since Bochs can
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// always access the parameters directly. So far, I haven't used
|
2002-08-29 18:59:37 +04:00
|
|
|
// these event types. In the CI I just call
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// SIM->get_param(parameter_id) to get a pointer to the bx_param_c
|
|
|
|
// object and then call the get/set methods. This is okay for
|
|
|
|
// configuration since bochs is not running. However it could be
|
|
|
|
// dangerous for the GUI thread to poke around in Bochs structures
|
|
|
|
// while the thread is running. For these cases, I may have to be
|
|
|
|
// more careful and actually build get/set events and place them on
|
|
|
|
// Bochs's event queue to be processed during SIM->periodic() or
|
|
|
|
// something.
|
2002-04-18 04:22:20 +04:00
|
|
|
typedef struct {
|
|
|
|
// type is BX_EVT_GET_PARAM, BX_EVT_SET_PARAM
|
|
|
|
class bx_param_c *param; // pointer to param structure
|
|
|
|
AnyParamVal val;
|
|
|
|
} BxParamEvent;
|
|
|
|
|
|
|
|
// Event type: BX_SYNC_EVT_ASK_PARAM
|
2002-08-29 18:59:37 +04:00
|
|
|
// Synchronous event sent from the simulator to the CI. This tells the
|
|
|
|
// CI to ask the user to choose the value of a parameter. The CI may
|
2002-04-18 04:22:20 +04:00
|
|
|
// need to discover the type of parameter so that it can use the right
|
|
|
|
// kind of graphical display. The BxParamEvent is used for these events
|
|
|
|
// too.
|
|
|
|
// FIXME: at the moment the GUI implements the ASK_PARAM event for just
|
|
|
|
// a few parameter types. I need to implement the event for all parameter
|
|
|
|
// types.
|
|
|
|
|
|
|
|
// Event type: BX_ASYNC_EVT_VALUE_CHANGED
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
//
|
2002-08-29 18:59:37 +04:00
|
|
|
// Asynchronous event sent from the simulator to the CI, telling it that
|
2002-04-18 04:22:20 +04:00
|
|
|
// some value that it (hopefully) cares about has changed. This isn't
|
|
|
|
// being used yet, but a good example is in a debugger interface, you might
|
|
|
|
// want to maintain a reasonably current display of the PC or some other
|
2002-08-29 18:59:37 +04:00
|
|
|
// simulation state. The CI would set some kind of event mask (which
|
2002-04-18 04:22:20 +04:00
|
|
|
// doesn't exist now of course) and then when certain values change, the
|
2002-08-29 18:59:37 +04:00
|
|
|
// simulator would send this event so that the CI can update. We may need
|
2002-04-18 04:22:20 +04:00
|
|
|
// some kind of "flow control" since the simulator will be able to produce
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// new events much faster than the gui can accept them.
|
2002-04-18 04:22:20 +04:00
|
|
|
|
- use setjmp() and longjmp() to quit the simulation thread cleanly.
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.
2002-08-27 22:11:13 +04:00
|
|
|
// Event type: BX_ASYNC_EVT_LOG_MSG (unused)
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
//
|
2002-08-29 18:59:37 +04:00
|
|
|
// Asynchronous event from the simulator to the CI. When a BX_PANIC,
|
2002-04-18 04:22:20 +04:00
|
|
|
// BX_ERROR, BX_INFO, or BX_DEBUG is found in the simulator code, this
|
2002-08-29 18:59:37 +04:00
|
|
|
// event type can be used to inform the CI of the condition. There is
|
|
|
|
// no point in sending messages to the CI that will not be displayed; these
|
2002-04-18 04:22:20 +04:00
|
|
|
// would only slow the simulation. So we will need some mechanism for
|
2002-08-29 18:59:37 +04:00
|
|
|
// choosing what kinds of events will be delivered to the CI. Normally,
|
2002-04-18 04:22:20 +04:00
|
|
|
// you wouldn't want to look at the log unless something is going wrong.
|
|
|
|
// At that point, you might want to open up a window to watch the debug
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// messages from one or two devices only.
|
2002-04-18 04:22:20 +04:00
|
|
|
//
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// Idea: Except for panics that require user attention to continue, it
|
|
|
|
// might be most efficient to just append log messages to a file.
|
|
|
|
// When the user wants to look at the log messages, the gui can reopen
|
|
|
|
// the file (read only), skip to the end, and look backward for a
|
|
|
|
// reasonable number of lines to display (200?). This allows it to
|
|
|
|
// skip over huge bursts of log entries without allocating memory,
|
|
|
|
// synchronizing threads, etc. for each.
|
2002-04-18 04:22:20 +04:00
|
|
|
typedef struct {
|
|
|
|
Bit8u level;
|
- add Debug Log dialog, which shows all the text output that is normally
printed to stderr in the text debugger. Also allows the user to
type (text) debugger commands directly, which also appear in the log.
- all text output in the debugger now passes through dbg_printf()
(used to be fprintf to stderr) so that in wxWindows I can redirect
it all to the wxWindows debug log screen. Added debug_fputs to
siminterface which actually sends the text to the GUI by creating
a BX_ASYNC_EVT_DBG_MSG event.
- changed prefix and msg fields of BxLogMsgEvent to const char *,
and also in args of logmsg method of siminterface.
- don't trap SIGINT in wxWindows. There are other ways to stop execution.
Also, signal handling with multiple threads is very strange and different
on different platforms.
- minor changes to fix gcc -Wall warnings in dbg_main.cc
- add a new boolean parameter BXP_DEBUG_RUNNING that tells if the debugger is
running freely or not. This is used by the wxWindows GUI to enable or
disable certain choices.
- CpuRegistersDialog has continue,stop,step buttons. When the sim is running
freely, I disable continue and step, and enable stop. When the sim stops
to wait for the user, I disable stop and enable continue and step. The
change of enables used to be triggered by actually pressing the button,
but then if you started/stopped the simulation in some other way (typing
in debug log window) the enables were never changed. Now the enables are
controlled by the value of BXP_DEBUG_RUNNING, which is set by the debug code
itself, and the buttons are enabled at the right time.
- ParamDialog::Refresh() is now virtual so that child classes can redefine
its refresh behavior.
- in safeWxStrcpy, force the last element of the array to be a 0, since
I noticed that strncpy is not guaranteed to terminate the string!
- modified: debug/dbg_main.cc debug/debug.h gui/siminterface.cc
gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
gui/wxmain.h
2002-09-15 15:21:35 +04:00
|
|
|
const char *prefix;
|
|
|
|
const char *msg;
|
2002-04-18 04:22:20 +04:00
|
|
|
} BxLogMsgEvent;
|
|
|
|
|
- add Debug Log dialog, which shows all the text output that is normally
printed to stderr in the text debugger. Also allows the user to
type (text) debugger commands directly, which also appear in the log.
- all text output in the debugger now passes through dbg_printf()
(used to be fprintf to stderr) so that in wxWindows I can redirect
it all to the wxWindows debug log screen. Added debug_fputs to
siminterface which actually sends the text to the GUI by creating
a BX_ASYNC_EVT_DBG_MSG event.
- changed prefix and msg fields of BxLogMsgEvent to const char *,
and also in args of logmsg method of siminterface.
- don't trap SIGINT in wxWindows. There are other ways to stop execution.
Also, signal handling with multiple threads is very strange and different
on different platforms.
- minor changes to fix gcc -Wall warnings in dbg_main.cc
- add a new boolean parameter BXP_DEBUG_RUNNING that tells if the debugger is
running freely or not. This is used by the wxWindows GUI to enable or
disable certain choices.
- CpuRegistersDialog has continue,stop,step buttons. When the sim is running
freely, I disable continue and step, and enable stop. When the sim stops
to wait for the user, I disable stop and enable continue and step. The
change of enables used to be triggered by actually pressing the button,
but then if you started/stopped the simulation in some other way (typing
in debug log window) the enables were never changed. Now the enables are
controlled by the value of BXP_DEBUG_RUNNING, which is set by the debug code
itself, and the buttons are enabled at the right time.
- ParamDialog::Refresh() is now virtual so that child classes can redefine
its refresh behavior.
- in safeWxStrcpy, force the last element of the array to be a 0, since
I noticed that strncpy is not guaranteed to terminate the string!
- modified: debug/dbg_main.cc debug/debug.h gui/siminterface.cc
gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
gui/wxmain.h
2002-09-15 15:21:35 +04:00
|
|
|
// Event type: BX_ASYNC_EVT_DBG_MSG (unused)
|
|
|
|
//
|
|
|
|
// Also uses BxLogMsgEvent, but this is a message to be displayed in
|
|
|
|
// the debugger history window.
|
|
|
|
|
- use setjmp() and longjmp() to quit the simulation thread cleanly.
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.
2002-08-27 22:11:13 +04:00
|
|
|
// Event type: BX_SYNC_EVT_LOG_ASK
|
|
|
|
//
|
|
|
|
// This is a synchronous version of BX_ASYNC_EVT_LOG_MSG, which is used
|
|
|
|
// when the "action=ask" setting is used. If the simulator runs into a
|
2002-08-29 18:59:37 +04:00
|
|
|
// panic, it sends a synchronous BX_SYNC_EVT_LOG_ASK to the CI to be
|
|
|
|
// displayed. The CI shows a dialog that asks if the user wants to
|
- use setjmp() and longjmp() to quit the simulation thread cleanly.
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.
2002-08-27 22:11:13 +04:00
|
|
|
// continue, quit, etc. and sends the answer back to the simulator.
|
|
|
|
// This event also uses BxLogMsgEvent.
|
2002-09-25 22:32:36 +04:00
|
|
|
enum {
|
|
|
|
BX_LOG_ASK_CHOICE_CONTINUE,
|
|
|
|
BX_LOG_ASK_CHOICE_CONTINUE_ALWAYS,
|
|
|
|
BX_LOG_ASK_CHOICE_DIE,
|
|
|
|
BX_LOG_ASK_CHOICE_DUMP_CORE,
|
|
|
|
BX_LOG_ASK_CHOICE_ENTER_DEBUG,
|
2006-01-31 22:37:56 +03:00
|
|
|
BX_LOG_ASK_N_CHOICES,
|
|
|
|
BX_LOG_NOTIFY_FAILED
|
2002-09-25 22:32:36 +04:00
|
|
|
};
|
- use setjmp() and longjmp() to quit the simulation thread cleanly.
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.
2002-08-27 22:11:13 +04:00
|
|
|
|
- add infrastructure for sending commands from the wxWindows interface to the
Bochs debugger. The Bochs debugger calls SIM->debug_get_next_command() which
does not return until a debugger command is found. The siminterface sends an
synchronous event to the wxWindows thread with a blank to be filled in with a
debugger command. wxWindows fills in the blank and sends the synchronous
event back, and the Bochs debugger interprets it as if it was typed on
the command line. For the long term I haven't decided whether to stick with
sending text strings vs. some other method.
- so far the wxWindows debugger consists of one big dialog box that shows
all the standard registers, and a working Continue, Stop, and Step button.
- modify ParamDialog so that it is more useful as a base class, by moving
some things to protected members&fields, separating out functionality
that is most likely to be replaced into virtual functions, and making it
generally more flexible. The new CpuRegistersDialog is based on
ParamDialog.
- in wxdialog.cc, continue the convention of using wxID_HELP, wxID_OK,
wxID_CANCEL, etc. for the id's of buttons, instead of wxHELP, wxOK, etc.
which are intended to be ORred together in a bit field.
- cpu/init.cc: put ifdefs around DEFPARAMs for flags in configurations
where they don't exist. Add an eflags shadow parameter that represents all
of the bits of eflags at once. There are also boolean shadow params for
each bit.
- modified files: cpu/init.cc debug/dbg_main.cc debug/debug.h
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h
2002-09-13 23:39:38 +04:00
|
|
|
// Event type: BX_SYNC_EVT_GET_DBG_COMMAND
|
|
|
|
//
|
|
|
|
// This is a synchronous event sent from the simulator to the debugger
|
|
|
|
// requesting the next action. In a text mode debugger, this would prompt
|
|
|
|
// the user for the next command. When a new command is ready, the
|
|
|
|
// synchronous event is sent back with its fields filled in.
|
|
|
|
typedef struct {
|
|
|
|
char *command; // null terminated string. allocated by debugger interface
|
|
|
|
// with new operator, freed by simulator with delete.
|
|
|
|
} BxDebugCommand;
|
|
|
|
|
|
|
|
|
|
|
|
|
2002-04-18 04:22:20 +04:00
|
|
|
// Event type: BX_EVT_TOOLBAR
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// Asynchronous event from the VGAW to the simulator, sent when the user
|
2002-04-18 04:22:20 +04:00
|
|
|
// clicks on a toolbar button. This may one day become something more
|
|
|
|
// general, like a command event, but at the moment it's only needed for
|
|
|
|
// the toolbar events.
|
|
|
|
typedef struct {
|
|
|
|
bx_toolbar_buttons button;
|
|
|
|
bool on; // for toggling buttons, on=true means the toolbar button is
|
|
|
|
// pressed. on=false means it is not pressed.
|
|
|
|
} BxToolbarEvent;
|
|
|
|
|
|
|
|
// The BxEvent structure should be used for all events. Every event has
|
|
|
|
// a type and a spot for a return code (only used for synchronous events).
|
|
|
|
typedef struct {
|
|
|
|
BxEventType type; // what kind is this?
|
|
|
|
Bit32s retcode; // sucess or failure. only used for synchronous events.
|
|
|
|
union {
|
|
|
|
BxKeyEvent key;
|
|
|
|
BxMouseEvent mouse;
|
|
|
|
BxParamEvent param;
|
|
|
|
BxLogMsgEvent logmsg;
|
|
|
|
BxToolbarEvent toolbar;
|
- add infrastructure for sending commands from the wxWindows interface to the
Bochs debugger. The Bochs debugger calls SIM->debug_get_next_command() which
does not return until a debugger command is found. The siminterface sends an
synchronous event to the wxWindows thread with a blank to be filled in with a
debugger command. wxWindows fills in the blank and sends the synchronous
event back, and the Bochs debugger interprets it as if it was typed on
the command line. For the long term I haven't decided whether to stick with
sending text strings vs. some other method.
- so far the wxWindows debugger consists of one big dialog box that shows
all the standard registers, and a working Continue, Stop, and Step button.
- modify ParamDialog so that it is more useful as a base class, by moving
some things to protected members&fields, separating out functionality
that is most likely to be replaced into virtual functions, and making it
generally more flexible. The new CpuRegistersDialog is based on
ParamDialog.
- in wxdialog.cc, continue the convention of using wxID_HELP, wxID_OK,
wxID_CANCEL, etc. for the id's of buttons, instead of wxHELP, wxOK, etc.
which are intended to be ORred together in a bit field.
- cpu/init.cc: put ifdefs around DEFPARAMs for flags in configurations
where they don't exist. Add an eflags shadow parameter that represents all
of the bits of eflags at once. There are also boolean shadow params for
each bit.
- modified files: cpu/init.cc debug/dbg_main.cc debug/debug.h
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h
2002-09-13 23:39:38 +04:00
|
|
|
BxDebugCommand debugcmd;
|
2002-04-18 04:22:20 +04:00
|
|
|
} u;
|
|
|
|
} BxEvent;
|
|
|
|
|
2001-06-16 03:52:34 +04:00
|
|
|
|
2001-06-16 23:29:59 +04:00
|
|
|
////////////////////////////////////////////////////////////////////
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// parameter classes: bx_param_c and family
|
|
|
|
////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
|
|
|
// All variables that can be configured through the CI are declared as
|
|
|
|
// "parameters" or objects of type bx_param_*. There is a bx_param_*
|
|
|
|
// class for each type of data that the user would need to see and
|
|
|
|
// edit, e.g. integer, boolean, enum, string, filename, or list of
|
|
|
|
// other parameters. The purpose of the bx_param_* class, in addition
|
|
|
|
// to storing the parameter's value, is to hold the name, description,
|
|
|
|
// and constraints on the value. The bx_param_* class should hold
|
2002-08-29 18:59:37 +04:00
|
|
|
// everything that the CI would need to display the value and allow
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// the user to modify it. For integer parameters, the minimum and
|
|
|
|
// maximum allowed value can be defined, and the base in which it
|
|
|
|
// should be displayed and interpreted. For enums, the
|
|
|
|
// bx_param_enum_c structure includes the list of values which the
|
|
|
|
// parameter can have.
|
|
|
|
//
|
|
|
|
// Also, some parameter classes support get/set callback functions to
|
|
|
|
// allow arbitrary code to be executed when the parameter is get/set.
|
|
|
|
// An example of where this is useful: if you disable the NE2K card,
|
|
|
|
// the set() handler for that parameter can tell the user interface
|
|
|
|
// that the NE2K's irq, I/O address, and mac address should be
|
|
|
|
// disabled (greyed out, hidden, or made inaccessible). The get/set
|
|
|
|
// methods can also check if the set() value is acceptable using
|
|
|
|
// whatever means and override it.
|
|
|
|
//
|
|
|
|
// The parameter concept is similar to the use of parameters in JavaBeans.
|
|
|
|
|
2002-09-03 12:46:30 +04:00
|
|
|
class bx_object_c;
|
|
|
|
class bx_param_c;
|
|
|
|
class bx_param_num_c;
|
|
|
|
class bx_param_enum_c;
|
|
|
|
class bx_param_bool_c;
|
|
|
|
class bx_param_string_c;
|
|
|
|
class bx_param_filename_c;
|
|
|
|
class bx_list_c;
|
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
class BOCHSAPI bx_object_c {
|
2001-06-16 03:52:34 +04:00
|
|
|
private:
|
2006-03-08 21:10:41 +03:00
|
|
|
Bit32u id;
|
2002-04-18 04:22:20 +04:00
|
|
|
bx_objtype type;
|
2001-06-16 03:52:34 +04:00
|
|
|
protected:
|
2006-05-30 21:01:27 +04:00
|
|
|
void set_type(bx_objtype _type) { type = _type; }
|
2001-06-16 03:52:34 +04:00
|
|
|
public:
|
2006-05-30 21:01:27 +04:00
|
|
|
bx_object_c(Bit32u _id): id(_id), type(BXT_OBJECT) {}
|
2006-05-30 02:33:38 +04:00
|
|
|
virtual ~bx_object_c() {}
|
2006-05-30 21:01:27 +04:00
|
|
|
Bit32u get_id() const { return id; }
|
|
|
|
Bit8u get_type() const { return type; }
|
2001-06-16 03:52:34 +04:00
|
|
|
};
|
|
|
|
|
2006-05-23 01:29:54 +04:00
|
|
|
#define BASE_DEC 10
|
|
|
|
#define BASE_HEX 16
|
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
class BOCHSAPI bx_param_c : public bx_object_c {
|
2002-11-15 21:31:55 +03:00
|
|
|
BOCHSAPI_CYGONLY static const char *default_text_format;
|
2001-06-21 18:37:55 +04:00
|
|
|
protected:
|
2006-02-17 00:44:17 +03:00
|
|
|
bx_list_c *parent;
|
2001-06-16 03:52:34 +04:00
|
|
|
char *name;
|
|
|
|
char *description;
|
2003-08-30 15:21:56 +04:00
|
|
|
char *label; // label string for text menus and gui dialogs
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
const char *text_format; // printf format string. %d for ints, %s for strings, etc.
|
2006-02-19 18:43:03 +03:00
|
|
|
const char *long_text_format; // printf format string. %d for ints, %s for strings, etc.
|
2001-06-18 18:11:55 +04:00
|
|
|
char *ask_format; // format string for asking for a new value
|
2004-05-30 12:28:52 +04:00
|
|
|
char *group_name; // name of the group the param belongs to
|
2001-06-18 18:11:55 +04:00
|
|
|
int runtime_param;
|
2001-06-21 18:37:55 +04:00
|
|
|
int enabled;
|
2001-06-16 03:52:34 +04:00
|
|
|
public:
|
2006-05-30 21:01:27 +04:00
|
|
|
bx_param_c(Bit32u id, const char *name, const char *description);
|
|
|
|
bx_param_c(Bit32u id, const char *name, const char *label, const char *description);
|
2006-05-30 02:33:38 +04:00
|
|
|
virtual ~bx_param_c();
|
2006-02-18 19:53:18 +03:00
|
|
|
bx_param_c *get_parent() { return (bx_param_c *) parent; }
|
2006-02-24 15:05:24 +03:00
|
|
|
int get_param_path(char *path_out, int maxlen);
|
2006-02-18 19:53:18 +03:00
|
|
|
void set_format(const char *format) {text_format = format;}
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *get_format() const {return text_format;}
|
2006-02-19 18:43:03 +03:00
|
|
|
void set_long_format(const char *format) {long_text_format = format;}
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *get_long_format() const {return long_text_format;}
|
2006-06-04 11:55:34 +04:00
|
|
|
void set_ask_format(const char *format);
|
|
|
|
const char *get_ask_format() const {return ask_format;}
|
2006-05-30 21:01:27 +04:00
|
|
|
void set_label(const char *text);
|
|
|
|
void set_description(const char *text);
|
|
|
|
const char *get_label() const {return label;}
|
2006-02-18 19:53:18 +03:00
|
|
|
void set_runtime_param(int val) { runtime_param = val; }
|
|
|
|
int get_runtime_param() { return runtime_param; }
|
2006-06-05 23:06:36 +04:00
|
|
|
void set_group(const char *group);
|
|
|
|
const char *get_group() const {return group_name;}
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *get_name() const { return name; }
|
2006-05-30 21:01:27 +04:00
|
|
|
const char *get_description() const { return description; }
|
2006-05-30 02:33:38 +04:00
|
|
|
int get_enabled() const { return enabled; }
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void set_enabled(int enabled) { this->enabled = enabled; }
|
|
|
|
virtual void reset() {}
|
2006-05-30 02:33:38 +04:00
|
|
|
int getint() const {return -1;}
|
2006-02-18 19:53:18 +03:00
|
|
|
static const char* set_default_format(const char *f);
|
|
|
|
static const char *get_default_format() { return default_text_format; }
|
|
|
|
virtual bx_list_c *get_dependent_list() { return NULL; }
|
2004-01-29 21:50:33 +03:00
|
|
|
#if BX_USE_TEXTCONFIG
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void text_print(FILE *fp) {}
|
|
|
|
virtual int text_ask(FILE *fpin, FILE *fpout) {return -1;}
|
2001-06-18 18:11:55 +04:00
|
|
|
#endif
|
2001-06-16 23:29:59 +04:00
|
|
|
};
|
|
|
|
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
typedef Bit64s (*param_event_handler)(class bx_param_c *, int set, Bit64s val);
|
2006-05-27 18:02:34 +04:00
|
|
|
#if BX_SUPPORT_SAVE_RESTORE
|
|
|
|
typedef Bit64s (*param_sr_handler)(void *devptr, class bx_param_c *, Bit64s val);
|
|
|
|
#endif
|
2003-08-10 02:17:38 +04:00
|
|
|
typedef int (*param_enable_handler)(class bx_param_c *, int en);
|
2001-06-16 03:52:34 +04:00
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
class BOCHSAPI bx_param_num_c : public bx_param_c {
|
2002-11-15 21:31:55 +03:00
|
|
|
BOCHSAPI_CYGONLY static Bit32u default_base;
|
2002-09-17 08:47:55 +04:00
|
|
|
// The dependent_list is initialized to NULL. If dependent_list is modified
|
|
|
|
// to point to a bx_list_c of other parameters, the set() method of
|
|
|
|
// bx_param_bool_c will enable those parameters when this bool is true, and
|
|
|
|
// disable them when this bool is false.
|
|
|
|
bx_list_c *dependent_list;
|
2006-02-18 19:53:18 +03:00
|
|
|
void update_dependents();
|
2001-06-20 18:01:39 +04:00
|
|
|
protected:
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit64s min, max, initial_val;
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
union _uval_ {
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit64s number; // used by bx_param_num_c
|
|
|
|
Bit64s *p64bit; // used by bx_shadow_num_c
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit32s *p32bit; // used by bx_shadow_num_c
|
|
|
|
Bit16s *p16bit; // used by bx_shadow_num_c
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit8s *p8bit; // used by bx_shadow_num_c
|
2002-10-25 15:44:41 +04:00
|
|
|
bx_bool *pbool; // used by bx_shadow_bool_c
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
} val;
|
2001-06-17 03:08:32 +04:00
|
|
|
param_event_handler handler;
|
2006-05-27 18:02:34 +04:00
|
|
|
#if BX_SUPPORT_SAVE_RESTORE
|
|
|
|
void *sr_devptr;
|
|
|
|
param_sr_handler save_handler;
|
|
|
|
param_sr_handler restore_handler;
|
|
|
|
#endif
|
2003-08-10 02:17:38 +04:00
|
|
|
param_enable_handler enable_handler;
|
2001-06-18 18:11:55 +04:00
|
|
|
int base;
|
2003-09-06 02:07:54 +04:00
|
|
|
Bit32u options;
|
2006-04-22 22:14:55 +04:00
|
|
|
bx_bool is_shadow;
|
2001-06-16 03:52:34 +04:00
|
|
|
public:
|
2003-09-06 02:07:54 +04:00
|
|
|
enum {
|
|
|
|
// When a bx_param_num_c is displayed in dialog, USE_SPIN_CONTROL controls
|
|
|
|
// whether a spin control should be used instead of a simple text control.
|
2004-02-07 01:28:00 +03:00
|
|
|
USE_SPIN_CONTROL = (1<<0)
|
2003-09-06 02:07:54 +04:00
|
|
|
} bx_numopt_bits;
|
2006-02-18 19:53:18 +03:00
|
|
|
bx_param_num_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
2006-05-30 21:01:27 +04:00
|
|
|
const char *label,
|
|
|
|
const char *description,
|
2006-04-22 22:14:55 +04:00
|
|
|
Bit64s min, Bit64s max, Bit64s initial_val,
|
|
|
|
bx_bool is_shadow = 0);
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void reset();
|
|
|
|
void set_handler(param_event_handler handler);
|
2006-05-27 18:02:34 +04:00
|
|
|
#if BX_SUPPORT_SAVE_RESTORE
|
|
|
|
void set_sr_handlers(void *devptr, param_sr_handler save, param_sr_handler restore);
|
|
|
|
#endif
|
2006-02-18 19:53:18 +03:00
|
|
|
void set_enable_handler(param_enable_handler handler);
|
|
|
|
virtual bx_list_c *get_dependent_list() { return dependent_list; }
|
|
|
|
void set_dependent_list(bx_list_c *l);
|
|
|
|
virtual void set_enabled(int enabled);
|
|
|
|
virtual Bit32s get() { return (Bit32s) get64(); }
|
|
|
|
virtual Bit64s get64();
|
|
|
|
virtual void set(Bit64s val);
|
|
|
|
void set_base(int base) { this->base = base; }
|
|
|
|
void set_initial_val(Bit64s initial_val);
|
2006-05-30 21:01:27 +04:00
|
|
|
int get_base() const { return base; }
|
2006-02-18 19:53:18 +03:00
|
|
|
void set_range(Bit64u min, Bit64u max);
|
|
|
|
Bit64s get_min() { return min; }
|
|
|
|
Bit64s get_max() { return max; }
|
|
|
|
static Bit32u set_default_base(Bit32u val);
|
|
|
|
static Bit32u get_default_base() { return default_base; }
|
|
|
|
void set_options(Bit32u options) { this->options = options; }
|
2006-05-30 21:01:27 +04:00
|
|
|
Bit32u get_options() const { return options; }
|
2004-01-29 21:50:33 +03:00
|
|
|
#if BX_USE_TEXTCONFIG
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void text_print(FILE *fp);
|
|
|
|
virtual int text_ask(FILE *fpin, FILE *fpout);
|
2001-06-18 18:11:55 +04:00
|
|
|
#endif
|
2001-06-16 23:29:59 +04:00
|
|
|
};
|
|
|
|
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
// a bx_shadow_num_c is like a bx_param_num_c except that it doesn't
|
2002-09-11 07:53:48 +04:00
|
|
|
// store the actual value with its data. Instead, it uses val.p32bit
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
// to keep a pointer to the actual data. This is used to register
|
2005-07-31 18:49:45 +04:00
|
|
|
// existing variables as parameters, without having to access it via
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
// set/get methods.
|
2002-10-25 01:07:56 +04:00
|
|
|
class BOCHSAPI bx_shadow_num_c : public bx_param_num_c {
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit8u varsize; // must be 64, 32, 16, or 8
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit8u lowbit; // range of bits associated with this param
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit64u mask; // mask is ANDed with value before it is returned from get
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
public:
|
2006-03-07 23:32:07 +03:00
|
|
|
bx_shadow_num_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit64s *ptr_to_real_val,
|
2006-05-23 01:29:54 +04:00
|
|
|
int base = BASE_DEC,
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit8u highbit = 63,
|
|
|
|
Bit8u lowbit = 0);
|
2006-03-07 23:32:07 +03:00
|
|
|
bx_shadow_num_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit64u *ptr_to_real_val,
|
2006-05-23 01:29:54 +04:00
|
|
|
int base = BASE_DEC,
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit8u highbit = 63,
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit8u lowbit = 0);
|
2006-03-07 23:32:07 +03:00
|
|
|
bx_shadow_num_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit32s *ptr_to_real_val,
|
2006-05-23 01:29:54 +04:00
|
|
|
int base = BASE_DEC,
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit8u highbit = 31,
|
|
|
|
Bit8u lowbit = 0);
|
2006-03-07 20:54:27 +03:00
|
|
|
bx_shadow_num_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
2006-03-07 20:54:27 +03:00
|
|
|
Bit32u *ptr_to_real_val,
|
2006-05-23 01:29:54 +04:00
|
|
|
int base = BASE_DEC,
|
2006-03-07 20:54:27 +03:00
|
|
|
Bit8u highbit = 31,
|
|
|
|
Bit8u lowbit = 0);
|
2006-03-07 23:32:07 +03:00
|
|
|
bx_shadow_num_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit16s *ptr_to_real_val,
|
2006-05-23 01:29:54 +04:00
|
|
|
int base = BASE_DEC,
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit8u highbit = 15,
|
|
|
|
Bit8u lowbit = 0);
|
2006-03-07 23:32:07 +03:00
|
|
|
bx_shadow_num_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit16u *ptr_to_real_val,
|
2006-05-23 01:29:54 +04:00
|
|
|
int base = BASE_DEC,
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit8u highbit = 15,
|
|
|
|
Bit8u lowbit = 0);
|
2006-03-07 23:32:07 +03:00
|
|
|
bx_shadow_num_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit8s *ptr_to_real_val,
|
2006-05-23 01:29:54 +04:00
|
|
|
int base = BASE_DEC,
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit8u highbit = 7,
|
|
|
|
Bit8u lowbit = 0);
|
2006-03-07 23:32:07 +03:00
|
|
|
bx_shadow_num_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit8u *ptr_to_real_val,
|
2006-05-23 01:29:54 +04:00
|
|
|
int base = BASE_DEC,
|
- upgrade bx_param_num to use 64 bit values, so that I could make
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
2002-10-16 23:39:27 +04:00
|
|
|
Bit8u highbit = 7,
|
|
|
|
Bit8u lowbit = 0);
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual Bit64s get64();
|
|
|
|
virtual void set(Bit64s val);
|
|
|
|
virtual void reset();
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
};
|
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
class BOCHSAPI bx_param_bool_c : public bx_param_num_c {
|
2002-09-03 12:46:30 +04:00
|
|
|
// many boolean variables are used to enable/disable modules. In the
|
|
|
|
// user interface, the enable variable should enable/disable all the
|
|
|
|
// other parameters associated with that module.
|
2001-06-20 18:01:39 +04:00
|
|
|
public:
|
2006-02-18 19:53:18 +03:00
|
|
|
bx_param_bool_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
2006-05-30 21:01:27 +04:00
|
|
|
const char *label,
|
|
|
|
const char *description,
|
2006-05-01 22:24:47 +04:00
|
|
|
Bit64s initial_val,
|
|
|
|
bx_bool is_shadow = 0);
|
2004-01-29 21:50:33 +03:00
|
|
|
#if BX_USE_TEXTCONFIG
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void text_print(FILE *fp);
|
|
|
|
virtual int text_ask(FILE *fpin, FILE *fpout);
|
2001-06-20 18:01:39 +04:00
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
// a bx_shadow_bool_c is a shadow param based on bx_param_bool_c.
|
2002-10-25 01:07:56 +04:00
|
|
|
class BOCHSAPI bx_shadow_bool_c : public bx_param_bool_c {
|
2002-09-11 07:53:48 +04:00
|
|
|
// each bit of a bitfield can be a separate value. bitnum tells which
|
|
|
|
// bit is used. get/set will only modify that bit.
|
|
|
|
Bit8u bitnum;
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
public:
|
2006-03-07 20:54:27 +03:00
|
|
|
bx_shadow_bool_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
2006-05-30 21:01:27 +04:00
|
|
|
const char *label,
|
2006-03-07 20:54:27 +03:00
|
|
|
bx_bool *ptr_to_real_val,
|
|
|
|
Bit8u bitnum = 0);
|
2006-05-14 19:47:37 +04:00
|
|
|
bx_shadow_bool_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
2006-05-14 19:47:37 +04:00
|
|
|
bx_bool *ptr_to_real_val,
|
|
|
|
Bit8u bitnum = 0);
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual Bit64s get64();
|
|
|
|
virtual void set(Bit64s val);
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
class BOCHSAPI bx_param_enum_c : public bx_param_num_c {
|
2001-06-20 18:01:39 +04:00
|
|
|
char **choices;
|
|
|
|
public:
|
2006-02-19 18:43:03 +03:00
|
|
|
bx_param_enum_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
2006-05-30 21:01:27 +04:00
|
|
|
const char *label,
|
|
|
|
const char *description,
|
2006-02-19 18:43:03 +03:00
|
|
|
char **choices,
|
|
|
|
Bit64s initial_val,
|
|
|
|
Bit64s value_base = 0);
|
2006-02-18 19:53:18 +03:00
|
|
|
char *get_choice(int n) { return choices[n]; }
|
2006-02-22 00:35:09 +03:00
|
|
|
char *get_selected() { return choices[val.number - min]; }
|
2006-02-18 19:53:18 +03:00
|
|
|
int find_by_name(const char *string);
|
2006-04-07 00:42:51 +04:00
|
|
|
bx_bool set_by_name(const char *string);
|
2004-01-29 21:50:33 +03:00
|
|
|
#if BX_USE_TEXTCONFIG
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void text_print(FILE *fp);
|
|
|
|
virtual int text_ask(FILE *fpin, FILE *fpout);
|
2001-06-20 18:01:39 +04:00
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
2006-03-13 21:55:53 +03:00
|
|
|
typedef const char* (*param_string_event_handler)(class bx_param_string_c *, int set, const char *val, int maxlen);
|
2001-06-16 23:29:59 +04:00
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
class BOCHSAPI bx_param_string_c : public bx_param_c {
|
2001-06-16 23:29:59 +04:00
|
|
|
int maxsize;
|
|
|
|
char *val, *initial_val;
|
|
|
|
param_string_event_handler handler;
|
2003-08-10 02:17:38 +04:00
|
|
|
param_enable_handler enable_handler;
|
2001-06-21 23:27:05 +04:00
|
|
|
bx_param_num_c *options;
|
|
|
|
char separator;
|
2001-06-16 23:29:59 +04:00
|
|
|
public:
|
2001-06-21 23:27:05 +04:00
|
|
|
enum {
|
- fixed up ParamDialog to correctly handle "trees" of parameters. A
bx_list_c can now be displayed as either a wxStaticBox with the
child parameters inside, or as a wxNotebook with each child
parameter in a separate tab. (The children can also be lists of
course.) The default display is the wxStaticBox type, but if you
set the option bit bx_list_c::USE_TAB_WINDOW in the list,
ParamDialog will use the wxNotebook display instead.
- to get the param trees working, I created a new struct
AddParamContext, which is passed to AddParam(). This struct is
critical when AddParam calls itself recursively to display lists
within lists.
- use the wxNotebook display feature for the ATA0,1,2,3 controller
dialog box. Now instead of being hundreds of pixels tall, it is
reasonable height with three different tabs. This fixed bug
#619074: "wx: ATA interface editor too tall" and was the whole
reason I started messing with this at all.
plus some minor cleanups
- when I added the enum constant bx_list_c::USE_TAB_WINDOW, I also
removed the BX_ prefix from all the other enum constants that are
used in parameter options in siminterface.cc. Since these constants
are enums within a class, there is no possibility of namespace
conflicts so the prefix is not needed.
- added wxADJUST_MINSIZE to all wxChoice controls, since that tells
wxWindows to adjust its size to the length of the longest string.
- instead of calling SetSize or SetSizeHints on every textcontrol with
a hardcoded width, I am using just two wxSize specifications for
everything: either normalTextSize or longTextSize.
- edit names of a few menus and params. For example now instead of
the tab saying "Master ATA device on channel 0" it will say
"First HD/CD on channel 0".
Modified Files:
main.cc gui/control.cc gui/gui.cc gui/siminterface.cc gui/siminterface.h
gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
2002-10-06 06:37:28 +04:00
|
|
|
RAW_BYTES = 1, // use binary text editor, like MAC addr
|
|
|
|
IS_FILENAME = 2, // 1=yes it's a filename, 0=not a filename.
|
|
|
|
// Some guis have a file browser. This
|
|
|
|
// bit suggests that they use it.
|
2006-08-30 00:10:27 +04:00
|
|
|
SAVE_FILE_DIALOG = 4, // Use save dialog opposed to open file dialog
|
|
|
|
SELECT_FOLDER_DLG = 8 // Use folder selection dialog
|
2001-06-21 23:27:05 +04:00
|
|
|
} bx_string_opt_bits;
|
2006-02-18 19:53:18 +03:00
|
|
|
bx_param_string_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
2006-05-30 21:01:27 +04:00
|
|
|
const char *label,
|
|
|
|
const char *description,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *initial_val,
|
2006-02-17 00:44:17 +03:00
|
|
|
int maxsize=-1);
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual ~bx_param_string_c();
|
|
|
|
virtual void reset();
|
|
|
|
void set_handler(param_string_event_handler handler);
|
|
|
|
void set_enable_handler(param_enable_handler handler);
|
|
|
|
virtual void set_enabled(int enabled);
|
|
|
|
Bit32s get(char *buf, int len);
|
|
|
|
char *getptr() {return val; }
|
2006-03-13 21:55:53 +03:00
|
|
|
void set(const char *buf);
|
2006-02-18 19:53:18 +03:00
|
|
|
bx_bool equals(const char *buf);
|
|
|
|
bx_param_num_c *get_options() { return options; }
|
|
|
|
void set_separator(char sep) {separator = sep; }
|
2006-05-30 02:33:38 +04:00
|
|
|
char get_separator() const {return separator; }
|
|
|
|
int get_maxsize() const {return maxsize; }
|
|
|
|
void set_initial_val(const char *buf);
|
2004-01-29 21:50:33 +03:00
|
|
|
#if BX_USE_TEXTCONFIG
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void text_print(FILE *fp);
|
|
|
|
virtual int text_ask(FILE *fpin, FILE *fpout);
|
2001-06-18 18:11:55 +04:00
|
|
|
#endif
|
2001-06-16 03:52:34 +04:00
|
|
|
};
|
|
|
|
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// Declare a filename class. It is identical to a string, except that
|
2002-04-18 04:22:20 +04:00
|
|
|
// it initializes the options differently. This is just a shortcut
|
- fixed up ParamDialog to correctly handle "trees" of parameters. A
bx_list_c can now be displayed as either a wxStaticBox with the
child parameters inside, or as a wxNotebook with each child
parameter in a separate tab. (The children can also be lists of
course.) The default display is the wxStaticBox type, but if you
set the option bit bx_list_c::USE_TAB_WINDOW in the list,
ParamDialog will use the wxNotebook display instead.
- to get the param trees working, I created a new struct
AddParamContext, which is passed to AddParam(). This struct is
critical when AddParam calls itself recursively to display lists
within lists.
- use the wxNotebook display feature for the ATA0,1,2,3 controller
dialog box. Now instead of being hundreds of pixels tall, it is
reasonable height with three different tabs. This fixed bug
#619074: "wx: ATA interface editor too tall" and was the whole
reason I started messing with this at all.
plus some minor cleanups
- when I added the enum constant bx_list_c::USE_TAB_WINDOW, I also
removed the BX_ prefix from all the other enum constants that are
used in parameter options in siminterface.cc. Since these constants
are enums within a class, there is no possibility of namespace
conflicts so the prefix is not needed.
- added wxADJUST_MINSIZE to all wxChoice controls, since that tells
wxWindows to adjust its size to the length of the longest string.
- instead of calling SetSize or SetSizeHints on every textcontrol with
a hardcoded width, I am using just two wxSize specifications for
everything: either normalTextSize or longTextSize.
- edit names of a few menus and params. For example now instead of
the tab saying "Master ATA device on channel 0" it will say
"First HD/CD on channel 0".
Modified Files:
main.cc gui/control.cc gui/gui.cc gui/siminterface.cc gui/siminterface.h
gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
2002-10-06 06:37:28 +04:00
|
|
|
// for declaring a string param and setting the options with IS_FILENAME.
|
2002-10-25 01:07:56 +04:00
|
|
|
class BOCHSAPI bx_param_filename_c : public bx_param_string_c {
|
2002-04-18 04:22:20 +04:00
|
|
|
public:
|
2006-02-18 19:53:18 +03:00
|
|
|
bx_param_filename_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
2006-05-30 21:01:27 +04:00
|
|
|
const char *label,
|
|
|
|
const char *description,
|
|
|
|
const char *initial_val,
|
2006-02-17 00:44:17 +03:00
|
|
|
int maxsize=-1);
|
2002-04-18 04:22:20 +04:00
|
|
|
};
|
|
|
|
|
2006-04-15 18:05:18 +04:00
|
|
|
#if BX_SUPPORT_SAVE_RESTORE
|
|
|
|
class BOCHSAPI bx_shadow_data_c : public bx_param_c {
|
|
|
|
Bit32u data_size;
|
|
|
|
Bit8u *data_ptr;
|
|
|
|
public:
|
|
|
|
bx_shadow_data_c(bx_param_c *parent,
|
2006-05-30 02:33:38 +04:00
|
|
|
const char *name,
|
2006-04-15 18:05:18 +04:00
|
|
|
Bit8u *ptr_to_data,
|
|
|
|
Bit32u data_size);
|
|
|
|
Bit8u *getptr() {return data_ptr;}
|
2006-05-30 21:01:27 +04:00
|
|
|
Bit32u get_size() const {return data_size;}
|
2006-04-15 18:05:18 +04:00
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
2006-02-17 00:44:17 +03:00
|
|
|
#define BX_DEFAULT_LIST_SIZE 6
|
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
class BOCHSAPI bx_list_c : public bx_param_c {
|
2006-02-17 00:44:17 +03:00
|
|
|
protected:
|
2001-06-18 18:11:55 +04:00
|
|
|
// just a list of bx_param_c objects. size tells current number of
|
|
|
|
// objects in the list, and maxsize tells how many list items are
|
|
|
|
// allocated in the constructor.
|
|
|
|
bx_param_c **list;
|
|
|
|
int size, maxsize;
|
|
|
|
// options is a bit field whose bits are defined by bx_listopt_bits ORed
|
|
|
|
// together. Options is a bx_param so that if necessary the bx_list could
|
|
|
|
// install a handler to cause get/set of options to have side effects.
|
|
|
|
bx_param_num_c *options;
|
|
|
|
// for a menu, the value of choice before the call to "ask" is default.
|
|
|
|
// After ask, choice holds the value that the user chose. Choice defaults
|
|
|
|
// to 1 in the constructor.
|
|
|
|
bx_param_num_c *choice;
|
|
|
|
// title of the menu or series
|
|
|
|
bx_param_string_c *title;
|
2006-02-18 19:53:18 +03:00
|
|
|
void init(const char *list_title);
|
2001-06-16 03:52:34 +04:00
|
|
|
public:
|
2001-06-18 18:11:55 +04:00
|
|
|
enum {
|
|
|
|
// When a bx_list_c is displayed as a menu, SHOW_PARENT controls whether or
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// not the menu shows a "Return to parent menu" choice or not.
|
- fixed up ParamDialog to correctly handle "trees" of parameters. A
bx_list_c can now be displayed as either a wxStaticBox with the
child parameters inside, or as a wxNotebook with each child
parameter in a separate tab. (The children can also be lists of
course.) The default display is the wxStaticBox type, but if you
set the option bit bx_list_c::USE_TAB_WINDOW in the list,
ParamDialog will use the wxNotebook display instead.
- to get the param trees working, I created a new struct
AddParamContext, which is passed to AddParam(). This struct is
critical when AddParam calls itself recursively to display lists
within lists.
- use the wxNotebook display feature for the ATA0,1,2,3 controller
dialog box. Now instead of being hundreds of pixels tall, it is
reasonable height with three different tabs. This fixed bug
#619074: "wx: ATA interface editor too tall" and was the whole
reason I started messing with this at all.
plus some minor cleanups
- when I added the enum constant bx_list_c::USE_TAB_WINDOW, I also
removed the BX_ prefix from all the other enum constants that are
used in parameter options in siminterface.cc. Since these constants
are enums within a class, there is no possibility of namespace
conflicts so the prefix is not needed.
- added wxADJUST_MINSIZE to all wxChoice controls, since that tells
wxWindows to adjust its size to the length of the longest string.
- instead of calling SetSize or SetSizeHints on every textcontrol with
a hardcoded width, I am using just two wxSize specifications for
everything: either normalTextSize or longTextSize.
- edit names of a few menus and params. For example now instead of
the tab saying "Master ATA device on channel 0" it will say
"First HD/CD on channel 0".
Modified Files:
main.cc gui/control.cc gui/gui.cc gui/siminterface.cc gui/siminterface.h
gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
2002-10-06 06:37:28 +04:00
|
|
|
SHOW_PARENT = (1<<0),
|
2001-06-18 18:11:55 +04:00
|
|
|
// Some lists are best displayed shown as menus, others as a series of
|
- fixed up ParamDialog to correctly handle "trees" of parameters. A
bx_list_c can now be displayed as either a wxStaticBox with the
child parameters inside, or as a wxNotebook with each child
parameter in a separate tab. (The children can also be lists of
course.) The default display is the wxStaticBox type, but if you
set the option bit bx_list_c::USE_TAB_WINDOW in the list,
ParamDialog will use the wxNotebook display instead.
- to get the param trees working, I created a new struct
AddParamContext, which is passed to AddParam(). This struct is
critical when AddParam calls itself recursively to display lists
within lists.
- use the wxNotebook display feature for the ATA0,1,2,3 controller
dialog box. Now instead of being hundreds of pixels tall, it is
reasonable height with three different tabs. This fixed bug
#619074: "wx: ATA interface editor too tall" and was the whole
reason I started messing with this at all.
plus some minor cleanups
- when I added the enum constant bx_list_c::USE_TAB_WINDOW, I also
removed the BX_ prefix from all the other enum constants that are
used in parameter options in siminterface.cc. Since these constants
are enums within a class, there is no possibility of namespace
conflicts so the prefix is not needed.
- added wxADJUST_MINSIZE to all wxChoice controls, since that tells
wxWindows to adjust its size to the length of the longest string.
- instead of calling SetSize or SetSizeHints on every textcontrol with
a hardcoded width, I am using just two wxSize specifications for
everything: either normalTextSize or longTextSize.
- edit names of a few menus and params. For example now instead of
the tab saying "Master ATA device on channel 0" it will say
"First HD/CD on channel 0".
Modified Files:
main.cc gui/control.cc gui/gui.cc gui/siminterface.cc gui/siminterface.h
gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
2002-10-06 06:37:28 +04:00
|
|
|
// related questions. This bit suggests to the CI that the series of
|
|
|
|
// questions format is preferred.
|
|
|
|
SERIES_ASK = (1<<1),
|
2003-08-23 19:28:06 +04:00
|
|
|
// When a bx_list_c is displayed in a dialog, USE_TAB_WINDOW suggests
|
- fixed up ParamDialog to correctly handle "trees" of parameters. A
bx_list_c can now be displayed as either a wxStaticBox with the
child parameters inside, or as a wxNotebook with each child
parameter in a separate tab. (The children can also be lists of
course.) The default display is the wxStaticBox type, but if you
set the option bit bx_list_c::USE_TAB_WINDOW in the list,
ParamDialog will use the wxNotebook display instead.
- to get the param trees working, I created a new struct
AddParamContext, which is passed to AddParam(). This struct is
critical when AddParam calls itself recursively to display lists
within lists.
- use the wxNotebook display feature for the ATA0,1,2,3 controller
dialog box. Now instead of being hundreds of pixels tall, it is
reasonable height with three different tabs. This fixed bug
#619074: "wx: ATA interface editor too tall" and was the whole
reason I started messing with this at all.
plus some minor cleanups
- when I added the enum constant bx_list_c::USE_TAB_WINDOW, I also
removed the BX_ prefix from all the other enum constants that are
used in parameter options in siminterface.cc. Since these constants
are enums within a class, there is no possibility of namespace
conflicts so the prefix is not needed.
- added wxADJUST_MINSIZE to all wxChoice controls, since that tells
wxWindows to adjust its size to the length of the longest string.
- instead of calling SetSize or SetSizeHints on every textcontrol with
a hardcoded width, I am using just two wxSize specifications for
everything: either normalTextSize or longTextSize.
- edit names of a few menus and params. For example now instead of
the tab saying "Master ATA device on channel 0" it will say
"First HD/CD on channel 0".
Modified Files:
main.cc gui/control.cc gui/gui.cc gui/siminterface.cc gui/siminterface.h
gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
2002-10-06 06:37:28 +04:00
|
|
|
// to the CI that each item in the list should be shown as a separate
|
|
|
|
// tab. This would be most appropriate when each item is another list
|
|
|
|
// of parameters.
|
2003-08-23 19:28:06 +04:00
|
|
|
USE_TAB_WINDOW = (1<<2),
|
|
|
|
// When a bx_list_c is displayed in a dialog, the list name is used as the
|
|
|
|
// label of the group box if USE_BOX_TITLE is set. This is only necessary if
|
|
|
|
// more than one list appears in a dialog box.
|
2004-05-30 12:28:52 +04:00
|
|
|
USE_BOX_TITLE = (1<<3),
|
|
|
|
// When a bx_list_c is displayed as a menu, SHOW_GROUP_NAME controls whether
|
|
|
|
// or not the name of group the item belongs to is added to the name of the
|
|
|
|
// item (used in the runtime menu).
|
|
|
|
SHOW_GROUP_NAME = (1<<4)
|
2001-06-18 18:11:55 +04:00
|
|
|
} bx_listopt_bits;
|
2006-03-07 23:32:07 +03:00
|
|
|
bx_list_c(bx_param_c *parent, int maxsize = BX_DEFAULT_LIST_SIZE);
|
2006-05-30 02:33:38 +04:00
|
|
|
bx_list_c(bx_param_c *parent, const char *name, int maxsize = BX_DEFAULT_LIST_SIZE);
|
|
|
|
bx_list_c(bx_param_c *parent, const char *name, char *title, int maxsize = BX_DEFAULT_LIST_SIZE);
|
|
|
|
bx_list_c(bx_param_c *parent, const char *name, char *title, bx_param_c **init_list);
|
2001-12-22 23:58:25 +03:00
|
|
|
virtual ~bx_list_c();
|
2006-02-18 19:53:18 +03:00
|
|
|
bx_list_c *clone();
|
|
|
|
void add(bx_param_c *param);
|
|
|
|
bx_param_c *get(int index);
|
|
|
|
bx_param_c *get_by_name(const char *name);
|
2006-05-30 21:01:27 +04:00
|
|
|
int get_size() const { return size; }
|
2006-02-18 19:53:18 +03:00
|
|
|
bx_param_num_c *get_options() { return options; }
|
|
|
|
bx_param_num_c *get_choice() { return choice; }
|
|
|
|
bx_param_string_c *get_title() { return title; }
|
|
|
|
void set_parent(bx_param_c *newparent);
|
|
|
|
bx_param_c *get_parent() { return parent; }
|
|
|
|
virtual void reset();
|
2006-09-07 22:50:51 +04:00
|
|
|
virtual void clear();
|
2004-01-29 21:50:33 +03:00
|
|
|
#if BX_USE_TEXTCONFIG
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void text_print(FILE *);
|
|
|
|
virtual int text_ask(FILE *fpin, FILE *fpout);
|
2001-06-18 18:11:55 +04:00
|
|
|
#endif
|
2001-06-16 03:52:34 +04:00
|
|
|
};
|
2001-06-18 18:11:55 +04:00
|
|
|
|
2001-06-20 18:01:39 +04:00
|
|
|
////////////////////////////////////////////////////////////////
|
|
|
|
|
|
|
|
|
2002-11-15 16:22:06 +03:00
|
|
|
// These are the different start modes.
|
|
|
|
enum {
|
|
|
|
// Just start the simulation without running the configuration interface
|
|
|
|
// at all, unless something goes wrong.
|
|
|
|
BX_QUICK_START = 200,
|
|
|
|
// Run the configuration interface. The default action will be to load a
|
|
|
|
// configuration file. This makes sense if a config file could not be
|
|
|
|
// loaded, either because it wasn't found or because it had errors.
|
|
|
|
BX_LOAD_START,
|
|
|
|
// Run the configuration interface. The default action will be to
|
|
|
|
// edit the configuration.
|
|
|
|
BX_EDIT_START,
|
|
|
|
// Run the configuration interface, but make the default action be to
|
|
|
|
// start the simulation.
|
|
|
|
BX_RUN_START
|
|
|
|
};
|
2002-11-09 17:12:10 +03:00
|
|
|
|
2004-12-16 22:05:01 +03:00
|
|
|
enum {
|
|
|
|
BX_MOUSE_TYPE_NONE,
|
|
|
|
BX_MOUSE_TYPE_PS2,
|
|
|
|
BX_MOUSE_TYPE_IMPS2,
|
|
|
|
#if BX_SUPPORT_BUSMOUSE
|
|
|
|
BX_MOUSE_TYPE_BUS,
|
|
|
|
#endif
|
|
|
|
#if BX_SUPPORT_PCIUSB
|
|
|
|
BX_MOUSE_TYPE_USB,
|
|
|
|
#endif
|
|
|
|
BX_MOUSE_TYPE_SERIAL,
|
|
|
|
BX_MOUSE_TYPE_SERIAL_WHEEL
|
|
|
|
};
|
|
|
|
|
2001-06-20 18:01:39 +04:00
|
|
|
#define BX_FLOPPY_NONE 10 // floppy not present
|
|
|
|
#define BX_FLOPPY_1_2 11 // 1.2M 5.25"
|
|
|
|
#define BX_FLOPPY_1_44 12 // 1.44M 3.5"
|
|
|
|
#define BX_FLOPPY_2_88 13 // 2.88M 3.5"
|
|
|
|
#define BX_FLOPPY_720K 14 // 720K 3.5"
|
2002-08-01 11:37:56 +04:00
|
|
|
#define BX_FLOPPY_360K 15 // 360K 5.25"
|
2003-02-07 02:16:56 +03:00
|
|
|
#define BX_FLOPPY_160K 16 // 160K 5.25"
|
|
|
|
#define BX_FLOPPY_180K 17 // 180K 5.25"
|
|
|
|
#define BX_FLOPPY_320K 18 // 320K 5.25"
|
|
|
|
#define BX_FLOPPY_LAST 18 // last legal value of floppy type
|
|
|
|
|
2005-11-20 20:22:44 +03:00
|
|
|
#define BX_FLOPPY_AUTO 19 // autodetect image size
|
2004-09-07 22:02:29 +04:00
|
|
|
#define BX_FLOPPY_UNKNOWN 20 // image size doesn't match one of the types above
|
2001-06-20 18:01:39 +04:00
|
|
|
|
2002-09-23 00:56:12 +04:00
|
|
|
#define BX_ATA_DEVICE_DISK 0
|
|
|
|
#define BX_ATA_DEVICE_CDROM 1
|
|
|
|
#define BX_ATA_DEVICE_LAST 1
|
|
|
|
|
|
|
|
#define BX_ATA_BIOSDETECT_NONE 0
|
|
|
|
#define BX_ATA_BIOSDETECT_AUTO 1
|
|
|
|
#define BX_ATA_BIOSDETECT_CMOS 2
|
|
|
|
|
|
|
|
#define BX_ATA_TRANSLATION_NONE 0
|
|
|
|
#define BX_ATA_TRANSLATION_LBA 1
|
|
|
|
#define BX_ATA_TRANSLATION_LARGE 2
|
2002-10-28 00:25:33 +03:00
|
|
|
#define BX_ATA_TRANSLATION_RECHS 3
|
|
|
|
#define BX_ATA_TRANSLATION_AUTO 4
|
|
|
|
#define BX_ATA_TRANSLATION_LAST 4
|
2002-09-23 00:56:12 +04:00
|
|
|
|
2003-05-03 20:37:18 +04:00
|
|
|
#define BX_ATA_MODE_FLAT 0
|
|
|
|
#define BX_ATA_MODE_CONCAT 1
|
|
|
|
#define BX_ATA_MODE_EXTDISKSIM 2
|
|
|
|
#define BX_ATA_MODE_DLL_HD 3
|
|
|
|
#define BX_ATA_MODE_SPARSE 4
|
|
|
|
#define BX_ATA_MODE_VMWARE3 5
|
2006-12-17 11:17:28 +03:00
|
|
|
#define BX_ATA_MODE_VMWARE4 6
|
|
|
|
#define BX_ATA_MODE_UNDOABLE 7
|
|
|
|
#define BX_ATA_MODE_GROWING 8
|
|
|
|
#define BX_ATA_MODE_VOLATILE 9
|
|
|
|
#define BX_ATA_MODE_Z_UNDOABLE 10
|
|
|
|
#define BX_ATA_MODE_Z_VOLATILE 11
|
|
|
|
#define BX_ATA_MODE_LAST 11
|
2003-05-03 20:37:18 +04:00
|
|
|
|
2003-08-19 04:10:39 +04:00
|
|
|
#define BX_CLOCK_SYNC_NONE 0
|
|
|
|
#define BX_CLOCK_SYNC_REALTIME 1
|
|
|
|
#define BX_CLOCK_SYNC_SLOWDOWN 2
|
2003-08-27 00:24:36 +04:00
|
|
|
#define BX_CLOCK_SYNC_BOTH 3
|
|
|
|
#define BX_CLOCK_SYNC_LAST 3
|
2003-08-19 04:10:39 +04:00
|
|
|
|
|
|
|
#define BX_CLOCK_TIME0_LOCAL 1
|
|
|
|
#define BX_CLOCK_TIME0_UTC 2
|
|
|
|
|
2002-11-14 08:14:10 +03:00
|
|
|
BOCHSAPI extern char *bochs_start_names[];
|
|
|
|
BOCHSAPI extern char *floppy_type_names[];
|
|
|
|
BOCHSAPI extern int floppy_type_n_sectors[];
|
|
|
|
BOCHSAPI extern char *floppy_status_names[];
|
2004-10-16 19:44:00 +04:00
|
|
|
BOCHSAPI extern char *bochs_bootdisk_names[];
|
2002-11-14 08:14:10 +03:00
|
|
|
BOCHSAPI extern char *loader_os_names[];
|
|
|
|
BOCHSAPI extern char *keyboard_type_names[];
|
|
|
|
BOCHSAPI extern char *atadevice_type_names[];
|
2003-05-03 20:37:18 +04:00
|
|
|
BOCHSAPI extern char *atadevice_mode_names[];
|
2002-11-14 08:14:10 +03:00
|
|
|
BOCHSAPI extern char *atadevice_status_names[];
|
|
|
|
BOCHSAPI extern char *atadevice_biosdetect_names[];
|
|
|
|
BOCHSAPI extern char *atadevice_translation_names[];
|
2003-08-19 04:10:39 +04:00
|
|
|
BOCHSAPI extern char *clock_sync_names[];
|
2001-06-20 18:01:39 +04:00
|
|
|
|
2001-06-16 23:29:59 +04:00
|
|
|
////////////////////////////////////////////////////////////////////
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// base class simulator interface, contains just virtual functions.
|
|
|
|
// I'm not longer sure that having a base class is going to be of any
|
|
|
|
// use... -Bryce
|
2001-06-10 00:01:12 +04:00
|
|
|
|
- use setjmp() and longjmp() to quit the simulation thread cleanly.
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.
2002-08-27 22:11:13 +04:00
|
|
|
#include <setjmp.h>
|
|
|
|
|
2006-08-30 00:10:27 +04:00
|
|
|
enum ci_command_t { CI_START, CI_RUNTIME_CONFIG, CI_SHUTDOWN };
|
2002-12-17 08:58:45 +03:00
|
|
|
enum ci_return_t {
|
|
|
|
CI_OK, // normal return value
|
|
|
|
CI_ERR_NO_TEXT_CONSOLE // err: can't work because there's no text console
|
|
|
|
};
|
2002-10-25 01:07:56 +04:00
|
|
|
typedef int (*config_interface_callback_t)(void *userdata, ci_command_t command);
|
2005-10-13 21:36:32 +04:00
|
|
|
typedef BxEvent* (*bxevent_handler)(void *theclass, BxEvent *event);
|
2006-04-14 12:07:24 +04:00
|
|
|
typedef Bit32s (*user_option_parser_t)(const char *context, int num_params, char *params[]);
|
|
|
|
typedef Bit32s (*user_option_save_t)(FILE *fp);
|
2002-10-25 01:07:56 +04:00
|
|
|
|
2002-12-06 22:34:32 +03:00
|
|
|
// bx_gui->set_display_mode() changes the mode between the configuration
|
|
|
|
// interface and the simulation. This is primarily intended for display
|
|
|
|
// libraries which have a full-screen mode such as SDL, term, and svgalib. The
|
|
|
|
// display mode is set to DISP_MODE_CONFIG before displaying any configuration
|
|
|
|
// menus, for panics that requires user input, when entering the debugger, etc.
|
|
|
|
// It is set to DISP_MODE_SIM when the Bochs simulation resumes. The constants
|
|
|
|
// are defined here so that configuration interfaces can use them with the
|
|
|
|
// bx_simulator_interface_c::set_display_mode() method.
|
|
|
|
enum disp_mode_t { DISP_MODE_CONFIG=100, DISP_MODE_SIM };
|
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
class BOCHSAPI bx_simulator_interface_c {
|
2001-06-08 11:20:07 +04:00
|
|
|
public:
|
2006-05-30 02:33:38 +04:00
|
|
|
bx_simulator_interface_c() {}
|
2006-12-27 18:21:03 +03:00
|
|
|
virtual ~bx_simulator_interface_c() {}
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void set_quit_context(jmp_buf *context) {}
|
|
|
|
virtual int get_init_done() { return -1; }
|
|
|
|
virtual int set_init_done(int n) {return -1;}
|
|
|
|
virtual void reset_all_param() {}
|
2006-02-19 18:43:03 +03:00
|
|
|
// new param methods
|
|
|
|
virtual bx_param_c *get_param(const char *pname, bx_param_c *base=NULL) {return NULL;}
|
2006-02-26 22:11:20 +03:00
|
|
|
virtual bx_param_num_c *get_param_num(const char *pname, bx_param_c *base=NULL) {return NULL;}
|
|
|
|
virtual bx_param_string_c *get_param_string(const char *pname, bx_param_c *base=NULL) {return NULL;}
|
|
|
|
virtual bx_param_bool_c *get_param_bool(const char *pname, bx_param_c *base=NULL) {return NULL;}
|
|
|
|
virtual bx_param_enum_c *get_param_enum(const char *pname, bx_param_c *base=NULL) {return NULL;}
|
2006-02-19 18:43:03 +03:00
|
|
|
virtual unsigned gen_param_id() {return 0;}
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual int get_n_log_modules() {return -1;}
|
|
|
|
virtual char *get_prefix(int mod) {return 0;}
|
|
|
|
virtual int get_log_action(int mod, int level) {return -1;}
|
|
|
|
virtual void set_log_action(int mod, int level, int action) {}
|
|
|
|
virtual int get_default_log_action(int level) {return -1;}
|
|
|
|
virtual void set_default_log_action(int level, int action) {}
|
|
|
|
virtual char *get_action_name(int action) {return 0;}
|
|
|
|
virtual const char *get_log_level_name(int level) {return 0;}
|
|
|
|
virtual int get_max_log_level() {return -1;}
|
2002-04-18 04:22:20 +04:00
|
|
|
|
|
|
|
// exiting is somewhat complicated! The preferred way to exit bochs is
|
|
|
|
// to call BX_EXIT(exitcode). That is defined to call
|
|
|
|
// SIM->quit_sim(exitcode). The quit_sim function first calls
|
|
|
|
// the cleanup functions in bochs so that it can destroy windows
|
2002-08-29 18:59:37 +04:00
|
|
|
// and free up memory, then sends a notify message to the CI
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// telling it that bochs has stopped.
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void quit_sim(int code) {}
|
|
|
|
|
|
|
|
virtual int get_exit_code() { return 0; }
|
|
|
|
|
|
|
|
virtual int get_default_rc(char *path, int len) {return -1;}
|
2006-03-13 21:55:53 +03:00
|
|
|
virtual int read_rc(const char *path) {return -1;}
|
|
|
|
virtual int write_rc(const char *rc, int overwrite) {return -1;}
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual int get_log_file(char *path, int len) {return -1;}
|
|
|
|
virtual int set_log_file(char *path) {return -1;}
|
|
|
|
virtual int get_log_prefix(char *prefix, int len) {return -1;}
|
|
|
|
virtual int set_log_prefix(char *prefix) {return -1;}
|
|
|
|
virtual int get_debugger_log_file(char *path, int len) {return -1;}
|
|
|
|
virtual int set_debugger_log_file(char *path) {return -1;}
|
2006-02-26 22:11:20 +03:00
|
|
|
virtual int get_cdrom_options(int drive, bx_list_c **out, int *where = NULL) {return -1;}
|
2002-04-18 04:22:20 +04:00
|
|
|
|
2002-08-29 18:59:37 +04:00
|
|
|
// The CI calls set_notify_callback to register its event handler function.
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// This event handler function is called whenever the simulator needs to
|
2002-08-29 18:59:37 +04:00
|
|
|
// send an event to the CI. For example, if the simulator hits a panic and
|
|
|
|
// wants to ask the user how to proceed, it would call the CI event handler
|
|
|
|
// to ask the CI to display a dialog.
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
//
|
|
|
|
// NOTE: At present, the standard VGAW buttons (floppy, snapshot, power,
|
|
|
|
// etc.) are displayed and handled by gui.cc, not by the CI or siminterface.
|
|
|
|
// gui.cc uses its own callback functions to implement the behavior of
|
|
|
|
// the buttons. Some of these implementations call the siminterface.
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void set_notify_callback(bxevent_handler func, void *arg) {}
|
|
|
|
virtual void get_notify_callback(bxevent_handler *func, void **arg) {}
|
2002-04-18 04:22:20 +04:00
|
|
|
|
2002-08-29 18:59:37 +04:00
|
|
|
// send an event from the simulator to the CI.
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual BxEvent* sim_to_ci_event(BxEvent *event) {return NULL;}
|
2002-04-18 04:22:20 +04:00
|
|
|
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
// called from simulator when it hits serious errors, to ask if the user
|
|
|
|
// wants to continue or not
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual int log_msg(const char *prefix, int level, const char *msg) {return -1;}
|
- I've added lots of comments in siminterface.h, and tried to clean up
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.
2002-08-26 19:31:23 +04:00
|
|
|
|
2002-08-29 18:59:37 +04:00
|
|
|
// tell the CI to ask the user for the value of a parameter.
|
2006-02-27 12:37:58 +03:00
|
|
|
virtual int ask_param(bx_param_c *param) {return -1;}
|
2006-02-22 22:18:29 +03:00
|
|
|
virtual int ask_param(const char *pname) {return -1;}
|
2002-04-18 04:22:20 +04:00
|
|
|
|
|
|
|
// ask the user for a pathname
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual int ask_filename(char *filename, int maxlen, char *prompt, char *the_default, int flags) {return -1;}
|
2006-06-01 00:12:43 +04:00
|
|
|
// yes/no dialog
|
|
|
|
virtual int ask_yes_no(char *title, char *prompt, bx_bool the_default) {return -1;}
|
2002-04-18 04:22:20 +04:00
|
|
|
// called at a regular interval, currently by the keyboard handler.
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void periodic() {}
|
|
|
|
virtual int create_disk_image(const char *filename, int sectors, bx_bool overwrite) {return -3;}
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
// Tell the configuration interface (CI) that some parameter values have
|
|
|
|
// changed. The CI will reread the parameters and change its display if it's
|
|
|
|
// appropriate. Maybe later: mention which params have changed to save time.
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void refresh_ci() {}
|
2002-09-23 21:41:42 +04:00
|
|
|
// forces a vga update. This was added so that a debugger can force
|
|
|
|
// a vga update when single stepping, without having to wait thousands
|
|
|
|
// of cycles for the normal vga refresh triggered by iodev/keyboard.cc.
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void refresh_vga() {}
|
2002-09-23 21:41:42 +04:00
|
|
|
// forces a call to bx_gui.handle_events. This was added so that a debugger
|
|
|
|
// can force the gui events to be handled, so that interactive things such
|
|
|
|
// as a toolbar click will be processed.
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void handle_events() {}
|
2002-12-07 22:43:53 +03:00
|
|
|
// return first hard disk in ATA interface
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual bx_param_c *get_first_cdrom() {return NULL;}
|
2002-09-23 00:56:12 +04:00
|
|
|
// return first cdrom in ATA interface
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual bx_param_c *get_first_hd() {return NULL;}
|
- add infrastructure for sending commands from the wxWindows interface to the
Bochs debugger. The Bochs debugger calls SIM->debug_get_next_command() which
does not return until a debugger command is found. The siminterface sends an
synchronous event to the wxWindows thread with a blank to be filled in with a
debugger command. wxWindows fills in the blank and sends the synchronous
event back, and the Bochs debugger interprets it as if it was typed on
the command line. For the long term I haven't decided whether to stick with
sending text strings vs. some other method.
- so far the wxWindows debugger consists of one big dialog box that shows
all the standard registers, and a working Continue, Stop, and Step button.
- modify ParamDialog so that it is more useful as a base class, by moving
some things to protected members&fields, separating out functionality
that is most likely to be replaced into virtual functions, and making it
generally more flexible. The new CpuRegistersDialog is based on
ParamDialog.
- in wxdialog.cc, continue the convention of using wxID_HELP, wxID_OK,
wxID_CANCEL, etc. for the id's of buttons, instead of wxHELP, wxOK, etc.
which are intended to be ORred together in a bit field.
- cpu/init.cc: put ifdefs around DEFPARAMs for flags in configurations
where they don't exist. Add an eflags shadow parameter that represents all
of the bits of eflags at once. There are also boolean shadow params for
each bit.
- modified files: cpu/init.cc debug/dbg_main.cc debug/debug.h
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h
2002-09-13 23:39:38 +04:00
|
|
|
#if BX_DEBUGGER
|
|
|
|
// for debugger: same behavior as pressing control-C
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void debug_break() {}
|
|
|
|
virtual void debug_interpret_cmd(char *cmd) {}
|
|
|
|
virtual char *debug_get_next_command() {return NULL;}
|
|
|
|
virtual void debug_puts(const char *text) {}
|
- add infrastructure for sending commands from the wxWindows interface to the
Bochs debugger. The Bochs debugger calls SIM->debug_get_next_command() which
does not return until a debugger command is found. The siminterface sends an
synchronous event to the wxWindows thread with a blank to be filled in with a
debugger command. wxWindows fills in the blank and sends the synchronous
event back, and the Bochs debugger interprets it as if it was typed on
the command line. For the long term I haven't decided whether to stick with
sending text strings vs. some other method.
- so far the wxWindows debugger consists of one big dialog box that shows
all the standard registers, and a working Continue, Stop, and Step button.
- modify ParamDialog so that it is more useful as a base class, by moving
some things to protected members&fields, separating out functionality
that is most likely to be replaced into virtual functions, and making it
generally more flexible. The new CpuRegistersDialog is based on
ParamDialog.
- in wxdialog.cc, continue the convention of using wxID_HELP, wxID_OK,
wxID_CANCEL, etc. for the id's of buttons, instead of wxHELP, wxOK, etc.
which are intended to be ORred together in a bit field.
- cpu/init.cc: put ifdefs around DEFPARAMs for flags in configurations
where they don't exist. Add an eflags shadow parameter that represents all
of the bits of eflags at once. There are also boolean shadow params for
each bit.
- modified files: cpu/init.cc debug/dbg_main.cc debug/debug.h
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h
2002-09-13 23:39:38 +04:00
|
|
|
#endif
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void register_configuration_interface(
|
2002-10-25 01:07:56 +04:00
|
|
|
const char* name,
|
|
|
|
config_interface_callback_t callback,
|
|
|
|
void *userdata) {}
|
|
|
|
virtual int configuration_interface(const char* name, ci_command_t command) {return -1; }
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual int begin_simulation(int argc, char *argv[]) {return -1;}
|
2006-04-07 00:42:51 +04:00
|
|
|
typedef bx_bool (*is_sim_thread_func_t)();
|
2002-10-25 01:07:56 +04:00
|
|
|
is_sim_thread_func_t is_sim_thread_func;
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void set_sim_thread_func(is_sim_thread_func_t func) {
|
2002-10-25 01:07:56 +04:00
|
|
|
is_sim_thread_func = func;
|
|
|
|
}
|
2006-04-07 00:42:51 +04:00
|
|
|
virtual bx_bool is_sim_thread() {return 1;}
|
2006-11-12 13:07:18 +03:00
|
|
|
virtual void set_debug_gui(bx_bool val) {}
|
|
|
|
virtual bx_bool has_debug_gui() {return 0;}
|
2002-12-06 22:34:32 +03:00
|
|
|
// provide interface to bx_gui->set_display_mode() method for config
|
|
|
|
// interfaces to use.
|
2006-02-18 19:53:18 +03:00
|
|
|
virtual void set_display_mode(disp_mode_t newmode) {}
|
2006-04-07 00:42:51 +04:00
|
|
|
virtual bx_bool test_for_text_console() {return 1;}
|
2006-03-29 23:27:31 +04:00
|
|
|
// user-defined option support
|
2006-04-05 20:05:11 +04:00
|
|
|
virtual int find_user_option(const char *keyword) {return -1;}
|
2006-04-14 12:07:24 +04:00
|
|
|
virtual bx_bool register_user_option(const char *keyword, user_option_parser_t parser, user_option_save_t save_func) {return 0;}
|
2006-04-05 20:05:11 +04:00
|
|
|
virtual Bit32s parse_user_option(int idx, const char *context, int num_params, char *params []) {return -1;}
|
2006-04-14 12:07:24 +04:00
|
|
|
virtual Bit32s save_user_options(FILE *fp) {return -1;}
|
2006-04-09 17:55:55 +04:00
|
|
|
#if BX_SUPPORT_SAVE_RESTORE
|
2006-04-07 00:42:51 +04:00
|
|
|
// save/restore support
|
2006-09-07 22:50:51 +04:00
|
|
|
virtual void init_save_restore() {}
|
2006-04-07 16:49:50 +04:00
|
|
|
virtual bx_bool save_state(const char *checkpoint_path) {return 0;}
|
2006-04-07 00:42:51 +04:00
|
|
|
virtual bx_bool restore_config() {return 0;}
|
|
|
|
virtual bx_bool restore_logopts() {return 0;}
|
|
|
|
virtual bx_bool restore_hardware() {return 0;}
|
2006-04-15 18:05:18 +04:00
|
|
|
virtual bx_list_c *get_sr_root() {return NULL;}
|
2006-04-07 00:42:51 +04:00
|
|
|
#endif
|
2001-06-08 11:20:07 +04:00
|
|
|
};
|
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
BOCHSAPI extern bx_simulator_interface_c *SIM;
|
2002-09-05 11:48:39 +04:00
|
|
|
|
2006-02-18 19:53:18 +03:00
|
|
|
BOCHSAPI extern void bx_init_siminterface();
|
|
|
|
BOCHSAPI extern int bx_init_main(int argc, char *argv[]);
|
2002-11-01 18:19:48 +03:00
|
|
|
|
2004-02-04 22:54:58 +03:00
|
|
|
#if defined(__WXMSW__) || defined(WIN32)
|
2002-11-01 18:19:48 +03:00
|
|
|
// Just to provide HINSTANCE, etc. in files that have not included bochs.h.
|
|
|
|
// I don't like this at all, but I don't see a way around it.
|
|
|
|
#include <windows.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
// define structure to hold data that is passed into our main function.
|
|
|
|
typedef struct BOCHSAPI {
|
|
|
|
// standard argc,argv
|
|
|
|
int argc;
|
|
|
|
char **argv;
|
2004-02-04 22:54:58 +03:00
|
|
|
#ifdef WIN32
|
|
|
|
char initial_dir[MAX_PATH];
|
|
|
|
#endif
|
2002-11-01 18:19:48 +03:00
|
|
|
#ifdef __WXMSW__
|
2005-01-05 22:54:32 +03:00
|
|
|
// these are only used when compiling with wxWidgets. This gives us a
|
2002-11-01 18:19:48 +03:00
|
|
|
// place to store the data that was passed to WinMain.
|
|
|
|
HINSTANCE hInstance;
|
|
|
|
HINSTANCE hPrevInstance;
|
|
|
|
LPSTR m_lpCmdLine;
|
|
|
|
int nCmdShow;
|
|
|
|
#endif
|
|
|
|
} bx_startup_flags_t;
|
|
|
|
|
2002-11-14 08:14:10 +03:00
|
|
|
BOCHSAPI extern bx_startup_flags_t bx_startup_flags;
|
2003-05-27 22:19:13 +04:00
|
|
|
BOCHSAPI extern bx_bool bx_user_quit;
|
2006-01-18 21:35:38 +03:00
|
|
|
BOCHSAPI extern Bit8u bx_cpu_count;
|