to be signed instead of unsigned, it was looking up color values
like wxBochsPalette[-126] instead of wxBochsPalette[130]. This affected
any colors in the palette between 128 and 255. I simply hanged newBits
to signed, and it fixed bug #618462: wx: 256 color modes not working properly
- I am still not satisfied with the way that wxWindows maps colors on an
8-bit display, but that is a different issue.
after the palette changes. This makes the iodev/vga.cc code do the
right thing. This also fixes the toolstar splash screen, but at a
fraction of the cost of the solution in rev 1.37.
need to be updated. This was impossible before, because we only stored the
RGB values in wxScreen. I added a new array called wxPixel that stores the
8-bit color index that should be displayed. Now if the VGA palette changes,
I use wxPixel data to reconstruct wxScreen using the new palette.
- this fixes the display of the splash screen of the Toolstar disk, since
it relied on drawing the picture and then fading the colormap from back
up to the normal values. I was hoping it would fix the splash screen of
win95 too, but it does not.
exit out of cpu_loop() and back to the caller can be honored.
Previously, code in this function was a part of cpu_loop so
a "return;" would already do that. Now, a value is passed
back to cpu_loop() to denote such a request, and then a return
is executed from cpu_loop().
I haven't tested this yet, but previously I must have broke
certain debugging requests by moving the code to a separate
function and not fixing the "return;" statements.
Symptom: Linux kernel 2.4.19 would hang in random places. CPU still
running, but in dle loop.
Cause: if APIC interrupt occurred while a PIC interrupt was pending, the
PIC interrupt would be lost. This is because either an APIC or PIC
interrupt would trash any pending interrupt event because INTR is only a state,
not an event queue.
Temporary fix: reworked apic.cc to have it's own copy of INTR state. cpu.cc now
checks for both cpu.INTR and local_apic.INTR.
Need to do further research to see if local_apic and pic can be integrated in such
a way as properly manage the combined effects of both devices accessing INTR state.
value and a change-mask, rather than passing all the boolean
change flags as arguments.
Recoded the POPF instruction in flag_ctrl.cc to use the
new writeEFlags() function, and to make it more sane.
Also, the old write_flags() and write_eflags() functions
redirect to writeEFlags() for now. Later, when we get
back in a development mode, it would be better to make
all calls use the new function and get rid of the old ones.
been using the Boolean type for a number of multi-bit fields on the
assumption that it is actually many bits wide. However, this assumption is
unsafe and has caused some bugs that are hard to track down.
- in the Carbon library on MacOS X, Boolean is defined to be an unsigned char.
This has been causing some of the EFLAGS accessors to fail (bits 8-31)
because they depended on Boolean being 32 bits wide. I changed these
accessors to return Bit32u instead. I believe that this will finally fix
[ 618388 ] Unable to boot under MacOS X.
- It would be possible to create a bochs specific type for booleans (bx_bool),
but it's cleaner to simply use "Boolean" when we actually mean a 1-bit true
or false field, and Bit8u/Bit32u when it is a multibit field.
32-bits rather than 64. This is possible, because there is
always an active null (heartbeat) timer, with periodicity
of less than or equal to the maximum 32-bit int value.
This generates a little less code in the hot part of cpu_loop,
and saved about 3% execution time on a Win95 boot.
Moved the asynchronous handling code from cpu_loop() to its
own function since it's a long path. This neatened up the
code a little (less gotos and all), and made it more clear
to use a "while (1)" around the iterative code in cpu_loop().
which adds a help command to the debugger
- modified: debug/dbg_main.cc debug/debug.h debug/lexer.c debug/lexer.l
debug/parser.c debug/parser.h debug/parser.y docs-html/debugger.html
- removed the patch file now that the changes are committed
[ 618071 ] Cleaned up MacOSX Application Icon
His comments:
> The original icon was actually in a .bin (MacBinary)
> format but lacked that extension. So wouldn't work in
> practice.
>
> I've cleaned up the icon by adding transparent areas.
> (So it doesn't show up as a white square with the image
> in it) as well.
so that windows types can be used in fields, for example in cdrom.h:
#ifdef WIN32
HANDLE cdrom_interface::hFile;
#endif
- since every file includes bochs.h, I removed includes of <windows.h>
everywhere else
- modified: bochs.h cpu/extdb.cc gui/win32.cc gui/wx.cc iodev/cdrom.cc
iodev/eth_win32.cc iodev/floppy.cc
coverage of the high-frequency eflags instructions. That should
complete the asm() eflags updates for now, as we should be stabilizing
moving towards bochs 2.0.
integrate it, if it looks good. Putting here for the CVS trail.
"This patch adds extra inline asm statements for the most important
instructions I found to be still resorting to lazy flags execution.
I counted the instructions that "hit" and "missed" when an eflag
value was needed - if there was a miss, the flag was not known and
had to be calculated with lazy_flags.cc. The culprit instruction
which last executed to affect the eflags was tallied."
These seem to be working better, are a more simple design,
easier to understand, and AFAIK don't have race conditions
in them like the old ones do.
Re-coded the apic timer, to return cycle accurate values
which vary with each iteration of a read from a guest OS.
The previous implementation had very poor resolution. It
also didn't check the mask bit to see if an apic timer
interrupt should occur on countdown to 0. The apic timer
now calls its own bochs timer, rather than tag on the
one in iodev/devices.cc.
I needed to use one new function which is an inline in
pc_sytem.h. That would have to be added to the old pc_system.h if
we have to back-out to it.
Linux/x86-64 now boots until it hits two undefined opcodes:
FXRSTOR (0f ae). This restores FPU, MMX, XMM and MXCSR registers
from a 512-byte region of memory. We don't implement this yet.
MOVNTDQ (66 0f e7). This is a move involving an XMM register.
The 0x66 prefix is used so it's a double quadword, rather than
MOVNTQ (0f e7) which operates on a single quadword.
The Linux kernel panic is on the MOVNTQD opcodes. Perhaps that's
because that opcode is used in exception handling of the 1st?
Looks like we need to implement some new instructions.
version uses the cdrom drives in the system's order. Drive letters are not
used by ASPI.
- wrong BX_INFO message for ASPI disabled. The version number is never checked.
