- 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
/////////////////////////////////////////////////////////////////
2006-09-09 12:05:07 +04:00
// $Id: wxmain.cc,v 1.147 2006-09-09 08:05:07 vruppert Exp $
- 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
//
2004-10-03 13:11:28 +04:00
// wxmain.cc implements the wxWidgets frame, toolbar, menus, and dialogs.
2002-04-18 04:22:20 +04:00
// When the application starts, the user is given a chance to choose/edit/save
// a configuration. When they decide to start the simulation, functions in
// main.cc are called in a separate thread to initialize and run the Bochs
// simulator.
//
- 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
// Most ports to different platforms implement only the VGA window and
2004-10-03 13:11:28 +04:00
// toolbar buttons. The wxWidgets port is the first to implement both
- 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 VGA display and the configuration interface, so the boundaries
// between them are somewhat blurry. See the extensive comments at
// the top of siminterface for the rationale behind this separation.
//
// The separation between wxmain.cc and wx.cc is as follows:
2002-08-29 18:59:37 +04:00
// - wxmain.cc implements a Bochs configuration interface (CI),
2004-10-03 13:11:28 +04:00
// which is the wxWidgets equivalent of textconfig.cc. wxmain creates
- 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 frame with several menus and a toolbar, and allows the user to
// choose the machine configuration and start the simulation. Note
// that wxmain.cc does NOT include bochs.h. All interactions
2002-08-29 18:59:37 +04:00
// between the CI and the simulator are through the siminterface
- 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
// object.
2004-10-03 13:11:28 +04:00
// - wx.cc implements a VGA display screen using wxWidgets. It is
// is the wxWidgets equivalent of x.cc, win32.cc, macos.cc, etc.
2002-04-18 04:22:20 +04:00
// wx.cc includes bochs.h and has access to all Bochs devices.
// The VGA panel accepts only paint, key, and mouse events. As it
// receives events, it builds BxEvents and places them into a
// thread-safe BxEvent queue. The simulation thread periodically
// processes events from the BxEvent queue (bx_gui_c::handle_events)
// and notifies the appropriate emulated I/O device.
//
- 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
//////////////////////////////////////////////////////////////////////
// includes
//////////////////////////////////////////////////////////////////////
2002-10-25 01:07:56 +04:00
// Define BX_PLUGGABLE in files that can be compiled into plugins. For
// platforms that require a special tag on exported symbols, BX_PLUGGABLE
// is used to know when we are exporting symbols and when we are importing.
# define BX_PLUGGABLE
2002-11-19 08:47:45 +03:00
# include "config.h" // definitions based on configure script
# if BX_WITH_WX
2002-04-18 04:22:20 +04:00
// For compilers that support precompilation, includes "wx/wx.h".
2002-08-30 11:03:50 +04:00
# include <wx/wxprec.h>
2002-04-18 04:22:20 +04:00
# ifdef __BORLANDC__
# pragma hdrstop
# endif
# ifndef WX_PRECOMP
2002-08-30 11:03:50 +04:00
# include <wx/wx.h>
2002-04-18 04:22:20 +04:00
# endif
2002-08-30 11:03:50 +04:00
# include <wx/image.h>
2002-09-05 17:38:44 +04:00
# include <wx/clipbrd.h>
2002-04-18 04:22:20 +04:00
# include "osdep.h" // workarounds for missing stuff
# include "gui/siminterface.h" // interface to the simulator
# include "bxversion.h" // get version string
2002-08-28 07:20:23 +04:00
# include "wxdialog.h" // custom dialog boxes
2004-10-03 13:11:28 +04:00
# include "wxmain.h" // wxwidgets shared stuff
2002-10-25 01:07:56 +04:00
# include "extplugin.h"
2002-04-18 04:22:20 +04:00
// include XPM icons
# include "bitmaps/cdromd.xpm"
# include "bitmaps/copy.xpm"
# include "bitmaps/floppya.xpm"
# include "bitmaps/floppyb.xpm"
# include "bitmaps/paste.xpm"
# include "bitmaps/power.xpm"
# include "bitmaps/reset.xpm"
# include "bitmaps/snapshot.xpm"
# include "bitmaps/mouse.xpm"
2002-09-06 19:00:54 +04:00
//#include "bitmaps/configbutton.xpm"
2002-08-09 10:16:43 +04:00
# include "bitmaps/userbutton.xpm"
2006-06-07 02:11:09 +04:00
# if BX_SUPPORT_SAVE_RESTORE
# include "bitmaps/saverestore.xpm"
# endif
2002-12-25 20:13:45 +03:00
# ifdef __WXGTK__
# include "icon_bochs.xpm"
# endif
2002-04-18 04:22:20 +04:00
// FIXME: ugly global variables that the bx_gui_c object in wx.cc can use
// to access the MyFrame and the MyPanel.
MyFrame * theFrame = NULL ;
MyPanel * thePanel = NULL ;
2004-10-03 13:11:28 +04:00
// The wxBochsClosing flag is used to keep track of when the wxWidgets GUI is
2002-10-07 08:01:00 +04:00
// shutting down. Shutting down can be somewhat complicated because the
// simulation may be running for a while in another thread before it realizes
// that it should shut down. The wxBochsClosing flag is a global variable, as
// opposed to a field of some C++ object, so that it will be valid at any stage
// of the program. wxBochsClosing starts out false (not wxBochsClosing). When
// the GUI decides to shut down, it sets wxBochsClosing=true. If there
// is not a simulation running, everything is quite simple and it can just
// call Close(TRUE). If a simulation is running, it calls OnKillSim to
// ask the simulation to stop. When the simulation thread stops, it calls
// Close(TRUE) on the frame. During the time that the simulation is
// still running and afterward, the wxBochsClosing flag is used to suppress
// any events that might reference parts of the GUI or create new dialogs.
bool wxBochsClosing = false ;
2006-09-03 15:06:54 +04:00
// The wxBochsStopSim flag is used to select the right way when the simulation
// thread stops. It is set to 'true' when the stop simulation menu item is
// clicked instead of the power button.
bool wxBochsStopSim = false ;
2006-03-19 18:35:20 +03:00
bool isSimThread ( ) {
2002-12-12 01:55:18 +03:00
if ( wxThread : : IsMain ( ) ) return false ;
2006-03-19 18:35:20 +03:00
wxThread * current = wxThread : : This ( ) ;
if ( current = = ( wxThread * ) theFrame - > GetSimThread ( ) ) {
// wxLogDebug("isSimThread? yes");
2002-09-05 11:48:39 +04:00
return true ;
}
2006-03-19 18:35:20 +03:00
// wxLogDebug("isSimThread? no");
2002-09-05 11:48:39 +04:00
return false ;
}
2002-04-18 04:22:20 +04:00
//////////////////////////////////////////////////////////////////////
// class declarations
//////////////////////////////////////////////////////////////////////
class MyApp : public wxApp
{
virtual bool OnInit ( ) ;
2002-09-21 01:25:09 +04:00
virtual int OnExit ( ) ;
2002-09-25 22:40:15 +04:00
public :
// This default callback is installed when the simthread is NOT running,
// so that events coming from the simulator code can be handled.
// The primary culprit is panics which cause an BX_SYNC_EVT_LOG_ASK.
2006-03-19 18:35:20 +03:00
static BxEvent * DefaultCallback ( void * thisptr , BxEvent * event ) ;
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
// SimThread is the thread in which the Bochs simulator runs. It is created
// by MyFrame::OnStartSim(). The SimThread::Entry() function calls a
// function in main.cc called bx_continue_after_config_interface() which
// initializes the devices and starts up the simulation. All events from
// the simulator
2002-04-18 04:22:20 +04:00
class SimThread : public wxThread
{
MyFrame * frame ;
// when the sim thread sends a synchronous event to the GUI thread, the
// response is stored in sim2gui_mailbox.
// FIXME: this would be cleaner and more reusable if I made a general
// thread-safe mailbox class.
BxEvent * sim2gui_mailbox ;
wxCriticalSection sim2gui_mailbox_lock ;
public :
2006-03-19 18:35:20 +03:00
SimThread ( MyFrame * _frame ) { frame = _frame ; sim2gui_mailbox = NULL ; }
virtual ExitCode Entry ( ) ;
void OnExit ( ) ;
2002-04-18 04:22:20 +04:00
// called by the siminterface code, with the pointer to the sim thread
// in the thisptr arg.
2006-03-19 18:35:20 +03:00
static BxEvent * SiminterfaceCallback ( void * thisptr , BxEvent * event ) ;
BxEvent * SiminterfaceCallback2 ( BxEvent * event ) ;
2002-04-18 04:22:20 +04:00
// methods to coordinate synchronous response mailbox
2006-03-19 18:35:20 +03:00
void ClearSyncResponse ( ) ;
void SendSyncResponse ( BxEvent * ) ;
BxEvent * GetSyncResponse ( ) ;
2002-04-18 04:22:20 +04:00
} ;
//////////////////////////////////////////////////////////////////////
2004-10-03 13:11:28 +04:00
// wxWidgets startup
2002-04-18 04:22:20 +04:00
//////////////////////////////////////////////////////////////////////
2006-03-19 18:35:20 +03:00
static int ci_callback ( void * userdata , ci_command_t command )
2002-10-25 01:07:56 +04:00
{
switch ( command )
{
2002-11-01 18:19:48 +03:00
case CI_START :
# ifdef __WXMSW__
2002-11-01 18:28:41 +03:00
// on Windows only, wxEntry needs some data that is passed into WinMain.
// So, in main.cc we define WinMain and fill in the bx_startup_flags
// structure with the data, so that when we're ready to call wxEntry
// it has access to the data.
2006-03-18 19:30:52 +03:00
wxEntry (
2002-11-01 18:28:41 +03:00
bx_startup_flags . hInstance ,
bx_startup_flags . hPrevInstance ,
bx_startup_flags . m_lpCmdLine ,
bx_startup_flags . nCmdShow ) ;
2002-11-01 18:19:48 +03:00
# else
2006-03-18 19:30:52 +03:00
wxEntry ( bx_startup_flags . argc , bx_startup_flags . argv ) ;
2002-11-01 18:19:48 +03:00
# endif
2002-10-25 01:07:56 +04:00
break ;
case CI_RUNTIME_CONFIG :
2006-03-18 19:30:52 +03:00
fprintf ( stderr , " wxmain.cc: runtime config not implemented \n " ) ;
2002-10-25 01:07:56 +04:00
break ;
case CI_SHUTDOWN :
2006-03-18 19:30:52 +03:00
fprintf ( stderr , " wxmain.cc: shutdown not implemented \n " ) ;
2002-10-25 01:07:56 +04:00
break ;
}
return 0 ;
}
2006-03-19 18:35:20 +03:00
extern " C " int libwx_LTX_plugin_init ( plugin_t * plugin , plugintype_t type ,
2002-10-25 01:07:56 +04:00
int argc , char * argv [ ] )
{
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " plugin_init for wxmain.cc " ) ) ;
wxLogDebug ( wxT ( " installing wxWidgets as the configuration interface " ) ) ;
SIM - > register_configuration_interface ( " wx " , ci_callback , NULL ) ;
wxLogDebug ( wxT ( " installing %s as the Bochs GUI " ) , wxT ( " wxWidgets " ) ) ;
2006-02-22 00:35:09 +03:00
SIM - > get_param_enum ( BXPN_SEL_DISPLAY_LIBRARY ) - > set_enabled ( 0 ) ;
2006-03-19 18:35:20 +03:00
MyPanel : : OnPluginInit ( ) ;
2006-04-16 14:12:32 +04:00
bx_list_c * list = new bx_list_c ( SIM - > get_param ( " . " ) ,
" wxdebug " ,
" subtree for the wx debugger " ,
30 ) ;
bx_list_c * cpu = new bx_list_c ( list ,
" cpu " ,
" CPU State " ,
BX_MAX_SMP_THREADS_SUPPORTED ) ;
cpu - > get_options ( ) - > set ( bx_list_c : : USE_TAB_WINDOW ) ;
2002-10-25 01:07:56 +04:00
return 0 ; // success
}
2006-03-19 18:35:20 +03:00
extern " C " void libwx_LTX_plugin_fini ( )
2002-10-25 01:07:56 +04:00
{
2006-03-19 18:35:20 +03:00
// fprintf(stderr, "plugin_fini for wxmain.cc\n");
2002-10-25 01:07:56 +04:00
}
2002-04-18 04:22:20 +04:00
2002-10-25 01:07:56 +04:00
//////////////////////////////////////////////////////////////////////
2004-10-03 13:11:28 +04:00
// MyApp: the wxWidgets application
2002-10-25 01:07:56 +04:00
//////////////////////////////////////////////////////////////////////
IMPLEMENT_APP_NO_MAIN ( MyApp )
2004-10-03 13:11:28 +04:00
// this is the entry point of the wxWidgets code. It is called as follows:
// 1. main() loads the wxWidgets plugin (if necessary) and calls
2002-10-25 01:07:56 +04:00
// libwx_LTX_plugin_init, which installs a function pointer to the
// ci_callback() function.
// 2. main() calls SIM->configuration_interface.
// 3. bx_real_sim_c::configuration_interface calls the function pointer that
// points to ci_callback() in this file, with command=CI_START.
2004-10-03 13:11:28 +04:00
// 4. ci_callback() calls wxEntry() in the wxWidgets library
// 5. wxWidgets library creates the app and calls OnInit().
2002-10-25 01:07:56 +04:00
//
// Before this code is called, the command line has already been parsed, and a
// .bochsrc has been loaded if it could be found. See main() for details.
2002-04-18 04:22:20 +04:00
bool MyApp : : OnInit ( )
{
2006-03-19 18:35:20 +03:00
// wxLog::AddTraceMask(wxT("mime"));
wxLog : : SetActiveTarget ( new wxLogStderr ( ) ) ;
2006-03-05 13:24:29 +03:00
bx_init_siminterface ( ) ;
- clean up the command line argument parsing. Before, we had two slightly
different versions of the code for wxWindows and non-wxWindows and the GDB
stub did not accept any command line options at all.
- IMPORTANT CHANGE: the quick start option used to cause two things:
1) read the bochsrc immediately, 2) start simulation immediately without
going into the config interface. This has changed in a subtle way.
Now, we always try to read the bochsrc immediately. Then if the quick
start option is on, we start the simulation immediately.
- add "Restore Factory Default Configuration" in text config menu. It was
already there in wx. Now the default choice is always "5. Begin simulation"
and because the bochsrc is always read now, this works.
- When the user chooses "Read configuration file" from either text mode
or wx interfaces, reset all bochs parameters first, then read in the
new file. This means that every time you read a configuration file
you are starting from a consistent "blank slate".
- move much of the code from bx_do_text_config_interface into bx_init_main
so that wxWindows and non-wxWindows code uses the same logic. There was
only a tiny bit left in bx_do_text_config_interface so I eliminated it.
- move the "help" message into a separate function print_usage()
- detect all flags (cmdline args that start with -) in a loop, instead of
a big if/else. This makes it easy to add others.
- fix problem with Carbon gui, so that -psn arg gets ignored
- print usage if you type -h, --help, or if flags are not recognized
- code that called io->set_log_action (that sets the log action for all
devices) was only called if the configuration interface was on; I'm not
sure why. Now it is called all the time.
- the wxWindows equivalent of main() is called MyApp::OnInit. Now OnInit
and main() are very similar. They both call bx_init_siminterface, then
bx_init_main (and quit if it fails), then show the config interface if
quickstart is off, and then simulate.
- modified: main.cc gui/control.cc gui/wxmain.cc
2002-10-14 17:37:20 +04:00
// Install callback function to handle anything that occurs before the
// simulation begins. This is responsible for displaying any error
// dialogs during bochsrc and command line processing.
2006-03-05 13:24:29 +03:00
SIM - > set_notify_callback ( & MyApp : : DefaultCallback , this ) ;
2006-03-19 12:24:10 +03:00
MyFrame * frame = new MyFrame ( wxT ( " Bochs x86 Emulator " ) , wxPoint ( 50 , 50 ) , wxSize ( 450 , 340 ) , wxMINIMIZE_BOX | wxSYSTEM_MENU | wxCAPTION ) ;
2002-04-18 04:22:20 +04:00
theFrame = frame ; // hack alert
2006-03-05 13:24:29 +03:00
frame - > Show ( TRUE ) ;
SetTopWindow ( frame ) ;
wxTheClipboard - > UsePrimarySelection ( true ) ;
2002-09-05 11:01:30 +04:00
// if quickstart is enabled, kick off the simulation
2006-03-05 13:24:29 +03:00
if ( SIM - > get_param_enum ( BXPN_BOCHS_START ) - > get ( ) = = BX_QUICK_START ) {
2002-09-05 11:01:30 +04:00
wxCommandEvent unusedEvent ;
2006-03-05 13:24:29 +03:00
frame - > OnStartSim ( unusedEvent ) ;
2002-09-05 11:01:30 +04:00
}
2002-04-18 04:22:20 +04:00
return TRUE ;
}
2006-03-05 13:24:29 +03:00
int MyApp : : OnExit ( )
2002-09-21 01:25:09 +04:00
{
return 0 ;
}
2002-09-25 22:40:15 +04:00
// these are only called when the simthread is not running.
BxEvent *
2006-03-19 18:35:20 +03:00
MyApp : : DefaultCallback ( void * thisptr , BxEvent * event )
2002-09-25 22:40:15 +04:00
{
2006-03-19 12:24:10 +03:00
wxLogDebug ( wxT ( " DefaultCallback: event type %d " ) , event - > type ) ;
2002-09-25 22:40:15 +04:00
event - > retcode = - 1 ; // default return code
switch ( event - > type )
{
case BX_ASYNC_EVT_LOG_MSG :
case BX_SYNC_EVT_LOG_ASK : {
2006-03-19 12:24:10 +03:00
wxLogDebug ( wxT ( " DefaultCallback: log ask event " ) ) ;
2002-09-25 22:40:15 +04:00
wxString text ;
2006-03-19 18:35:20 +03:00
text . Printf ( wxT ( " Error: %s " ) , event - > u . logmsg . msg ) ;
2002-10-07 08:01:00 +04:00
if ( wxBochsClosing ) {
2002-11-01 18:28:41 +03:00
// gui closing down, do something simple and nongraphical.
2006-03-19 12:24:10 +03:00
fprintf ( stderr , " %s \n " , ( const char * ) text . mb_str ( wxConvUTF8 ) ) ;
2002-10-07 08:01:00 +04:00
} else {
2006-03-18 19:30:52 +03:00
wxMessageBox ( text , wxT ( " Error " ) , wxOK | wxICON_ERROR ) ;
2002-11-01 18:28:41 +03:00
// maybe I can make OnLogMsg display something that looks appropriate.
2006-03-19 18:35:20 +03:00
// theFrame->OnLogMsg(event);
2002-10-07 08:01:00 +04:00
}
event - > retcode = BX_LOG_ASK_CHOICE_DIE ;
2002-09-25 22:40:15 +04:00
// There is only one thread at this point. if I choose DIE here, it will
// call fatal() and kill the whole app.
break ;
}
2002-10-07 08:01:00 +04:00
case BX_SYNC_EVT_TICK :
if ( wxBochsClosing )
2002-11-01 18:28:41 +03:00
event - > retcode = - 1 ;
2002-10-07 08:01:00 +04:00
break ;
2002-09-25 22:40:15 +04:00
case BX_ASYNC_EVT_REFRESH :
case BX_ASYNC_EVT_DBG_MSG :
2002-09-26 02:54:23 +04:00
break ; // ignore
case BX_SYNC_EVT_ASK_PARAM :
2002-09-25 22:40:15 +04:00
case BX_SYNC_EVT_GET_DBG_COMMAND :
2002-09-26 02:54:23 +04:00
break ; // ignore
2002-09-25 22:40:15 +04:00
default :
2006-03-19 12:24:10 +03:00
wxLogDebug ( wxT ( " DefaultCallback: unknown event type %d " ) , event - > type ) ;
2002-09-25 22:40:15 +04:00
}
2002-09-26 07:01:13 +04:00
if ( BX_EVT_IS_ASYNC ( event - > type ) ) {
2002-09-26 02:54:23 +04:00
delete event ;
event = NULL ;
}
2002-09-25 22:40:15 +04:00
return event ;
}
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
// MyFrame: the top level frame for the Bochs application
2002-04-18 04:22:20 +04:00
//////////////////////////////////////////////////////////////////////
BEGIN_EVENT_TABLE ( MyFrame , wxFrame )
2002-08-30 20:23:36 +04:00
EVT_MENU ( ID_Config_New , MyFrame : : OnConfigNew )
2002-08-25 19:51:46 +04:00
EVT_MENU ( ID_Config_Read , MyFrame : : OnConfigRead )
EVT_MENU ( ID_Config_Save , MyFrame : : OnConfigSave )
2006-04-13 00:51:24 +04:00
EVT_MENU ( ID_State_Restore , MyFrame : : OnStateRestore )
2002-04-18 04:22:20 +04:00
EVT_MENU ( ID_Quit , MyFrame : : OnQuit )
EVT_MENU ( ID_Help_About , MyFrame : : OnAbout )
EVT_MENU ( ID_Simulate_Start , MyFrame : : OnStartSim )
EVT_MENU ( ID_Simulate_PauseResume , MyFrame : : OnPauseResumeSim )
EVT_MENU ( ID_Simulate_Stop , MyFrame : : OnKillSim )
2002-08-29 18:59:37 +04:00
EVT_MENU ( ID_Sim2CI_Event , MyFrame : : OnSim2CIEvent )
2002-12-12 19:31:41 +03:00
EVT_MENU ( ID_Edit_ATA0 , MyFrame : : OnEditATA )
EVT_MENU ( ID_Edit_ATA1 , MyFrame : : OnEditATA )
EVT_MENU ( ID_Edit_ATA2 , MyFrame : : OnEditATA )
EVT_MENU ( ID_Edit_ATA3 , MyFrame : : OnEditATA )
2006-02-18 19:53:18 +03:00
EVT_MENU ( ID_Edit_CPU , MyFrame : : OnEditCPU )
2002-09-03 00:13:52 +04:00
EVT_MENU ( ID_Edit_Memory , MyFrame : : OnEditMemory )
2006-02-19 18:43:03 +03:00
EVT_MENU ( ID_Edit_Clock_Cmos , MyFrame : : OnEditClockCmos )
2004-07-10 01:40:49 +04:00
EVT_MENU ( ID_Edit_PCI , MyFrame : : OnEditPCI )
2006-02-22 00:35:09 +03:00
EVT_MENU ( ID_Edit_Display , MyFrame : : OnEditDisplay )
2006-02-24 01:48:57 +03:00
EVT_MENU ( ID_Edit_Keyboard , MyFrame : : OnEditKeyboard )
EVT_MENU ( ID_Edit_Boot , MyFrame : : OnEditBoot )
- add generic dialog class called ParamDialog. You create it, call
a method to add the parameters (bx_param_c) that you want to edit,
and display it. It knows how to display and edit boolean, int,
enum, and string, so it can do a reasonable job on any parameter.
The end result is not as nice as a box that you lay out by hand, but
it's decent. The most obvious thing that's missing from
ParamDialog-generated dialogs is that I haven't found a way to
make an "Enable" button that enables/disables a bunch of other
parameters. I'll keep thinking about that.
- using ParamDialog, I made dialogs for Sound, Cmos, Serial/Parallel,
32bitOSloader, and an ugly catch-all category called other.
Now I believe you can edit every single option using wxWindows.
2002-09-03 09:32:49 +04:00
EVT_MENU ( ID_Edit_Serial_Parallel , MyFrame : : OnEditSerialParallel )
2006-03-01 20:14:36 +03:00
EVT_MENU ( ID_Edit_Network , MyFrame : : OnEditNet )
EVT_MENU ( ID_Edit_Sound , MyFrame : : OnEditSound )
- add generic dialog class called ParamDialog. You create it, call
a method to add the parameters (bx_param_c) that you want to edit,
and display it. It knows how to display and edit boolean, int,
enum, and string, so it can do a reasonable job on any parameter.
The end result is not as nice as a box that you lay out by hand, but
it's decent. The most obvious thing that's missing from
ParamDialog-generated dialogs is that I haven't found a way to
make an "Enable" button that enables/disables a bunch of other
parameters. I'll keep thinking about that.
- using ParamDialog, I made dialogs for Sound, Cmos, Serial/Parallel,
32bitOSloader, and an ugly catch-all category called other.
Now I believe you can edit every single option using wxWindows.
2002-09-03 09:32:49 +04:00
EVT_MENU ( ID_Edit_Other , MyFrame : : OnEditOther )
2002-09-02 21:03:14 +04:00
EVT_MENU ( ID_Log_Prefs , MyFrame : : OnLogPrefs )
2002-09-19 08:52:03 +04:00
EVT_MENU ( ID_Log_PrefsDevice , MyFrame : : OnLogPrefsDevice )
- 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
EVT_MENU ( ID_Debug_ShowCpu , MyFrame : : OnShowCpu )
EVT_MENU ( ID_Debug_ShowKeyboard , MyFrame : : OnShowKeyboard )
2002-09-19 00:59:05 +04:00
# if BX_DEBUGGER
2002-10-10 19:44:34 +04:00
EVT_MENU ( ID_Debug_Console , MyFrame : : OnDebugLog )
2002-09-16 19:28:19 +04:00
# endif
2002-04-18 04:22:20 +04:00
// toolbar events
2002-08-30 03:18:10 +04:00
EVT_TOOL ( ID_Edit_FD_0 , MyFrame : : OnToolbarClick )
EVT_TOOL ( ID_Edit_FD_1 , MyFrame : : OnToolbarClick )
2002-08-30 10:06:36 +04:00
EVT_TOOL ( ID_Edit_Cdrom , MyFrame : : OnToolbarClick )
2002-04-18 04:22:20 +04:00
EVT_TOOL ( ID_Toolbar_Reset , MyFrame : : OnToolbarClick )
EVT_TOOL ( ID_Toolbar_Power , MyFrame : : OnToolbarClick )
2006-08-30 00:10:27 +04:00
# if BX_SUPPORT_SAVE_RESTORE
EVT_TOOL ( ID_Toolbar_SaveRestore , MyFrame : : OnToolbarClick )
# endif
2002-04-18 04:22:20 +04:00
EVT_TOOL ( ID_Toolbar_Copy , MyFrame : : OnToolbarClick )
EVT_TOOL ( ID_Toolbar_Paste , MyFrame : : OnToolbarClick )
EVT_TOOL ( ID_Toolbar_Snapshot , MyFrame : : OnToolbarClick )
EVT_TOOL ( ID_Toolbar_Config , MyFrame : : OnToolbarClick )
EVT_TOOL ( ID_Toolbar_Mouse_en , MyFrame : : OnToolbarClick )
2002-08-09 10:16:43 +04:00
EVT_TOOL ( ID_Toolbar_User , MyFrame : : OnToolbarClick )
2002-04-18 04:22:20 +04:00
END_EVENT_TABLE ( )
2002-08-30 10:46:38 +04:00
//////////////////////////////////////////////////////////////////
// Menu layout (approximate)
//
// The actual menus will be changing so this probably isn't up
// to date, but having it in text form was useful in planning.
//////////////////////////////////////////////////////////////////
// - File
// +----------------------+
// | New Configuration |
// | Read Configuration |
// | Save Configuration |
// +----------------------+
// | Quit |
// +----------------------+
// - Edit
// +----------------------+
// | Floppy Disk 0... |
// | Floppy Disk 1... |
// | Hard Disk 0... |
// | Hard Disk 1... |
// | Cdrom... |
// | Boot... |
// | VGA... |
// | Memory... |
// | Sound... |
// | Networking... |
// | Keyboard... |
// | Other... |
// +----------------------+
// - Simulate
// +----------------------+
// | Start |
// | Pause/Resume |
// | Stop |
// +----------------------|
// - Debug
// +----------------------|
// | Show CPU |
// | Show Memory |
// | ? what else ? |
// +----------------------|
// - Event Log
// +----------------------+
// | View |
// | Preferences... |
// | By Device... |
// +----------------------+
// - Help
// +----------------------+
// | About Bochs... |
// +----------------------+
//////////////////////////////////////////////////////////////////
2002-04-18 04:22:20 +04:00
MyFrame : : MyFrame ( const wxString & title , const wxPoint & pos , const wxSize & size , const long style )
: wxFrame ( ( wxFrame * ) NULL , - 1 , title , pos , size , style )
{
2002-12-25 20:13:45 +03:00
SetIcon ( wxICON ( icon_bochs ) ) ;
2002-04-18 04:22:20 +04:00
// init variables
sim_thread = NULL ;
start_bochs_times = 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
showCpu = NULL ;
showKbd = 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
debugCommand = NULL ;
debugCommandEvent = NULL ;
2002-04-18 04:22:20 +04:00
// set up the gui
menuConfiguration = new wxMenu ;
2006-03-18 19:30:52 +03:00
menuConfiguration - > Append ( ID_Config_New , wxT ( " &New Configuration " ) ) ;
menuConfiguration - > Append ( ID_Config_Read , wxT ( " &Read Configuration " ) ) ;
menuConfiguration - > Append ( ID_Config_Save , wxT ( " &Save Configuration " ) ) ;
2006-02-18 19:53:18 +03:00
menuConfiguration - > AppendSeparator ( ) ;
2006-04-13 00:51:24 +04:00
menuConfiguration - > Append ( ID_State_Restore , wxT ( " &Restore State " ) ) ;
menuConfiguration - > AppendSeparator ( ) ;
2006-03-19 18:35:20 +03:00
menuConfiguration - > Append ( ID_Quit , wxT ( " &Quit " ) ) ;
2002-04-18 04:22:20 +04:00
menuEdit = new wxMenu ;
2006-03-18 19:30:52 +03:00
menuEdit - > Append ( ID_Edit_FD_0 , wxT ( " Floppy Disk &0... " ) ) ;
menuEdit - > Append ( ID_Edit_FD_1 , wxT ( " Floppy Disk &1... " ) ) ;
menuEdit - > Append ( ID_Edit_ATA0 , wxT ( " ATA Channel 0... " ) ) ;
menuEdit - > Append ( ID_Edit_ATA1 , wxT ( " ATA Channel 1... " ) ) ;
menuEdit - > Append ( ID_Edit_ATA2 , wxT ( " ATA Channel 2... " ) ) ;
menuEdit - > Append ( ID_Edit_ATA3 , wxT ( " ATA Channel 3... " ) ) ;
menuEdit - > Append ( ID_Edit_CPU , wxT ( " &CPU... " ) ) ;
menuEdit - > Append ( ID_Edit_Memory , wxT ( " &Memory... " ) ) ;
menuEdit - > Append ( ID_Edit_Clock_Cmos , wxT ( " C&lock/Cmos... " ) ) ;
menuEdit - > Append ( ID_Edit_PCI , wxT ( " &PCI... " ) ) ;
menuEdit - > Append ( ID_Edit_Display , wxT ( " &Display + Interface... " ) ) ;
menuEdit - > Append ( ID_Edit_Keyboard , wxT ( " &Keyboard + Mouse... " ) ) ;
menuEdit - > Append ( ID_Edit_Boot , wxT ( " &Boot... " ) ) ;
menuEdit - > Append ( ID_Edit_Serial_Parallel , wxT ( " &Serial/Parallel... " ) ) ;
menuEdit - > Append ( ID_Edit_Network , wxT ( " &Network... " ) ) ;
menuEdit - > Append ( ID_Edit_Sound , wxT ( " S&ound... " ) ) ;
menuEdit - > Append ( ID_Edit_Other , wxT ( " &Other... " ) ) ;
2002-04-18 04:22:20 +04:00
menuSimulate = new wxMenu ;
2006-03-18 19:30:52 +03:00
menuSimulate - > Append ( ID_Simulate_Start , wxT ( " &Start... " ) ) ;
menuSimulate - > Append ( ID_Simulate_PauseResume , wxT ( " &Pause... " ) ) ;
menuSimulate - > Append ( ID_Simulate_Stop , wxT ( " S&top... " ) ) ;
2006-02-18 19:53:18 +03:00
menuSimulate - > AppendSeparator ( ) ;
menuSimulate - > Enable ( ID_Simulate_PauseResume , FALSE ) ;
menuSimulate - > Enable ( ID_Simulate_Stop , FALSE ) ;
2002-04-18 04:22:20 +04:00
menuDebug = new wxMenu ;
2006-03-18 19:30:52 +03:00
menuDebug - > Append ( ID_Debug_ShowCpu , wxT ( " Show &CPU " ) ) ;
menuDebug - > Append ( ID_Debug_ShowKeyboard , wxT ( " Show &Keyboard " ) ) ;
2002-10-10 19:44:34 +04:00
# if BX_DEBUGGER
2006-03-18 19:30:52 +03:00
menuDebug - > Append ( ID_Debug_Console , wxT ( " Debug Console " ) ) ;
2002-10-10 19:44:34 +04:00
# endif
2006-03-18 19:30:52 +03:00
menuDebug - > Append ( ID_Debug_ShowMemory , wxT ( " Show &memory " ) ) ;
2002-04-18 04:22:20 +04:00
menuLog = new wxMenu ;
2006-03-18 19:30:52 +03:00
menuLog - > Append ( ID_Log_View , wxT ( " &View " ) ) ;
menuLog - > Append ( ID_Log_Prefs , wxT ( " &Preferences... " ) ) ;
menuLog - > Append ( ID_Log_PrefsDevice , wxT ( " By &Device... " ) ) ;
2002-04-18 04:22:20 +04:00
menuHelp = new wxMenu ;
2006-03-18 19:30:52 +03:00
menuHelp - > Append ( ID_Help_About , wxT ( " &About... " ) ) ;
2002-04-18 04:22:20 +04:00
wxMenuBar * menuBar = new wxMenuBar ;
2006-03-18 19:30:52 +03:00
menuBar - > Append ( menuConfiguration , wxT ( " &File " ) ) ;
menuBar - > Append ( menuEdit , wxT ( " &Edit " ) ) ;
menuBar - > Append ( menuSimulate , wxT ( " &Simulate " ) ) ;
menuBar - > Append ( menuDebug , wxT ( " &Debug " ) ) ;
menuBar - > Append ( menuLog , wxT ( " &Log " ) ) ;
menuBar - > Append ( menuHelp , wxT ( " &Help " ) ) ;
2006-02-18 19:53:18 +03:00
SetMenuBar ( menuBar ) ;
2002-09-03 12:55:35 +04:00
// disable things that don't work yet
2006-02-18 19:53:18 +03:00
menuDebug - > Enable ( ID_Debug_ShowMemory , FALSE ) ; // not implemented
menuLog - > Enable ( ID_Log_View , FALSE ) ; // not implemented
2006-02-27 15:03:56 +03:00
// enable ATA channels in menu
menuEdit - > Enable ( ID_Edit_ATA1 , BX_MAX_ATA_CHANNEL > 1 ) ;
menuEdit - > Enable ( ID_Edit_ATA2 , BX_MAX_ATA_CHANNEL > 2 ) ;
menuEdit - > Enable ( ID_Edit_ATA3 , BX_MAX_ATA_CHANNEL > 3 ) ;
2006-04-13 00:51:24 +04:00
// enable restore state if present
menuConfiguration - > Enable ( ID_State_Restore , BX_SUPPORT_SAVE_RESTORE ) ;
2002-09-03 12:55:35 +04:00
2002-04-18 04:22:20 +04:00
CreateStatusBar ( ) ;
2004-02-10 23:30:14 +03:00
wxStatusBar * sb = GetStatusBar ( ) ;
sb - > SetFieldsCount ( 12 ) ;
const int sbwidth [ 12 ] = { 160 , 38 , 38 , 38 , 38 , 38 , 38 , 38 , 38 , 38 , 38 , - 1 } ;
sb - > SetStatusWidths ( 12 , sbwidth ) ;
2002-04-18 04:22:20 +04:00
2002-09-03 23:04:17 +04:00
CreateToolBar ( wxNO_BORDER | wxHORIZONTAL | wxTB_FLAT ) ;
2006-09-03 20:55:35 +04:00
bxToolBar = GetToolBar ( ) ;
bxToolBar - > SetToolBitmapSize ( wxSize ( 32 , 32 ) ) ;
2002-04-18 04:22:20 +04:00
2002-09-03 21:50:12 +04:00
# define BX_ADD_TOOL(id, xpm_name, tooltip) do { \
2006-09-03 20:55:35 +04:00
bxToolBar - > AddTool ( id , wxBitmap ( xpm_name ) , tooltip ) ; \
2002-09-03 21:50:12 +04:00
} while ( 0 )
2002-04-18 04:22:20 +04:00
2006-03-18 19:30:52 +03:00
BX_ADD_TOOL ( ID_Edit_FD_0 , floppya_xpm , wxT ( " Change Floppy A " ) ) ;
BX_ADD_TOOL ( ID_Edit_FD_1 , floppyb_xpm , wxT ( " Change Floppy B " ) ) ;
BX_ADD_TOOL ( ID_Edit_Cdrom , cdromd_xpm , wxT ( " Change CDROM " ) ) ;
BX_ADD_TOOL ( ID_Toolbar_Reset , reset_xpm , wxT ( " Reset the system " ) ) ;
BX_ADD_TOOL ( ID_Toolbar_Power , power_xpm , wxT ( " Turn power on/off " ) ) ;
2006-06-07 02:11:09 +04:00
# if BX_SUPPORT_SAVE_RESTORE
BX_ADD_TOOL ( ID_Toolbar_SaveRestore , saverestore_xpm , wxT ( " Save simulation state " ) ) ;
# endif
2002-04-18 04:22:20 +04:00
2006-03-18 19:30:52 +03:00
BX_ADD_TOOL ( ID_Toolbar_Copy , copy_xpm , wxT ( " Copy to clipboard " ) ) ;
BX_ADD_TOOL ( ID_Toolbar_Paste , paste_xpm , wxT ( " Paste from clipboard " ) ) ;
BX_ADD_TOOL ( ID_Toolbar_Snapshot , snapshot_xpm , wxT ( " Save screen snapshot " ) ) ;
2004-10-03 13:11:28 +04:00
// Omit config button because the whole wxWidgets interface is like
2002-09-05 21:27:50 +04:00
// one really big config button.
//BX_ADD_TOOL(ID_Toolbar_Config, configbutton_xpm, "Runtime Configuration");
2006-03-18 19:30:52 +03:00
BX_ADD_TOOL ( ID_Toolbar_Mouse_en , mouse_xpm , wxT ( " Enable/disable mouse capture \n There is also a shortcut for this: a CTRL key + the middle mouse button. " ) ) ;
BX_ADD_TOOL ( ID_Toolbar_User , userbutton_xpm , wxT ( " Keyboard shortcut " ) ) ;
2002-04-18 04:22:20 +04:00
2006-09-03 20:55:35 +04:00
bxToolBar - > Realize ( ) ;
2002-04-18 04:22:20 +04:00
// create a MyPanel that covers the whole frame
2006-03-19 18:35:20 +03:00
panel = new MyPanel ( this , - 1 ) ;
panel - > SetBackgroundColour ( wxColour ( 0 , 0 , 0 ) ) ;
panel - > SetFocus ( ) ;
wxGridSizer * sz = new wxGridSizer ( 1 , 1 ) ;
sz - > Add ( panel , 0 , wxGROW ) ;
SetAutoLayout ( TRUE ) ;
SetSizer ( sz ) ;
2002-04-18 04:22:20 +04:00
- 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
# if BX_DEBUGGER
// create the debug log dialog box immediately so that we can write output
// to it.
2006-03-19 18:35:20 +03:00
showDebugLog = new DebugLogDialog ( this , - 1 ) ;
showDebugLog - > Init ( ) ;
- 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
# endif
2002-04-18 04:22:20 +04:00
}
2006-03-19 18:35:20 +03:00
MyFrame : : ~ MyFrame ( )
2002-09-05 20:01:34 +04:00
{
2002-09-21 01:25:09 +04:00
delete panel ;
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " MyFrame destructor " ) ) ;
2002-09-05 20:01:34 +04:00
theFrame = NULL ;
}
2002-08-30 20:23:36 +04:00
void MyFrame : : OnConfigNew ( wxCommandEvent & WXUNUSED ( event ) )
{
2006-03-18 19:30:52 +03:00
int answer = wxMessageBox ( wxT ( " This will reset all settings back to their default values. \n Are you sure you want to do this? " ) ,
wxT ( " Are you sure? " ) , wxYES_NO | wxCENTER , this ) ;
2006-03-19 18:35:20 +03:00
if ( answer = = wxYES ) SIM - > reset_all_param ( ) ;
2002-08-30 20:23:36 +04:00
}
2002-08-25 19:51:46 +04:00
void MyFrame : : OnConfigRead ( wxCommandEvent & WXUNUSED ( event ) )
{
2006-04-13 00:51:24 +04:00
char bochsrc [ 512 ] ;
2002-09-25 22:40:15 +04:00
long style = wxOPEN ;
2006-03-19 18:35:20 +03:00
wxFileDialog * fdialog = new wxFileDialog ( this , wxT ( " Read configuration " ) , wxT ( " " ) , wxT ( " " ) , wxT ( " *.* " ) , style ) ;
2002-09-25 22:40:15 +04:00
if ( fdialog - > ShowModal ( ) = = wxID_OK ) {
2006-04-13 00:51:24 +04:00
strncpy ( bochsrc , fdialog - > GetPath ( ) . mb_str ( wxConvUTF8 ) , sizeof ( bochsrc ) ) ;
2006-03-19 18:35:20 +03:00
SIM - > reset_all_param ( ) ;
SIM - > read_rc ( bochsrc ) ;
2002-09-25 22:40:15 +04:00
}
delete fdialog ;
2002-08-25 19:51:46 +04:00
}
void MyFrame : : OnConfigSave ( wxCommandEvent & WXUNUSED ( event ) )
{
2006-04-13 00:51:24 +04:00
char bochsrc [ 512 ] ;
2002-09-25 22:40:15 +04:00
long style = wxSAVE | wxOVERWRITE_PROMPT ;
2006-03-19 18:35:20 +03:00
wxFileDialog * fdialog = new wxFileDialog ( this , wxT ( " Save configuration " ) , wxT ( " " ) , wxT ( " " ) , wxT ( " *.* " ) , style ) ;
2002-09-25 22:40:15 +04:00
if ( fdialog - > ShowModal ( ) = = wxID_OK ) {
2006-04-13 00:51:24 +04:00
strncpy ( bochsrc , fdialog - > GetPath ( ) . mb_str ( wxConvUTF8 ) , sizeof ( bochsrc ) ) ;
2006-03-19 18:35:20 +03:00
SIM - > write_rc ( bochsrc , 1 ) ;
2002-09-25 22:40:15 +04:00
}
delete fdialog ;
2002-08-25 19:51:46 +04:00
}
2006-04-13 00:51:24 +04:00
void MyFrame : : OnStateRestore ( wxCommandEvent & WXUNUSED ( event ) )
{
# if BX_SUPPORT_SAVE_RESTORE
char sr_path [ 512 ] ;
// pass some initial dir to wxDirDialog
wxString dirSaveRestore ;
2006-06-04 18:16:31 +04:00
wxGetHomeDir ( & dirSaveRestore ) ;
2006-04-13 00:51:24 +04:00
wxDirDialog ddialog ( this , wxT ( " Select folder with save/restore data " ) , dirSaveRestore , wxDD_DEFAULT_STYLE ) ;
if ( ddialog . ShowModal ( ) = = wxID_OK ) {
strncpy ( sr_path , ddialog . GetPath ( ) . mb_str ( wxConvUTF8 ) , sizeof ( sr_path ) ) ;
SIM - > get_param_bool ( BXPN_RESTORE_FLAG ) - > set ( 1 ) ;
SIM - > get_param_string ( BXPN_RESTORE_PATH ) - > set ( sr_path ) ;
}
# endif
}
2006-02-18 19:53:18 +03:00
void MyFrame : : OnEditCPU ( wxCommandEvent & WXUNUSED ( event ) )
{
ParamDialog dlg ( this , - 1 ) ;
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( " cpu " ) ;
2006-03-19 12:24:10 +03:00
dlg . SetTitle ( wxString ( list - > get_title ( ) - > getptr ( ) , wxConvUTF8 ) ) ;
2006-02-18 19:53:18 +03:00
dlg . AddParam ( list ) ;
dlg . ShowModal ( ) ;
}
2002-09-03 00:13:52 +04:00
void MyFrame : : OnEditMemory ( wxCommandEvent & WXUNUSED ( event ) )
{
2006-02-17 00:44:17 +03:00
ParamDialog dlg ( this , - 1 ) ;
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( " memory " ) ;
2006-03-19 12:24:10 +03:00
dlg . SetTitle ( wxString ( list - > get_title ( ) - > getptr ( ) , wxConvUTF8 ) ) ;
2006-02-17 00:44:17 +03:00
dlg . AddParam ( list ) ;
dlg . ShowModal ( ) ;
2002-09-03 00:13:52 +04:00
}
2006-02-19 18:43:03 +03:00
void MyFrame : : OnEditClockCmos ( wxCommandEvent & WXUNUSED ( event ) )
{
ParamDialog dlg ( this , - 1 ) ;
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( " clock_cmos " ) ;
2006-03-19 12:24:10 +03:00
dlg . SetTitle ( wxString ( list - > get_title ( ) - > getptr ( ) , wxConvUTF8 ) ) ;
2006-02-19 18:43:03 +03:00
dlg . AddParam ( list ) ;
dlg . ShowModal ( ) ;
}
2004-07-10 01:40:49 +04:00
void MyFrame : : OnEditPCI ( wxCommandEvent & WXUNUSED ( event ) )
{
2006-02-20 00:35:50 +03:00
ParamDialog dlg ( this , - 1 ) ;
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( " pci " ) ;
2006-03-19 12:24:10 +03:00
dlg . SetTitle ( wxString ( list - > get_title ( ) - > getptr ( ) , wxConvUTF8 ) ) ;
2006-02-20 00:35:50 +03:00
dlg . AddParam ( list ) ;
dlg . ShowModal ( ) ;
2004-07-10 01:40:49 +04:00
}
2006-02-22 00:35:09 +03:00
void MyFrame : : OnEditDisplay ( wxCommandEvent & WXUNUSED ( event ) )
{
ParamDialog dlg ( this , - 1 ) ;
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( " display " ) ;
2006-03-19 12:24:10 +03:00
dlg . SetTitle ( wxString ( list - > get_title ( ) - > getptr ( ) , wxConvUTF8 ) ) ;
2006-02-22 00:35:09 +03:00
dlg . AddParam ( list ) ;
dlg . SetRuntimeFlag ( sim_thread ! = NULL ) ;
dlg . ShowModal ( ) ;
}
2006-02-22 22:18:29 +03:00
void MyFrame : : OnEditKeyboard ( wxCommandEvent & WXUNUSED ( event ) )
{
ParamDialog dlg ( this , - 1 ) ;
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( " keyboard_mouse " ) ;
2006-03-19 12:24:10 +03:00
dlg . SetTitle ( wxString ( list - > get_title ( ) - > getptr ( ) , wxConvUTF8 ) ) ;
2006-02-22 22:18:29 +03:00
dlg . AddParam ( list ) ;
dlg . SetRuntimeFlag ( sim_thread ! = NULL ) ;
dlg . ShowModal ( ) ;
}
2006-02-24 01:48:57 +03:00
void MyFrame : : OnEditBoot ( wxCommandEvent & WXUNUSED ( event ) )
{
int bootDevices = 0 ;
2006-02-25 01:35:46 +03:00
bx_param_enum_c * floppy = SIM - > get_param_enum ( BXPN_FLOPPYA_DEVTYPE ) ;
2006-02-24 01:48:57 +03:00
if ( floppy - > get ( ) ! = BX_FLOPPY_NONE ) {
bootDevices + + ;
}
bx_param_c * firsthd = SIM - > get_first_hd ( ) ;
if ( firsthd ! = NULL ) {
bootDevices + + ;
}
bx_param_c * firstcd = SIM - > get_first_cdrom ( ) ;
if ( firstcd ! = NULL ) {
bootDevices + + ;
}
if ( bootDevices = = 0 ) {
2006-03-18 19:30:52 +03:00
wxMessageBox ( wxT ( " All the possible boot devices are disabled right now! \n You must enable the first floppy drive, a hard drive, or a CD-ROM. " ) ,
wxT ( " None enabled " ) , wxOK | wxICON_ERROR , this ) ;
2006-02-24 01:48:57 +03:00
return ;
}
ParamDialog dlg ( this , - 1 ) ;
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( " boot_params " ) ;
2006-03-19 12:24:10 +03:00
dlg . SetTitle ( wxString ( list - > get_title ( ) - > getptr ( ) , wxConvUTF8 ) ) ;
2006-02-24 01:48:57 +03:00
dlg . AddParam ( list ) ;
dlg . ShowModal ( ) ;
}
2006-03-01 20:14:36 +03:00
void MyFrame : : OnEditSerialParallel ( wxCommandEvent & WXUNUSED ( event ) )
- add generic dialog class called ParamDialog. You create it, call
a method to add the parameters (bx_param_c) that you want to edit,
and display it. It knows how to display and edit boolean, int,
enum, and string, so it can do a reasonable job on any parameter.
The end result is not as nice as a box that you lay out by hand, but
it's decent. The most obvious thing that's missing from
ParamDialog-generated dialogs is that I haven't found a way to
make an "Enable" button that enables/disables a bunch of other
parameters. I'll keep thinking about that.
- using ParamDialog, I made dialogs for Sound, Cmos, Serial/Parallel,
32bitOSloader, and an ugly catch-all category called other.
Now I believe you can edit every single option using wxWindows.
2002-09-03 09:32:49 +04:00
{
2006-03-01 20:14:36 +03:00
ParamDialog dlg ( this , - 1 ) ;
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( " ports " ) ;
2006-03-19 12:24:10 +03:00
dlg . SetTitle ( wxString ( list - > get_title ( ) - > getptr ( ) , wxConvUTF8 ) ) ;
2006-03-01 20:14:36 +03:00
dlg . AddParam ( list ) ;
dlg . SetRuntimeFlag ( sim_thread ! = NULL ) ;
dlg . ShowModal ( ) ;
- add generic dialog class called ParamDialog. You create it, call
a method to add the parameters (bx_param_c) that you want to edit,
and display it. It knows how to display and edit boolean, int,
enum, and string, so it can do a reasonable job on any parameter.
The end result is not as nice as a box that you lay out by hand, but
it's decent. The most obvious thing that's missing from
ParamDialog-generated dialogs is that I haven't found a way to
make an "Enable" button that enables/disables a bunch of other
parameters. I'll keep thinking about that.
- using ParamDialog, I made dialogs for Sound, Cmos, Serial/Parallel,
32bitOSloader, and an ugly catch-all category called other.
Now I believe you can edit every single option using wxWindows.
2002-09-03 09:32:49 +04:00
}
2002-09-01 23:38:08 +04:00
void MyFrame : : OnEditNet ( wxCommandEvent & WXUNUSED ( event ) )
{
2006-03-01 20:14:36 +03:00
ParamDialog dlg ( this , - 1 ) ;
2006-03-02 23:13:14 +03:00
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( " network " ) ;
2006-03-19 12:24:10 +03:00
dlg . SetTitle ( wxString ( list - > get_title ( ) - > getptr ( ) , wxConvUTF8 ) ) ;
2006-03-01 20:14:36 +03:00
dlg . AddParam ( list ) ;
dlg . ShowModal ( ) ;
2002-09-01 23:38:08 +04:00
}
2006-03-01 20:14:36 +03:00
void MyFrame : : OnEditSound ( wxCommandEvent & WXUNUSED ( event ) )
- add generic dialog class called ParamDialog. You create it, call
a method to add the parameters (bx_param_c) that you want to edit,
and display it. It knows how to display and edit boolean, int,
enum, and string, so it can do a reasonable job on any parameter.
The end result is not as nice as a box that you lay out by hand, but
it's decent. The most obvious thing that's missing from
ParamDialog-generated dialogs is that I haven't found a way to
make an "Enable" button that enables/disables a bunch of other
parameters. I'll keep thinking about that.
- using ParamDialog, I made dialogs for Sound, Cmos, Serial/Parallel,
32bitOSloader, and an ugly catch-all category called other.
Now I believe you can edit every single option using wxWindows.
2002-09-03 09:32:49 +04:00
{
ParamDialog dlg ( this , - 1 ) ;
2006-03-03 23:29:50 +03:00
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( BXPN_SB16 ) ;
2006-03-19 12:24:10 +03:00
dlg . SetTitle ( wxString ( list - > get_title ( ) - > getptr ( ) , wxConvUTF8 ) ) ;
2006-03-01 20:14:36 +03:00
dlg . AddParam ( list ) ;
dlg . SetRuntimeFlag ( sim_thread ! = NULL ) ;
dlg . ShowModal ( ) ;
- add generic dialog class called ParamDialog. You create it, call
a method to add the parameters (bx_param_c) that you want to edit,
and display it. It knows how to display and edit boolean, int,
enum, and string, so it can do a reasonable job on any parameter.
The end result is not as nice as a box that you lay out by hand, but
it's decent. The most obvious thing that's missing from
ParamDialog-generated dialogs is that I haven't found a way to
make an "Enable" button that enables/disables a bunch of other
parameters. I'll keep thinking about that.
- using ParamDialog, I made dialogs for Sound, Cmos, Serial/Parallel,
32bitOSloader, and an ugly catch-all category called other.
Now I believe you can edit every single option using wxWindows.
2002-09-03 09:32:49 +04:00
}
void MyFrame : : OnEditOther ( wxCommandEvent & WXUNUSED ( event ) )
{
2006-02-24 01:48:57 +03:00
ParamDialog dlg ( this , - 1 ) ;
2006-03-04 15:43:47 +03:00
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( " misc " ) ;
2006-03-19 12:24:10 +03:00
dlg . SetTitle ( wxString ( list - > get_title ( ) - > getptr ( ) , wxConvUTF8 ) ) ;
2006-02-24 01:48:57 +03:00
dlg . AddParam ( list ) ;
dlg . SetRuntimeFlag ( sim_thread ! = NULL ) ;
dlg . ShowModal ( ) ;
- add generic dialog class called ParamDialog. You create it, call
a method to add the parameters (bx_param_c) that you want to edit,
and display it. It knows how to display and edit boolean, int,
enum, and string, so it can do a reasonable job on any parameter.
The end result is not as nice as a box that you lay out by hand, but
it's decent. The most obvious thing that's missing from
ParamDialog-generated dialogs is that I haven't found a way to
make an "Enable" button that enables/disables a bunch of other
parameters. I'll keep thinking about that.
- using ParamDialog, I made dialogs for Sound, Cmos, Serial/Parallel,
32bitOSloader, and an ugly catch-all category called other.
Now I believe you can edit every single option using wxWindows.
2002-09-03 09:32:49 +04:00
}
2002-09-02 21:03:14 +04:00
void MyFrame : : OnLogPrefs ( wxCommandEvent & WXUNUSED ( event ) )
{
// Ideally I would use the siminterface methods to fill in the fields
// of the LogOptionsDialog, but in fact several things are hardcoded.
// At least I can verify that the expected numbers are the same.
2006-03-11 13:00:56 +03:00
wxASSERT ( SIM - > get_max_log_level ( ) = = LOG_OPTS_N_TYPES ) ;
LogOptionsDialog dlg ( this , - 1 ) ;
2002-09-02 21:03:14 +04:00
// The inital values of the dialog are complicated. If the panic action
// for all modules is "ask", then clearly the inital value in the dialog
// for panic action should be "ask". This informs the user what the
// previous value was, and if they click Ok it won't do any harm. But if
// some devices are set to "ask" and others are set to "report", then the
// initial value should be "no change". With "no change", clicking on Ok
// will not destroy the settings for individual devices. You would only
// start to see "no change" if you've been messing around in the advanced
// menu already.
2002-09-20 21:53:14 +04:00
int level , nlevel = SIM - > get_max_log_level ( ) ;
for ( level = 0 ; level < nlevel ; level + + ) {
2002-09-02 21:03:14 +04:00
int mod = 0 ;
2006-03-11 13:00:56 +03:00
int first = SIM - > get_log_action ( mod , level ) ;
2002-09-02 21:03:14 +04:00
bool consensus = true ;
// now compare all others to first. If all match, then use "first" as
// the initial value.
2006-03-11 13:00:56 +03:00
for ( mod = 1 ; mod < SIM - > get_n_log_modules ( ) ; mod + + ) {
if ( first ! = SIM - > get_log_action ( mod , level ) ) {
2002-11-01 18:28:41 +03:00
consensus = false ;
break ;
2002-09-02 21:03:14 +04:00
}
}
if ( consensus )
2006-03-11 13:00:56 +03:00
dlg . SetAction ( level , first ) ;
2002-09-02 21:03:14 +04:00
else
2006-03-11 13:00:56 +03:00
dlg . SetAction ( level , LOG_OPTS_NO_CHANGE ) ;
2002-09-02 21:03:14 +04:00
}
2006-03-11 13:00:56 +03:00
int n = dlg . ShowModal ( ) ; // show the dialog!
2002-09-04 16:29:04 +04:00
if ( n = = wxID_OK ) {
2002-09-20 21:53:14 +04:00
for ( level = 0 ; level < nlevel ; level + + ) {
2002-09-02 21:03:14 +04:00
// ask the dialog what action the user chose for this type of event
2006-03-11 13:00:56 +03:00
int action = dlg . GetAction ( level ) ;
2002-09-02 21:03:14 +04:00
if ( action ! = LOG_OPTS_NO_CHANGE ) {
2002-11-01 18:28:41 +03:00
// set new default
2006-03-11 13:00:56 +03:00
SIM - > set_default_log_action ( level , action ) ;
2002-11-01 18:28:41 +03:00
// apply that action to all modules (devices)
2006-03-11 13:00:56 +03:00
SIM - > set_log_action ( - 1 , level , action ) ;
2002-09-02 21:03:14 +04:00
}
}
}
}
2002-09-19 08:52:03 +04:00
void MyFrame : : OnLogPrefsDevice ( wxCommandEvent & WXUNUSED ( event ) )
{
2006-03-19 18:35:20 +03:00
wxASSERT ( SIM - > get_max_log_level ( ) = = ADVLOG_OPTS_N_TYPES ) ;
2006-03-11 13:00:56 +03:00
AdvancedLogOptionsDialog dlg ( this , - 1 ) ;
dlg . ShowModal ( ) ;
2002-09-19 08:52:03 +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
// How is this going to work?
// The dialog box shows the value of CPU registers, which will be changing
// all the time. What causes the dialog to reread the register value and
// display it? Brainstorm:
// 1) The update could be controlled by a real-time timer.
// 2) It could be triggered by periodic BX_SYNC_EVT_TICK events.
// 3) It could be triggered by changes in the actual value. This is
// good for values that rarely change, but horrible for values like
// EIP that change constantly.
// 4) An update can be forced by explictly calling an update function. For
// example after a single-step you would want to force an update. If you
// interrupt the simulation, you want to force an update. If you manually
// change a parameter, you would force an update.
// When simulation is free running, #1 or #2 might make sense. Try #2.
void MyFrame : : OnShowCpu ( wxCommandEvent & WXUNUSED ( event ) )
{
2006-04-16 14:12:32 +04:00
if ( SIM - > get_param ( BXPN_WX_CPU0_STATE ) = = 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 params not initialized yet, then give up
2006-03-18 19:30:52 +03:00
wxMessageBox ( wxT ( " Cannot show the debugger window until the simulation has begun. " ) ,
wxT ( " Sim not started " ) , wxOK | wxICON_ERROR , this ) ;
- 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
return ;
}
- 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
if ( showCpu = = NULL ) {
2006-03-11 13:00:56 +03:00
showCpu = new CpuRegistersDialog ( this , - 1 ) ;
2002-09-16 19:28:19 +04:00
# if BX_DEBUGGER
2006-03-18 19:30:52 +03:00
showCpu - > SetTitle ( wxT ( " Bochs Debugger " ) ) ;
2002-09-19 00:59:05 +04:00
# else
2006-03-18 19:30:52 +03:00
showCpu - > SetTitle ( wxT ( " CPU Registers " ) ) ;
2002-09-16 19:28:19 +04:00
# endif
2006-03-11 13:00:56 +03:00
showCpu - > Init ( ) ;
- 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
} else {
2006-03-11 13:00:56 +03:00
showCpu - > CopyParamToGui ( ) ;
- 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
}
2006-03-11 13:00:56 +03:00
showCpu - > Show ( TRUE ) ;
- 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 MyFrame : : OnShowKeyboard ( wxCommandEvent & WXUNUSED ( event ) )
{
2006-04-16 14:12:32 +04:00
if ( SIM - > get_param ( BXPN_WX_KBD_STATE ) = = NULL ) {
2003-08-30 15:21:29 +04:00
// if params not initialized yet, then give up
2006-03-18 19:30:52 +03:00
wxMessageBox ( wxT ( " Cannot show the debugger window until the simulation has begun. " ) ,
wxT ( " Sim not started " ) , wxOK | wxICON_ERROR , this ) ;
2003-08-30 15:21:29 +04:00
return ;
}
- 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
if ( showKbd = = NULL ) {
2006-03-07 20:54:27 +03:00
showKbd = new ParamDialog ( this , - 1 ) ;
2006-03-18 19:30:52 +03:00
showKbd - > SetTitle ( wxT ( " Keyboard State (incomplete, this is a demo) " ) ) ;
2006-04-16 14:12:32 +04:00
showKbd - > AddParam ( SIM - > get_param ( BXPN_WX_KBD_STATE ) ) ;
2006-03-07 20:54:27 +03:00
showKbd - > Init ( ) ;
- 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
} else {
2006-03-07 20:54:27 +03:00
showKbd - > CopyParamToGui ( ) ;
- 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
}
2006-03-07 20:54:27 +03:00
showKbd - > Show ( TRUE ) ;
- 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-09-19 00:59:05 +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
void MyFrame : : OnDebugLog ( wxCommandEvent & WXUNUSED ( event ) )
{
2006-03-19 18:35:20 +03:00
wxASSERT ( showDebugLog ! = NULL ) ;
showDebugLog - > CopyParamToGui ( ) ;
showDebugLog - > Show ( TRUE ) ;
- 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
}
- 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
void
2006-03-18 19:30:52 +03:00
MyFrame : : DebugBreak ( )
- 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 ( debugCommand ) {
delete debugCommand ;
debugCommand = NULL ;
}
2006-03-19 18:35:20 +03:00
wxASSERT ( showDebugLog ! = NULL ) ;
2006-03-18 19:30:52 +03:00
showDebugLog - > AppendCommand ( " *** break *** " ) ;
SIM - > debug_break ( ) ;
- 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
}
2002-09-19 00:59:05 +04:00
- 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
void
2006-03-19 18:35:20 +03:00
MyFrame : : DebugCommand ( wxString cmd )
- 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
{
char buf [ 1024 ] ;
2006-03-19 18:35:20 +03:00
safeWxStrcpy ( buf , cmd , sizeof ( buf ) ) ;
DebugCommand ( buf ) ;
- 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
}
- 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
void
2006-03-19 18:35:20 +03:00
MyFrame : : DebugCommand ( const char * cmd )
- 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
{
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " debugger command: %s " ) , cmd ) ;
wxASSERT ( showDebugLog ! = NULL ) ;
showDebugLog - > AppendCommand ( cmd ) ;
- 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 ( debugCommand ! = NULL ) {
// one is already waiting
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " multiple debugger commands, discarding the earlier one " ) ) ;
- 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
delete debugCommand ;
debugCommand = NULL ;
}
int len = strlen ( cmd ) ;
char * tmp = new char [ len + 1 ] ;
2006-03-19 18:35:20 +03:00
strncpy ( tmp , cmd , len + 1 ) ;
- 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 an event is waiting for us, fill it an send back to sim_thread.
if ( debugCommandEvent ! = NULL ) {
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " sim_thread was waiting for this command '%s' " ) , tmp ) ;
2006-03-19 18:35:20 +03:00
wxASSERT ( debugCommandEvent - > type = = BX_SYNC_EVT_GET_DBG_COMMAND ) ;
- 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
debugCommandEvent - > u . debugcmd . command = tmp ;
debugCommandEvent - > retcode = 1 ;
2006-03-19 18:35:20 +03:00
sim_thread - > SendSyncResponse ( debugCommandEvent ) ;
wxASSERT ( debugCommand = = 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
debugCommandEvent = NULL ;
} else {
// store this command in debugCommand for the future
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " storing debugger command '%s' " ) , tmp ) ;
- 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
debugCommand = tmp ;
}
2002-09-19 00:59:05 +04:00
}
2002-09-16 19:28:19 +04:00
# endif
- 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
2002-04-18 04:22:20 +04:00
void MyFrame : : OnQuit ( wxCommandEvent & event )
{
2002-10-07 08:01:00 +04:00
wxBochsClosing = true ;
2006-09-03 15:06:54 +04:00
bx_user_quit = 1 ;
2002-10-07 08:01:00 +04:00
if ( ! sim_thread ) {
// no simulation thread is running. Just close the window.
Close ( TRUE ) ;
} else {
2006-03-18 19:30:52 +03:00
SIM - > set_notify_callback ( & MyApp : : DefaultCallback , this ) ;
2002-10-07 08:01:00 +04:00
// ask the simulator to stop. When it stops it will close this frame.
2006-03-18 19:30:52 +03:00
SetStatusText ( wxT ( " Waiting for simulation to stop... " ) ) ;
OnKillSim ( event ) ;
2002-10-07 08:01:00 +04:00
}
2002-04-18 04:22:20 +04:00
}
void MyFrame : : OnAbout ( wxCommandEvent & WXUNUSED ( event ) )
{
2006-03-19 12:24:10 +03:00
wxString str ( wxT ( " Bochs x86 Emulator version " ) ) ;
str + = wxString ( VER_STRING , wxConvUTF8 ) ;
str + = wxT ( " (wxWidgets port) " ) ;
2006-03-18 19:30:52 +03:00
wxMessageBox ( str , wxT ( " About Bochs " ) , wxOK | wxICON_INFORMATION , this ) ;
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
// update the menu items, status bar, etc.
2006-03-19 18:35:20 +03:00
void MyFrame : : simStatusChanged ( StatusChange change , bx_bool popupNotify ) {
2006-02-26 22:11:20 +03:00
char ata_name [ 20 ] ;
bx_list_c * base ;
- 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
switch ( change ) {
case Start : // running
2006-03-18 19:30:52 +03:00
wxLogStatus ( wxT ( " Starting Bochs simulation " ) ) ;
menuSimulate - > Enable ( ID_Simulate_Start , FALSE ) ;
menuSimulate - > Enable ( ID_Simulate_PauseResume , TRUE ) ;
menuSimulate - > Enable ( ID_Simulate_Stop , TRUE ) ;
menuSimulate - > SetLabel ( ID_Simulate_PauseResume , wxT ( " &Pause " ) ) ;
- 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
break ;
case Stop : // not running
2006-03-18 19:30:52 +03:00
wxLogStatus ( wxT ( " Simulation stopped " ) ) ;
menuSimulate - > Enable ( ID_Simulate_Start , TRUE ) ;
menuSimulate - > Enable ( ID_Simulate_PauseResume , FALSE ) ;
menuSimulate - > Enable ( ID_Simulate_Stop , FALSE ) ;
menuSimulate - > SetLabel ( ID_Simulate_PauseResume , wxT ( " &Pause " ) ) ;
2006-09-04 22:36:47 +04:00
# if BX_DEBUGGER
showDebugLog - > Show ( FALSE ) ;
# endif
- 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
// This should only be used if the simulation stops due to error.
// Obviously if the user asked it to stop, they don't need to be told.
if ( popupNotify )
2006-03-18 19:30:52 +03:00
wxMessageBox ( wxT ( " Bochs simulation has stopped. " ) , wxT ( " Bochs Stopped " ) ,
2003-08-23 09:34:40 +04:00
wxOK | wxICON_INFORMATION , this ) ;
- 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
break ;
case Pause : // pause
2006-03-18 19:30:52 +03:00
wxLogStatus ( wxT ( " Pausing simulation " ) ) ;
2006-03-19 18:35:20 +03:00
menuSimulate - > SetLabel ( ID_Simulate_PauseResume , wxT ( " &Resume " ) ) ;
- 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
break ;
case Resume : // resume
2006-03-18 19:30:52 +03:00
wxLogStatus ( wxT ( " Resuming simulation " ) ) ;
2006-03-19 18:35:20 +03:00
menuSimulate - > SetLabel ( ID_Simulate_PauseResume , wxT ( " &Pause " ) ) ;
- 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
break ;
}
2002-08-30 03:18:10 +04:00
bool canConfigure = ( change = = Stop ) ;
2006-03-19 18:35:20 +03:00
menuConfiguration - > Enable ( ID_Config_New , canConfigure ) ;
menuConfiguration - > Enable ( ID_Config_Read , canConfigure ) ;
2006-04-13 00:51:24 +04:00
# if BX_SUPPORT_SAVE_RESTORE
menuConfiguration - > Enable ( ID_State_Restore , canConfigure ) ;
# endif
2002-12-30 20:04:43 +03:00
// only enabled ATA channels with a cdrom connected are available at runtime
2006-02-27 15:03:56 +03:00
for ( unsigned i = 0 ; i < BX_MAX_ATA_CHANNEL ; i + + ) {
2006-02-26 22:11:20 +03:00
sprintf ( ata_name , " ata.%d.resources " , i ) ;
base = ( bx_list_c * ) SIM - > get_param ( ata_name ) ;
if ( ! SIM - > get_param_bool ( " enabled " , base ) - > get ( ) ) {
2006-02-27 15:03:56 +03:00
menuEdit - > Enable ( ID_Edit_ATA0 + i , canConfigure ) ;
2002-12-30 20:04:43 +03:00
} else {
2006-02-26 22:11:20 +03:00
sprintf ( ata_name , " ata.%d.master " , i ) ;
base = ( bx_list_c * ) SIM - > get_param ( ata_name ) ;
2006-02-27 15:03:56 +03:00
if ( SIM - > get_param_enum ( " type " , base ) - > get ( ) ! = BX_ATA_DEVICE_CDROM ) {
2006-02-26 22:11:20 +03:00
sprintf ( ata_name , " ata.%d.slave " , i ) ;
base = ( bx_list_c * ) SIM - > get_param ( ata_name ) ;
2006-02-27 15:03:56 +03:00
if ( SIM - > get_param_enum ( " type " , base ) - > get ( ) ! = BX_ATA_DEVICE_CDROM ) {
2006-02-26 22:11:20 +03:00
menuEdit - > Enable ( ID_Edit_ATA0 + i , canConfigure ) ;
}
2002-12-30 20:04:43 +03:00
}
}
}
2006-02-18 19:53:18 +03:00
menuEdit - > Enable ( ID_Edit_CPU , canConfigure ) ;
menuEdit - > Enable ( ID_Edit_Memory , canConfigure ) ;
2006-02-19 18:43:03 +03:00
menuEdit - > Enable ( ID_Edit_Clock_Cmos , canConfigure ) ;
2006-02-18 19:53:18 +03:00
menuEdit - > Enable ( ID_Edit_PCI , canConfigure ) ;
2006-02-24 01:48:57 +03:00
menuEdit - > Enable ( ID_Edit_Boot , canConfigure ) ;
2006-02-18 19:53:18 +03:00
menuEdit - > Enable ( ID_Edit_Network , canConfigure ) ;
2002-08-30 03:18:10 +04:00
// during simulation, certain menu options like the floppy disk
// can be modified under some circumstances. A floppy drive can
// only be edited if it was enabled at boot time.
2006-09-03 20:55:35 +04:00
Bit64u value ;
value = SIM - > get_param_enum ( BXPN_FLOPPYA_DEVTYPE ) - > get ( ) ;
menuEdit - > Enable ( ID_Edit_FD_0 , canConfigure | | ( value ! = BX_FLOPPY_NONE ) ) ;
bxToolBar - > EnableTool ( ID_Edit_FD_0 , canConfigure | | ( value ! = BX_FLOPPY_NONE ) ) ;
value = SIM - > get_param_enum ( BXPN_FLOPPYB_DEVTYPE ) - > get ( ) ;
menuEdit - > Enable ( ID_Edit_FD_1 , canConfigure | | ( value ! = BX_FLOPPY_NONE ) ) ;
bxToolBar - > EnableTool ( ID_Edit_FD_1 , canConfigure | | ( value ! = BX_FLOPPY_NONE ) ) ;
bxToolBar - > EnableTool ( ID_Edit_Cdrom , canConfigure | | ( SIM - > get_first_cdrom ( ) ! = NULL ) ) ;
- 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
void MyFrame : : OnStartSim ( wxCommandEvent & event )
2002-04-18 04:22:20 +04:00
{
wxCriticalSectionLocker lock ( sim_thread_lock ) ;
if ( sim_thread ! = NULL ) {
2006-03-18 19:30:52 +03:00
wxMessageBox (
wxT ( " Can't start Bochs simulator, because it is already running " ) ,
wxT ( " Already Running " ) , wxOK | wxICON_ERROR , this ) ;
2002-11-01 18:28:41 +03:00
return ;
2002-04-18 04:22:20 +04:00
}
2002-10-26 17:22:47 +04:00
// check that display library is set to wx. If not, give a warning and
// change it to wx. It is technically possible to use other vga libraries
// with the wx config interface, but there are still some significant
// problems.
2006-02-22 00:35:09 +03:00
bx_param_enum_c * gui_param = SIM - > get_param_enum ( BXPN_SEL_DISPLAY_LIBRARY ) ;
char * gui_name = gui_param - > get_selected ( ) ;
if ( strcmp ( gui_name , " wx " ) ! = 0 ) {
2006-03-18 19:30:52 +03:00
wxMessageBox ( wxT (
2004-10-03 13:11:28 +04:00
" The display library was not set to wxWidgets. When you use the \n "
" wxWidgets configuration interface, you must also select the wxWidgets \n "
2006-03-18 19:30:52 +03:00
" display library. I will change it to 'wx' now. " ) ,
wxT ( " display library error " ) , wxOK | wxICON_WARNING , this ) ;
2006-03-19 18:35:20 +03:00
if ( ! gui_param - > set_by_name ( " wx " ) ) {
2006-03-18 19:30:52 +03:00
wxASSERT ( 0 & & " Could not set display library setting to 'wx " ) ;
2002-10-25 01:07:56 +04:00
}
}
// give warning about restarting the simulation
2002-04-18 04:22:20 +04:00
start_bochs_times + + ;
if ( start_bochs_times > 1 ) {
2006-03-18 19:30:52 +03:00
wxMessageBox ( wxT (
" You have already started the simulator once this session. Due to memory leaks and bugs in init code, you may get unstable behavior. " ) ,
wxT ( " 2nd time warning " ) , wxOK | wxICON_WARNING , this ) ;
2002-04-18 04:22:20 +04:00
}
num_events = 0 ; // clear the queue of events for bochs to handle
2006-03-19 18:35:20 +03:00
sim_thread = new SimThread ( this ) ;
sim_thread - > Create ( ) ;
sim_thread - > Run ( ) ;
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " Simulator thread has started. " ) ) ;
2002-04-18 04:22:20 +04:00
// set up callback for events from simulator thread
2006-03-19 18:35:20 +03:00
SIM - > set_notify_callback ( & SimThread : : SiminterfaceCallback , sim_thread ) ;
simStatusChanged ( Start ) ;
2002-04-18 04:22:20 +04:00
}
void MyFrame : : OnPauseResumeSim ( wxCommandEvent & WXUNUSED ( event ) )
{
wxCriticalSectionLocker lock ( sim_thread_lock ) ;
if ( sim_thread ) {
2006-03-19 18:35:20 +03:00
if ( sim_thread - > IsPaused ( ) ) {
simStatusChanged ( Resume ) ;
sim_thread - > Resume ( ) ;
} else {
simStatusChanged ( Pause ) ;
sim_thread - > Pause ( ) ;
}
2002-04-18 04:22:20 +04:00
}
}
void MyFrame : : OnKillSim ( wxCommandEvent & WXUNUSED ( event ) )
{
// DON'T use a critical section here. Delete implicitly calls
// OnSimThreadExit, which also tries to lock sim_thread_lock.
// If we grab the lock at this level, deadlock results.
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " OnKillSim() " ) ) ;
2002-09-14 01:53:37 +04:00
# if BX_DEBUGGER
// the sim_thread may be waiting for a debugger command. If so, send
// it a "quit"
2006-03-18 19:30:52 +03:00
DebugCommand ( " quit " ) ;
2002-09-14 01:53:37 +04:00
# endif
2002-04-18 04:22:20 +04:00
if ( sim_thread ) {
2006-09-03 15:06:54 +04:00
wxBochsStopSim = true ;
2006-03-18 19:30:52 +03:00
sim_thread - > Delete ( ) ;
- 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
// Next time the simulator reaches bx_real_sim_c::periodic() it
// will quit. This is better than killing the thread because it
// gives it a chance to clean up after itself.
2002-04-18 04:22:20 +04:00
}
2006-09-03 15:06:54 +04:00
if ( ! wxBochsClosing ) {
theFrame - > simStatusChanged ( theFrame - > Stop , true ) ;
}
2002-04-18 04:22:20 +04:00
}
void
2006-03-19 18:35:20 +03:00
MyFrame : : OnSimThreadExit ( ) {
wxCriticalSectionLocker lock ( sim_thread_lock ) ;
2002-04-18 04:22:20 +04:00
sim_thread = NULL ;
}
int
2006-03-19 18:35:20 +03:00
MyFrame : : HandleAskParamString ( bx_param_string_c * param )
2002-04-18 04:22:20 +04:00
{
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " HandleAskParamString start " ) ) ;
2006-03-19 18:35:20 +03:00
bx_param_num_c * opt = param - > get_options ( ) ;
wxASSERT ( opt ! = NULL ) ;
2006-02-27 15:03:56 +03:00
int n_opt = opt - > get ( ) ;
2006-05-30 20:05:51 +04:00
const char * msg = param - > get_label ( ) ;
2006-02-27 15:03:56 +03:00
if ( ( msg = = NULL ) | | ( strlen ( msg ) = = 0 ) ) {
msg = param - > get_name ( ) ;
}
2006-08-30 00:10:27 +04:00
char newval [ 512 ] ;
newval [ 0 ] = 0 ;
2002-04-18 04:22:20 +04:00
wxDialog * dialog = NULL ;
2006-08-30 00:10:27 +04:00
if ( n_opt & param - > SELECT_FOLDER_DLG ) {
// pass some initial dir to wxDirDialog
wxString homeDir ;
wxGetHomeDir ( & homeDir ) ;
wxDirDialog * ddialog = new wxDirDialog ( this , wxString ( msg , wxConvUTF8 ) , homeDir , wxDD_DEFAULT_STYLE ) ;
if ( ddialog - > ShowModal ( ) = = wxID_OK )
strncpy ( newval , ddialog - > GetPath ( ) . mb_str ( wxConvUTF8 ) , sizeof ( newval ) ) ;
dialog = ddialog ; // so I can delete it
} else if ( n_opt & param - > IS_FILENAME ) {
2002-04-18 04:22:20 +04:00
// use file open dialog
2006-08-30 00:10:27 +04:00
long style =
( n_opt & param - > SAVE_FILE_DIALOG ) ? wxSAVE | wxOVERWRITE_PROMPT : wxOPEN ;
wxFileDialog * fdialog = new wxFileDialog ( this , wxString ( msg , wxConvUTF8 ) , wxT ( " " ) , wxString ( param - > getptr ( ) , wxConvUTF8 ) , wxT ( " *.* " ) , style ) ;
if ( fdialog - > ShowModal ( ) = = wxID_OK )
strncpy ( newval , fdialog - > GetPath ( ) . mb_str ( wxConvUTF8 ) , sizeof ( newval ) ) ;
dialog = fdialog ; // so I can delete it
2002-04-18 04:22:20 +04:00
} else {
// use simple string dialog
2006-08-30 00:10:27 +04:00
long style = wxOK | wxCANCEL ;
wxTextEntryDialog * tdialog = new wxTextEntryDialog ( this , wxString ( msg , wxConvUTF8 ) , wxT ( " Enter new value " ) , wxString ( param - > getptr ( ) , wxConvUTF8 ) , style ) ;
if ( tdialog - > ShowModal ( ) = = wxID_OK )
strncpy ( newval , tdialog - > GetValue ( ) . mb_str ( wxConvUTF8 ) , sizeof ( newval ) ) ;
dialog = tdialog ; // so I can delete it
2002-04-18 04:22:20 +04:00
}
2006-08-30 00:10:27 +04:00
if ( strlen ( newval ) > 0 ) {
// change floppy path to this value.
wxLogDebug ( wxT ( " Setting param %s to '%s' " ) , param - > get_name ( ) , newval ) ;
param - > set ( newval ) ;
delete dialog ;
return 1 ;
2002-04-18 04:22:20 +04:00
}
delete dialog ;
return - 1 ;
}
// This is called when the simulator needs to ask the user to choose
// a value or setting. For example, when the user indicates that he wants
// to change the floppy disk image for drive A, an ask-param event is created
// with the parameter id set to BXP_FLOPPYA_PATH. The simulator blocks until
// the gui has displayed a dialog and received a selection from the user.
// In the current implemention, the GUI will look up the parameter's
// data structure using SIM->get_param() and then call the set method on the
// parameter to change the param. The return value only needs to return
// success or failure (failure = cancelled, or not implemented).
// Returns 1 if the user chose a value and the param was modified.
// Returns 0 if the user cancelled.
// Returns -1 if the gui doesn't know how to ask for that param.
int
2006-03-19 18:35:20 +03:00
MyFrame : : HandleAskParam ( BxEvent * event )
2002-04-18 04:22:20 +04:00
{
2006-03-19 18:35:20 +03:00
wxASSERT ( event - > type = = BX_SYNC_EVT_ASK_PARAM ) ;
2002-04-18 04:22:20 +04:00
bx_param_c * param = event - > u . param . param ;
2006-03-19 18:35:20 +03:00
Raise ( ) ; // bring window to front so that you will see the dialog
switch ( param - > get_type ( ) )
2002-04-18 04:22:20 +04:00
{
2006-03-19 18:35:20 +03:00
case BXT_PARAM_STRING :
return HandleAskParamString ( ( bx_param_string_c * ) param ) ;
2006-06-01 23:35:46 +04:00
case BXT_PARAM_BOOL :
2006-09-09 12:05:07 +04:00
{
long style = wxYES_NO ;
if ( ( ( bx_param_bool_c * ) param ) - > get ( ) = = 0 ) style | = wxNO_DEFAULT ;
( ( bx_param_bool_c * ) param ) - > set ( wxMessageBox ( wxString ( param - > get_description ( ) , wxConvUTF8 ) ,
wxString ( param - > get_label ( ) , wxConvUTF8 ) , style , this ) = = wxYES ) ;
return 0 ;
}
2006-03-19 18:35:20 +03:00
default :
{
wxString msg ;
msg . Printf ( wxT ( " ask param for parameter type %d is not implemented in wxWidgets " ) ,
param - > get_type ( ) ) ;
wxMessageBox ( msg , wxT ( " not implemented " ) , wxOK | wxICON_ERROR , this ) ;
return - 1 ;
}
2002-04-18 04:22:20 +04:00
}
return - 1 ; // could not display
}
2004-10-03 13:11:28 +04:00
// This is called from the wxWidgets GUI thread, when a Sim2CI event
- 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
// is found. (It got there via wxPostEvent in SiminterfaceCallback2, which is
// executed in the simulator Thread.)
2002-04-18 04:22:20 +04:00
void
2006-03-19 18:35:20 +03:00
MyFrame : : OnSim2CIEvent ( wxCommandEvent & event )
2002-04-18 04:22:20 +04:00
{
2006-03-18 19:30:52 +03:00
IFDBG_EVENT ( wxLogDebug ( wxT ( " received a bochs event in the GUI thread " ) ) ) ;
BxEvent * be = ( BxEvent * ) event . GetEventObject ( ) ;
IFDBG_EVENT ( wxLogDebug ( wxT ( " event type = %d " ) , ( int ) be - > type ) ) ;
2002-04-18 04:22:20 +04:00
// all cases should return. sync event handlers MUST send back a
- 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
// response. async event handlers MUST delete the event.
2002-04-18 04:22:20 +04:00
switch ( be - > type ) {
- 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
case BX_ASYNC_EVT_REFRESH :
2006-03-18 19:30:52 +03:00
RefreshDialogs ( ) ;
2002-09-26 02:54:23 +04:00
break ;
2002-04-18 04:22:20 +04:00
case BX_SYNC_EVT_ASK_PARAM :
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " before HandleAskParam " ) ) ;
2006-03-19 18:35:20 +03:00
be - > retcode = HandleAskParam ( be ) ;
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " after HandleAskParam " ) ) ;
2002-09-26 02:54:23 +04:00
// return a copy of the event back to the sender.
2002-04-18 04:22:20 +04:00
sim_thread - > SendSyncResponse ( be ) ;
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " after SendSyncResponse " ) ) ;
2002-09-26 02:54:23 +04:00
break ;
2002-09-19 00:59:05 +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
case BX_ASYNC_EVT_DBG_MSG :
2006-05-22 20:35:03 +04:00
showDebugLog - > AppendText ( wxString ( be - > u . logmsg . msg , wxConvUTF8 ) ) ;
- 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
// free the char* which was allocated in dbg_printf
2002-09-16 19:28:19 +04:00
delete [ ] ( ( char * ) be - > u . logmsg . msg ) ;
2002-09-26 02:54:23 +04:00
break ;
2002-09-16 19:28:19 +04:00
# endif
- 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
case BX_SYNC_EVT_LOG_ASK :
2002-04-18 04:22:20 +04:00
case BX_ASYNC_EVT_LOG_MSG :
2006-03-19 18:35:20 +03:00
OnLogMsg ( be ) ;
2002-09-26 02:54:23 +04:00
break ;
- 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
case BX_SYNC_EVT_GET_DBG_COMMAND :
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " BX_SYNC_EVT_GET_DBG_COMMAND received " ) ) ;
- 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 ( debugCommand = = NULL ) {
// no debugger command is ready to send, so don't send a response yet.
// When a command is issued, MyFrame::DebugCommand will fill in the
// event and call SendSyncResponse() so that the simulation thread can
// continue.
debugCommandEvent = be ;
//
2006-03-19 18:35:20 +03:00
if ( showCpu = = NULL | | ! showCpu - > IsShowing ( ) ) {
2002-11-01 18:28:41 +03:00
wxCommandEvent unused ;
2006-03-19 18:35:20 +03:00
OnShowCpu ( unused ) ;
- 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
}
} else {
// a debugger command is waiting for us!
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " sending debugger command '%s' that was waiting " ) , debugCommand ) ;
- 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
be - > u . debugcmd . command = debugCommand ;
debugCommand = NULL ; // ready for the next one
debugCommandEvent = NULL ;
be - > retcode = 1 ;
2006-03-19 18:35:20 +03:00
sim_thread - > SendSyncResponse ( be ) ;
- 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
}
2002-09-26 02:54:23 +04:00
break ;
2002-04-18 04:22:20 +04:00
default :
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " OnSim2CIEvent: event type %d ignored " ) , ( int ) be - > type ) ;
2002-09-26 02:54:23 +04:00
if ( ! BX_EVT_IS_ASYNC ( be - > type ) ) {
// if it's a synchronous event, and we fail to send back a response,
// the sim thread will wait forever. So send something!
- 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
sim_thread - > SendSyncResponse ( be ) ;
}
2002-09-26 02:54:23 +04:00
break ;
2002-04-18 04:22:20 +04:00
}
2002-09-26 02:54:23 +04:00
if ( BX_EVT_IS_ASYNC ( be - > type ) )
delete be ;
2002-04-18 04:22:20 +04:00
}
2006-03-19 18:35:20 +03:00
void MyFrame : : OnLogMsg ( BxEvent * be ) {
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " log msg: level=%d, prefix='%s', msg='%s' " ) ,
2002-09-25 22:40:15 +04:00
be - > u . logmsg . level ,
be - > u . logmsg . prefix ,
be - > u . logmsg . msg ) ;
2002-09-26 02:54:23 +04:00
if ( be - > type = = BX_ASYNC_EVT_LOG_MSG )
return ; // we don't have any place to display log messages
else
2006-03-19 18:35:20 +03:00
wxASSERT ( be - > type = = BX_SYNC_EVT_LOG_ASK ) ;
2006-03-19 12:24:10 +03:00
wxString levelName ( SIM - > get_log_level_name ( be - > u . logmsg . level ) , wxConvUTF8 ) ;
2006-03-19 18:35:20 +03:00
LogMsgAskDialog dlg ( this , - 1 , levelName ) ; // panic, error, etc.
2002-09-25 22:40:15 +04:00
# if !BX_DEBUGGER
2006-03-19 18:35:20 +03:00
dlg . EnableButton ( dlg . DEBUG , FALSE ) ;
2002-09-25 22:40:15 +04:00
# endif
2006-03-19 12:24:10 +03:00
dlg . SetContext ( wxString ( be - > u . logmsg . prefix , wxConvUTF8 ) ) ;
dlg . SetMessage ( wxString ( be - > u . logmsg . msg , wxConvUTF8 ) ) ;
2006-03-19 18:35:20 +03:00
int n = dlg . ShowModal ( ) ;
2002-09-25 22:40:15 +04:00
// turn the return value into the constant that logfunctions::ask is
// expecting. 0=continue, 1=continue but ignore future messages from this
2003-10-24 19:39:57 +04:00
// device, 2=die, 3=dump core, 4=debugger.
if ( n = = BX_LOG_ASK_CHOICE_CONTINUE ) {
2006-03-19 18:35:20 +03:00
if ( dlg . GetDontAsk ( ) ) n = BX_LOG_ASK_CHOICE_CONTINUE_ALWAYS ;
2002-09-25 22:40:15 +04:00
}
be - > retcode = n ;
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " you chose %d " ) , n ) ;
2002-09-25 22:40:15 +04:00
// This can be called from two different contexts:
// 1) before sim_thread starts, the default application callback can
// call OnLogMsg to display messages.
// 2) after the sim_thread starts, the sim_thread callback can call
// OnLogMsg to display messages
if ( sim_thread )
2006-03-19 18:35:20 +03:00
sim_thread - > SendSyncResponse ( be ) ; // only for case #2
2002-09-25 22:40:15 +04:00
}
2002-08-28 11:54:53 +04:00
bool
2006-03-19 18:35:20 +03:00
MyFrame : : editFloppyValidate ( FloppyConfigDialog * dialog )
2002-08-28 11:54:53 +04:00
{
2002-08-30 10:06:36 +04:00
// haven't done anything with this 'feature'
2002-08-28 11:54:53 +04:00
return true ;
}
2006-02-25 01:35:46 +03:00
void MyFrame : : editFloppyConfig ( int drive )
2002-08-28 11:54:53 +04:00
{
2006-02-25 01:35:46 +03:00
FloppyConfigDialog dlg ( this , - 1 ) ;
2006-03-19 12:24:10 +03:00
dlg . SetDriveName ( wxString ( drive = = 0 ? BX_FLOPPY0_NAME : BX_FLOPPY1_NAME , wxConvUTF8 ) ) ;
2006-02-25 01:35:46 +03:00
dlg . SetCapacityChoices ( n_floppy_type_names , floppy_type_names ) ;
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( ( drive = = 0 ) ? BXPN_FLOPPYA : BXPN_FLOPPYB ) ;
2006-03-18 19:30:52 +03:00
if ( ! list ) { wxLogError ( wxT ( " floppy object param is null " ) ) ; return ; }
2006-02-25 01:35:46 +03:00
bx_param_filename_c * fname = ( bx_param_filename_c * ) list - > get_by_name ( " path " ) ;
bx_param_enum_c * disktype = ( bx_param_enum_c * ) list - > get_by_name ( " type " ) ;
bx_param_enum_c * status = ( bx_param_enum_c * ) list - > get_by_name ( " status " ) ;
if ( fname - > get_type ( ) ! = BXT_PARAM_STRING
| | disktype - > get_type ( ) ! = BXT_PARAM_ENUM
2002-08-28 11:54:53 +04:00
| | status - > get_type ( ) ! = BXT_PARAM_ENUM ) {
2006-03-18 19:30:52 +03:00
wxLogError ( wxT ( " floppy params have wrong type " ) ) ;
2002-08-28 19:27:26 +04:00
return ;
2002-08-28 11:54:53 +04:00
}
2005-11-24 21:51:55 +03:00
if ( sim_thread = = NULL ) {
2006-03-18 19:30:52 +03:00
dlg . AddRadio ( wxT ( " Not Present " ) , wxT ( " " ) ) ;
2005-11-24 21:51:55 +03:00
}
2006-03-18 19:30:52 +03:00
dlg . AddRadio ( wxT ( " Ejected " ) , wxT ( " none " ) ) ;
2002-09-04 22:39:20 +04:00
# if defined(__linux__)
2006-03-18 19:30:52 +03:00
dlg . AddRadio ( wxT ( " Physical floppy drive /dev/fd0 " ) , wxT ( " /dev/fd0 " ) ) ;
dlg . AddRadio ( wxT ( " Physical floppy drive /dev/fd1 " ) , wxT ( " /dev/fd1 " ) ) ;
2002-09-04 22:39:20 +04:00
# elif defined(WIN32)
2006-03-18 19:30:52 +03:00
dlg . AddRadio ( wxT ( " Physical floppy drive A: " ) , wxT ( " A: " ) ) ;
dlg . AddRadio ( wxT ( " Physical floppy drive B: " ) , wxT ( " B: " ) ) ;
2002-09-04 22:39:20 +04:00
# else
// add your favorite operating system here
# endif
2006-02-25 01:35:46 +03:00
dlg . SetCapacity ( disktype - > get ( ) - disktype - > get_min ( ) ) ;
2006-03-19 12:24:10 +03:00
dlg . SetFilename ( wxString ( fname - > getptr ( ) , wxConvUTF8 ) ) ;
2006-03-19 18:35:20 +03:00
dlg . SetValidateFunc ( editFloppyValidate ) ;
2002-08-30 10:06:36 +04:00
if ( disktype - > get ( ) = = BX_FLOPPY_NONE ) {
2005-11-26 12:22:58 +03:00
dlg . SetRadio ( 0 ) ;
2006-02-25 01:35:46 +03:00
} else if ( ( status - > get ( ) = = BX_EJECTED ) | | ( ! strcmp ( " none " , fname - > getptr ( ) ) ) ) {
2005-11-26 12:22:58 +03:00
dlg . SetRadio ( ( sim_thread = = NULL ) ? 1 : 0 ) ;
2002-08-30 10:06:36 +04:00
} else {
// otherwise the SetFilename() should have done the right thing.
}
2006-02-25 01:35:46 +03:00
int n = dlg . ShowModal ( ) ;
2006-03-18 19:30:52 +03:00
wxLogMessage ( wxT ( " floppy config returned %d " ) , n ) ;
2002-09-01 23:38:08 +04:00
if ( n = = wxID_OK ) {
2002-09-01 19:27:33 +04:00
char filename [ 1024 ] ;
2006-02-25 01:35:46 +03:00
wxString fn ( dlg . GetFilename ( ) ) ;
2006-03-19 12:24:10 +03:00
strncpy ( filename , fn . mb_str ( wxConvUTF8 ) , sizeof ( filename ) ) ;
2006-03-18 19:30:52 +03:00
wxLogMessage ( wxT ( " filename is '%s' " ) , filename ) ;
wxLogMessage ( wxT ( " capacity = %d (%s) " ) , dlg . GetCapacity ( ) , floppy_type_names [ dlg . GetCapacity ( ) ] ) ;
2006-02-25 01:35:46 +03:00
fname - > set ( filename ) ;
disktype - > set ( disktype - > get_min ( ) + dlg . GetCapacity ( ) ) ;
2005-11-26 12:22:58 +03:00
if ( sim_thread = = NULL ) {
if ( dlg . GetRadio ( ) = = 0 ) {
2006-02-25 01:35:46 +03:00
disktype - > set ( BX_FLOPPY_NONE ) ;
2005-11-26 12:22:58 +03:00
}
} else {
if ( dlg . GetRadio ( ) > 0 ) {
status - > set ( BX_INSERTED ) ;
}
}
2002-08-28 11:54:53 +04:00
}
}
2006-03-18 19:30:52 +03:00
void MyFrame : : editFirstCdrom ( )
2002-08-30 10:06:36 +04:00
{
2006-03-18 19:30:52 +03:00
bx_param_c * firstcd = SIM - > get_first_cdrom ( ) ;
2002-12-12 19:52:21 +03:00
if ( ! firstcd ) {
2006-03-18 19:30:52 +03:00
wxMessageBox ( wxT ( " No CDROM drive is enabled. Use Edit:ATA to set one up. " ) ,
wxT ( " No CDROM " ) , wxOK | wxICON_ERROR , this ) ;
2002-12-12 19:52:21 +03:00
return ;
}
2006-03-18 19:30:52 +03:00
ParamDialog dlg ( this , - 1 ) ;
dlg . SetTitle ( wxT ( " Configure CDROM " ) ) ;
dlg . AddParam ( firstcd ) ;
dlg . SetRuntimeFlag ( sim_thread ! = NULL ) ;
dlg . ShowModal ( ) ;
2002-12-12 19:31:41 +03:00
}
2006-02-26 22:11:20 +03:00
void MyFrame : : OnEditATA ( wxCommandEvent & event )
2002-12-12 19:31:41 +03:00
{
2006-03-19 18:35:20 +03:00
int id = event . GetId ( ) ;
2002-12-12 19:31:41 +03:00
int channel = id - ID_Edit_ATA0 ;
2006-02-26 22:11:20 +03:00
char ata_name [ 10 ] ;
sprintf ( ata_name , " ata.%d " , channel ) ;
ParamDialog dlg ( this , - 1 ) ;
bx_list_c * list = ( bx_list_c * ) SIM - > get_param ( ata_name ) ;
2006-03-19 12:24:10 +03:00
dlg . SetTitle ( wxString ( list - > get_title ( ) - > getptr ( ) , wxConvUTF8 ) ) ;
2006-02-26 22:11:20 +03:00
dlg . AddParam ( list ) ;
dlg . SetRuntimeFlag ( sim_thread ! = NULL ) ;
dlg . ShowModal ( ) ;
2002-08-28 19:27:26 +04:00
}
2002-04-18 04:22:20 +04:00
void MyFrame : : OnToolbarClick ( wxCommandEvent & event )
{
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " clicked toolbar thingy " ) ) ;
2002-04-18 04:22:20 +04:00
bx_toolbar_buttons which = BX_TOOLBAR_UNDEFINED ;
2006-03-19 18:35:20 +03:00
int id = event . GetId ( ) ;
2002-04-18 04:22:20 +04:00
switch ( id ) {
2006-09-03 15:06:54 +04:00
case ID_Toolbar_Power : which = BX_TOOLBAR_POWER ; wxBochsStopSim = false ; break ;
2002-04-18 04:22:20 +04:00
case ID_Toolbar_Reset : which = BX_TOOLBAR_RESET ; break ;
2006-08-30 00:10:27 +04:00
# if BX_SUPPORT_SAVE_RESTORE
case ID_Toolbar_SaveRestore : which = BX_TOOLBAR_SAVE_RESTORE ; break ;
# endif
2002-08-30 03:18:10 +04:00
case ID_Edit_FD_0 :
2002-08-28 11:54:53 +04:00
// floppy config dialog box
2006-03-19 18:35:20 +03:00
editFloppyConfig ( 0 ) ;
2002-08-28 11:54:53 +04:00
break ;
2002-08-30 03:18:10 +04:00
case ID_Edit_FD_1 :
2002-08-28 11:54:53 +04:00
// floppy config dialog box
2006-03-19 18:35:20 +03:00
editFloppyConfig ( 1 ) ;
2002-08-28 11:54:53 +04:00
break ;
2002-12-12 19:31:41 +03:00
case ID_Edit_Cdrom :
// cdrom config dialog box (first cd only)
2006-03-19 18:35:20 +03:00
editFirstCdrom ( ) ;
2002-12-12 19:31:41 +03:00
break ;
2002-04-18 04:22:20 +04:00
case ID_Toolbar_Copy : which = BX_TOOLBAR_COPY ; break ;
case ID_Toolbar_Paste : which = BX_TOOLBAR_PASTE ; break ;
case ID_Toolbar_Snapshot : which = BX_TOOLBAR_SNAPSHOT ; break ;
case ID_Toolbar_Config : which = BX_TOOLBAR_CONFIG ; break ;
case ID_Toolbar_Mouse_en : which = BX_TOOLBAR_MOUSE_EN ; break ;
2002-08-09 10:16:43 +04:00
case ID_Toolbar_User : which = BX_TOOLBAR_USER ; break ;
2002-04-18 04:22:20 +04:00
default :
2006-03-18 19:30:52 +03:00
wxLogError ( wxT ( " unknown toolbar id %d " ) , id ) ;
2002-04-18 04:22:20 +04:00
}
if ( num_events < MAX_EVENTS ) {
event_queue [ num_events ] . type = BX_ASYNC_EVT_TOOLBAR ;
event_queue [ num_events ] . u . toolbar . button = which ;
num_events + + ;
}
}
- 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
// warning: This can be called from the simulator thread!!!
2006-03-19 18:35:20 +03:00
bool MyFrame : : WantRefresh ( ) {
- 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
bool anyShowing = false ;
2006-03-19 18:35:20 +03:00
if ( showCpu ! = NULL & & showCpu - > IsShowing ( ) ) anyShowing = true ;
if ( showKbd ! = NULL & & showKbd - > IsShowing ( ) ) anyShowing = true ;
- 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
return anyShowing ;
}
2006-03-19 18:35:20 +03:00
void MyFrame : : RefreshDialogs ( ) {
if ( showCpu ! = NULL & & showCpu - > IsShowing ( ) ) showCpu - > CopyParamToGui ( ) ;
if ( showKbd ! = NULL & & showKbd - > IsShowing ( ) ) showKbd - > CopyParamToGui ( ) ;
- 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-04-18 04:22:20 +04:00
//////////////////////////////////////////////////////////////////////
// Simulation Thread
//////////////////////////////////////////////////////////////////////
void *
2006-03-19 18:35:20 +03:00
SimThread : : Entry ( void )
2002-09-05 20:01:34 +04:00
{
2002-04-18 04:22:20 +04:00
// run all the rest of the Bochs simulator code. This function will
- 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
// run forever, unless a "kill_bochs_request" is issued. The shutdown
// procedure is as follows:
2002-04-18 04:22:20 +04:00
// - user selects "Kill Simulation" or GUI decides to kill bochs
2006-03-19 18:35:20 +03:00
// - GUI calls sim_thread->Delete()
2002-04-18 04:22:20 +04:00
// - sim continues to run until the next time it reaches SIM->periodic().
// - SIM->periodic() sends a synchronous tick event to the GUI, which
// finally calls TestDestroy() and realizes it needs to stop. It
2002-10-07 08:01:00 +04:00
// sets the sync event return code to -1. SIM->periodic() notices
// the -1 and calls quit_sim, which longjumps to quit_context, which is
// right here in SimThread::Entry.
2002-04-18 04:22:20 +04:00
// - Entry() exits and the thread stops. Whew.
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " in SimThread, starting at bx_continue_after_config_interface " ) ) ;
- 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
static jmp_buf context ; // this must not go out of scope. maybe static not needed
2006-03-19 18:35:20 +03:00
if ( setjmp ( context ) = = 0 ) {
SIM - > set_quit_context ( & context ) ;
SIM - > begin_simulation ( bx_startup_flags . argc , bx_startup_flags . argv ) ;
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " in SimThread, SIM->begin_simulation() exited normally " ) ) ;
- 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
} else {
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " in SimThread, SIM->begin_simulation() exited by longjmp " ) ) ;
- 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
}
2006-03-19 18:35:20 +03:00
SIM - > set_quit_context ( NULL ) ;
2002-09-05 20:01:34 +04:00
// it is possible that the whole interface has already been shut down.
// If so, we must end immediately.
2002-10-07 08:01:00 +04:00
// we're in the sim thread, so we must get a gui mutex before calling
2004-10-03 13:11:28 +04:00
// wxwidgets methods.
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " SimThread::Entry: get gui mutex " ) ) ;
2002-10-07 08:01:00 +04:00
wxMutexGuiEnter ( ) ;
if ( ! wxBochsClosing ) {
2006-09-03 15:06:54 +04:00
if ( ! wxBochsStopSim ) {
wxLogDebug ( wxT ( " SimThread::Entry: sim thread ending. call simStatusChanged " ) ) ;
theFrame - > simStatusChanged ( theFrame - > Stop , true ) ;
}
2002-10-07 08:01:00 +04:00
} else {
2006-03-18 19:30:52 +03:00
wxLogMessage ( wxT ( " SimThread::Entry: the gui is waiting for sim to finish. Now that it has finished, I will close the frame. " ) ) ;
2006-03-19 18:35:20 +03:00
theFrame - > Close ( TRUE ) ;
2002-09-05 20:01:34 +04:00
}
2002-10-07 08:01:00 +04:00
wxMutexGuiLeave ( ) ;
2002-04-18 04:22:20 +04:00
return NULL ;
}
void
2006-03-19 18:35:20 +03:00
SimThread : : OnExit ( )
2002-04-18 04:22:20 +04:00
{
// notify the MyFrame that the bochs thread has died. I can't adjust
// the sim_thread directly because it's private.
2006-03-19 18:35:20 +03:00
frame - > OnSimThreadExit ( ) ;
2002-09-25 22:40:15 +04:00
// don't use this SimThread's callback function anymore. Use the
// application default callback.
2006-03-19 18:35:20 +03:00
SIM - > set_notify_callback ( & MyApp : : DefaultCallback , this ) ;
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
// Event handler function for BxEvents coming from the simulator.
// This function is declared static so that I can get a usable
// function pointer for it. The function pointer is passed to
// SIM->set_notify_callback so that the siminterface can call this
// function when it needs to contact the gui. It will always be
// called with a pointer to the SimThread as the first argument, and
// it will be called from the simulator thread, not the GUI thread.
2002-04-18 04:22:20 +04:00
BxEvent *
2006-03-19 18:35:20 +03:00
SimThread : : SiminterfaceCallback ( void * thisptr , BxEvent * event )
2002-04-18 04:22:20 +04:00
{
SimThread * me = ( SimThread * ) thisptr ;
// call the normal non-static method now that we know the this pointer.
2006-03-19 18:35:20 +03:00
return me - > SiminterfaceCallback2 ( event ) ;
2002-04-18 04:22:20 +04:00
}
// callback function for sim thread events. This is called from
// the sim thread, not the GUI thread. So any GUI actions must be
// thread safe. Most events are handled by packaging up the event
// in a wxEvent of some kind, and posting it to the GUI thread for
// processing.
BxEvent *
2006-03-19 18:35:20 +03:00
SimThread : : SiminterfaceCallback2 ( BxEvent * event )
2002-04-18 04:22:20 +04:00
{
2006-03-19 18:35:20 +03:00
// wxLogDebug(wxT("SiminterfaceCallback with event type=%d"), (int)event->type);
2002-04-18 04:22:20 +04:00
event - > retcode = 0 ; // default return code
int async = BX_EVT_IS_ASYNC ( event - > type ) ;
if ( ! async ) {
// for synchronous events, clear away any previous response. There
2002-11-01 18:28:41 +03:00
// can only be one synchronous event pending at a time.
2006-03-19 18:35:20 +03:00
ClearSyncResponse ( ) ;
2002-11-01 18:28:41 +03:00
event - > retcode = - 1 ; // default to error
2002-04-18 04:22:20 +04:00
}
// tick event must be handled right here in the bochs thread.
if ( event - > type = = BX_SYNC_EVT_TICK ) {
2006-03-19 18:35:20 +03:00
if ( TestDestroy ( ) ) {
2002-11-01 18:28:41 +03:00
// tell simulator to quit
event - > retcode = - 1 ;
} else {
event - > retcode = 0 ;
}
return event ;
2002-04-18 04:22:20 +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
// prune refresh events if the frame is going to ignore them anyway
2006-03-19 18:35:20 +03:00
if ( event - > type = = BX_ASYNC_EVT_REFRESH & & ! theFrame - > WantRefresh ( ) ) {
- 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
delete event ;
return NULL ;
}
2004-10-03 13:11:28 +04:00
//encapsulate the bxevent in a wxwidgets event
2006-03-19 18:35:20 +03:00
wxCommandEvent wxevent ( wxEVT_COMMAND_MENU_SELECTED , ID_Sim2CI_Event ) ;
wxevent . SetEventObject ( ( wxEvent * ) event ) ;
if ( isSimThread ( ) ) {
2006-03-18 19:30:52 +03:00
IFDBG_EVENT ( wxLogDebug ( wxT ( " Sending an event to the window " ) ) ) ;
wxPostEvent ( frame , wxevent ) ;
2002-09-11 07:52:27 +04:00
// if it is an asynchronous event, return immediately. The event will be
// freed by the recipient in the GUI thread.
if ( async ) return NULL ;
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " SiminterfaceCallback2: synchronous event; waiting for response " ) ) ;
2002-09-11 07:52:27 +04:00
// now wait forever for the GUI to post a response.
BxEvent * response = NULL ;
while ( response = = NULL ) {
2006-03-19 18:35:20 +03:00
response = GetSyncResponse ( ) ;
2002-11-01 18:28:41 +03:00
if ( ! response ) {
//wxLogDebug ("no sync response yet, waiting");
2006-03-19 18:35:20 +03:00
this - > Sleep ( 20 ) ;
2002-11-01 18:28:41 +03:00
}
// don't get stuck here if the gui is trying to close.
if ( wxBochsClosing ) {
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " breaking out of sync event wait because gui is closing " ) ) ;
2002-11-01 18:28:41 +03:00
event - > retcode = - 1 ;
return event ;
}
2002-09-11 07:52:27 +04:00
}
2006-03-19 18:35:20 +03:00
wxASSERT ( response ! = NULL ) ;
2002-09-11 07:52:27 +04:00
return response ;
} else {
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " sim2ci event sent from the GUI thread. calling handler directly " ) ) ;
2006-03-19 18:35:20 +03:00
theFrame - > OnSim2CIEvent ( wxevent ) ;
2002-09-11 07:52:27 +04:00
return event ;
2002-04-18 04:22:20 +04:00
}
}
void
2006-03-19 18:35:20 +03:00
SimThread : : ClearSyncResponse ( )
2002-04-18 04:22:20 +04:00
{
wxCriticalSectionLocker lock ( sim2gui_mailbox_lock ) ;
if ( sim2gui_mailbox ! = NULL ) {
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " WARNING: ClearSyncResponse is throwing away an event that was previously in the mailbox " ) ) ;
2002-04-18 04:22:20 +04:00
}
sim2gui_mailbox = NULL ;
}
void
2006-03-18 19:30:52 +03:00
SimThread : : SendSyncResponse ( BxEvent * event )
2002-04-18 04:22:20 +04:00
{
wxCriticalSectionLocker lock ( sim2gui_mailbox_lock ) ;
if ( sim2gui_mailbox ! = NULL ) {
2006-03-18 19:30:52 +03:00
wxLogDebug ( wxT ( " WARNING: SendSyncResponse is throwing away an event that was previously in the mailbox " ) ) ;
2002-04-18 04:22:20 +04:00
}
sim2gui_mailbox = event ;
}
BxEvent *
2006-03-18 19:30:52 +03:00
SimThread : : GetSyncResponse ( )
2002-04-18 04:22:20 +04:00
{
wxCriticalSectionLocker lock ( sim2gui_mailbox_lock ) ;
BxEvent * event = sim2gui_mailbox ;
sim2gui_mailbox = NULL ;
return event ;
}
2002-09-03 00:13:52 +04:00
///////////////////////////////////////////////////////////////////
// utility
///////////////////////////////////////////////////////////////////
void
2006-03-18 19:30:52 +03:00
safeWxStrcpy ( char * dest , wxString src , int destlen )
2002-09-03 00:13:52 +04:00
{
2006-03-18 19:30:52 +03:00
wxString tmp ( src ) ;
2006-03-19 12:24:10 +03:00
strncpy ( dest , tmp . mb_str ( wxConvUTF8 ) , destlen ) ;
- 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
dest [ destlen - 1 ] = 0 ;
2002-09-03 00:13:52 +04:00
}
2002-10-25 01:07:56 +04:00
2002-11-19 08:47:45 +03:00
# endif /* if BX_WITH_WX */