Keyboard interrupt...how?
Matthew Partridge
Can anyone help me to set up a keyboard interrupt in 'C'. I've never
tried anything like this before and I have no idea where to start.
I've looked at "The Amiga GURU Book" but can't find anything about
specificaly opening the keyboard.device.
What I would like is a routine that gets called everytime a key is
pressed. Could this be done before the keypress gets to a console? And
if so could I stop it ever getting to the console, so I could print it
out myself?
Thanks in advance.
Matt.
Andre Weissflog
Matthew Partridge wrote:
A possible solution depends on what you want to do.
Writing your own keyboard interrupt handler is not necessary in
any case.
The highest level approach would be to open an intuition
window and ask for vanilla key or raw key events. That
way you only get signalled when the input focus is yours,
and keys are pressed.
If for any reason you must go lower level (and loose the
input focus handling), write an input handler.
Anyway, get the RKMs! (sorry for being sarcastic today)
--
Andre 'Floh' Weissflog <fl...@mkmk.in-chemnitz.de>
#include "cool_sig.h"
M.R.Pa...@ncl.ac.uk
"Andre Weissflog" <fl...@mkmk.in-chemnitz.de> wrote:
>Matthew Partridge wrote:
>
>> Can anyone help me to set up a keyboard interrupt in 'C'. I've never
>> tried anything like this before and I have no idea where to start.
>> I've looked at "The Amiga GURU Book" but can't find anything about
>> specificaly opening the keyboard.device.
>>
>> What I would like is a routine that gets called everytime a key is
>> pressed. Could this be done before the keypress gets to a console? And
>> if so could I stop it ever getting to the console, so I could print it
>> out myself?
>>
>
>A possible solution depends on what you want to do.
>Writing your own keyboard interrupt handler is not necessary in
>any case.
OK I'll come clean. I'm converting something that has been written for
PC's and the original code used a keyboard interrupt and I am unsure
about where to put a polling routine.
>The highest level approach would be to open an intuition
>window and ask for vanilla key or raw key events. That
>way you only get signalled when the input focus is yours,
>and keys are pressed.
I've tried this, but won't I have to poll the keyboard, or put my
program in a wait() state?
>If for any reason you must go lower level (and loose the
>input focus handling), write an input handler.
Sounds far to complex. I'm sure you can just set up an interrupt...maybe
not?
>Anyway, get the RKMs! (sorry for being sarcastic today)
I have one, the Hardware Ref Manual, I'm just waiting till I see the
others going cheap.
Dennis Lee Bieber
In article <4ojq8f$h...@whitbeck.ncl.ac.uk> M.R.Pa...@ncl.ac.uk writes:
> "Andre Weissflog" <fl...@mkmk.in-chemnitz.de> wrote:
>
> >The highest level approach would be to open an intuition
> >window and ask for vanilla key or raw key events. That
> >way you only get signalled when the input focus is yours,
> >and keys are pressed.
>
> I've tried this, but won't I have to poll the keyboard, or put my
> program in a wait() state?
>
You NEVER use a polling loop/busy wait on a multitasking machine!
Hook up an IDCMP message port to the window and specify which
events you are interested in, and a signal bit to be triggerred when
one of those events arrives. Wait(bit); get message, copy needed
data, reply message, process data; repeat the get cycle until no more
messages, go back to wait.
--
> ============================================================ <
> wulf...@netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> D.Bi...@GEnie.com | FurryMUCK and FurToonia <
> ============================================================ <
> PGP key: Finger wulf...@netcom.com <
> Home Page: ftp://ftp.netcom.com/pub/wu/wulfraed/wulfraed.htm <
Jeroen T. Vermeulen
In article <4ohf31$b...@whitbeck.ncl.ac.uk> Matthew Partridge <M.R.Pa...@ncl.ac.uk> writes:
> What I would like is a routine that gets called everytime a key is
> pressed. Could this be done before the keypress gets to a console? And
> if so could I stop it ever getting to the console, so I could print it
> out myself?
Yes you can--but IMHO a keyboard interrupt is a very dirty and inelegant
solution. It may even make the programming harder for you as there are things
you just can't do from an interrupt directly.
Why not just write a commodity? For an example, look at my proggie Clicker on
Aminet (Clicker.lha in util/cdity). It does almost exactly what you want, only
it generates audio clicks for each keypress. It's PD, C source is included plus
Makefile for gcc, SMakefile for SAS and "project" file for StormC. Should be
quite readable but feel free to mail me if you should find that it isn't.
All the extra stuff such as "eating" the input events so they don't reach the
original recipient can be done through commodities objects, but be careful whose
input you eat.
> Matt.
--
============================================================================
# Jeroen T. Vermeulen \"How are we doing kid?"/ Yes, we use Amigas. #
#--- j...@xs4all.nl ---\"Oh, same as always."/-- ... --#
#jver...@wi.leidenuniv.nl \ "That bad, huh?" / Got a problem with that? #
We don't call people `dead' here. We prefer to say they're vitally impaired.
Peter McGavin
Matthew Partridge <M.R.Pa...@ncl.ac.uk> writes:
>Can anyone help me to set up a keyboard interrupt in 'C'.
Reading keyboard events is normally not done through direct access to
the keyboard.device. It's better to use IDCMP or an input handler.
>What I would like is a routine that gets called everytime a key is
>pressed. Could this be done before the keypress gets to a console? And
>if so could I stop it ever getting to the console, so I could print it
>out myself?
It sounds like you want to install an input handler. That let's you
intercept and filter input events before they reach Intuition and the
console.device. This is all fully described with examples in the
Devices RKM pages 101..118.
--
Peter McGavin. (p.mc...@irl.cri.nz)
M.R.Pa...@ncl.ac.uk
pet...@maths.grace.cri.nz (Peter McGavin) wrote:
>Matthew Partridge <M.R.Pa...@ncl.ac.uk> writes:
>>Can anyone help me to set up a keyboard interrupt in 'C'.
>It sounds like you want to install an input handler. That let's you
>intercept and filter input events before they reach Intuition and the
>console.device. This is all fully described with examples in the
>Devices RKM pages 101..118.
Thanks for the tips but it looks like I'm going to have to get the RKM's.
One down (hardware) 3 (??) to go.
- Matt
Andre Weissflog
M.R.Partridge wrote:
> "Andre Weissflog" <fl...@mkmk.in-chemnitz.de> wrote:
>
> >The highest level approach would be to open an intuition
> >window and ask for vanilla key or raw key events. That
> >way you only get signalled when the input focus is yours,
> >and keys are pressed.
>
> I've tried this, but won't I have to poll the keyboard, or put my
> program in a wait() state?
>
If you can't Wait() you can still check the message port directly
if there are messages waiting, that would be polling. But it's
not multitasking friendly, doing a Delay() in the loop
would help a bit however.
It would be helpful to know what the PC program you want
to port over does with the keyboard information.
> >If for any reason you must go lower level (and loose the
> >input focus handling), write an input handler.
>
> Sounds far to complex. I'm sure you can just set up an
> interrupt...maybe
> not?
>
You could add an interrupt handler, but that's just as
complex as writing an input handler. And remember that
AmigaOS is a multitasking system, you'd had to check
explicitly in your keyboard handler if your program has
the focus, or you will be bothered with text that has
been typed by the user into another programs window.
> >Anyway, get the RKMs! (sorry for being sarcastic today)
>
> I have one, the Hardware Ref Manual, I'm just waiting till I see the
> others going cheap.
>
If they are still available then... the RKM Libraries is
a must, and with your specific problem RKM Devices would also
be a help.
Dennis Lee Bieber
In article <4on546$r...@whitbeck.ncl.ac.uk> M.R.Pa...@ncl.ac.uk writes:
> Thanks for the tips but it looks like I'm going to have to get the RKM's.
> One down (hardware) 3 (??) to go.
>
Four if you count the Style Guide
M.R.Pa...@ncl.ac.uk
"Andre Weissflog" <fl...@mkmk.in-chemnitz.de> wrote:
>If you can't Wait() you can still check the message port directly
>if there are messages waiting, that would be polling. But it's
>not multitasking friendly, doing a Delay() in the loop
>would help a bit however.
>
>It would be helpful to know what the PC program you want
>to port over does with the keyboard information.
>
is processed and converted into a format that a BBC would understand and
then fed into the main BBC fetch/exectue loop as an hardware interrupt
for the BBC.
This is why I can't simply Wait().
I've tried to find a convienient spot for a polling routine but none seem
to work.
>> >Anyway, get the RKMs! (sorry for being sarcastic today)
>>
>> I have one, the Hardware Ref Manual, I'm just waiting till I see the
>> others going cheap.
>>
>If they are still available then... the RKM Libraries is
>a must, and with your specific problem RKM Devices would also
>be a help.
I'll get them when I next see them ;-)
Matt.
Michael van Elst
M.R.Pa...@ncl.ac.uk writes:
>The PC program in question is a BBC emulator. The keyboard information
>is processed and converted into a format that a BBC would understand and
>then fed into the main BBC fetch/exectue loop as an hardware interrupt
>for the BBC.
>This is why I can't simply Wait().
>I've tried to find a convienient spot for a polling routine but none seem
>to work.
Simple. The BBC emulator should open a window. Somewhere in the emulator
main loop you should poll the windows message port for RAWKEY messages
and translate them accordingly.
Regards,
--
Michael van Elst
Internet: mle...@serpens.rhein.de
"A potential Snark may lurk in every tree."
Andre Weissflog
Michael van Elst wrote:
> M.R.Pa...@ncl.ac.uk writes:
>
> >This is why I can't simply Wait().
>
> Simple. The BBC emulator should open a window. Somewhere in the emulator
> main loop you should poll the windows message port for RAWKEY messages
> and translate them accordingly.
>
Yes, and while we're at it... It might be a good idea to
pause the emulator when its window is not the active one, so the
emulator isn't sucking cpu cycles when the user does
something else.
Just tell Intuition you want to hear also about IDCMP_INACTIVEWINDOW
and IDCMP_ACTIVEWINDOW. In the main loop poll for IDCMP_INACTIVEWINDOW,
then Wait() until a IDCMP_ACTIVEWINDOW message arrives. At least
that's the theory.
M.R.Pa...@ncl.ac.uk
"Andre Weissflog" <fl...@mkmk.in-chemnitz.de> wrote:
>Michael van Elst wrote:
>> Simple. The BBC emulator should open a window. Somewhere in the emulator
>> main loop you should poll the windows message port for RAWKEY messages
>> and translate them accordingly.
>
>Yes, and while we're at it... It might be a good idea to
>pause the emulator when its window is not the active one, so the
>emulator isn't sucking cpu cycles when the user does
>something else.
OK I've got it now. Is this the recommended way of doing things, polling when
the task is active (and it's window as well) and then effectively shutting it
down when the user switches away from the task?
Matt.
Dennis Lee Bieber
In article <4op1rt$2...@whitbeck.ncl.ac.uk> M.R.Pa...@ncl.ac.uk writes:
> The PC program in question is a BBC emulator. The keyboard information
> is processed and converted into a format that a BBC would understand and
> then fed into the main BBC fetch/exectue loop as an hardware interrupt
> for the BBC.
>
I have to admit that I don't know what a "BBC" is...
However, I'd see the above as two separate tasks running in
parallel. The BBC emulator, and an input process. The input process
would use a window and Wait() for IDCMP messages. It would format
those messages into whatever is needed by the BBC and send the new
string out to the BBC via another message port. If you really needed
to, the BBC could do a polling loop on THAT message port. This
prevents having to hook into the keyboard processing itself and
trying to figure out which window the key was meant for. Intuition
would only send stuff to the Formatter/Translator task when the focus
is in its window; the Formatter/Translator task then sends only what
the BBC expects via a separate port.
> This is why I can't simply Wait().
>
This scheme does let the Formatter use Wait(), and lessons
the load on the system even with a polling loop in the emulator --
since the emulator will not find a message unless the Formatter has
sent it one -- the test for a waiting message should be much shorter
and less processor intensive than having to handle every keypress...
Peter McGavin
M.R.Pa...@ncl.ac.uk writes:
>The PC program in question is a BBC emulator. The keyboard information
>is processed and converted into a format that a BBC would understand and
>then fed into the main BBC fetch/exectue loop as an hardware interrupt
>for the BBC.
The approach I used in my Spectrum emulator is multiple tasks sharing
a block of public memory. The public memory includes emulated Z80 I/O
and memory address space. The main, highest-priority task handles
IDCMP input events (keyboard, gameport, menus,...) in a Wait() loop
and updates Z80 IO space as events occur. The middle-priority task
runs every vblank and generates the display from emulated vram as
necessary (but usually it does nothing because there no changes to the
display.) The lowest-priority task runs the Z80 emulator. It all
goes something like this:
Main task: (high priority)
initialise and open devices;
start other tasks;
loop {
Wait (eventmask);
if (keyboard)
convert keycode to public format used by Z80 IN instruction;
if (gameport)
convert joystick data to public format used by Z80 IN instruction;
if (menu)
...
}
kill other tasks;
cleanup;
Display updater task: (medium priority)
loop {
WaitTOF();
compare Z80 vram with oldvram and QBlit() parts of display as required;
/* QBlit() runs in parallel with the Z80 emulator */
}
Z80 emulation task: (low priority)
loop {
check for Z80 interrupts or requests to pause or stop;
execute a few Z80 instructions; /* actually threaded code */
}
OK, version 1.7 that I released has only 2 tasks, but the above is
what I was working towards. In fact I have all 3 tasks working but I
revamped the Z80 emulator at the same time and introduced so many bugs
in the Z80 emulator that I never released the new version.
--
Peter McGavin. (p.mc...@irl.cri.nz)
Andre Weissflog
M.R.Partridge wrote:
> "Andre Weissflog" <fl...@mkmk.in-chemnitz.de> wrote:
> >Yes, and while we're at it... It might be a good idea to
> >pause the emulator when its window is not the active one, so the
> >emulator isn't sucking cpu cycles when the user does
> >something else.
>
> OK I've got it now. Is this the recommended way of doing things,
> polling when
> the task is active (and it's window as well) and then effectively
> shutting it
> down when the user switches away from the task?
>
No of course not. If every program did it like this, then
there would be no multitasking at all, but some sort of
"application switching". Most programs (even those without
user interface) wait for some event to happen (and have
nothing to do if no events arrive). Instead of polling
in an (otherwise empty) loop and wasting cpu cycles, the
task asks the operating system to put itself to sleep and
wake it up again, when the requested event arrives [of course
that's a rather obvious explanation of "why multitasking
even works on a 7MHz 68000" :-)].
Some programs don't fit very well into this system, for instance
action games or bbc emulators, because they must do stuff all
the time and are not event driven. On the other hand, this is not
the type of program which MUST continue in the background. So the
"stop when not active" is a good compromise (you don't want to run
raytracers on the emulator, do you?). It's some sort of "power
managment" for system responsiveness.
--
#id "Andre 'Floh' Weissflog <fl...@mkmk.in-chemnitz.de>"
#include "yasig.h"
#project "Personal Amok"
Dennis Lee Bieber
In article <4oqbvd$5...@whitbeck.ncl.ac.uk> M.R.Pa...@ncl.ac.uk writes:
>
> OK I've got it now. Is this the recommended way of doing things, polling when
> the task is active (and it's window as well) and then effectively shutting it
> down when the user switches away from the task?
>
"Recommended"? Not really. On the Amiga all tasks could be
active, the window only defines which task has the INPUT stream.
Using a polling loop when the task has input focus may still be
wasting CPU cycles which could be better used by another task (maybe
something with no input, but lots of output being generated).
This presumes a true polling loop, ie:
loop forever
test-input-stream
if input available then
process input
end if
end loop
That type of loop is best replaced with a system Wait()
operation:
loop forever
Wait(input-stream)
process input
end loop
OTOH, if you have some other type of processing going on,
then fitting a test at some regular interval may be feasible.
loop forever
loop for j=1..400 // pretend we are updating a
disply
loop for i=1..640
update pixel (i,j)
end loop
test-input-stream
if input available then
process input
end if
end loop
end loop
This is not such a waste of CPU time as meaningful processing
is taking place, not just spinning cycles until something arrives as
input.
The input stream would still be something like an IDCMP
message port -- no need to go to the input device/keyboard
Kevin McKinnon
In article <4oqbvd$5...@whitbeck.ncl.ac.uk>, M.R.Pa...@ncl.ac.uk
says...
>
>"Andre Weissflog" <fl...@mkmk.in-chemnitz.de> wrote:
>>Michael van Elst wrote:
>>> Simple. The BBC emulator should open a window. Somewhere in the
emulator
>>> main loop you should poll the windows message port for RAWKEY
messages
>>> and translate them accordingly.
>>
>>pause the emulator when its window is not the active one, so the
>>emulator isn't sucking cpu cycles when the user does
>>something else.
>
polling when
>the task is active (and it's window as well) and then effectively
shutting it
>down when the user switches away from the task?
>
If you set up a proper Wait() loop, you don't need to worry about
whether a task is active or not. Intuition will feed you RAWKEY
msgs when you are active, and you'll stay in the Wait() loop when
you're not ('cause Intuition won't be feeding you RAWKEYs... someone
else will be getting them.)
Sample code available if it will help.
Best regards,
Kev
Matthew Partridge
max...@knet.kootenay.net (Kevin McKinnon) wrote:
>If you set up a proper Wait() loop, you don't need to worry about
>whether a task is active or not. Intuition will feed you RAWKEY
>msgs when you are active, and you'll stay in the Wait() loop when
>you're not ('cause Intuition won't be feeding you RAWKEYs... someone
>else will be getting them.)
>
>Sample code available if it will help.
I can't Wait() as the program needs to keep working while the user isn't
using the keyboard.
It is working now (a tiny bit slowly though ;) the key presses don't seem to
be stored. They only appear if the user happens to be pressing the key when
the program checks (this seems to be the same as Frodo)
Matt.
Wessel Dankers
Matthew Partridge <M.R.Pa...@ncl.ac.uk> wrote:
> I can't Wait() as the program needs to keep working while the user isn't
> using the keyboard.
Poll the signals using SetSignal(NULL, NULL).
> Matt.
--
Wessel Dankers
Børge Nøst
>The PC program in question is a BBC emulator.
>This is why I can't simply Wait().
Wrong approach.
Decouple the emulator hw and the Amiga hw.
Use an input handler or some other asynchronous method to get the keyboard
data. Massage the data to be what the BBC expects.
When the emulator does a read of the keyboard use the data you already have
stored. Probably much faster if the 6502 program polls the stuff in a loop.
-Børge Nøst
Heinz Wrobel
Matthew Partridge (M.R.Pa...@ncl.ac.uk) wrote:
>I can't Wait() as the program needs to keep working while the user isn't
>using the keyboard.
Use SetSignal() to check for events on the IDCMP while your SW is
busy.
--
Heinz Wrobel Private Mail: he...@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email
ch...@wiloyee.shnet.org
I havn't yet tried to write an keyboard interrupt, although it should be
no problem to set up the needed CIA stuff. I usually poll the keyboard once
each vertical blanking interrupt, assuming that nobody can type more then 25
characters per second :-)
Please follow 100% the timing guidelines layed out in the rom kernal manual,
or otherwise your code will fail on some older Amigas. THIS IS NO JOKE!
THIS REALLY HAPPENS! If you hack the hardware, do it, but do it RIGHT!
To get this work correctly you must disable the kernel interrupts (or
two tasks are reading the keyboard) and send the handshake pulse (by
switching a CIA bit for a specified amount of time).
Try to get the one and only Amiga Hardware Reference Manual for detailed
info. No Amiga Hardware Programmer can live without, there is no substitute.
dierk "chaos" ohlerich.
Peter McGavin
ch...@wiloyee.shnet.org writes:
>Please follow 100% the timing guidelines layed out in the rom kernal manual,
>or otherwise your code will fail on some older Amigas. THIS IS NO JOKE!
>THIS REALLY HAPPENS! If you hack the hardware, do it, but do it RIGHT!
Good advice...
>To get this work correctly you must disable the kernel interrupts (or
>two tasks are reading the keyboard) and send the handshake pulse (by
>switching a CIA bit for a specified amount of time).
...although personally I think it is unwise to hack the hardware for
keyboard input. An input handler is practically as fast and is
guaranteed to work on foreign keyboards and future Amigas. Even IDCMP
RAWKEY is fast enough for most things. Had I coded my Spectrum
Emulator your way (when only A1000s and A500s existed) then it
wouldn't work on current Amigas.
>To get this work correctly you must disable the kernel interrupts (or
>two tasks are reading the keyboard) and send the handshake pulse (by
>switching a CIA bit for a specified amount of time).
Disabling kernel interrupts is a last resort, IMO.
>Try to get the one and only Amiga Hardware Reference Manual for detailed
>info. No Amiga Hardware Programmer can live without, there is no substitute.
It's a useful book, but it only tells about existing Amigas and
existing standard devices. Really all the RKMs are required for the
full story.
--
Peter McGavin. (p.mc...@irl.cri.nz)
Accolyte
> I havn't yet tried to write an keyboard interrupt, although it should
> be no problem to set up the needed CIA stuff. I usually poll the
> keyboard once each vertical blanking interrupt, assuming that nobody
> can type more then 25 characters per second :-)
Argh! They can! (serious :) ). I've noticed a lot of games that do this,
ie: polling the keyboard each frame, and they miss characters when you
type fast.
The thing is, you might not consistently type 25 characters per second,
but it's dead easy to have such a small delay between just two characters,
or between pressing one character and releasing it - and the result of
course is that characters are dropped :(
-- __ ____ __ __ ____
/ "\ /\/\\__"\ / "\ / "\ /\\__"\
Accolyte/Cydonia / / // / // / // / // / // // ' / Packing Class
(Coder) / /\/ > // / // / // / // // / /__ And Kickin'Arse!
\__/ \_/ \__/ \__/ \/\/ \/ \/\/ \/
John Hendrikx
In a message of 10 Jun 96 Ch...@wiloyee.shnet.org wrote to All:
Cws> I havn't yet tried to write an keyboard interrupt, although it should
Cws> be no problem to set up the needed CIA stuff. I usually poll the
Cws> keyboard once each vertical blanking interrupt, assuming that nobody
Cws> can type more then 25 characters per second :-)
This will fail as soon as your 'routine' supports key-repeat, or qualifier
keys. With key-repeat you need to watch for both up and down keys and keep
track of which ones or up and down. With a slow routine like that you are
bound to miss some 'up' keys. Same goes for the qualifier keys.
Cws> Please follow 100% the timing guidelines layed out in the rom kernal
Cws> manual, or otherwise your code will fail on some older Amigas. THIS IS
Cws> NO JOKE! THIS REALLY HAPPENS! If you hack the hardware, do it, but do
Cws> it RIGHT!
Why not do it at all? Install your own input handler at a high priority and
grab all the keys (and mouse stuff as well) in a completely system friendly
manner. I've got a routine which does exactly this and it needs very little
CPU time (even with the rest of the system active) as it doesn't pass any keys
down the handler chain as long as my screen is the front one (well, except any
keys with right amiga as qualifier to allow for screen switching).
Cws> To get this work correctly you must disable the kernel interrupts (or
Cws> two tasks are reading the keyboard) and send the handshake pulse (by
Cws> switching a CIA bit for a specified amount of time).
The OS can do it for you in numerous ways, ranging from very high level
(Intuition Messages) to very lowlevel (keyboard.device), or something in the
middle (an input handler). If you use an input-handler then even things like
remote keyboards with ParNet will work, and mice connected via the serial port
for example.
Cws> Try to get the one and only Amiga Hardware Reference Manual for
Cws> detailed info. No Amiga Hardware Programmer can live without, there is
Cws> no substitute.
That is if you're really a Hardware Programmer. Probably not, you're probably
a Demo or Game Programmer.
Grtz John
-- Via Xenolink 1.985B5, XenolinkUUCP 1.1