The NOR gate is a circuit which produces an output signal only when there are no signals on any of the inputs. If you are short on time you only need to grasp that, in principle, triode valves switch OFF with a negative grid voltage, and ON with a positive grid voltage.
The Valve.Computer is created from 560 of these NOR gates, and each one uses both triodes in the 6N3P glass tube.
5 volts on any input turns the first triode ON. A voltage dividing trimmer sits between the anode and -40 volts. Its output voltage is set to -2v which turns the second triode OFF and keeps the output LOW. On the other hand, if all inputs are 0v or below, the first triode is switched OFF, which increases it's resistance, and anode voltage, raising the trimmer output voltage to a positive voltage, which switches ON the second triode, creating a current through the 51k load, making the output HIGH.
So it only has a HIGH output if, and only if, all inputs are LOW, which is the NOR gate function.
I sourced the 6N3P thermionic valves mainly from Ukraine, but also from Slovakia, Poland, and Romania. They were produced by several East European factories and differ in performance.
I wanted to mitigate the gain variations of the 6N3P valves as simply as possible. All other considerations were secondary.
Normally each active component is identical to its peer, and you can accurately calculate the optimum value for a circuit component. The selection of values for the Valve.Computer NOR Gate was different.
I calculated the component values and tested the results, but in many cases the theory did not accurately match the practice. So I built a test rig with two variable power supplies to test the stability of various component values. I chose several thermionic valves from each source, ran the tests, and found a range of values that worked for them all. My final criteria was to select the optimum, lowest power, standard values for the components.
But what a palaver!
As the Valve.Computer is an original design I kept the number of sub circuits to an absolute minimum.
I think there is a simple relationship between the number of unique sub systems and screw ups.
This page contains all the circuits I designed for the Valve.Computer and the two prototype computers. I have checked and rechecked them, but please be kind if you find errors as I'm easily hurt.
Initially I tried various architectures with different types of gates, but they all became too intricate, and I failed to remember to “keep it simple, keep it clean”. Eventually I made a design just using NOR gates.
I modelled a thermionic valve NOR gate and I was able to test the design on a modern simulator, which just about worked, and so I built a 5 NOR valve test rig for a prototype register, and to my total amazement that also worked.
I recently discovered that a few incredibly important computers had designs based entirely on NOR gates. It goes to show that an electronics education could have halved the design time, it would also have filled this page with sophisticated technical prose.
They say you can never have too much decoupling, or was that chocolate?
Decoupling capacitors are extremely important, they provide a bypass path for transient currents which would otherwise cause voltage spikes on common power supply paths. Every Valve.Computer NOR gate has a 100nF decoupling capacitor to provide the bypass route to ground and also a 10uF, for local energy storage.
In an attempt to create a memory with no moving parts I have experimented with photocells illuminated by lamps and leds as experimental NOR gates.
A pair would be a simple SR latch memory cell. I built three, just to test the idea. The prototypes take over 120ms to switch, but they do form a stable ring oscillator.
I have yet to build a complete optical NOR memory system, but hopefully fibre optics will form the core.
The Valve.Computer also incorporates a bit7 carry forward register. The result is held and later used by the [ADDC] instruction, Enabling 16, 32 and 64 bit maths. I have recently considered whether 128 bits might work using using the Page RAM.
Yes ridiculous, but it would give you plenty of time to make a nice cup of tea, or maybe have a three course lunch with a friend.
Memory registers use over 400 thermionic valves in the Valve.Computer. Each register consists of 8 D latches except the Instruction and RAMpage registers, which only have 4. There are also several single registers. The [RAMP] instruction uses SPEED which sets the chosen oscillator and so the clock speed, and HALT which disables the oscillator outputs. There is also a bit7 carry register used by the [ADDC] instruction. All have a [CLEAR] to initially set the latch to a known state. They operate as conventional D latches, except that they are NOR instead of NAND, so the Load pulse is active Low. They input both data and NOTdata from 12 bit buses. and so do not require a NOT gate. All have a final active low Enable to bus stage, which also conveniently acts as a zero substitute on the output from the X and Y registers to the ALU.
I designed the ALU to only generate four functions, [SUM], [XNOR], [NOT] and [INC]. A combination of these instructions can produce Subtract, Decrement, and XOR. Any more complexity seemed superfluous!
The 8 bit ALU in the Valve.Computer uses 72 valves. The X and Y registers permanently feed the ALU with data, which the ROM microcode can substitute with a zero value.
Each ALU stage generates a Carry Out [COUT] which becomes the Carry In [CIN] for the next stage.
A [CSET] sets all ALU carries to 1, creating the bitwise XNOR function, The [CSET] is also used by the [NOT] instruction when, after storing the current accumulator value and also loading it in the Y register, the microcode substitutes zero as the X register output value and stores the [NOT] ALU value into the accumulator.
The Valve.Computer clocks produce the fetch/execute cycle clock signals from the selected oscillator. There are four clocks in series, each one halves the frequency of the previous one to produce the three bits needed for the eight microcode instruction steps plus the LOAD signal for the registers. Each clock consists of two SR latches, the first is cross coupled to the second and the second is fed back to the first. It needs to be setup very carefully. There are four phases to the clock operation, the first phase to setup is when the first latch sets during the stable high output of the second latch on the edge of the input signal. The third phase, the first latch reset, can then be set during the stable low output of the second latch on the edge of the input signal. Stable as a rock when done, but what a molarkie to setup!
The Valve.Computer has two oscillators, both are 3 NOR ring oscillators, each with 3 pluggable capacitor delays. Links on the top of a 10 valve auxiliary board select the capacitors and the buffers square up the rounded outputs of the oscillators, and provide isolation from a change in load. Three polyester 470pfs result in a frequency of 11.3kHz, two gives 16.9kHz and one 33.8kHz.
The second oscillator currently has three 10nf ceramic capacitors resulting in frequencies of 700Hz, 1.0kHz and 2.1kHz.
A simple NOR switching circuit feeds the clocks with the oscillator set by the SPEED register.
The logic levels of the thermionic valve NOR gates are nominally 0v & 5v and the fan-out is about 25.
A key component of the machine code is the [JUMPzero] instruction. If the accumulator value is zero the program branches. This circuit tests to see if the value of the lower 8 bits of the data bus is zero. The clock value used to to activate the last [JUMPzero] microcode is then disabled and the program branches to the operand address else the program continues. [JUMPzero] can be achieved by several conditions, including identical or complimentary X & Y Register values or if either the sum or individual value of the two data registers is either zero or -1.
The PONG program uses this instruction, it selectively branches the program to calculate the next location of the ball.
The Valve.Computer has a new system console, which lifts open from the front.
A top row of status monitoring leds can be patched to most main board test points and helps to find faulty thermionic valves, uncleared registers and timing issues.
The PSUs are behind the console, and have a capability to continuously supply 300 Amps. The console now only switches 12v and 5v, all 240v is direct to plugs.
The new 700Hz Reed Relay RAM boards are stacked to the right of the GUI, but sadly the RAM no longer makes a clicking noise. It is much faster but only buzzes very quietly and not the good old click and bang of the subminature relays. It is though, a good excuse to add a new sound port to make lots of other noises.
The Valve.Computer has 16 single step instructions for data storage, data manipulation and program control.
The instructions are [LOADA], [LOADX], [LOADY], [STOREA], [JUMPzero] a conditional jump to the operand address if the Accumulator is zero, [GOTO], [INPUT] & an input next cycle Flag, [OUTPUT] & an output next cycle Flag, [ADD], [XNOR], [INC], [NOT], [ADDC] which is [ADD] plus carry in, [GUIW] the GUI relay RAM write, [GUIR] the GUI relay RAM read, and [RAMP] which sets the 4 bit RAM page Register, plus the Speed, Halt, Sound and Spare registers.
I hope in future to use the 1 bit Sound output as a control register to change the output ports into an 8 bit sound port.
The finest 6N3P thermionic valves were selected at manufacture for military use, with up to 5000 hours life expectancy and printed with an extra code (Cyrillic 6Н3П-ЕВ). The rest were for domestic use, and with the ability to operate at over 210Mhz, the 6N3P was used in many 1960s East European VHF radios, televisions and military equipment.
Each triode can individually source over 22ma and so can easily switch a reed relay.
The basic, domestic quality thermionic valves have codes for a projected life span of either 1500 (6Н3П-Е) or only 500 hours (6Н3П). Held in stores for over 50 years, quality stamps may have been accidentally altered, so life expectancy may be questionable, both for the valves and for me!
I spent a lot of time designing the PCBs. I tried to make the boards both robust enough to handle the large currents and configurable enough to simplify the build.
The 8 main boards measure 476mm x 393mm (18 inches x 15 inches), each hold either 60 or 70 thermionic valves, weigh just over 2Kg and are designed in 3 sections.
The central section of the main board processes a single bit of the data with thermionic valves configured for 1 bit of the accumulator, and X and Y data registers, complement data, 1 bit of the ALU, program counter, memory address register, instruction register, plus single input, output and GUI read and write buffers. There are also double latch clocks on boards #0 to #3 plus ROM address decoders and a further 5 NOR gates to process ROM microcodes.
Boards #4 to #7 have empty clock sections.
At the top of the boards are two 17mm wide heater supply tracks, which can conduct 25 amps whilst self heating about 5 degrees above ambient. The heater track pair are fed from the top screw terminals, via a quad 1mm cable from the 60 Amp power supplies. Pairs of 1mm tracks each supply 5 thermionic valves with 1.75 Amps via an SMD fuse. There is a 0.2 voltage drop along this heater feed.
The bottom section has the inter board connections and a ridiculous number of test points. A 280 way bus connects all the boards and each board is configured for its own needs. The data bit, compliment data, register load and Enables to bus, input and output commands, ALU carry in and out, HV supplies, and all the other appropriate signals are connected by several small mezzanine boards which act as two dimensional jumpers.
Each board is mounted onto the 4mm acrylic wall panel using sixteen 3mm x 20mm offsets. The 190cm x 130cm wall panel is attached via three 2m x 30mm x 30mm aluminium box sections to the wall. The total wall load is about 31Kg and fortunately, the wall is made of brick.
Currently the main memory is a 700Hz hybrid memory system using thermionic valve address, clear, read & write NOR gates coupled to reed relay memory cells built on separate stackable boards.
The Valve.Computer also has 8 bits of valve RAM, memory switches that can access 64 bits of relay RAM and upto 4K of paged NVRAM.
The additional 60 valve memories used as data registers within the Valve.Computer are described in detail above.
Reed relays operate much faster than the little blue HK4100F subminiature signal relays but they are more expensive, require a considered PCB layout, and sadly they are very quiet.
Normally closed reed relays are available, but for simplicity I chose to use only normally open designs for the Valve.Computer and let the valves do the additional computation.
I simply could not understand relay RAM.
I looked at several examples online, but I had an enormous problem interpreting the relay schematics. I was so unsure of my design that I added 16 miniature 3 way slide switches to all the prototype computer RAM boards so I could set and test the relays independently of the signals from the computer. Daft thing was, it all worked first time!
Due my lack of understanding of the relay schematics and how a relay RAM works, I decided to designed my own from scratch. I found even drawing the relay schematics difficult until I realised that a relay is just a type of transmission gate, and then the penny dropped. Forget about the coil and bent bits of metal and just consider the relay as a rather special transmission gate. One that incorporates the benefits of a bidirectional control signal with good hysteresis, 150 milliohms transmission resistance, and a small operating delay. What a fantastic device. Normally transmission gate latches require 2 additional NOT gates to add a feedback delay but the reed relay has a small, built in delay. Simplicity itself!
For anyone like me, who finds the relay RAM concept confusing I have drawn this simplified schematic of the RAM that I designed for the prototype and use in the Valve.Computer.
The Write and Address Select commands route the Data to the RAM cell, which stays latched when both commands are removed because the RAM cell output remains high for a moment and feeds back to the RAM cell input. Each RAM cell is read by selecting its address and activating the RAM Read Control, and the cell is cleared by removing the Address Clear signal. That is it, easy peasy!
All signals are Active high or Open Circuit (no active Low). The Address Clear and Address Select both act on the RAM Address byte whereas the Read and Write act on the bit.
In the Valve.Computer two clock cycles are required for each read and write. The GUIR instruction microcode first reads the operand RAM address and secondly loads the data into the Accumulator. The GUIW first erases the reed relay RAM at the operand address and secondly writes the Accumulator value to that Memory cell.
I still find it amazing that the 8 memory cells of each byte of the Relay RAM can be cleared and then written in parallel more than 700 times each second. The memory read action could be even faster, but as the Valve.Computer uses 2 execution microcodes for all instructions, the full read cycle would still take 1.4ms, the same time as a write.
The 700Hz continuous repeat write speed achieved by the RAM, is shown here with the write pulse below.
I since have also tested the write speed at 1000Hz, they do work in a single write but not 100% in a repeat write test. The read was stable at 1000Hz.
Relays bounce is not an issue if you simply wait half a read clock cycle to load the data onto the databus, but the back electromotive force is normally a real pain and the negative spikes can clearly be seen on the display. They are due to the collapse of the magnet field when the drive voltage is removed from the coil by the clear pulse, shown here below the memory trace. The collapse of the magnetic field induces a negative voltage spike in the same coil. This can easily damage electronic equipment and usually a diode is used to convert this unwanted current into heat. The speed of the relay is reduced by this quenching of the back EMF, but for any NMOS driver or CMOS input this protection is a must, as they do not like minus 30 volts up 'em.
Valves, on the other hand, take it in their stride, so that the Valve.Computer reed relays are able to run as fast as possible without any back EMF protection.
Reed relays are susceptible to magnetic effects which could degrade performance and produce memory errors. The prototype boards were all tickety-boo with a side to side relay configuration and a centre to centre separation of 12mm. But I did not run any tests deliberately activating adjacent relays. The Valve.Computer Reed Relay PCB design has the same parallel 12mm alignment but hopefully the reed relays have a reduced magnetic interaction due to the staggered layout, which increases the coil centre to centre distance to 15mm.
But I still have not run a proper test, maybe one day!
All the valve relay drivers are simply NOR gates that have been set for an 8 volt output when driving a 1K load. I tried to keep the common anode relay driver grid voltage near zero, and so from the spec sheet I expected a slightly higher off load voltage, but the actual 51k load outputs are around 15v to 20v. The oscilloscope trace shows a typical Valve.Computer 6N3P valve relay driver output both on and off load. The 12 volt, 1K coil reed relays are a dream to use and operate anywhere from around 8v to 30v, so they easily interface with the 6N3P valve Chauffeur!
[I know, a rubbish joke, but I do hope you found this page interesting and thank you for reading it]