- fixed pcidev targets in iodev/Makefile.in
- updated all Makefile dependencies using a default setup (.conf.linux).
TODO: dependencies should be generated at compile time since they depend on
the config settings
- added emulation of the PS/2 mouse port without a mouse connected (some OS's
still detect a mouse)
- fixes for the mouse type 'serial_wheel' (the wheel still doesn't work in Win98)
#1079240 by Ben Lunt. There are still some problems:
- PS/2 mouse is always present (some code to emulate a disconnected mouse needed)
- PS/2 wheel mouse doesn't work properly
- serial wheel mouse detected as a standard mouse and doesn't work at all
bochs.h already not include iodev.h which reduces compilation dependences for almost all cpu and fpu files, now cpu files will not be recompiled if iodev includes was changed
- it works only on x86 with gcc2.95+
- uses the GCC function atribute "regparm(n)" to declare that certain
functions use the register calling convention
- performance improvement is about 6%
"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
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
specific to X windows. I changed a few names of variables and methods to
sound less X windows specific, for example in the BXKeyEntry struct
the "xwinKey" field is now called "hostKey".
- remove the hacks in bx_keymap_c::loadKeymap that checked that every
keysym started with "XK_". Now I can still make that check, but it
is done in x.cc's convertStringToXKeysym() instead.
- in sdl.cc, load the keymap in specific_init function. I had to
create a conversion function from SDL key names to SDLkey values.
I created a table of key names and associated values, and I just
do a strcmp on each name. It's not a fast algorithm obviously but this
conversion only has to be done for maybe 200 keys at startup time.
- added a key map file for SDL called sdl-pc-us.map. Since this has
basically all the SDLK_* symbols defined, it is a good starting point
if you need to make any other keymaps.
- modified: gui/keymap.cc gui/keymap.h gui/sdl.cc gui/x.cc iodev/keyboard.cc
- added: gui/sdlkeys.h gui/keymaps/sdl-pc-us.map
- a few weeks ago I changed the gui code so that it always made a copy
of the clipboard data using new Bit8u[] and passed it into the keyboard
code. But I didn't get the keyboard code quite right, and Christophe
noticed the incorrect malloc that I had forgotten to remove. I changed
it to work as I intended:
1. gui code allocates paste buffer (new), copies clipboard data in
2. gui code passes the buffer to the keyboard code, and forgets about it
3. keyboard code uses the buffer, then frees it when finished (delete)
- modified: iodev/keyboard.h iodev/keyboard.cc
and I could never explain it. The problem was that in keyboard.cc it
included "math.h" with quotes instead of <math.h> with less than/greater
than, so gcc -MM didn't realize it was a system header.
