How compatible the MPC
by Stuart Baker
The Multiperipheral Controller (MPC) is an interface that replaces several existing device controllers. This one board replaces the precision interval clock, line frequency clock, hardware communications assist, line printer interface, loader storage unit, 8-line communications multiplexer or two quad-synchronous adapters. The intent was to design an interface that would function identically to the boards it was replacing.
This article addresses only the 8-line communications multiplexer aspect of the MPC. It compares the standard 8-line communications multiplexer with the RS-232C support of the MPC. The differences between these two interfaces have come to my attention through the school of hard knocks. The information presented is drawn from my experience in writing drivers that must function with these two interfaces.
The first difference, clearly documented I might add, is that you must direct write instructions to the write address, and read instruction to the read address. This is not the case with the 8-line mux, but properly written drivers should have been using these conventions all along. Since writing to the read side allows you to re-program the MPC this difference is easy to accept.
The second difference concerns the issuance of commands to the interface. It is possible to overrun the MPC with too many back to back output commands. Problems resulting from a overrun condition are very insidious and difficult to locate. I feel that this is a very serious problem and should be well documented. An interface that suffers from this type of problem will cause difficult to locate problems as processor speeds increase.
The third difference concerns one of my pet peeves, the clock rate dilemma. One of the 8-line mux design features that I find very irritating is that you must live with pre-defined clock groups. The MPC has redefined these groups (another incompatibility), but still imposes the same lack of flexibility. The groups still do not address the choices needed to handle today's modems. Observe that today's 2400 bps modems support 300, 1200 and 2400 bps. Unfortunately neither interface is flexible enough to allow you to group these speeds the way you need to. The 2400 bps speed is in one group, while 300 and 1200 is another. It looks hopeless, the market place is selling 300/1200/2400 bps modems and CCUR blessed you with a controller which is not in tune with today. If you are going to intentionally vary from the interface that you are copying, then take that opportunity to correct the shortcomings of the original interface! If you don't see fit to allow users the choice of defining the clock groups, at least offer a group of 300/1200/2400/9600 to cover today's modems.
The fourth difference occurs when you select 7-bit, even/odd parity, the default for BIOC DCB39 and ITAM. The MPC returns the most significant bit set to the parity of the received data, not forced to zero. The 8-line mux always returns a zero under the same circumstances. This is a very serious difference, because it affects application programs that should never see any differences between interface controllers! While using the 8-line mux, programs that do image reads receive 7 data bits with the parity bit set to zero. The same program receives 7 data bits with the parity bit defined by the selected parity when you use an MPC. The program fails with an MPC if it does not mask the data to 7-bit before doing data compares. This problem became very apparent at Interchange 86 in San Diego. The LEX demo was intermittently failing. After much head scratching, we discovered that if we were connected to a 8-line mux port, the demo worked. If we were connected to the MPC, the demo failed. The fact that the NTS10 box was selecting the port made this problem very difficult to isolate. The same problem caused the KERMIT demo to fail at Interchange 85.
The fifth difference is a very basic incompatibility. The MPC discards all data it receives if the carrier signal is not present! This is the first RS-232C interface in the entire product line that performs in this manner! This problem became apparent when I was developing the HAYES AT auto dialing driver for the PASSPORT product. I initially developed and tested this driver on both the CCUR and MACROLINK 8-line mux. When one of my customers hooked up a modem to a MPC, he reported that he could not get the modem to dial. It took a trip to the customers site to discover that the driver was not receiving any interrupts when the modem responded. The MPC was discarding all characters sent by the modem. Since carrier is not present until a connection is made, it was difficult to give dialing instructions. At least the MPC allows data transmissions when carrier is not present, so it was possible to create a blind dialing scenario.
This covers the main differences that I have discovered while working with the MPC. There are probably others that will show up in the future. I hope that revealing these differences will simplify the problem solving process for other driver writers that have to contend with the idiosyncrasies of the MPC. In the name of compatibility it would be nice to see these differences removed.
This SBSW.COM page has been optimized for printing.