| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 180.1 | Don't call EventMultiple too often. | PANGLS::BAILEY | | Tue Aug 02 1988 16:45 | 13 |
| It depends upon how gritty you want to get.
The only ``portable'' approach is with an EventMultiple call. The
best way to put an EventMultiple in a loop which is performance
sensitive is to only call it every second or so. The performance
really does get bad if you call it frequently.
Your other option is to put a wedge into one of the keyboard interupt
handlers. Look in the XBIOS docs for how to do that. I'm not sure
that its really all that difficult to do this.
Steph
|
| 180.2 | Bconstat | PRNSYS::LOMICKAJ | Jeff Lomicka | Fri Aug 05 1988 12:23 | 3 |
| Bconstat() is a pretty cheap service to detect if there is any typeahead
on the console.
|
| 180.3 | ^Y detect or typeahead | MILRAT::WALLACE | | Fri Aug 05 1988 13:08 | 7 |
| That implies that your program can't take advantage of typeahead
and detect ^Y at the same time. Also using Bconstat() means you
need a call to it (or appropriate handler routine) in every "loop"
in your program. It would be much nicer (though maybe not possible)
to have an AST type ^Y detection.
Ray
|
| 180.4 | Bconout() versus get_event() | MILRAT::WALLACE | | Fri Aug 05 1988 13:13 | 10 |
| Just reRead the original note (should have done that before my reply
to Jeffs suggestion)... Since Martin mentions the use of get_event()
and it being slow, I would concurr with Jeff that Bconstat() would
be a good (faster) alternative to get_event().
It would still be nice to be able to trap ^Y's asynchronously and
without disturbing the rest of the typeahead buffer while whatching
for the ^Y.
Ray
|
| 180.5 | A possibility | PRNSYS::LOMICKAJ | Jeff Lomicka | Mon Aug 08 1988 11:34 | 14 |
| > It would still be nice to be able to trap ^Y's asynchronously and
> without disturbing the rest of the typeahead buffer while whatching
> for the ^Y.
Well, there are a few things you can try. Note that I don't think you
will ever find a reasonable way of "signaling" the interrupt event in a
trappable way, but if you are willing to poll, there may be ways. One
possibility would be to do an Iorec( 1), and poll the tail of the
buffer for the keyboard scan code of "^Y" to appear. I don't believe
that this will actually work, because I think that there is another
level of buffering going on inside GEM that is below this level that
handles the ^C that is trapped by Cconout and Cconin. It is, however,
worth a try.
|
| 180.6 | ISRs aren't necessarily all that hard. | PANGLS::BAILEY | | Mon Aug 08 1988 18:25 | 7 |
| Really, the only way to get asynchronous ^Y detection is to write
a keyboard interrupt handler which check to see if the key is a
^Y, and if not, calls the old keyboard handler.
Poling is a way of life in low-budget event-driven interfaces.
Steph
|
| 180.7 | Other way around ? | MOVIES::FORSTER | | Mon Nov 07 1988 07:49 | 7 |
| I know this is a bit late but...
I had a look at this and it seemed simpler to steal the KBD/MIDI ISR vector
and call the existing keyboard ISR first, then look at the IOREC when the
ISR returns. This requires a lot less coding.
Dave.
|