Sharp Users Club - MZ-80B Section - Using a Serial Card

Even though this subject has been covered a number of times in the Magazine, and very ably by John Ibberson Vol. 8 No. 3, I thought, nevertheless, it could do with another airing. The reasons for this decision were a) a batch of 'RS 232' cards have been donated to the club from Sharpsoft and b) I had an inquiry about serial interfacing from a member from Ireland.

It is fortunate that the '80B‘ is blessed with easy means of fitting a serial port, plus a BASIC interpreter to drive it ( SB-6511 - see J.I's article ). Until I received one of the cards from Sharpsoft I had always assumed that there were only two serial cards that could be used on the '80B', both from Sharp; the original MZ-8BIO3, and the MZ-1E24 for the MZ-700 / 800. In this article I will confine myself to the Sharp cards, since we still have to investigate the unknown cards from Sharpsoft ( I hope to report on these in a future article ). I intend to concentrate on the practicalities of connecting-up to the serial card, but before I do that I feel that I should explain a few things about serial data transmission and the term 'RS-232‘.

Most of us, I am sure, will be familiar with parallel data transmission, although we may not have realized it. It is used to send data to Sharp or 'Centronics‘ type printers, using a suitable printer interface card. In both cases the data is sent to the printer in packets of 8 bits ( 1 byte ) at a time using 8 data lines. This is the normal way that data is stored and manipulated inside 8 bit computers, and these data lines appear as standard on the expansion bus of all Sharp computers. In serial data transmission, the data bit are transmitted one after the other, and in order to transmit 1 byte of data it is therefore necessary to start by converting the incoming parallel data from the bus into a serial bit stream. This obviously slows down the transmission of data so why is serial transmission used? One reason is the limited length of cable that can be used with parallel transmission. Early personal computers were developed from main frame terminals, which used serial transmission to link to the main frame computer and to any peripherals such as punch card readers, line printers, teletype units. The Commodore ( spit ) 64 computer used its own special form of serial interface, so one had to purchase printers, disc drives etc. from Commodore. The main advantage of serial transmission, however, is that it allows computers to communicate with each other, and for that a connection and protocol standard needed to be set.

Serial data transmission can be synchronous ( clocked ) or asynchronous ( non-clocked ); the latter has obvious advantages and is far more popular. The rate of data transmission is the number of bits transmitted per unit time. The commonly adopted unit is the 'baud‘, with 1 baud roughly equivalent to 1 bit / second. It should, however, be noted that there is a subtle difference between the bit rate as seen by the computer, and the baud rate present in the transmission medium. This is because additional synchronizing bits are required to recover asynchronously transmitted data. In the case of RS232 11 bits are required to transmit 7 bits of data ( additional bits consist of start, stop and parity ). A line baud rate of 600 thus represents a useful data transfer rate of about 382 bits / second.

Having mentioned the term RS232, I should explain that it is the most widely used method of serial communication between microcomputers and peripherals, and is the interface defined in the Electronics Industries Association ( EIA ) standard for the connection of Data Terminal Equipment ( DTE ) and Data Communication Equipment ( DCE ). For most purposes, DTE and DCE mean computer and peripheral respectively; but the distinction is not always clear as, for example, when two microcomputers are linked together via RS232. In general, the DTE and DCE in an RS232 system can be physically separated by up to 20m.

An RS232 system may be configured for a variety of operating modes; this makes it versatile and adaptable, but also leads to wide variations in interpretation which can, and often do, result in bewildering anomalies in the connection and control protocols of practical RS232 systems. An RS232 interface is usually distinguishable by its connector - a 25-way 'D' connector. DCE equipment normally has a female connector, while DTE equipment has a male connector. In practice, few RS232 systems on PC‘s make use of all the signal lines; indeed many arrangements use only 9 lines ( including the protective ground and signal return ). The most common microcomputer RS232 interface involves 7 signal lines and two grounds. These use pins 1 to 8 and 20 of the 25-way ‘D‘ connector and their functions, at the computer end of the interface, are as follows:

Since an effective serial port for microcomputers can manage by using only these connections, several manufactures took the logical step of using a physically smaller connector and most adopted the 9-way ‘D‘ connector. Unfortunately, a standard pinout was not adopted for this connector until IBM used it on their AT computers. Quite sensibly, Sharp used the 9-way connector for their serial interface cards, this way they could fit two serial ports onto one card, but as you might guess, they adopted their own pinout. They further compounded the situation by allowing each port to be configured as either a DTE or a DCE: the pin designations of each are the same but the signal directions are opposite. This means that to connect a DTE to DCE all that is required is to use a straight cable, i.e. pin 1 to pin 1, pin 2 to pin 2 etc. But to connect a DTE to a DTE a ‘crossed' cable is required so that the appropriate input from one device is connected to the appropriate output of the other device and vice versa. As we have said, a computer is a DTE and a Modem is a DCE so the ‘crossed‘ cable is referred to as a ‘null-modem‘ cable. And because different manufacturers implement different control signals, particularly with regard to printers, there is not a standard cable that can be guaranteed to work in all situations. As I have already said, Sharp had the foresight to provide the option of configuring their serial ports as DTE or DCE; the problem is knowing how the configuration should be set. It is not helped by the terminology Sharp use for each configuration, viz.‘Terminal Mode‘ and ‘Modem Mode', and in each mode Sharp changed the labeling of each pin. On a normal modem a pin label shows the connections to make to a DTE‚ and not its function. Sharp provide cables for each situation but not everyone will have these cables so I hope the following information will enable appropriate cables to be made up:-

1. Terminal mode is equivalent to DTE so make up a cable as follows for the various devices:

2. Modem mode is equivalent to DCE so make up a cable as follows for the various devices:

From the above I would suggest that only one cable needs to be made up in accordance with 1a above; then either use one channel and switch modes as appropriate, or use both channels, set each to a different mode, and then switch channels as appropriate.

Serial RS232 data is transmitted asynchronously ( i.e. it is not clocked ) and each data word represents a single ASCII character. Most systems provide for seven data bits although some may be configured for any number of bits between five and eight. The number of stop bits may also range between 1, 1.5, and 2. Parity may be even, odd or disabled.

You now have all the information to enable you to setup and make connections to your Sharp serial interface cards; and even if you do not possess a modem you can have fun by connecting to the serial port of another computer, providing of course you have suitable communications software running on the other machine. In fact the first Sharp computer I bought was an MZ-700, for which I soon purchased a Mills-Harris EPROM board which also contained a serial interface and some rudimentary software. The fun was in connecting it up to my BBC computer and then writing comms software on both machines so that I could transfer machine code programs from the '700' into the BEEB, and then transfer the code onto EPROMs, using an EPROM blower connected to the BEEB. ( Maybe if Paul Trainer asks me nicely I can write an article? - although I feel the subject might be of limited interest, in view of the small number of people who have EPROM boards).