set_text_charbyte()
- vga: store the address of the active charmap in the new variable
charmap_address
- vga: text mode hack removed. The write modes, operations and masks must be
used in text mode too.
- sdl: clear_screen() is not necessary when the charmap has changed
- win32: update only the changed font bitmaps before drawing the text
- All mouse events in the VGA window go to MyPanel::OnMouse. Middle mouse
button and F12 both toggle mouse capture. OnMouse queues an event
for the simulation thread to process. The simulation thread calls
bx_devices.keyboard->mouse_motion() when it sees the event on the queue.
- add IFDBG_VGA around some display debug code. All wx mouse debug code
is controlled by IFDBG_MOUSE.
- modified: gui/wx.cc gui/wxmain.cc gui/wxmain.h
the wxwindows thread, it just sets a boolean flag needRefresh. Meanwhile, a
wxTimer running in wall clock time (as opposed to sim time) triggers a
repaint only if the the boolean is true.
- now MyRefresh is implemented by just setting needRefresh=true.
- make graphics_tile_update call MyRefresh.
- make dimension_update call MyRefresh.
instead of bx_param_bool_c. There are several cases where I need an
enum to enable/disable some fields, and this change should allow
that.
- modified: gui/siminterface.h gui/siminterface.cc
wxWindows without debugger, I needed to add some more cases of
#if BX_DEBUGGER to make it work. It is certainly possible to
handle such problems by always compiling in the debug dialogs but
only instantiating them if debug support is compiled in, but I have
chosen (for now) to put #if BX_DEBUGGER around things like this.
- modified: gui/wxdialog.h gui/wxdialog.cc
wxWindows without debugger, I needed to add some more cases of #if
BX_DEBUGGER to make it work. All the problems I found were things like
referencing a debug structure which was never initialized (NULL). It is
possible to handle such problems by always compiling in the debug dialogs but
only instantiating them if debug support is compiled in, but I have chosen
(for now) to put #if BX_DEBUGGER around things like this.
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
at the appropriate times. For example, you can't stop when you're
stopped. You can't step when it's running.
- modified: gui/wxdialog.cc gui/wxdialog.h
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
length. (The first guinea pig is the 2-bit IOPL field in eflags.)
Also it can have a pointer to a Bit8u, Bit16u, Bit32u and signed
equivalents and do the right thing.
- add lots more CPU fields as parameters: EBP ESI EDI ESP, all segment regs,
LDTR, GDTR, eflags, DR*, TR*, CR*. These are all visible on a
ridiculously tall dialog box that will one day become the debugger.
wxWindows thread. However, when the wxWindows thread calls
Bochs code, for example SIM->some_action() that triggers a
BX_PANIC(), then the Sim2CI event is created in the wxWindows
thread. This used to cause thread deadlock, but now it is
recognized and handled safely.
vga_charmap
- the SDL gui uses the charmap data for the vga text display
* TODO: implement this feature for other guis
- removed unused variables in sdl.cc and gui.cc
- fixed a warning in vga.cc
- 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.
X windows, wxWindows. Each platform has its own way of returning
a variable length string, and its own rules about how you're supposed
to dispose of the string. Now all platforms do the same thing: they
allocate a Bit8u buffer with C++ "new" and copy the clipboard data in,
then release the clipboard data in the platform-specific correct way.
The Bit8u buffer is sent to the keyboard code, which frees it with
delete [] when finished.
- modified: gui/wxmain.cc gui/wxmain.h
X windows, wxWindows. Each platform has its own way of returning
a variable length string, and its own rules about how you're supposed
to dispose of the string. Now all platforms do the same thing: they
allocate a Bit8u buffer with C++ "new" and copy the clipboard data in,
then release the clipboard data in the platform-specific correct way.
The Bit8u buffer is sent to the keyboard code, which frees it with
delete [] when finished.
- modified: gui/wx.cc gui/x.cc gui/win32.cc iodev/keyboard.cc
files that need them. This is more in line with the other gui libraries,
and the compile line is easier to read.
- modified: Makefile.in configure.in configure gui/Makefile.in
delivered to both the GUI and simulator thread, so they both call
bx_signal_handler. This can lead to deadlock as multiple threads enter
BX_PANIC and try to show a dialog box at once. To solve the problem, I made
a function isSimThread() which can be called from anywhere. If the
bx_signal_handler is called from any thread OTHER THAN the simulation thread,
it returns without doing anything. As a result, only one thread is allowed
to enter the signal handler code, and now control-C works correctly.
Bochs to immediately read the bochsrc and start simulating immediately (as
opposed to going into the configuration interface first). Now -q does
the right thing in the wxWindows interface. It behaves as if you selected
Read Configuration and then Simulate:Start.
- modified: main.cc gui/siminterface.cc gui/siminterface.h gui/wxmain.cc
wxHAS_RAW_KEY_CODES is not available in the wxWindows library.
my patch "patch.wx-raw-keycodes" adds wxHAS_RAW_KEY_CODES to the wxWindows
library, and it will also be in wxWindows 2.3.3 and beyond.
correct name for floppy and cdrom devices:on windows, A:, B:, etc;
on Linux /dev/fd0 and /dev/cdrom.
- It's perfectly ok to type device names into the blank on those dialog
boxes, but the label "Disk Image File:" sort of implies that it has to
be a file. To try to avoid confusion change the label to simply
"Disk Image:".
on win32. I believe this is the same problem that scarlip referred to as
"it doesn't start reliably. sometimes it works, sometimes it won't".
See comments in gui/wx.cc (dimension_update) for details.
- since dimension_update is called from the simulator thread, it needs to
get the GUI mutex before calling any wxWindows functions. Now it does.
- add lots of IFDBG_VGA(...) lines which I use to diagnose various problems.
They are compiled away by default (for performance). See definition of
IFDBG_VGA() in gui/wxmain.h.
values. All wxWindows dialogs return wxID_OK or wxID_CANCEL. The
wxOK and wxCANCEL symbols are ONLY used in input arguments that determine
whether to display the ok and cancel buttons. Now I'm doing the same.
Return values are wxID_OK if they pressed the ok button, and wxID_CANCEL
if they pressed cancel.
SetToolBitmapSize() to set the icon size to 16x16; when I changed the icon
size I forgot to change SetToolBitmapSize() and somehow it looked ok on
wxGTK.
- change mouse tooltip to "(Mouse Not Implemented Yet!)" for now
has a 16bit signed value. If you try to set the max above 32767, it
overflows and does stupid things. To combat this tendency, I now use
the SPINCTRL_FIX_MAX(x) macro when setting the max range of a spinctrl.
On platforms that need it, this will saturate the range at 32767.
- implement the Edit Keyboard dialog using ParamDialog instead of the
handcoded thing.
- make Serial/Parallel dialog look a little better
- change order of "other" dialog to get ips and vga_update_interval on top
ParamDialog. When a boolean param changes, I read its dependent_list
field to see which other parameters depend on it. Then, for any
dependents that are actually showing in the dialog, I set their
enable bit accordingly. This required addition of another hash table,
called paramHash. The two EnableChanged() methods implement this.
- remove all ConfigKeyboardDialog code because I can do just as well
using the generic ParamDialog.
- fix bug that caused occasional crashes. To attempt to find all the
choices in an a wxChoice control, I was calling GetClientData() on
increasing index until it returned NULL. The docs implied that this
was safe, but it's not. Eventually I found an apparantly undocumented
call wxChoice::GetCount() that gives the number of strings in the
choice box and it allows me to do the right thing.
to change the enable/disable status of other parameters worked fine for
the text mode interface but poorly for the wxWindows gui. So I
implemented it a different way. Now in every boolean parameter, there is
a field called dependent_list which is a list of parameters which
are enabled/disabled by that boolean. Having this list available
allows both the text mode CI and the wxWindows CI to know which fields
should be enabled and disabled as a result of a boolean changing value.
- when the set() method of a bool param is called, or when the
dependent_list is changed, a private method called update_dependents()
changes the enabled status of all dependent parameters.
- add macros to get parameter ids of serial and parallel port parameters,
using the port number as an input variable.
to change the enable/disable status of other parameters worked fine for
the text mode interface but poorly for the wxWindows gui. So I
implemented it a different way. Now in every boolean parameter, there is
a field called dependent_list which is a list of parameters which
are enabled/disabled by that boolean. Having this list available
allows both the text mode CI and the wxWindows CI to know which fields
should be enabled and disabled as a result of a boolean changing value.
- when the set() method of a bool param is called, or when the
dependent_list is changed, a private method called update_dependents()
changes the enabled status of all dependent parameters.
a method to add the parameters (bx_param_c) that you want to edit,
and display it. It knows how to display and edit boolean, int,
enum, and string, so it can do a reasonable job on any parameter.
The end result is not as nice as a box that you lay out by hand, but
it's decent. The most obvious thing that's missing from
ParamDialog-generated dialogs is that I haven't found a way to
make an "Enable" button that enables/disables a bunch of other
parameters. I'll keep thinking about that.
- using ParamDialog, I made dialogs for Sound, Cmos, Serial/Parallel,
32bitOSloader, and an ugly catch-all category called other.
Now I believe you can edit every single option using wxWindows.
- remove the format string from GetTextCtrlInt() because the strtoul
conversion is better than the sscanf with a format string (it supports
both base 10 and 16 with 0xFF notation).
- modified files: gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h
- also other browse buttons were somewhat broken in that they didn't
set the initial value of the wxFileDialog. Now all text fields
with a browse button use a single function BrowseTextCtrl() to
avoid future problems of this sort.
- if the Ok on the MemoryConfigDialog is rejected because the integers
can't be parsed, now give a more specific error message that points you
to which field has the illegal value.
- print hex numbers with CAPS. With proportional font this is much
easier to read.
- accept either strings with base 10 or 16 numbers in GetTextCtrlInt by
default. If the sscanf fails, accept anything that strtoul can
read. Unfortunately legitimate "-1"'s being returned from strtoul will
be rejected, but at present there is no need for negative numbers in
textfields anywhere.
- modified files: gui/wxdialog.cc gui/wxdialog.h
and also the optional rom settings. I think it all works except that
the Browse buttons aren't hooked up yet.
- modified Files: gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h
die, or ask the user for each type of event. It has a button that
will lead to the "advanced" dialog, which doesn't exist yet.
- in gui/wxdialog.h, sketch a few more dialogs to be done soon
- modified: gui/wxdialog.cc gui/wxdialog.h gui/wxmain.cc gui/wxmain.h
- for all modal dialogs that return a boolean result, return either
wxOK or wxCANCEL instead of 0,-1.
- you can view the NetConfigDialog box if you choose the Edit:Network menu
item, but it's not connected to the actual parameter values yet.
into normal C strings. After asking about it on wx-users, I understand
it better now.
Example of unsafe code:
char *filename = dlg.GetFilename().c_str ();
printf ("file name is %s\n", filename);
The problem is that dlg.GetFilename() returns a temporary wxString
that goes out of scope at the end of that line of code. The "filename"
string is unstable if you write it this way.
Example of safe code:
char filename[1024];
wxString fn (dlg.GetFilename ());
strncpy (filename, fn.c_str (), sizeof(filename));
printf ("file name is %s\n", name);
Now we have a stable copy of the wxString in "fn" which is usable
as long as fn is in scope.
- also now we use wxStrings (almost) all the time in the interface to the
wxdialogs. Any conversion from char* to wxString and back is done in
wxmain.cc now.
- HDConfigDialog now uses an EnableChanged() method to set the enabled bit
on components controlled by the enable checkbox.
- now sets the present bit on hard disks and cdrom
- enforces the rule that you can't have DISKD and CDROMD (just in time for
Christophe to add another interface)
- now the megabytes field is a wxStaticText, which makes it clear that
it cannot be edited.
- add "enter size/compute geometry" button for HD image
- make a few more strings into #defines in wxdialog.h
- disable most of the Edit menu during simulation, reenable it when
simulation stops
choose the filename and capacity of a floppy image. This dialog
can recognize a list of names as physical disk drives, and it has a
Browse button so that you can click on a new image intead of having
to type it. If you press ok, then the Bochs parameters are updated.
- eventually we should make a function that makes a list of the
physical devices that should be mentioned here. For Windows it should
say "Physical drive A:" for "a:", while on Linux it should say
"Physical drive fd0" for "/dev/fd0" or something. Even if bochs
doesn't find the correct physical disk drives, you can still type
whatever file name you want.
gui/wxdialog.h and gui/wxdialog.cc. The first dialog box is
called LogMsgAskDialog. It displays panic messages and asks if you
want to continue, quit, etc.
I use setjmp() to save the context just before calling
bx_continue_after_config_interface(). Then, in
bx_real_sim_c:quit_sim, I use longjmp() to jump back to that context.
This happens in main.cc and in gui/wxmain.cc (wxWindows only).
I haven't tested with the debugger yet. Possibly with debugger
the quit longjmp() should jump back to the debugger prompt loop
instead of actually quitting the program.
- clean up BX_ASYNC_EVT_LOG_MSG implementation by creating a different,
synchronous event called BX_SYNC_EVT_LOG_ASK. The async event
could be used to simply tell the CI that an event has occurred,
for example if the user wanted to view the events on screen
(not implemented). The sync event is used when you want the user
to respond before the simulation can continue, such as a for the
"panic=ask" behavior.
- in wxmain.cc, move the updates to the Start,Stop,Pause,Resume menu
items into a separate method simStatusChanged(). This makes the code that
does important stuff more readable.
- remove wxMutexGuiEnter()/Leave() from MyFrame::OnSim2CuiEvent().
This method is an event handler called in the gui thread, so it
already has the gui lock. This call caused thread lock on my linux
box.
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.
- loading default bochsrc for the wx gui no longer necessary
- the wx gui version of bochs now accepts the same command line arguments as
the other guis
to "*_ENABLED"
- bx_serial_options for all 4 ports moved into an array com[4]
- serial port com1 is enabled by default
- detection of com2, com3 and com4 config options disabled for now
- new parameter "enabled" added to the serial bochsrc options
- error handling for serial and parallel bochsrc options changed. The unhandled
BX_PANICs are replaced by BX_ERRORs.
- new function bx_write_serial_options() added
- serial destructor restores original terminal settings only when serial port
is enabled and the tty_id is valid
parport1 with the new option "enabled". The old option "enable" only
controlled the output. The parport1 is enabled with no output by default.
Changes:
* bochrc option "enable" replaced by "enabled"
* parport option "Oenable" replaced by "Opresent"
* bx_parport_options par1 and par2 replaced by an array par[2]
* initialize parport1 resources only when enabled
* renamed variable "parport_init_list" to "par_ser_init_list" since it
contains parport and serial options
* documentation and bochsrc updates
- the parport variables "output" and "initmode" now belong to the bx_par_t
structure
- TODO: add parport2 (disabled by default), parport detection in the bios
(from plex86 curses.cc)
- set the log action for the log level "panic" to "fatal", because the "ask"
menu causes trouble in the terminal
- logfile output to stderr not allowed
- handle_events(): type of variable 'character' must be 'int'
- two terminal chars added in function get_term_char()
- bit 7 of the vga attribute enables the A_REVERSE flag of the terminal char
(from plex86 curses.cc)
- variable term_attr no longer necessary in function text_update()
- function keys are working now
- clear_screen() function works now
- a few special vga characters converted to terminal characters
- exit() now clears the screen and calls endwin()
- "[TERM]" removed from info/error messages
- debug messages changed to BX_DEBUG
bitmaps. The bochs window now consists of 3 windows: the main window and
it's child windows simulation window and toolbar window.
Changes:
- new windows "mainWnd" and "simWnd" replace the old "hwnd"
- moved the functions of the old window procedure to the new ones
- toolbar functions added in create_bitmap(), headerbar_bitmap() and
replace_bitmap()
- function show_headerbar() no longer needed (must be present for
compatibility)
- a few variables for the headerbar changed or removed
- bitmap and headerbar variables now initialized in specific_init()
the guest OS. The shortcut can be defined in the bochsrc or in the config
interface. It is possible to change it at runtime.
These shortcuts are currently recognized:
ctrlaltdel, ctrlaltesc, ctrlaltf1, alttab
Here is the list of changes:
* userbutton.h and userbutton.xpm added in gui/bitmaps
* config options for the userbutton shortcut added
* initialize the new button in the gui.cc
* the new userbutton handler generates keypresses and relaeses depending on
the shortcut keyword
* the gui stops adding buttons to the headerbar if not enough space is left.
This can happen when the screen width is 320 pixels (done for X11 only).
* TODO: build a dialog box for the wxWindows gui
more work in the floppy and bios code.
- floppy and cdrom entries in the runtime config menu can be disabled if the
drive wasn't defined in bochsrc or start menu
- floppy variable "initial_status" and cdrom variable "inserted" renamed to
"status"
- unused variable *ips in function build_runtime_options_prompt() disabled
* new floppy type 360k can be used in .bochsrc and the config interface
* media type and geometry can be set for the floppy type
* BIOS changes to make 360k floppy drives work
* bximage can create 360k images now
to describe the format of the log prefix. This option can be any string
with special tokens being replaced at run time :
# %t : 11 decimal digits timer tick
# %i : 8 hexadecimal digits of cpu0 current eip
# %e : 1 character event type ('i'nfo, 'd'ebug, 'p'anic, 'e'rror)
# %d : 5 characters string of the device, between brackets
the default is "%t%i%d", so the logprefix is the same as before.
New tokens can be easily added or changed if needed.
Modified Files:
.bochsrc bochs.h logio.cc main.cc gui/control.cc
gui/siminterface.h gui/siminterface.cc
patches/patch.logfilefmteip
* dimension_update() stores the global variables columns, rows and
font_height_orig; it uses X font sizes to recalculate the screen size
* text_update() uses the columns, rows and X font sizes when redrawing the
screen; it adjusts the cursor shape using the font sizes
- The emulated vga card issues a dimension_update() using the real
screen dimensions and the real font height.
- The gui selects a font with the requested height or it recalculates
the screen height if the font height is not available.
- The text_update() function uses a new variable 'ncols' instead of the
fixed value of 80 for the number of text columns.
I have tested the changes with X11/Linux, SDL, wxGTK and win32. The changes
in the other guis are not tested yet.
all of the window especially after a resize". This causes screen corruption
on my win98 box whenever Bochs changes resolution, so I removed it from cvs
and checked it in as patches/patch.win32-resize instead.
- added toggle_mouse_enable() call to the handling of the middle mouse button
- removed break statement between SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP
- added prefix "SDL" in specific init
GUI specific paste functions for X11 and WIN32 in paste_handler() moved to
the new function
- get_clipboard_text() prepared for other GUIs
- set_clipboard_text() has now a return value (0 = failed or not implemented)
- use portable code in copy_handler() if set_clipboard_text() fails
- snapshot_handler() prepared for adding a file dialog call
- writing snapshot file in binary mode (LF->CRLF conversion already done)
GUI specific copy functions for X11 and WIN32 in copy_handler() moved to
the new function
- set_clipboard_text() prepared for other GUIs
- value of text mode cursor variables fixed (and renamed in x.cc)
- BX_ERROR message in snapshot_handler() fixed
- paste: grabbing the data from the clipboard in win32 was not implemented
at all. I found some example code on usenet and adapted it for Bochs.
- keymap: now if you call loadKeymap with NULL for the function pointer,
it just fills in all the X windows keysyms with zero. Added a call
to loadKeymap in win32.cc.
copy to the clipboard so I removed them.
- I was having cygwin compile problems because <windows.h> was not always
included when compiling this file. Add an include of <windows.h> at
the top, and now it compiles in cygwin.
Here are the patches (without the serial name fix). Let me know if you want
me to change that. Oh, FYI, my changes also open up the com1 terminal in raw
mode, which makes the emulation much more accurate. You'll also notice that
I added infrastructure for com2->4 in the option parsing. I didn't add it to
the serial code, as I think a bunch of things need to be untangled before
that can work.
Added control for 80x50 fonts
Added mouse input
Added mouse grabbing
Added automatic mouse grabbing when entering full screen
Added autoremoval of header when going fullscreen
Simplified a couple of graphic routines
interface menus. Parallel port #1 is implemented, and I left stubs for
parallel port #2 in case we want to ever add it. If the parallel port
is enabled, the init method of parallel.cc does an fopen() on the output
file. If disabled, or if the fopen fails, the file handler remains
NULL and no characters are printed. There is no attempt to enable/disable
the operation of the parallel port, only the output to a file.
removed! I used this trick sometimes to check that a function returned
what I expected, like assert (func () == 0), but this caused the
func() to never get called. Oops.
will dump core, and the core can sometimes be loaded into the debugger
to give some hints as to what is going on. This could be especially
useful when the bochs debugger is off.
- try to do something reasonable when abort() doesn't exist on the system.
which were generated with gcc -MM to the end of each Makefile.in
so that make understands which files depend on which. Basically,
everything depends on bochs.h, which depends on everything, which
is not ideal.
- rework the order of initialization with and without the control panel.
The thing that was bothering me most was the command line options were
being processed after the user had set everything in the control panel.
This is clearly not what's expected--the command line options should
affect the startup defaults of the control panel, but whatever the user
chooses in the cpanel menus is the final choice.
- if the control panel (config interface) is not wanted, the user can
put "-nocp" or "-nocontrolpanel" as the FIRST argument on the command
line. Also, the "-psn" option which is automatically passed in by
MacOS X when you doubleclick the application causes the control panel
to be disabled. In this case, the order of operations is:
1. read bochsrc
2. parse command line options.
- if the control panel is enabled (default), the command line options are
parsed to provide the startup defaults for the control panel, but the
control panel settings are the final answer. So the order is:
1. parse command line options
2. run control panel (if user chooses, he can read bochsrc from menus)
- I haven't tested command line options with the debugger yet.
