mgvalen@cs.vu.nl (Valent MG) (04/11/91)
To everybody. I have a question or 3 (surprise !). I'm trying to write a (fast) game in Turbo C on an AT, so I want the keyboard-reading to happen as fast as possible. The fastest way is, I think, using inportb(0x60). The problem now is, that the keyboard-buffer fills up, and because I'm not emptying it, I get the buffer-full interrupt & bell. I could solve this by using getch() after each key-hit, but that slows down the (fast) reading quite a lot. So my questions are: - is there a way to turn that buffering off (and in this way , also the checking if the buffer is full)? (In this case, I'll probably miss a few key-hits, but that doesn't matter.) - or some simpel way to check how full the buffer is, and when necessary, emptying the buffer by clearing some bit (and perhaps give an acknowledgement) ? - am I totally wrong and should I do the keyboard-reading completely different (and what is that better solution) ? Thanks already from this side, Marco V.
cs352a41@cs.iastate.edu (Adam Goldberg) (04/12/91)
mgvalen@cs.vu.nl (Valent MG) writes: >To everybody. >I have a question or 3 (surprise !). >I'm trying to write a (fast) game in Turbo C on an AT, so I want >the keyboard-reading to happen as fast as possible. The fastest way >is, I think, using inportb(0x60). The problem now is, that the >keyboard-buffer fills up, and because I'm not emptying it, I get the >buffer-full interrupt & bell. >I could solve this by using getch() after each key-hit, but that >slows down the (fast) reading quite a lot. >So my questions are: > - is there a way to turn that buffering off (and in this way > , also the checking if the buffer is full)? > (In this case, I'll probably miss a few key-hits, > but that doesn't matter.) Sure you could turn it off...redirect the keyboard interrupt vector to point to just an IRET -- but (below) > - or some simpel way to check how full the buffer is, and > when necessary, emptying the buffer by clearing some bit > (and perhaps give an acknowledgement) ? > - am I totally wrong and should I do the keyboard-reading > completely different (and what is that better solution) ? The problem with reading the keyboard via an inportb() function is that you're reading the scan code, not the ASCII code. Further, if you really want fast, you could look into intercepting the keyboard interrupt yourself and calling the BIOS interrupt routine yourself, then dealing with the key when you return...or you could xlate the scan code yourself...ugh -- +-----------------------------------------------------------------------------+ ! Adam Goldberg ! "It's simple! Even a PASCAL ! ! cs352a41@cs.iastate.edu <= this one ! programmer could do it!" ! +-----------------------------------------------------------------------------+
mas35638@uxa.cso.uiuc.edu (Sleipnir) (04/12/91)
In a very similar situation, some friends of mine wrote the read routine in assembly, and then linked it in. This works very well, but requires a little work (I don't know how to link into c). Mike Stangel m-stangel@uiuc.edu