BBOURBIN@UMDD.BITNET (Brett S Bourbin) (02/16/88)
Does anyone out there have any good examples of using and setting up the
gameport devices in assembly language? I have been trying to use the ones
in the ROM KM but it seems to use heavy "C" support.
I also wrote some code ( with some help from Kodiak's example ) in assembly
to release port 0 from intuitions control, so I can use that port for my
mouse control.
Last question: What is the difference between using a:
DoIo( IO_Message) ;
or using :
SendIO( IO_Message ) ;
WaitPort( MsgPort );
GetMsg( MsgPort );
I thought that the only difference between DoIO and SendIO is that SendIO
returns right away? If this is true than the two examples should do the
same thing. Why would they use the 3 system commands instead of using
DoIO? Am I missing something here?
- Brett Bourbin BITNET: bbourbin@umddrap@ardent.UUCP (Rob Peck) (02/19/88)
In article <8802160312.AA22247@jade.berkeley.edu>, BBOURBIN@UMDD.BITNET (Brett S Bourbin) writes: > Last question: What is the difference between using a: > > DoIo( IO_Message) ; > > or using : > > SendIO( IO_Message ) ; > WaitPort( MsgPort ); > GetMsg( MsgPort ); > DoIO is a synchronous command. Your task sleeps while the I/O is happening. To paraphrase the RKM, DoIO "internally uses" the ReplyPort IF THERE IS ONE, meaning that it sends the I/O message to the device, waits for the reply to be received, and removes the message from the port without your task ever being aware that this has happened. But there does not have to be a ReplyPort specified for the I/O message (if I remember RKM correctly). SendIO is asynchronous. You start the I/O then can go on to do other things. The example given works if and only if the port begin waited on is that which is specified in the mn_ReplyPort. Only when you feel you cannot do anything more until the I/O completes do you need to use WaitPort. If the I/O is done, no wait occurs - the next instruction gets executed right away. In the example provided, it is GetMsg, that removes the message from the port. (If you fail to remove the message, then send it off a second time, it is likely that you will lock up the system - endless loop of linking a list node onto its own tail as I recall). If you provide no ReplyPort in the message when using SendIO, then you can tell that the I/O has completed by using CheckIO(IO_Message). I forget exactly what this function returns, but it effects a polling function on the message. Or use WaitIO(IO_Message) that will put your task to sleep until the I/O finishes. Rob Peck ...ihnp4!hplabs!ardent!rap
dillon@CORY.BERKELEY.EDU (Matt Dillon) (02/19/88)
:DoIO is a synchronous command. Your task sleeps while the I/O is :happening. To paraphrase the RKM, DoIO "internally uses" the :ReplyPort IF THERE IS ONE, meaning that it sends the I/O message to :the device, waits for the reply to be received, and removes the :message from the port without your task ever being aware that this :has happened. But there does not have to be a ReplyPort specified :for the I/O message (if I remember RKM correctly). From looking at the ROM code, DoIO (or more specifically, the device) 'uses' the reply port whether it exists or not. If you *know* the device can handle the command synchronously (i.e. it leaves IOF_QUICK set), then you can get away with it, but in general, you should *always* provide a reply port when using DoIO(). >SendIO is asynchronous. You start the I/O then can go on to do >other things. The example given works if and only if the port >begin waited on is that which is specified in the mn_ReplyPort. >Only when you feel you cannot do anything more >until the I/O completes do you need to use WaitPort. If the If you are waiting for a specific IO request to complete, you should use WaitIO(). If you are using the port to handle the reply from just one message (the iorequest), then you can use WaitPort()/GetMsg(), but many people will use a replyport as an io sink for more than one io request. In that case, WaitPort()/GetMsg() will work, but you then must figure out which request GetMsg() returned by either comparing it to known pending request addresses, or by sticking some kind of ID in the request (I usually use the io_Message.mn_Node.ln_Name field). >If you provide no ReplyPort in the message when using SendIO, then >you can tell that the I/O has completed by using CheckIO(IO_Message). >I forget exactly what this function returns, but it effects a polling >function on the message. Or use WaitIO(IO_Message) that will put >your task to sleep until the I/O finishes. CheckIO(req) returns the request if it is complete, NULL if it is not. You CANNOT use WaitIO(req) if the request does not have a reply port, because WaitIO() uses the signal bit in the reply port to Wait() for something to happen to the request. -Matt