2001-10-03 17:10:38 +04:00
|
|
|
/////////////////////////////////////////////////////////////////////////
|
2004-10-25 00:04:52 +04:00
|
|
|
// $Id: siminterface.h,v 1.127 2004-10-24 20:04:51 vruppert Exp $
|
2001-10-03 17:10:38 +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
|
|
|
// 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
|
|
|
|
// control.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
|
|
|
|
// bochs.h. You'll notice that control.cc include osdep.h, control.h, 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
|
|
|
|
// process, where direct method calls would be impossible. Also, we have been
|
|
|
|
// considering turning devices into plugin modules which are dynamically
|
|
|
|
// 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
|
2002-08-29 18:59:37 +04:00
|
|
|
// to by the global variable bx_simulator_interface_c *SIM; The base class
|
|
|
|
// 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
|
|
|
|
// they are declared. Search for "parameter classes" below for detals.
|
- 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
|
|
|
|
// wxWindows interface, but I'm not sure if I like it. One problem is
|
|
|
|
// that in order to declare member functions that are useful for
|
|
|
|
// wxWindows, the wxWindows header files would have to be included
|
|
|
|
// before the param object definitions. That means that all the
|
|
|
|
// wxwindows headers would have be included when compiling every
|
|
|
|
// 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
|
2002-08-29 18:59:37 +04:00
|
|
|
// <wx.h>, and the wxwindows CI (wxmain.cc) doesn't need to include <bochs.h>.
|
|
|
|
// 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,
|
|
|
|
BXT_LIST
|
|
|
|
} bx_objtype;
|
|
|
|
|
- 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
|
|
|
// list if parameter id values. The actual values are not important;
|
|
|
|
// it's only important that they all be different from each other.
|
2001-06-16 03:52:34 +04:00
|
|
|
typedef enum {
|
2002-11-09 17:12:10 +03:00
|
|
|
BXP_NULL = 301,
|
2001-06-18 18:11:55 +04:00
|
|
|
BXP_IPS,
|
2002-10-30 01:26:32 +03:00
|
|
|
BXP_REALTIME_PIT,
|
2002-12-12 09:21:43 +03:00
|
|
|
BXP_TEXT_SNAPSHOT_CHECK,
|
2001-06-16 03:52:34 +04:00
|
|
|
BXP_VGA_UPDATE_INTERVAL,
|
|
|
|
BXP_MOUSE_ENABLED,
|
2001-06-16 23:29:59 +04:00
|
|
|
BXP_MEM_SIZE,
|
|
|
|
BXP_ROM_PATH,
|
2001-06-17 17:50:52 +04:00
|
|
|
BXP_ROM_ADDRESS,
|
2001-06-18 18:11:55 +04:00
|
|
|
BXP_VGA_ROM_PATH,
|
2002-07-24 21:52:34 +04:00
|
|
|
BXP_OPTROM1_PATH,
|
|
|
|
BXP_OPTROM2_PATH,
|
|
|
|
BXP_OPTROM3_PATH,
|
|
|
|
BXP_OPTROM4_PATH,
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_OPTROM1_ADDRESS,
|
|
|
|
BXP_OPTROM2_ADDRESS,
|
|
|
|
BXP_OPTROM3_ADDRESS,
|
2002-07-24 21:52:34 +04:00
|
|
|
BXP_OPTROM4_ADDRESS,
|
2004-10-25 00:04:52 +04:00
|
|
|
BXP_OPTROM_LIST,
|
2001-06-20 18:01:39 +04:00
|
|
|
BXP_KBD_SERIAL_DELAY,
|
2002-03-26 16:51:48 +03:00
|
|
|
BXP_KBD_PASTE_DELAY,
|
2001-12-12 13:38:39 +03:00
|
|
|
BXP_KBD_TYPE,
|
2001-06-20 18:01:39 +04:00
|
|
|
BXP_FLOPPY_CMD_DELAY,
|
2002-08-04 12:42:34 +04:00
|
|
|
BXP_FLOPPYA_DEVTYPE,
|
2001-06-20 18:01:39 +04:00
|
|
|
BXP_FLOPPYA_PATH,
|
|
|
|
BXP_FLOPPYA_TYPE,
|
|
|
|
BXP_FLOPPYA_STATUS,
|
2001-06-21 18:37:55 +04:00
|
|
|
BXP_FLOPPYA,
|
2002-08-04 12:42:34 +04:00
|
|
|
BXP_FLOPPYB_DEVTYPE,
|
2001-06-20 18:01:39 +04:00
|
|
|
BXP_FLOPPYB_PATH,
|
|
|
|
BXP_FLOPPYB_TYPE,
|
|
|
|
BXP_FLOPPYB_STATUS,
|
2001-06-21 18:37:55 +04:00
|
|
|
BXP_FLOPPYB,
|
2003-08-10 02:17:38 +04:00
|
|
|
|
- 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
|
|
|
BXP_ATA0_MENU,
|
|
|
|
BXP_ATA1_MENU,
|
|
|
|
BXP_ATA2_MENU,
|
|
|
|
BXP_ATA3_MENU,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_MENU(i) (BXP_ATA0_MENU + (i))
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0,
|
|
|
|
BXP_ATA1,
|
|
|
|
BXP_ATA2,
|
|
|
|
BXP_ATA3,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx(i) (BXP_ATA0 + (i))
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_PRESENT,
|
|
|
|
BXP_ATA1_PRESENT,
|
|
|
|
BXP_ATA2_PRESENT,
|
|
|
|
BXP_ATA3_PRESENT,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_PRESENT(i) (BXP_ATA0_PRESENT + (i))
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_IOADDR1,
|
|
|
|
BXP_ATA1_IOADDR1,
|
|
|
|
BXP_ATA2_IOADDR1,
|
|
|
|
BXP_ATA3_IOADDR1,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_IOADDR1(i) (BXP_ATA0_IOADDR1 + (i))
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_IOADDR2,
|
|
|
|
BXP_ATA1_IOADDR2,
|
|
|
|
BXP_ATA2_IOADDR2,
|
|
|
|
BXP_ATA3_IOADDR2,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_IOADDR2(i) (BXP_ATA0_IOADDR2 + (i))
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_IRQ,
|
|
|
|
BXP_ATA1_IRQ,
|
|
|
|
BXP_ATA2_IRQ,
|
|
|
|
BXP_ATA3_IRQ,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_IRQ(i) (BXP_ATA0_IRQ + (i))
|
|
|
|
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_MASTER,
|
|
|
|
BXP_ATA0_SLAVE,
|
|
|
|
BXP_ATA1_MASTER,
|
|
|
|
BXP_ATA1_SLAVE,
|
|
|
|
BXP_ATA2_MASTER,
|
|
|
|
BXP_ATA2_SLAVE,
|
|
|
|
BXP_ATA3_MASTER,
|
|
|
|
BXP_ATA3_SLAVE,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_DEVICE(i, s) (BXP_ATA0_MASTER + (2*(i)) + (s))
|
|
|
|
|
|
|
|
#define BXP_PARAMS_PER_ATA_DEVICE 12
|
|
|
|
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_MASTER_PRESENT,
|
|
|
|
BXP_ATA0_SLAVE_PRESENT,
|
|
|
|
BXP_ATA1_MASTER_PRESENT,
|
|
|
|
BXP_ATA1_SLAVE_PRESENT,
|
|
|
|
BXP_ATA2_MASTER_PRESENT,
|
|
|
|
BXP_ATA2_SLAVE_PRESENT,
|
|
|
|
BXP_ATA3_MASTER_PRESENT,
|
|
|
|
BXP_ATA3_SLAVE_PRESENT,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_DEVICE_PRESENT(i, s) (BXP_ATA0_MASTER_PRESENT + (2*(i)) + (s))
|
|
|
|
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_MASTER_TYPE,
|
|
|
|
BXP_ATA0_SLAVE_TYPE,
|
|
|
|
BXP_ATA1_MASTER_TYPE,
|
|
|
|
BXP_ATA1_SLAVE_TYPE,
|
|
|
|
BXP_ATA2_MASTER_TYPE,
|
|
|
|
BXP_ATA2_SLAVE_TYPE,
|
|
|
|
BXP_ATA3_MASTER_TYPE,
|
|
|
|
BXP_ATA3_SLAVE_TYPE,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_DEVICE_TYPE(i, s) (BXP_ATA0_MASTER_TYPE + (2*(i)) + (s))
|
|
|
|
|
2003-05-03 20:37:18 +04:00
|
|
|
BXP_ATA0_MASTER_MODE,
|
|
|
|
BXP_ATA0_SLAVE_MODE,
|
|
|
|
BXP_ATA1_MASTER_MODE,
|
|
|
|
BXP_ATA1_SLAVE_MODE,
|
|
|
|
BXP_ATA2_MASTER_MODE,
|
|
|
|
BXP_ATA2_SLAVE_MODE,
|
|
|
|
BXP_ATA3_MASTER_MODE,
|
|
|
|
BXP_ATA3_SLAVE_MODE,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_DEVICE_MODE(i, s) (BXP_ATA0_MASTER_MODE + (2*(i)) + (s))
|
|
|
|
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_MASTER_PATH,
|
|
|
|
BXP_ATA0_SLAVE_PATH,
|
|
|
|
BXP_ATA1_MASTER_PATH,
|
|
|
|
BXP_ATA1_SLAVE_PATH,
|
|
|
|
BXP_ATA2_MASTER_PATH,
|
|
|
|
BXP_ATA2_SLAVE_PATH,
|
|
|
|
BXP_ATA3_MASTER_PATH,
|
|
|
|
BXP_ATA3_SLAVE_PATH,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_DEVICE_PATH(i, s) (BXP_ATA0_MASTER_PATH + (2*(i)) + (s))
|
|
|
|
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_MASTER_CYLINDERS,
|
|
|
|
BXP_ATA0_SLAVE_CYLINDERS,
|
|
|
|
BXP_ATA1_MASTER_CYLINDERS,
|
|
|
|
BXP_ATA1_SLAVE_CYLINDERS,
|
|
|
|
BXP_ATA2_MASTER_CYLINDERS,
|
|
|
|
BXP_ATA2_SLAVE_CYLINDERS,
|
|
|
|
BXP_ATA3_MASTER_CYLINDERS,
|
|
|
|
BXP_ATA3_SLAVE_CYLINDERS,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_DEVICE_CYLINDERS(i, s) (BXP_ATA0_MASTER_CYLINDERS + (2*(i)) + (s))
|
|
|
|
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_MASTER_HEADS,
|
|
|
|
BXP_ATA0_SLAVE_HEADS,
|
|
|
|
BXP_ATA1_MASTER_HEADS,
|
|
|
|
BXP_ATA1_SLAVE_HEADS,
|
|
|
|
BXP_ATA2_MASTER_HEADS,
|
|
|
|
BXP_ATA2_SLAVE_HEADS,
|
|
|
|
BXP_ATA3_MASTER_HEADS,
|
|
|
|
BXP_ATA3_SLAVE_HEADS,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_DEVICE_HEADS(i, s) (BXP_ATA0_MASTER_HEADS + (2*(i)) + (s))
|
|
|
|
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_MASTER_SPT,
|
|
|
|
BXP_ATA0_SLAVE_SPT,
|
|
|
|
BXP_ATA1_MASTER_SPT,
|
|
|
|
BXP_ATA1_SLAVE_SPT,
|
|
|
|
BXP_ATA2_MASTER_SPT,
|
|
|
|
BXP_ATA2_SLAVE_SPT,
|
|
|
|
BXP_ATA3_MASTER_SPT,
|
|
|
|
BXP_ATA3_SLAVE_SPT,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_DEVICE_SPT(i, s) (BXP_ATA0_MASTER_SPT + (2*(i)) + (s))
|
|
|
|
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_MASTER_STATUS,
|
|
|
|
BXP_ATA0_SLAVE_STATUS,
|
|
|
|
BXP_ATA1_MASTER_STATUS,
|
|
|
|
BXP_ATA1_SLAVE_STATUS,
|
|
|
|
BXP_ATA2_MASTER_STATUS,
|
|
|
|
BXP_ATA2_SLAVE_STATUS,
|
|
|
|
BXP_ATA3_MASTER_STATUS,
|
|
|
|
BXP_ATA3_SLAVE_STATUS,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_DEVICE_STATUS(i, s) (BXP_ATA0_MASTER_STATUS + (2*(i)) + (s))
|
|
|
|
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_MASTER_MODEL,
|
|
|
|
BXP_ATA0_SLAVE_MODEL,
|
|
|
|
BXP_ATA1_MASTER_MODEL,
|
|
|
|
BXP_ATA1_SLAVE_MODEL,
|
|
|
|
BXP_ATA2_MASTER_MODEL,
|
|
|
|
BXP_ATA2_SLAVE_MODEL,
|
|
|
|
BXP_ATA3_MASTER_MODEL,
|
|
|
|
BXP_ATA3_SLAVE_MODEL,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_DEVICE_MODEL(i, s) (BXP_ATA0_MASTER_MODEL + (2*(i)) + (s))
|
|
|
|
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_MASTER_BIOSDETECT,
|
|
|
|
BXP_ATA0_SLAVE_BIOSDETECT,
|
|
|
|
BXP_ATA1_MASTER_BIOSDETECT,
|
|
|
|
BXP_ATA1_SLAVE_BIOSDETECT,
|
|
|
|
BXP_ATA2_MASTER_BIOSDETECT,
|
|
|
|
BXP_ATA2_SLAVE_BIOSDETECT,
|
|
|
|
BXP_ATA3_MASTER_BIOSDETECT,
|
|
|
|
BXP_ATA3_SLAVE_BIOSDETECT,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_DEVICE_BIOSDETECT(i, s) (BXP_ATA0_MASTER_BIOSDETECT + (2*(i)) + (s))
|
|
|
|
|
2002-09-23 00:56:12 +04:00
|
|
|
BXP_ATA0_MASTER_TRANSLATION,
|
|
|
|
BXP_ATA0_SLAVE_TRANSLATION,
|
|
|
|
BXP_ATA1_MASTER_TRANSLATION,
|
|
|
|
BXP_ATA1_SLAVE_TRANSLATION,
|
|
|
|
BXP_ATA2_MASTER_TRANSLATION,
|
|
|
|
BXP_ATA2_SLAVE_TRANSLATION,
|
|
|
|
BXP_ATA3_MASTER_TRANSLATION,
|
|
|
|
BXP_ATA3_SLAVE_TRANSLATION,
|
2003-08-10 02:17:38 +04:00
|
|
|
#define BXP_ATAx_DEVICE_TRANSLATION(i, s) (BXP_ATA0_MASTER_TRANSLATION + (2*(i)) + (s))
|
|
|
|
|
|
|
|
BXP_ATA0_MASTER_JOURNAL,
|
|
|
|
BXP_ATA0_SLAVE_JOURNAL,
|
|
|
|
BXP_ATA1_MASTER_JOURNAL,
|
|
|
|
BXP_ATA1_SLAVE_JOURNAL,
|
|
|
|
BXP_ATA2_MASTER_JOURNAL,
|
|
|
|
BXP_ATA2_SLAVE_JOURNAL,
|
|
|
|
BXP_ATA3_MASTER_JOURNAL,
|
|
|
|
BXP_ATA3_SLAVE_JOURNAL,
|
|
|
|
#define BXP_ATAx_DEVICE_JOURNAL(i, s) (BXP_ATA0_MASTER_JOURNAL + (2*(i)) + (s))
|
|
|
|
|
2004-07-28 23:36:42 +04:00
|
|
|
#define BXP_PARAMS_PER_SERIAL_PORT 3
|
2002-08-24 21:11:33 +04:00
|
|
|
BXP_COM1_ENABLED,
|
2004-07-28 23:36:42 +04:00
|
|
|
BXP_COM1_MODE,
|
2002-03-03 09:03:29 +03:00
|
|
|
BXP_COM1_PATH,
|
2002-08-24 21:11:33 +04:00
|
|
|
BXP_COM2_ENABLED,
|
2004-07-28 23:36:42 +04:00
|
|
|
BXP_COM2_MODE,
|
2002-03-03 09:03:29 +03:00
|
|
|
BXP_COM2_PATH,
|
2002-08-24 21:11:33 +04:00
|
|
|
BXP_COM3_ENABLED,
|
2004-07-28 23:36:42 +04:00
|
|
|
BXP_COM3_MODE,
|
2002-03-03 09:03:29 +03:00
|
|
|
BXP_COM3_PATH,
|
2002-08-24 21:11:33 +04:00
|
|
|
BXP_COM4_ENABLED,
|
2004-07-28 23:36:42 +04:00
|
|
|
BXP_COM4_MODE,
|
2002-03-03 09:03:29 +03:00
|
|
|
BXP_COM4_PATH,
|
2003-01-28 19:58:10 +03:00
|
|
|
#define BXP_PARAMS_PER_USB_HUB 3
|
|
|
|
BXP_USB1_ENABLED,
|
|
|
|
BXP_USB1_IOADDR,
|
|
|
|
BXP_USB1_IRQ,
|
2001-06-20 18:01:39 +04:00
|
|
|
BXP_PRIVATE_COLORMAP,
|
2001-08-16 00:17:19 +04:00
|
|
|
BXP_FULLSCREEN,
|
2001-08-16 06:00:31 +04:00
|
|
|
BXP_SCREENMODE,
|
2001-06-20 18:01:39 +04:00
|
|
|
BXP_I440FX_SUPPORT,
|
2004-07-10 01:40:49 +04:00
|
|
|
BXP_PCI,
|
2001-06-20 18:01:39 +04:00
|
|
|
BXP_NEWHARDDRIVESUPPORT,
|
|
|
|
BXP_LOG_FILENAME,
|
2002-06-26 18:42:35 +04:00
|
|
|
BXP_LOG_PREFIX,
|
2002-12-03 00:26:05 +03:00
|
|
|
BXP_DEBUGGER_LOG_FILENAME,
|
2001-06-20 18:01:39 +04:00
|
|
|
BXP_CMOS_PATH,
|
|
|
|
BXP_CMOS_IMAGE,
|
2003-08-19 04:10:39 +04:00
|
|
|
BXP_CLOCK,
|
|
|
|
BXP_CLOCK_TIME0,
|
|
|
|
BXP_CLOCK_SYNC,
|
2001-06-20 18:01:39 +04:00
|
|
|
BXP_LOAD32BITOS_WHICH,
|
|
|
|
BXP_LOAD32BITOS_PATH,
|
|
|
|
BXP_LOAD32BITOS_IOLOG,
|
|
|
|
BXP_LOAD32BITOS_INITRD,
|
2001-06-21 23:57:21 +04:00
|
|
|
BXP_LOAD32BITOS,
|
2004-10-16 19:44:00 +04:00
|
|
|
BXP_BOOTDRIVE1,
|
|
|
|
BXP_BOOTDRIVE2,
|
|
|
|
BXP_BOOTDRIVE3,
|
2002-04-23 11:44:34 +04:00
|
|
|
BXP_FLOPPYSIGCHECK,
|
2004-10-17 20:25:10 +04:00
|
|
|
BXP_BOOT,
|
2001-06-21 18:37:55 +04:00
|
|
|
BXP_MENU_MAIN,
|
|
|
|
BXP_MENU_MEMORY,
|
|
|
|
BXP_MENU_INTERFACE,
|
|
|
|
BXP_MENU_DISK,
|
2002-03-03 09:10:04 +03:00
|
|
|
BXP_MENU_SERIAL_PARALLEL,
|
2001-06-21 18:37:55 +04:00
|
|
|
BXP_MENU_SOUND,
|
2003-08-23 19:28:06 +04:00
|
|
|
BXP_MENU_KEYBOARD,
|
2001-06-21 18:37:55 +04:00
|
|
|
BXP_MENU_MISC,
|
2003-09-06 02:07:54 +04:00
|
|
|
BXP_MENU_MISC_2,
|
2001-06-21 18:37:55 +04:00
|
|
|
BXP_MENU_RUNTIME,
|
2001-06-21 20:59:56 +04:00
|
|
|
BXP_MAX_IPS,
|
2002-11-18 20:16:07 +03:00
|
|
|
BXP_NE2K_PRESENT,
|
2001-06-21 22:34:50 +04:00
|
|
|
BXP_NE2K_IOADDR,
|
|
|
|
BXP_NE2K_IRQ,
|
|
|
|
BXP_NE2K_MACADDR,
|
|
|
|
BXP_NE2K_ETHMOD,
|
|
|
|
BXP_NE2K_ETHDEV,
|
2002-05-02 11:54:22 +04:00
|
|
|
BXP_NE2K_SCRIPT,
|
2001-06-21 22:34:50 +04:00
|
|
|
BXP_NE2K,
|
2004-10-25 00:04:52 +04:00
|
|
|
BXP_PNIC_ENABLED,
|
|
|
|
BXP_PNIC_IOADDR,
|
|
|
|
BXP_PNIC_IRQ,
|
|
|
|
BXP_PNIC_MACADDR,
|
|
|
|
BXP_PNIC_ETHMOD,
|
|
|
|
BXP_PNIC_ETHDEV,
|
|
|
|
BXP_PNIC_SCRIPT,
|
|
|
|
BXP_PNIC,
|
|
|
|
BXP_NETWORK,
|
2004-01-15 05:08:37 +03:00
|
|
|
BXP_PCIDEV_VENDOR,
|
|
|
|
BXP_PCIDEV_DEVICE,
|
|
|
|
BXP_PCIDEV,
|
2001-06-21 22:34:50 +04:00
|
|
|
BXP_SB16_PRESENT,
|
|
|
|
BXP_SB16_MIDIFILE,
|
|
|
|
BXP_SB16_WAVEFILE,
|
|
|
|
BXP_SB16_LOGFILE,
|
|
|
|
BXP_SB16_MIDIMODE,
|
|
|
|
BXP_SB16_WAVEMODE,
|
|
|
|
BXP_SB16_LOGLEVEL,
|
|
|
|
BXP_SB16_DMATIMER,
|
|
|
|
BXP_SB16,
|
2002-09-03 12:46:30 +04:00
|
|
|
#define BXP_PARAMS_PER_PARALLEL_PORT 2
|
2002-08-24 21:11:33 +04:00
|
|
|
BXP_PARPORT1_ENABLED,
|
2001-11-12 05:35:09 +03:00
|
|
|
BXP_PARPORT1_OUTFILE,
|
2002-08-24 21:11:33 +04:00
|
|
|
BXP_PARPORT2_ENABLED,
|
2001-11-12 05:35:09 +03:00
|
|
|
BXP_PARPORT2_OUTFILE,
|
2004-06-29 23:24:34 +04:00
|
|
|
#define BXP_PARAMS_PER_PCI_SLOT 2
|
|
|
|
BXP_PCI_SLOT1_USED,
|
|
|
|
BXP_PCI_SLOT1_DEVNAME,
|
|
|
|
BXP_PCI_SLOT2_USED,
|
|
|
|
BXP_PCI_SLOT2_DEVNAME,
|
|
|
|
BXP_PCI_SLOT3_USED,
|
|
|
|
BXP_PCI_SLOT3_DEVNAME,
|
|
|
|
BXP_PCI_SLOT4_USED,
|
|
|
|
BXP_PCI_SLOT4_DEVNAME,
|
|
|
|
BXP_PCI_SLOT5_USED,
|
|
|
|
BXP_PCI_SLOT5_DEVNAME,
|
2001-12-14 20:56:37 +03:00
|
|
|
BXP_KEYBOARD_USEMAPPING,
|
|
|
|
BXP_KEYBOARD_MAP,
|
|
|
|
BXP_KEYBOARD,
|
2002-08-09 10:16:43 +04:00
|
|
|
BXP_USER_SHORTCUT,
|
2002-04-18 04:22:20 +04:00
|
|
|
BXP_ASK_FOR_PATHNAME, // for general file selection dialog
|
2002-11-09 17:12:10 +03:00
|
|
|
BXP_BOCHS_START, // How Bochs starts
|
- 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
|
|
|
// experiment: add params for CPU registers
|
|
|
|
BXP_CPU_PARAMETERS,
|
|
|
|
BXP_CPU_EAX,
|
|
|
|
BXP_CPU_EBX,
|
|
|
|
BXP_CPU_ECX,
|
|
|
|
BXP_CPU_EDX,
|
2002-09-11 07:53:48 +04:00
|
|
|
BXP_CPU_EBP,
|
|
|
|
BXP_CPU_ESI,
|
|
|
|
BXP_CPU_EDI,
|
|
|
|
BXP_CPU_ESP,
|
- 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
|
|
|
BXP_CPU_EIP,
|
2002-09-11 07:53:48 +04:00
|
|
|
BXP_CPU_SEG_CS,
|
|
|
|
BXP_CPU_SEG_DS,
|
|
|
|
BXP_CPU_SEG_SS,
|
|
|
|
BXP_CPU_SEG_ES,
|
|
|
|
BXP_CPU_SEG_FS,
|
|
|
|
BXP_CPU_SEG_GS,
|
|
|
|
BXP_CPU_SEG_LDTR,
|
|
|
|
BXP_CPU_SEG_TR,
|
|
|
|
BXP_CPU_GDTR_BASE,
|
|
|
|
BXP_CPU_GDTR_LIMIT,
|
|
|
|
BXP_CPU_IDTR_BASE,
|
|
|
|
BXP_CPU_IDTR_LIMIT,
|
- 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
|
|
|
BXP_CPU_EFLAGS,
|
2002-09-11 07:53:48 +04:00
|
|
|
BXP_CPU_EFLAGS_ID,
|
|
|
|
BXP_CPU_EFLAGS_VIP,
|
|
|
|
BXP_CPU_EFLAGS_VIF,
|
|
|
|
BXP_CPU_EFLAGS_AC,
|
|
|
|
BXP_CPU_EFLAGS_VM,
|
|
|
|
BXP_CPU_EFLAGS_RF,
|
|
|
|
BXP_CPU_EFLAGS_NT,
|
|
|
|
BXP_CPU_EFLAGS_IOPL,
|
|
|
|
BXP_CPU_EFLAGS_OF,
|
|
|
|
BXP_CPU_EFLAGS_DF,
|
|
|
|
BXP_CPU_EFLAGS_IF,
|
|
|
|
BXP_CPU_EFLAGS_TF,
|
|
|
|
BXP_CPU_EFLAGS_SF,
|
|
|
|
BXP_CPU_EFLAGS_ZF,
|
|
|
|
BXP_CPU_EFLAGS_AF,
|
|
|
|
BXP_CPU_EFLAGS_PF,
|
|
|
|
BXP_CPU_EFLAGS_CF,
|
|
|
|
BXP_CPU_DR0,
|
|
|
|
BXP_CPU_DR1,
|
|
|
|
BXP_CPU_DR2,
|
|
|
|
BXP_CPU_DR3,
|
|
|
|
BXP_CPU_DR6,
|
|
|
|
BXP_CPU_DR7,
|
|
|
|
BXP_CPU_TR3,
|
|
|
|
BXP_CPU_TR4,
|
|
|
|
BXP_CPU_TR5,
|
|
|
|
BXP_CPU_TR6,
|
|
|
|
BXP_CPU_TR7,
|
|
|
|
BXP_CPU_CR0,
|
|
|
|
BXP_CPU_CR1,
|
|
|
|
BXP_CPU_CR2,
|
|
|
|
BXP_CPU_CR3,
|
|
|
|
BXP_CPU_CR4,
|
- 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 few parameters for the keyboard
|
|
|
|
BXP_KBD_PARAMETERS,
|
|
|
|
BXP_KBD_PARE,
|
|
|
|
BXP_KBD_TIM ,
|
|
|
|
BXP_KBD_AUXB,
|
|
|
|
BXP_KBD_KEYL,
|
|
|
|
BXP_KBD_C_D,
|
|
|
|
BXP_KBD_SYSF,
|
|
|
|
BXP_KBD_INPB,
|
|
|
|
BXP_KBD_OUTB,
|
|
|
|
BXP_KBD_TIMER_PENDING,
|
|
|
|
BXP_KBD_IRQ1_REQ,
|
|
|
|
BXP_KBD_IRQ12_REQ,
|
2002-09-16 19:28:19 +04:00
|
|
|
#if BX_DEBUGGER
|
- 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
|
|
|
// in debugger, is the simulation running (continue command) or waiting.
|
|
|
|
// This is only modified by debugger code, not by the user.
|
|
|
|
BXP_DEBUG_RUNNING,
|
2002-09-16 19:28:19 +04:00
|
|
|
#endif
|
2002-10-25 01:07:56 +04:00
|
|
|
BXP_SEL_CONFIG_INTERFACE,
|
|
|
|
BXP_SEL_DISPLAY_LIBRARY,
|
2004-02-22 21:51:38 +03:00
|
|
|
BXP_DISPLAYLIB_OPTIONS,
|
2001-06-18 18:11:55 +04:00
|
|
|
BXP_THIS_IS_THE_LAST // used to determine length of list
|
2001-06-16 03:52:34 +04:00
|
|
|
} bx_id;
|
|
|
|
|
2002-09-03 12:46:30 +04:00
|
|
|
// use x=1,2,3,4
|
|
|
|
#define BXP_COMx_ENABLED(x) \
|
|
|
|
(bx_id)(BXP_COM1_ENABLED + (((x)-1)*BXP_PARAMS_PER_SERIAL_PORT))
|
2004-07-28 23:36:42 +04:00
|
|
|
#define BXP_COMx_MODE(x) \
|
|
|
|
(bx_id)(BXP_COM1_MODE + (((x)-1)*BXP_PARAMS_PER_SERIAL_PORT))
|
2002-09-03 12:46:30 +04:00
|
|
|
#define BXP_COMx_PATH(x) \
|
|
|
|
(bx_id)(BXP_COM1_PATH + (((x)-1)*BXP_PARAMS_PER_SERIAL_PORT))
|
2003-01-28 19:58:10 +03:00
|
|
|
|
|
|
|
// use x=1
|
|
|
|
#define BXP_USBx_ENABLED(x) \
|
|
|
|
(bx_id)(BXP_USB1_ENABLED + (((x)-1)*BXP_PARAMS_PER_USB_HUB))
|
|
|
|
#define BXP_USBx_IOADDR(x) \
|
|
|
|
(bx_id)(BXP_USB1_IOADDR + (((x)-1)*BXP_PARAMS_PER_USB_HUB))
|
|
|
|
#define BXP_USBx_IRQ(x) \
|
|
|
|
(bx_id)(BXP_USB1_IRQ + (((x)-1)*BXP_PARAMS_PER_USB_HUB))
|
|
|
|
|
2002-09-03 12:46:30 +04:00
|
|
|
// use x=1,2
|
|
|
|
#define BXP_PARPORTx_ENABLED(x) \
|
|
|
|
(bx_id)(BXP_PARPORT1_ENABLED + (((x)-1)*BXP_PARAMS_PER_PARALLEL_PORT))
|
|
|
|
#define BXP_PARPORTx_OUTFILE(x) \
|
|
|
|
(bx_id)(BXP_PARPORT1_OUTFILE + (((x)-1)*BXP_PARAMS_PER_PARALLEL_PORT))
|
|
|
|
|
2004-06-29 23:24:34 +04:00
|
|
|
// use x=1,2,3,4,5
|
|
|
|
#define BXP_PCISLOTx_USED(x) \
|
|
|
|
(bx_id)(BXP_PCI_SLOT1_USED + (((x)-1)*BXP_PARAMS_PER_PCI_SLOT))
|
|
|
|
#define BXP_PCISLOTx_DEVNAME(x) \
|
|
|
|
(bx_id)(BXP_PCI_SLOT1_DEVNAME + (((x)-1)*BXP_PARAMS_PER_PCI_SLOT))
|
|
|
|
|
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,
|
|
|
|
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:
|
|
|
|
//
|
2002-08-29 18:59:37 +04:00
|
|
|
// async event: In the wxWindows implementation, both 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
|
|
|
// VGAW operate in the wxWindows GUI thread. When the user presses a
|
|
|
|
// key, wxWindows sends a wxKeyEvent to the VGAW event handler code in
|
|
|
|
// 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
|
|
|
|
// the simulator, then the VGAW handler returns. (With wxWindows and
|
|
|
|
// 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
|
|
|
|
// events aren't implemented in our wxWindows 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,
|
|
|
|
BX_LOG_ASK_N_CHOICES
|
|
|
|
};
|
- 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:
|
|
|
|
bx_id id;
|
2002-04-18 04:22:20 +04:00
|
|
|
bx_objtype type;
|
2001-06-16 03:52:34 +04:00
|
|
|
protected:
|
2002-04-18 04:22:20 +04:00
|
|
|
void set_type (bx_objtype type);
|
2001-06-16 03:52:34 +04:00
|
|
|
public:
|
|
|
|
bx_object_c (bx_id id);
|
|
|
|
bx_id get_id () { return id; }
|
|
|
|
Bit8u get_type () { return type; }
|
|
|
|
};
|
|
|
|
|
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:
|
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.
|
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:
|
2002-04-18 04:22:20 +04:00
|
|
|
bx_param_c (bx_id id, char *name, char *description);
|
- 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
|
|
|
void set_format (const char *format) {text_format = format;}
|
|
|
|
const char *get_format () {return text_format;}
|
2001-06-18 18:11:55 +04:00
|
|
|
void set_ask_format (char *format) {ask_format = format; }
|
|
|
|
char *get_ask_format () {return ask_format;}
|
2003-08-30 15:21:56 +04:00
|
|
|
void set_label (char *text) {label = text;}
|
|
|
|
char *get_label () {return label;}
|
2001-06-18 18:11:55 +04:00
|
|
|
void set_runtime_param (int val) { runtime_param = val; }
|
2003-09-02 23:34:48 +04:00
|
|
|
int get_runtime_param () { return runtime_param; }
|
2004-05-30 12:28:52 +04:00
|
|
|
void set_group (char *group) {group_name = group;}
|
|
|
|
char *get_group () {return group_name;}
|
2001-06-16 03:52:34 +04:00
|
|
|
char *get_name () { return name; }
|
|
|
|
char *get_description () { return description; }
|
2001-06-21 18:37:55 +04:00
|
|
|
int get_enabled () { return enabled; }
|
2002-09-23 00:56:12 +04:00
|
|
|
virtual void set_enabled (int enabled) { this->enabled = enabled; }
|
2001-06-16 03:52:34 +04:00
|
|
|
void reset () {}
|
2001-06-16 23:29:59 +04:00
|
|
|
int getint () {return -1;}
|
- 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
|
|
|
static const char* set_default_format (const char *f);
|
|
|
|
static const char *get_default_format () { return default_text_format; }
|
2002-09-23 00:56:12 +04:00
|
|
|
virtual bx_list_c *get_dependent_list () { return NULL; }
|
2004-01-29 21:50:33 +03:00
|
|
|
#if BX_USE_TEXTCONFIG
|
2001-06-18 18:11:55 +04:00
|
|
|
virtual void text_print (FILE *fp) {}
|
2001-06-22 17:37:08 +04:00
|
|
|
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);
|
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;
|
|
|
|
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;
|
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;
|
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;
|
2001-06-16 03:52:34 +04:00
|
|
|
bx_param_num_c (bx_id id,
|
|
|
|
char *name,
|
|
|
|
char *description,
|
- 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, Bit64s max, Bit64s initial_val);
|
2001-06-16 03:52:34 +04:00
|
|
|
void reset ();
|
2001-06-21 18:37:55 +04:00
|
|
|
void set_handler (param_event_handler handler);
|
2003-08-10 02:17:38 +04:00
|
|
|
void set_enable_handler (param_enable_handler handler);
|
2002-09-23 00:56:12 +04:00
|
|
|
virtual bx_list_c *get_dependent_list () { return dependent_list; }
|
- 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
|
|
|
void set_dependent_list (bx_list_c *l);
|
2002-09-23 00:56:12 +04:00
|
|
|
virtual void set_enabled (int enabled);
|
2002-10-21 05:05:53 +04:00
|
|
|
virtual Bit32s get () { return (Bit32s) get64(); }
|
|
|
|
virtual Bit64s get64 ();
|
- 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
|
|
|
virtual void set (Bit64s val);
|
2001-06-18 18:11:55 +04:00
|
|
|
void set_base (int base) { this->base = base; }
|
- 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
|
|
|
void set_initial_val (Bit64s initial_val);
|
2002-04-18 04:22:20 +04:00
|
|
|
int get_base () { return base; }
|
- 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
|
|
|
void set_range (Bit64u min, Bit64u max);
|
|
|
|
Bit64s get_min () { return min; }
|
|
|
|
Bit64s get_max () { return max; }
|
- 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
|
|
|
static Bit32u set_default_base (Bit32u val);
|
|
|
|
static Bit32u get_default_base () { return default_base; }
|
2003-09-06 02:07:54 +04:00
|
|
|
void set_options (Bit32u options) { this->options = options; }
|
|
|
|
Bit32u get_options () { return options; }
|
2004-01-29 21:50:33 +03:00
|
|
|
#if BX_USE_TEXTCONFIG
|
2001-06-18 18:11:55 +04:00
|
|
|
virtual void text_print (FILE *fp);
|
|
|
|
virtual int text_ask (FILE *fpin, FILE *fpout);
|
|
|
|
#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
|
|
|
|
// existing variables as parameters, without have to access it via
|
|
|
|
// 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:
|
|
|
|
bx_shadow_num_c (bx_id id,
|
|
|
|
char *name,
|
|
|
|
char *description,
|
- 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,
|
|
|
|
Bit8u highbit = 63,
|
|
|
|
Bit8u lowbit = 0);
|
|
|
|
bx_shadow_num_c (bx_id id,
|
|
|
|
char *name,
|
|
|
|
char *description,
|
|
|
|
Bit64u *ptr_to_real_val,
|
|
|
|
Bit8u highbit = 63,
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit8u lowbit = 0);
|
- 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_shadow_num_c (bx_id id,
|
|
|
|
char *name,
|
|
|
|
char *description,
|
- 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,
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit8u highbit = 31,
|
|
|
|
Bit8u lowbit = 0);
|
- 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_shadow_num_c (bx_id id,
|
|
|
|
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
|
|
|
char *description,
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit32u *ptr_to_real_val,
|
|
|
|
Bit8u highbit = 31,
|
|
|
|
Bit8u lowbit = 0);
|
|
|
|
bx_shadow_num_c (bx_id id,
|
|
|
|
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
|
|
|
char *description,
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit16s *ptr_to_real_val,
|
|
|
|
Bit8u highbit = 15,
|
|
|
|
Bit8u lowbit = 0);
|
|
|
|
bx_shadow_num_c (bx_id id,
|
|
|
|
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
|
|
|
char *description,
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit16u *ptr_to_real_val,
|
|
|
|
Bit8u highbit = 15,
|
|
|
|
Bit8u lowbit = 0);
|
- 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
|
|
|
bx_shadow_num_c (bx_id id,
|
|
|
|
char *name,
|
|
|
|
char *description,
|
|
|
|
Bit8s *ptr_to_real_val,
|
|
|
|
Bit8u highbit = 7,
|
|
|
|
Bit8u lowbit = 0);
|
|
|
|
bx_shadow_num_c (bx_id id,
|
|
|
|
char *name,
|
|
|
|
char *description,
|
|
|
|
Bit8u *ptr_to_real_val,
|
|
|
|
Bit8u highbit = 7,
|
|
|
|
Bit8u lowbit = 0);
|
2002-10-21 05:05:53 +04:00
|
|
|
virtual Bit64s get64 ();
|
- 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
|
|
|
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_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:
|
|
|
|
bx_param_bool_c (bx_id id,
|
|
|
|
char *name,
|
|
|
|
char *description,
|
- 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 initial_val);
|
2004-01-29 21:50:33 +03:00
|
|
|
#if BX_USE_TEXTCONFIG
|
2001-06-20 18:01:39 +04:00
|
|
|
virtual void text_print (FILE *fp);
|
|
|
|
virtual int text_ask (FILE *fpin, FILE *fpout);
|
|
|
|
#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:
|
|
|
|
bx_shadow_bool_c (bx_id id,
|
|
|
|
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
|
|
|
char *description,
|
2002-10-25 15:44:41 +04:00
|
|
|
bx_bool *ptr_to_real_val,
|
2002-09-11 07:53:48 +04:00
|
|
|
Bit8u bitnum = 0);
|
2002-10-21 05:05:53 +04:00
|
|
|
virtual Bit64s get64 ();
|
- 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
|
|
|
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:
|
|
|
|
bx_param_enum_c (bx_id id,
|
|
|
|
char *name,
|
|
|
|
char *description,
|
|
|
|
char **choices,
|
- 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 initial_val,
|
|
|
|
Bit64s value_base = 0);
|
2002-04-18 04:22:20 +04:00
|
|
|
char *get_choice (int n) { return choices[n]; }
|
2002-10-25 01:07:56 +04:00
|
|
|
int find_by_name (const char *string);
|
|
|
|
bool set_by_name (const char *string);
|
2004-01-29 21:50:33 +03:00
|
|
|
#if BX_USE_TEXTCONFIG
|
2001-06-21 18:37:55 +04:00
|
|
|
virtual void text_print (FILE *fp);
|
|
|
|
virtual int text_ask (FILE *fpin, FILE *fpout);
|
2001-06-20 18:01:39 +04:00
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
2001-06-21 18:37:55 +04:00
|
|
|
typedef char* (*param_string_event_handler)(class bx_param_string_c *, int set, 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.
|
|
|
|
SAVE_FILE_DIALOG = 4 // Use save dialog opposed to open file dialog
|
2001-06-21 23:27:05 +04:00
|
|
|
} bx_string_opt_bits;
|
2001-06-16 23:29:59 +04:00
|
|
|
bx_param_string_c (bx_id id,
|
|
|
|
char *name,
|
|
|
|
char *description,
|
2001-06-18 18:11:55 +04:00
|
|
|
char *initial_val,
|
|
|
|
int maxsize=-1);
|
2001-12-22 23:58:25 +03:00
|
|
|
virtual ~bx_param_string_c ();
|
2001-06-16 23:29:59 +04:00
|
|
|
void reset ();
|
2001-06-21 18:37:55 +04:00
|
|
|
void set_handler (param_string_event_handler handler);
|
2003-08-10 02:17:38 +04:00
|
|
|
void set_enable_handler (param_enable_handler handler);
|
|
|
|
virtual void set_enabled (int enabled);
|
2001-06-16 23:29:59 +04:00
|
|
|
Bit32s get (char *buf, int len);
|
|
|
|
char *getptr () {return val; }
|
|
|
|
void set (char *buf);
|
2002-12-12 21:31:20 +03:00
|
|
|
bx_bool equals (const char *buf);
|
2001-06-21 23:27:05 +04:00
|
|
|
bx_param_num_c *get_options () { return options; }
|
|
|
|
void set_separator (char sep) {separator = sep; }
|
2003-08-25 19:21:19 +04:00
|
|
|
char get_separator () {return separator; }
|
|
|
|
int get_maxsize () {return maxsize; }
|
2004-01-29 21:50:33 +03:00
|
|
|
#if BX_USE_TEXTCONFIG
|
2001-06-18 18:11:55 +04:00
|
|
|
virtual void text_print (FILE *fp);
|
|
|
|
virtual int text_ask (FILE *fpin, FILE *fpout);
|
|
|
|
#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:
|
|
|
|
bx_param_filename_c (bx_id id,
|
|
|
|
char *name,
|
|
|
|
char *description,
|
|
|
|
char *initial_val,
|
|
|
|
int maxsize=-1);
|
|
|
|
};
|
|
|
|
|
2002-10-25 01:07:56 +04:00
|
|
|
class BOCHSAPI bx_list_c : public bx_param_c {
|
2001-06-16 03:52:34 +04:00
|
|
|
private:
|
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;
|
|
|
|
// if the menu shows a "return to previous menu" type of choice,
|
|
|
|
// this controls where that choice will go.
|
|
|
|
bx_param_c *parent;
|
|
|
|
void init ();
|
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;
|
2002-09-03 12:46:30 +04:00
|
|
|
bx_list_c (bx_id id, int maxsize);
|
2001-06-21 18:37:55 +04:00
|
|
|
bx_list_c (bx_id id, char *name, char *description, bx_param_c **init_list);
|
- 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_list_c (bx_id id, char *name, char *description, int maxsize);
|
2001-12-22 23:58:25 +03:00
|
|
|
virtual ~bx_list_c();
|
2002-09-23 00:56:12 +04:00
|
|
|
bx_list_c *clone ();
|
2001-06-18 18:11:55 +04:00
|
|
|
void add (bx_param_c *param);
|
|
|
|
bx_param_c *get (int index);
|
2002-09-03 09:31:42 +04:00
|
|
|
int get_size () { return size; }
|
2001-06-18 18:11:55 +04:00
|
|
|
bx_param_num_c *get_options () { return options; }
|
2002-09-23 00:56:12 +04:00
|
|
|
void set_options (bx_param_num_c *newopt) { options = newopt; }
|
2001-06-18 18:11:55 +04:00
|
|
|
bx_param_num_c *get_choice () { return choice; }
|
|
|
|
bx_param_string_c *get_title () { return title; }
|
2002-09-23 00:56:12 +04:00
|
|
|
void set_parent (bx_param_c *newparent) { parent = newparent; }
|
|
|
|
bx_param_c *get_parent () { return parent; }
|
2004-01-29 21:50:33 +03:00
|
|
|
#if BX_USE_TEXTCONFIG
|
2001-06-18 18:11:55 +04:00
|
|
|
virtual void text_print (FILE *);
|
|
|
|
virtual int text_ask (FILE *fpin, FILE *fpout);
|
|
|
|
#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
|
|
|
|
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
|
|
|
|
|
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
|
2003-08-22 05:00:58 +04:00
|
|
|
#define BX_ATA_MODE_UNDOABLE 6
|
|
|
|
#define BX_ATA_MODE_GROWING 7
|
|
|
|
#define BX_ATA_MODE_VOLATILE 8
|
2004-01-06 01:18:01 +03:00
|
|
|
#define BX_ATA_MODE_LAST 8
|
|
|
|
//#define BX_ATA_MODE_Z_UNDOABLE 9
|
|
|
|
//#define BX_ATA_MODE_Z_VOLATILE 10
|
|
|
|
//#define BX_ATA_MODE_SPLIT 6
|
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 int n_bochs_start_names;
|
|
|
|
BOCHSAPI extern char *floppy_type_names[];
|
|
|
|
BOCHSAPI extern int floppy_type_n_sectors[];
|
|
|
|
BOCHSAPI extern int n_floppy_type_names;
|
|
|
|
BOCHSAPI extern char *floppy_status_names[];
|
|
|
|
BOCHSAPI extern int n_floppy_status_names;
|
2004-10-16 19:44:00 +04:00
|
|
|
BOCHSAPI extern char *bochs_bootdisk_names[];
|
|
|
|
BOCHSAPI extern int n_bochs_bootdisk_names;
|
2002-11-14 08:14:10 +03:00
|
|
|
BOCHSAPI extern char *loader_os_names[];
|
|
|
|
BOCHSAPI extern int n_loader_os_names;
|
|
|
|
BOCHSAPI extern char *keyboard_type_names[];
|
|
|
|
BOCHSAPI extern int n_keyboard_type_names;
|
|
|
|
BOCHSAPI extern char *atadevice_type_names[];
|
|
|
|
BOCHSAPI extern int n_atadevice_type_names;
|
2003-05-03 20:37:18 +04:00
|
|
|
BOCHSAPI extern char *atadevice_mode_names[];
|
|
|
|
BOCHSAPI extern int n_atadevice_mode_names;
|
2002-11-14 08:14:10 +03:00
|
|
|
BOCHSAPI extern char *atadevice_status_names[];
|
|
|
|
BOCHSAPI extern int n_atadevice_status_names;
|
|
|
|
BOCHSAPI extern char *atadevice_biosdetect_names[];
|
|
|
|
BOCHSAPI extern int n_atadevice_biosdetect_names;
|
|
|
|
BOCHSAPI extern char *atadevice_translation_names[];
|
|
|
|
BOCHSAPI extern int n_atadevice_translation_names;
|
2003-08-19 04:10:39 +04:00
|
|
|
BOCHSAPI extern char *clock_sync_names[];
|
|
|
|
BOCHSAPI extern int clock_sync_n_names;
|
2001-06-20 18:01:39 +04:00
|
|
|
|
|
|
|
typedef struct {
|
2002-08-04 12:42:34 +04:00
|
|
|
bx_param_enum_c *Odevtype;
|
2001-06-20 18:01:39 +04:00
|
|
|
bx_param_string_c *Opath;
|
|
|
|
bx_param_enum_c *Otype;
|
2002-08-04 12:42:34 +04:00
|
|
|
bx_param_enum_c *Ostatus;
|
2001-06-20 18:01:39 +04:00
|
|
|
} bx_floppy_options;
|
|
|
|
|
|
|
|
typedef struct {
|
2002-09-23 00:56:12 +04:00
|
|
|
bx_list_c *Omenu;
|
2001-06-20 18:01:39 +04:00
|
|
|
bx_param_bool_c *Opresent;
|
2002-09-23 00:56:12 +04:00
|
|
|
bx_param_enum_c *Otype;
|
2003-05-03 20:37:18 +04:00
|
|
|
bx_param_enum_c *Omode;
|
2001-06-20 18:01:39 +04:00
|
|
|
bx_param_string_c *Opath;
|
2003-08-10 02:17:38 +04:00
|
|
|
bx_param_string_c *Ojournal;
|
2001-06-20 18:01:39 +04:00
|
|
|
bx_param_num_c *Ocylinders;
|
|
|
|
bx_param_num_c *Oheads;
|
|
|
|
bx_param_num_c *Ospt;
|
2002-09-23 00:56:12 +04:00
|
|
|
bx_param_enum_c *Ostatus;
|
|
|
|
bx_param_string_c *Omodel;
|
|
|
|
bx_param_enum_c *Obiosdetect;
|
|
|
|
bx_param_enum_c *Otranslation;
|
|
|
|
} bx_atadevice_options;
|
2001-06-20 18:01:39 +04:00
|
|
|
|
2002-03-03 09:03:29 +03:00
|
|
|
typedef struct {
|
2002-08-24 21:11:33 +04:00
|
|
|
bx_param_bool_c *Oenabled;
|
2004-07-28 23:36:42 +04:00
|
|
|
bx_param_enum_c *Omode;
|
2002-03-03 09:03:29 +03:00
|
|
|
bx_param_string_c *Odev;
|
|
|
|
} bx_serial_options;
|
|
|
|
|
2003-01-28 19:58:10 +03:00
|
|
|
typedef struct {
|
|
|
|
bx_param_bool_c *Oenabled;
|
|
|
|
bx_param_num_c *Oioaddr;
|
|
|
|
bx_param_num_c *Oirq;
|
|
|
|
} bx_usb_options;
|
|
|
|
|
2004-01-13 22:21:21 +03:00
|
|
|
typedef struct {
|
|
|
|
bx_param_bool_c *Oenabled;
|
|
|
|
bx_param_num_c *Oioaddr;
|
|
|
|
bx_param_num_c *Oirq;
|
|
|
|
bx_param_string_c *Omacaddr;
|
|
|
|
bx_param_enum_c *Oethmod;
|
|
|
|
bx_param_string_c *Oethdev;
|
|
|
|
bx_param_string_c *Oscript;
|
|
|
|
} bx_pnic_options;
|
2001-06-18 18:11:55 +04:00
|
|
|
|
2004-06-29 23:24:34 +04:00
|
|
|
typedef struct {
|
|
|
|
bx_param_bool_c *Oused;
|
|
|
|
bx_param_string_c *Odevname;
|
|
|
|
} bx_pcislot_options;
|
|
|
|
|
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>
|
|
|
|
|
2002-10-25 01:07:56 +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);
|
|
|
|
|
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:
|
|
|
|
bx_simulator_interface_c ();
|
- 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
|
|
|
virtual void set_quit_context (jmp_buf *context) {}
|
2001-06-18 18:11:55 +04:00
|
|
|
virtual int get_init_done () { return -1; }
|
|
|
|
virtual int set_init_done (int n) {return -1;}
|
2002-04-18 04:22:20 +04:00
|
|
|
virtual void get_param_id_range (int *min, int *max) {}
|
2001-06-18 18:11:55 +04:00
|
|
|
virtual int register_param (bx_id id, bx_param_c *it) {return -1;}
|
2002-08-30 20:23:36 +04:00
|
|
|
virtual void reset_all_param () {}
|
2001-06-16 23:29:59 +04:00
|
|
|
virtual bx_param_c *get_param (bx_id id) {return NULL;}
|
|
|
|
virtual bx_param_num_c *get_param_num (bx_id id) {return NULL;}
|
2001-06-17 03:08:32 +04:00
|
|
|
virtual bx_param_string_c *get_param_string (bx_id id) {return NULL;}
|
2002-09-05 11:01:30 +04:00
|
|
|
virtual bx_param_bool_c *get_param_bool (bx_id id) {return NULL;}
|
2002-09-23 00:56:12 +04:00
|
|
|
virtual bx_param_enum_c *get_param_enum (bx_id id) {return NULL;}
|
2001-06-08 11:20:07 +04: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) {}
|
- How to handle default log options has been somewhat confused for a long
time, so I've tried to improve it. Now the logfunctions class has a
static field default_onoff[] which represents the default actions for
each kind of log message. Default_onoff[] is initialized with static
data so it should be valid by the time it's used. This can be reached by
static accesors logfunctions::set_default_action and
logfunctions::get_default_action. It seemed appropriate to put the defaults
inside the logfunctions class, rather than in bx_options or siminterface.
However, to make them accessible to the config interface, I added similar
methods in siminterface that map to the accessors in logfunctions.
- logio.cc had two different definitions of LOG_THIS for different halves
of the file, which was ugly and confusing. (LOG_THIS is needed for BX_INFO,
BX_DEBUG, etc.) I removed the first definition and fixed the minor compile
problems that ensued. In the initializers for iofunctions, everything
is complicated because of the unpredictable order that constructors get
called. They must use this->log to print things, because genlog hasn't
been initialized yet.
- now if SIM->set_log_action(int mod, int level, int action) is called
with mod<0, it sets the action for all modules/devices instead of just one.
- modified: bochs.h logio.cc main.cc gui/siminterface.cc gui/siminterface.h
2002-09-20 21:56:22 +04:00
|
|
|
virtual int get_default_log_action (int level) {return -1;}
|
|
|
|
virtual void set_default_log_action (int level, int action) {}
|
2001-06-08 11:20:07 +04:00
|
|
|
virtual char *get_action_name (int action) {return 0;}
|
2001-11-14 03:23:08 +03:00
|
|
|
virtual const char *get_log_level_name (int level) {return 0;}
|
2001-06-08 11:20:07 +04:00
|
|
|
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.
|
2002-04-18 04:22:20 +04:00
|
|
|
virtual void quit_sim (int code) {}
|
|
|
|
|
2002-12-16 09:43:02 +03:00
|
|
|
virtual int get_exit_code () { return 0; }
|
|
|
|
|
2001-06-12 00:27:23 +04:00
|
|
|
virtual int get_default_rc (char *path, int len) {return -1;}
|
2001-06-10 00:01:12 +04:00
|
|
|
virtual int read_rc (char *path) {return -1;}
|
2001-06-11 10:35:18 +04:00
|
|
|
virtual int write_rc (char *rc, int overwrite) {return -1;}
|
2001-06-12 00:27:23 +04:00
|
|
|
virtual int get_log_file (char *path, int len) {return -1;}
|
2001-06-10 00:01:12 +04:00
|
|
|
virtual int set_log_file (char *path) {return -1;}
|
2002-06-26 18:42:35 +04:00
|
|
|
virtual int get_log_prefix (char *prefix, int len) {return -1;}
|
|
|
|
virtual int set_log_prefix (char *prefix) {return -1;}
|
2002-12-03 00:26:05 +03:00
|
|
|
virtual int get_debugger_log_file (char *path, int len) {return -1;}
|
|
|
|
virtual int set_debugger_log_file (char *path) {return -1;}
|
2001-06-10 00:01:12 +04:00
|
|
|
virtual int get_floppy_options (int drive, bx_floppy_options *out) {return -1;}
|
2002-09-23 00:56:12 +04:00
|
|
|
virtual int get_cdrom_options (int drive, bx_atadevice_options *out, int *where = NULL) {return -1;}
|
2001-06-10 00:01:12 +04:00
|
|
|
virtual char *get_floppy_type_name (int type) {return NULL;}
|
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.
|
2002-10-25 01:07:56 +04:00
|
|
|
typedef BxEvent* (*bxevent_handler)(void *theclass, BxEvent *event);
|
|
|
|
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.
|
|
|
|
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
|
- 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
|
|
|
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.
|
2002-04-18 04:22:20 +04:00
|
|
|
virtual int ask_param (bx_id param) {return -1;}
|
|
|
|
|
|
|
|
// ask the user for a pathname
|
|
|
|
virtual int ask_filename (char *filename, int maxlen, char *prompt, char *the_default, int flags) {return -1;}
|
|
|
|
// called at a regular interval, currently by the keyboard handler.
|
|
|
|
virtual void periodic () {}
|
2002-10-25 15:44:41 +04:00
|
|
|
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.
|
|
|
|
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.
|
|
|
|
virtual void refresh_vga () {}
|
|
|
|
// 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.
|
|
|
|
virtual void handle_events () {}
|
2002-12-07 22:43:53 +03:00
|
|
|
// return first hard disk in ATA interface
|
|
|
|
virtual bx_param_c *get_first_cdrom () {return NULL;}
|
2002-09-23 00:56:12 +04:00
|
|
|
// return first cdrom in ATA interface
|
2002-12-07 22:43:53 +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
|
|
|
|
virtual void debug_break () {}
|
|
|
|
virtual void debug_interpret_cmd (char *cmd) {}
|
|
|
|
virtual char *debug_get_next_command () {return NULL;}
|
2002-09-16 17:04:13 +04:00
|
|
|
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
|
2002-10-25 01:07:56 +04:00
|
|
|
virtual void register_configuration_interface (
|
|
|
|
const char* name,
|
|
|
|
config_interface_callback_t callback,
|
|
|
|
void *userdata) {}
|
|
|
|
virtual int configuration_interface(const char* name, ci_command_t command) {return -1; }
|
|
|
|
virtual int begin_simulation (int argc, char *argv[]) {return -1;}
|
|
|
|
typedef bool (*is_sim_thread_func_t)();
|
|
|
|
is_sim_thread_func_t is_sim_thread_func;
|
|
|
|
virtual void set_sim_thread_func (is_sim_thread_func_t func) {
|
|
|
|
is_sim_thread_func = func;
|
|
|
|
}
|
|
|
|
virtual bool is_sim_thread () {return true;}
|
2002-11-19 12:27:39 +03:00
|
|
|
virtual bool is_wx_selected () {return false;}
|
2002-12-06 22:34:32 +03:00
|
|
|
// provide interface to bx_gui->set_display_mode() method for config
|
|
|
|
// interfaces to use.
|
|
|
|
virtual void set_display_mode (disp_mode_t newmode) {}
|
2002-12-17 08:58:45 +03:00
|
|
|
virtual bool test_for_text_console () { return true; }
|
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
|
|
|
|
2002-10-25 01:07:56 +04: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__
|
|
|
|
// these are only used when compiling with wxWindows. This gives us a
|
|
|
|
// 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;
|