Implementation of fast file transfers between microcomputers and the Computer Centre Network Exchange

Cose 460

Honours project report.

Department of Computer Science. Unh,ersity

of

Canterbury.

lmP.lementation of Fast File Transfers between Microcoml,!uten and the C:omP-uter Centre Network EHchonge.

Mtuk

Cnmness

October 1984

~

Contents

I ntrocluc t ion

2 Fi le transfer 4

3 Tool for writing transfer programs. ... 8

3. l Macros . . .. . .. ... . .. . ... ... ... . ... .. ... . .. . ... .. . .. ... . .. . .. . .. . .. . .. . .. . .. ... . . 9

3.2 Pseudo Pascal... 12

4 Two implementations ... l 3 4. 1 App I

e

I I . .. .. .. .. .. . .. .. .. . .. .. .. . .. .. .. . .. .. . .. .. . .. . .. .. .. . .. .. .. .. .. .. .. .. .. . .. .. .. .. . .. . I 4 4.2 BBC ... 16

5 The BBC network ... :... 18

6 lnterf acing BBC network to CCTR network ... 21

7 Conclusions ... 24

References ... 25

Appendices ... 26 A: Pseu(Jo Pascal algorithm for file transfer.

B: Structure diagram for file transfer.

1

'Lntrodmttou

The purpose of this project is to Investigate methods for

fast file transfer between rn1crocornputers and the computer

centre (CCTR) network at the University of Canterbur'y, to ease

the process of writing file transfer programs for new

microcomputers, and also an investigation of the possible

interfacing of the Geography departments BBC networl< to the CCTR

network.

5oeed or ex1st1ng

transfer

orograros

It was found that in many implementations of file transfer

procedures on micros, the maximum obtainable speed was about

40 characters per second (approx. 36% of the capacity of a 1200

baud line), and that U1e speed of the micro seemed to be the

bottleneck. ,

A transfer program wri ten by John Roper-L 1ndsay of the

Computer Centre, to run on the Apple I I computer showed that the

speed of disk access on the microcomputer combined with the

overhead of using an Interpretive language (Basic) for the

Implementation of the programs was the problem.

Some methods needed to be found to speed up the transfer

rate. Hie obvious methods are to Increase disk buff er Ing to

eleviate the d1sl< transfer problem, and to use mact1lne code rather

than an interpreter for the implementation language.

1

Unfortunately, many micro computers do not have compiled languages available for them, and so assembly language must be used instead.

Easing the process of writing transfer programs

At present, writing file transfer programs is made more difficult than it could be, because the structure and design of the programs are left for the user to decide, despite the basic form of all implementations being the same.

This project investigates two ways in which the micro user can be helped with the writing of these programs:

I) The use of macros to generate a file transfer program automatically.

2) The provision of a pseudo coded transfer program to help the user build their own programs.

Implementation for Apple and BBC computers

In order to demonstrate that the transfer rate can be increased, an inplementation of file transfer to any one of the exchange machines was done, on the Apple //, which was then ported to the BBC microcomputer. This prograrn utilised assembler code and large disk buffering, and is describecl in section 4.

A network of BBC computers

2

ftl.e Transfer

There are many methods of file transfer between computers.

Two examples are given here: llie simple method used in the DSIR

network wl,lch can only transfer text files, and a user transparent

file transfer on a network of computers, Pr1menet be1ng an

example.

DSIR F11e transfer

The user uses an H-11, which Is a LSl-11 based

micro computer, as an Intelligent terminal to a host

computer. To transfer a file, the user prepares to

create a file by running an editor and entering text

Input mode. He then instructs 1,1s terminal to Inject

the contents of a local file 1nto the input stream for

the host computer. The user then exits from input

mode of the editor and saves the f i 1 e tl,us entered.

Network Fi le Transfers

These transfers take place within the network

when a user references a remote file, that ls, one not

present on local disks, but on the disks of another

computer on the net.worl<. The user is not. explicitly

aware of the transfers, and can consider the f11e to be

local for most purposes. Pieces of the file are

The simple DSIR method above, has disadvantages : Its a Very clumsy way of transfer, and there is no error checking on data sent/received.

whereas the latter, much more comp lex, method l1as al I tl1e error checking and correcting capabilities of the network protocol involved.

At the University of Canterbury, we have a situation which is in between these two. The user Is aware of the transfer, much as for the DSIR, but provision. for simple error checking is provided , a desirable feature, as any errors in say numeric data, cannot be tolerated.

File transfer at Canterbuty University.

File transfer at Canterbury University is done via the Computer Centre exchange network. The user attachs his micro to an exchange terminal connection, and then runs a program on his micro to transfer the file

When the file has been completely transfered a trailer message is sent to close the file, and then an abort message is sent to ,~econfigure the connection back to a terminal port.

This higr, level message exchange (with block check characters and sequence numbers for error checking) is possible because the falcons (being small PDP- I Is) are 'intelligent'

Again, (as for the DSI~~ network), only text files can be

transrn

it tecJ.

As noted before, File transfer at Canterbury had a problem with low speecl. On a 1200 baucl connection, which has a maximum throughput of 1 Io chars/sec ( 1 start, 8 data and 2 stop bi ts) U'le rate attained in practice is 40 to 50 chars/sec.

Substantial improvements are possible, as is demonstrated by the following example.

A friend l1ad written a simple bibliographic search program (in Basic) that. searched a 25KB file for a single key occurring in document references. The program took 5 minutes to run, so he altered tl1e logic to give more disk buffering (read in the entire file, then process it) and the time was reduced to 2 minutes, still considered to be too slow.

3

Toots for

the

t-vri.ti..n9 ...

n.f

tran;sf.er P-ro9n:uns

For reasons of efficiency, it is (Jesirable that file transfer programs be written in rnachine code, ie their source code must be assembler or· a compiled language.

Many microcomputers do not have com pi led languages available for tt1ern, and so the use of assembler is mandatory if speed is required. However, large assembler prograrns are diff icull. to write and debug. For this reason this project exarnined two methods to ease tt,e process of writing these programs.

I) The use of macros lo generate a program for the user's particular machine.

_ 3. I Macro

The macro approach is to use a macro language to allow automatic generation of file transfer programs. This method initially looked very attractive, as it entailed the least amount of work for the micro user. What would have been required is the writing of the file transfer software in a 'general', pseudo assembly code (coded in a macro language) which ran on a machine with a 'general' arch.itecture. The assumed architecture of the machine would be of

a

single accumulator, single index register machine with all registers eight bit (This being the lowest common denominator of architectures, and easily emulated on others ).

The micro user (who would have to have a good knowledge of the assembly language for his particular machine) then provides a set of macro definitions to il)lp lement each of the pseudo codes.

Some example macros are given below fot"' three machines:

6502 code

zao

code

32 I

sto_at <addr> STA <addr>

LO (<addr>),A

st index <addr> STA <addr>,Y

LO HL,<addr>

ADD HL, IY

LO (HL), A

atlndlr <addr> LOX

#0

LO HL,(<addr>)

STA (<addr>,X) LO (HL), A

Where the register allocations are:

Acc. : Index:

6502

Z80

A reg.

Y

reg.

A reg. IY reg.

code

STH O,<addr>

STH 0, <addr>, 1

STH O,<addr>,*

These macro clefinitions would be input, along with the file transfer software, to a macro processor probably running on the Prime, to give the resulting assembly code for the target machine.

This sequence is shown be I ow by t11e use a T di agrnm :

l•,tliJ fj H

And a n

~

\ t···l"1,:,ro do:fh. fN· ps,;,ud,:, ood0

is o rnach inti }::

\·Vhi ch can on 1

!J

nm

p1·09rarns

\·V i-i l

t

1::J n i n ):: 1 ., i ts rn a

c:

hi n e code.

Fi10 tr·.:1nsfi?r

However, thls method has several lmportant disadvantages :

The end result would be 1000-2000 I ines of uninte l I igib le glbberish which tl1e user w i I l have to type into the target mlcro, without errors, and assemble.

2) The llkelyhood of the resultlng program actually worklng w l thout bugs, or working at al 1, would seem remote, because of the many intermedlate steps to produce the final program.

If the program does not work, debugging would be very di ff icul t.

4) The mlcro user stlll has to provide routines to read and write from/to the RS232 port on board the m lcro, and provlde a routine to read/write data from/to disk (In large blocks, for reasons mentioned earlier).

3.2 Pseudo Pascal

This method is to provide trie micro user with a description of the file transfer program.

At present the protocol for message exchange between the falcon and micro is flow charted for the user in a document by Alan Causer, however in implementation the algorithm is changed slightly to al low recovery from mis typed usercodes or passwords

The implementation of the protoco I routines, and other areas of the file transfer program such as disk buffering, the user interface, and ini t ia 1 ly setting up the communications path, are left to the user. Which could·have the effect of him independently making everybody else's mistakes all over again.

For myself, considerable study of the existing programs for the Apple was needed before attempting to write a new version.

--4 Two

tmP-km~ntatwns

An assembler version of file transfer to

any

of the exchange mainframes was implemented, on the Apple//, and then ported to

4.1 Apple//

Thls was the first machine that file transfer was implement on, as I had had more experience with Apples than with any other micro.

The use of assembler was essentlal to gain any speed, the questlon being, what sections of the transfer program should be written in assembler.

Experience had shown that the reading from disk, of file data, and buffering should be done in machine code. Also that the provided Disk Operating System (DOS) cal ls for f I le 10 were inefficlent. So It was decided to use special routlnes to read text fi Jes, at sector I eve 1, off of the disk. These I had already written for the bibliographic search program I mentioned above.

It seemed probable that the sending and receiving of messages to/from the excliange would requlre the use of assembler.

Thls left little to decide upon except the user interface routines, and initialization code. Because most of the code was to be written in assembler, It was decided to write all of the transfer program ln assembler, as this would avoid the use of the Basic language.

before finally coding in assembler.

The implemention was done on the Zoology dept's Apples, largely after hours as the Apples were heavily used during the day. The assembler used was 'Big Mac·, a combined macro assembler/ editor.

It was anticipated that the program would be difficult to debug, so I built a simple break point routine to enable program execution to continue after a BRK instruction (by restoring the registers and the stack pointer) to rnake debugging easier. Even so, the time taken to fully debug tl1e first program was considerably more than expected, approximately 4 weeks.

The operation of this program is described in appendix C below. It consists of approximately 1100 lines of assembler which produces 2·4 KB of machine code.

Measurement showed the speed of the program to be about 70 characters per second over a 1200 baud line, 50% faster tl1an the previously available version, but still be low the theoretical maximum of I IO chars per second.

Before trying to speed the program up, It had to be known were it was spending its time (and whether it could be sped up at all). To do tl1is tracing was added to the program. As the file transfer' progressed, U-1e Apple contlnualy 'says' what It ls doing: either sending to or receiving from the exchange, doing internal processing, or reading from disk into memory. It does this by highlighting on of the letters 'S RD A' on the second line of the display.

This tracing revealed that almost all of the time was spent either actively sending a message, or waiting for the network to respond to a message ( ie for the message to reach the Prime/Burroughs and for a reply to be sent back) and that the time spent in internal processing was so small that it didn't even register on the screen. The time spent on disk 10 was also very small, being about 1 ·5 seconds every 60 seconds.

The transfer rate was found to be limited by the speed of the line ( 1200 buad) and by the time taken to elicit a response from the host computer.

4.2 BBC Implementation

The BBC has the same 11 Processor as the Apple I I, so It seemed a good idea to modify the Apple program rather than write

a

new one from scratch. The manner in which the Apple program was written made this very easy.

First the transfer program had to be physically ported to the BBC. To do this two programs were written, one on the Apple, one on U)e BBC. The Apple progrnm sent the source text file one line at a time, and received acknowledgements as the BBC processed them. Basic line nurnbers were pref lxed to eact1 l lne. This transfer took a very long time because of the very slow access times for the text file on the Apple (approx. 3 minutes).

BBC is built into the Basic).

The structurecl design of the program meant that all that was required to complete the port, was to replace the following routines, (see the BBC listings for details), witl1 BBC specific code

fault: reads from file to memory, op_bbc: opens micro file,

set_bbc : sets up file variables, say : (uses screen addressing), receive : gets a char. from R5232 port, wai tout : gets a char. with timeout,

send : send char. to RS232 port, init6850: sets up RS232 port.

All of the routines except for 'fault' were trivial to write, largely due to the well documented Operating System calls for the BBC. 'Fault' is the routine called when the disk buffer is found to be empty and must be refilled. On the BBC 'fault' required approximately 70 lines of assembler code.

The rest of the code remained unchanged from the Apple implementation, which was about 80% of the total code.

5

The

:BBC Network,

The BBC computer has

a

networking capability, and the machines on wl1ich the file transfer program was written were attached to a network. This network presented an interesting opportunity to study possible means of interconnecting the Computer Centre exchange network and Geography's 'Econet' BBC networl<.

Tbe Eunct1001og or tbe

Networt ..

Tl1e BBC network, 'Econet', ls a Contention bus network. contro 1 of the bus ls distributec1 among the BBC micros connected

to lt.

Each BBC micro has on board, for the purpose of 1nterfac1ng to the network, a Motorola MC6854 Advanced Data Link Control (ADLC) ch1p. This ch1p can handle t11e transm lsslon and reception of HDLC and SDLC frames. The frame format used 1n the BBC Econet is almost that of an HDLC frame ; the control field is mlss1ng. The format of tr)e frames used 1s :

When any micro on the network starts to send a frame, interrupts occur in all other micros, signaling that a frame is arriving (the flag byte causes the first interrupt). All micros read the destination field of the frame, and if they recognise their station number they will collect the rest of the frame. If they do not recognise their numbers, they w i 11 disable interrupts from the network for the rest of the frame so as to ignore it. (Note that the act of receiving a frame does not preclude the processor doing other things, because it is interrupt driven).

Transmission of data around the network is effected by a 'four way handshake' protocol, consisting of the following steps:

l) We send a 'scout' frame to see if the destination micro Is 1 istening for messages

2) If the destination is listening, ie has an active .receive buff er specifying the correct port, then it

responds with an acknow 1 edge frame.

3) We then send data, wl1ich can be of variable length. 4) if received correctly (the CRC will trap most errors)

The main use of the Econet network is to provlde BBC computers attached to the network, with shared access to printers, disk drives and the like.

This is done by providing in each machine, a Network Fileing system ROM. All calls for file access (open, read, write) are routed through this ROM routines which convey the requests to a single BBC nominated as the file server. This BBC has disk drives attached, and will allow remote access to files by the requesting BBC m lcro. All file 10 and requests across the network use the four' way protocol out l lned above.

Current resource servers on the Geography network are : 1) The file server, which is a dedicated machine.

11

lntru:Jacing

1t8Cs

tiQ

the

ccm.

network,.

There are three ways in which the BBC network can be usefully interfaced to the Computer Centre network :

Option one.

A 1 ine from the CCTR network Is connected to one of the BBC micros and a small assembler program exists as a background ( Interrupt driven) process In that rn lcro. Any QIN of the other BBCs

attached to the Econet network can run a f lie transfer program, with all communication to the exchange going through the Econet, and through the BBC with tt1e exchange connection.

This would be easy to do, and would entail altering the 'send' and 'receive' routine of the transfer program to use Econet rather than the RS232 port. The function of the sma 11 assembler program is to collect entire messages from the CCTR network, and send them to the BBC running the file transfer program.

Alternately, the Geography department have bought for some of there BBCs, 'sideways· (bank switched) RAM. This RAM exists, in the BBC address space, at the same addresses as the f i 1 ing system and language ROMS. The program could be placed in a part of this RAM and would not interfer at all with normal operation of the host BBC.

Ootlon two.

A BBC on the Econet network would be designated as a dedicated file transfer rn ic'.o, and have a connect ion to the CCTR exchange. To transfer a file from/to the CCTR network a user sends a request to tl,e transfer BBC, specifying filename etc. The request would be queued until the transfer BBC was free, and then the transfer done. The user would be notified when the transfer was complete.

QQ.t_ion three.

A (much) more ambitious method would be to turn the Econet network into a (part time) terminal cluster. One of the BBCs would take on part of tl1e functions of a falcon, that is, the

x·2s

protocol used to communicate with the exchange. Other functions of the falcon could be distributed around the BBC network, for example, line editing would reside within the BBC which was being used as a terminal, as well as the CHEF virtual terminal support. The Econet network would correspond to the rnultlplexor of the present falcon arrangement. The us~ of a BBC micro as a terminal would not interfer with the normal operation of the Econet network.

-1

Cont::fu.stons

The speed of file transfer can be sped up at the expense of program deve loprnent and debugging t irne.

Since the CCTR exchange was found to be the bottleneck, the use of assembly code to speed up the transfer is not compulsory; If a compiler exists for any language on the micro, then it could be used instead.

The single most inportant method to speed up the transfer, is to have a degree of disk buffering, typically rnore than ll<B or buff er space would be required.

The bottleneck on the exchange is caused because usually only one message to a host mainframe can be outstanding at any one time if the errnr checking is to be used. This could be alleviated by not waiting t'or the mainframe to reply to the last. message sent before sending tt)e next message. Thus messages sent would always be one ahead of replies for them. Alternately, the transfer protocol could· be changed to allow a window size of two or more, rather than one.

< )

(I] The advanced user quide for the BBC micro. Bray, Dickens, and Holmes.

(2] Leve 1 two file server advanced user qui de. BBC computer inc.

[3] BBC microcomputer system Disk system user qui de. Brian Ware!.

[4] Apple// DOS listings. Steven Gunn.

.

(5] File Transfer Protocols on the Exchange. Alan Causer

CCTR.

A: Pseudo Pase a I code for file transfer program. B: Structure diagrams for file transfer program.

Program

to_exchange;

const

var

a_large_number = 16*256+ 1; (* typical size of buff er*)

er= chr( 13) (* er delimits lines in input file*) sp = chr(32)

abort

=

$0 I ack = $07

retry= $OE data= $19 request

=

$ I C header= $1 F

(* message types for exchange (hex ) *)

seq: integer (* sequence number, 16 bits*)

text: packed array[O .. 127] of char;(* stores current l lne *) mess_type: byte (* message type*)

bee: byte (* block check char*)

maxrcsiz: byte(* maximum chars to a line*)

txtcount: integer (* stores length of line being sent*) buff er: packed array (0 .. a_large_number] of bytes; buff er_index: integer;

eof: boolean; (* if eof reached yet*) eoln: boolean; (* J'eturn seen in data yet*) micro_file_length: integer;(* how much file to go*)

mainframe: char'; (* stores which computer we are sending to*)

: function receive: byte; (* get char from RS232 port*)

begin (* user must supply this*) end

procedure send( ch : byte ); (* send char to RS232 port*)

begin (* user must supply this*) end

function nxt_disk (* get a single byte off of disk*) var

length : integer;

procedure read_from_f i le( length, buffer); begin (* this routine is system specific*)

(* it must read lengt11 bytes into buffer*) end; (* length may be zero*)

begin

(* user must supply this*)

(* it should employ a factor of buffering to speed up disk access*) (* typically it looks like this:*)

buff er _index:= buffer _Index + 1;

if buff er _index>= a._large_number then begin (*'Fault'*)

buff er _index:"" O;

length:= MIN( a_large __ nur0ber, rn icro_f i le_length ); micro_file_length:=

* -

length;

read_from_f i le( length, buff er );

buff er[ length J := O (* marks end of file*) end;

nxt_disk := buffer[ buff er _index ); end;(* of nxt_disk *)

procedure open Ii ne;

(* to ensure that the exchange is talking to us*) begin

send( ctrLx ); (* a control x *) wait( I second);

if receive <> "?" then begin

send( ctrLx ); wait( 1 second );

if receive<>"?" then (* exchange is not talking*) HALT; end;

procedure filein; label 99; var

ch: char;

message : string;

(* send

a

filein message*) begin

99: write In( 'To the prime or burroughs (P/B)' ); readln( mainframe );

case mainframe of

'P': message:= 'PFILEIN'; 'B' : message:= 'BF I LE IN'; otherwise GOTO 99 end·

'

for I:= 1 to 7 do begin

send( message[ I ] );

ch:= receive (* get e~ho *)

end·

,

send( er); ch:= receive;

ch:= receive; (* get LF

at

end*) end·

,

procedure mess_send;

(* send message_type, seq, text, txtcount etc.*) var

i : integer; begin

send( mess_type ); send( txtcount );

send( seq MOD 256 ); (* low order byte*) send( seq DIV 256 ); (* high order*) for i:= I to txtcount do

send( text[ I ] );

(* BCC is last char of text array*) end;(* mess_.send *)

(* for other routines the user should look at other file transfer programs*) (* see Jim Greens lade of the computer centre, who has the listings*)

begin (* main body of program*)

introduction; (* tell user about tt1e program*) initialize the R5232 port;(* machine specific*)

(*

=====================

*)

repeat

(* repeat until got header message thru *)

open I ine; fi Jein;

ch l := receive; ch2:= receive;

if (ch 1 <> 'D') or (ch2 <> 'O') then(* not done*) HALT; ch:= receive; ch:= receive; (·~get 'NE' *)

get_usercode( ucode ); (* query user and store answers*)

get_password(

passwd );

~ '

get_fi lename( network_f i lename ); get_ma~char_l ine( maxrcsiz );

text:= "NNSCS(" + ucode + ")" + passwd + sp +

network_fi Jename + sp + Characters( maxrcsiz ) + "CHAR";

if mainframe = 'B' then

begin

text[ 1 ):="A"; text[ 3 ]:= "N"; end· I

txtcount:= length_of( text ); seq:= O;

mess_type:= header;

repeat

mess_send; ch:= receive until ch<> retry;

get_micro_f i lname( m_f i lename );

write In( 'insert correct disk and press ret.' ); readln;

open( m_filename );(* open micro file for input*)

set_up_f i Je_vars; (*buff er index:= a_Jarge_number+ 1 *)

(*file length:= ?? *)

eof:= false;

mess_type:= data

(*=========================~====

*)

repeat

(* ... unti 1 ( eof ) *)

seq:= seq + 1;

bee:= data+(seq rnod 256)+(seq div 256);

_.

txtcount:= O;

eoln:= false;

repeat

(* collect chars off disk and assemble message*)

ch:- nxt_disk; (* get a single char from buff er*) case ch of

O: begin

end;

eof:= true; eoln:= true;

rness_type:= trailer

er: eoln:= true;

otherwise begin (* it is a character*) text[ txtcount ]:= ch;

bee:= bee + ch; (* mod 256 *) txtcount:=

*

+ l;

if txtcount <= maxrcsiz then eoln:= true;

end; end; (*case*)

txtcount:=

*

+ I;

bee:= bee + txtcount;

text[ txtcount ]:= bee; (* last char is BCC *)

repeat (* we now have a line to send*)

if mess_type

>=

clata then

mess_send

else

send( mess_type ); . ch:= receive;

until (ch <> reply);

case ch of

ack : ; (* nothing*)

abort:(* exchange aborted transfer*) HALT;

otherwise ERROR

end; (*case*)

unt i1 ( eof );

send( abort); (* close the line·*)

success!!; (* say yay! and give summary, close files*)

...

I

T

I

I

C

f<epefJ:Lv.dJ (

eofl

J

r . - - _ _ . _ _ _ _

e0f

-;=

False

ser~~

-*"+l>'

emp+j tne..utt9c.

C

Repe,,..t, --

u.11-l-,l

eoln.

~ )

1

l

s enJ.

e-.,..-,

-· o..b

cd

f

o

e,e,A_

- " I,,

.) a..!1

S\Lae.s s.

close

F·/e.

~--fl,

eped ...

1LAfi (

repl'!J

-:f:-!fil!:,

cas(

~Pj

of::.

\ ~Read

cA

11

co.se

_cfa

ae.t .

.:.; /'e

pl

1!J

-____. 1') HAL,

~f

e

of::::. eoft1 -:~ tru.e· 1 ,·

tnessa..9e--::: /r.ttj

lijpe

seriJ.

f

u..11

se;1v< (

gpe

~1ve. ,r1e..SS'~5e

Hid

1

exdv.~e

a.ho.~f-ed.

~;ivr:J,i

to/'j

_~ 'Lnstn.wtt.ons for

A12J'illLLI

and BBC

file

transfn

Apple// : To run the· program: 'RUN TONET'.

BBC : To run the program: '*TONET' or '*RUN TONET'.

The functioning of the program is the same on both machines. 1. First a page of text describing the program is displayed.

2. The user is then asked which mainframe the file w i 11 be sent to. 3 .... Then asked for the UFD the file will be created in.

4. ... Then asked for trie password to that UFO. ( the password does not show on the screen).

5. ...Tl1en asked for the filename in the given UFD, to create. 6. ...Then asked for the filename of the micro file to be sent. 7. If the usercode/password is incorrect, then goto step 3. 8. ...Told to place the disk with the file to be sent in the drive.

10 .... The file is then transfered. On the screen are the letlers

·s

RD A' on the Apple, and

·s

RD B' on the BBC.

These stand for S.end, Receive, D.isk, and Apple (B.BC).

As the transfer progresses, the micro indicates what it is doing by highlighting one of these letters, ie.

sending a message to the exchange, (S)

waiting to receive a reply back from exchange, (R) reading from the micros disl< drive (D), or

internal processing (A or B).

Below the

·s

_{R D A' is a 2tream of dots (full stops). For each} sector (group of 256 characters) that are processed, one dot w11l be printed.

1 I. ... When the transfer is cornplete, the message: Fi le '<etc>'

Transfered as '<etc>' <nnn> Records created. appears.