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.