Message-ID: <36CAE539.FD86039A@ameritech.net> Date: Wed, 17 Feb 1999 09:50:17 -0600 From: John Scott Kjellman X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: djgpp AT delorie DOT com Subject: Re: How to check the carry flag? (long) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com 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.