Currently I am using 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, plus a NVRAM.
This second generation RAM board is developed from the combined subminiature and reed relay boards used in the prototype computer.
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 Fred.Computer and let the valves do the additional computation.
I simply could not understanding how a relay RAM worked.
I looked at several examples online, but I had an enormous problem understanding the relay schematics. I was so unsure of my design that I added 16 miniature 3 way slide switches to all prototype 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 I designed and used in the Fred.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 Fred.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 Fred.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 Fred.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 Fred.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 Chauffeurs [geeky joke] are simply NOR gates that have been set for an 8 volt output when driving [get it] 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 Fred.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!
Whilst swimming I suddenly realised that the Fred.Computer reed relay memory operates at audio frequencies and I thought what a marvellous idea it would be to simply put a speaker across a memory cell output and have a listen. Taking it a stage further, when dry I scribbled a short music program that wrote a word to a cell at 3 different rates as the notes, and 3 lengths of pauses to separate the notes into a tune. To me, it is a beautiful melody, that reminds me of the Twinkle Twinkle Little Star nursery rhyme, but I remain in a minority of one.
I always get my best ideas whilst swimming.