- new functions raise_irq() and lower_irq()
- all trigger_irq() / untrigger_irq() calls are replaced by the new functions
- REMARK: timer IRQ handling is not correct but it works
- TODO: IOAPIC IRQ handling needs to be changed
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.
X servers that I've seen, however on other X servers it makes all
key mappings into absolute junk. We need to continue to work on this
patch to support all X servers and all key maps.
been converted into parameters temporarily have the letter "O" appended
to their name. I don't want to keep it this way, but it has helped
in the conversion process because the compiler refuses to compile the
old uses of the name. Before I started using the "O" trick, there were
many bugs like this: if (bx_options.diskc.present) {...}
This was legal with the new parameters, but it was testing whether the
parameter structure had been created, instead of testing the value of
the present parameter. Renaming present to Opresent turns this into
a compile error, which points out the incorrect use of the param.
- the "--disable-control-panel" no longer works, I'm afraid. I can no
longer support this and continue progress.
To see the commit logs for this use either cvsweb or
cvs update -r BRANCH-io-cleanup and then 'cvs log' the various files.
In general this provides a generic interface for logging.
logfunctions:: is a class that is inherited by some classes, and also
. allocated as a standalone global called 'genlog'. All logging uses
. one of the ::info(), ::error(), ::ldebug(), ::panic() methods of this
. class through 'BX_INFO(), BX_ERROR(), BX_DEBUG(), BX_PANIC()' macros
. respectively.
.
. An example usage:
. BX_INFO(("Hello, World!\n"));
iofunctions:: is a class that is allocated once by default, and assigned
as the iofunction of each logfunctions instance. It is this class that
maintains the file descriptor and other output related code, at this
point using vfprintf(). At some future point, someone may choose to
write a gui 'console' for bochs to which messages would be redirected
simply by assigning a different iofunction class to the various logfunctions
objects.
More cleanup is coming, but this works for now. If you want to see alot
of debugging output, in main.cc, change onoff[LOGLEV_DEBUG]=0 to =1.
Comments, bugs, flames, to me: todd@fries.net