[comp.sys.amiga.programmer] Need a helping hand

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~