- 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
|
|
|
/////////////////////////////////////////////////////////////////
|
2011-02-25 01:05:47 +03:00
|
|
|
// $Id$
|
- 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
|
|
|
/////////////////////////////////////////////////////////////////
|
2013-02-11 01:26:51 +04:00
|
|
|
//
|
2021-01-21 21:10:40 +03:00
|
|
|
// Copyright (C) 2002-2021 The Bochs Project
|
2013-02-11 01:26:51 +04:00
|
|
|
//
|
2014-01-04 00:46:59 +04:00
|
|
|
// This library is free software; you can redistribute it and/or
|
|
|
|
// modify it under the terms of the GNU Lesser General Public
|
|
|
|
// License as published by the Free Software Foundation; either
|
|
|
|
// version 2 of the License, or (at your option) any later version.
|
|
|
|
//
|
|
|
|
// This library is distributed in the hope that it will be useful,
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
// Lesser General Public License for more details.
|
|
|
|
//
|
|
|
|
// You should have received a copy of the GNU Lesser General Public
|
|
|
|
// License along with this library; if not, write to the Free Software
|
|
|
|
// Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
|
|
|
//
|
|
|
|
/////////////////////////////////////////////////////////////////
|
|
|
|
|
2008-02-06 01:57:43 +03:00
|
|
|
// This file defines variables and classes that the wxWidgets .cc files
|
|
|
|
// share. It should be included only by wx.cc and wxmain.cc.
|
2002-04-18 04:22:20 +04:00
|
|
|
|
2008-02-06 01:57:43 +03:00
|
|
|
// forward class declaration so that each class can have a pointer to
|
2002-04-18 04:22:20 +04:00
|
|
|
// the others.
|
|
|
|
class MyFrame;
|
|
|
|
class MyPanel;
|
|
|
|
class SimThread;
|
- 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;
|
2014-01-12 23:27:01 +04:00
|
|
|
class LogViewDialog;
|
2002-04-18 04:22:20 +04:00
|
|
|
|
|
|
|
//hack alert; yuck; FIXME
|
|
|
|
extern MyFrame *theFrame;
|
|
|
|
|
2002-10-07 08:01:00 +04:00
|
|
|
// wxBochsClosing flag, see comments in wxmain.h
|
|
|
|
extern bool wxBochsClosing;
|
|
|
|
|
2002-04-18 04:22:20 +04:00
|
|
|
#define MAX_EVENTS 256
|
|
|
|
extern unsigned long num_events;
|
|
|
|
extern BxEvent event_queue[MAX_EVENTS];
|
|
|
|
|
2002-08-28 11:54:53 +04:00
|
|
|
enum
|
|
|
|
{
|
|
|
|
ID_Quit = 1,
|
|
|
|
ID_Config_New,
|
|
|
|
ID_Config_Read,
|
|
|
|
ID_Config_Save,
|
2006-04-13 00:51:24 +04:00
|
|
|
ID_State_Restore,
|
2012-02-18 20:25:10 +04:00
|
|
|
ID_Edit_Plugins,
|
2002-08-28 19:27:26 +04:00
|
|
|
ID_Edit_FD_0,
|
|
|
|
ID_Edit_FD_1,
|
2002-09-23 00:56:12 +04:00
|
|
|
ID_Edit_ATA0,
|
|
|
|
ID_Edit_ATA1,
|
|
|
|
ID_Edit_ATA2,
|
|
|
|
ID_Edit_ATA3,
|
2011-06-13 13:32:39 +04:00
|
|
|
ID_Edit_Cdrom1, // for toolbar. FIXME: toolbar can't handle >1 cdrom
|
2006-02-18 19:53:18 +03:00
|
|
|
ID_Edit_CPU,
|
2012-02-18 20:25:10 +04:00
|
|
|
ID_Edit_CPUID,
|
2002-08-28 11:54:53 +04:00
|
|
|
ID_Edit_Memory,
|
2006-02-22 00:35:09 +03:00
|
|
|
ID_Edit_Clock_Cmos,
|
2004-07-10 01:40:49 +04:00
|
|
|
ID_Edit_PCI,
|
2006-02-22 00:35:09 +03:00
|
|
|
ID_Edit_Display,
|
2006-02-24 01:48:57 +03:00
|
|
|
ID_Edit_Keyboard,
|
|
|
|
ID_Edit_Boot,
|
- 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
|
|
|
ID_Edit_Serial_Parallel,
|
2006-03-01 20:14:36 +03:00
|
|
|
ID_Edit_Network,
|
|
|
|
ID_Edit_Sound,
|
2002-08-28 11:54:53 +04:00
|
|
|
ID_Edit_Other,
|
|
|
|
ID_Simulate_Start,
|
|
|
|
ID_Simulate_PauseResume,
|
|
|
|
ID_Simulate_Stop,
|
|
|
|
ID_Log_View,
|
|
|
|
ID_Log_Prefs,
|
|
|
|
ID_Log_PrefsDevice,
|
|
|
|
ID_Help_About,
|
2002-08-29 18:59:37 +04:00
|
|
|
ID_Sim2CI_Event,
|
2002-08-28 11:54:53 +04:00
|
|
|
// ids for Bochs toolbar
|
|
|
|
ID_Toolbar_Reset,
|
|
|
|
ID_Toolbar_Power,
|
|
|
|
ID_Toolbar_Copy,
|
|
|
|
ID_Toolbar_Paste,
|
|
|
|
ID_Toolbar_Snapshot,
|
|
|
|
ID_Toolbar_Mouse_en,
|
|
|
|
ID_Toolbar_User,
|
2006-06-07 02:11:09 +04:00
|
|
|
ID_Toolbar_SaveRestore,
|
2002-08-28 11:54:53 +04:00
|
|
|
// dialog box: LogMsgAskDialog
|
|
|
|
ID_Continue,
|
|
|
|
ID_Die,
|
|
|
|
ID_DumpCore,
|
|
|
|
ID_Debugger,
|
|
|
|
ID_Help,
|
|
|
|
// dialog box: FloppyConfigDialog
|
2002-08-30 00:13:05 +04:00
|
|
|
ID_Create,
|
2002-09-02 21:03:14 +04:00
|
|
|
// dialog box: LogOptions
|
2009-03-28 01:22:07 +03:00
|
|
|
ID_Browse,
|
- 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
|
|
|
// dialog box: CpuRegistersDialog
|
|
|
|
ID_Debug_Continue,
|
|
|
|
ID_Debug_Stop,
|
|
|
|
ID_Debug_Step,
|
|
|
|
ID_Debug_Commit,
|
|
|
|
ID_Close,
|
2012-08-15 16:47:08 +04:00
|
|
|
// Debug console
|
- 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
|
|
|
ID_Execute,
|
|
|
|
ID_DebugCommand,
|
2002-09-19 08:52:03 +04:00
|
|
|
// advanced log options
|
|
|
|
ID_ApplyDefault,
|
2012-02-21 16:00:54 +04:00
|
|
|
// dialog box: PluginControlDialog
|
2021-01-21 21:10:40 +03:00
|
|
|
ID_PluginList1,
|
|
|
|
ID_PluginList2,
|
2012-02-21 16:00:54 +04:00
|
|
|
ID_Load,
|
|
|
|
ID_Unload,
|
- 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
|
|
|
// that's all
|
|
|
|
ID_LAST_USER_DEFINED
|
2002-08-28 11:54:53 +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
|
|
|
// to compile in debug messages, change these defines to x. To remove them,
|
2002-04-18 04:22:20 +04:00
|
|
|
// 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
|
|
|
|
|
2002-09-19 02:44:02 +04:00
|
|
|
#define IFDBG_MOUSE(x) /* nothing */
|
|
|
|
//#define IFDBG_MOUSE(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
|
|
|
|
|
2002-04-18 04:22:20 +04:00
|
|
|
|
2002-09-03 00:13:52 +04:00
|
|
|
// defined in wxmain.cc
|
2021-01-26 10:22:58 +03:00
|
|
|
int wx_ci_callback(void *userdata, ci_command_t command);
|
2006-03-19 18:35:20 +03:00
|
|
|
void safeWxStrcpy(char *dest, wxString src, int destlen);
|
2002-09-03 00:13:52 +04:00
|
|
|
|
2002-04-18 04:22:20 +04:00
|
|
|
/// the MyPanel methods are defined in wx.cc
|
|
|
|
class MyPanel: public wxPanel
|
|
|
|
{
|
2021-01-30 21:32:52 +03:00
|
|
|
bool fillBxKeyEvent(wxKeyEvent& event, BxKeyEvent& bxev, bool release); // for all platforms
|
|
|
|
bool fillBxKeyEvent_MSW(wxKeyEvent& event, BxKeyEvent& bxev, bool release);
|
|
|
|
bool fillBxKeyEvent_GTK(wxKeyEvent& event, BxKeyEvent& bxev, bool release);
|
2002-04-18 04:22:20 +04:00
|
|
|
public:
|
2006-03-18 19:30:52 +03:00
|
|
|
MyPanel(wxWindow* parent, wxWindowID id, const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = wxTAB_TRAVERSAL, const wxString& name = wxT("panel"));
|
2002-09-21 01:25:09 +04:00
|
|
|
~MyPanel();
|
2002-04-18 04:22:20 +04:00
|
|
|
void OnKeyDown(wxKeyEvent& event);
|
|
|
|
void OnKeyUp(wxKeyEvent& event);
|
2004-10-03 13:11:28 +04:00
|
|
|
void OnTimer(wxTimerEvent& event);
|
2002-09-19 02:44:02 +04:00
|
|
|
void OnPaint(wxPaintEvent& event);
|
|
|
|
void OnMouse(wxMouseEvent& event);
|
2014-12-27 18:57:30 +03:00
|
|
|
void OnKillFocus(wxFocusEvent& event);
|
2006-03-19 18:35:20 +03:00
|
|
|
void MyRefresh();
|
|
|
|
static void OnPluginInit();
|
|
|
|
void ToggleMouse(bool fromToolbar);
|
2002-04-18 04:22:20 +04:00
|
|
|
private:
|
2002-09-19 00:59:35 +04:00
|
|
|
bool needRefresh;
|
|
|
|
wxTimer refreshTimer;
|
2002-09-19 02:44:02 +04:00
|
|
|
Bit16s mouseSavedX, mouseSavedY;
|
|
|
|
Bit32u centerX, centerY;
|
2002-04-18 04:22:20 +04:00
|
|
|
DECLARE_EVENT_TABLE()
|
|
|
|
};
|
|
|
|
|
|
|
|
/// the MyFrame methods are defined in wxmain.cc
|
|
|
|
class MyFrame: public wxFrame
|
|
|
|
{
|
|
|
|
MyPanel *panel;
|
|
|
|
public:
|
|
|
|
MyFrame(const wxString& title, const wxPoint& pos, const wxSize& size, const long style);
|
2002-09-05 20:01:34 +04:00
|
|
|
~MyFrame();
|
- 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
|
|
|
enum StatusChange { Start, Stop, Pause, Resume };
|
2021-01-30 21:32:52 +03:00
|
|
|
void simStatusChanged(StatusChange change, bool popupNotify=false);
|
2002-08-30 20:23:36 +04:00
|
|
|
void OnConfigNew(wxCommandEvent& event);
|
2002-08-25 19:51:46 +04:00
|
|
|
void OnConfigRead(wxCommandEvent& event);
|
|
|
|
void OnConfigSave(wxCommandEvent& event);
|
2006-04-13 00:51:24 +04:00
|
|
|
void OnStateRestore(wxCommandEvent& event);
|
2002-04-18 04:22:20 +04:00
|
|
|
void OnQuit(wxCommandEvent& event);
|
|
|
|
void OnAbout(wxCommandEvent& event);
|
|
|
|
void OnStartSim(wxCommandEvent& event);
|
|
|
|
void OnPauseResumeSim(wxCommandEvent& event);
|
2021-01-30 21:32:52 +03:00
|
|
|
bool SimThreadControl(bool resume);
|
2002-04-18 04:22:20 +04:00
|
|
|
void OnKillSim(wxCommandEvent& event);
|
2002-08-29 18:59:37 +04:00
|
|
|
void OnSim2CIEvent(wxCommandEvent& event);
|
2016-12-29 12:47:07 +03:00
|
|
|
void OnLogDlg(BxEvent *be);
|
2012-02-18 20:25:10 +04:00
|
|
|
void OnEditPluginCtrl(wxCommandEvent& event);
|
2006-02-18 19:53:18 +03:00
|
|
|
void OnEditCPU(wxCommandEvent& event);
|
2012-02-18 20:25:10 +04:00
|
|
|
void OnEditCPUID(wxCommandEvent& event);
|
2002-09-03 00:13:52 +04:00
|
|
|
void OnEditMemory(wxCommandEvent& event);
|
2006-02-19 18:43:03 +03:00
|
|
|
void OnEditClockCmos(wxCommandEvent& event);
|
2004-07-10 01:40:49 +04:00
|
|
|
void OnEditPCI(wxCommandEvent& event);
|
2006-02-22 00:35:09 +03:00
|
|
|
void OnEditDisplay(wxCommandEvent& event);
|
2006-02-24 01:48:57 +03:00
|
|
|
void OnEditKeyboard(wxCommandEvent& event);
|
|
|
|
void OnEditBoot(wxCommandEvent& 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
|
|
|
void OnEditSerialParallel(wxCommandEvent& event);
|
2006-03-01 20:14:36 +03:00
|
|
|
void OnEditNet(wxCommandEvent& event);
|
|
|
|
void OnEditSound(wxCommandEvent& 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
|
|
|
void OnEditOther(wxCommandEvent& event);
|
2002-09-02 21:03:14 +04:00
|
|
|
void OnLogPrefs(wxCommandEvent& event);
|
2002-09-19 08:52:03 +04:00
|
|
|
void OnLogPrefsDevice(wxCommandEvent& event);
|
2014-01-12 23:27:01 +04:00
|
|
|
void OnLogView(wxCommandEvent& event);
|
2002-12-12 19:31:41 +03:00
|
|
|
void OnEditATA(wxCommandEvent& event);
|
2006-03-19 18:35:20 +03:00
|
|
|
void editFloppyConfig(int drive);
|
|
|
|
void editFirstCdrom();
|
2002-04-18 04:22:20 +04:00
|
|
|
void OnToolbarClick(wxCommandEvent& event);
|
2006-03-19 18:35:20 +03:00
|
|
|
int HandleAskParam(BxEvent *event);
|
|
|
|
int HandleAskParamString(bx_param_string_c *param);
|
2020-07-10 11:13:17 +03:00
|
|
|
void StatusbarUpdate(BxEvent *event);
|
2002-04-18 04:22:20 +04:00
|
|
|
|
|
|
|
// called from the sim thread's OnExit() method.
|
2006-03-19 18:35:20 +03:00
|
|
|
void OnSimThreadExit();
|
|
|
|
SimThread *GetSimThread() { return sim_thread; }
|
2002-04-18 04:22:20 +04:00
|
|
|
|
2013-12-26 12:37:51 +04:00
|
|
|
void UpdateToolBar(bool simPresent);
|
2013-12-24 21:18:46 +04:00
|
|
|
void SetToolBarHelp(int id, wxString& text);
|
|
|
|
|
2002-04-18 04:22:20 +04:00
|
|
|
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 *menuLog;
|
|
|
|
wxMenu *menuHelp;
|
2006-09-03 20:55:35 +04:00
|
|
|
wxToolBar *bxToolBar;
|
2014-01-12 23:27:01 +04:00
|
|
|
LogViewDialog *showLogView;
|
- apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc
----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep 6 12:13:28 EDT 2002
Description:
Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.) This is the first step toward
making something resembling a wxWindows debugger.
First, variables which are going to be visible in the CI must be
registered as parameters. For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.
To deal with this, I introduced the concept of a shadow parameter. A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value. Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods. Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.
To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.
The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class). I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value. At the moment, in the
Debug:Show CPU dialog, changing the values has no effect. However
this is trivial to add when it's time (just call CommitChanges!). It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.
The Refresh() method must be called periodically or else the dialog
will show the initial values forever. At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().
Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
implement shadow parameter class for Boolean, called bx_shadow_bool_c.
more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
its display. For now, the refresh event causes the CI to check every
parameter it is watching and change the display value. Later, it may
be worth the trouble to keep track of which parameters have actually
changed. Code in the simulator thread calls SIM->refresh_ci(), which
creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
the config interface. When it arrives in the wxWindows gui thread,
it calls RefreshDialogs(), which calls the Refresh() method on any
dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
is printed. Otherwise, the refresh would wait until the next
SIM->periodic(), which might be thousands of cycles. This way,
when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
which tells whether it has any need for refresh events. If no
dialogs are showing that need refresh events, then no event is sent
between threads.
- add a few defaults to the param classes that affect the settings of
newly created parameters. When declaring a lot of params with
similar settings it's more compact to set the default for new params
rather than to change each one separately. default_text_format is
the printf format string for displaying numbers. default_base is
the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
boxes such as "Debug:Show CPU". The new Refresh() method queries
all the parameters for their current value and changes the value in
the wxWindows control. The ParamDialog class still needs a little
work; for example, if it's modal it should have Cancel/Ok buttons,
but if it's going to be modeless it should maybe have Apply (commit
any changes) and Close.
2002-09-06 20:43:26 +04:00
|
|
|
public:
|
2002-04-18 04:22:20 +04:00
|
|
|
|
|
|
|
DECLARE_EVENT_TABLE()
|
|
|
|
};
|
|
|
|
|