From:	is05562 AT salleURL DOT edu
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: keyboard handler...
Date:	2 Feb 1999 08:59:07 GMT
Organization:	CESCA News service. Catalunya
Lines:	108
Message-ID:	<796eor$ja$1@pedraforca.cesca.es>
NNTP-Posting-Host:	cygnus.salleurl.edu
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

>> I've been coding some stuff with djgpp, and I've been using the
>> "whole" allegro only for the keyboard handler. But I think that if
>> I wrote my own keyboard handler the application I'm coding would
>> be faster
>
>I don't think that is a very sensible decision. You can surely save
>a lot of space by writing something less complex than the Allegro
>keyboard handler,

SURE!!! :)

>but it won't be measurably faster. Remember that
>this code is only ever executed when somebody presses a key: in the
>grand scale of things this is a completely negligible overhead, and
>I very much doubt that you will even see it in a profile log! There
>is no point in trying to speed up your program by optimising code
>that is already not taking any time to execute...

Yes... well... maybe I didn't explained myself very well... I'm not a
newbie in writing interrupt handlers, and I understand perfectly the concepts
behind them. The thing is that with allegro keyboard handler, and my program,
I have to check some array variables every 1/50 sec, EVEN THERE HASN'T been a
key press/release, and now if I write my own keyboard handler, this check will
only occur when a key has been pressed / released ONLY! This surelly will
save me a lot of CPU cycles, as well as the keyboard response of my
application will resemble more fresh... (at least I hope so! :))

>> I know I "should" lock some code/data, but as this C example
>> should not swap to disk, I'm still not doing it.
>
>It is still important, though. You might be surprised by the strange
>places that some DPMI servers (eg. win95) can decide to start swapping,
>and if you are running under CWSDPMI, you have to lock the data even
>if your program doesn't swap (that's a safety precaution to help
>people write reliable code).

OK then... One thing that I'll have in mind from now... Maybe I'll still use
the allegro macros to lock data/code! :))

>> also: What's an "iret_wrapper", and "why" should I need one ? Is it
>> mandatory?
>
>Very much so. An interrupt isn't called in the same way as a regular
>C function, so you need a block of wrapper code that will be called
>by the hardware event, and that can then set up the standard C
>environment before calling your handler function.

OK then... I think that I knew then what an iret_wrapper was, (it's "more or
less the same that adding the interrupt" keyword in borland for example ).
But then sorry for my djgpp-newbie-ness in pm-interrupt handling! The word
"wrapper" didn't mean anything for me... and even confused me a bit... This
might be a thing to correct in the FAQ's then.. (which should be intended for
newbies), or maybe is that I'm the only one which got confused with the
"wrapper" concept! :))

>The djgpp libc wrappers are ok for simple interrupts, but don't
>properly deal with reentrant calls to the same handler. If you need
>things like that, you will have to write your own wrapper in asm:
>see the irqwrap.s file from Allegro for one possible implementation
>and to get an idea of what kind of stuff these wrappers must do.

Ok... I'll have a check then, even I don't seem to need them now...

>> static void my_keyboard_rsi(void){
>>
>>    asm("cli");
>>    leave=1;
>>    outportb(0x20,0x20);
>>    asm("sti");
>> }
>
>You don't need those cli and sti instructions.

I didn't knew... I didn't know exactly the code that gcc/as were generating
for my handler...

>Your problem, though,
>is that you are never bothering to read any data from the keyboard
>controller (a byte from port 0x60), so it is stuck waiting for your
>program to access the current keypress, and is unable to respond
>to any further input.

OH MY GOD!!! What a shame!!! :( How could I have send this piece of code
to the newsgroup!! HOW COULD I FORGET THAT!!!! :)) Now I've destroyed my
image of serious coder! :))

I've just added the inportb(0x60), and the handler worked flawlessly! :))
Thanks!! BTW also, maybe I didn't wanted to actually read the 0x60 port,
but only actualizing the "leave" variable... In both cases the inport 0x60
seems to be necessary though... The thing is that whithout the inport 0x60
the handler behaviour wasn't as rare as one would expect... it even updated
the variable... but then when changing back to the old RSI, the inport 0x60
seemed to be waiting, locking the whole PC...

BTW also, a new doubt came to me... If I "allocate" an IRET wrapper, MUST I
deallocate it explicitly? (There's a go32 function to do that...) If I don't
deallocate it, my program seems to work ok... But I don't feel 100% OK, as
maybe it's only casuality...

BTW also, thanks also to all other people answering my doubts, but my 
problems seem to have disappeared (for the moment only! :)

ok then... bye for now...


                                                Isaac Santaolalla

- Raw text -