El 11/03/2010, a las 07:42, Roy Tam escribió:
2010/3/11 Kevin O'Connor <ke...@koconnor.net>:
On Wed, Mar 10, 2010 at 01:24:27PM +0800, Roy Tam wrote:
2010/3/10 Kevin O'Connor <ke...@koconnor.net>:
I don't see an "Illegal Instruction" message. Instead, I see the
keyboard just not working. What qemu version and what command line
did you use?
latest git today. when you type fast.
Bleh. That image defines an int15 wrapper which corrupts %edi.
SeaBIOS calls int154f from the keyboard irq, and it is not prepared
to
handle a corrupted edi. In contrast, Bochs BIOS doesn't care if the
registers change.
What the fdos0138.img image is doing is broken - once it reads
the key
from the ps2 port, nothing stops a new key from being read the next
time something reads from the port. Indeed, although the keyboard
works in qemu-0.11 for fdos0138.img, if one types fast they'll see
duplicate and lost keys.
But it is how programs(Chinese/Japanese/Korean Display Systems,
GW-BASIC, etc.) in the past get input from keyboard.
Can you point me to documentation on this usage?
Sorry I can't find documentation on this usage. But instead I have
lots of old programs written with this usage.
Using undocumented features from BIOS/DOS is very usual in that time.
I cannot check it out right now but I remember to have read that this
is the usual behaviour, not for Asian display systems (that use
combinational character recognition in software (pressing K and A with
a japanese IME writes the KA kana), but for modifiers (CTRL, ALT, so
on).
If you just press A the scancode is just A, then nothing (two reads).
If you press CTRL-A, the scancode is CTRL, then A (two reads).
Anyway this can be tested in real hardware easily. Norton Utilities
diagnostics shown the scancodes.
"Consider" legacy as "broken" is wrong IMHO.
It's broken because it causes key presses to be lost and corrupted.
The ps2 port hardware just doesn't work the way that software is
trying to use it.
You said that "it causes key presses to be lost and corrupted" but I
haven't heard any complain about this.
Real BIOSes (Award BIOS, AMI BIOS, Phoenix BIOS) handle this usage
very well and no key press are lost or corrupted.
Any key press should generate 4 IRQs, for example when I press [Tab]
key, it should have IRQs like this:
ps2: data f (status=1d)
ps2: data f (status=1c)
ps2: data 8f (status=1d)
ps2: data 8f (status=1c)
Even if status&1==1 is handled by the program itself, status==0x1c is
still handled by BIOS.
Programs in the past will try to get data from BIOS in this moment to
ensure two scancodes are the same.
On the contrary *NOT* sending keycode in this moment cause bigger
problem.
The following patch help people to see irq status and data change:
---
diff --git a/src/ps2port.c b/src/ps2port.c
index 49bf551..48d940f 100644
--- a/src/ps2port.c
+++ b/src/ps2port.c
@@ -154,11 +154,19 @@ process_ps2byte(u8 status, u8 data)
static void
process_ps2bytes(void)
{
+ u8 status = 0;
+ u8 data = 0;
+ u8 old_status = 0;
+ u8 old_data = 0;
for (;;) {
- u8 status = inb(PORT_PS2_STATUS);
+ old_status = status;
+ old_data = data;
+ status = inb(PORT_PS2_STATUS);
+ data = inb(PORT_PS2_DATA);
+ if ((data != old_data)||(status!=old_status))
+ dprintf(1, "ps2: data %x (status=%x)\n", data, status);
if (!(status & I8042_STR_OBF))
return;
- u8 data = inb(PORT_PS2_DATA);
process_ps2byte(status, data);
}
}
