RFC 0809
UCL facsimile system
Pages: 99
Unclassified
Unclassified
Part 2 of 3 – Pages 30 to 59
In order to implement this strategy, each time a
piece of data is required, the size of the buffer
needed is compared with that of the unused buffer area
in the current CSB. If the latter is not less than the
former, the current buffer pointer is returned.
Otherwise, a temporary buffer has to be employed. The
data is copied into the buffer until the requested size
is reached. In this case, instead of a part of the
current buffer, the temporary buffer will be returned.
A 'cswrite' call with the 'need' field set to zero
tells the interface routine that no more data will be
sent. It causes a 'close' CSB to be sent to the
destination routine.
If there is not enough data available, 'csread'
returns zero to indicate the end of data.
4. UCL FACSIMILE SYSTEM
Now we discuss the implementation of the computerised
facsimile system developed in the Department of
Computer Science at UCL.
This system has several components. Since the total
system is a modular and multi-process one, a specific
system must be built up for a specific application. The
way that this is done is discussed in section 4.1. The
specific devices and their drivers are described in
section 4.2. The system can be attached to a number of
networks. In the UCL configuration, the network
interface can be direct to SATNET [22], SERC NET [23],
PSS [24], and the Cambridge Ring. The form of network
connection is discussed further in section 4.3. The
system must transfer data between the facsimile devices
and the disks, and between the networks and the disks.
For this a filing system is required which is discussed
in section 4.4.
A key aspect of the UCL system is flexibility of
devices, networks, and data formats. The flexibility of
device is achieved by the modular nature of the device
drivers (section 4.2). The flexibility of network is
discussed in section 4.8. The additional flexibility of
data structure is described in section 4.5. The
flexibility can be utilised by incorporating conversion
routines as in section 4.6. An important aspect of the
UCL system is the ability to provide local manipulation
facilities for the graphics files. The facilities
implemented for the local manipulation are discussed in
section 4.7. In order to transfer files over the
different networks of section 4.3. a high level data
transmission protocol must be defined. The procedures
used in the UCL system are discussed in section 4.8.
4.1 Multi-Task Structure
The task controller and processing tasks are
implemented as MOS processes. A number of utility
routines are provided for users to build new task
processes and modules at application level.
In the environment of MOS, a process is included in a
system by specifying a Process Control Table when the
system is built up. The macro 'setpcte' is used for
this purpose, the meaning of its parameters being
defined in [14].
#define setpcte(name,entry,pridev,prodev,stklen,
relpid,relopc)
{0,name,entry,pridev,prodev,stklen,relpid,relopc}
A Device Control Table (DCT) has to be specified for
each device when the system is built up. A DCT can be
defined anywhere as devices are referenced by the DCT
address. The macro 'setdcte' is designed to declare
devices, the meanings of its parameters being specified
in [14]. This method is used in the device
descriptions.
#define setdcte(name,intvec,devcsr,devbuf,devinit,
ioinit,intrpt,mate)
{04037,intrpt,0,0,name,mate,intvec,devinit,
devcsr,devbuf,ioinit}
4.2 The Devices
As mentioned in section 2, apart from the general
purpose system console, there are three devices in the
system to support the facsimile service. These are:
(1) AED62 Floppy Disk, which is used as the secondary
memory storing the facsimile image data. Above its
driver, a file system is implemented to manage the
data stored on the disks, so that an image data
file can be accessed through the Clean and Simple
interface. This file system is dicussed in detail
in the next section. For some processing jobs, the
image data has to buffered on a temporary file
lest time-out occurs on the facsimile machine.
(2) DACOM Facsimile Machine, which is used to input
and output image data. It reads an image and
creates the corresponding data stream. On other
hand, it accepts the image data and reproduces the
corresponding image. Above its driver, there is a
interface task to fit the facsimile machine into
the system, the Clean and Simple interface being
supported. The encoding algorithm for the DACOM
machine is described in [19].
(3) Grinnell Colour Display, which is used as the
monitor of the system. Above its driver, an
interface task is implemented so that the image
data in standard format can be accepted through
the Clean and Simple interface.
The detailed description of these devices can be
found in Appendix 1. The interface task and the
description for each device are listed in the following
table. The interface tasks can be directly used as data
source or sink in a task string.
Device Interface Task Description
AED62 Floppy Disk fs() aed62(device)
DACOM fax Machine fax() dacom(device)
Grinnell Display grinnell() grinnell(device)
Note that the DCTs for the facsimile machine and
Grinnell display have been included in the
corresponding interface tasks, so that there is no need
to declare them if these tasks are used.
4.3 The Networks
There are three relevant wide-area networks
terminating in the Department of Computer Science at
the end of 1981. These are:
(1) A British Telecom X25 network (PSS, [24]).
(2) A private X25 network (SERC NET, [23])
(3) A Defence network (ARPANET/SATNET, [21], [22])
In addition there is a Cambridge Ring as a local
network.
For the time being, the UCL facsimile system is
directly attached to the various networks at the point
NI (Network Interface) of Fig. 1.
As mentioned earlier, pictures can be exchanged via
the SATNET/ARPANET, between UCL in London, ISI in Los
Angeles, and COMSAT in Washington D.C.. The Network
Independent File Transfer Protocol (NIFTP, [9]) is used
to transfer the image data. This protocol has been
implemented on LSI under MOS [10]. In addition, we at
UCL have put NIFTP on an ARPANET TOPS-20 host, which
can act as an Internet File Forwader (IFF). In this
case, TCP/IP ([28], [29]) is employed as the underlying
transport service. Since TCP provides reliable
communication channels, the provision of checkpoints
and error-recovery procedures are not included in our
NIFTP implementations.
In the X25 network, the transport procedure is
NITS/X25 ([25], [26]). Though pictures can be
transferred to the X25 networks, no experimental work
has been done, because:
(1) There is at present no collaborative partner on
these networks.
(2) The LSI-11, on which our system is implemented,
has no direct connection to these networks.
Locally, image data can be transmitted to the
PDP11-44s running the UNIX time-sharing operating
system. At present, the SCP ring-driver software uses
permanent virtual circuits (PVCs) to connect the
various computers on the ring.
4.4 File System
A file system has been designed, based on the AED62
double density floppy disk, for use under MOS. It is
itself implemented as a MOS process supporting the
Clean and Simple interface. The description of this
task, fs(fax), can be found in Appendix 2.
In a command string, the file system task can only
serve as either data source or data sink. In other
words, it can only appear at the first or last position
on a command string. In the former case, the file
specified is to be read, while the file is to be
written in the latter case.
Three access modes are allowed which are:
* Read a file
* Create a file
* Append a file
The file name and access mode are specified as the
open parameters.
Let us consider an example. If a document is to be
read on the facsimile machine and the data stream
created is to be stored on the file system, the command
string required is:
fax"r|fs"c,doc
where: fax - interface task for facsimile machine
r - read from facsimile machine
fs - file system task
c - create a new file
doc - the name of the file to be created.
In order to dump a file, a task process od() is
provided which works as a data sink in a command
string.
4.5 Data Structure
Facsimile image data is created using a high-
resolution raster scanner, so that the original picture
can be reproduced faithfully. The facsimile data
represents binary images, in monochrome, with two
levels of intensity, belonging to the data type of
bit-mapped graphics.
The simplest representation is the bit-map itself.
The bits, each of which corresponds to a single picture
element, are arranged in the same order as that in
which the original picture is scanned, 1s standing for
black pixels and 0s for white ones. Operations on the
picture are easily carried out. For example, two images
represented in the bit-map format can be merged
together by using a simple logic OR operation. Any
specific pixel can be retrieved by a simple
calculation. However, its size is usually large because
of the high resolution. This makes it almost
unrealistic for storage or transmission.
Facsimile image data should therefore be compressed
to reduce its redundancy, so that the efficient storage
and transmission can be achieved.
Run-length encoding is a useful compression scheme.
Instead of the pattern, the counts of consecutive black
and white runs are used to represent the image.
Vector representation, in which the run-lengths are
coded as integers or bytes, is a useful internal
representation of images. Not only is it reasonably
compressed, but it is also quite easy for processing.
Chopping, scaling and mask-scanning are examples of the
processing operations which may be performed.
Furthermore, a conversion between different compression
schemes may have to be carried out in such a way that
the data is first decompressed into the vector format
and then recompressed. The difficulty in retrieval can
be overcome by means of line index, which gives the
pointers to each lines of the image.
A higher compression rate leads to a more efficient
transmission. But this is at the expense of ease of
processing. An example of this is the use of Huffman
Code in the CCITT 1-dimensional compression scheme.
While the data can be compressed more efficiently, it
is rather difficult to manipulate the data direcltly.
Taking the correlation between adjacent lines into
account, 2-dimensional compression can achieve an even
higher compression rate. CCITT 2-dimensional
compression and the DACOM facsimile machine use this
method.
It is desirable to integrate facsimile images with
other data types, such as text and geometric graphics;
the structure of these other types must then be
incorporated in the system. At present, only text
structure is available, while the structure for
geometric graphics is a topic for the further study.
In the facsimile system, the following data
structures are supported. The corresponding
descriptions, if any, are listed as well and they can
be found in Appendix 3 (except of dacom(device)).
type structure compression description
bit-map bit-map - -
vector 1D run-length vector(fax)
dacom block 2D run-length dacom(device)
CCITT T4 1D run-length t4(fax)
2D run-length t4(fax)
text text - text(fax)
As an internal data structure, vector format is
widely used for data transfer between task processes.
The set of interface routines has been extended by
introducing two subroutines, namely getl() and putl(),
which read and write line vectors directly through the
Clean and Simple interface. These two routines can be
found in Appendix 3 (getl(fax) and putl(fax))
In order to check the validity of a vector file, a
check task process check() is provided which works as a
data sink in a command string. It can also dump the
vector elements of the specific lines.
4.6 Data Conversion
In order to convert one data structure into another,
several conversion modules are provided in this system.
These modules fall into two categories, task processes
and subroutines. The task processes are MOS processes
which can only be used in the environment described in
this note, while the subroutines which are written in c
and compatible under UNIX are more generally usable.
Character strings or text can be converted into
vector format, so that an integrated image combining
picture and text can be formed.
The following table lists these conversion modules,
including their functions and descriptions (which can
be found in Appendix 3).
module type from to description
decomp process dacom vector decomp(fax)
recomp process vector dacom recomp(fax)
ccitt process vector t4 ccitt(fax)
t4 vector
bitmap subroutine vector bitmap bit-map(fax)
tovec subroutine bitmap vector tovec(fax)
ts subroutine ASCII string vector ts(fax)
string process ASCII string vector string(fax)
tf process text vector tf(fax)
Since each DACOM block contains a Cyclic Redundancy
Check (CRC) field, the system supplies a subroutine
crc() to calculate or check the CRC code. (see
crc(fax))
If a vector file is to be printed on the DACOM
facsimile machine, the image data should be re-
compressed into the DACOM-block format, the required
command string being shown below.
fs"e,pic|recomp|fax"w
where fs - file system task
e - read an existing file
ic - file name
recomp - re-compression task
fax - interface task for facsimile machine
w - print an image on facsimile machine
4.7 Image Manipulation
Four processing task processes are provided in the
system. These are:
(1) Chop, which applies a defined window to the input
image.
(2) Scale, which enlarges or shrinks the input image
to the defined dimensions.
(3) Merge, which puts the input image on the specified
area of a background image.
(4) Clean, which removes the noise on the input image.
The Clean and Simple interfaces are supported in
these processing tasks so that the tasks can be used in
command strings. However, these tasks can be neither
source nor sink in a command string. The data format
of their input and output is vector.
For example, a facsimile page can be cleaned and then
printed on the facsimile machine. Note that the image
data must be recompressed before being sent to the
facsimile machine. If the original data is the form of
DACOM block, it has to be decompressed as the
processing tasks only accept line vectors. The
required command string is shown below.
fs"e,page|clean|recomp|fax"w
where fs - file system task
e - read an existing file
page - file name
clean - cleaning task
recomp - re-compression task
fax - interface task for facsimile machine
w - print an image on facsimile machine
The descriptions of these processing tasks can be
found in Appendix 2 (chop(fax), scale(fax), merge(fax),
and clean(fax)).
In tasks 'chop' and 'merge', a window is set by
giving the coordinates of its vertices. However, it is
usually rather difficult for a human user to decide the
exact coordinates. The system supplies a subroutine
choice() which specifies a rectangular subsection of an
image by interactive manipulations of a rectangular
subsection on the screen of the Grinnell display
displaying the image. It provides a set of interactive
commands whereby a user can intuitively choose an area
he is interested in. Note that this subroutine must be
called by a MOS process and the Grinnell display must
be included in the system.
By means of these image processing modules, the image
editing described in section 2.4 can be carried out.
Let us consider an example. An image abstracted from a
picture 'a' is to be merged onto a specified area of
another picture 'b'. First of all, the two pictures 'a'
and 'b' should be displayed on the left half and right
half of the screen, respectively. Assume that the two
pictures are standard DACOM pages whose dimensions are
1726x1200. They have to be shrunk to fit the dimension
of the half screen (256x512). Note that if the data
format is not vector, conversion should be carried out
first. the required command strings are:
e,a|scale"1726,1200,256,512|grinnell"0,511,255,0,z,g
fs"e,b|scale"1726,1200,256,512|grinnell"256,511,511,0,z,b
where fs - file system task
e - read an existing file
a - file name
b - file name
scale - scale task
1726,1200 - old dimension
256,512 - new dimension
grinnell - grinnell display interface task
0,511,255,0 - presentation area (the left half)
256,511,511,0 - presentation area (the right half)
z - zero write mode
g - green
b - blue
In an application process, the subroutine choice() is
called in the following ways for the user to choose the
areas on both pictures.
choice(r, 1726, 1200, 1, 0, 0);
/* choice the area on 'a' */
/* r - red
1726 - width of the original picture
1200 - height of the original picture
1 - left half of the screen
0 - the subsection can be of any width
0 - the subsection can be of any height
*/
choice(r, 1726, 1200, 2, 0, 0);
/* choice the area on 'b' */
/* r - red
1726 - width of the original picture
1200 - height of the original picture
2 - right half of the screen
0 - the subsection can be of any width
0 - the subsection can be of any height
*/
When the user finishes editing, the coordinates of
the chosen rectangular areas are returned. An example
is given in the table below. The widths and heights
listed in the table are actually calculated from the
coordinates returned and they indicate that the source
image has to be enlarged to fit its destination.
(0, 0)
+-------------------------------> x
|
| (x0, y0) w
| +--------------------+
| ! !
| ! !
| ! ! h
| ! !
| ! !
| +--------------------+
| (x1, y1)
V
y
original x0 y0 x1 y1 w h
a 30 40 100 120 70 80
b 100 100 1100 1100 1000 1000
At this stage, our final goal can be achieved by
performing a job specified below. It is assumed that
the result image is to be stored as a new file 'c'.
fs"e,a|chop"30,40,100,120|scale"70,80,1000,1000
|merge"b,0,100,100,1100,1100|fs"c,c
where fs - file system task
e - read an existing file
a - file name
chop - chop task
30,40,100,120 - the area to be abstracted
scale - scale task
70,80 - old dimension
1000,1000 - new dimension
merge - merge task
b - file name of the background image
0 - to be overlaid
100,100,1100,1100 - the area to be overlaid
fs - file system task
c - create a new file
c - the name of the file to be
created
4.8 Data Transmission
In order to transmit facsimile image data over
computer networks, using the configuration of Fig. 1,
the Network Independent File Transfer Protocol [9] is
implemented as a MOS task process, the Clean and Simple
interface of section 3.3 being supported [10]. Thus
this module can be used in a command string directly.
In this case, the module always works in the initiator
mode, though the server mode is supported as well. Its
description can be found in Appendix 2 (ftp(fax)).
As a network-independent protocol, it employs a
transport service to communicate across the networks.
The Clean and Simple interface is also used for the
communication between the module and transport service
processes.
Suppose that an image file stored in a remote file
system is to be printed on the local facsimile machine.
Assume that the data is transmitted via the ARPANET
[21], Transport Control Protocol (TCP) [28] being used
as the underlying transport service. As was described
before, since the delay caused by the network may
result in a time-out on the local facsimile machine,
the job should be divided into two subjobs.
(1) The remote file is transmitted by using NIFTP
module. However, instead of being put on the
facsimile machine directly, the received data is
store in a temporary file.
ftp"r,b,ucl,fax,pic;tcp:1234,10,3,3,42,4521|fs"c,tmp
where ftp - NIFTP task
t - receive
b - binary
ucl - remote user name
fax - remote password
pic - remote file name
tcp - transport service process
parameters for the transport service:
1234 - local channel number
10,3,3,42 - remote address
4521 - channel reserved for the
remote server
fs - local file system task
c - create a new file
tmp - the name of the file to be created
(2) The temporary file is read and the image is sent
to the facsimile machine for printing. Here it is
assumed the data received is in the form of DACOM
block so that no conversion is needed.
fs"e,tmp|fax"w
where fs - file system task
e - read an existing file
tmp - file name
fax - interface task for facsimile machine
w - print an image on facsimile machine
We are able to exchange image data with ISI and
COMSAT. At present DACOM block is the only format that
can be used as all the three participants in this
experiment possess DACOM facsimile machines and no
other data format is available in both ISI and COMSAT.
However, it is the intention of the ARPA-Facsimile
community to adopt the CCITT standard for future work.
As mentioned earlier, UCL already has this facility.
Above NIFTP, a simple protocol was used to control
the transmission of facsimile data. In this protocol,
the format of a facsimile data file was defined as
follows: Each DACOM block was recorded with a 2-byte
header at the front. This header was composed of a
length-byte indicating the length of the block
(including the header) and a code-byte indicating the
type of the block. This is shown in the following
diagram.
|<--- header ---->|<------ 74 bytes ------->|
+--------+--------+-------------------------+
! length ! code ! DACOM block !
+--------+--------+-------------------------+
The Length-byte is 76 (decimal) for all DACOM blocks.
The code-byte for a setup block is 071 (octal) and 072
for a data block. A special EOP block was used to
indicate the end of a page. This block had only the
header with the length-byte set to 2 and the code-byte
undefined. A facsimile data file could contain several
pages, which were separated by EOP blocks.
5. CONCLUSION
5.1 Summary
Though techniques for facsimile transmission were
invented in 1843, it was not until the recent years
that integration with computer communication systems
gave rise to "great expectation". The system described
in this note incarnates the compatibility and
flexibility of computerised facsimile systems.
In this system, facsimile no longer refers simply to
the transmission device, but rather to the function of
transferring hard copy from one place to another. Not
only does the system allow for more reliable and
accurate document transmission over computer networks
but images can also be manipulated electronically.
Image is converted from one representation format to
another, so that different makes of facsimile machines
can communicate with each other. It is possible for a
picture to be presented on different bit-map devices,
e.g. TV-like screen, as it can be scaled to overcome
the incompatibilities. Moreover, the system provides
windowing and overlaying facilities whereby a
sophisticated editor can be supported.
One of the most important aspects of this system is
that text can be converted into its bit-mapped
representation format and integrated with pictures.
Geometric graphics could also be included in the
system. Thus, the facsimile machine may serve as a
printer for multi-type documents. It is clear that
facsimile will play an important role in future
information processing system.
As far as the system per se is concerned, the
following advantages can be recognised. Though our
discussion is concentrated on the facsimile system,
many features developed here apply equally well to
other information-processing systems.
(1) Flexibility: The user jobs can be easily
organised. The only thing to be done for this
purpose is to make the logical links for the
appropriate task processes.
(2) Simplicity: The interface routines are responsible
for the operations such as signal handling and
buffer management. By avoiding this burden, the
implementation of the task processes becomes very
"clean and simple".
(3) Portability: The interface routines also makes the
task processes totally independent of the
operating environment. Only these routines should
be modified if the environment were changed.
(4) Ease of extension: The power of the system can be
simply and infinitely extended by adding new task
processes.
(5) Distributed Environment: This approach can be
easily extended to a distributed environment,
where limitless hardware and software resources
can be provided.
5.2 Problems
As discussed earlier, the network we were using for
the experimental work was not designed for image data
transmission. The data transfer is so slow that a
time-out may be caused on the facsimile machine. Though
this problem was solved by means of local buffering and
pictures were successfully exchanged over the network,
the slowness is rather disappointing because of the
quantity of image data. The measurement showed that the
throughput was around 500 bits/sec. In other words, it
took at least 5 minutes to transfer a page. This was
caused by the network but not our system. The situation
has been improved recently. However, It is nevertheless
required that more efficient compression schemes be
developed.
At present, the system must be directly attached to
the network to be accessed. However, the network ports
are much demanded, so that frequent reconfiguration is
required.
The facsimile system can be connected only to the
local network, the Cambridge Ring, while the foreign
networks are connected via gateways to the ring. This
is shown in Fig. 12. Now the X25 network is attached to
the Ring via an X25 gateway, XG [25], while SATNET is
connected by another gateway, SG [25]. Both network are
at the transport level; XG and SG support the relevant
transport procedures. In the case of XG, this is
NITS/X25 ([26], [27]); in the case of SATNET, it is
TCP/IP ([28], [29]).
UCL facsimile
system - - - - - - - -
+--------+ / \ +------+
! ! ---- Cambridge Ring ---- ! PE !
+--------+ \ / +------+
- - - - - - - - |
/ \ |
+------+ +------+ |
! XG ! ! SG ! --- SATNET
+------+ +------+
/ \
PSS SERC NET
Fig. 12 Schematic of UCL network connection
When the network software runs in the same machine as
the application software, the Clean and Simple
interface of section 3.5 was used as an interface
between the modules. When the gateway software was
removed to a separate machine, an Inter-Processor Clean
and Simple [30] was required. The appropriate
transport process is transferred to the relevant
gateway, and appropriate facilities are implemented for
addressing the relevant gateway. Otherwise, the
software has to be little altered to cater for the
distributed case.
In our experimental work, the following problems were
also encountered.
(1) The primary memory of the LSI-11 is so small that
we cannot build up a system to include all the
modules we have developed. In order to transfer
an edited picture using the NIFTP module, we have
to first load an editor system to input and
process the picture, and then an NIFTP system is
then loaded to transmit it.
(2) The execution of an image processing procedure
becomes very slow. For example, it takes several
minutes to shrink a picture to fit the screen of
the Grinnell display. This prevents the system
from being widely used in its present form.
(3) As secondary storage, floppy disks are far from
adequate to keep image data files. At present, we
have two double-density floppy disk drives, the
capacity of each disk being about 630K bytes.
However, an image page contains at least 50K bytes
and, sometimes, this number may be doubled for a
rather complex picture. Only a limited number of
pages can be stored.
On the other hand, in our department, we have two
PDP11-44s running UNIX together with large disks
supplying abundant file storage. Their processing speed
is much higher than that of the LSIs. The UNIX file
system supports a very convenient information-
management environment. This inspired the idea that the
UNIX file system could pretend to be a file server
responsible for storing and managing the image data, so
that all the processing tasks may be carried out on
UNIX. Not only does this immediately solve the problems
listed above, but the following additional advantages
immediately accrue.
(1) UNIX provides a far better software-development
environment than LSI MOS ever can or will.
(2) The facsimile service can be enhanced to be able
to support many users at a time.
(3) The UNIX file system is so sophisticated that more
complex data entities can be handled.
In fact the 44s and the LSI-11, to which the
facsimile machine and Grinnell display are attached,
are all connected to the UCL Cambridge Ring. A
distributed processing environment can be built up
where a job in one computer can be initiated by another
and then the job will be carried out by cooperation of
both computers.
In such a distributed system, the LSI-11 micro-
computer, together with the facsimile machine,
constitutes a totally passive facsimile server
controlled by a UNIX user. A page is read on the
facsimile machine and the image data stream produced is
transmitted to the UNIX via the ring. The image data is
stored as a UNIX file and may be processed if
necessary. It can also be sent via the ring to the
facsimile server where it will be reprinted on the
facsimile machine.
In order to build up such a distributed environment,
IPCS [30] is far from adequate for this purpose, as it
does not provide any facility for a remote job to be
organised. In our system, the task controller can be
modified so that the command strings can be supplied
from a remote host on the network. Having accepted the
request, the task controller organises the relevant
task chain and the requested job is executed under its
control. The execution of the distributed job may
require synchronisation between the two computers.
These problems are discussed in detail in [31].
Generally speaking, a distributed system based on a
local network, which supplies cheap, fast, and reliable
communication, could be the ultimate solution of the
operational problems discussed in this section. In such
a system, different system operations are carried out
in the most suitable places.
For the time being, only a procedure-oriented task-
control language is available in this system. The
command string of the fitter can be typed from the
system console directly, the corresponding job being
organised and executed. Theoretically, this is quite
enough to cope with any requirement of a user.
However, when the job is complex, command typing
becomes very tedious and prone to error.
Above the task-controller, a job-controller layer is
required which provides a problem-oriented language
whereby the user can easily put forward his requirement
to the system. On receipt of such a command, the job
controller translates it into a command string of the
task controller and passes the string to the task
controller so that operation request can be done.
Sometimes, one job has to be divided into several
subjobs, which are to be dealt with separately. The
job controller should be also responsible for high
level calculation and management, so that the user need
not be concerned with system details.
In the system supporting facsimile service under
UNIX, a set of high-level command is provided, while
the command strings for the facsimile station are
arranged automatically and they are totally hidden from
a UNIX user.
5.3 Future Study
At the next stage, our attention should be moved to a
higher-level, more sophisticated system which supports
a multi-type environment. In such a system, not only
does the facsimile machine work as an facsimile
input/output device, but it should also play the role
of a printer for the multi-type document. This is
because other data types, e.g. coded character text and
geometric graphics can be easily converted into bit-
mapped graphics format which the facsimile machine is
able to accept.
First of all, a data structure should be designed to
represent multi-type information. In a distributed
environment, such a structure should be understood all
over the system, so that multi-media message can be
exchanged.
In a future system, different services should be
supported, including viewdata, Teletex, facsimile,
graphics, slow-scan TV and speech. The techniques
developed for facsimile will be generalised for use of
other bit-mapped image representations, such as slow-
scan TV.
To improve the performance of the facsimile system,
we are investigating how we could use an auxiliary
special purpose processor to perform some of the image
processing operations. Such a processor will be
essential for the higher data rate involved in slow-
scan TV.
Reference
[1] P. T. Kirstein, "The Role of Facsimile in Business
Communication", INDRA Note 1047, Jan. 1981.
[2] T. Chang, "A Proposed Configuration of the
Facsimile station", INDRA Note 922, May, 1980.
[3] T. Chang, "Data Structure and Procedures for
Facsimile Signal Processing", INDRA Note 923, May,
1980.
[4] S. Treadwell, "On Distorting Facsimile Image",
INDRA Note No 762, June, 1979.
[5] M. G. B. Ismail and R. J. Clarke, "A New Pre-
Processing Techniques for Digital Facsimile
Transmission", Dept. of Electronic Engineering,
University of Technology, Loughborough.
[6] T. Chang, "Mask Scanning Algorithm and Its
Application", INDRA Note 924, June, 1980.
[7] M. Kunt and O. Johnsen, "Block Coding of Graphics:
A Tutorial Review", Proceedings of the IEEE,
special issue on digital encoding of graphics,
Vol. 68, No 7, July, 1980.
[8] T. Chang, "Facsimile Data Compression by
Predictive Encoding", INDRA Note No 978, May.
1980.
[9] High Level Protocol Group, "A Network Independent
File Transfer Protocol", HLP/CP(78)1, alos INWG
Protocol Note 86, Dec. 1978.
[10] T. Chang, "The Implementation of NIFTP on LSI-11",
INDRA Note 1056, Mar. 1981.
[11] T. Chang, "The Design and Implementation of a
Computerised Facsimile System", INDRA Note No.
1184, Apr. 1981.
[12] T. Chang, "The Facsimile Editor", INDRA Note 1085,
Apr. 1981.
[13] K. Jackson, "Facsimile Compression", Project
Report, Dept. of Computer Science, UCL, June,
1981.
[14] R. Cole and S. Treadwell, "MOS User Guide", INDRA
Note 1042, Jan. 1981.
[15] CCITT, "Recommendation T.4, Standardisation of
Group 3 Facsimile Apparatus for Document
Transmission", Geneva, 1980.
[16] "DACOM 6450 Computerfax Transceiver Operator
Instructions", DACOM, Mar. 1977.
[17] "AED 6200LP Floppy Disk Storage System", Technical
Manual, 105499-01A, Advanced Electronics Design,
Inc. Feb. 1977.
[18] "The User Manual for Grinnelll Colour Display".
[19] D. R. Weber, "An Adaptive Run Length Encoding
Algorithm", ICC-75.
[20] R. Braden and P. L. Higginson, "Clean and Simple
Interface under MOS", INDRA Note No. 1054, Feb.
1981.
[21] L. G. Roberts et al, "The ARPA Computer Network",
Computer Communication Networks, Prentice Hall,
Englewood, pp485-500, 1973.
[22] I. M. Jacobs et al: "General Purpose Satellite
Network", Proc. IEEE, Vol. 66, No. 11,
pp1448-1467, 1978.
[23] J. W. Burren et al, "Design fo an SRC/NERC
Computer Network", RL 77-0371A, Rutherford
Laboratory, 1977.
[24] P. T. F. Kelly, "Non-Voice Network Services -
Future Plans", Proc. Conf. Business
Telecommunications, Online, pp62-82, 1980.
[25] P. T. Kirstein, "UK-US Collaborative Computing",
INDRA Note No. 972, Aug. 1980.
[26] "A Network Independent Transport Service", PSS
User Forum, Study Group 3, British Telecom,
London, 1980.
[27] CCITT, Recommendation X3, X25, X28 and X29 on
Packet Switched Data Services", Geneva 1978.
[28] "DoD Standard Transmission Control Protocol",
RFC761, Information Sciences Inst., Marina del
Rey, 1979.
[29] "DoD Standard Internet Protocol", RFC760,
Information Sciences Inst., Marina del Rey, 1979.
[30] P. L. Higginson, "The Orgainisation of the Current
IPCS System", INDRA Note No. 1163, Oct. 1981.
[31] T. Chang, "Distributed Processing for LSIs under
MOS", INDRA Note No. 1199, Jan. 1982.
Appendix I: Devices
AED62(DEV) AED62(DEV)
NAME
aed62 - double density floppy disk
SYNOPSIS
DCT aed62
setdct("aed62", 0170, 0170450, 0170450,
aedini, aedsio, aedint, 0);
DESCRIPTION
The Double Density disks contain 77 tracks numbered from 0
to 76. There are 16 sectors (sometimes called blocks) per
track, for a total of 1232 sectors on each side of the disk.
These are numbered 0 to 1231. Each sector contains 512
bytes, for a total of 630,784 bytes on each side of the
floppy.
Only one side of the floppy can be accessed at a time. There
is only one head per drive, and it is located on the under-
side of the disk. To access the other side, the disk must be
manually removed and inserted the other way up.
Each block is actually two blocks on the disk: an adddress
ID block and the data block. The address ID block is used
by the hardware and contains the track number, the block
number and the size of the data block that follows. When an
operation is to take place, the seek mechanism first locates
the block by reading the address ID blocks and literally
'hunting' for the correct one. It will hunt for up to 2
seconds before reporting a failure.
Both the address ID and the data blocks are followed by a
checksum word that is maintained by the hardware and is hid-
den from the user. On writing, the checksum is calculated
and appended to the block. On reading it is verified (both
on reading the ID and data blocks) and any error is reported
as a Data Check. No checking on the data block takes place
on a write, and the hardware has no idea if it was written
correctly. The only way to verify it is to read it.
Although there are two drives in the unit, they cannot be
used simultaneously. If an operation is in progress on one,
no access can be made to the other until the first operation
is complete. The driver will queue requests for both drives
however, and ensure that are performed in order.
The MOS driver is called aed62.obj. It operates on the fol-
lowing IORB entries:
irfnc
The operation to be performed, as follows:
0 - Read
1 - Write
2 - Verify
3 - Seek
Read and Write cause data to be transferred to and from
disk. Verify does a hardware read without transferring
the data to memory and is used for verifying that the
data can be successfully read. The checksum at the end
of the block of each sector is verified by the
hardware. The seek command is used to move the disk
heads to a specified track.
irusr1
The drive number. Only Zero or One is accepted. This is
matched against the number dialed on the drive. If the
number is specified on both drives, or neither, a
hardware error will be reported.
irusr2
The Sector or Block Number. Must be in the range 0 to
1231 inclusive. irusr2 specifies the block number that
the transfer is to begin at for Read and Write, the be-
ginning of the verified area for the Verify command,
and the position of the head for the Seek command. In
the latter case the head will be positioned to the
track that contains the block.
iruva
This specifies the data adress, which must be even
(word boundary). If an odd address is given, the low
order bit is set to zero to make it even. Not required
for the Seek or Verify commands.
irbr
Transfer length as a positive number of bytes. Not re-
quired for the seek command, bit IS used by Verify com-
mand so that the correct number of blocks may be veri-
fied. The disk is only capable of transferring an even
number of bytes. If an odd length is given the low ord-
er bit is made zero to reduce the length to the lower
even value. The length is NOT restricted to the sector
size of 512 bytes. If the length is greater than 512,
successive blocks are read/written until the required
transfer
length has been satisfied. If the length is not an ex-
act multiple of 512 bytes, only the specified length
will be read/written. Note that the hardware always
reads and writes a complete sector, so specifying a
shorter length on a read will cause the remainder of
the block to be skipped. On a write, the hardware will
repeat the last specified word until the sector is
full.
The driver will attempt to recover from all soft errors.
There is no automatic write/read verify as on mag tapes, so
that data that is incorrectly written will not be detected
as such until a read is attempted. For this reason, the ver-
ify feature can be used (see above) to force the checking of
written data. When an error is detected while performing a
read, the offending block will be re-read up to 16 times and
disk resets will be attempted during this time too. If all
fails a hardware error indication is returned to the user.
Other errors possible are Protection Error (attempt to write
to a read-only disk) and User Error, which indicates that
the parameters in the IORB were incorrect. Errors such as
there being no disk loaded, or the drive door being open are
NOT detectable by the program. The interface sees these as
Seek Errors (i.e. soft errors), and thus the driver will re-
try several times before returning a Hardware Error indica-
tion to the user. It should be noted that error recovery can
take a long time. As mentioned above, there is a 2 second
delay before a seek error is reported by the hardware, for
instance.
GRINNELL(DEV) GRINNELL(DEV)
NAME
grinnell - colour display
SYNOPSIS
DCT grndout
setdct("grndout", 03000, 0172520, 0172522,
grnoi, grnot, grnoti, &grndin);
DCT grndin
setdct("grndin", 03000, 0172524, 0172526,
grnoi, grnot, grnoti, &grndout);
DESCRIPTION
The Grinnell colour display has a screen of 512x512 pels.
Three colours (red, green and blue) can be used, but no grey
scale is supported. Three graphics modes are available.
These are:
(1) Alphanumeric: The input ASCII characters are displayed
at the selected positions on the screen.
(2) Graphic: Basic geometric elements, such as line and
rectangle, are drawn by means of graphics commands.
(3) Image: The input data is interpreted as bit patterns,
the corresponding images being illustrated.
The values used to construct commands are described in the
Grinnell User Manual. They are also listed below.
#define LDC 0100000 /* Load Display Channels */
#define LSM 0010000 /* Load Subchannel Mask */
#define RED 0000010 /* Read Subchannel */
#define GREEN 0000020 /* Green subchannel */
#define BLUE 0000040 /* Blue subchannel */
#define WID 0000000 /* Write Image Data */
#define WGD 0020000 /* Write Graphic Data */
#define WAC 0022000 /* Write AlphanumCh */
#define LWM 0024000 /* Load Write Mode */
#define REVERSE 0200 /* Reverse Background */
#define ADDITIVE 0100 /* Additive (not Replace) */
#define ZEROWRITE 040 /* Dark Write */
#define VECTOR 020 /* Select Vector Graph */
#define DBLEHITE 010 /* Double Height write */
#define DBLEWIDTH 004 /* Double Width write */
#define CURSORAB 002 /* Cursor (La+Lb,Ea+Eb) */
#define CURSORON 001 /* Cursor On */
#define LUM 0026000 /* Load Update Mode */
#define Ec 001 /* Load Ea with Ec */
#define Ea_Eb 002 /* Load Ea with Ea + Eb */
#define Ea_Ec 003 /* load Ea with Ea + Ec */
#define Lc 004 /* Load La with Lc */
#define La_Lb 010 /* Load La with La + Lb */
#define La_Lc 014 /* Load La with La + Lc */
#define SRCL_HOME 020 /* Scroll dsiplay to HOME */
#define SRCL_DOWN 040 /* Scroll down one line */
#define SCRL_UP 060 /* Scroll up one line */
#define ERS 0030000 /* Erase */
#define ERL 0032000 /* Erase Line */
#define SLU 0034000 /* Special Location Update */
#define SCRL_ZAP 0100 /* unlimited scroll speed */
#define EGW 0036000 /* Execute Graphic Write */
#define LER 0040000 /* Load Ea relative */
#define LEA 0044000 /* Load Ea */
#define LEB 0050000 /* Load Eb */
#define LEC 0054000 /* Load Ec */
#define LLR 0060000 /* Load La Relative */
#define LLA 0064000 /* Load La */
#define LLB 0070000 /* Load Lb */
#define LLC 0074000 /* Load Lc */
#define LGW 02000 /* perform write */
#define NOP 0110000 /* No-Operation */
#define SPD 0120000 /* Select Special Device */
#define LPA 0130000 /* Load Peripheral Address */
#define LPR 0140000 /* Load Peripheral Register */
#define LPD 0150000 /* Load Peripheral Data */
#define RPD 0160000 /* ReadBack Peripheral Data */
#define MEMRB 00400 /* SPD - Memory Read-Back */
#define DATA 01000 /* SPD - Byte Unpacking */
#define ALPHA 06000 /* LPR - Alphanumeric data */
#define GRAPH 04000 /* LPR - Graphic data */
#define IMAGE 02000 /* LPR - Image data */
#define LTHENH 01000 /* take lo byte then hi byte */
#define DROPBYTE 0400 /* drop last byte */
#define INTERR 02000 /* SPD - Interrupt Enable */
#define TEST 04000 /* SPD - Diagnostic Test */
The MOS driver is called grin.obj. It operates on the fol-
lowing IORB entries.
iruva
This is a pointer to the buffer where the data is
stored.
This data must be ready formtatted for the Grinnell,
since no conversion is performed by the driver.
irbr
This transfer length as a positive number of bytes.
Addressing the grinnell. Rows consist of elments numbered 0
to 511 running left to right. The lines are number from 0 to
511 running from bottom to top. It is thus addressed as a
conventional X-Y coordinate system. Note that this coordi-
e system is different the one used for the image.
X A
|
| (511, 511)
511 +-------------------------------+
| |
| |
| |
| |
| (x, y) |
| + |
| |
| |
| |
| |
| |
+-------------------------------+----->
0 511 Y
SEE ALSO
grinnell(fax)
(next page on part 3)