⟦4e9f4f6db⟧

TextFile

<se *< *pn 0,0**pl 297,28,240,4,10*
*lm0**lw 170* *ld8* *ps15*
*sj*
H. C. Ørsted Institute
Københavns Universitet
Universitetsparken 5
DK-2100 København Ø
Denmark
*qr*
1979-10-25
*rj*
*lm10*
The editor*nl*
Computers and Chemistry*nl3**np 20*
Dear Dr. Delos F. DeTar
*rj*
*nl3**lm0*
*np 10*
Enclosed is a manuscript I would like to have considered for
publication in Computers and Chemistry.
*np 10*
*nl6*
*lm100*
Sincerely
*nl4*
Anders Lindgård
*lm 0**ps15*
*rj*
*sj*
submitted to Computers and Chemistry 1979-10-25
*nl2*
*nl*
*ct*
Hierarchical Multi-Level Computer Network for
---------------------------------------------
Laboratory Automation
---------------------
*ld8*
*0010**nl 1*
Anders Lindgård
H. C. Ørsted Institutet
Københavns Universitet
Universitetsparken 5
DK-2100 København Ø
Denmark
*rj*
*ld8**ns 1,6,Running title: Microcomputer network*
*rh 1,Microcomputer network*
*ns 1,3,Received:*
*ps0*
*ld8**ns 1,3,Abstract*
--------*ld16**np*
The design and implementation of a microcomputer network to support
laboratory automation is described and discussed. It is a multilevel
hierarchical starnetwork connected to a multiprogrammed computer
on which all programdevelopment is done. The system is capable of
supporting a large number of experimental setups. The microcomputers
are either used as 1. local microcomputers for experiment control
2. multiplexers for other microcomputers or 3. controllers for
peripherals known in the multiprogrammed computer.
*np*
The system combines the advan-
tages of a large multiprogrammed computer with those of a small
cheap dedicated computer close to the experiment.*np*
Characteroriented peripherals are connected to the multipro-
grammed computer only. This reduces the amount of system software to be
written for the network by an order of magnitude and eliminates the need for inter-
facing to existing small computer software.
The system software consist of three small programs (monitors)
providing a process concept and multibuffering of
data in the involved computers.
The monitor establishes a hierarchy of control
and they eliminate the need for any local load device for the
microcomputers as their monitors are in a read-only store.
*np*
The system developed is designed for control of experiments in
an environment where the experiments and the control strategies
change with time and where the datarefinement required is beyond
what can be done on the present generation of microcomputers.
*pn 5,0*
*ps 0*
*ld8**ns 1,3,Introduction*
------------*ld16**np*
The background for this project is the increasing need for
computer service to a large number of experiments at the H. C.
Ørsted Institute. Most experiments in physics and chemistry
there, are rather small but also very different in nature, so the
computer facility should be able to support very different needs.
The requirements from the experimentalists may be summarized as
follows:
*nl**lm20*
*mt 1, 1.* need for complex numerical datarefinement.*nl*
*mt 1, 2.*if local storage is provided, only moderate data transfer speed between experiment
and main computational facility is needed.*nl*
*mt 1, 3.* high degree of data security*nl*
*mt 1, 4.* experiments should be able to run for days*nl*
*mt 1, 5.* it must be cheap to add a new experiment to the system*nl*
*mt 1, 6.* short response time on a human time scale between
datacollection and final results*nl*
*mt 1, 7.* support of experiments at fairly large distances.*nl*
*mt 1, 8.* program development and modification must be easy*nl*
*lm0*
*nl2**np*
It is easy for a contemporary microcomputer system to fulfill
part of the experimentalists requirements, and it is easy for
a timeshared computer with an extensive set of peripherals
(lineprinter, magnetic tape units, disc file units, hardware
floating point) to fulfill what the microcomputer cannot do well.
So an obvious solution for us was to design a system where a simple
microcomputer is placed close to each experiment and
connected to a timeshared computer.
*nl**np*
The primary reason for choosing a solution with a many level
hierarchical computer system
was the requirement of being able to support
a cluster of experiments at a fair distance from the multi-
programmed computer.
*nl**np*
The design presented here is based on our experience with some
much less general microcomputer systems developed for the
RC4000 (Lindgård et al., 1977).
*ld8**ns 1,3,Computer systems*
----------------*ld16**nl**np*
Minicomputer systems have for a long time been used extensively
to control laboratory experiments. Often it has been the only
way of performing on-line control and data collection with
complex experiments. If a minicomputer system is used for
programdevelopment, debugging or just minor corrections to
the experiment control program it must have a fairly extensive
and expensive set of peripherals, usually costing much more
than the minicomputer itself. Still in most cases it is a tedious
job to develop programs and the system can by no means be said to
be cheap. It is a disadvantage in institutions with several
computerized experiments that stand-alone systems do not encourage
exchange of experience and programs. Often even the computers
are of several different kinds adding to desorganisation and
double work.*nl2*
Microcomputers are hardwarewise a good replacement for complex
specialized logic especially when local storage is required as
e.g. for multichannelanalyzers, as they are very cheap. They are
however very tedious to program. The short wordlenght, the primitive
instruction set makes debugging of assembly language programs
much more difficult than on most larger computers. This implies
that programsize should be kept small by using microcomputers only
for rather simple task as datacollection.
Some stand-alone systems have BASIC interpreters and some do
even have compilers for higher level languages. Often however
assembly language programming must be used for handling
process peripherals as this cannot be done within the language.
When using interpreters for datacollection it is a common problem that the data rate
is too fast for the slow interpretation of the code and
assembly language must be used.
*nl2*
A multiprogrammed computer with disc, lineprinter, good compilers,
editor etc. is very well suited for programdevelopment and for
controlling experiments which do not have responstime or syncroni-
sation requirements. A number of software techniques (Graae Sørensen and Lindgård, 1973)
are available
to make it possible to honor responsetime requirements on a multi-
programmed computer, but the more severe the responsetime requirements
are, the more inappropriate are constraints felt by other userpro-
grams. Dedicated monoprogrammed computers are much better suited
for handling responsetime requirements performing 'busy wait' until
the critical signal arrives. To make the busy wait situation tole-
rable the hardware must be cheap and here is where the microcom-
puters fit in. A symbiosis of a number of microprocessors with
a multiprogrammed computer retains the advantages of both systems.
*ld8**ns 1,3,Computer networks*
-----------------*ld16**nl**np*
Most computer networks (Kimbleton and Schneider, 1976) consist of
geographically separated individual computers connected through
slow serial lines. The earliest large scale
network is the ARPA net, which gives a possibility for communication
between large and smaller computers throughout USA (Roberts and
Wessler, 1970).*np*
A number of computer networks for experiment control
in physics and chemistry are described in "Computer networking and Chemistry"
(Lykos, 1975) and by Milett (Milett, 1976).
Most systems are hierarchical (Klopfenstein, 1973). At each experiment
there is a dedicated stand-alone minicomputer doing experiment control
only, while an experiment is in progress. The network has no control
over the computer. The computer has only a sparse set of
peripherals, and especially the lack of backing store makes
extensive programdevelopment and modification difficult.
The local minicomputer is connected to a more powerfull computer
through slow serial lines (typically less than 9600 baud). The
software for the different computers is very different and this
inhomogeneous structure reduces the usefulness of the system
considerably.
*nl**np*
*ld8**ns 1,3,Description of the implemented system*
-------------------------------------*ld16**nl**np*
The general layout of the network is shown in figure 1.
Each experiment using this network has a local microcomputer. The
microcomputers are all connected through the network to
a central microcomputer which is
of the same type as the local microcomputers.
A computer may be a multiplexer for up to 15 other
computers on the next lower level of the hierarchy. With
5 levels there is in practice no limit to
the number of computers which may be supported.
The central micro-
computer is connected to and controlled by the RC4000 computer.
A local microcomputer is a simple selfcontained system. It is primarily
used as replacement for multichannel analyzers, but also for complicated
experiments with extensive interaction between computer and experiment.
An example is an experiment for controlling oscillatory chemical reactions
(Graae Sørensen, 1979).
*np*
The local microcomputer is build around the Motorola M6800 central processor.
The standard microcomputer has 16k (expandable to 57k)
bytes store for user program and for
the monitor there is 4k bytes EPROM and 1 k bytes RAM. Standard peripherals
are 3 asynchronous transmitter/receiver units and a programmable clock.
To control experiments the user has registers, counters and analog converters
available according to specific need.
*np*
The prototype microcomputer was developed in 1978 and now
there are 5 local microcomputers in the network.*np*
The microcomputers in the network are connected with 3 serial
50 kbaud lines. One is dedicated to commands from the computer higher
in the hierarchy (the master) and one for requests from the other (the
slave) and the third for block transfers between the two computers.
This separation makes the software interface much simpler at a rather
small cost in extra hardware.
*np*
*ld8**ns 1,3,The System Software*
-------------------*ld16**np*
The system software attempts to make the network trans-
parent to the programmer. In the RC4000 computer the local micro-
computer user program is simulated as a process much like another computational
process (internal process) (Brinch Hansen, 1970,1973). In the
local microcomputer the RC4000 is simulated as a process as well,
and we have attempted as far as possible to keep the same conventions
in both ends.*nl**np*
The system provides only a set of tools for control and communication
but it does no enforce any strategy for user programs in the
two computers (Brinch Hansen, 1970).
*nl**np*
When using the system there will at run time exist the following
programs.*nl*
*lm12*
*nl*
*mt 1, 1.* Local microcomputer user program

*nl*
*mt 1, 2.* Local microcomputer monitor simulating the RC4000,
simulating local peripherals and controlling the local user program

*nl*
*mt 1, 3.* A multiplexer program in the central microcomputer
handling up to 8 simultaneus messages between the RC4000
and each local microcomputer

*nl*
*mt 1, 4.* Multiplexer program in the local microcomputers acting
as nodes in the network.

*nl*
*mt 1, 5.* RC4000 processes simulating the local microcomputers
and some system processes

*nl*
*mt 1, 6.* RC4000 user program acting as an operating system for the local microcomputer
user program
*nl**lm0*
*nl**np*

*ld8**ns 1,3,RC4000 processes*
----------------*ld16**nl**np*
In the RC4000 computer the network is represented as a set of peripheral
processes as part of the RC4000 monitor (Brinch Hansen, 1970, 1973),
see figure 2.
Closest to the hardware there is a blocktransfer process named "dma", a process
for handling messages to the central microcomputer named "trm" and a process
for handling answers to messages named "rec". Theese processes handles
normally only messages from the process
named "central", exept when debugging the hardware
or the system software for the central microcomputer. In the latter
case they are handled directly from priviledged RC4000 internal processes.
For each local microcomputer there exist a process. For a normal
experiment microcomputer this is the process the RC4000 user program
communicates with. The multiplexer microcomputers can only be accessed
by priviledged processes and this is only used for initialization.
Local peripherals to a local microcomputer may be represented in
the RC4000 as proceses. Only block input/output are accepted
for these processes.
*nl**np*
Messages to the local microcomputers:
*lm20*
*nl2*
*mt 1, 1.* autoload
*nl*
*mt 1, 2.* sense
*nl*
*mt 1, 3.* start user
*nl*
*mt 1, 4.*stop user
*nl*
*mt 1, 5.*input block
*nl*
*mt 1, 6.*output block
*nl**np**lm0*
An autoload message initializes a microcomputer. All pending
messages in the network are released. The user program is put
into the stopped state, but otherwise nothing is done to the user
program.
*nl**np*
The sense message gives a statusword for the userprogram.
*nl**np*
start user program and stop user program will start and stop the
user program respectively. stop user followed by start user
do not change the value of the program counter.
*nl**np*
block input or block output tranfers one datablock
of 768 bytes. The transfer may be to absolute addresses in the
local microcomputer or the micrcomputer user program may
supply the addres for the transfer.
*nl**np*
The RC4000 user program may be regarded as an operating system
for the local microcomputer user program. It is normally initiated
from a typewriter terminal placed in the same room as the local
microcomputer, but this is not a requirement. It acts as a loader
for the local microcomputer user program and receives the collected
data which then are stored in a file. It may automatically be re-
started after system breakdown in the RC4000 using the automatic
upstart facilities in one of the operating systems
(Lindgård, 1979).
*ld8**ns 1,3,Local microcomputers*
--------------------*ld16**np*
The primary reasons for introducing the local microcomputers is
that they radically improve data security and that they give a
much better timeresponse to external signals than a multipro-
grammed computer.*nl2*

We have designed the system such that a datacollection may
continue independant of whether the central microcomputer or the
RC4000 are running, which is invaluable as the RC4000 is a machine
used for hardware and software experiments. Interrupt driven data-
collection from the experiment is expected to be the normal way
of working. We do not consider it important to be able to do this
with the highest obtainable speed, as it is not very expensive to
replace interrupt driven datacollection with a DMA-channel.
For continous datacollection a speed with one 8-bit data word
every few milliseconds transferred from the experiment to the
backing store of the RC4000 is our design goal. This
is an improvement of two orders of magnitude for interrupt driven
datacollection using a time sharing swopping operating system in
the multiprogrammed computer.*nl2*
*ld8**ns 1,2,Local monitor*
*ld16*
*nl**np*
The monitorprogram resides in the EPROM. It preforms the fol-
lowing functions:
*nl2*
*lm20*
*mt 1, 1.* Handling the three communication channels to the central
microcomputer and the internal clock

*nl*
*mt 1, 2.*
Implements control functions as autoload, start and stop
on demand from the central microcomputer

*nl*
*mt 1, 3.* Provides hardware test functions as read and write in
all parts of the store

*nl*
*mt 1, 4.* Simulates the RC4000 and all local peripherals as pro-
cesses for the user program
*nl*
*mt 1, 5.*supplies the user program with a set of procedures for
communication with other proceses.
*nl**np**lm0*
Internally the monitor is divided into a number of processes
communicating with small messagebuffers passed by reference.
*np*
To the user process the monitor is a number of processes. There
is the process describing the RC4000, the internal clock and a
process for each peripheral. The communication takes place sending
messages to these processes and waiting for answers
using monitor procedures. From the
RC4000 messages may be send to the user process and they are handled
by the user program calling monitor procedures wait-message, send-answer. Waiting on
any event is taken care of by a wait event procedure. All these
procedures are as close to their RC4000 equivalents (Brinch Hansen,
1970 and 1973) as possible in order to simplify concepts and software. A message
to another process will contain an operation describing the proce-
dure to be used by the called process, some parameters and a
time-out specification. The time-out specification is necessi-
tated as we are forced to regard the process peripherals as highly un-
reliable. The internal clock is used by the called process to keep
track of whether the external signal comes before time out occurs,
and thus provides a check on the peripheral equipment.
Peripheral processes will in general accept messages requesting
a block of data to be input or output, thus freeing the user
program for handling the devices on a primitive level.
*nl2*

*ld8**ns 1,3,The central microcomputer.*
--------------------------*ld16**np*
The hardware for the central microcomputer differs from the local microcomputers by the interface to the RC4000 only. Simple communication between
the RC4000 and the central microcomputer uses two sets of dual 24 bit regis-
ters and interrupts, see figure 1. Block transfers takes place directly between the
stores of the two computers.
The RC4000 can reset, stop and start
the central microcomputer thus having complete control over the microcompu-
ter. The only private peripherals for the central microcomputer are 15
triples of receiver/transmittes used for communication with the
local microcomputers on the next level.
*nl**np*
The multiplexer program handles up to 8 messages to
each local microcomputer from RC4000.
Theese message are used for input of data blocks, output of
datablocks and for control. One is reserved for handling autoload messages, else
the system would be able to deadlock itself.

The term input is used for data to the
RC4000 and output for data from the RC4000. Due to
some restrictions in the RC4000 monitor it has been necessary
to let only the RC4000 user program send messages.
This does not limit the possibilities for interaction
between the user programs in the two computers, but it
does make conversations more elaborate.
The multiplexer program is organized
as a number of processes each describing a local microcomputer and a
central logic handling the incoming messages and answers.
The blocktransfers is handled using a
multibuffer technique to smoothe datatransfers to the RC4000. At
present there are three buffers of 768 bytes in the pool
for each microcomputer.
Multibuffering of input is necessary to speed up the transfer of data
to the RC4000 backing store as this has to go through the user
process in the RC4000 and the user process is subject to swopping.
Times between swop out and swop in does only rarely and at very
high loads exceed 30 sec giving a minimal data rate of 75 bytes/sec.
In practice by measuring over several days the
limit is 2000 bytes/sec.
*ld8**ns 1,3,Using the system.*
-----------------*ld16**np*
The user of the system is supplied with two model programs,
one ALGOL program for the RC4000 and an assembly language program
for the local microcomputer. From these two programs
the user is expected to develop the specific programs
for the experiment. The model programs handles a
standard task of reading data from a device
and transfering buffers to a
file in the RC4000 system.*nl2*
The local microcomputer model program.*nl2*
This program is organized as a set of coroutines having a single
waiting point (wait event). One coroutine takes care of the data-
collection proper. This part is usually different from applica-
tion to application.
A coroutine receives messages
from the RC4000 and interpretes the content, which may be a stop
datacollection message or a request for transmission of a speci-
fied buffer. As a convention all buffers contain an identification
number, number of words in this buffer and a status word.*nl2*
The ALGOL model program*nl2*
The ALGOL model program handles both datatransfers and control
of the local microcomputer user program.
In the arguments in the call the user specifies 1. the name of the
microcomputer, 2. the file holding the microcomputer assembled pro-
gram 3. the datafile for results and 4. restart condition. The program
checks rather detailed that arguments are sensible e.g. that the
file of the assembled program does contain a program for this type
of local microcomputer, Normally the program then proceeds by reading
the local microcomputer program from the file
into the local microcomputer
and starts it. If the restart condition is true no loading takes
place but the program in the local microcomputer is checked. The
program now has to handle two parallel activities: 1. to transfer
datablocks from the micro and store these in the file specified
and 2. to receive commands from the terminal and interprete and
execute these.
Transfer of datablocks is performed using a multibuffer technique
and the program is prepared to handle retransmission when faulty
blocks occur.
*nl**np*
For maximum safety, the data result file contain the idenfication-
number of the latest file stored. When restarted the program will
request the local program to retransmit all buffers with this
identificationnumber and higher, previously sent.*nl2*
At any time the user may from the terminal issue a command to the
ALGOL program. At present the command may be 'stop'
datacollection or 'where'. 'Where' will give the number of buffers
collected.*nl2*
Data safety.*nl2*
This issue is of primary concern to the users who really do not accept
other failures than those due to their own equipment. For this reason
we have in the software implemented fairly elaborate safety precau-
tions.*nl2*
In the local micro no datapoint is destroyed before the whole available
store is filled up with data. As most of the computers has data storage
enough for a complete experiment the multibuffer strategy will try
to ensure that there during the experiment is both a copy on the RC4000
disc of most of the data and a copy in the local microcomputer.
The RC4000 datafile will the next morning automatically be dumped on to
a magnetic tape.*nl**np*
The restart facility can be used in an automatic upstart of the data-
collection program by one of the operating systems
(Lindgård, 1979). This operating system will as part of the start
up sequence after a system failure start a number of programs.*nl**np*
The program for the central microcomputer is as standard loaded
by the RC4000 monitor during its initialization. This has only the
effect on the local microcomputer that any pending datatransfers are
delayed until a request is issued from the user ALGOL program to
start again.*nl**np*
Noise on the communication lines between the local microcomputer and
the central microcomputer is a problem as faulty transmissions do
occur now and then. Our remedy is to use full duplex transmission and to
have the sender to retransmit a few times.
For severe transmission errors the ALGOL program must determine what to do.
*nl**np*
The local microcomputer is equipped with a clock and this is used
for 'time-out' on all datatransfers. This ensures that
any coroutine or process will not wait for ever in any waiting point
due to hardware errors in the peripherals.*nl2*
*ld8**ns 1,3,Discussion*
----------*ld16**np*
The network approach taken in this work offers several advantages
compared to other networks for laboratory automation
(Lennon, 1975; Ashenhurst, 1975; Arden and Berenbaum, 1975)
The local microcomputers really has the minimal configuration to per-
form the datacollection and control task, as the only peripherals
besides the simple communication channels are the process control
peripherals.
A drawback in our approach is that the multiprogrammed computer
must be running in order to use the terminals, but as this computer
very rarely fails this is of minor importance.*nl2*
In the minicomputer networks where the local minicomputers are stand
alone systems (Ashenhurst, 1975) most of the program development is
done on the local computers using a slow teletype. The program-
ming is usually done in BASIC extended with assembly language coded
procedures for the specific aplication. The larger computer in the
system provide backing store facilities and may offer assembly of
assembly language programs with listing of programs. Usually several
types of computers are connected in the network making the software
inhomogenous with e.g. different editors and compilers on the different levels.
*nl2*
In our approach to computer networks we have eliminated many of the
problems of the traditional laboratory automation networks. Connec-
ting character oriented peripherals to the central computer only,
makes it possible to have only one level of character oriented soft-
ware, which is much easier to maintain than a two level system
with possibly different computer types. In this system the only pro-
gram parts which will differ when a local central processor is replaced
by another completely different type is the short application
program and the local monitor. On the central computer the only
software change is to generate a new table describing the instruction
set to our general table-driven assembler (Bang, 1974).
The hierarchy of strict
control as implemented by the local monitor in non-volatile stores
reduces upstart problems, program loading and it creates a simple
block oriented communication scheme, which is simple to use.*nl2*
The most important disadvantage of the present system is the requirement that
application programs for the local microcomputers has to be written
in assembly language, allthough the local monitor has a very extensive set of
procedures to support the user programs. They are usually very short.
In our next microcomputer project
this will be remedied. We
are currently developing PASCAL compilers.
Theese are primarily based on the sequential and
concurrent PASCAL compilers developed by Brinch Hansen (Brinch Hansen
1975, 1976).*nl**np*
Using a network of slavemicrocomputers for control and datacollection
rather than the larger multiprogrammed computer directly has a number
of advantages for a large class of experiments.
Experiments which have simple data input requests in the range
from approximately 1 ms to approximately 1 sec for long periodes of time are hard to
handle in a general way on a multiprogrammed computer (lindgård et al
1976, Lindgård et al, 1977). In this timerange the microcomputer
completely solves the timing problems as we have demonstrated
continous datacollection with 5 msec per point where the data ends
safely on the backing store of the larger computer.
Another advantage
of the local microcomputers is the ease of introducing new devices
for a specific experiment. On the RC4000 computer the introduction
of a new directly controlled device requires a new table called a processdescription for
each new device introduced.
This is a part of the monitor
which then must be reassembled and reloaded. This is a tedious task
and requires that all user activities are stopped during reload.
In the microcomputers only the application pro-
gram and possibly, but rarely, the local monitor must be changed.
Theese changes requires only a stop for the specific local micro-
computer.*nl2*
*ld8**ns 1,3,Acknowledgement*
---------------*ld16**np*
The enlightning and valuable discussions with Dr. P. Graae Sørensen
and Dr. R. Moss
during the years has had a great impact on the project.
E. Sørensen implemented the local microcomputer monitor and
the multiplexer programs. J. Oxenbøll implemented the hardware.*nl2*
*rj*
*ps0*
*ld8**ns 1,2,References*
----------*nl2*
*sj*

Arden B. W. and Berenbaum A. D. 1975
Proc. 5th symposium Operating System Principles,
Austin, Texas 114-115

Ashenhurst R. L. 1975
Computer Networking and Chemistry,
Ed. P. Lykos, ACS Symposium Series _«bs»1_«bs»9 108-117

Bang J. 1974
Rapport 74/15, Datalogisk Institut,
Københavns Universitet

Brinch Hansen P. 1970
Comm. ACM _«bs»1_«bs»3 238-250

Brinch Hansen P. 1973
Operating System Principles
Prentice Hall, Englewood Cliffs, New Jersey

Brinch Hansen P. 1975
IEEE Trans. Soft. Eng. SE-_«bs»1 199-215

Brinch Hansen P. 1976
Software Pract. & Exper. _«bs»6 141-206

Graae Sørensen P. and Lindgård A. 1973
Computers in Chemical Research and Education
Ed. D. Hadzi, Elsevier, Amsterdam 5/39-58

Graae Sårensen P. 1979
Ann. New York Acad. Sci. _«bs»3_«bs»1_«bs»6 667

Kimbleton S. R. and Schneider G. M. 1975
Comput. Surv. _«bs»7 129-173

Klopfenstein C.E., Heap A. R., Koskinen J.,
and Spencer R. B. 1973
Computers in Chemical Research and Education,
Ed. D. Hadzi, Elsevier, Amsterdam 1/171-188

Lennon W. J. 1975
Computer Networking and Chemistry
Ed. P. Lykos ACS Symposium Series _«bs»1_«bs»9 67-84

Lindgård A., Moss R. and Oxenbøll J. 1976
Comp. & Chem. _«bs»1 7-11

Lindgård A., Graae Sørensen P. and Oxenbøll J. 1977
J. Phys. E Scientific Instrumentation _«bs»1_«bs»0 264-270

Lindgård A. 1979
Software Pract. & Exper. _«bs»9 xxx

Lykos P. 1975
Computer Networking and Chemistry
ACS Symposium Series _«bs»1_«bs»9

Millet E. J. 1976
J. Phys. E _«bs»9 794-802

Roberts L. G. and Wessler B. D. 1970
Proc. AFIPS _«bs»3_«bs»6 543-549
*ef*
▶EOF◀

DataMuseum.dk

RC4000/8000/9000

⟦4e9f4f6db⟧ TextFile

Derivation

TextFile