Mail Archives: djgpp/1999/02/17/10:52:17
Eli,
Thanks for the reply. Before I say (type? ;-) anything else, I would like to
take a moment to say thanks for all the help you have given me and the hundreds
(thousands?) of people in the new groups. As I have read the news group I have
noticed that you regularly and diligently respond to people in need (even
questions that are repeated once or twice a day ;-). DJGPP couldn't have become
the icon it is today without the support and efforts of people like yourself and
DJ (and the rest of the gang!). It is a good thing to do
development/documentation work for free (and very generous). It is an even
better thing to take the time to help people directly and point them to where
the information is. Great work!
Please let me know what to change and where and I'll take care of it at this
end. It would seem that overwriting just the dangerous flags would be a safer
approach than overwriting them all. The flags that are usually used to pass a
status bit or two (zero, carry, ...) should be all that are left altered.
As far as returning 0x00 is concerned, it actually may cause problems. I have
noticed that the BIOS ignores break codes (it never does anything when you
release a key), but it does pay attention to make codes. Since the BIOS code is
written for a standard PC keyboard, it may just look for values below 0x80 for
processing. I have had pretty good luck sending 0x80, but in some versions of
the Phoenix BIOS this causes it to send something to the keyboard that is
erroneous. That is the keyboard responds back with an 0xFF (this is an error
response form the keyboard). Recently I changed substituting 0xF0, which the
BIOS seems to ignore completely. Don't ask me why, I didn't bother to try and
dis-assemble the BIOS code, I just tried various values while watching Int 9.
As far as my comment about not following the docs, I wasn't referring to the
ASCII code returned by getxkey (although that *is* the way I worded it :O ), but
was referring to the flag register not being preserved. Come to think of it I
do remember (vaguely ;-) something about not changing the flags in the DPMI
register structure in an int handler. It had something to do with setting a bad
SP, CS or DS, can't remember which... This maybe why the wrapper does this.
Is there a way I can *not* use the wrapper code? While it made my life a lot
easier, this carry flag thing does need some attention (at least in my project).
Thanks for your help, this problem has been a true annoyance on a project that
has more than it's fair share of problems ;-)
Take care,
KJohn
Eli Zaretskii wrote:
>
> On Mon, 15 Feb 1999, John Scott Kjellman wrote:
>
> > If you run it and then press a few keys, it will display the character (if
> > printable) and the getxkey() value for each key. The '1' key should be
> > translated to a '2' and the '0' key should be dropped, but isn't!
>
> The problem is real. The wrapper overwrites the FLAGS with their
> original value, before it does an IRET. I know how to fix this (a simple
> change to the wrapper is all it takes), but I want first to be sure I
> don't introduce bugs with that change. The wrappers were written by
> several very clever and experienced people, and they might have done this
> for a good reason (e.g., some bits in FLAGS are very dangerous). I asked
> the rest of DJGPP developers whether they are aware of any problems.
>
> In the meantime, you can work around this problem by changing the scan
> code to 0; this will also make the key be ignored (as no key has a zero
> scan code).
>
> Btw, I think your code has to check for key-break events, not only for
> key-make events. Who knows what will some BIOSes do if you only
> substitute the make scan codes?
>
> > BTW, in my
> > previous posting I stated 0x30 was the scan code for the '0' key, it is not 0x0B
> > is, 0x30 is the ASCII value ;-) This just doesn't seem to follow the docs....
>
> Where does the docs contradict this? ASCII keys return their ASCII codes
> in getxkey, not their scan codes.
- Raw text -