Bochs/bochs/gui/siminterface.cc

1412 lines
38 KiB
C++
Raw Normal View History

/////////////////////////////////////////////////////////////////////////
// $Id: siminterface.cc,v 1.105 2004-01-05 22:18:01 cbothamy 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
// See siminterface.h for description of the siminterface concept.
// Basically, the siminterface is visible from both the simulator and
// the configuration user interface, and allows them to talk to each other.
#include "bochs.h"
bx_simulator_interface_c *SIM = NULL;
logfunctions *siminterface_log = NULL;
#define LOG_THIS siminterface_log->
// bx_simulator_interface just defines the interface that the Bochs simulator
// and the gui will use to talk to each other. None of the methods of
// bx_simulator_interface are implemented; they are all virtual. The
// bx_real_sim_c class is a child of bx_simulator_interface_c, and it
// implements all the methods. The idea is that a gui needs to know only
// definition of bx_simulator_interface to talk to Bochs. The gui should
// not need to include bochs.h.
//
// I made this separation to ensure that all guis use the siminterface to do
// access bochs internals, instead of accessing things like
// bx_keyboard.s.internal_buffer[4] (or whatever) directly. -Bryce
//
class bx_real_sim_c : public bx_simulator_interface_c {
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
bxevent_handler bxevent_callback;
void *bxevent_callback_data;
const char *registered_ci_name;
config_interface_callback_t ci_callback;
void *ci_callback_data;
int init_done;
bx_param_c **param_registry;
int registry_alloc_size;
int enabled;
// save context to jump to if we must quit unexpectedly
jmp_buf *quit_context;
int exit_code;
public:
bx_real_sim_c ();
virtual ~bx_real_sim_c ();
virtual void set_quit_context (jmp_buf *context) { quit_context = context; }
virtual int get_init_done () { return init_done; }
virtual int set_init_done (int n) { init_done = n; return 0;}
virtual void get_param_id_range (int *min, int *max) {
*min = BXP_NULL;
*max = BXP_THIS_IS_THE_LAST-1;
}
virtual int register_param (bx_id id, bx_param_c *it);
virtual void reset_all_param ();
virtual bx_param_c *get_param (bx_id id);
virtual bx_param_num_c *get_param_num (bx_id id);
virtual bx_param_string_c *get_param_string (bx_id id);
virtual bx_param_bool_c *get_param_bool (bx_id id);
virtual bx_param_enum_c *get_param_enum (bx_id id);
virtual int get_n_log_modules ();
virtual char *get_prefix (int mod);
virtual int get_log_action (int mod, int level);
virtual void set_log_action (int mod, int level, int action);
virtual char *get_action_name (int action);
virtual int get_default_log_action (int level) {
return logfunctions::get_default_action (level);
}
virtual void set_default_log_action (int level, int action) {
logfunctions::set_default_action (level, action);
}
2001-11-14 03:23:08 +03:00
virtual const char *get_log_level_name (int level);
virtual int get_max_log_level ();
virtual void quit_sim (int code);
virtual int get_exit_code () { return exit_code; }
virtual int get_default_rc (char *path, int len);
virtual int read_rc (char *path);
virtual int write_rc (char *path, int overwrite);
virtual int get_log_file (char *path, int len);
virtual int set_log_file (char *path);
virtual int get_log_prefix (char *prefix, int len);
virtual int set_log_prefix (char *prefix);
virtual int get_debugger_log_file (char *path, int len);
virtual int set_debugger_log_file (char *path);
virtual int get_floppy_options (int drive, bx_floppy_options *out);
virtual int get_cdrom_options (int drive, bx_atadevice_options *out, int *device = NULL);
virtual char *get_floppy_type_name (int type);
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
virtual void set_notify_callback (bxevent_handler func, void *arg);
virtual void get_notify_callback (bxevent_handler *func, void **arg);
virtual BxEvent* sim_to_ci_event (BxEvent *event);
- add Debug Log dialog, which shows all the text output that is normally printed to stderr in the text debugger. Also allows the user to type (text) debugger commands directly, which also appear in the log. - all text output in the debugger now passes through dbg_printf() (used to be fprintf to stderr) so that in wxWindows I can redirect it all to the wxWindows debug log screen. Added debug_fputs to siminterface which actually sends the text to the GUI by creating a BX_ASYNC_EVT_DBG_MSG event. - changed prefix and msg fields of BxLogMsgEvent to const char *, and also in args of logmsg method of siminterface. - don't trap SIGINT in wxWindows. There are other ways to stop execution. Also, signal handling with multiple threads is very strange and different on different platforms. - minor changes to fix gcc -Wall warnings in dbg_main.cc - add a new boolean parameter BXP_DEBUG_RUNNING that tells if the debugger is running freely or not. This is used by the wxWindows GUI to enable or disable certain choices. - CpuRegistersDialog has continue,stop,step buttons. When the sim is running freely, I disable continue and step, and enable stop. When the sim stops to wait for the user, I disable stop and enable continue and step. The change of enables used to be triggered by actually pressing the button, but then if you started/stopped the simulation in some other way (typing in debug log window) the enables were never changed. Now the enables are controlled by the value of BXP_DEBUG_RUNNING, which is set by the debug code itself, and the buttons are enabled at the right time. - ParamDialog::Refresh() is now virtual so that child classes can redefine its refresh behavior. - in safeWxStrcpy, force the last element of the array to be a 0, since I noticed that strncpy is not guaranteed to terminate the string! - modified: debug/dbg_main.cc debug/debug.h gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h
2002-09-15 15:21:35 +04:00
virtual int log_msg (const char *prefix, int level, const char *msg);
virtual int ask_param (bx_id which);
// ask the user for a pathname
virtual int ask_filename (char *filename, int maxlen, char *prompt, char *the_default, int flags);
// called at a regular interval, currently by the keyboard handler.
virtual void periodic ();
- Apply patch.replace-Boolean rev 1.3. Every "Boolean" is now changed to a "bx_bool" which is always defined as Bit32u on all platforms. In Carbon specific code, Boolean is still used because the Carbon header files define it to unsigned char. - this fixes bug [ 623152 ] MacOSX: Triple Exception Booting win95. The bug was that some code in Bochs depends on Boolean to be a 32 bit value. (This should be fixed, but I don't know all the places where it needs to be fixed yet.) Because Carbon defined Boolean as an unsigned char, Bochs just followed along and used the unsigned char definition to avoid compile problems. This exposed the dependency on 32 bit Boolean on MacOS X only and led to major simulation problems, that could only be reproduced and debugged on that platform. - On the mailing list we debated whether to make all Booleans into "bool" or our own type. I chose bx_bool for several reasons. 1. Unlike C++'s bool, we can guarantee that bx_bool is the same size on all platforms, which makes it much less likely to have more platform-specific simulation differences in the future. (I spent hours on a borrowed MacOSX machine chasing bug 618388 before discovering that different sized Booleans were the problem, and I don't want to repeat that.) 2. We still have at least one dependency on 32 bit Booleans which must be fixed some time, but I don't want to risk introducing new bugs into the simulation just before the 2.0 release. Modified Files: bochs.h config.h.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h plugin.cc plugin.h bios/rombios.c cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith64.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer16.cc cpu/ctrl_xfer32.cc cpu/ctrl_xfer64.cc cpu/data_xfer16.cc cpu/data_xfer32.cc cpu/data_xfer64.cc cpu/debugstuff.cc cpu/exception.cc cpu/fetchdecode.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io_pro.cc cpu/lazy_flags.cc cpu/lazy_flags.h cpu/mult16.cc cpu/mult32.cc cpu/mult64.cc cpu/mult8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/segment_ctrl_pro.cc cpu/stack_pro.cc cpu/tasking.cc debug/dbg_main.cc debug/debug.h debug/sim2.cc disasm/dis_decode.cc disasm/disasm.h doc/docbook/Makefile docs-html/cosimulation.html fpu/wmFPUemu_glue.cc gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxmain.cc gui/wxmain.h gui/x.cc instrument/example0/instrument.cc instrument/example0/instrument.h instrument/example1/instrument.cc instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/cdrom.cc iodev/cdrom.h iodev/cdrom_osx.cc iodev/cmos.cc iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_arpback.cc iodev/eth_packetmaker.cc iodev/eth_packetmaker.h iodev/floppy.cc iodev/floppy.h iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/ioapic.cc iodev/ioapic.h iodev/iodebug.cc iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.h iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/serial.cc iodev/serial.h iodev/vga.cc iodev/vga.h memory/memory.h memory/misc_mem.cc
2002-10-25 15:44:41 +04:00
virtual int create_disk_image (const char *filename, int sectors, bx_bool overwrite);
- 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
virtual void refresh_ci ();
virtual void refresh_vga () {
// maybe need to check if something has been initialized yet?
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
DEV_vga_refresh();
}
virtual void handle_events () {
// maybe need to check if something has been initialized yet?
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
bx_gui->handle_events ();
}
// find first hard drive or cdrom
bx_param_c *get_first_atadevice (Bit32u search_type);
bx_param_c *get_first_cdrom () {
return get_first_atadevice (BX_ATA_DEVICE_CDROM);
}
bx_param_c *get_first_hd () {
return get_first_atadevice (BX_ATA_DEVICE_DISK);
}
- add infrastructure for sending commands from the wxWindows interface to the Bochs debugger. The Bochs debugger calls SIM->debug_get_next_command() which does not return until a debugger command is found. The siminterface sends an synchronous event to the wxWindows thread with a blank to be filled in with a debugger command. wxWindows fills in the blank and sends the synchronous event back, and the Bochs debugger interprets it as if it was typed on the command line. For the long term I haven't decided whether to stick with sending text strings vs. some other method. - so far the wxWindows debugger consists of one big dialog box that shows all the standard registers, and a working Continue, Stop, and Step button. - modify ParamDialog so that it is more useful as a base class, by moving some things to protected members&fields, separating out functionality that is most likely to be replaced into virtual functions, and making it generally more flexible. The new CpuRegistersDialog is based on ParamDialog. - in wxdialog.cc, continue the convention of using wxID_HELP, wxID_OK, wxID_CANCEL, etc. for the id's of buttons, instead of wxHELP, wxOK, etc. which are intended to be ORred together in a bit field. - cpu/init.cc: put ifdefs around DEFPARAMs for flags in configurations where they don't exist. Add an eflags shadow parameter that represents all of the bits of eflags at once. There are also boolean shadow params for each bit. - modified files: cpu/init.cc debug/dbg_main.cc debug/debug.h gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h
2002-09-13 23:39:38 +04:00
#if BX_DEBUGGER
virtual void debug_break ();
virtual void debug_interpret_cmd (char *cmd);
virtual char *debug_get_next_command ();
virtual void debug_puts (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
#endif
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
virtual void register_configuration_interface (
const char* name,
config_interface_callback_t callback,
void *userdata);
virtual int configuration_interface(const char* name, ci_command_t command);
virtual int begin_simulation (int argc, char *argv[]);
virtual void set_sim_thread_func (is_sim_thread_func_t func) {}
virtual bool is_sim_thread ();
bool wxsel;
virtual bool is_wx_selected () { return wxsel; }
// provide interface to bx_gui->set_display_mode() method for config
// interfaces to use.
virtual void set_display_mode (disp_mode_t newmode) {
if (bx_gui != NULL)
bx_gui->set_display_mode (newmode);
}
virtual bool test_for_text_console ();
};
bx_param_c *
bx_real_sim_c::get_param (bx_id id)
{
BX_ASSERT (id >= BXP_NULL && id < BXP_THIS_IS_THE_LAST);
int index = (int)id - BXP_NULL;
bx_param_c *retval = param_registry[index];
if (!retval)
BX_INFO (("get_param can't find id %u", id));
return retval;
}
bx_param_num_c *
bx_real_sim_c::get_param_num (bx_id id) {
bx_param_c *generic = get_param(id);
if (generic==NULL) {
BX_PANIC (("get_param_num(%u) could not find a parameter", id));
return NULL;
}
int type = generic->get_type ();
if (type == BXT_PARAM_NUM || type == BXT_PARAM_BOOL || type == BXT_PARAM_ENUM)
return (bx_param_num_c *)generic;
BX_PANIC (("get_param_num %u could not find an integer parameter with that id", id));
return NULL;
}
bx_param_string_c *
bx_real_sim_c::get_param_string (bx_id id) {
bx_param_c *generic = get_param(id);
if (generic==NULL) {
BX_PANIC (("get_param_string(%u) could not find a parameter", id));
return NULL;
}
if (generic->get_type () == BXT_PARAM_STRING)
return (bx_param_string_c *)generic;
BX_PANIC (("get_param_string %u could not find an integer parameter with that id", id));
return NULL;
}
bx_param_bool_c *
bx_real_sim_c::get_param_bool (bx_id id) {
bx_param_c *generic = get_param(id);
if (generic==NULL) {
BX_PANIC (("get_param_bool(%u) could not find a parameter", id));
return NULL;
}
if (generic->get_type () == BXT_PARAM_BOOL)
return (bx_param_bool_c *)generic;
BX_PANIC (("get_param_bool %u could not find a bool parameter with that id", id));
return NULL;
}
bx_param_enum_c *
bx_real_sim_c::get_param_enum (bx_id id) {
bx_param_c *generic = get_param(id);
if (generic==NULL) {
BX_PANIC (("get_param_enum(%u) could not find a parameter", id));
return NULL;
}
if (generic->get_type () == BXT_PARAM_ENUM)
return (bx_param_enum_c *)generic;
BX_PANIC (("get_param_enum %u could not find a enum parameter with that id", id));
return NULL;
}
void bx_init_siminterface ()
{
siminterface_log = new logfunctions ();
2001-06-27 23:16:01 +04:00
siminterface_log->put ("CTRL");
siminterface_log->settype(CTRLLOG);
if (SIM == NULL)
SIM = new bx_real_sim_c();
}
bx_simulator_interface_c::bx_simulator_interface_c ()
{
}
bx_real_sim_c::bx_real_sim_c ()
{
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
bxevent_callback = NULL;
bxevent_callback_data = NULL;
ci_callback = NULL;
ci_callback_data = NULL;
is_sim_thread_func = NULL;
wxsel = false;
enabled = 1;
int i;
init_done = 0;
registry_alloc_size = BXP_THIS_IS_THE_LAST - BXP_NULL;
param_registry = new bx_param_c* [registry_alloc_size];
for (i=0; i<registry_alloc_size; i++)
param_registry[i] = NULL;
quit_context = NULL;
exit_code = 0;
}
// called by constructor of bx_param_c, so that every parameter that is
// initialized gets registered. This builds a list of all parameters
// which can be used to look them up by number (get_param).
bx_real_sim_c::~bx_real_sim_c ()
{
if ( param_registry != NULL )
{
delete [] param_registry;
param_registry = NULL;
}
}
int
bx_real_sim_c::register_param (bx_id id, bx_param_c *it)
{
if (id == BXP_NULL) return 0;
BX_ASSERT (id >= BXP_NULL && id < BXP_THIS_IS_THE_LAST);
int index = (int)id - BXP_NULL;
if (this->param_registry[index] != NULL) {
BX_INFO (("register_param is overwriting parameter id %d", id));
}
this->param_registry[index] = it;
return 0;
}
void
bx_real_sim_c::reset_all_param ()
{
bx_reset_options ();
}
int
bx_real_sim_c::get_n_log_modules ()
{
return io->get_n_logfns ();
}
char *
bx_real_sim_c::get_prefix (int mod)
{
logfunc_t *logfn = io->get_logfn (mod);
return logfn->getprefix ();
}
int
bx_real_sim_c::get_log_action (int mod, int level)
{
logfunc_t *logfn = io->get_logfn (mod);
return logfn->getonoff (level);
}
void
bx_real_sim_c::set_log_action (int mod, int level, int action)
{
// normal
if (mod >= 0) {
logfunc_t *logfn = io->get_logfn (mod);
logfn->setonoff (level, action);
return;
}
// if called with mod<0 loop over all
int nmod = get_n_log_modules ();
for (mod=0; mod<nmod; mod++)
set_log_action (mod, level, action);
}
char *
bx_real_sim_c::get_action_name (int action)
{
return io->getaction (action);
}
2001-11-14 03:23:08 +03:00
const char *
bx_real_sim_c::get_log_level_name (int level)
{
return io->getlevel (level);
}
int
bx_real_sim_c::get_max_log_level ()
{
return N_LOGLEV;
}
void
bx_real_sim_c::quit_sim (int code) {
BX_INFO (("quit_sim called with exit code %d", code));
exit_code = code;
// use longjmp to quit cleanly, no matter where in the stack we are.
//fprintf (stderr, "using longjmp() to jump directly to the quit context!\n");
if (quit_context != NULL) {
longjmp (*quit_context, 1);
BX_PANIC (("in bx_real_sim_c::quit_sim, longjmp should never return"));
}
if (SIM->is_wx_selected ()) {
// in wxWindows, the whole simulator is running in a separate thread.
// our only job is to end the thread as soon as possible, NOT to shut
// down the whole application with an exit.
BX_CPU(0)->async_event = 1;
BX_CPU(0)->kill_bochs_request = 1;
// the cpu loop will exit very soon after this condition is set.
} else {
// just a single thread. Use exit() to stop the application.
if (!code)
BX_PANIC (("Quit simulation command"));
::exit (exit_code);
}
}
int
bx_real_sim_c::get_default_rc (char *path, int len)
{
char *rc = bx_find_bochsrc ();
if (rc == NULL) return -1;
strncpy (path, rc, len);
path[len-1] = 0;
return 0;
}
int
bx_real_sim_c::read_rc (char *rc)
{
return bx_read_configuration (rc);
}
// return values:
// 0: written ok
// -1: failed
// -2: already exists, and overwrite was off
int
bx_real_sim_c::write_rc (char *rc, int overwrite)
{
return bx_write_configuration (rc, overwrite);
}
int
bx_real_sim_c::get_log_file (char *path, int len)
{
strncpy (path, bx_options.log.Ofilename->getptr (), len);
return 0;
}
int
bx_real_sim_c::set_log_file (char *path)
{
bx_options.log.Ofilename->set (path);
return 0;
}
int
bx_real_sim_c::get_log_prefix (char *prefix, int len)
{
strncpy (prefix, bx_options.log.Oprefix->getptr (), len);
return 0;
}
int
bx_real_sim_c::set_log_prefix (char *prefix)
{
bx_options.log.Oprefix->set (prefix);
return 0;
}
int
bx_real_sim_c::get_debugger_log_file (char *path, int len)
{
strncpy (path, bx_options.log.Odebugger_filename->getptr (), len);
return 0;
}
int
bx_real_sim_c::set_debugger_log_file (char *path)
{
bx_options.log.Odebugger_filename->set (path);
return 0;
}
int
bx_real_sim_c::get_floppy_options (int drive, bx_floppy_options *out)
{
*out = (drive==0)? bx_options.floppya : bx_options.floppyb;
return 0;
}
int
bx_real_sim_c::get_cdrom_options (int level, bx_atadevice_options *out, int *where)
{
for (Bit8u channel=0; channel<BX_MAX_ATA_CHANNEL; channel++) {
for (Bit8u device=0; device<2; device++) {
if (bx_options.atadevice[channel][device].Otype->get() == BX_ATA_DEVICE_CDROM) {
if (level==0) {
*out = bx_options.atadevice[channel][device];
if (where != NULL) *where=(channel*2)+device;
return 1;
}
else level--;
}
}
}
2001-06-12 00:51:15 +04:00
return 0;
}
char *bochs_start_names[] = { "quick", "load", "edit", "run" };
int n_bochs_start_names = 3;
char *floppy_type_names[] = { "none", "1.2M", "1.44M", "2.88M", "720K", "360K", "160K", "180K", "320K", NULL };
int floppy_type_n_sectors[] = { -1, 80*2*15, 80*2*18, 80*2*36, 80*2*9, 40*2*9, 40*1*8, 40*1*9, 40*2*8 };
int n_floppy_type_names = 9;
char *floppy_status_names[] = { "ejected", "inserted", NULL };
int n_floppy_status_names = 2;
char *floppy_bootdisk_names[] = { "floppy", "disk","cdrom", NULL };
int n_floppy_bootdisk_names = 3;
char *loader_os_names[] = { "none", "linux", "nullkernel", NULL };
int n_loader_os_names = 3;
char *keyboard_type_names[] = { "xt", "at", "mf", NULL };
int n_keyboard_type_names = 3;
char *atadevice_type_names[] = { "disk", "cdrom", NULL };
int n_atadevice_type_names = 2;
//char *atadevice_mode_names[] = { "flat", "concat", "external", "dll", "sparse", "vmware3", "split", "undoable", "growing", "volatile", "z-undoable", "z-volatile", NULL };
char *atadevice_mode_names[] = { "flat", "concat", "external", "dll", "sparse", "vmware3", "undoable", "growing", "volatile", NULL };
int n_atadevice_mode_names = 9;
char *atadevice_status_names[] = { "ejected", "inserted", NULL };
int n_atadevice_status_names = 2;
char *atadevice_biosdetect_names[] = { "none", "auto", "cmos", NULL };
int n_atadevice_biosdetect_names = 3;
char *atadevice_translation_names[] = { "none", "lba", "large", "rechs", "auto", NULL };
int n_atadevice_translation_names = 5;
char *clock_sync_names[] = { "none", "realtime", "slowdown", "both", NULL };
int clock_sync_n_names=4;
char *
bx_real_sim_c::get_floppy_type_name (int type)
{
BX_ASSERT (type >= BX_FLOPPY_NONE && type <= BX_FLOPPY_LAST);
type -= BX_FLOPPY_NONE;
return floppy_type_names[type];
}
void
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
bx_real_sim_c::set_notify_callback (bxevent_handler func, void *arg)
{
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
bxevent_callback = func;
bxevent_callback_data = arg;
}
2002-09-23 20:57:45 +04:00
void bx_real_sim_c::get_notify_callback (
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
bxevent_handler *func,
2002-09-23 20:57:45 +04:00
void **arg)
{
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
*func = bxevent_callback;
*arg = bxevent_callback_data;
2002-09-23 20:57:45 +04:00
}
BxEvent *
bx_real_sim_c::sim_to_ci_event (BxEvent *event)
{
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
if (bxevent_callback == NULL) {
BX_ERROR (("notify called, but no bxevent_callback function is registered"));
return NULL;
2001-06-12 00:51:15 +04:00
} else {
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
return (*bxevent_callback)(bxevent_callback_data, event);
}
}
// returns 0 for continue, 1 for alwayscontinue, 2 for die.
int
- add Debug Log dialog, which shows all the text output that is normally printed to stderr in the text debugger. Also allows the user to type (text) debugger commands directly, which also appear in the log. - all text output in the debugger now passes through dbg_printf() (used to be fprintf to stderr) so that in wxWindows I can redirect it all to the wxWindows debug log screen. Added debug_fputs to siminterface which actually sends the text to the GUI by creating a BX_ASYNC_EVT_DBG_MSG event. - changed prefix and msg fields of BxLogMsgEvent to const char *, and also in args of logmsg method of siminterface. - don't trap SIGINT in wxWindows. There are other ways to stop execution. Also, signal handling with multiple threads is very strange and different on different platforms. - minor changes to fix gcc -Wall warnings in dbg_main.cc - add a new boolean parameter BXP_DEBUG_RUNNING that tells if the debugger is running freely or not. This is used by the wxWindows GUI to enable or disable certain choices. - CpuRegistersDialog has continue,stop,step buttons. When the sim is running freely, I disable continue and step, and enable stop. When the sim stops to wait for the user, I disable stop and enable continue and step. The change of enables used to be triggered by actually pressing the button, but then if you started/stopped the simulation in some other way (typing in debug log window) the enables were never changed. Now the enables are controlled by the value of BXP_DEBUG_RUNNING, which is set by the debug code itself, and the buttons are enabled at the right time. - ParamDialog::Refresh() is now virtual so that child classes can redefine its refresh behavior. - in safeWxStrcpy, force the last element of the array to be a 0, since I noticed that strncpy is not guaranteed to terminate the string! - modified: debug/dbg_main.cc debug/debug.h gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h
2002-09-15 15:21:35 +04:00
bx_real_sim_c::log_msg (const char *prefix, int level, const char *msg)
{
BxEvent be;
be.type = BX_SYNC_EVT_LOG_ASK;
be.u.logmsg.prefix = prefix;
be.u.logmsg.level = level;
be.u.logmsg.msg = msg;
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
// default return value in case something goes wrong.
be.retcode = BX_LOG_ASK_CHOICE_DIE;
//fprintf (stderr, "calling notify.\n");
sim_to_ci_event (&be);
return be.retcode;
}
- I've added lots of comments in siminterface.h, and tried to clean up the terminology a bit. In particular, the term "gui" has started to mean different things in different contexts, so I've defined some more specific names for the parts of the user interface, and updated comments and some variable names to reflect it. See siminterface.h for a more complete description of all of these. VGAW: VGA display window and toolbar buttons, the traditional Bochs display which is ported to X, win32, MacOS X, etc. Implemented in gui/gui.* and platform dependent gui/*.cc files. CI: configuration interface that lets the user change settings such as floppy disk image, ne2k settings, log options. The CI consists of two parts: configuration user interface (CUI) which does the actual rendering to the screen and handles key/mouse/menu events, and the siminterface object. CUI: configuration user interface. This handles the user interactions that allow the user to configure Bochs. To actually change any values it talks to the siminterface object. One implementation of the CUI is the text-mode menus in gui/control.cc. Another implementation is (will be) the wxWindows menus and dialogs in gui/wxmain.cc. siminterface: the glue between the CUI and the simulation code, accessible throughout the code by the global variable bx_simulator_interface_c *SIM; Among other things, siminterface methods allow the simulator to ask the CUI to display things or ask for user input, and allows the CUI to query and modify variables in the simulation code. GUI: Literally, "graphical user interface". Until the configuration menus and wxWindows came along, everyone understood that "gui" referred to the VGA display window and the toolbar buttons because that's all there was. Now that we have the wxWindows code, which implements both the VGAW and the CUI, while all other platforms implement only the VGAW, it's not so clear. So, I'm trying to use VGAW, CI, and CUI consistently since they are more specific. control panel: This has been used as another name for the configuration interface. "control panel" is also somewhat unspecific and it sounds like it would be graphical with buttons and sliders, but our text-mode thing is not graphical at all. I've replaced "control panel" with "configuration interface" wherever I could find it. In configure script, the --disable-control-panel option is still supported, but it politely suggests that you use --disable-config-interface instead. - clean up comments in siminterface,wx* code - add comments and examples for bx_param_* and BxEvents - remove some obsolete stuff: notify_*_args, bx_simulator_interface_c::[sg]et_enabled() methods - in siminterface.cc, move a few bx_real_sim_c methods to where they belong, with the rest of the methods. No changes to the actual methods. - remove some DOS ^M's which crept in and confused my editor.
2002-08-26 19:31:23 +04:00
// Called by simulator whenever it needs the user to choose a new value
// for a registered parameter. Create a synchronous ASK_PARAM event,
// send it to the CI, and wait for the response. The CI will call the
- I've added lots of comments in siminterface.h, and tried to clean up the terminology a bit. In particular, the term "gui" has started to mean different things in different contexts, so I've defined some more specific names for the parts of the user interface, and updated comments and some variable names to reflect it. See siminterface.h for a more complete description of all of these. VGAW: VGA display window and toolbar buttons, the traditional Bochs display which is ported to X, win32, MacOS X, etc. Implemented in gui/gui.* and platform dependent gui/*.cc files. CI: configuration interface that lets the user change settings such as floppy disk image, ne2k settings, log options. The CI consists of two parts: configuration user interface (CUI) which does the actual rendering to the screen and handles key/mouse/menu events, and the siminterface object. CUI: configuration user interface. This handles the user interactions that allow the user to configure Bochs. To actually change any values it talks to the siminterface object. One implementation of the CUI is the text-mode menus in gui/control.cc. Another implementation is (will be) the wxWindows menus and dialogs in gui/wxmain.cc. siminterface: the glue between the CUI and the simulation code, accessible throughout the code by the global variable bx_simulator_interface_c *SIM; Among other things, siminterface methods allow the simulator to ask the CUI to display things or ask for user input, and allows the CUI to query and modify variables in the simulation code. GUI: Literally, "graphical user interface". Until the configuration menus and wxWindows came along, everyone understood that "gui" referred to the VGA display window and the toolbar buttons because that's all there was. Now that we have the wxWindows code, which implements both the VGAW and the CUI, while all other platforms implement only the VGAW, it's not so clear. So, I'm trying to use VGAW, CI, and CUI consistently since they are more specific. control panel: This has been used as another name for the configuration interface. "control panel" is also somewhat unspecific and it sounds like it would be graphical with buttons and sliders, but our text-mode thing is not graphical at all. I've replaced "control panel" with "configuration interface" wherever I could find it. In configure script, the --disable-control-panel option is still supported, but it politely suggests that you use --disable-config-interface instead. - clean up comments in siminterface,wx* code - add comments and examples for bx_param_* and BxEvents - remove some obsolete stuff: notify_*_args, bx_simulator_interface_c::[sg]et_enabled() methods - in siminterface.cc, move a few bx_real_sim_c methods to where they belong, with the rest of the methods. No changes to the actual methods. - remove some DOS ^M's which crept in and confused my editor.
2002-08-26 19:31:23 +04:00
// set() method on the parameter if the user changes the value.
int
bx_real_sim_c::ask_param (bx_id param)
{
bx_param_c *paramptr = SIM->get_param(param);
BX_ASSERT (paramptr != NULL);
// create appropriate event
BxEvent event;
event.type = BX_SYNC_EVT_ASK_PARAM;
event.u.param.param = paramptr;
sim_to_ci_event (&event);
return event.retcode;
- I've added lots of comments in siminterface.h, and tried to clean up the terminology a bit. In particular, the term "gui" has started to mean different things in different contexts, so I've defined some more specific names for the parts of the user interface, and updated comments and some variable names to reflect it. See siminterface.h for a more complete description of all of these. VGAW: VGA display window and toolbar buttons, the traditional Bochs display which is ported to X, win32, MacOS X, etc. Implemented in gui/gui.* and platform dependent gui/*.cc files. CI: configuration interface that lets the user change settings such as floppy disk image, ne2k settings, log options. The CI consists of two parts: configuration user interface (CUI) which does the actual rendering to the screen and handles key/mouse/menu events, and the siminterface object. CUI: configuration user interface. This handles the user interactions that allow the user to configure Bochs. To actually change any values it talks to the siminterface object. One implementation of the CUI is the text-mode menus in gui/control.cc. Another implementation is (will be) the wxWindows menus and dialogs in gui/wxmain.cc. siminterface: the glue between the CUI and the simulation code, accessible throughout the code by the global variable bx_simulator_interface_c *SIM; Among other things, siminterface methods allow the simulator to ask the CUI to display things or ask for user input, and allows the CUI to query and modify variables in the simulation code. GUI: Literally, "graphical user interface". Until the configuration menus and wxWindows came along, everyone understood that "gui" referred to the VGA display window and the toolbar buttons because that's all there was. Now that we have the wxWindows code, which implements both the VGAW and the CUI, while all other platforms implement only the VGAW, it's not so clear. So, I'm trying to use VGAW, CI, and CUI consistently since they are more specific. control panel: This has been used as another name for the configuration interface. "control panel" is also somewhat unspecific and it sounds like it would be graphical with buttons and sliders, but our text-mode thing is not graphical at all. I've replaced "control panel" with "configuration interface" wherever I could find it. In configure script, the --disable-control-panel option is still supported, but it politely suggests that you use --disable-config-interface instead. - clean up comments in siminterface,wx* code - add comments and examples for bx_param_* and BxEvents - remove some obsolete stuff: notify_*_args, bx_simulator_interface_c::[sg]et_enabled() methods - in siminterface.cc, move a few bx_real_sim_c methods to where they belong, with the rest of the methods. No changes to the actual methods. - remove some DOS ^M's which crept in and confused my editor.
2002-08-26 19:31:23 +04:00
}
- I'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
int
bx_real_sim_c::ask_filename (char *filename, int maxlen, char *prompt, char *the_default, int flags)
{
// implement using ASK_PARAM on a newly created param. I can't use
// ask_param because I don't intend to register this param.
BxEvent event;
bx_param_string_c param (BXP_NULL, prompt, "filename", the_default, maxlen);
- fixed up ParamDialog to correctly handle "trees" of parameters. A bx_list_c can now be displayed as either a wxStaticBox with the child parameters inside, or as a wxNotebook with each child parameter in a separate tab. (The children can also be lists of course.) The default display is the wxStaticBox type, but if you set the option bit bx_list_c::USE_TAB_WINDOW in the list, ParamDialog will use the wxNotebook display instead. - to get the param trees working, I created a new struct AddParamContext, which is passed to AddParam(). This struct is critical when AddParam calls itself recursively to display lists within lists. - use the wxNotebook display feature for the ATA0,1,2,3 controller dialog box. Now instead of being hundreds of pixels tall, it is reasonable height with three different tabs. This fixed bug #619074: "wx: ATA interface editor too tall" and was the whole reason I started messing with this at all. plus some minor cleanups - when I added the enum constant bx_list_c::USE_TAB_WINDOW, I also removed the BX_ prefix from all the other enum constants that are used in parameter options in siminterface.cc. Since these constants are enums within a class, there is no possibility of namespace conflicts so the prefix is not needed. - added wxADJUST_MINSIZE to all wxChoice controls, since that tells wxWindows to adjust its size to the length of the longest string. - instead of calling SetSize or SetSizeHints on every textcontrol with a hardcoded width, I am using just two wxSize specifications for everything: either normalTextSize or longTextSize. - edit names of a few menus and params. For example now instead of the tab saying "Master ATA device on channel 0" it will say "First HD/CD on channel 0". Modified Files: main.cc gui/control.cc gui/gui.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
2002-10-06 06:37:28 +04:00
flags |= param.IS_FILENAME;
- 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
param.get_options()->set (flags);
event.type = BX_SYNC_EVT_ASK_PARAM;
event.u.param.param = &param;
sim_to_ci_event (&event);
- 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
if (event.retcode >= 0)
memcpy (filename, param.getptr(), maxlen);
return event.retcode;
}
void
bx_real_sim_c::periodic ()
{
// give the GUI a chance to do periodic things on the bochs thread. in
// particular, notice if the thread has been asked to die.
BxEvent tick;
tick.type = BX_SYNC_EVT_TICK;
sim_to_ci_event (&tick);
if (tick.retcode < 0) {
- I've added lots of comments in siminterface.h, and tried to clean up the terminology a bit. In particular, the term "gui" has started to mean different things in different contexts, so I've defined some more specific names for the parts of the user interface, and updated comments and some variable names to reflect it. See siminterface.h for a more complete description of all of these. VGAW: VGA display window and toolbar buttons, the traditional Bochs display which is ported to X, win32, MacOS X, etc. Implemented in gui/gui.* and platform dependent gui/*.cc files. CI: configuration interface that lets the user change settings such as floppy disk image, ne2k settings, log options. The CI consists of two parts: configuration user interface (CUI) which does the actual rendering to the screen and handles key/mouse/menu events, and the siminterface object. CUI: configuration user interface. This handles the user interactions that allow the user to configure Bochs. To actually change any values it talks to the siminterface object. One implementation of the CUI is the text-mode menus in gui/control.cc. Another implementation is (will be) the wxWindows menus and dialogs in gui/wxmain.cc. siminterface: the glue between the CUI and the simulation code, accessible throughout the code by the global variable bx_simulator_interface_c *SIM; Among other things, siminterface methods allow the simulator to ask the CUI to display things or ask for user input, and allows the CUI to query and modify variables in the simulation code. GUI: Literally, "graphical user interface". Until the configuration menus and wxWindows came along, everyone understood that "gui" referred to the VGA display window and the toolbar buttons because that's all there was. Now that we have the wxWindows code, which implements both the VGAW and the CUI, while all other platforms implement only the VGAW, it's not so clear. So, I'm trying to use VGAW, CI, and CUI consistently since they are more specific. control panel: This has been used as another name for the configuration interface. "control panel" is also somewhat unspecific and it sounds like it would be graphical with buttons and sliders, but our text-mode thing is not graphical at all. I've replaced "control panel" with "configuration interface" wherever I could find it. In configure script, the --disable-control-panel option is still supported, but it politely suggests that you use --disable-config-interface instead. - clean up comments in siminterface,wx* code - add comments and examples for bx_param_* and BxEvents - remove some obsolete stuff: notify_*_args, bx_simulator_interface_c::[sg]et_enabled() methods - in siminterface.cc, move a few bx_real_sim_c methods to where they belong, with the rest of the methods. No changes to the actual methods. - remove some DOS ^M's which crept in and confused my editor.
2002-08-26 19:31:23 +04:00
BX_INFO (("Bochs thread has been asked to quit."));
bx_atexit ();
- 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
quit_sim (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
static int refresh_counter = 0;
if (++refresh_counter == 50) {
// only ask the CI to refresh every 50 times periodic() is called.
// This should obviously be configurable because system speeds and
// user preferences vary.
refresh_ci ();
refresh_counter = 0;
}
- 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
#if 0
// watch for memory leaks. Allocate a small block of memory, print the
// pointer that is returned, then free.
BxEvent *memcheck = new BxEvent ();
BX_INFO(("memory allocation at %p", memcheck));
delete memcheck;
#endif
}
// create a disk image file called filename, size=512 bytes * sectors.
// If overwrite is true and the file exists, returns -1 without changing it.
// Otherwise, opens up the image and starts writing. Returns -2 if
// the image could not be opened, or -3 if there are failures during
// write, e.g. disk full.
//
// wxWindows: This may be called from the gui thread.
int
bx_real_sim_c::create_disk_image (
const char *filename,
int sectors,
- Apply patch.replace-Boolean rev 1.3. Every "Boolean" is now changed to a "bx_bool" which is always defined as Bit32u on all platforms. In Carbon specific code, Boolean is still used because the Carbon header files define it to unsigned char. - this fixes bug [ 623152 ] MacOSX: Triple Exception Booting win95. The bug was that some code in Bochs depends on Boolean to be a 32 bit value. (This should be fixed, but I don't know all the places where it needs to be fixed yet.) Because Carbon defined Boolean as an unsigned char, Bochs just followed along and used the unsigned char definition to avoid compile problems. This exposed the dependency on 32 bit Boolean on MacOS X only and led to major simulation problems, that could only be reproduced and debugged on that platform. - On the mailing list we debated whether to make all Booleans into "bool" or our own type. I chose bx_bool for several reasons. 1. Unlike C++'s bool, we can guarantee that bx_bool is the same size on all platforms, which makes it much less likely to have more platform-specific simulation differences in the future. (I spent hours on a borrowed MacOSX machine chasing bug 618388 before discovering that different sized Booleans were the problem, and I don't want to repeat that.) 2. We still have at least one dependency on 32 bit Booleans which must be fixed some time, but I don't want to risk introducing new bugs into the simulation just before the 2.0 release. Modified Files: bochs.h config.h.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h plugin.cc plugin.h bios/rombios.c cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith64.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer16.cc cpu/ctrl_xfer32.cc cpu/ctrl_xfer64.cc cpu/data_xfer16.cc cpu/data_xfer32.cc cpu/data_xfer64.cc cpu/debugstuff.cc cpu/exception.cc cpu/fetchdecode.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io_pro.cc cpu/lazy_flags.cc cpu/lazy_flags.h cpu/mult16.cc cpu/mult32.cc cpu/mult64.cc cpu/mult8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/segment_ctrl_pro.cc cpu/stack_pro.cc cpu/tasking.cc debug/dbg_main.cc debug/debug.h debug/sim2.cc disasm/dis_decode.cc disasm/disasm.h doc/docbook/Makefile docs-html/cosimulation.html fpu/wmFPUemu_glue.cc gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxmain.cc gui/wxmain.h gui/x.cc instrument/example0/instrument.cc instrument/example0/instrument.h instrument/example1/instrument.cc instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/cdrom.cc iodev/cdrom.h iodev/cdrom_osx.cc iodev/cmos.cc iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_arpback.cc iodev/eth_packetmaker.cc iodev/eth_packetmaker.h iodev/floppy.cc iodev/floppy.h iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/ioapic.cc iodev/ioapic.h iodev/iodebug.cc iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.h iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/serial.cc iodev/serial.h iodev/vga.cc iodev/vga.h memory/memory.h memory/misc_mem.cc
2002-10-25 15:44:41 +04:00
bx_bool overwrite)
{
FILE *fp;
if (!overwrite) {
// check for existence first
fp = fopen (filename, "r");
if (fp) {
// yes it exists
fclose (fp);
return -1;
}
}
fp = fopen (filename, "w");
if (fp == NULL) {
#ifdef HAVE_PERROR
char buffer[1024];
sprintf (buffer, "while opening '%s' for writing", filename);
perror (buffer);
// not sure how to get this back into the CI
#endif
return -2;
}
int sec = sectors;
/*
* seek to sec*512-1 and write a single character.
* can't just do: fseek(fp, 512*sec-1, SEEK_SET)
* because 512*sec may be too large for signed int.
*/
while (sec > 0)
{
/* temp <-- min(sec, 4194303)
* 4194303 is (int)(0x7FFFFFFF/512)
*/
int temp = ((sec < 4194303) ? sec : 4194303);
fseek(fp, 512*temp, SEEK_CUR);
sec -= temp;
}
fseek(fp, -1, SEEK_CUR);
if (fputc('\0', fp) == EOF)
{
fclose (fp);
return -3;
}
fclose (fp);
return 0;
}
- 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 bx_real_sim_c::refresh_ci () {
if (SIM->is_wx_selected ()) {
// presently, only wxWindows interface uses these events
// It's an async event, so allocate a pointer and send it.
// The event will be freed by the recipient.
BxEvent *event = new BxEvent ();
event->type = BX_ASYNC_EVT_REFRESH;
sim_to_ci_event (event);
}
- add infrastructure for sending commands from the wxWindows interface to the Bochs debugger. The Bochs debugger calls SIM->debug_get_next_command() which does not return until a debugger command is found. The siminterface sends an synchronous event to the wxWindows thread with a blank to be filled in with a debugger command. wxWindows fills in the blank and sends the synchronous event back, and the Bochs debugger interprets it as if it was typed on the command line. For the long term I haven't decided whether to stick with sending text strings vs. some other method. - so far the wxWindows debugger consists of one big dialog box that shows all the standard registers, and a working Continue, Stop, and Step button. - modify ParamDialog so that it is more useful as a base class, by moving some things to protected members&fields, separating out functionality that is most likely to be replaced into virtual functions, and making it generally more flexible. The new CpuRegistersDialog is based on ParamDialog. - in wxdialog.cc, continue the convention of using wxID_HELP, wxID_OK, wxID_CANCEL, etc. for the id's of buttons, instead of wxHELP, wxOK, etc. which are intended to be ORred together in a bit field. - cpu/init.cc: put ifdefs around DEFPARAMs for flags in configurations where they don't exist. Add an eflags shadow parameter that represents all of the bits of eflags at once. There are also boolean shadow params for each bit. - modified files: cpu/init.cc debug/dbg_main.cc debug/debug.h gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h
2002-09-13 23:39:38 +04:00
}
bx_param_c *
bx_real_sim_c::get_first_atadevice (Bit32u search_type) {
for (int channel=0; channel<BX_MAX_ATA_CHANNEL; channel++) {
if (!bx_options.ata[channel].Opresent->get ())
continue;
for (int slave=0; slave<2; slave++) {
Bit32u present = bx_options.atadevice[channel][slave].Opresent->get ();
Bit32u type = bx_options.atadevice[channel][slave].Otype->get ();
if (present && (type == search_type)) {
return bx_options.atadevice[channel][slave].Omenu;
}
}
}
return NULL;
}
- add infrastructure for sending commands from the wxWindows interface to the Bochs debugger. The Bochs debugger calls SIM->debug_get_next_command() which does not return until a debugger command is found. The siminterface sends an synchronous event to the wxWindows thread with a blank to be filled in with a debugger command. wxWindows fills in the blank and sends the synchronous event back, and the Bochs debugger interprets it as if it was typed on the command line. For the long term I haven't decided whether to stick with sending text strings vs. some other method. - so far the wxWindows debugger consists of one big dialog box that shows all the standard registers, and a working Continue, Stop, and Step button. - modify ParamDialog so that it is more useful as a base class, by moving some things to protected members&fields, separating out functionality that is most likely to be replaced into virtual functions, and making it generally more flexible. The new CpuRegistersDialog is based on ParamDialog. - in wxdialog.cc, continue the convention of using wxID_HELP, wxID_OK, wxID_CANCEL, etc. for the id's of buttons, instead of wxHELP, wxOK, etc. which are intended to be ORred together in a bit field. - cpu/init.cc: put ifdefs around DEFPARAMs for flags in configurations where they don't exist. Add an eflags shadow parameter that represents all of the bits of eflags at once. There are also boolean shadow params for each bit. - modified files: cpu/init.cc debug/dbg_main.cc debug/debug.h gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h
2002-09-13 23:39:38 +04:00
#if BX_DEBUGGER
// this can be safely called from either thread.
void bx_real_sim_c::debug_break () {
bx_debug_break ();
}
// this should only be called from the sim_thread.
void bx_real_sim_c::debug_interpret_cmd (char *cmd) {
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
if (!is_sim_thread ()) {
- 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
fprintf (stderr, "ERROR: debug_interpret_cmd called but not from sim_thread\n");
return;
}
bx_dbg_interpret_line (cmd);
}
char *bx_real_sim_c::debug_get_next_command ()
{
fprintf (stderr, "begin debug_get_next_command\n");
BxEvent event;
event.type = BX_SYNC_EVT_GET_DBG_COMMAND;
BX_INFO (("asking for next debug command"));
sim_to_ci_event (&event);
- add infrastructure for sending commands from the wxWindows interface to the Bochs debugger. The Bochs debugger calls SIM->debug_get_next_command() which does not return until a debugger command is found. The siminterface sends an synchronous event to the wxWindows thread with a blank to be filled in with a debugger command. wxWindows fills in the blank and sends the synchronous event back, and the Bochs debugger interprets it as if it was typed on the command line. For the long term I haven't decided whether to stick with sending text strings vs. some other method. - so far the wxWindows debugger consists of one big dialog box that shows all the standard registers, and a working Continue, Stop, and Step button. - modify ParamDialog so that it is more useful as a base class, by moving some things to protected members&fields, separating out functionality that is most likely to be replaced into virtual functions, and making it generally more flexible. The new CpuRegistersDialog is based on ParamDialog. - in wxdialog.cc, continue the convention of using wxID_HELP, wxID_OK, wxID_CANCEL, etc. for the id's of buttons, instead of wxHELP, wxOK, etc. which are intended to be ORred together in a bit field. - cpu/init.cc: put ifdefs around DEFPARAMs for flags in configurations where they don't exist. Add an eflags shadow parameter that represents all of the bits of eflags at once. There are also boolean shadow params for each bit. - modified files: cpu/init.cc debug/dbg_main.cc debug/debug.h gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h
2002-09-13 23:39:38 +04:00
BX_INFO (("received next debug command: '%s'", event.u.debugcmd.command));
if (event.retcode >= 0)
return event.u.debugcmd.command;
return NULL;
}
- 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 bx_real_sim_c::debug_puts (const char *text)
- 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 (SIM->is_wx_selected ()) {
// send message to the wxWindows debugger
BxEvent *event = new BxEvent ();
event->type = BX_ASYNC_EVT_DBG_MSG;
event->u.logmsg.msg = text;
sim_to_ci_event (event);
// the event will be freed by the recipient
} else {
// text mode debugger: just write to console
fputs (text, stderr);
delete [] (char *)text;
}
- 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
#endif
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
void
bx_real_sim_c::register_configuration_interface (
const char* name,
config_interface_callback_t callback,
void *userdata)
{
ci_callback = callback;
ci_callback_data = userdata;
registered_ci_name = name;
}
int
bx_real_sim_c::configuration_interface(const char *ignore, ci_command_t command)
{
bx_param_enum_c *ci_param = SIM->get_param_enum (BXP_SEL_CONFIG_INTERFACE);
char *name = ci_param->get_choice (ci_param->get ());
if (!ci_callback) {
BX_PANIC (("no configuration interface was loaded"));
return -1;
}
if (strcmp (name, registered_ci_name) != 0) {
BX_PANIC (("siminterface does not support loading one configuration interface and then calling another"));
return -1;
}
if (!strcmp (name, "wx"))
wxsel = true;
else
wxsel = false;
// enter configuration mode, just while running the configuration interface
set_display_mode (DISP_MODE_CONFIG);
int retval = (*ci_callback)(ci_callback_data, command);
set_display_mode (DISP_MODE_SIM);
return retval;
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
}
int
bx_real_sim_c::begin_simulation (int argc, char *argv[])
{
return bx_begin_simulation (argc, argv);
}
bool bx_real_sim_c::is_sim_thread ()
{
if (is_sim_thread_func == NULL) return true;
return (*is_sim_thread_func)();
}
// check if the text console exists. On some platforms, if Bochs is
// started from the "Start Menu" or by double clicking on it on a Mac,
// there may be nothing attached to stdin/stdout/stderr. This function
// tests if stdin/stdout/stderr are usable and returns false if not.
bool
bx_real_sim_c::test_for_text_console ()
{
#if BX_WITH_CARBON
// In a Carbon application, you have a text console if you run the app from
// the command line, but if you start it from the finder you don't.
if(!isatty(STDIN_FILENO)) return false;
#endif
// default: yes
return true;
}
- 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
/////////////////////////////////////////////////////////////////////////
// define methods of bx_param_* and family
/////////////////////////////////////////////////////////////////////////
bx_object_c::bx_object_c (bx_id id)
{
this->id = id;
this->type = BXT_OBJECT;
}
void
bx_object_c::set_type (bx_objtype type)
{
this->type = 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
const char* bx_param_c::default_text_format = NULL;
bx_param_c::bx_param_c (bx_id id, char *name, char *description)
: bx_object_c (id)
{
set_type (BXT_PARAM);
this->name = name;
this->description = description;
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
this->text_format = default_text_format;
this->ask_format = NULL;
this->label = NULL;
this->runtime_param = 0;
this->enabled = 1;
SIM->register_param (id, this);
}
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
const char* bx_param_c::set_default_format (const char *f) {
const char *old = default_text_format;
default_text_format = f;
return old;
}
bx_param_num_c::bx_param_num_c (bx_id id,
char *name,
char *description,
Bit64s min, Bit64s max, Bit64s initial_val)
: bx_param_c (id, name, description)
{
set_type (BXT_PARAM_NUM);
this->min = min;
this->max = max;
this->initial_val = initial_val;
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
this->val.number = initial_val;
this->handler = NULL;
this->enable_handler = NULL;
- 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
this->base = default_base;
// dependent_list must be initialized before the set(),
// because set calls update_dependents().
dependent_list = NULL;
set (initial_val);
}
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
Bit32u bx_param_num_c::default_base = 10;
Bit32u bx_param_num_c::set_default_base (Bit32u val) {
Bit32u old = default_base;
default_base = val;
return old;
}
void
bx_param_num_c::reset ()
{
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
this->val.number = initial_val;
}
void
bx_param_num_c::set_handler (param_event_handler handler)
{
this->handler = handler;
// now that there's a handler, call set once to run the handler immediately
//set (get ());
}
void
bx_param_num_c::set_enable_handler (param_enable_handler handler)
{
this->enable_handler = handler;
}
void bx_param_num_c::set_dependent_list (bx_list_c *l) {
dependent_list = l;
update_dependents ();
}
Bit64s
bx_param_num_c::get64 ()
{
if (handler) {
// the handler can decide what value to return and/or do some side effect
- 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 (*handler)(this, 0, val.number);
} else {
// just return the value
- 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 val.number;
}
}
void
bx_param_num_c::set (Bit64s newval)
{
if (handler) {
// the handler can override the new value and/or perform some side effect
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
val.number = newval;
(*handler)(this, 1, newval);
} else {
// just set the value. This code does not check max/min.
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
val.number = newval;
}
2003-10-11 14:43:52 +04:00
if ((val.number < min || val.number > max) && (Bit64u)max != BX_MAX_BIT64U)
BX_PANIC (("numerical parameter %s was set to " FMT_LL "d, which is out of range " FMT_LL "d to " FMT_LL "d", get_name (), val.number, min, max));
if (dependent_list != NULL) update_dependents ();
}
void bx_param_num_c::set_range (Bit64u min, Bit64u max)
{
this->min = min;
this->max = max;
}
void bx_param_num_c::set_initial_val (Bit64s initial_val) {
this->val.number = this->initial_val = initial_val;
}
void bx_param_num_c::update_dependents ()
{
if (dependent_list) {
int en = val.number && enabled;
for (int i=0; i<dependent_list->get_size (); i++) {
bx_param_c *param = dependent_list->get (i);
if (param != this)
param->set_enabled (en);
}
}
- 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
bx_param_num_c::set_enabled (int en)
{
// The enable handler may wish to allow/disallow the action
if (enable_handler) {
en = (*enable_handler) (this, en);
}
bx_param_c::set_enabled (en);
update_dependents ();
}
// Signed 64 bit
bx_shadow_num_c::bx_shadow_num_c (bx_id id,
char *name,
char *description,
Bit64s *ptr_to_real_val,
Bit8u highbit,
Bit8u lowbit)
: bx_param_num_c (id, name, description, BX_MIN_BIT64S, BX_MAX_BIT64S, *ptr_to_real_val)
{
this->varsize = 16;
this->lowbit = lowbit;
this->mask = (1 << (highbit - lowbit)) - 1;
val.p64bit = ptr_to_real_val;
}
// Unsigned 64 bit
bx_shadow_num_c::bx_shadow_num_c (bx_id id,
char *name,
char *description,
Bit64u *ptr_to_real_val,
Bit8u highbit,
Bit8u lowbit)
: bx_param_num_c (id, name, description, BX_MIN_BIT64U, BX_MAX_BIT64U, *ptr_to_real_val)
{
this->varsize = 16;
this->lowbit = lowbit;
this->mask = (1 << (highbit - lowbit)) - 1;
val.p64bit = (Bit64s*) ptr_to_real_val;
}
// Signed 32 bit
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
bx_shadow_num_c::bx_shadow_num_c (bx_id id,
char *name,
char *description,
Bit32s *ptr_to_real_val,
Bit8u highbit,
Bit8u lowbit)
: bx_param_num_c (id, name, description, BX_MIN_BIT32S, BX_MAX_BIT32S, *ptr_to_real_val)
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
{
this->varsize = 16;
this->lowbit = lowbit;
this->mask = (1 << (highbit - lowbit)) - 1;
val.p32bit = ptr_to_real_val;
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
}
// Unsigned 32 bit
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
bx_shadow_num_c::bx_shadow_num_c (bx_id id,
char *name,
char *description,
Bit32u *ptr_to_real_val,
Bit8u highbit,
Bit8u lowbit)
: bx_param_num_c (id, name, description, BX_MIN_BIT32U, BX_MAX_BIT32U, *ptr_to_real_val)
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
{
this->varsize = 32;
this->lowbit = lowbit;
this->mask = (1 << (highbit - lowbit)) - 1;
val.p32bit = (Bit32s*) ptr_to_real_val;
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
}
// Signed 16 bit
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
bx_shadow_num_c::bx_shadow_num_c (bx_id id,
char *name,
char *description,
Bit16s *ptr_to_real_val,
Bit8u highbit,
Bit8u lowbit)
: bx_param_num_c (id, name, description, BX_MIN_BIT16S, BX_MAX_BIT16S, *ptr_to_real_val)
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
{
this->varsize = 16;
this->lowbit = lowbit;
this->mask = (1 << (highbit - lowbit)) - 1;
val.p16bit = ptr_to_real_val;
}
// Unsigned 16 bit
bx_shadow_num_c::bx_shadow_num_c (bx_id id,
char *name,
char *description,
Bit16u *ptr_to_real_val,
Bit8u highbit,
Bit8u lowbit)
: bx_param_num_c (id, name, description, BX_MIN_BIT16U, BX_MAX_BIT16U, *ptr_to_real_val)
{
this->varsize = 16;
this->lowbit = lowbit;
this->mask = (1 << (highbit - lowbit)) - 1;
val.p16bit = (Bit16s*) ptr_to_real_val;
}
// Signed 8 bit
bx_shadow_num_c::bx_shadow_num_c (bx_id id,
char *name,
char *description,
Bit8s *ptr_to_real_val,
Bit8u highbit,
Bit8u lowbit)
: bx_param_num_c (id, name, description, BX_MIN_BIT8S, BX_MAX_BIT8S, *ptr_to_real_val)
{
this->varsize = 16;
this->lowbit = lowbit;
this->mask = (1 << (highbit - lowbit)) - 1;
val.p8bit = ptr_to_real_val;
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
}
// Unsigned 8 bit
bx_shadow_num_c::bx_shadow_num_c (bx_id id,
char *name,
char *description,
Bit8u *ptr_to_real_val,
Bit8u highbit,
Bit8u lowbit)
: bx_param_num_c (id, name, description, BX_MIN_BIT8U, BX_MAX_BIT8U, *ptr_to_real_val)
{
this->varsize = 8;
this->lowbit = lowbit;
this->mask = (1 << (highbit - lowbit)) - 1;
val.p8bit = (Bit8s*) ptr_to_real_val;
}
Bit64s
bx_shadow_num_c::get64 () {
Bit64u current = 0;
switch (varsize) {
case 8: current = *(val.p8bit); break;
case 16: current = *(val.p16bit); break;
case 32: current = *(val.p32bit); break;
case 64: current = *(val.p64bit); break;
default: BX_PANIC(("unsupported varsize %d", varsize));
}
current = (current >> lowbit) & mask;
- 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 (handler) {
// the handler can decide what value to return and/or do some side effect
return (*handler)(this, 0, current) & mask;
- 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 {
// just return the value
return current;
- 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
bx_shadow_num_c::set (Bit64s newval)
- 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
{
Bit64u tmp = 0;
2003-10-11 14:43:52 +04:00
if ((newval < min || newval > max) && (Bit64u)max != BX_MAX_BIT64U)
BX_PANIC (("numerical parameter %s was set to " FMT_LL "d, which is out of range " FMT_LL "d to " FMT_LL "d", get_name (), newval, min, max));
switch (varsize) {
case 8:
tmp = (*(val.p8bit) >> lowbit) & mask;
tmp |= (newval & mask) << lowbit;
*(val.p8bit) = (Bit8s)tmp;
break;
case 16:
tmp = (*(val.p16bit) >> lowbit) & mask;
tmp |= (newval & mask) << lowbit;
*(val.p16bit) = (Bit16s)tmp;
break;
case 32:
tmp = (*(val.p32bit) >> lowbit) & mask;
tmp |= (newval & mask) << lowbit;
*(val.p32bit) = (Bit32s)tmp;
break;
case 64:
tmp = (*(val.p64bit) >> lowbit) & mask;
tmp |= (newval & mask) << lowbit;
*(val.p64bit) = tmp;
break;
default:
BX_PANIC(("unsupported varsize %d", varsize));
}
- 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 (handler) {
// the handler can override the new value and/or perform some side effect
(*handler)(this, 1, tmp);
}
}
bx_param_bool_c::bx_param_bool_c (bx_id id,
char *name,
char *description,
Bit64s initial_val)
: bx_param_num_c (id, name, description, 0, 1, initial_val)
{
set_type (BXT_PARAM_BOOL);
set (initial_val);
}
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
bx_shadow_bool_c::bx_shadow_bool_c (bx_id id,
char *name,
char *description,
- Apply patch.replace-Boolean rev 1.3. Every "Boolean" is now changed to a "bx_bool" which is always defined as Bit32u on all platforms. In Carbon specific code, Boolean is still used because the Carbon header files define it to unsigned char. - this fixes bug [ 623152 ] MacOSX: Triple Exception Booting win95. The bug was that some code in Bochs depends on Boolean to be a 32 bit value. (This should be fixed, but I don't know all the places where it needs to be fixed yet.) Because Carbon defined Boolean as an unsigned char, Bochs just followed along and used the unsigned char definition to avoid compile problems. This exposed the dependency on 32 bit Boolean on MacOS X only and led to major simulation problems, that could only be reproduced and debugged on that platform. - On the mailing list we debated whether to make all Booleans into "bool" or our own type. I chose bx_bool for several reasons. 1. Unlike C++'s bool, we can guarantee that bx_bool is the same size on all platforms, which makes it much less likely to have more platform-specific simulation differences in the future. (I spent hours on a borrowed MacOSX machine chasing bug 618388 before discovering that different sized Booleans were the problem, and I don't want to repeat that.) 2. We still have at least one dependency on 32 bit Booleans which must be fixed some time, but I don't want to risk introducing new bugs into the simulation just before the 2.0 release. Modified Files: bochs.h config.h.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h plugin.cc plugin.h bios/rombios.c cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith64.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer16.cc cpu/ctrl_xfer32.cc cpu/ctrl_xfer64.cc cpu/data_xfer16.cc cpu/data_xfer32.cc cpu/data_xfer64.cc cpu/debugstuff.cc cpu/exception.cc cpu/fetchdecode.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io_pro.cc cpu/lazy_flags.cc cpu/lazy_flags.h cpu/mult16.cc cpu/mult32.cc cpu/mult64.cc cpu/mult8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/segment_ctrl_pro.cc cpu/stack_pro.cc cpu/tasking.cc debug/dbg_main.cc debug/debug.h debug/sim2.cc disasm/dis_decode.cc disasm/disasm.h doc/docbook/Makefile docs-html/cosimulation.html fpu/wmFPUemu_glue.cc gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxmain.cc gui/wxmain.h gui/x.cc instrument/example0/instrument.cc instrument/example0/instrument.h instrument/example1/instrument.cc instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/cdrom.cc iodev/cdrom.h iodev/cdrom_osx.cc iodev/cmos.cc iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_arpback.cc iodev/eth_packetmaker.cc iodev/eth_packetmaker.h iodev/floppy.cc iodev/floppy.h iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/ioapic.cc iodev/ioapic.h iodev/iodebug.cc iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.h iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/serial.cc iodev/serial.h iodev/vga.cc iodev/vga.h memory/memory.h memory/misc_mem.cc
2002-10-25 15:44:41 +04:00
bx_bool *ptr_to_real_val,
Bit8u bitnum)
: bx_param_bool_c (id, name, description, (Bit64s) *ptr_to_real_val)
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
{
val.pbool = ptr_to_real_val;
this->bitnum = bitnum;
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
}
Bit64s
bx_shadow_bool_c::get64 () {
- 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 (handler) {
// the handler can decide what value to return and/or do some side effect
Bit64s ret = (*handler)(this, 0, (Bit64s) *(val.pbool));
return (ret>>bitnum) & 1;
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
} else {
// just return the value
return (*(val.pbool)) & 1;
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
}
}
void
bx_shadow_bool_c::set (Bit64s newval)
- 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
{
// only change the bitnum bit
Bit64s tmp = (newval&1) << bitnum;
*(val.pbool) &= ~tmp;
*(val.pbool) |= tmp;
- 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 (handler) {
// the handler can override the new value and/or perform some side effect
(*handler)(this, 1, newval&1);
- apply a patch I've been working on - modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc ---------------------------------------------------------------------- Patch name: patch.wx-show-cpu2 Author: Bryce Denney Date: Fri Sep 6 12:13:28 EDT 2002 Description: Second try at implementing the "Debug:Show Cpu" and "Debug:Show Keyboard" dialog with values that change as the simulation proceeds. (Nobody gets to see the first try.) This is the first step toward making something resembling a wxWindows debugger. First, variables which are going to be visible in the CI must be registered as parameters. For some variables, it might be acceptable to change them from Bit32u into bx_param_num_c and access them only with set/get methods, but for most variables it would be a horrible pain and wreck performance. To deal with this, I introduced the concept of a shadow parameter. A normal parameter has its value stored inside the struct, but a shadow parameter has only a pointer to the value. Shadow params allow you to treat any variable as if it was a parameter, without having to change its type and access it using get/set methods. Of course, a shadow param's value is controlled by someone else, so it can change at any time. To demonstrate and test the registration of shadow parameters, I added code in cpu/init.cc to register a few CPU registers and code in iodev/keyboard.cc to register a few keyboard state values. Now these parameters are visible in the Debug:Show CPU and Debug:Show Keyboard dialog boxes. The Debug:Show* dialog boxes are created by the ParamDialog class, which already understands how to display each type of parameter, including the new shadow parameters (because they are just a subclass of a normal parameter class). I have added a ParamDialog::Refresh() method, which rereads the value from every parameter that it is displaying and changes the displayed value. At the moment, in the Debug:Show CPU dialog, changing the values has no effect. However this is trivial to add when it's time (just call CommitChanges!). It wouldn't really make sense to change the values unless you have paused the simulation, for example when single stepping with the debugger. The Refresh() method must be called periodically or else the dialog will show the initial values forever. At the moment, Refresh() is called when the simulator sends an async event called BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci (). Details: - implement shadow parameter class for Bit32s, called bx_shadow_num_c. implement shadow parameter class for Boolean, called bx_shadow_bool_c. more to follow (I need one for every type!) - now the simulator thread can request that the config interface refresh its display. For now, the refresh event causes the CI to check every parameter it is watching and change the display value. Later, it may be worth the trouble to keep track of which parameters have actually changed. Code in the simulator thread calls SIM->refresh_ci(), which creates an async event called BX_ASYNC_EVT_REFRESH and sends it to the config interface. When it arrives in the wxWindows gui thread, it calls RefreshDialogs(), which calls the Refresh() method on any dialogs that might need it. - in the debugger, SIM->refresh_ci() is called before every prompt is printed. Otherwise, the refresh would wait until the next SIM->periodic(), which might be thousands of cycles. This way, when you're single stepping, the dialogs update with every step. - To improve performance, the CI has a flag (MyFrame::WantRefresh()) which tells whether it has any need for refresh events. If no dialogs are showing that need refresh events, then no event is sent between threads. - add a few defaults to the param classes that affect the settings of newly created parameters. When declaring a lot of params with similar settings it's more compact to set the default for new params rather than to change each one separately. default_text_format is the printf format string for displaying numbers. default_base is the default base for displaying numbers (0, 16, 2, etc.) - I added to ParamDialog to make it able to display modeless dialog boxes such as "Debug:Show CPU". The new Refresh() method queries all the parameters for their current value and changes the value in the wxWindows control. The ParamDialog class still needs a little work; for example, if it's modal it should have Cancel/Ok buttons, but if it's going to be modeless it should maybe have Apply (commit any changes) and Close.
2002-09-06 20:43:26 +04:00
}
}
bx_param_enum_c::bx_param_enum_c (bx_id id,
char *name,
char *description,
char **choices,
Bit64s initial_val,
Bit64s value_base)
: bx_param_num_c (id, name, description, value_base, BX_MAX_BIT64S, initial_val)
{
set_type (BXT_PARAM_ENUM);
this->choices = choices;
// count number of choices, set max
char **p = choices;
while (*p != NULL) p++;
this->min = value_base;
// now that the max is known, replace the BX_MAX_BIT64S sent to the parent
// class constructor with the real max.
this->max = value_base + (p - choices - 1);
set (initial_val);
}
Add plugin support to Bochs by merging all the changes from the BRANCH_PLUGINS branch! Authors: Bryce Denney Christophe Bothamy Kevin Lawton (we grabbed a lot of plugin code from plex86) Testing help from: Volker Ruppert Don Becker (Psyon) Jeremy Parsons (Br'fin) The change log is too long to paste in here. To read the change log, do cvs log patches/patch.final-from-BRANCH_PLUGINS.gz All the changes and a detailed description are contained in a patch called patch.final-from-BRANCH_PLUGINS.gz. To look at the complete patch, do cvs upd -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz Then you will have a local copy of the patch, which you can gunzip and play with however you want. Modified Files: .bochsrc Makefile.in aclocal.m4 bochs.h config.h.in configure configure.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h state_file.h bios/Makefile.in bios/rombios.c cpu/Makefile.in cpu/access.cc cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer32.cc cpu/exception.cc cpu/fetchdecode.cc cpu/fetchdecode64.cc cpu/flag_ctrl.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io.cc cpu/logical16.cc cpu/logical32.cc cpu/logical8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/protect_ctrl.cc cpu/segment_ctrl_pro.cc cpu/shift16.cc cpu/shift32.cc cpu/stack64.cc cpu/string.cc cpu/tasking.cc debug/Makefile.in debug/dbg_main.cc disasm/Makefile.in doc/docbook/user/user.dbk dynamic/Makefile.in fpu/Makefile.in gui/Makefile.in gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/control.cc gui/control.h gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/sdlkeys.h gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h gui/x.cc gui/keymaps/sdl-pc-de.map gui/keymaps/sdl-pc-us.map gui/keymaps/x11-pc-de.map instrument/example0/instrument.h instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/Makefile.in iodev/biosdev.cc iodev/biosdev.h iodev/cdrom.cc iodev/cmos.cc iodev/cmos.h iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_fbsd.cc iodev/eth_linux.cc iodev/eth_null.cc iodev/eth_tap.cc iodev/floppy.cc iodev/floppy.h iodev/guest2host.cc iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/iodebug.cc iodev/iodebug.h iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.cc iodev/ne2k.h iodev/parallel.cc iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pci2isa.cc iodev/pci2isa.h iodev/pic.cc iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/scancodes.cc iodev/scancodes.h iodev/serial.cc iodev/serial.h iodev/slowdown_timer.cc iodev/slowdown_timer.h iodev/unmapped.cc iodev/unmapped.h iodev/vga.cc iodev/vga.h memory/Makefile.in memory/memory.cc memory/memory.h memory/misc_mem.cc misc/bximage.c misc/niclist.c Added Files: README-plugins extplugin.h ltdl.c ltdl.h ltdlconf.h.in ltmain.sh plugin.cc plugin.h
2002-10-25 01:07:56 +04:00
int
bx_param_enum_c::find_by_name (const char *string)
{
char **p;
for (p=&choices[0]; *p; p++) {
if (!strcmp (string, *p))
return p-choices;
}
return -1;
}
bool
bx_param_enum_c::set_by_name (const char *string)
{
int n = find_by_name (string);
if (n<0) return false;
set (n);
return true;
}
bx_param_string_c::bx_param_string_c (bx_id id,
char *name,
char *description,
char *initial_val,
int maxsize)
: bx_param_c (id, name, description)
{
set_type (BXT_PARAM_STRING);
if (maxsize < 0)
maxsize = strlen(initial_val) + 1;
this->val = new char[maxsize];
this->initial_val = new char[maxsize];
this->handler = NULL;
this->enable_handler = NULL;
this->maxsize = maxsize;
strncpy (this->val, initial_val, maxsize);
strncpy (this->initial_val, initial_val, maxsize);
this->options = new bx_param_num_c (BXP_NULL,
"stringoptions", NULL, 0, BX_MAX_BIT64S, 0);
set (initial_val);
}
bx_param_filename_c::bx_param_filename_c (bx_id id,
char *name,
char *description,
char *initial_val,
int maxsize)
: bx_param_string_c (id, name, description, initial_val, maxsize)
{
- fixed up ParamDialog to correctly handle "trees" of parameters. A bx_list_c can now be displayed as either a wxStaticBox with the child parameters inside, or as a wxNotebook with each child parameter in a separate tab. (The children can also be lists of course.) The default display is the wxStaticBox type, but if you set the option bit bx_list_c::USE_TAB_WINDOW in the list, ParamDialog will use the wxNotebook display instead. - to get the param trees working, I created a new struct AddParamContext, which is passed to AddParam(). This struct is critical when AddParam calls itself recursively to display lists within lists. - use the wxNotebook display feature for the ATA0,1,2,3 controller dialog box. Now instead of being hundreds of pixels tall, it is reasonable height with three different tabs. This fixed bug #619074: "wx: ATA interface editor too tall" and was the whole reason I started messing with this at all. plus some minor cleanups - when I added the enum constant bx_list_c::USE_TAB_WINDOW, I also removed the BX_ prefix from all the other enum constants that are used in parameter options in siminterface.cc. Since these constants are enums within a class, there is no possibility of namespace conflicts so the prefix is not needed. - added wxADJUST_MINSIZE to all wxChoice controls, since that tells wxWindows to adjust its size to the length of the longest string. - instead of calling SetSize or SetSizeHints on every textcontrol with a hardcoded width, I am using just two wxSize specifications for everything: either normalTextSize or longTextSize. - edit names of a few menus and params. For example now instead of the tab saying "Master ATA device on channel 0" it will say "First HD/CD on channel 0". Modified Files: main.cc gui/control.cc gui/gui.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
2002-10-06 06:37:28 +04:00
get_options()->set (IS_FILENAME);
}
bx_param_string_c::~bx_param_string_c ()
{
if ( this->val != NULL )
{
delete [] this->val;
this->val = NULL;
}
if ( this->initial_val != NULL )
{
delete [] this->initial_val;
this->initial_val = NULL;
}
if ( this->options != NULL )
{
delete [] this->options;
this->options = NULL;
}
}
void
bx_param_string_c::reset () {
strncpy (this->val, this->initial_val, maxsize);
}
void
bx_param_string_c::set_handler (param_string_event_handler handler)
{
this->handler = handler;
// now that there's a handler, call set once to run the handler immediately
//set (getptr ());
}
void
bx_param_string_c::set_enable_handler (param_enable_handler handler)
{
this->enable_handler = handler;
}
void
bx_param_string_c::set_enabled (int en)
{
// The enable handler may wish to allow/disallow the action
if (enable_handler) {
en = (*enable_handler) (this, en);
}
bx_param_c::set_enabled (en);
}
Bit32s
bx_param_string_c::get (char *buf, int len)
{
- fixed up ParamDialog to correctly handle "trees" of parameters. A bx_list_c can now be displayed as either a wxStaticBox with the child parameters inside, or as a wxNotebook with each child parameter in a separate tab. (The children can also be lists of course.) The default display is the wxStaticBox type, but if you set the option bit bx_list_c::USE_TAB_WINDOW in the list, ParamDialog will use the wxNotebook display instead. - to get the param trees working, I created a new struct AddParamContext, which is passed to AddParam(). This struct is critical when AddParam calls itself recursively to display lists within lists. - use the wxNotebook display feature for the ATA0,1,2,3 controller dialog box. Now instead of being hundreds of pixels tall, it is reasonable height with three different tabs. This fixed bug #619074: "wx: ATA interface editor too tall" and was the whole reason I started messing with this at all. plus some minor cleanups - when I added the enum constant bx_list_c::USE_TAB_WINDOW, I also removed the BX_ prefix from all the other enum constants that are used in parameter options in siminterface.cc. Since these constants are enums within a class, there is no possibility of namespace conflicts so the prefix is not needed. - added wxADJUST_MINSIZE to all wxChoice controls, since that tells wxWindows to adjust its size to the length of the longest string. - instead of calling SetSize or SetSizeHints on every textcontrol with a hardcoded width, I am using just two wxSize specifications for everything: either normalTextSize or longTextSize. - edit names of a few menus and params. For example now instead of the tab saying "Master ATA device on channel 0" it will say "First HD/CD on channel 0". Modified Files: main.cc gui/control.cc gui/gui.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
2002-10-06 06:37:28 +04:00
if (options->get () & RAW_BYTES)
memcpy (buf, val, len);
else
strncpy (buf, val, len);
if (handler) {
// the handler can choose to replace the value in val/len. Also its
// return value is passed back as the return value of get.
(*handler)(this, 0, buf, len);
}
return 0;
}
void
bx_param_string_c::set (char *buf)
{
- fixed up ParamDialog to correctly handle "trees" of parameters. A bx_list_c can now be displayed as either a wxStaticBox with the child parameters inside, or as a wxNotebook with each child parameter in a separate tab. (The children can also be lists of course.) The default display is the wxStaticBox type, but if you set the option bit bx_list_c::USE_TAB_WINDOW in the list, ParamDialog will use the wxNotebook display instead. - to get the param trees working, I created a new struct AddParamContext, which is passed to AddParam(). This struct is critical when AddParam calls itself recursively to display lists within lists. - use the wxNotebook display feature for the ATA0,1,2,3 controller dialog box. Now instead of being hundreds of pixels tall, it is reasonable height with three different tabs. This fixed bug #619074: "wx: ATA interface editor too tall" and was the whole reason I started messing with this at all. plus some minor cleanups - when I added the enum constant bx_list_c::USE_TAB_WINDOW, I also removed the BX_ prefix from all the other enum constants that are used in parameter options in siminterface.cc. Since these constants are enums within a class, there is no possibility of namespace conflicts so the prefix is not needed. - added wxADJUST_MINSIZE to all wxChoice controls, since that tells wxWindows to adjust its size to the length of the longest string. - instead of calling SetSize or SetSizeHints on every textcontrol with a hardcoded width, I am using just two wxSize specifications for everything: either normalTextSize or longTextSize. - edit names of a few menus and params. For example now instead of the tab saying "Master ATA device on channel 0" it will say "First HD/CD on channel 0". Modified Files: main.cc gui/control.cc gui/gui.cc gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc
2002-10-06 06:37:28 +04:00
if (options->get () & RAW_BYTES)
memcpy (val, buf, maxsize);
else
strncpy (val, buf, maxsize);
if (handler) {
// the handler can return a different char* to be copied into the value
buf = (*handler)(this, 1, buf, -1);
}
}
bx_bool
bx_param_string_c::equals (const char *buf)
{
if (options->get () & RAW_BYTES)
return (memcmp (val, buf, maxsize) == 0);
else
return (strncmp (val, buf, maxsize) == 0);
}
bx_list_c::bx_list_c (bx_id id, int maxsize)
: bx_param_c (id, "list", "")
{
set_type (BXT_LIST);
this->size = 0;
this->maxsize = maxsize;
this->list = new bx_param_c* [maxsize];
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
bx_list_c::bx_list_c (bx_id id, char *name, char *description, int maxsize)
: bx_param_c (id, name, description)
{
set_type (BXT_LIST);
this->size = 0;
this->maxsize = maxsize;
this->list = new bx_param_c* [maxsize];
init ();
}
bx_list_c::bx_list_c (bx_id id, char *name, char *description, bx_param_c **init_list)
: bx_param_c (id, name, description)
{
set_type (BXT_LIST);
this->size = 0;
while (init_list[this->size] != NULL)
this->size++;
this->maxsize = this->size;
this->list = new bx_param_c* [maxsize];
for (int i=0; i<this->size; i++)
this->list[i] = init_list[i];
init ();
}
bx_list_c::~bx_list_c()
{
if (this->list)
{
delete [] this->list;
this->list = NULL;
}
if ( this->title != NULL)
{
delete this->title;
this->title = NULL;
}
if (this->options != NULL)
{
delete this->options;
this->options = NULL;
}
if ( this->choice != NULL )
{
delete this->choice;
this->choice = NULL;
}
}
void
bx_list_c::init ()
{
// the title defaults to the name
this->title = new bx_param_string_c (BXP_NULL,
"title of list",
"",
get_name (), 80);
this->options = new bx_param_num_c (BXP_NULL,
"list_option", "", 0, BX_MAX_BIT64S,
0);
this->choice = new bx_param_num_c (BXP_NULL,
"list_choice", "", 0, BX_MAX_BIT64S,
1);
this->parent = NULL;
}
bx_list_c *
bx_list_c::clone ()
{
bx_list_c *newlist = new bx_list_c (BXP_NULL, name, description, maxsize);
for (int i=0; i<get_size (); i++)
newlist->add (get(i));
newlist->set_options (get_options ());
newlist->set_parent (get_parent ());
return newlist;
}
void
bx_list_c::add (bx_param_c *param)
{
if (this->size >= this->maxsize)
BX_PANIC (("add param %u to bx_list_c id=%u: list capacity exceeded", param->get_id (), get_id ()));
list[size] = param;
size++;
}
bx_param_c *
bx_list_c::get (int index)
{
BX_ASSERT (index >= 0 && index < size);
return list[index];
}