The ENGLISH ELECTRIC Co. Ltd.
Programming Items
The following excerpts from DEUCE documents describe aspects of programming
and/or operating the computer. Entries in italics are comments not in the originals.
Report No. NS y 78 21 November 1957.
This is a seven page report by Miss A. Birchmore of the LONDON COMPUTING SERVICE,
NELSON RESEARCH LABORATORIES, STAFFORD. A facsimile of the report in pdf format
is available here (2.1 MB).
STANDARD OPERATING INSTRUCTIONS FOR DEUCE
SUMMARY
Operating a computer on a production run requires attention to a number of
details to ensure successful operation. Many of these detailed procedures are
common to all jobs, others are common to most.
This report gives a standard procedure for operating DEUCE on production
work; variations may be needed by the particular ambient circumstances at
different DEUCE installations, but it is hoped that the procedure set out will
form an acceptable basis in most cases. In any particular case these standard
instructions should be supplemented by written operating instructions for the
job concerned. Between them, the general and specific operating instructions
should specify the operation completely and should not require additional
verbal explanation.
1. STANDARD COMPUTER STATE
Put the keys, lamps, etc, on the Control Panel, Punch and Reader in the
standard state described below before using the computer.
Control Panel Keys
All keys level except Stop Key and Char Key.
Stop key raised (on NORMAL).
Char key raised.
Control Panel Lamps
32 OS lamps off.
32 ID lamps off.
Red lamp above Stop key off.
Lamp above Read key off.
Lamp above Punch key off.
No red lamps on in the upper right corner of the Control Panel (a red light
here should be reported to the engineer).
Lamps on Reader
All lamps off.
Lamps on Punch
Ready lamp on.
All other lamps off.
Switches on Punch
Counters re-set to zero.
Parameter switches OFF or set to required position.
Cards in Punch
Cards removed from hopper.
Punch run out and cards removed from stacker.
Hopper refilled with salmon stripe cards.
Punch run in.
2. HOW TO ACHIEVE THIS
Symptom Remedy
OS lamp(s) on Press down "Clear OS" key on the right
hand side of OS lamps.
ID lamp(s) on Press down "Clear ID" key on the right
hand side of ID lamps.
Red lamp on above Stop key Press down Release key.
Lamp above Read key on Raise Read key.
Lamp above Punch key on Raise Punch key.
R.H.S. lamps on Reader - 1 on Remove cards from hopper.
- 2, 3 on Run out.
- 6 on Remove cards from stacker.
L.H.S. lamps on Reader
- Not Ready lamp on Put Control Panel keys in their standard
positions.
- Missed Card lamp on Raise Run In key on Reader.
- Any other on All others should now be off.
Lamps on Punch - Called lamp on Raise Punch key on the Control Panel.
- Ready lamp off Put red cards in hopper if necessary
and press run in key.
3. WHAT YOU NEED FOR A PARTICULAR JOB
For a particular job you need:-
a) Operating instructions for the particular job. These will be a list of two
sorts of things -
i) what you must do, and
ii) what DEUCE will do
in the order in which they are expected to happen.
b) List of input cards.
c) Input cards, in trays (two sorts - program cards and data cards).
d) Trays for output cards. (with all necessary index cards prepared ready).
4. HOW TO MANAGE CARDS DURING A RUN
Reader
Place cards in the Reader hopper, face inwards and with the Y-row edge
leading. Put in as many as you can comfortably hold in your hand. Read in the
first handful of cards with the Initial Input key. When the Reader hopper is
empty and lamps 1-5 are off, remove all the cards from the stacker, and refill
the hopper. Read in these cards with the Run In key.
Punch
Place blank cards in the Punch hopper, face downwards and with the Y-row edge
leading, and press the Run In key. When the Punch hopper is empty or almost
empty, press the Stop key (the Ready lamp on the Punch will then be off).
Remove cards from the stacker, refuel the hopper and press the Run In key.
Warning
Never place cards in or remove cards from either Reader or Punch without
first checking that the appropriate Ready lamp is off. If it is not,
for Reader - raise Run In key on Reader
for Punch - press Stop key on Punch
Trays
Keep two trays on the console desk - one for input cards, and one for output
cards. All cards must be either in a tray or in the Reader or Punch. Keep a
marker in the input cards to show where you are.
5. MONITOR DISPLAY
Line up the monitor display if you have been given the necessary information.
(See 8).
6. UNEXPECTED SITUATIONS
Symptoms Remedy
a) Computer buzzes Press down Alarum key, or if this does not
work raise the Alarum key to suppress the
noise. Also consult the list of failure
indications. If this is a failure indi-
cation, do what the operating instructions
say you should. If not EMERGENCY (see 7).
b) No buzz, but computer stops, Look for Other Symptoms.
(i.e. Go lamp is off)
Other Symptoms Remedy
Reader called but not Ready EMERGENCY (see 7).
- Missed Card lamp on
Reader called but not Ready Examine R.H.S. lamps on Reader.
- Missed Card lamp off
Reader called but not Ready Remove cards from stacker. Press Run In
- R.H.S. lamps 1-3 on key.
Reader called but not Ready Reader card jam.
- R.H.S. lamps 1, 2 on; 3 off
Reader called but not Ready Run In. If this is not successful, Reader
- R.H.S. lamps 1 on; 2, 3 off Card jam.
Reader called but not Ready Refuel hopper if there are any more input
- R.H.S. lamps 1-3 off cards; if not, EMERGENCY (see 7).
Reader Card jam Take cards out of hopper, and examine to
see if the top cards are damaged. If they
are, reproduce them. Now put the cards
back carefully, and run in. If this is not
successful, call for engineer's help.
Punch called but not Ready Remove cards from stacker. Refill the
Punch hopper if necessary, and run in. If
this is not successful, Punch Card jam.
Punch Card jam Take cards out of hopper, throw away any
that are damaged, and replace them
carefully. Run in. If this is not
successful, call for engineer's help.
Both Reader and Punch called EMERGENCY (see 7).
Neither called Look through the list of operating
instructions and the list of failure
indications. If this does not help you,
EMERGENCY (see 7).
c) No buzz and the computer going Is this a failure indication?
(i.e. the go lamp is on), but If not, EMERGENCY (see 7).
not doing what the operating
instructions say it should.
7. EMERGENCY
If the programmer is available, ask for his help. If he is not available do
what he said you should in an EMERGENCY, if anything. Otherwise do this:
a) Clear Read and Punch by raising Read and Punch keys on the Control Panel.
b) Put the Stop key at STOP.
c) Write down the NIS, Source and Destination displayed on the IS lamps.
d) POST MORTEM (see 8).
8. THINGS THE OPERATING INSTRUCTIONS MIGHT TELL YOU TO DO
Stop the Computer
Put the Stop key at STOP.
One-shot or Single-shot
Press down the Single shot key and release it.
Release
Press down the Release key and release it.
Call Read Manually
Press down the Read key on the Control panel and release it.
Call Punch Manually
Press down the Punch key on the Control Panel and release it.
Clear Read
Raise the Read key on the Control Panel and release it.
Clear Punch
Raise the Punch key on the Control Panel and release it.
Set N S-D(c) on the IS keys
NIS, Source and Destination keys - level = 0, down = 1 .
Characteristic key - Up = 0, level = 1 and down = 2.
Obey N S-D(c) ( or a sequence of such instructions) with External Tree and
Cont TT (or with External Tree and one-shot)
a) Put the Stop key at STOP.
b) Put External Tree key down.
c) Set N S-D(c) on the IS keys.
d) Press down Cont TT key (or Single shot key) and release.
e) Raise the External Tree key.
Program Display
Put the Stop key at AUG STOP. Fill the Punch hopper with Program Display
cards (i.e. instruction cards with a mauve edge).
Press down Program Display key and release it. Punching continues until:
a) The Punch is not Ready. To continue remove cards from stacker, refill hopper
and Run In.
b) The Punch is not called and the red lamp above the stop key is on. To
continue release (the red lamp will go off) and then press Program Display key.
c) The Punch is not called, and the red lamp above the Stop key is not on. To
continue raise and then press Program Display key.
Request Stop
To Request Stop on NIS = n, S = s, D = d (where one, two or three of n, s
and d may be specified).
a) Stop key to Stop
b) Set the given n, s and/or d on the IS keys.
c) Press down corresponding Request Stop switches leaving the other(s)
(if any) up.
d) Raise the External Tree key.
e) Stop key to normal.
f) The computer will Request Stop on the next instruction it reaches of the
specified form.
g) Stop key to Stop.
Now proceed as instructed.
Restore Control to GIP 5
Put P32 on ID. Put Stop key at NORMAL. Read in "Re-enter GIP" (2L86) with
the initial input key. When the computer stops, the next codeword is on the OS
lamps, but has not yet been obeyed.
Post Mortem
Put stop key at Stop
Set 0 30-0 (1) on the IS keys
Depress External Tree key
One-shot
Raise External Tree key
Put Stop key at NORMAL
Call Read manually.
Run in Post Mortem (either ZP29 if the program is not controlled by GIP, or
ZP29 (GIP) if the program is controlled by GIP). Cards are then punched (between
reading various bits of program). After punching a number up to 268 triads of
cards the computer stops at 0-22 X.
Line up Monitor Display
The R.H.S. monitor display tube shows the 32 mcs, in order, of a DL selected
by the rotary switch. The display is said to be lined up when mc 0 of the
program is at the top of the screen.
To Line Up
a) If the operating instructions for the particular job give the contents of one
minor cycle of a particular DL:
i) use rotary switch to bring this DL on to the R.H.S. display tube;
ii) identify the given mc;
iii) press MC SLIP button until this mc is in the correct position.
b) While the program is being stored on the drum, some people find it possible
to line up in DL11;
i) use rotary switch to bring DL11 on to the R.H.S. display tube;
ii) press MC SLIP button until the longest interval between filling
consecutive rows occurs between the bottom row and the top row.
Signed: A Birchmore
LONDON COMPUTING SERVICE, N.R.L., MARCONI HOUSE.
Report No: NS y 80 25 November 1957.
This is a 36 page report by P. J. Landin of the MATHEMATICS DEPARTMENT,
NELSON RESEARCH LABORATORIES, STAFFORD E. E. CO. LTD.
Sections 2.1 and 2.2 (pages 4-9) are reproduced here.
PREPARING AND TESTING DEUCE PROGRAMMES.
SUMMARY.
This report describes the various stages of writing and
testing a DEUCE program with special emphasis on procedures
that make a program easy to check, use and modify. The report
has been specially prepared for distribution to members of the
December, 1957, DEUCE Programmers Course.
..... snip .....
2. WRITING A PROGRAM:
This chapter describes some of the decisions a programmer will
(despite himself) have made by the time his program is written.
The best time to make them is sometime after writing the first
draft of the logical flow diagram and before writing the computer flow
diagram.
Most of the procedures suggested here are aimed at making a program
easy to diagnose faults in, easy to modify and easy to use. These aims
rarely conflict with one another or with rapid preparation of a program
since the extra time spent in designing a program will be more than repaid
by avoiding the lengthy job of salvaging a badly designed or undesigned
program.
There are some applications of DEUCE to which these recommendations
may not all apply in detail, but it is intended to lay out an approach to
programming that will have universal application, and illustrate it with
references to DEUCE programs.
2.1. Inputting and Obeying the Instructions.
2.11. General Procedure.
2.11.1. For a self-contained program pack.
Each computer operation starts by establishing a standard computer
state. This is partly achieved by the operator (see "Standard Operating
Instructions" by A. Birchmore) and partly by instruction cards, in the
following way. A program that does not use any computer-stored data starts
with the three cards:
Type I Initial Card (to establish correct mc number).
Clear Drum ZP13/1 (to write zeros in all drum addresses and leave
both sets of heads at position zero).
Set Clock Track ZP36 (to write on 15/15 a clock track with which
Sync Clock Track ZP37 and Clock Track Set or Sync ZP34 and Post
Mortem ZP29 can all synchronise).
These are followed by cards containing instructions to be stored in
the computer (together with instructions that will store them there). The
cards to do this are any or all of
(1) Read to Drum ZP14.
Triads of information destined for tracks of the drum except
track 15/15.
(2) Fill Short Tanks etc. ZP35.
Triads of information destined for short tanks, OPS, triggers
and head positions.
(3) Triads for DL's 12 to 1.
The second of these items is too complicated to use, except in an
emergency to reconstruct a particular computer state. The third of them
can often be advantageously dispensed with if one of the schemes described
in 2.2. to 2.5. is adopted.
2.11.2 For a Program pack that uses computer-stored data.
A program pack that uses computer-stored data will generally be read
by instructions initiated by a program already in the computer, in which case
the first three cards listed in 2.11.1 should be omitted.
In an emergency it may be necessary to break in on the current
computer operation and the pack should then be preceded by Clock Track Set
or Sync ZP34 instead of the three cards listed in 2.11.1. (If mercurystored
information is required then the operator must clear TS COUNT manually and
use the run in key instead of the initial input key.)
2.12. Dividing a Program into Sections.
There are 402 mercury addresses in DEUCE of which 256 can be used
as next instruction addresses, and many programs require a lot more than
400 DEUCE instructions. It is therefore often necessary to overwrite
instructions by other ones during the course of a program. The over
writing program can be stored on cards or on the drum, and the instructions
to transfer it to the mercury must be already in the mercury.
Transferring 32 instructions to a delay line takes nearly a second
from cards and up to 50 ms from the drum, and 32 instructions can take as
little as 2 ms to obey, so it can save a lot of time if the program is
partitioned in such a way that instructions are obeyed as often as possible
without being overwritten; i.e. it is more efficient to overwrite programs
in between loops than in the middle of them. It also follows from these
figures that if there is room on the drum to store all the program there is
little to lose by initially transferring the entire program from cards to
drum (via mercury) and then transferring from drum to mercury as required.
The gains are:
(a) even if some instructions do have to transferred to the
mercury on several different occasions, they only have to be
read from cards once and this is by far the longer transfer;
(b) a card pack can be made containing all the instructions with
only one copy of each part of the program and without the
necessity to interleave data with instructions each time the
program is used. This simplifies the operating instructions
and reduces the chance of operating errors;
(c) the whole program or any part of it can be made re-entrant or
can easily be adapted as part of an even longer program if
later required.
Efficient partitioning usually means that each item of the overall
logical flow diagram is obeyed without interruption from program transfers
and so the program consists of several sections each with a specific function,
each working on numbers read from cards, and/or left in the computer by
previous sections, and each leaving results in the computer for succeeding
sections and/or on cards.
If furthermore each section is as self-contained as possible and a
precise specification of what it does is given then
(d) programming time can often be saved by using existing programs,
e.g. for input and output of matrices, in computations to
which they are not obviously relevant;
(e) it is easier to localise mistakes and to make alterations that
are only local in effect.
2.13 Standard Program Sections.
In 2.14 a standard form for a program section is described that
has the following additional advantages:
(a) All the transfer of program from cards to drum and from drum to
mercury can be done with control programs that are already
written.
(b) These control programs have built-in program testing facilities,
e.g. for tracing the progress of a large program, restoring
control if the program runs amok, re-starting at any required
section, and re-writing a single track during testing.
(c) The sections can be written so that they may be obeyed
indifferently from the drum or the reader. So if for a
particular use of the program there is not room on the drum for
data and instructions, a small re-arrangement will often permit
the instructions to be obeyed directly from the reader without
requiring any drum storage.
2.14 The Rules for a Standard Program Section.
The following conditions do not greatly restrict the programmer and
allow him to use any of the control programs described below:
(a) Each section of program is transferred to consecutive DL's
including DL1 before it is obeyed. If it is stored on the
drum it is stored on consecutive tracks (lowest DL number in
lowest track number). It may have up to 10 DL's although
instructions in 9 and 10 will have to be transferred again
before they can be obeyed.) The cards are punched with normal
initial instructions except for DLl which has
blank
1, 0-1 (1) 26, 25 X
1, 0-1 30, 31 X
1, 9-24 0, 29 X
The instruction 9-24 x punched on the 4th row of the DLl triad
is obeyed in mc 31 if the section is obeyed from the reader. The last
row of the triad is punched with the section number of the program at P17.
This is only transferred from the card to the computer when the section is
not obeyed directly from the reader. It serves during testing to identify
easily the section currently being obeyed from the drum.
(b) Each section starts
(131 9-24 X) (only obeyed if the section is obeyed
130 directly from the reader.)
and finds in the QS's (and in certain other short tanks
depending on the control program used) and DL's, except DL11
and the ones it occupies, whatever was left there by the last
section.
(c) Each section can use any of the stores except 1229-31, track 15/15,
and the tracks containing program sections or the control program.
So the copy of the program on the drum is left unchanged (unless
replenished from the reader) and each transfer of a particular
program section to the mercury places an identical set of
instructions there.
(d) Each section ends by placing a parameter that specifics what
happens next and leads out with
12-1 (32)
130
and leaves the contents of the QS's (and of certain other short
tanks depending on the control program used) and DL's except DL11
to be found by the next section (which will overwrite at least DL1).
The form of the parameter, and which of the short tanks are preserved,
depends on which control program is being used.
2.15 Fixing the Order in which Sections are Obeyed
The way in which the order of obeying the sections is specified depends
on the context and on the control program used:
(a) The simplest is that each section ends by placing a parameter saying
which section comes next. It might have a choice of exit points
specifying different successors depending on discriminations made
while it is obeyed. (ZC01/3, ZC11 and ZC13 all allow this.)
(b) One of the sections may use another section as a subroutine,
specifying not only which section is to be used next, but also the
re-entry point to itself afterwards (ZC11 allows this.)
(c) There may be a master routine which uses all the other sections as
subroutines and does nothing itself except this. (ZC01/3 and ZC11
allow this. For ZC01/3 this master routine is simply a list of the
section numbers in the order of execution with special facilities
for loops.)
If all the basic program sections you require are already written and
all you want to do is to string them together then you should use the master
routine method.
If you are writing nearly all the program yourself and the logical
arrangement of sections is fairly simple, method (a) is the best with perhaps
slight modification of the ends of existing sections to make them lead correctly
to their successors.
If the logic is more complicated, with sections using other sections as
subroutines and re-entering themselves, ZC11 must be used.
It is possible approximately to rank the three control programs
mentioned in various ways:
By power and flexibility ZC01/3 (but rather inconvenient for using
sections as subroutines)
ZC11
ZC13
By simplicity in use ZC-1/3 (sic)
ZC13
ZC11
By efficiency in use of ZC13
computer time and storage ZC11
once the program is ZC01/3 (threshold time of approximately
prepared and tested 1 sec per section)
For further information on ZC01/3 see DEUCE News 10
on ZC11 see R.A.E. Technical Note MS 31
"The Assembly of Large Programs for
the Automatic Computer"
on ZC13 see Library Program Report.
2.2 Input of Data
2.21 Punched Data
Some programs require that each time they are used certain parameters
are specified. Even if only one use is to be made of it a program can often be
tested more effectively by varying these. No program should require parameters
to be punched among its instructions each time it is used since this complicates
pack assembly and provides opportunities for mistakes during both testing and
use.
Nor should they be put into the computer via the ID lamps or any other
manual input since this is slow and provides opportunities for unrecorded
operating mistakes. Nor should they be read from cards punched with "initial
instructions" used for reading instructions into DLs, since this complicates
data preparation and compels the use of binary. Instead the extra instructions
necessary to read them from cards (preferably decimally punched) should be
written and these cards prepared with other punched data each time the program
is used.
A programmer must program not only the computer, but also the people who
will use his work (including himself) and his job includes writing the
instructions for preparing data and assembling the card pack (see 3.1). This
should be done before finalising the form of the program. It is frequently
worthwhile to simplify data preparation at the expense of program complication.
Decimal is generally better than binary and the logically simple arrangement
of numbers with no unnecessary information except checked redundancy checks
(see 2.42) may be better than the arrangement that is easiest to program (as a
trivial example, do not require data to be punched with P54's).
The only exception to these rules is that sometimes the operator is
required to give the computer information resulting from decisions made during
the running of the program as a result of the computer's behaviour. The use
of manual input and the circumstances that may make it unavoidable are
considered in 2.22.
2.22 Manual Input
A program should be written so that the operating instructions are as
simple as possible with minimum opportunity for mistakes, especially irrevocable
mistakes. Complicated instructions result in computer time being wasted while
the operator unravels and obeys them or worse in delays in getting jobs done
because they are disobeyed. In 3.5 the even more important matter of making
them precise will be discussed.
The sorts of action required of an operator are:
(a) pressing keys and turning knobs;
(b) inserting at specified places in the pack of cards to be read, cards
that have been produced by the computer;
(c) punching cards and inserting them in specified places in the pack of
cards to be read;
(d) recording on paper information obtained by observation during
the running of the program.
These may be unconditional instructions or conditional on certain
behaviour of the computer. They will now be discussed one sort at a time
to see if they can be eliminated.
(a) Obviously not all key work (e.g. pressing the initial input
key) can be avoided. Complicated instructions such as setting
up a large binary number on the I.D. keys can be replaced by
punching it on a card, which is preferable since it is recorded.
A particular sort of knob-turning that could almost always be
eliminated, but often with great programming inconvenience is
the use of the punch numbering switches (4 counters, 8 fixed
switches and associated keys). It can happen that the rules
for operating them involve periods of idle computer time in
excess of actual computing time. This occurs especially when
a program originally intended for large values of some of its
parameters is used with small values of them.
(b) These instructions can only be reduced to the extent that
internal storage is available.
(c) If precise operating instructions are possible then this sort
can be replaced by computer instructions and thus punching is
eliminated. If not, then not.
(d) Again if precise operating instructions are possible this sort
could be replaced by punched output but possibly at the expense
of complicating the subsequent card processing to an unreasonable
extent (e.g. if special cards have to be removed from the
output pack before printing.)
Any unpunched information indicated by the operator to the computer
or given by the computer to the operator, should be coded as simply as
possible. For example, if a choice from four alternatives is to be indicated
they should be coded 0,1,2,3 or 1,2,3,4 rather than 5,17,18,31. Furthermore,
in the case of signals from the operator to the computer it should be
made physically impossible to give an irrevocably inappropriate signal.
Particular cases of this are that no program should rely on the I.D. lamps
being the same on two consecutive glances at them or be affected by the I.D.
lamps or (during calculation) the T.I.L. key except in ways that are known
and declared in the specification.
The operating described above is the operating that is planned
as part of the program's actual use, not the operating that the programmer
does during testing. For example, a program that does not use manual
input (other than essentials such as initial input key) or visual output
is easier to operate in use and consequently easier to test, but this does
not preclude the use of these devices during testing (see 5 and 6.)
2.3. ..........
Rugby/Whetstone DEUCE Bulletin Issue No. 2, 1 June 1959, pp6-11
PROGRAMMING
1. Use of 64-column reader and punch.
The following details are taken from DEUCE News, No's. 17, 24, 27, 29.
1.1 Hollerith Cards.
The α- and 13 β- fields are in card columns 17 - 48 and 49 - 80 respectively.
A hole in card column 1 will stop the reader.
1.2 DEUCE Operation.
32- and 64- column working are controlled by switches on the punch and reader.
These should be checked before starting.
It should be noted that 64-column programs, unlike some 32-column ones, cannot
be read in with the machine on "stop".
1.3 Programming.
The α -field is read or punched first, using a normal stopped instruction, then
the β -field, using an instruction with a "go" digit. When punching, an
instruction 8-24(1) must intervene; thus, for reading
0α - A X
0β - B Go (after 20 m.c.)
and for punching
A - 29α X
8 - 24(1)
B - 29β
Note that in reading, switching of fields is caused by all instructions with
source 0, except 0-24, 0-30, 0-31. Therefore, care must be taken not to include,
for example, 0-0 waste instructions, between the reading of α- and β- fields,
or the wrong field may be read. In punching, the switching is caused by 8 - 24(1).
1.4 Timing.
|
Field
|
Reader Availability
|
Punch Availability
|
|
α
|
S.S. till 4 m.c. after end of stopped instruction
|
S.S. till 8-24(1)
|
|
β (begins)
|
20 m.c. after end of stopped instruction
|
after 8-24(1)
|
|
β (ends)
|
2 m.s. after S.S.
|
4 m.s. after S.S.
|
Rugby/Whetstone DEUCE Bulletin No. 4, 1 August 1959.
Short article on the reliability of DEUCE, summarised here. This is not a
verbatim copy.
The probability of having a run of at least equal to t minutes is: (a = DEUCE
and reader and punch; b = DEUCE only; c = DEUCE and punch)
t(minutes) a(%) b(%) c(%)
50 90 94 92
100 82 88 85
150 74 79 82
200 66 72 78
250 60 66 74
300 55 61 70
There are no figures to show these running periods were 100% good runs. All
programs over 30 minutes should be checked.
DEUCE Bulletin No. 9, 22 February 1960.
1. PROGRAMMING FOR DEUCE MARK IIA.
A second DEUCE has been ordered for the Whetstone installation, and delivery
is expected in September of this year. The new machine will be a Mark IIA.
The following notes are published in order to assist programmers in using the
additional facilities available with the Mark IIA machine.
1.1 Extra delay lines. (See DEUCE News 46)
Seven additional delay lines are available, DL's 1A to 7A. These can be used
as N.I.S. under control of a trigger, T.C.C., which is stimulated by the in-
struction 14 - 24 with characteristic equal 1. An instruction with N.I.S. 3, for
example will call D.L. 3 if T.C.C. is off, and D.L. 3A if T.C.C. is on. TCC is
cleared by the instruction 14 - 24 (0), and also by the "initial input" and
"clear store" keys on the console. The N.I.S. of a 14 - 24 instruction is
determined by the new state of T.C.C.; ie., 1, 14 - 24 (1) will call 1A, but
1, 14 - 24 (0) will call D.L. 1.
Transfers to and from D.L.'s 1A to 7A are governed by the P1 digit of the
instruction. Thus an instruction "3 - 6" without a P1 will transfer between
D.L.'s 3 and 6, and "P1, 3 - 6" will transfer 3A to 6A. It is impossible to
transfer directly between (for example) D.L.'s 3 and 6A, but transfers between
either 3 or 3A and 0, 8, 9 ... 12 and higher sources or destinations are
possible. Instructions such as 7 - 24, 7 - 31 have the same effect with or
without P1.
Further pages of this article dealing with changes introduced by the Mark IIA
can be viewed in the Turing Archive.
DEUCE Bulletin No. 10, 13 June 1960, pp8-12
FOR WHAT ITS WORTH
1. A Proposal for a Modification to DEUCE by G.J. Tee
At present there are 3 principal devices by means of which DEUCE can
communicate its results to the outside world. By far the most commonly used is
the card punch, whose advantages and disadvantages are well-known to all users.
The pictorial display on the oscilloscope, though potentially very versatile,
in practice proves to be somewhat inflexible, and requires much storage space.
Further, the pattern of 32x32 dots is of inherently low resolution, and above
all, the record is not permanent. A built-in camera could overcome this
objection, but the others would still remain, and there would be added the
delay and inconvenience of developing the film. The automatic plotter produces,
of course, a vividly graphic display. It does however work rather slowly, and
is very expensive.
It is therefore suggested that the output facilities of DEUCE be
supplemented by the addition of a knitting machine. Such a device would have
many advantages, including the following:
a) Inexpensiveness:
A wide range of domestic models are available at prices ranging from £15 to
£106/10/0d. The more expensive versions incorporate facilities for knitting
in several different colours simultaneously, and for producing buttonholes,
loops, hems and various other special-purpose patterns.
b) Clarity:
When several different graphs are to be superimposed, the output may be
knitted by Fair Isle techniques, using a different colour for every curve.
c) Versatility:
It is safe to assert that no output medium currently used provides such a
number of varieties of format as is possible with a knitting machine. If the
results are required in alphabetic or numerical form, instead of being
restricted to the set of alpha-numeric symbols, there is no limit to the variety
of characters which may be employed. If the output is to be in graphical form,
the curves may be produced together with their coordinate axes (whether
Cartesian or curvilinear), labels and text. The format may be designed so as to
be suitable for immediate publication by photographic techniques. If the output
is to represent a surface in 3 dimensions, then 2 projections may be knitted
superimposed on each other, one in red wool and the other in green, so that the
fabric need merely be viewed through appropriately coloured spectacles to create
a stereoscopic effect of seeing the surface in 3D. Alternatively, the surface
may be knitted directly in 3 dimensions, which would be very convenient for
turbine blade designing and similar investigations. Indeed, in such a case, the
output could be knitted in the full scale of the blade in a fairly rigid thread
(such as nylon, or cotton moistened with starch), which could be employed as the
master mould or template from which to fabricate the blade. If the knitter were
equipped with sock needles, it could be used to produce an output in the form
of a long tube. e.g. if the DEUCE were producing a continuous sequence of
curves, (such as a sequence of curves, converging to an eigenfunction), the
curves in polar coordinates could be knitted as the successive sections of
the tube, at intervals of one stitch along the tube.
d) Electromagnetic Output and Input:
Investigations are currently being made by several research workers of the
practicability of constructing computer storage devices by knitting wires
together (a single Kt 1, P1 stitch seems the most promising) and coating the
resultant circuit with ferrite paste. This is designed to avoid the difficulty
and expense of threading ferrite cores on matrices of wires. Should these
experiments prove to be successful, such circuits would be eminently suitable
as a form of output from the knitting-machine fitted to DEUCE. By using fine
wires of soft insulated copper, information could be built into circuits which
could then be plugged into an immense variety of electrical devices, so as to
control their behaviour. In particular, such circuits could be plugged into
DEUCE, either at the input stage (as would be most suitable for data), or into
the operating circuits, if it were desired to build in additional arithmetical
or logical facilities, sub-routines or programs. Furthermore, such circuits
could well be hand-knitted, so that input data and programs could be prepared
by the girls of the Hollerith Office by means of ordinary knitting needles which
would undoubtedly be less wearing on their delicate fingers than the present
system of punches, and would not interrupt their conversation.
e) Compactness:
Most systems of storage (punched card, punched tape, magnetic tape or
photographic film) require an area of several square millimetres to record a
single binary bit of information. If the output circuit were knitted by a
stocking machine on 66 gauge mesh using very fine wire (15 denier), it is
estimated that 4 bits could be stored for every square millimetre of fabric.
Moreover, precise positioning of the bits would not be so crucial as with the
current systems of storage, and an experienced operator could read the circuit
visually, which cannot be done with magnetic tape.
It is interesting to note the historical fore-runners of the proposed
output, in the form of the quipu of the Peruvian Amerindians (cf. Mason pp 73 et
al ), and the similar device used in China during the early dynasties (cf.
Needham, Vol. 1, pp 229 and 237). In each case, intricately knotted cords were
used to record information, and there is some evidence that calendrical
computations were performed by their means. On the other hand, punched cards
were first devised (in the late 18th century) specifically for the purpose of
controlling the weaving of fabrics by the Jacquard loom.
The principal objection to a knitted form of output appears to be the risk
of ladders in the fabric, but with adequate control of the knitting tension,
this risk should be no more serious than the current risk of tearing cards.
However, there remains the problem of modifying data or programs once they have
been knitted. The author would welcome suggestions upon this matter from anyone
with practical experience of darning stockings. Also, the author invites
proposals for standard alphabets and lists of other characters to be built into
the machine, for modifications to Alphacode and TIP so as to adapt them to knit
their outputs, and for a family of programs to convert existing programs to
knitted circuits.
A program which could well be written to test the new output would be a
demonstration program to knit socks for visitors, incorporating their own
initials.
REFERENCES
MASON J. Alden, "The Ancient Civilizations of Peru", Pelican, 1957.
NEEDHAM Joseph, "Science and Civilization in China, Volume 1, Cambridge
University Press, 1954.