Mail Archives: djgpp/1998/09/10/05:15:37
> Always begin with the PM handler and only install a real-mode one if PM
> is not enough to catch up. In general, you should never need a real-mode
> handler for the keyboard, since it is only required for interrupt rates
> in excess of several KHz, and no keyboard is that fast.
>
> I'm not sure you indeed need a hardware interrupt handler. It might be a
> good idea to describe why do you think you need it, so people here could
> advise.
Well, first of all, I prefer to write ALL my code by myself, don't ask
why, it's just so.
I know I need a keyboard handler for my ray-casting engine(you all knew
what I was doing, right? according to the function names in the
profiler...), so numerous buttons can be pressed at once(go left AND
up). I was thinking of doing a variable, with each bit in it,
representing a different key(al the handler would do is to change this
variable), that way I can check before starting each frame, which keys
are pressed.
For the time being, using he getch, gives me a little side-effect. When
I keep a key down for a few seconds, the values are starting to pile up
in the buffer, and after I release the key, it takes the program some
time to stop. This, ofcourse, will never happen if i'll use a keyboard
handler.
If I'm already here, then I'll ask two more questions:
1)If I took control on the keyboard hardware interrupt, but I want some
of the keys to be acknowledged to the old one, there is a port number
that I don't remember, right?
should I write the keyboard codes into it?
2)if the keyboard interrupt is a hardware one, how can it be that it has
an address in memory?
3)how do I compile ASM files into .S(excuse my ignorance)?
4)how will I link those .S files into my program?
5)how will I be able to use the keyboard variable declared in my main c
source, in the handler, that was written somewhere else?
- Raw text -