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.