Bochs/bochs/gui/wxmain.h

200 lines
5.5 KiB
C
Raw Normal View History

- 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
/////////////////////////////////////////////////////////////////
- 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
// $Id: wxmain.h,v 1.21 2002-09-06 16:43:24 bdenney 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
/////////////////////////////////////////////////////////////////
// This file defines variables and classes that the wxWindows .cc files
// share. It should be included only by wx.cc and wxmain.cc.
// forward class declaration so that each class can have a pointer to
// the others.
class MyFrame;
class MyPanel;
class SimThread;
class FloppyConfigDialog;
- 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
class ParamDialog;
//hack alert; yuck; FIXME
extern MyFrame *theFrame;
extern MyPanel *thePanel;
#define MAX_EVENTS 256
extern unsigned long num_events;
extern BxEvent event_queue[MAX_EVENTS];
enum
{
ID_Quit = 1,
ID_Config_New,
ID_Config_Read,
ID_Config_Save,
ID_Edit_FD_0,
ID_Edit_FD_1,
ID_Edit_HD_0,
ID_Edit_HD_1,
ID_Edit_Cdrom,
ID_Edit_Boot,
ID_Edit_Memory,
ID_Edit_Sound,
ID_Edit_Cmos,
ID_Edit_Network,
ID_Edit_Keyboard,
ID_Edit_Serial_Parallel,
ID_Edit_Parallel,
ID_Edit_LoadHack,
ID_Edit_Other,
ID_Simulate_Start,
ID_Simulate_PauseResume,
ID_Simulate_Stop,
ID_Simulate_Speed,
ID_Debug_ShowCpu,
- 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
ID_Debug_ShowKeyboard,
ID_Debug_ShowMemory,
ID_Log_View,
ID_Log_Prefs,
ID_Log_PrefsDevice,
ID_Help_About,
ID_Sim2CI_Event,
// ids for Bochs toolbar
ID_Toolbar_FloppyA,
ID_Toolbar_FloppyB,
ID_Toolbar_CdromD,
ID_Toolbar_Reset,
ID_Toolbar_Power,
ID_Toolbar_Copy,
ID_Toolbar_Paste,
ID_Toolbar_Snapshot,
ID_Toolbar_Config,
ID_Toolbar_Mouse_en,
ID_Toolbar_User,
// dialog box: LogMsgAskDialog
ID_Continue,
ID_Die,
ID_DumpCore,
ID_Debugger,
ID_Help,
// dialog box: FloppyConfigDialog
ID_None,
ID_Physical_A,
ID_Physical_B,
ID_Filename,
ID_FilenameText,
ID_Browse,
ID_Create,
// dialog box: HDConfigDialog
ID_Enable,
ID_Cylinders,
ID_Heads,
ID_SPT,
ID_Megs,
ID_ComputeGeometry,
// dialog box: LogOptions
ID_Advanced,
// that's all
ID_LAST_USER_DEFINED
};
- 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
// to compile in debug messages, change these defines to x. To remove them,
// change the defines to return nothing.
#define IFDBG_VGA(x) /* nothing */
//#define IFDBG_VGA(x) x
#define IFDBG_KEY(x) /* nothing */
//#define IFDBG_KEY(x) x
- 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
#define IFDBG_EVENT(x) /* nothing */
//#define IFDBG_EVENT(x) x
#define IFDBG_DLG(x) /* nothing */
//#define IFDBG_DLG(x) x
// defined in wxmain.cc
void safeWxStrcpy (char *dest, wxString src, int destlen);
/// the MyPanel methods are defined in wx.cc
class MyPanel: public wxPanel
{
Boolean fillBxKeyEvent (wxKeyEvent& event, BxKeyEvent& bxev, Boolean release); // for all platforms
Boolean fillBxKeyEvent_MSW (wxKeyEvent& event, BxKeyEvent& bxev, Boolean release);
Boolean fillBxKeyEvent_GTK (wxKeyEvent& event, BxKeyEvent& bxev, Boolean release);
public:
MyPanel(wxWindow* parent, wxWindowID id, const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = wxTAB_TRAVERSAL, const wxString& name = "panel")
: wxPanel (parent, id, pos, size, style, name)
{ wxLogDebug ("MyPanel constructor"); }
void OnKeyDown(wxKeyEvent& event);
void OnKeyUp(wxKeyEvent& event);
void OnPaint(wxPaintEvent& event);
void MyRefresh ();
void ReadConfiguration ();
void SaveConfiguration ();
private:
DECLARE_EVENT_TABLE()
};
/// the MyFrame methods are defined in wxmain.cc
class MyFrame: public wxFrame
{
MyPanel *panel;
// closing is set as soon as the Close(TRUE) is called. This informs any
// actions that may occur after the closing of the frame, so that they can
// quit A.S.A.P.
bool closing;
public:
MyFrame(const wxString& title, const wxPoint& pos, const wxSize& size, const long style);
~MyFrame();
enum StatusChange { Start, Stop, Pause, Resume };
bool IsClosing () { return closing; }
void simStatusChanged (StatusChange change, Boolean popupNotify=false);
void OnConfigNew(wxCommandEvent& event);
void OnConfigRead(wxCommandEvent& event);
void OnConfigSave(wxCommandEvent& event);
void OnQuit(wxCommandEvent& event);
void OnAbout(wxCommandEvent& event);
void OnStartSim(wxCommandEvent& event);
void OnPauseResumeSim(wxCommandEvent& event);
void OnKillSim(wxCommandEvent& event);
void OnSim2CIEvent(wxCommandEvent& event);
void OnEditBoot(wxCommandEvent& event);
void OnEditMemory(wxCommandEvent& event);
void OnEditSound(wxCommandEvent& event);
void OnEditCmos(wxCommandEvent& event);
void OnEditNet(wxCommandEvent& event);
void OnEditKeyboard(wxCommandEvent& event);
void OnEditSerialParallel(wxCommandEvent& event);
void OnEditLoadHack(wxCommandEvent& event);
void OnEditOther(wxCommandEvent& event);
void OnLogPrefs(wxCommandEvent& event);
void OnOtherEvent(wxCommandEvent& event);
- 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 OnShowCpu(wxCommandEvent& event);
void OnShowKeyboard(wxCommandEvent& event);
static bool editFloppyValidate (FloppyConfigDialog *dialog);
void editFloppyConfig (int drive);
void editHDConfig (int drive);
void editCdromConfig ();
void OnToolbarClick(wxCommandEvent& event);
int HandleAskParam (BxEvent *event);
int HandleAskParamString (bx_param_string_c *param);
// called from the sim thread's OnExit() method.
void OnSimThreadExit ();
SimThread *GetSimThread () { return sim_thread; }
private:
wxCriticalSection sim_thread_lock;
SimThread *sim_thread; // get the lock before accessing sim_thread
int start_bochs_times;
wxMenu *menuConfiguration;
wxMenu *menuEdit;
wxMenu *menuSimulate;
wxMenu *menuDebug;
wxMenu *menuLog;
wxMenu *menuHelp;
- 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
ParamDialog *showCpu, *showKbd;
void RefreshDialogs ();
public:
bool WantRefresh ();
DECLARE_EVENT_TABLE()
};