merlyn@digibd (Brian Westley (Merlyn LeRoy)) (06/16/90)
I am writing a driver for an 8-port mac serial board that my company is making, and in the process I've had to analyze the behavior of the modem port (in order to duplicate it). Since this may be useful to other people, I'll post what I've found. Corrections, additions, and clarifications are encouraged. Hardware flow control is CTS tied to DTR, which is not the usual CTS/RTS handshaking. Not all RS232 mac cables are wired correctly. To change RS422 to RS232, the RX+ pin needs to be tied to ground. Two of my cables (not from Apple) left these floating - it would work plugged into a modem, but not plugged into one of our serial ports. Grounding RX+ fixed it. All flow control is off by default. Most Apple docs say hardware flow control is on, but the Q&A stack says they're lying. Apple's documentation says that incoming breaks can be detected two ways; 1) by having the driver post a break event 2) by having breakRecd (-90) returned by the input driver when it comes in. The first works; the second works ONLY when a read is in progress when the break comes in. Otherwise, it is simply recorded as a null. (a break looks like a null with a framing error). The framing error bit is NOT set by this. The first method is discouraged by Apple; the second works only by accident. Applications that I have tested generally don't recognize breakRecd as a break; they say something like "read error (-90)". Characters with framing (and, I think, hardware overrun) errors are not thrown away, nor are they changed into the parity error special character (if any); they are read in as is (and the error bits are set). This is useful if you are trying to autobaud with software. Not much error checking is done; you can set the input buffer size to -10 (yes, buffer size is signed). If you set the baud rate to 0, it bombs (divide by zero, I assume). I don't think anyone will complain if I return errors instead. No TX buffering is done. Sync writes don't return until all the data is sent. If an XOFF has been sent, and you turn off flow control, the new (not old) XON character is sent. If an XOFF has been sent, and you change the flow control characters, nothing special is done (I would argue that proper behavior is "send old XON character followed by new XOFF character"). The explicit send XON/XOFF commands don't care if flow control is on or not. If you write (not send via control calls) an XOFF character, the driver doesn't set its "XOFF was sent" flag. XOFF is sent/DTR is dropped when the input buffer is 3/4 full. It is turned back on when the buffer is less than 1/4 full. Changing the input buffer tosses any unread characters. The input buffer is changed back to the default 64 byte buffer on a close. RX errors are cleared. Unread characters tossed. If XOFF was sent, an XON is sent. ---- Merlyn LeRoy