The Proposed BAEC Computer

There is no doubt that this proposed project has created considerable interest amongst members, from those who think it is crazy to others who have contributed practical ideas on how to do it. Computers are electronics, if anything is, and a great deal has been learnt from the suggestions made by members. Personally, I think it is a practical project for us, provided it can be of benefit to all members who have a serious use for it, then it must be possible to send it to them easily, and the print-outs must be available to pass on the information computed to other members.

I think the time has come to start on block diagrams and circuits, and even if the thought of a computer leaves you cold, these will help you learn more about electronic designs and practical applications. Mike Lord pointed out that the CPU should have priority over the input/output, as it is the heart of the computer, and I quite agree, with the proviso that I also think that the input/output should be a printer of some sort. Thomas Clarke described very well how the creed 7B teleprinter could be interfaced in the July Newsletter, the only problem being that it is very heavy! If you have any suggestions to make on improvising a suitable unit, please let me know.

Going back to the CPU, this could be either a core store, integrated circuits, or both. It might be that the cost will be a factor here, and enquires are being made to find out which would be best for us. Arithmetical functions could be done best using LSI calculator chips, which are now quite cheap - and could be cheaper still by the time we got round to them! The number of bits in each word also affects the cost, but naturally, the more bits there are the more versatile it would be.

I would particularly like to thank Peter Hinchcliffe for all the work he has done in co-originating all the suggestions, as well as for his own, of course, and for taking on the breathtaking task of being in charge of our computer project. Thank you also to Mike Lord, Thomas Clarke, Paul Maddison and other members who have taken it seriously and contributed so many useful ideas. When I start putting the circuit diagrams in the Newsletter I will drop the word "proposed" from the title, as I think this project is too important to leave in mid-air. C.B.

From M. Lord to P. Hinchcliffe

STACK

REMAINING MEMORY

PROGRAM

Advantage is that you can get a bigger stack and RAM costs less per bit than special registers.

Incidentally - why not use serial accumulators/arithmetic unit?

From T. Clarke to P. Hinchcliffe

1. USE. This has been discussed by several people who all seem to have different ideas on the subject. In order to cope with this natural difference of opinion I think that the computer will have to be as general purpose as possible. The two main categories that uses of computers tend to break down into are:
   • Scientific - the processing of numbers (real, of course) to give an output in terms of a graph or another set of numbers.
   • Filing - the storage of large quantities of data, usually alphameric, and the sorting of this data.
   Both these categories are extremes, and I have found that most of the interesting uses of computers have elements of both of these in them. There is a third use which might be regarded as completely different and that is the one that Mr Harding described in part (b) of his letter in the January Newsletter. However as long as I/O facilities are complex enough G.P. computer handles this well enough - though a hybrid computer would handle this sort of application better. Anyway, a C.P. computer can be made hybrid easily enough as long as it's I/O facilities are flexible enough by adding an analogue units.
2. MEMORY. This is perhaps the next most important consideration after use, because it determines the wordsize and data storage form of the computer. Also, usually, it costs much more than the CPU. The are several things to be chosen:
   • Size - this depends on how much one is willing to pay - something which none has been willing to specify yet. However I agree with Mr Lord when he specifies at least 1000 words @ 16 bits, but anything larger might be too ambitious.
   • Wordsize - as a rule, the larger the computer, the larger the wordsize. Thus 12 bit is the usual small minicomputer size, 16 bit is used in large minicomputers, and 32 and upwards is used in big computers. This rule has more exceptions than most, however, and I tend to agree with Mr Lord the 16 bits would be a good size. It has several advantages:
     • 16 bits gives a nice useful accuracy - 5 digits - and this means that more double precision is usually not needed.
     • One can have a lot of direct addressing, as Mr Lord points out.
     • 16 has considerable advantages from the point of hardware; it is a standard amount which is useful in counting up to 16, etc.
     Even so, though I like the idea of 16 bits, they do mean that the memory is fairly expensive.
     • Form of data storage: see below.
     • Implementation. This is very important and must, I think be considered at this stage. The various forms of memory are listed below.

   Core Memory

   This is still cheaper than any other form for a large size (4K @ 16) but for only 1K @ 16 the prices of MOS become competitive. The reason for this is that it is the driver and decode electronics that cost the most and the cost of this goes up at the square root (very approximately) of the size of the memory. An advantage of core which is not often considered is that it is non-volatile. This does not make much difference if as at most computer installations, punch tape or magnetic tape backup is available, but if these are not, putting in even 100 words @ 8 decimal digits by hand takes a long time.

   MOS Memory

   This has the great advantage of being easy to use. The power supplies needed are small, power dissipation as heat is negligible, and the memory can be TTL compatible (I am assuming the TTL will be used in the CPU). There are several types of MOS which could be used:
   1. TTL compatible, static shift registers. These are slightly cheaper than RAM's, but they make looping much slower than normal. In fact the larger the s.r., the less it costs per bit and the longer looping takes.
   2. Non TTL compatible, dynamic s.r.s. These have the lowest cost per bit of any MOS, but have the same disadvantage as static s.r.s. (though they are slightly quicker), and also interfacing then with TTL is costly and they are not very easy to use.
   3. TTL compatible RAM's. These are surprisingly cheap, (though still more expensive than other MOS), but are ideal from all other considerations except volatility. I believe that Mr Lord has up to date prices of MOS, mine are a little out of date.

3. FORM OF DATA STORAGE. Mr Maddison has championed the BCD cause, which personally, I believe to be a lost one. Though it has the advantage of not requiring decoding and coding, this can be done very efficiently and easily with software. It has two major disadvantages; it makes inefficient use of memory (16 bits gives us digit accuracy, instead of 5½ digit accuracy) and processing becomes much more complicated. Apart from the natural complications inherent in taking bytes of 4 bits, addition is about twice as complicated. If the computer is to be GP, storage ought to be of binary integers, using 2's complement storage of negative numbers. Storage of real numbers is possible but it is just not worth the hardware complications. Anyway, it complicates counting and the storage of alphametic data.
4. CPU ORGANISATION. The CPU must be organised for serial operation. This has many advantages, the only disadvantages being that it takes longer. This is not important because the major contribution to instruction time is the memory cycle time. Advantages:
   • Hardware is much less expensive and easier.
   • Right and left shifting is easier.
   • Hardware selection of one particular digit is much easier.

   The one part of the computer which ought to be parallel in the memory, buy even so input and output of the memory should be serial, apart from anything else to reduce interconnections. Addressing of the memory could be serial, with a shift register inside the memory unit, for serial/parallel conversion, or it could be parallel.

   The accumulator (See also section on instruction codes). The instruction set of the PDP8 is fairly typical of single accumulator sets. This is fairly easy to turn into hardware, but it is terribly restricting. With more than one accumulator the scope of the computer increases tremendously. Having 8 accumulators makes programming 2-8 times as efficient, and with the high cost of memory this is not to be ignored. The problem is how to fit more than one AC into a neat instruction code. I am interested in your idea of a nesting store, as it solves this problem at least to some extent, however I am not sure whether or not the hardware complications are too great. I myself had not considered that possibility and it could be a very good idea.

5. INSTRUCTION CODES. These bare a great relation to hardware structure inside the CPU. If the instruction set is easy to formulate and neat the odds are that the hardware implementation of it will be cheap and easy. The main trouble and complication of many IS's are the address fields. Ideally the computer ought to have one part of it's instruction address and the other part op-code, and all the instructions ought to use the same address. However this is not possible.
6. HARDWARE AND SOFTWARE. This is essentially the point that Mr Lord made in letter (4) in the Newsletter. The design is always a compromise between hardware and software. I must agree wholeheartedly that software in more versatile, but this is no excuse for not considering multiple-AC systems as we have only a limited amount of money to spend on memory and extra AC's would be used in almost every program. A distinction must be made here between extra conditional skips etc, and something like multiplication which requires considerable control and would complicate hardware tremendously. The only way to include it would be to perform it in the way that calculators do it, and this is excessively slow. Given such an instruction on a computer I would prefer to make my own subroutine to accomplish it.

For P. Hinchcliffe to M. Lord

You mentioned a shift register main store in earlier correspondence. Mr. T. Clark has just written to me also suggesting this. I wonder if you could supply a rough explanation of the operation of such a store, for example how it is accessed and subdivided, and the type of shift registers most applicable. I can certainly see the advantages of this type of store, but am uncertain as to actual implementation.

For P. Hinchcliffe to T. Clarke

1. Use - Versatility is mainly a function of accumulator design. If we provide single but logic, as well as whole word-handling facilities we should be able to cover most possible types of use. We could, of course, improve alphameric handling by splitting the accumulator into single character bytes, and providing byte processing hardware. However this could also be done by software if required, and I can't see the justification for this particular refinement,
2. Memory - MOS appears to be much more attractive than ferrite cores for our purposes. I found your analysis of the situation very interesting. Mike Lord tells me that the cheaper MOS RAM's are a bit fussy about timing. However, this should present no problems to the BAEC.
3. CPU organisation - actually the extra hardware required for a nesting store is minimal - just a shift register (one word) for each level of stack required, the double word accumulator acting as the top two levels. A bit of gating is required if one direction S.R.'s are used, but very little in comparison to the advantages.
4. Instruction Codes - I would like to see either continuously packed, variable length instructions, or, perhaps more practically, two major types of instructions: 1½ word, addressed instructions and ½ word non-addressed instructions. Using a nesting store the latter type would be in the majority so this system would be very economical. Mike Lord is worried about hardware complications and I can see his point. However, I am optimistic about this technique.
5. Hardware/Software - you make some very valid points here. There is an intermediate possibility - the use of handwired routines, perhaps on plug-in modules to allow for an expanding range. However, I've not thought this out fully yet.

M. Lord to P. Hinchcliffe

Incidentally, after seeing the prices International Electronics Unlimited are asking for RAM, it may be that RAM would be cheaper, however:

Take one 1024 (say) bit SR. We have one input, one output and a clock. Each clock pulse moves the contents of all 1024 SR elements along one, in doing this the bit previously at the output is lost, and a new bit taken into the input. If we join the output to the input then the clock pulses just move the information around in a circle, without (hopefully) changing it. A few gates will allow us to either close the loop (output to input) when we want to keep the information or open the loop to allow us to put new information in. To keep track of where the information is connect a 10 stage binary (divide by 1024) counter to the same clock. Reset the counter to zero when you switch on if you like, it's not really necessary. We have now got a 1024 word store (one bit/word). The address (10 bits) of the wanted word is compared with the state of the counter and clock pulses applied until a match is obtained. When this happens we can write or read. To get more bits/word we can either drive several SR in parallel, in which case we will write or read in parallel, or we can store complete words in each SR as follows:

We can store 64 16 bit words in one 1024 bit SR, giving us 6 address bits. By comparing these 6 bits with the 6 high order stages of the counter we can find out when to read or write a word, the 4 low order stages of the counter then tell us which of the 16 bits of the word we are reading or writing. Thus we have a serial input/output which is compatible with a serial arithmetic unit. The cheapest SR are dynamic, and so need to have a clock continually supplied (usually 10 KHz to 2 MHz) to keep the information stored. The same clock can also be used as the basic machine clock to ensure synchronisation. To increase the capacity of the store simply connect more SR to the same clock, with individual gating for each SR to select it (according to other address bits) for reading or writing.

Suitable types are the Signetics 2502/3/4. These are also made by many other manufacturers. The 2502 has 4 256 bit SR sharing the same clock, the 2503 has 2 512 bit SR and 2504 is slightly more expensive. The advantage of using a shorter SR is of course that you can get to the wanted bit in less time. The 2503 is probably the best bet, with a 1MHz clock rate you get a worst case access time of 256µS, which is not too bad. When used as a computer store where a lot of the memory accesses tend to be sequential (read a word, do some processing, then read the next word), the average access time can be speeded up somewhat by crossing the connections to the comparator. For example if we compare bit 0 of the address with bit 3 of the counter, bit 2 with bit 2, bit 1 with bit 1, bit 3 of the address with bit 0 of the counter, bit 4 with bit 4 and bit 5 with bit 5 where bit 0 is the least significant bit, then it will appear as though the words are stored in the order:

0, 8, 2, 10, 4, 12, 6, 14, 1, 9, 3, 11, 5, 13, 7, 15