Surely that runs the risk of alcoholics breaking into the system and drinking the data?
If Alan Turing had been in charge of the EDSAC (Electronic Delay Storage Automatic Calculator) project in the late 1940s, the first computer memory might not have been based on mercury - but on a good gin. In his Turing Award speech in 1967, Sir Maurice Wilkes, the actual EDSAC project chief, recalled Turing's input on …
I suspect the final decision was based on the credibility of using a very expensive, hard to handle "scientific" substance rather than a cheap, easy to use one that wouldn't have impressed the people providing the funding.
In a 13A fuse, the substance that absorbs the energy when the fuse blows (and for which I don't think anyone ever found a better replacement) is sand. But the literature has to refer to it as granular silicon dioxide.
You are correct of course, but perhaps I should explain that the preferred material is in fact silicate beach sand, sieved to get the right grain size, and is not manufactured. Early literature tried to give the impression that this was some exotic substance, not something that someone had shovelled into a van on the Isle of Wight.
I suspect it probably had more to do with reliability. Sure for the first test it probably would have worked. But do you really think it would have worked on the fifth day? Drinking mercury will kill you pretty quick. Gin in the proper quantities is quite different. And the savings on the bar tab could have been huge. In fact, it might not even have worked on the second day.
During the 60's and 70's many weird and wonderful technologies were developed to solve the memory problem of basically how to store a page (about 80x24 characters) of data in the terminal.
IIRC Univac went with a "Torsional" ultrasonic delay line with a clever coupler that converted the efficient driving modes to the torsional wave. Torsional waves were slower so more delay (or more characters) per unit of (NiCr or NiFe) wire.
Keep in mind in 1970 an Intel 1024 bit DRAM was cutting edge stuff. You'd need 16 for the characters, 16 more if they each had an individual "attribute" byte associated with them.
Good luck with getting the model working.
I don't really delve much into electronics, but a delay line does nothing but just take a little while to transmit a bit of information and then retrieve it automatically at a later time, which you can use as a "refresh" memory kind of deal? Cycle it enough and you can keep refreshing it with the same data while also being able to pull that data off any sensor you're using and send it to the rest of the computer. Is that right?
In that case, mercury, or even alcohol, seems an incredibly complex way to achieve this, even in an era void of semiconductors (how do you propagate the signal back to the refresh AND somehow read from it without amplifying it along the way?). In fact the whole concept of acoustic delay lines seems... too advanced for a relatively simple task. Was there really no other simple way to do this? I'm honestly asking out of curiosity because it seems a most odd situation to result in rooms full of mercury-filled tubes just to delay a signal by a relatively small amount.
Are we in the era of analogue computers? Could not a (more) primitive physical system have been available?
I sometimes use the concept that a computer can be easily replicated using pieces of wood, falling water or just ball-bearings to achieve the same *kinds* of calculations. It's a feat of engineering, no doubt, but early mechanical computers existed using much more rigorous build processes, so there's nothing stopping you making a simple binary adder or equivalent using the most basic of materials. But does it really necessitate a mercury/alcohol filled tube to delay a signal for a short while?
I understand the analogue-signal requirement, and maybe the incoming signal correlated directly to ultrasonic frequencies - coming out of a radar system - but while you're waiting for them to propagate through a fluid, is it really particular to mercury or alcohol that something could be made to do that. Surely, even air-pressure in an appropriate sealed tube would do something similar, or a more basic hydraulic system of just about any design (The article states minimal energy loss and a fast speed of sound as the primary factors, but surely a fast speed of sound in the fluid you're using is a BAD thing that means it needs to be longer and refresh more often, and energy losses would be higher in a system moving a much more dense fluid than air - or whatever gas?).
Would this not have been possible with 1940's-era speakers and microphones and a sealed tube of some fixed length manufactured by, say, a trombone maker? The sort of thing we've had since the 1800's and requiring no specialist materials?
Dammit, it almost makes me want to go and tinker myself to find out what the problem is.
(I'm reminded of a small clock on display in the British Museum. It has a balanced tray, with a path inscribed on it, and a ball-bearing. The ball bearing slides down the path, taking 15 seconds to do so, and when it hits the end it nudges a lever that tilts the tray the other way. The path reverses, the ball goes the other way, hits another lever, the tray tilts and so on ad infinitum. And it turns out to produce an amazingly accurate (and beautiful) clock. It was made in about 1805.
(how do you propagate the signal back to the refresh AND somehow read from it without amplifying it along the way?)
You *do* amplify it along the way, using a little gizmo known as a "thermionic valve". Amplification didn't begin with semiconductors, which your question seems to assume.
I suspect that the advantage of a relatively stiff viscous fluid compared to air has to do with getting less multi-path reflections off the side of the channel relative to the main wave propagating down the center of it.
There was a lot of research in to mechanisms for storing data, because it was a previously untackled problem before. Telephone and telegraph systems didn't store data, just transmitted it onwards to the next part of the system.
For fast access you need a pure electronic bistable circuit to record a binary state, but these use several valves each, and so you only used them on the internal registers of the CPU itself.
Another, a bit later, was to use a CRT with long persistence phosphor. You mounted a 2D array of photodiodes across the screen and implemented a refresh cycle circuit.
If you look at the transistor structure of a register it looks like two inverters driving each other so, yes, they do amplify the signal around and it stays stable. Computer programs only work because they do stuff in the right order so you need to delay the logic circuits so that everything doesn't happen in random order. Flip flops are used now with a clock in the GHz range. These devices ran at kHz and could also store more than one bit in each loop. Although they are called delay lines they were used because they were fast (in comparison to relays) and low power (in comparison to thermionic valves).
The point is that the delay line doesn't store just one bit - it stores a whole bunch of 'em, all running in one end and out the other, being amplified, and shoved in the front again.
Think of a drum memory (and the story of Mel!) wherein the processor has to wait until the required bits arrive at the read head again.
p.s. Congreve escapements are notoriously unreliable timekeepers: they're sensitive to dirt in the tracks and to external vibration. But they're very pretty, and somewhat soothing.
It's all a problem of timing. You not only need a delay which, as you note, could be achieved by any number of Heath Robinson type contraptions. You need a delay that reliably takes in a signal at clock n and spits it out again at clock n+x. Mechanical systems are very bad at that, especially when the clock period is very short.
You can actually experience this first hand if you try building computers in Minecraft. The electrical signals propagate quite slowly and worse, they propagate at variable speed depending on server load. It's insanely hard to build high clock rate computers under those circumstances.
A simple bistable device could be made from contemporaneous devices such as a couple of valves ("tubes" to Americans and other aliens) or or relays per bit, the problem is one of scale, you could either have a room full of racks of relays or valves with the inevitable reliability and heat-dissipation problems or you could have a couple of tubes full of Hg which if handled correctly is quite safe (well it was in the 1940's, I wonder what changed?).
Also it's far more elegant which should always be an important consideration.
Many years ago, in a very large office which didn't have enough storage space, I worked alongside someone who had masses and masses of documentation - manuals, reports, program listings, and so on.
His solution to the shortage of local storage was to make up parcels of documentation addressed to himself, and leave them in the secretaries' office as outgoing mail. At any one time he would have several such packages "stored" in the internal mail. They would, of course, return to him in a day or two - and that was an acceptable retrieval time.
He claimed to have based this on his knowledge of mercury delay line technology.
He is long gone, and nowadays I don't even have a desk, let alone cupboards....
In a similar way, it was claimed that when the Japanese claimed to have invented just in time manufacturing, they did in fact have conventional warehouses. They were, however, in the form of articulated lorries stuck in the traffic jams around the major cities.
At one time, many governments have had "inventory taxes", paid on the value of goods available for sale, but not those in transit. At least one company I know of found it worthwhile to rent semitrailers, load them with goods for "inventory day", and unload them the next day. Apparently this started out with actual transit, but some legal decision held that just being loaded _for_ transit was sufficient to dodge the tax. The one company I know of doing this was a major computer manufacturer, since deceased, whose first computers used delay-line memory.
As for "those oldsters", note that the maximum latency (in CPU clock cycles) for a memory access today is in the same range as that of a delay-line or drum-memory computer. That's why "All programming can be viewed as an exercise in caching".
And CRT (Williams-Kilburn) memories did not use photodiodes. The phosphor itself stored the "bits" via secondary emission. Early analog-addressedd DRAM.
JIT manufacturing was a collaborative development between the Japanese who needed to rebuild their industry after WWII and US manufacturing consultants who came from the world of Ford's assembly lines. Japan also had very few natural resources, so they needed to import everything and imports were expensive. That meant i) they needed to use imports more efficiently and ii) they couldn't afford to make things to send to warehouses because they needed to sell as much as possible, especially for export - to pay for the imports. If you read the history, though, JIT/Lean/Toyota Production system wasn't implemented overnight and it took significant re-training of all levels of manufacturing staff from CEOs to workers via managers.
But yes, it is true, JIT is dependent on efficient transport mechanisms and heijunka (re-introducing batches and tuning batch size to smooth production flow while keeping as close as possible to the target takt time) otherwise you can get caught with no input materials or a backlog of output very very quickly.
Come on guys, you've been trying to get paris into space, how about prooving that Gin is good for memory..
You could even try differant brands of gin!,
For the love of God your jornalists and you haven't realies the potential for the tax deductable after experiment party!!
- PS if you do try and compare with mercury delay pipes, make sure those pipes are clearly marked, locked down, shackled, painted a distatesful colour. Just to prevent over enthusiasic consumption at the after experiment party. Note mercury is not a good drink, even with tonic..
It was observed in the 18th century, when it was the only known treatment for syphilis, that a night of Venus might mean a lifetime of mercury.
However, you would need to be very drunk indeed not to notice if you were drinking it. The wine glass weighing a couple of kilos might be a clue. And the average drunk would really struggle with the beer glass (about 7 kilos).
But...nasty, yes you are right. I was comparing notes once with someone else responsible for radiological protection. "Oh," he said, "Tritium doesn't give me any worries at all. But we have mercury on site and that gives me nightmares."
So I did an audit. We turned out to have a test machine made by an "engineer" (ex TV repairman) that did some moderate voltage switching (about 5000VDC). This was accomplished with a wooden box full of large glass bodied mercury switches each of which was attached to a rotary solenoid. If one of them ever broke, which become increasingly probable as the glass aged, about 100g of mercury would spill on a large production floor and a factory would have to be evacuated.
The best I could do was to get it stood in a polypropylene bund with a warning on it, and wait for the product concerned to be discontinued.
In 1960 our Physics teacher was introducing us to various physical properties of materials - like expansion and density.
At one point he produced a beaker of mercury to show it was a heavy, liquid metal. In a vacuum tube it had a meniscus, opposite to that of water, that showed that it was "dry". He probably showed us heavy objects that sank in water and floated on mercury. I remember we had fun chasing small beads of mercury round the bench top - presumably why it used to be called "quicksilver".
... lodged in Cambridge. For some reason the guy that owned the house had a plasic bottle of mercury in the cupboard on the stairs - must have been a couple of kilograms in weight.
Mind you, he also had a couple of gallons of neat caustic soda in there too - he tried to clean the bath with it and took the enamel off back to the metal ...
The English Electric Deuce was programmed using punched cards. The columns were apparently printed with timings. Some calculations involved cleverly picking chosen data off the mercury delay lines by the program timng where it had reached in its circuit.
IIRC the program store was very small - and a sequence of cards had to be read at exactly the right time for the next part of the instruction stream.
My boss Maurice Marvin mentioned these insights to me about 45 years ago when I was doing system support on the emerging 3rd generation System 4 machines. Deuce was still doing the payroll about that time.
The Deuce mercury delay line units looked like large mushrooms about 4 feet high - each with a cable plugged into a 13amp floor socket for the heater. Apparently the cleaners had to be taught not to unplug them when looking for a convenient socket for their vacuum cleaners.
When you add the tonic, you need to make sure it is all sealed up so the bubbles don't come out of solution!
All of this begs the question (stated above): When will someone try this out. The research questions:
Is Gin better than Vodka? Does vermouth make a difference? Olive, or Onion? Shaken or Stirred?
Hb. Chem.& Phys. 53rd Ed., E41 gives the velocity of sound in m/s at 25+t°C as:
Water (distilled): 1496.7+2.4t
--> 37.5% ethanol, 62.5% water 1388+0t (estimated)
So Turing was right. Gin (and Vodka) are OK. Vermouth (16-18% ABV) won't work in a delay line.
"Ever the pragmatist, Wilkes was not too concerned about the elegance of the storage medium - he just wanted something that worked and was reasonably reliable."
Then, by that standard, every IT person is a pragmatist sunshine! :)
One does wonder if all that mercury was disposed of properly when they broke the system down.
In the book (named by the posting title) there is an example of programming a delay line computer. Because the delay line cycle was so slow compared with the instruction execution time, each instruction gave the address of the next instruction to be executed. If the instructions had been contiguous in memory, as modern machines are, the execution rate would only be one per cycle.
Optimisation of the program was done by calculating each instruction time, and the timing of collecting and storing the data that it would do, and laying out the data items and the next instruction so they would be available as soon after they were required as possible. Each address was the tube number plus the word number so there was some flexibility.
The delay lines needed to be short to give faster cycle times and long to give more storage. Having more tubes meant that there would more often be incorrect synchronisation.
Oh dear. So many mistakes!
As any fule kno, the first working memory used by a working stored program digital electronic computer was the Williams-Kilburn tube - used by the Manchester Small Scale Experimental Machine (SSEM aka Baby), which executed its first program on 21st June 1948. There's a replica at the Manchester Museum of Science and Industry - not sure if it's still working, though.
The mercury delay line memory used by EDSAC (widely considered the SECOND full scale stored program digital electronic computer, after the Manchester Mark 1) was developed not at Cambridge University here in Blighty but over the pond by J. Presper Eckert at the University of Pennsylvania's Moore School of Electrical Engineering during the Second World War for use in radar to remove ground clutter.
When Turing made his boozy suggestion, acoustic delay line memory was proven working technology - working with mercury.
Eckert was one of the bods behind the design of EDVAC, which was the foundation of the EDSAC project in Cambridge.
Eckert and his colleague John Mauchly were behind the mercury delay-line memory BINAC computer, delivered to Northrop Aircraft in September 1949. If it had ever worked properly after delivery then BINAC would be in the running for the title of first full scale useful stored program digital electronic computer, since it ran its first program in February 1949 - before the Manchester Mark 1 became operational in April 1949 or EDSAC became operational in May 1949.
ED 13 should note that the Williams-Kilburn tube (the original CRT memory) operated electrostatically - no photodiodes required - and provided both the fast main store of the early Manchester computers as well as the fast internal registers used by the processing elements.
(On the Manchester Mark 1, the CRT memory could be considered similar to modern high speed cache, with the slow but larger mag drum store being considered similar to modern main RAM. File store in the modern sense could be considered as being provided by punched paper tape.)
Williams-Kilburn tubes have various advantages over mercury delay line memory: faster, random access rather than serial access, not needing ovens for temperature stability, needing lesser PSU stability, and not needing large amounts of an expensive and toxic liquid metal. It's just that when the EDSAC project started, mercury delay lines were proven US technology and part of the EDVAC design which EDSAC was based on, while Williams-Kilburn tubes were a new idea still under development - details of which weren't widely available until late 1947.
..GEC, Coventry, once telling me how they corrupted 'programs' by jumping on the floor, under which were said delay lines...
Maybe he was after the gin, to which he was partial, esp. home-made Sloe Gin ( From him, I learned to make a 'Sloe pricker', from a plastic BNC socket cover, a box of pins, and Araldite)
They made a delay line based standards converter, so they could convert 59.94 Hz NTSC to 50 Hz PAL. It essentially involved delaying the video by a variable amount of time and dropping frames. This was done with a series of quartz delay lines and an additional smaller delay line consisting of inductivities and capacitive diodes.
You can often see the results in old issues of "Top of the Pops". It's not perfect, but _way_ better than anything that existed back then. The next best alternative was film as an intermediate.
Biting the hand that feeds IT © 1998–2019