[net.micro.amiga] Adding Input Device Handlers

mcclure@osu-eddie.UUCP (James Edward McClure) (09/05/86)

	Has anyone successfully added an input device handler using
   Aztec C.  If you have how did you do it?

	Thanks in advance,

	Jim McClure
	 

daveb@cbmvax.cbm.UUCP (Dave Berezowski) (09/06/86)

In article <2283@osu-eddie.UUCP> mcclure@osu-eddie.UUCP (James Edward McClure) writes:
>
>	Has anyone successfully added an input device handler using
>   Aztec C.  If you have how did you do it?
>
>	Thanks in advance,
>
>	Jim McClure
>	 

	I havn't BUT I have some advice. Remember that if you are writting
a routine that gets called by one of Amiga's routines (such as a printer
driver) that all of the args will be longs. Also, if you compile under
Aztec's small data module, you'll have to set up your own a4 (DataSeg ptr)
on initialization.  I'm not sure if an input device handler falls into
the above category, BUT I thought I'd pass the info along anyway.

	Regards, David Berezowski

jimm@amiga.UUCP (James D. Mackraz) (09/07/86)

In article <705@cbmvax.cbmvax.cbm.UUCP> daveb@cbmvax.UUCP (Dave Berezowski) writes:
>In article <2283@osu-eddie.UUCP> mcclure@osu-eddie.UUCP (James Edward McClure) writes:
>>
>>	Has anyone successfully added an input device handler using
>>   Aztec C.  If you have how did you do it?
>>
>>	Thanks in advance,
>>
>>	Jim McClure
>>	 
>
>	I havn't BUT I have some advice. Remember that if you are writting
>a routine that gets called by one of Amiga's routines (such as a printer
>driver) that all of the args will be longs. Also, if you compile under
>Aztec's small data module, you'll have to set up your own a4 (DataSeg ptr)
>on initialization.  I'm not sure if an input device handler falls into
>the above category, BUT I thought I'd pass the info along anyway.
>
>	Regards, David Berezowski


I don't know why I had trouble setting up A4 when I tried this, so I wrote
code like the system libraries: all "global" data the input handler ever uses
is packed in a structure, the address of which is passed as is_Data in
the interrupt structure you use to add the handler.  Your program gets
that pointer in, ... is it D1?.

Within the handler, make all data references offset from that pointer,
or use local variables on your stack (automatics).
As for code references, I didn't call any functions (got it to come up
and went away), but Jim Goodnow claims that as long as your codes is small
enough, your function calls will end up as pc-relative references (I think
his linker does it), and you will be OK.

Otherwise, you have to get the base pointer in A4, which is described in
his manual (some section about interrupts (tech.notes?)).

I very much like the fact that if you have to set up A4 or move D0 and D1
onto the stack for your C-program you can do it inline with #asm.

You could also go large model.  I like the small data model, and if you
have a program which communicates with your handler via the data in your
structure, be sure to use a semaphore (SignalSemaphore in v1.2) to arbitrate
access to it.  Forbid/Permit isn't polite.  You can also use messages
exclusively, but my application requires that the handler walk through lists
or tables which programs should be able to change.