Or Return To On Line Magazine

Thanks to Steven Flintham. They are very detailed instructions on how to make a lead and link two BBCs. Both parts are here.

Linking two computers Part 1

by Steven Flintham (15A)

Introduction

Judging by some of the comments in issue 32, it seems that there is some confusion about how to link two computers together. The easiest way of doing this is to use their serial or RS423 ports. This is also probably the best way, apart from using an Econet which would be considerably more expensive.

The link consists of two parts - the hardware and the software. Note that this article assumes that both machines are Acorn computers - in principle, almost any two machines equipped with RS423 or RS232 ports can be linked, but this introduces extra complications and also reduces the flexibility of the link.

The hardware

The hardware is very simple in principle, consisting of a lead which connects to the socket labelled RS423 on the back of each computer. The lead has to transmit several signals between the two computers, the exact number depending on the nature of the link. The simplest two-way serial link requires only three wires - one for data travelling in each direction and one (called the ground or earth) to complete the electrical circuit.

However, a full RS423 link also provides two extra wires to allow the two computers to control the flow of data. This process is called handshaking and although it can be implemented by sending special signals over the data connection, it is more convienient to provide separate connections. There is the additional advantage that the operating system used by Acorn computers will handle this form of handshaking automatically, while handshaking over the data connections would require extra programming.

If this doesn't make sense, don't worry. You do not need to understand how the link works to make the cable (or buy one) and once the cable has been connected between the computers the operating system takes care of all the intricate details.

The link will therefore need a cable with at least five wires and of sufficient length to reach between the two computers. I have used around 20m of 6-core telephone cable to link my Archimedes and Master together and it seems to work fine. Almost any cable will do, provided it contains sufficient wires. If you plan to use telephone cable, note that most telephone cable sold for home use has only four wires and is therefore not suitable. The cable can be almost any length, although if it is extremely long (50m or more, say) then you may encounter problems.

In addition to the cable you will need two plugs, one for each end of the cable. To be precise, you need two 5-pin C DIN plugs. There are three different 5-pin DIN plugs and only type C (also referred to as domino or 360 degree) will work, so be careful not to get the wrong sort. If they are not labelled, you can recognise them by the pattern of the pins, which is: Now for the worst bit - soldering the plugs onto the cable.

If you consult your User Guide (or Welcome Guide for Master owners) you will find a diagram of the RS423 port somewhere in the appendices. You should wire the lead as follows:
Connect a wire between the CTS pin at one end and the RTS pin at the other Connect a wire between the RTS pin at one end to the CTS pin at the other Connect a wire between 'data in' pin at one end and 'data out' pin at the other Connect a wire between 'data out' pin at one end and 'data in' pin at the other Connect a wire between the 0v pin at one end and the 0v pin at the other.

i.e. link RTS to CTS, data in to data out and 0v to 0v. Note that the data in pin may also be labelled Rx or receive, the data out pin may also be labelled Tx or transmit and the 0v pin may also be labelled ground or earth.

Take care not to misread the diagram - it is probably the view from the back of the plug as you are soldering, not from the front as you look at the pins. Actually, provided you misread it at both ends, it shouldn't matter.

Due to a bit of poor design on someone's part, the plug will actually fit into the RS423 socket either way up and only one of these will work. You should therefore plug the lead into both computers and test it (as described below).

If it doesn't work, try rotating the plug by 180 degrees at either end and test it again. If it still doesn't work, fiddle around futilely for a while and then wearily disassemble the plugs and check the connections.

When you do get it working, I would advise you to mark the top of each plug with Tippex or nail varnish so that you know which way round to put them in the next time. Of course, you can leave the lead permanently connected if you wish, but if the computers are in different rooms and you can't hide the cable then you will have to disconnect it when not in use, making it particularly important that you know which way round to put the cable in - running back and forth between rooms to fiddle with the plugs can be very tiring!

Earlier I mentioned briefly about the possibility of buying a lead, so you might wonder why to go to all the trouble of making one. Firstly, commercial leads tend to be quite expensive. Secondly, they are usually fairly short - 5m or so. This is fine if the computers are next to one another, but if they are a long way apart then this is not much use.

However, if you don't need a long lead and you want to avoid the stress and strain of making your own a commercial lead should be perfectly satisfactory, although you may still need to go through the business of working out which way round the plugs go and marking the tops to indicate this.

Testing the lead

To test the lead, run the accompanying program TestRec on one computer and then run TestSnd on the other (no harm will result if you run TestSnd first, but the test may not work even if the lead if OK). You should see Zarch-style landscapes being produced on both computer screens, albeit rather slowly. The lack of speed is not due to the serial link itself - if you really want to know, it is due to the receive program being deliberately slowed down to make sure the handshaking is tested. TestSnd is a modified version of Duncan Lilly's Zarch landscape generator from issue 26.

If this works then you should try it the other way round, with the computer which was running TestSnd running TestRec and the computer which was running TestRec now running TestSnd. If it works both ways then the link is almost certainly OK.

If it fails to work in either direction then try modifying the lines *FX7,7 and *FX8,7 in both programs to read *FX7,3 and *FX8,3 respectively. This slows down the rate of data transmission and may solve the problem, particularly if you are using a long cable - if it does then you will have to make similar changes in all the examples given and you should also experiment to find the highest value which works reliably. However, this may only solve the problem because it removes the need to use handshaking, so you should check the cable even if slowing down the transmission rate helps as it may indicate incorrect connection of the CTS and RTS pins. On all except the longest cables, *FX7,7 and *FX8,7 should work perfectly.

If this does not help then the link is probably at fault - see the hardware section above for further advice. If you have trouble getting the link to work with *FX7,7 and *FX8,7 and cannot find any problems with the cable, send a 999 message to 8BS giving full details so that myself and other members can see if we can see what's wrong.

Warning

Apparently, some Masters have RS423 hardware which apparently overheats on occasion and sometimes corrupts the bytes passing through the RS423. I have no personal experience of this, but having seen it mentioned in Archive (volume 1, issue 1) I felt that I ought to mention it just in case.

If you are using a Master and the link appears to be faulty for no reason, you might want to try it after the computer has been off for a while or while blowing cold air over the computer with the lid off. If this cures the problem then it strongly suggests that overheating is the cause, but I have no idea how to cure this problem permanently.

Software

I will cover software to use the link in part 2. However, if you want to reassure yourself that the link is not so slow as to be useless, try using the test programs but with line 110 of TestRec deleted. You may also like to experiment with changing the *FX7,7 and *FX8,7 commands to *FX7,8 and *FX8,8 commands - this gives the highest possible speed over the link but is 'not guaranteed' according to the manual although it has always worked reliably for me.

Disclaimer

Note that neither the author nor 8-bit Software can be held responsible for any damage which may be incurred as a result of the instructions contained in this article. The information provided is not guaranteed correct and although we apologise for any time or money wasted as a result of incorrect information no liability can be accepted.

Linking two computers Part 2

by Steven Flintham (15A)

Introduction

The second part of this article covers software to use an RS423 serial link, as described in issue 33. Exactly why you felt it would be useful to link two computers together will determine what sort of software you require, and you may feel that some of the ideas given here are of no use to you.

The general purpose nature of the link means that this is unavoidable - these are just a few suggestions which came to mind. Whatever you want to do with it, the general programming techniques will be the same. All of the examples given use BASIC, but the techniques still apply to other languages.

How to use the link

General points

Any program which will use the link should make sure that the baud rate and data format are set up correctly. This need only be done once, at the start of the program, and could take the form of a procedure:

DEF PROCinit_serial
*FX7,7
*FX8,7
*FX156,86,0
*FX2,2
ENDPROC

The first two lines set the speed at which data is transmitted and received over the link - it is possible to use different speeds in each direction, but this introduces the extra complication of having to set one computer to send at a certain rate and the other to receive at that rate and vice versa. In other words, the situation is no longer symmetrical. Unless you are writing communications software (in which case you should not need to read this article in the first place!), I cannot think of any reason why you should want to do so.

If you carried out the tests described last month, you may have found that your link needs to operate at a slower speed - simply change the *FX7 and *FX8 commands appropriately. This is a good reason to put these commands in their own procedure, since it makes it easy to find and modify them.

The third command sets the data transfer format - for those in the know, it specifies 8 bits, no parity and one stop bit. You should not need to modify this. The last command will prevent any problems with data being missed when receiving - if you are interested, it ensures that any data arriving at the RS423 port will be buffered.

You should also take special care with the error trapping in any program which uses the link. Even if you feel that the program would not otherwise require it, you should have a line of the form ON ERROR PROCerror:END , with PROCerror looking something like this:

DEF PROCerror
*FX2,0
*FX3,0
CLS:REPORT:PRINT " at line ";ERL
ENDPROC

It is the first two lines which are worthy of comment. The first tells the computer to accept input from the keyboard, rather than the RS423 port. The second tells it to output to the screen, once again rather than the RS423 port. You will see why these are necessary when I cover sending and receiving data over the link.

Sending data

To send data over the link, you must select the RS423 port for output using the *FX3,X command. The exact command required varies and several possiblities are given below. After this, anything which would normally go to the screen (e.g. output using PRINT or VDU) will be sent over the link. *FX3,0 should be used when you have finised sending data.

The *FX3,X command required to start sending data depends on whether you require simultaneous output to the screen or printer. Usually you will want neither of these and so you should use *FX3,7. If you want the output to appear on the screen as well, use *FX3,5. If you want output to the printer as well as the RS423 port, use *FX3,11 - no VDU 2 is necessary in this case. Output to all three is selected using *FX3,1 - VDU 2 is required in this case.

This is all rather confusing, and since you can always just send the data over the link and show it on the screen and/or printer using separate commands if required, I would suggest that you stick to *FX3,7.

The nature of the data sent over the link will depend on the receiving program - I will give examples once I have described how to receive data.

Receiving data To receive data from the link, you must select the RS423 port for input using *FX2,1. After this, commands such as GET, GET$, INKEY() (positive values only - INKEY with a negative number will ALWAYS read the keyboard), INKEY$() and INPUT will only accept input from the RS423 port. After receiving data, you can reselect the keyboard with *FX2,2.

If you do not want the received data to be displayed on screen (when using INPUT - this does not affect GET, GET$, INKEY() or INKEY$()) you should use *FX3,6 after *FX2,1 and *FX3,0 after *FX2,2.

Examples Run the accompanying program Rec1 on one computer and the program Send1 on the other. You will be asked for a string (which can be almost anything) by Send1, which will then be sent over the link and printed by Rec1. Having read the above descriptions of sending and receiving, the programs should be self explanatory. Note that if the PRINT string$ line in Send1 had been PRINT string$; then the INPUT statement would never have been completed since no RETURN character would have been sent over the link.

Now try Send2 and Rec2, which demonstate sending a number. The sending and receiving techniques are the same, but you should note that the number is PRINTed in the usual manner and received as a string, after which it is converted to a number using VAL. You could PRINT the number using STR$(number), but there is then a risk of errors being introduced. Note that the setting of @% is important - unless you want to restrict transmitted accuracy, you should avoid setting a fixed number of decimal places. You do not need to worry about this unless you have altered @% yourself.

Send3 and Rec3 show how data can be sent and received without using PRINT and INPUT. Their operation should be fairly obvious, but you should note that although GET is used in Send3, Rec3 can still use GET$ because the keypress is sent using a VDU command, which transmits as a single character. GET could have been used in Rec3, just as both GET and GET$ can be used when reading the keyboard.

These three examples should be sufficient to enable you to experiment with the serial link. Serial links can be unpredictable, so I would advise you to try any ideas out with a couple of quick test programs before writing anything elaborate.

Possible uses for the link

File transfer

Perhaps the most common use for a serial link is in transferring files. If both computers are Acorn machines, this is not always necessary since discs or cassettes can often be physically moved from one machine to another. However, there are several circumstances in which a serial link provides the only convenient solution:

1) The two machines have different disc sizes and it is not possible to take the disc drive from one and connect it to the other as a second drive 2) The two machines use incompatible filing systems and it is not possible to use both filing systems on a single machine. An example of this would be in transferring files from a non-standard DFS on a BBC to ADFS on a Master. 3) One machine has only a tape interface and the other has only a disc interface (e.g. unexpanded BBC B connected to a Master Compact or Archimedes)

If you intend to do a lot of file transfer over the serial link, I would suggest that you obtain something like BBC Kermit (in the TBI pool). However, a simple means of transferring BASIC programs is to type *FX2,1 on the receiving machine and type the following on the other machine:

LOAD "filename" *FX3,5 LIST *FX3,0 (optional - you can press BREAK instead)

The program should appear on the receiving machine as if typed in at the keyboard. When it has finished, you will not be able to type anything in because it is still set up to receive input from the serial port. Press BREAK to regain control and type OLD to recover the program, which can then be SAVEd or RUN as appropriate.

Two machine, two player software

With a little ingenuity, it should be possible to modify or write software for two players, each using a separate machine. I have never done anything like this myself, but I see no reason why it should not work. Obviously, only certain types of game are suitable for this technique.

Advanced printer control

One machine could set up to use a serial printer (either with *FX5,2 or, on a Master, *CONFIGURE PRINT 2) and the other used to run a special program which accepts input from the serial port, processes it and passes it on to a printer connected to its own parallel port. The second computer could alternatively display the incoming data as a hex dump, allowing you to see what codes the printer would be receiving without having to waste paper by using the printer's own hex dump mode.

This technique could also be used to implement a printer buffer, with the second computer using its own memory to store the data ready for the printer. Although sideways RAM would be more convenient, it will not always be available and provided the sideways RAM buffer works on the serial port, using a second computer as well could provide a further increase in buffer size.

A more advanced possibility would be to write a program to analyse the incoming codes and convert them to a form suitable for a non-standard printer. In this way, non-Epson compatible printers could be used with software which requires one and unacceptable codes could be filtered out. For instance, if a daisywheel printer was to be used, underline and bold codes could be converted to the correct commands and other codes (e.g. italic) could either be filtered out or the second computer could request the user to change the daisywheel.

Another possiblity would be to have a printer connected to each computer and write a simple program to print out a text file simultaneously on both, or even to print two separate files at the same time.

I hope that this article will help you to write your own software for the serial link if you so desire. It is just possible that some of the information above is incorrect - if you discover, or think you have discovered, an error please let me know. Equally, if anyone has any further questions or anything they would like further information on, please let me know and I will do my best to help.

Or Return To On Line Magazine