 Felly, rhai cwm Mary Bennett â'i gyrtwch ac rwy'n enwedig i ydy gydag o'ch cyfnodd. Fathgoed ddynu, arniwar. Ac wrth gwaith amdano'n gydag o flynyddion yma'r amsergylchedd ellau gennyngau gwaith ershaeth, edsack. Roeddwn yn gwneud morolol, Morris Wilkes, a'r holl yma'n ddweud o gynyddiad edsack gwahanol, oherwydd mae'r ysgol mewn ddweud i'r cymhwynau blwyddyn. My goal is to introduce school students who will be the engineers of the future to the reality of a computer which shaped modern society. Pure software simulations of EDSAC have existed for many years. Crucially, our project is about recreating a physical version of EDSAC. One where connections can come loose, where paper tape jams and sometimes misreads, where initial orders can be mis-entered and where teleprinters can run out of paper just at the wrong time. There will be demonstrations. With these I'll be helped by my grammar assistant Jeremy. These should work perfectly due to my hard work. But of course if anything goes wrong, you can blame him. Let's look at where it's all started. From the night 1822, difference engine of Charles Babbage, computing was purely mechanical until the Second World War. Code cracking during the war led to the emergence of the first electromechanical and then purely electronic computers. By the end of the war there were the colossus machines at Bletchley Park in the UK and designs for ENYAC and the successor EDVAC in the USA. John von Neumann, who was part of the EDVAC team, was responsible for two important design elements. Using two complement binary arithmetic and using a single memory to hold both the program and the data on which it was to operate. The latter concept was so fundamental that all subsequent machines following this design were known as von Neumann machines. Morris Wilkes, newly appointed director of the Cambridge University Mathematical Laboratory, learnt of the EDVAC design during a 1946 visit by Leslie Comroy. The remit of his mathematical laboratory was to provide a computing service for general use and to be a centre for development of computational techniques in the university. Wilkes was old to make a von Neumann machine available to the university. His approach was relentlessly practical. During on the experience of EDVAC he used only proven methods for constructing each part of EDVAC. The resulting computer was slower and smaller than other planned contemporary computers but ran successfully from May 1949, two years before the much larger and more complex EDVAC on which it was based. EDVAC used mercury delay lines from memory and vacuum tubes for logic. Despite 3,000 vacuum tubes and the five foot long delay lines, EDVAC could just about fit into a five metre by four metre room. EDVAC consisted of a control unit to hold the order being processed, an ALU holding a 71-bit accumulator and two 35-bit multiplication operands and a general store, initially only holding 512 18-bit words, which later increased to 1,024 words. Short words on EDVAC were 17 bits long, since, due to timing issues, the topmost bits in every short word could not be used. Long words could use the topmost bit and so were 35 bits long. The accumulator could hold 71 bits, including the sign. This allowed two long numbers to be multiplied without losing any precision. EDVAC used two complement binary numbers. Unusially, the multiplier was designed to treat numbers as fixed point fractions in a range between 1 and minus 1. Therefore, the binary point was immediately to the right of the sign. All instruction codes were by design represented by one mnemonic letter in five-bit modified Bowdo code. That's an ADD instruction, for example, used the EDVAC character for the code of letter A. There were no division instructions, not any way to directly load a number into the accumulator. Instead, a store and zero accumulator instruction, followed by an ADD instruction, were necessary to store a value in the accumulator. There were no unconditional jump instructions, nor was there a procedural call instruction, as procedures had not yet been invented. With such a restricted instruction set and memory, self-modifying code was widely used. EDVAC used punched paper tape to input programs. A programmer would provide the handwritten program to a specialist typist who converted the program into EDVAC Bowdo code and punched the five-hole wide tape. The programmer would then hang their tape on a rack, ready to be run. If there were then found to be errors in the tape, a hand punch could be used to make small corrections. The program instructed a printed output and an electromechanical teleprinter was used. EDVAC could send the least significant five bits of the long word being printed to an internal buffer. When a new character was received in the internal buffer, the previous character would be printed. There was still the problem of bootstrapping. To save time, the initial 32 instructions, known as orders in EDVAC, were hardwired on a set of uniselector switches. By May 1949, the initial orders provided a primitive relocating assembler, taking advantage of the numeronic notation used in programs. This was the world's first assembler. As an example, this is the initial bootstrapped code of 32 instructions, alongside its paper tape representation. Note that, like Hebrew, you need to read the paper tape from right to left. You can see the paper tape today, etched in the windows of the Cambridge University Computer Lab T-room. David Wheeler, Morris Wilkes' assistant, came up with the technique to allow blocks of code to be reused for multiple locations. The program could store its current location in the accumulator, and then jump to the block of code to be reused. The block of code would then add the opcode for a jump to location 2 to the accumulator, and store it at the final location of the code. This modified code was then a link order, allowing control to return to the original program. You can see the behavior of the main program. At location p-1, it zoos the accumulator. At location p, it stores its current location, p, in the accumulator. Before at location p-1, it jumps to the block of code at location q. At the start of block of code at location q, it adds the value at location 3 to the value in the accumulator. By convention, location 3 held the order for jump to location 2 if positive. The addition created the order to jump to location p-2 if positive. At location q-1, it then stores the value in location q-r, the final location of the block of code. The penultimate order of the code block starts at location q-r-1. At location q-r-1, it zoos the accumulator to ensure the following jump if positive is taken. At location q-r-r, the jump instruction, modified at the start of the block, is executed, which returns control to the point in the main program immediately after the jump. Of course we know this today as a subroutine, but David Wheeler was the first to use this technique. By 1951, a library of 87 subroutines were available on tape for general use, including complex numbers, logarithms, and the equivalent of modern while and for loops. In 1951, Wilkes and Wheeler, and their colleague Stanley Gill, published the first ever book on programming. Sadly, 70 years later, the first edition, a key historical resource, is only available as a copyright facsimile. Amazon have two copies available second hand, for £1,175 each. There is a downloadable copy of the second edition, which is a sensual resource, although it describes later extensions to EDSAC, not the original 1949 machine. EDSAC was intended to advance scientific research in the university. In 1951, it found a 79-digit prime, more than doubling the record which had stood for the preceding 75 years. Ronald Fish's paper on gene frequencies the same year included a table of solutions computed by Wilkes and Wheeler on EDSAC. This was the first example of a computer being used in biological research. In 1951, Hodgkin and Huxley wanted to use EDSAC for the analysis of nerve signalling. Unfortunately, EDSAC was offline for a six-month refurbishment and missed out on involvement in work which led to a Nobel Prize. However, EDSAC did play a big role in their later work. The first graphical video game was also written and played on EDSAC, an implementation of tic-tac-toe with graphical output sent to a cathode ray tube, an input via a telephone rotary dial. The development of computing was a massive public interest. Here is how British newspaper, The Star, reported on EDSAC in 1949, and many software simulators of EDSAC. But none of these captured the physical nature of early computing. We have reimagined EDSAC using a modern FPGA for the processor and 3D printing, discrete electronics and arduinos for the delay line and three key peripherals. Everything is open source and we have aimed to keep the cost of design low to make the project accessible for schools. In this talk, I am going to look in more detail at the use of FPGA boards for the main EDSAC logic, one of the peripherals, the paper tape reader, and the delay line used for memory. This is a work in progress currently based on the original 1949 version of EDSAC. We welcome all contributions to extend our work. An FPGA is a software reconfigurable silicon chip. There are now many small FPGA boards available which can be used to learn silicon chip design. The designs are specified in a hardware description language and for this project we have used Baralloc. The MyStorm board is a low cost option designed by Ken Boak and Alan Wood. All board schematics are freely available, so if you want to make your own version of the MyStorm, you can. MyStorm in turn uses free and open source EOSIS tools by Clifford Wolff for Baralloc synthesis. So you have a completely free tool chain from hardware design to physical realisation. Bill Purvis started the original EDSAC drawings with the original EDSAC drawings from Wilkes. He redrew the logic system using modern notation and then rewrote it in Baralloc for use on MyStorm board. Gate level simulations confirmed the design work as expected. There are physical switches to control the implementation and provide initial orders as shown on screen. However, this version of EDSAC still relied on software to simulate the external peripheral world. As part of the 2017 Google Summer of Code, Hatham Canchwala, shown on right, created a new implementation in Baralloc. This was particularly designed to take advantage of the MyStorm PMOD ports so it could drive external physical peripherals. Let's now look at one of the peripheral devices. Our reimagining of the paper tape reader. We don't have access to a paper tape punch or indeed any old paper tape to punch. Instead we use a thermal printer of the type used in a shopping till to print out paper tape. Like traditional paper tape, we have three holes on one side, then a sprocket hole, then two holes on the other side. To read the tape, we'll shine a light on the paper and detect how much is reflected back using a light dependent resistor. The light dependent resistor has a resistance which under bright light drops to as little as 5 kilo ohms but rises to 20 mega ohms in the dark. We connect one end of the light dependent resistor to the 5 volt veil and the other end to a 22 kilo ohm pulldown resistor to ground. We'll use the voltage at the mid connection, connecting it to an Arduino analog input. When the light dependent resistor is dark it will have a very high resistance compared to the pulldown resistor. Following Kirchoff's law, we know the voltage will distribute across the resistors proportionately. So the voltage provided to the analog input will be close to 0 volts. Conversely, when the light dependent resistor is illuminated it will have a low resistance compared to the pulldown resistor. The voltage now just rebutes mostly across the pulldown resistor and the voltage provided to the analog input will be much closer to 5 volts. We'll be looking for low voltages which correspond to dark holes on the tape. Having built our reader, the first step was to feed a trial tape through with an oscilloscope on the analog inputs. Here is what we see. The sensor for the sprocket hole in yellow at the top and the middle data hole at the bottom in blue. After some random noise at the start of the tape the sprocket hole shows a regular signal. Since it has a hole for each row, by contrast the data hole has a mixed signal. There is not a hole in every row. When it does have a signal it has a larger amplitude since it has larger holes than the sprocket. We then connected the reader to the Arduino and used it to collect the raw data from the analog pins sampling at 200 Hertz. The Arduino analog to digital converters are 10 bit so will yield values from 0 for 0 volts to 1023 for 5 volts. The plus of all 5 data pins and the sprocket pin is revealing. As expected after an initial random period while the blank leader passes the sensor, we see a series of minima for each pin corresponding to dark patches on the tape. The yellow line for the sprocket hole shows a regular pattern with a minimum for each hole. However notice that the signals are quite smooth. No sharp edges as we meet a hole. Also note that when a signal has a period of no holes such as data hole 3 shown in purple it rises to a higher value than when it had a frequent minima. This is because light dependent resistors are quite slow to react. Secondly notice that the absolute value of individual sensors varies considerably. The minimum for bits 1 and 2 are around 200. While the maximum for bits 0 and 4 is around 100. This is because of stray illumination from neighbouring LEDs meaning that sensors with two neighbours generally get more light and so will show a lower reading. Finally notice that the yellow sprocket signal has got a smaller range than the other pins since its dark holes are smaller. Central to our approach we will be detecting the sprocket holes. We can't use absolute values so instead we will look for minima in the signal. We need to avoid random small minima which occur during the feed-in period. However we can see that the real minima are seeded by a very fast change in speed in signal value a steep slope on the graph. Something that does not occur much with noise. A brief diversion into calculating the rate of change of a signal. This is the slope of the graph at any one point if we had a continuous function we would just use the derivative of the function. However in this case we are going to discrete data points so we can measure how much the signal value changes over time with each step. Delta X divided by delta T. For adjacent points we must just subtract signal values and time values to yield delta X and delta T. However we know that the delta T will always be the same since we are sampling at 200 Hz It will be 5 milliseconds We could just divide all the delta X values by a constant 0.005. However the absolute value for the rate of change of signal doesn't matter. Just thus this is consistent so we can just ignore the division and use the delta X value directly. Admitting the division will also make the computation much quicker. Calculating slopes in this way relies on having a reasonably smooth signal. Taking a close up look at part of the sprocket signal we can see that this is not the case. Random variation in the senses makes for some roughness. The solution is exponential smoothing where we can combine the sense of value with 4 fifths of the previous sense of value. The result is a smooth signal. We'll get more reliable slope estimates which is good. But at the expense of reducing the peaks and troughs we wish to detect which is not so good. Computing the delta for the five data holes and the sprocket hole we see two useful properties. First of all they are all centered around the same value. Zero. Secondly there is a clear distinction between noise which has small deltas and signal which has large deltas. Since finding the sprocket hole is central to reading the tape we will look at that in more detail. Here is part of the sprocket signal as we come to the end of the feed-in tape and see the first few holes. The deltas show the minima and maxima where the line crosses zero. We are interested in transitions from negative to positive since these will be minima. That is dark holes on the paper tape. However we also get a number of these in the noise period at the start of the tape. We now look at the minimum delta achieved since the last minimum to see if this is a real signal. The blue line traces this value which resets at zero each time we encounter a minimum. We can see that the noise for each value never goes below minus two. While for the real signals the value is always less than minus five. Choosing a castle point in the riddle minus 3.5 allows us to simply distinguish the signal from noise. We can see that we have found four sprocket holes. We now have everything we need to determine if data bits are set. This is the deltas for the sensor for data bit two. We overlay the sprocket signal with the delta. Each time we find a sprocket hole we look to see whether the delta for the data bit two has gone below minus 3.5 since the last sprocket minimum. If it has we have a dark hole and if not we don't. We see that for data bit two we have a sequence of four zeroes four ones four zeroes four ones four zeroes four ones four zeroes then nine ones and so on. Looking back at our original oscilloscope image we see that this is identical. We have a reliable if relatively slow paper tape reader. It is simply a matter to drive the values out of the digital pins via a five volt to 3.3 volt converter and into the edsac running on the mystone board. In fact it's so simple that we haven't actually yet done it so that will be the subject of a future talk. My assistant will now give a demonstration of the paper tape reader in operation. The paper tape contains a single binary coding of the numbers zero through 31 and some random values to represent a program. Each time a character is read the signal LED will flash and since this is for demonstration purposes the value read will be displayed on the Arduino serial monitor. For those of you at the front you may be able to see those values but for those of you at the back we have printed out this on screen. A 3D printed case was used to minimise the amounts of background light entering the chamber where the holes were being sensed. The printer used was a Prusa Mendel Repwrap and the components were designed using OpenScad written by Clifford Wolff whose program tick approach makes accurate shape design easy. The paper tape reader uses a rubber wheel on a motor to pull the tape under an array of light dependent resistors. The signals are then processed by an Arduino. A switch and a button on the top allow the paper tape to be pulled through in either direction with a read speed of around 10 moles per second. The wavelength emitted by the LED is chosen to match the maximum sensitivity of the light dependent resistor. In this case 550 nanometre green light oh no no no sorry got a bit confused there I'm now going to look at how we recreated the delay lines using edsac. The original edsac delay lines used sound to store data bits in a loop because sound is slower than electricity. Many bits can be stored as sound pulses in a relatively short tube. Piezoelectric transduces were used to generate the sound pulses at one end and convert them back to digital signals at the other. The delay lines were filled with mercury because the acoustic impedances of mercury are almost exactly the same as that of the piezoelectric crystals. This minimized energy loss and echoes. Large transduces were used to create a very thin beam of sound and avoided echoes from the size of the tube. But to get the acoustic impedances to match as closely as possible the mercury had to be kept at a constant temperature of 40 degrees Celsius. This made servicing the tubes hot and uncomfortable work. The piezoelectric transduces operated at 500 kHz. The speed of sound in mercury is around about 1,450 metres per second. So, in a five foot tube they could store 512 bits. Hot mercury is not the most suitable fluid for schools to obtain a news. What should we use instead? Alan Chewing was involved in design discussions for edsac and was alert to the challenges of using mercury. He advocated the use of gin, which he said had alcohol and water in just the right proportions to give a 0 temperature coefficient of propagation velocity at room temperature. But enough gin to feel even a modest tube is still quite expensive. So how about wine? Or to be really cheap beer? Or since we are targeting schools perhaps Pepsi is more suitable. Please, getting good fluid seals and waterproof components was a bit of a problem. In the end we chose air for a number of reasons. Firstly, it came ready packaged with a tube. Secondly, if you spilt it it didn't make a mess. And thirdly the speed of sound is quite low through air. So you can operate it at audible frequencies. Piezoelectric transduces and receivers are very, very expensive. So we were replaced by a normal speaker and microphone which yielded a delay line which could hold up to 49 bits. However we found reflections and echoes mean that even a 10-bit word would degenerate quite quickly. To minimise the harmful echoes we thought of using parabolic mirrors at each end of the tube. The speaker and microphone face their respective mirror. When the speaker admits a sound it reflects off its mirror which focuses the sound in the other end of the tube where a parabolic mirror focuses the sound on the microphone stray reflections are minimised and being at the wrong angle will not be focused on the microphone in any way. But in the end just stuffing the ends with acoustic foam seemed to work really well in a quiet office. The microphone is connected to ground via pull-up resistor but needs amplification and filtering so it can be passed to the Arduino as a square wave. I used a simple circuit based on a standard audio amplifier chip with a variable resistor used to control the volume of the signal The whole circuit fits easily on a standard strip board The yellow line is the output straight from the microphone and the blue line is the output from the amplifier signal The blue line is four times larger than the yellow line per division As you can see there is a large change in amplitude yielding a clean digital signal for the Arduino On the other side the circuit is a lot smaller To prevent damaging the speaker or the Arduino the speaker's output resistance must match the input resistance of the Arduino The output resistance is 8 ohms hence a standard 10 ohm resistor is close enough My assistant will now demonstrate the delay line The delay line will repeat a pattern twice to make sure that the tube is filled with information After 10 loops of the pattern there will be a pause This is to clear the echoes in the tube The pattern is a 10-bit binary number In decimal it is 592 You will hear a bleep for everyone and silence for every zero If the microphone works and other sounds outside the tube Sometimes the first repeated pattern is very similar If you want to hear the tube a bit louder Once this is all done come forward and we can show it to you again These peripherals are meant for education so the best way to use them was to run a tutorial course and include them as a resource This course is a course for education to Veralog using mice donboards and the EOSIS toolchain It coincided with the 60th anniversary of the British Computer Society which was founded by Maurice Wilkes With support from the BCS the event was organised for 80 students and hobbyists by the open source specialist group from the BCS The course combined introductory talks on FPGA design using Veralog with talks on the history of EDSAC Students were encouraged to bring up the EDSAC designs and interface them with one of the peripherals Much of the material I have demonstrated today came from that workshop In summary, EDSAC was first one in May 1949 It was one of the first general purpose computers to be used and was open for the University of Cambridge students and researchers Racing forward to 2017 EDSAC has been reimagined as an open source educational project for schools and hobbyists It uses three physical peripherals and an air delay line to aid in understanding the key parts of the original EDSAC The international open source team who helped me put together the reimagined EDSAC Alan Wood and Ken Boke who created the Mi Storm, Clifford Wolfe who created Deosis and Open Scad Bill Purvis and Hatham Carchwala who converted EDSAC into Veralog Dan Gorange and Peter Bennett who designed the peripherals Everyone at Chippac who put the peripherals through their paces and finally I would like to thank the Embercosm team Without them I would not have an opportunity like this I hope I have managed to inspire you to recreate the project at home This project is always looking to be improved Any patches are welcome All the sources are on Github. Thank you for listening We still have time for some questions Please wave and we'll come to you Hi, have you collaborated at all with the National Museum of Computing who are working on their reconstruction of EDSAC Much with the reconstruction but we did use Bill Purvis' version which he used for the recreation of the replica I like the way you're trying to introduce the physicality of the original EDSAC into the system Did you consider whether it was possible to introduce a valve in any of your design Introducing a valve It was quite difficult to make a completely filled tube It was hard enough to fill the delay line with water It would have been quite a lot harder to remove all the vacuum, all the air from the tube as well to create what was necessary for the valve to work Do you know how it's working the rebuild in a bledgelebar the rebuild of the EDSAC in the museum is it in good shape or I can't quite hear, so I repeat the question please They are rebuilding EDSAC in a bledgelebar How is it going now? Hopefully as soon as possible They did say it was going to be in 2017 but it's kind of shifting forward a little bit Tomorrow it may be out in a couple of months time I don't really know much about the hold up but I'm really looking forward to it Really? No more questions? Seeing as the rebuild has been mentioned Are you going to try running any of the code that's been developed on your little EDSAC on the real thing once it goes live? Because I know one of the things they're looking for is they need code to run on the rebuild to actually have it do something and I think one of the things they were quite keen on doing was having children working on so that they could run on the rebuild You developed this as an educational resource for kids Are you planning to run any of the programs that they write and get working on this on the actual rebuild? We are hoping to run perhaps a couple more educational programs once we've managed to interface everything together and maybe a couple of you guys could help with that Eventually hopefully everything will come together and we'll be able to do it in an actual school or in a maker space or at home or in a church Are there any more questions? So we've still some minutes left for your time so if anyone is interested I think to have a closer look at the things you brought with you there is still some time left for that before the next talk starts Thank you very much