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, 
Sections 2.1 and 2.2 (pages 4-9) are reproduced here.



        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 .....


        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 

        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 

        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 mercury≠stored 
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 

        (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

            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

        (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)
            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)

        By simplicity in use       ZC-1/3  (sic)

        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 

        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. There≠fore, 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.
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.
1.5 Fillers. a) To read into DL's single triads of instructions punched in the α -field only, use normal 32-column fillers punched in the α -field. b) To read a double triad into NIS DL's A and B and call NT, 10 being blank, Y Blank Blank X 1, 0-A(1) 27,26 Go B, 0-A, 30,30 X 0 A, 0-B(1) 28,27 Go A, 0-B, 30,31 Go 1 B, 0-A, 30,30 X N, 0-B, 30,T-1, Go 2 A0 B0 etc. c) To read a double triad into non-NIS DL's A and B via NIS DL's C and D, and call NT, 10 being blank, Y Blank Blank X 1, 0-C(1) 27,26 Go D, 0-A, 30,30 X 0 1, 0-D(1) 29,28 Go C, 0-B, 30,31 Go 1 C, 0-D, 27,28 Go N, 0-B, 30,T-1, Go 2 A0 B0 etc. d) ZP39T will read double triads to DL's or drum (see below). Row Y is punched in each field with the number of the store to be filled, XP1 for a track and XP10 for a DL. To enter the program at NT, punch NIS N and timing number T in addition to the destination. Rows X, 0, 1 are ignored. Note that, for use with ZP39T single triads must be punched in the β -field. 1.6 Useful Programs. a) ZP41. Stop and field detector for 32-columns. This stops the machine unless the reader is switched to 32 columns and the stop key is at "normal". b) ZP39T. For 64-column programs. Card 0 is an initial card, set scope and stop detector. Cards 1 to 3 will clear drum if DL 11 is empty, set clock track (P31 in 15/15 m.c. 16) if a triad follows with P32 on row Y, and read program to drum and DL's. c) ZP46T/1. This program takes an existing single field program and produced a two-field version using ZP39T as the input routine. No instructions in the resulting pack are changed, and data should be punched in the α -field only. OPERATING INSTRUCTIONS. Order of Cards Initial card ) clear drum (essential) ) As for single field Drum filling program ) program Triads for drum ) ZP46T/1 Triads for DL's As for field program. Card with P32 on Y-row Output. Copy of ZP39T (4 cards) Two field triads for drum. (Track x P1 on Y row of each field). Two field triads for DL's (DL x P10 on Y row of each field). The β -field of the last triad punched has N P2 + T P26 added to the Y row parameter, to enter the program at NT. Before using the 64 column pack, punch card column 1, in row 9, in the first output card. This clears read, and allows the stop detector facility to operate. No other modification of the output pack is required, and on being read the 64 column pack puts the machine in the same state as the original pack. Initial card and clear drum are built into ZP39T. To make second copy without reading in 32 column program again. Initial input. 1) Sync. card. 2) ZP46T/1 3) Triads for DL's. 4) Card with P32 on Y row.

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.