From: Stefan Ring <stefanrin@gmail.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0 of 1] Fix for DOS keyboard problems
Date: Sun, 23 Aug 2009 19:20:31 +0200 [thread overview]
Message-ID: <53e878390908231020s32575288jf2dd1450bae241c9@mail.gmail.com> (raw)
In-Reply-To: <20090823124410.GA30789@shareable.org>
On Sun, Aug 23, 2009 at 2:44 PM, Jamie Lokier<jamie@shareable.org> wrote:
> Stefan Ring wrote:
>> The keyboard is still very unreliable when a keyboard driver is
>> loaded inside DOS (I assume that the keyboard driver completely
>> disables the BIOS handler). This behavior is also present without
>> my patch, and I personally don't care about it, so this should not
>> be an obstacle.
>
> Can you say a bit more about what your patch actually fixes?
>
> I've been using QEMU with several versions of MS-DOS and haven't
> noticed any keyboard problems.
>
> I even use various "halt-on-idle" idle programs, and haven't noticed
> any keyboard problems.
>
> So what behaviour does your patch fix?
The particular problem that I noticed and that is 100% reproducible
and also very understandable when you look at what the DOS programs
do, is that in Borland's Text-Mode DOS IDEs (most likely BC++ 3.1, 4,
Turbo Pascal 6 but definitely Turbo Pascal 7) and IIRC also in Turbo
Vision programs generated by them, every cursor key press is
interpreted twice. So when you open up the leftmost menu and press the
down cursor key once, the third entry gets selected instead of the
second one.
The reason for this is that said programs install an IRQ 1 handler
which does little more than read from port 60h and pass control to the
underlying BIOS (or keyboard driver) handler. The BIOS handler reads
port 60h again, and should apparently see the same value as the first
handler. The problem with the cursor keys is that they generate two
scan codes in succession on port 60h that should be read by two
separate IRQ handler activations but because QEMU's original behavior
is to consume one data byte per read from 60h, the data gets used up
too fast.
next prev parent reply other threads:[~2009-08-23 17:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-23 10:54 [Qemu-devel] [PATCH 0 of 1] Fix for DOS keyboard problems Stefan Ring
2009-08-23 10:54 ` [Qemu-devel] [PATCH 1 " Stefan Ring
2009-08-23 12:44 ` [Qemu-devel] [PATCH 0 " Jamie Lokier
2009-08-23 17:20 ` Stefan Ring [this message]
2009-08-23 21:55 ` Jamie Lokier
2009-08-23 22:54 ` Stefan Ring
2009-08-24 7:50 ` Hans de Bruin
2009-08-24 9:24 ` Jamie Lokier
2009-08-24 9:41 ` Hans de Bruin
2009-08-24 8:21 ` malc
2009-08-24 8:44 ` Stefan Ring
2009-08-24 8:49 ` malc
2009-08-24 9:22 ` Jamie Lokier
2009-08-24 9:27 ` Stefan Ring
2009-08-24 9:31 ` Stefan Ring
2009-08-24 15:11 ` Stefan Ring
2009-08-24 15:34 ` malc
2009-08-24 15:38 ` Stefan Ring
2009-08-24 15:40 ` malc
2009-08-25 14:50 ` malc
2009-08-24 13:03 ` Stefan Ring
2009-08-24 13:07 ` Stefan Ring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53e878390908231020s32575288jf2dd1450bae241c9@mail.gmail.com \
--to=stefanrin@gmail.com \
--cc=jamie@shareable.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).