Ok, This one gives a descriptin of the adapters now also. Like this:
Description
\Device\Packet_BLAH
and you would put \Device\Packet_BLAH in .bochsrc
It only works with Visual C++ in debug mode for some reason... Ill get it
figured out I guess.
It did an exception, and then the real code seemed to be commented out
with an #if 0...#endif. I put a panic there, asking people to please
report how they arrived at that condition, and enabled the #if 0 code.
This was pointed out by luca abeni <l_abeni@hotmail.com>.
for debug configuration or obj-release for release configuration.
- instead of gui,iodev,cpu,etc. having their own obj-debug directory, it
all goes into a single output directory for the whole project. I did
this when I was having trouble getting any debug information from the
static library directories to be recognized in the VC++ debugger. Maybe
it's not necessary.
- changed the compile arguments for the debug config so that debug symbols
are created. We used to have:
debug config: /G6 /MT /W4 /GX /O2
Now it says this:
debug config: /MTd /W3 /GX /Z7 /Od
I guess I haven't tested the release config yet, but the debug config is
working great now. I even have symbolic debugging of functions in the
gui/iodev/cpu libraries.
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.
device and disk file for a while. Even though its version of
read_toc is minimal, in fact I would say broken, it lets people use
an ISO disk file as a cdrom.
- in this revision, I wrote the "unix equivalent" of the win32 code, including
the broken version of read_toc. Now win32 and unix should act very similar
when they encounter an ISO disk image.
- one important improvement is in read_toc, I have added "*length=1" for both
win32 and unix, since otherwise the function returns random junk for the
length of the TOC. I also tried "*length=0" and that created the "lost
interrupt" behavior that psyon has been trying to get rid of...I changed it
back to *length=1 of course and left a note to him in that bug report.
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.
of just panicing. In particular, if the logical sector is out of bounds
or the disk image cannot be read/written at the desired offset, we now
abort the ATA command and return an error code. Many of the old BX_PANIC
messages are turned to BX_ERROR, so they will still appear in the
log, but now the device model will try to communicate this fact to
the OS instead of simply giving up.
that TICK is called so I put a trace call just before each TICK.
This seems best, since the trace has a chance to print before the tick
can trigger time-based events elsewhere in the system.
> Attached is a patch to get Bochs 1.2.1 compiling with the Sun Workshop 6
> compiler suite...
>
> Plain - out the box - the build fails with:
> -- snip --
> "pic.cc", line 503: Error: Badly formed constant expression.
> "pic.cc", line 533: Error: Badly formed constant expression.
> -- snip --
> It looks that the preprocessor expects an integer in these cases and not
> a string...
>
>
> Additionally I added some fixes to get rid of the Zillion compiler
> warnings like "Warning: String literal converted to char* in
to run the conf script in order to even have a Makefile. Instead, I just
added some instructions that tell you to run the .conf.win32-vcpp script
yourself and then do "make win32_snap" to unzip the workspace files and
zip up the whole source package.
bug #429448. What is strange about this problem (on OpenBSD) is that the
compile and link goes fine, but when you execute your first readline library
function it does a dynamic link and crashes on the spot. Many autoconf
tests only compile and sometimes link the test program, but this test
compiles, links, and runs it.
[ #433759 ] virtual address checks can overflow
> Bochs has been crashing in some cases when you try to access data which
> overlaps the segment limit, when the segment limit is near the 32-bit
> boundary. The example that came up a few times is reading/writing 4 bytes
> starting at 0xffffffff when the segment limit was 0xffffffff. The
> condition used to compare offset+length-1 with the limit, but
> offset+length-1 was overflowing so the comparison went wrong. This patch
> changes the condition so that it supports all segment limits except for
> sizes 0,1,2,3 bytes. Dave and I figured that these sizes would not be
> needed, while size 0xffffffff is used quite a lot.
I still need to do add some commands from older specs that are obsolete
(and not listed) in ATAPI-6.
- commands that aren't in the spec will still panic.
- fill in names from spec on various commands
- add command aborted for 0x08 device reset on disks (it's only for ATAPI)
- add command aborted for 0xe1 idle immediate
media status to 0 then 1 (equivalent to removing then inserting a disk).
Then it calls the UI function bx_gui.update_floppy_status_buttons()
if the interface has been initialized already.
has run. This ensures that the prev_eip and prev_esp that is used
for tracing and breakpoint checks is correct even in the cycle after
an interrupt or trap.
in performance, but I did not check the debugger carefully enough while
testing them. Part of the performance gain in main.cc revision 1.33 and
cpu.cc revision 1.9 was to allow bochs to stay in the cpu loop forever
in a single processor simulation. (In a multiprocessor simulation it must
quit the loop periodically to give the other procs a chance to simulate
too. Cooperative multiprocessing?) In the process, I restored calls
to BX_TICK in the cpu loop for 1-proc simulation only, and removed them
from the outer loop. (See main.cc, since it was done right.) However
I never made the equivalent change in the debugger code, so in the
debugger, there were ticks coming from the cpu loop and then an
equivalent number of ticks coming from the debugger code just outside
the cpu loop. The result was, of course, that simulation time went
at 2x the correct rate. This simulation time speedup was made even
worse because the continue loop in the debugger would increment ticks
by one quantum (5 at the time) no matter how many instructions had
actually been executed. So in trace mode in particular, the way it was
implemented before today, cpu loop would run only one instruction at
a time and the simulation time would get incremented 1+5=6 times! One
tick from the cpu loop, then 5 erroneous ticks from the continue loop.
Anyway, much of this nonsense should be fixed now. For uniprocessor
simulations, only the cpu loop does ticks (for best performance). For
multiprocessor simulations, the cpu loop exits after one quantum and
the code that calls the cpu loop gets to increment ticks instead.
> This patch fixes a number of debugger problems.
> - with trace-on, simulation time would pass 5x faster than usual, so
> interrupts and other timed events would happen at different times
> - with trace-on, breakpoints were ignored
> - with trace-on, control-C would not stop the processor and return to the
> debugger.
>
> This patch changes the execution quantum for the debugger to 1, which means
> that cpu_loop is asked to do one instruction at a time. This may cause
> bochs with the debugger to be slower than before.
>
> I haven't tested without the debugger yet, so I don't know if the timing
> of events matches or not.
line, like this:
<HTML
><HEAD
><TITLE
>FreeBSD</TITLE
>
Glimpse, which is indexing our website, finds this very confusing and
it cannot pick out the title from this mess. This script takes a list
of HTML files on the command line and attempts to make the <TITLE> tag
look more normal so that glimpse can understand it.
WARNING: This is a hack. It's made to work on docbook generated html, but
may do strange things on anything else.
instructions, configure options
- added a transcript of a successful compile, since that gives all the
commands and shows people where their compile went wrong.
This is a patch from Volker Ruppert <Volker.Ruppert@t-online.de>, who
comments: "The fdisk command reports an unusable second harddisk if the cdrom
is enabled. This patch helps, but I don't know if it is the right way."
> I have inspected the header of output file and several sample MIDI files. I
> have found two different bytes in the header. After I have changed this
> bytes Winamp could play the output file, but it showed a track time of
> 0:00. The Windows Media Player still doesn't like the file.
in an output format similar to gdb (when you do info all-registers).
Also, if you do "info all" you get the CPU registers and the FPU
registers.
- added bx_cpu_c method called fpu_print_regs, which is implemented
in wmFPUemu_glue.cc
posted to bochs-developers on Wed, 29 Aug 2001 00:08:45 +0100
David Haslam wrote:
> I have been looking at the keyboard problem with Minix, which for
> those that haven't tried Minix results in every key press giving the
> response: ^@
>
> I am aware of the comments in the changelog that suggest removing 2
> keyboard ACKs in iodev/keyboard.cc, but this is a bit of a hack,
> (which is presumably why it was never incorporated).
>
> The problem seems to be that the Minix keyboard driver doesn't obey
> the rules, and Bochs doesn't model the 8042 accurately. When issuing
> commands to set the LEDs, Minix polls the 8042 output data register
> waiting for an ACK even though the OBF flag isn't set.
>
> Bochs returns zero under these circumstances, which seems to
> trigger obscure behaviour that messes up the Minix internal
> keyboard queue. I don't fully understand why Minix breaks, but I
> think the fact that the ACK generates an interrupt, and Minix treats
> it as a scan code also has something to do with it.
>
> In any case, I believe, the fix is for Bochs to return the output
> buffer contents, regardless of whether the OBF flag (called outb in
> Bochs) is set.
>
> I expect the real hardware allows the register to be read at anytime,
> and with this fix we are modelling the behaviour of the hardware more
> accurately.
>
> I have tested it with Minix 2.0.0. Also DOS 6.22 still works after this fix.
> Does anyone think this will break anything else?
>
> This diff is against the latest CVS of iodev/keyboard.cc, version 1.29
> The last part of the diff is a minor fix to an unrelated debug print.
