Input/Output

To be able to do their jobs, application MFMs need to communicate with the real world. ROBOS provides them with the means of doing this. To an application MFM, ROBOS is the real world. Furthermore it is a real world which can be communicated with by the sending and receiving of messages. And these messages are of a form and in the language familiar to MFMs.

To achieve this, ROBOS includes means of converting raw data from the real world into ROBOS-compatible internal messages. Naturally it also contains means of converting response messages back into the various forms expected at their real-world destinations. These means are called Input Handlers and Output Handlers.

Two Design Options

Two approaches to the design of these Handlers were considered.

The first approach was to write each Handler as a single interrupt-driven 'C' function of the form: 

extern int _far PutMsg(void(_far *)(void _far *), void _far *);

void _interrupt _far xxIH(
  [CPU REGISTERS]                //The input data appears in
  ...............                //specified CPU registers when
  ...............                //the given interrupt occurs.
) {
  struct MSG {                   //input device's message format
    [FIELD]                      //Specify each field of the 
    .......                      //input message type concerned.
    .......
  } _far *msg;                   //ptr to such a message type

  //Provided there's enough free memory for the new message...
  if((msg = (struct msg _far *)_fmalloc(sizeof(struct msg)))
      != NULL) {
    msg->[FIELD] = [REGISTER];   //fill out each field
    ............ = ..........;   
    ............ = ..........;   
    PutMsg(xxMP, msg);           //put the message on 
  }                              //ROBOS's message queue
}
xx is the name of the outside source from which the input has come. Examples are Com1, Com2, Mouse, Keybd. xxIH is the name of the interrupt handler which grabs input from that source. xxMP is the name of the Message Processor MFM which deals with messages received from that source.

This approach is intellectually interesting. However it could be a bit dangerous. One can never be sure how a particular 'C' compiler deals with interrupts. It may suppress some and not others within the body of the function. Furthermore, the execution time for a function like the one above would be rather long for an interrupt handler. For these reasons, this approach was rejected.

The second approach is to write very simple Input and Output Handlers in the host machine's assembler language. Such a Handler would put and get one character at a time respectively to or from its associated memory buffer.

Under this option, Robos's input service would comprise a set of corresponding polling functions. Each of these would empty its associated input buffer on a regular cycle. Robos's output service would be different. It would comprise a set of special MFMs. Each of these would feed its associated output buffer with output data as and when such data were passed to it by message from an application MFM.

This page's parent within this Web Site. About this Web Site. Its home page. Email its Author.