hoffmann@acl.kodak.com (marty hoffmann) (01/31/91)
I'm trying to write a handler for the input device under 1.3, but I can't seem to get the system to ever call it. I'm using a very old version of the ROM Kernal Manual as a guide, and I've done the following: - created a port - created an io request (giving it the port) - initialized three fields of an Interrupt structure (is_Code, is_Data, and ..._ln_Pri (priority 51)) - opened the input device (giving it the request) - initialized the io request for an ..._ADDHANDLER (the io_Command and io_Data(?) fields) - called DoIO() The code pointed to by is_Code is a little assembler routine which moves the the two arguments (A0 and A1?) onto the stack and then JSR's to my handler written in C. After the call, it adds #8 to A7 and returns (this is just like it shows in my copy of the ROM Kernal manual -- page 3-113 I think). Anyway, the creates, open, and DoIO all return OK status, but it appears that my handler never gets called (the handler simply increments a global variable in the program and returns the event list untouched -- the global variable never appears to change). When my program exits (and tries to cleanup the mess created above) it's GURU city. Am I missing anything obvious? Anything obscure? Thanks in advance, MRH
hoffmann@acl.kodak.com (marty hoffmann) (02/04/91)
I posted a note about trouble I've been having writing
an event handler for the input device. From the number
of replies I've received (0), I conclude:
1) My message never got out
2) It got out, but no one cared :^(
3) No one could figure out what I was talking
about
Anyway, I figured it out (All I had to do was RTFM).
SAS C (and possible Lattice V5.0) doesn't automatically
reload A4 with the base address of your data hunk when
you enter a function (unless you ask it to with the
-y option on the compile).
When the input handler called my handler, I went
and trashed memory in its address space. The solution
was to use "-y". Global variables will be my undoing :^)
While reading the manual, I also found a way to get
rid of the assembly code needed to call my handler.
I just declared it:
struct InputEvent * __interrupt __asm
myhandler (register __a0 struct InputEvent *ev,
register __a1 struct MemEntry *mydata[])
{
...
}
NEAT! Of course, __interrupt doesn't do anything, but
maybe someday...
MRH
markv@kuhub.cc.ukans.edu (02/06/91)
> Anyway, I figured it out (All I had to do was RTFM). > > SAS C (and possible Lattice V5.0) doesn't automatically > reload A4 with the base address of your data hunk when > you enter a function (unless you ask it to with the > -y option on the compile). > When the input handler called my handler, I went > and trashed memory in its address space. The solution > was to use "-y". Global variables will be my undoing :^) You can also do with the __saveds keyword on function definition (but I've had problems with the compiler viewing __savds as mutually exclusive from __asm, __regargs and such ilk). It also supports geta4(); as a function call (which should be the first line in the func). Note that -y/__saveds/geta4() never hurt beyond the CPU cycles to perfrom the fetch. You also need to do such things when using a function as a task. You DONT need to do this for 32 bit abs data (ie __chip, __far, or -b0) since these addresses are fixed at load time and non-context dependant. > While reading the manual, I also found a way to get > rid of the assembly code needed to call my handler. > I just declared it: > > struct InputEvent * __interrupt __asm > myhandler (register __a0 struct InputEvent *ev, > register __a1 struct MemEntry *mydata[]) > { > .... > } Right, but remember that __a4 to __a7 are generally off limits because of the way the Amiga does things (a7 is SP, a6 is used for Library base on system calls, a5 is used for stack frame, and a4 is used for global data base). > NEAT! Of course, __interrupt doesn't do anything, but > maybe someday... Actually, with 5.04 and later it DOES. An __interrupt function will perform a TST.L D0 on exit (D0 is where your return() value goes) so your can code interrupts in C even when the system uses condition codes for return checking (like the VBLANK chain). Now only if SAS would support multiple register returns of different values. Psuedo variables for registers would be nice too (not to mention inline assembly...). > MRH -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~