On Sun, 17 Jun 2001, Marcus Meissner wrote:
However, Monkey Island does not appear to get <return> presses. I see in 60 returning scancode 0x1c (and 0x9c on release), but it never triggers any reaction :(
Yes, the relevant code in msdos/int09.c is stiff #if 0-ed out in the Wine CVS. I think I have some stuff fixing it lying around in my old Wine tree, but it was rejected in its first form, so it might need a rewrite. But the vm86 restructure is probably more important...
On Sun, Jun 17, 2001 at 11:14:15PM +0200, Ove Kaaven wrote:
On Sun, 17 Jun 2001, Marcus Meissner wrote:
However, Monkey Island does not appear to get <return> presses. I see in 60 returning scancode 0x1c (and 0x9c on release), but it never triggers any reaction :(
Yes, the relevant code in msdos/int09.c is stiff #if 0-ed out in the Wine CVS. I think I have some stuff fixing it lying around in my old Wine tree, but it was rejected in its first form, so it might need a rewrite. But the vm86 restructure is probably more important...
Hmm.
Not really, I do see int9 delivered to monkey1.exe and monkey1.exe in turn doing inb(0x60) and the +io debugging giving back the correct scancode (0x1c on press and 0x9c on release).
It however does not react on it :/
Ciao, Marcus
On Fri, 22 Jun 2001, Marcus Meissner wrote:
Not really, I do see int9 delivered to monkey1.exe and monkey1.exe in turn doing inb(0x60) and the +io debugging giving back the correct scancode (0x1c on press and 0x9c on release).
After reading the scancode, however, it determintes that it was not a cursor key, so it passes it on to the DOS int9 handler for default processing there. Then it expects the keypress to appear in the BIOS keyboard buffer.
(You might have seen that if you also ran --debugmsg +int)
I think we managed to get monkey island to start by fixing that keyboard code. However, because of that annoying wineserver assertion failure, no DOS apps like this run with my code anymore, so I can't check. Unless you want to fix the wineserver assertion at server/console.c line 194, so CONSOLE_make_complex can run in one thread while another winedos thread keeps waiting for input?
Hmm, but it looks like I may already have rewritten the interrupt separation for int9 enough, maybe I could submit that patch independently of the new DOS event loop (if you don't need the high performance the new event handling sustains)?
On Fri, Jun 22, 2001 at 02:44:06PM +0200, Ove Kaaven wrote:
On Fri, 22 Jun 2001, Marcus Meissner wrote:
Not really, I do see int9 delivered to monkey1.exe and monkey1.exe in turn doing inb(0x60) and the +io debugging giving back the correct scancode (0x1c on press and 0x9c on release).
After reading the scancode, however, it determintes that it was not a cursor key, so it passes it on to the DOS int9 handler for default processing there. Then it expects the keypress to appear in the BIOS keyboard buffer.
I forgot I am also using the following additional patch (probably slightly incorrect for special keys):
Index: dosvm.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/dosvm.c,v retrieving revision 1.6 diff -u -r1.6 dosvm.c --- dosvm.c 2001/05/14 20:09:38 1.6 +++ dosvm.c 2001/06/23 06:49:02 @@ -388,6 +388,7 @@ static void DOSVM_ProcessMessage(MSG *msg) { BYTE scan = 0; + BYTE xchar;
TRACE_(int)("got message %04x, wparam=%08x, lparam=%08lx\n",msg->message,msg->wParam,msg->lParam); if ((msg->message>=WM_MOUSEFIRST)&& @@ -408,7 +409,8 @@ * should check for them */ INT_Int09SendScan(0xE0,0); } - INT_Int09SendScan(scan,0); + xchar = msg->wParam & 0xff; + INT_Int09SendScan(scan,xchar); break; } }
This code is putting 0x0d/0x1c pairs into the keyboard buffer.
(You might have seen that if you also ran --debugmsg +int)
I see those, and I see it appended to the keyboard buffer (even looking directly at the DOS image under /tmp/filexxxxx).
However, monkey1.exe does not seem to read out this buffer, some keypresses later it is full. The BIOS data structures appear all ok.
Trace snippet:
trace:int:DOSVM_SendQueuedEvent dispatching IRQ 1 trace:int:DOSVM_SendQueuedEvent clearing Pending flag trace:int:IO_inport 1-byte value from port 0x60 trace:int:IO_inport returning ( 0x1c ) 0x60 < 1c @ 201a:1632 trace:int:DOSVM_SimulateInt builtin interrupt 09 has been branched to trace:int:INT_Int09Handler scan=1c fixme:int16:INT_Int16AddChar (0d,1c) fixme:int16:INT_Int16AddChar (0d,1c) at offset 30 trace:int:DOSVM_PIC_ioport_out received EOI for current IRQ, clearing trace:int:DOSVM_PIC_ioport_out another event pending, signalling dosmod trace:int:DOSVM_Process DOS module caught signal 12 trace:int:DOSVM_Process setting Pending flag, interrupts are currently enabled trace:int:DOSVM_SendQueuedEvent dispatching IRQ 1 trace:int:DOSVM_SendQueuedEvent clearing Pending flag trace:int:IO_inport 1-byte value from port 0x60 trace:int:IO_inport returning ( 0x9c ) 0x60 < 9c @ 201a:1632 trace:int:DOSVM_SimulateInt builtin interrupt 09 has been branched to trace:int:INT_Int09Handler scan=9c trace:int:DOSVM_PIC_ioport_out received EOI for current IRQ, clearing
Very puzzling.
I think we managed to get monkey island to start by fixing that keyboard code. However, because of that annoying wineserver assertion failure, no DOS apps like this run with my code anymore, so I can't check. Unless you want to fix the wineserver assertion at server/console.c line 194, so CONSOLE_make_complex can run in one thread while another winedos thread keeps waiting for input?
I do not get that assertion? I get keyboard input directly from the DirectDraw window with above message loop.
Ciao, Marcus
-
Marcus Meissner -
Ove Kaaven