[comp.sys.mac.hypercard] XCMD/XFCN for GetNextEvent

nugteren@pttrnl.nl (01/05/91)

Hi there,

I have written a hardware driver that must communicate with a SuperCard 
project via the Event Queue. To attain this the SuperCard project must
be able to check the Event Queue and read any Application Defined Events 
the driver may have posted there.
I am not very experienced on Mac programming and was wondering if there is
anyone out there willing to give me some tips on how write such a XFCN/XCMD.
Or maybe something like this already exists? 
I would appreciate any tips ( and any sample code would be even better).
I have Think C 4.0 and a low-level debugger (MacsBug/TMON).
Thanks in advance for any help.

Happy New Year,
Nils Nugteren

mandel@vax.anes.tulane.edu (Jeff E Mandel MD MS) (01/08/91)

In article <63768.2784b96f@pttrnl.nl> nugteren@pttrnl.nl writes:
>Hi there,
>
>I have written a hardware driver that must communicate with a SuperCard 
>project via the Event Queue. To attain this the SuperCard project must
>be able to check the Event Queue and read any Application Defined Events 
>the driver may have posted there.

As someone who has written drivers for real-time IO, I can tell you that I
abandoned the technique of using the appevent to post messages from device-time
to event-time. The problem is simply that you cannot predict what will happen
if another App gets a hold of one of your events, since there is no convention
for what the format of the event message is. The better method is to define
your own private event queue which only your code will use. Let us assume that
your messages are 4 bytes long, and you do not expect that there will ever be
more than ten of them queued, you could simply allocate 50 bytes (10 4 byte
slots plus a queue) as a pointer or locked handle, and use Enqueue and Dequeue
(IM vII pp382-3) to insert and remove the messages into your queue. You can
either use the eventQueue convention of overwriting the oldest entry with new
data (faster) or checking for free entries to preserve old data (requires
garbage collection).

Thus, your driver involves the following components:
1) In the Open call, initialize the queue and squirrel it's address away.
2) In whatever code gets the IO data, recover the event queue and add your
   message to the queue.
3) Provide a Control call that removes the qHead message and returns it to you.

Your XCMD only needs one feature (since I assume you already know how to make
your driver open and function) - the ability to issue the Control call to your
driver.

Some quick examples mangled from old MPW ASM code:

Insert into queue from driver:

Export			Procedure		SampleTask,link=debug
		Begin	Save=A1-A3/D3

# Recover your driver's storage Handle
				MOVE.L			(A1),A1
				MOVE.L			dCtlStorage(A1),A0
				MOVE.L			(A0),A2

# Assumes the offset of the next queue entry to be used is in D1. The address
# of the queue entry is in A0

				MOVE.L			myQStorage(A2,D1),A0
				MOVE.L			myDataRegister,(A0)

# put the address of the queue header into A1

				MOVE.L			myQHdr(A2),A1
				_Enqueue
 			Return
				ENDP

Remove queue element and report back:

Export			Function		PrivateQueueService,link=debug
		Begin	Save=A1-A3/D3

				MOVE.L   A0,A3
    MOVE.L			(A1),A1
				MOVE.L			dCtlStorage(A1),A0
				MOVE.L			(A0),A2

				MOVE.L			myQHdr(A2),A1
				MOVE.L			qHead(A1),A0
    If# NE Then.S
      _Dequeue
      MOVE.L   (A0),csParam(A3)
				Else#.S
      CLR.L    csParam(A3)
    EndIf#
    MOVE.L   A3,A0
 			Return
				ENDP

Note that I wrote this originally during the Reagan administration, and my
recollection of it is little better than his for his presidency. Also, I
modified the code somewhat, and so no guarantees that it will assemble as
written. Sorry for the ASM code, but it was what I used for drivers back then,
and besides it builds character. I am posting this to the Net rather than
direct mailing as I think this stuff is fun, and anyone who gets too smug about
their programming abilities should try writing real-time IO drivers to get in
touch with their limitations.

Jeff E Mandel MD MS
Asst. Professor of Anesthesiology
Tulane University School of Medicine
New Orleans, LA

Disclaimer: "Anyone who lets an anesthesiologist teach them how to write
drivers should be equally willing to let a systems programmer give them an
anesthetic"