YG's 16bits Relay Electric Computer, rebooted

Similar projects worth following
For administrative reasons, I shelved the project "YGREC16 - YG's 16bits Relay Electric Computer". All the background is still available there and I continue working here instead.

This project is the first to implement the ideas of AMBAP, using old russian SPDT relays.
This is an experimental architecture, surfing the neovintage and electropunk wave that imagines a world without transistors. Old technologies can still yield new techniques, such as the Capacitively-Coupled Pre-Biased Relay Logic (CCPBRL), MUX trees with balanced fan-in, a new algorithm to compute the Game of Life, and I refine the YGREC's architecture!

It's also a warning for the young generations : Kids, don't waste your time with SPDT relays !
Use DPDT instead ;-)

You will find a lot of background information in #AMBAP: A Modest Bitslice Architecture Proposal and #YGREC16 - YG's 16bits Relay Electric Computer, this new project contains the latest developments since April 1st.

1. Evolution of the architecture
2. DRAM (again)
3. PROM boards
4. Assembler and disassembler
5. I hope that's enough
6. First DRAM array prototype
7. The Program Counter's circuit
8. Tubular bell
9. Flip Dots !
10. Electromechanical User Interface : the Assembler board
11. How to drive РЭС15 relays with a computer ?
12. Programming the YGREC
13. Carry chain considerations
14. I hope that's enough this time
15. The instruction register (cont'd)
16. Now it should be enough
17. I can see now
18. Instruction display panel
19. Relay DAC

Let's build a computer. Literally a bare metal computer, that is also funny and ridiculous !

  • Ridiculously slow (20 IPS ?)
  • Ridiculously greedy ( >200W)
  • Ridiculously noisy (OK, that's actually desirable)
  • Ridiculously incompatible (it's a brand new architecture called YGREC that I develop at the same time)
  • Ridiculously limited (512 words of DRAM, a bit more instructions)
  • Ridiculously unreliable (I added 2 parity bits)
  • Ridiculously useless (except to compute the Game of Life to prove my point that ridicule doesn't kill)...

It started almost as a joke one year ago with #SPDT16: 16-bits arithmetic unit with relays but the joke was on me and the fun, the learning, the charting of new design spaces have slowly changed my approach to computer design.

Now I have a complete architecture, an instruction set, all the needed essential parts, and I continue to put things together in the logs. In parallel, every new breakthrough is reinjected in such projects as #YASEP Yet Another Small Embedded Processor and #F-CPU (which was rebooted thanks to this project).

The YGREC architecture is pretty simple and designed to use as few resources as possible, yet run the #Game of Life bit-parallel algorithm efficiently (though it's not the original goal or purpose, there was none in fact, it was just "loooook those cute relays must be fun to use!")

The datapath is shown below : The 16 registers (including PC) are accessed as the SRCX operand while only 8 registers are read as the SRC operand (because such a large MUX uses a LOT of relays). The narrower SRC operand can be shifted/rotated, or substituted with an immediate value from the opcode. Both operands are then processed in the ALU (either in ROP2 mode, where all combinations are possible, or in Add/Sub mode where comparison, carry and Min/Max are possible). The result is checked for being zeroed, and sent back to the register set.

Really, it can't be smaller or simpler while preserving functionality (I'm not doing a Brainfuck computer, I'm interested in actual practical architectures)

The register set maps memory addresses, memory data, the Program Counter and Input/Output ports. Only R1-R4 and T1-T3 are "standard registers", making the YGREC a hybrid architecture: it looks like some classic RISC and also behaves like TTA (for operations other than Shift/ALU/ROP2). There is indeed no actual opcode, only 32 combinations for the ALU and 16 Shift/Rotate combinations to care about. The architecture is highly orthogonal, all the essential operations can be achieved with a combination of the available fields and special registers. All the instructions are predicated, except CALL which replaces the condition "NEVER". In this case, the result goes to PC, while PC+1 goes to the register set.

The YGREC can be reduced to MUXes and DFF registers (which can also be made with MUXes). This maps perfectly to dual-throw relays !

Some characteristics (if you haven't read the other project) :

  • Based on a bitslice architecture, with 18 bitplanes (16 data bits and 2 parity bits, one bit per byte)
  • Uses about 3000 РЭС15 relays (low voltage, circa 1989), a ton of diodes (but not for the logic), 10K capacitors for the dynamic RAM and CCPBRL
  • 24-bits wide RISC instructions with predicates
  • integrated debugger...
Read more »


DRAM Circuit to simulate with

plain - 5.57 kB - 04/26/2017 at 18:18


  • 3000 × РЭС15 Low voltage, russian SPDT mini-relay
  • 10000 × 100µF 25V electrolytic capacitors 5mm or 6mm diameter
  • 10000 × BAV99 Dual diode, SOT23
  • 768 × DIP Switches 8 positions (that should be enough for more than 1K instructions)
  • 200 × 1N4148 Diodes

View all 7 components

  • Relay DAC

    Yann Guidon / YGDES16 hours ago 0 comments

    Some people have already implemented relay-based DACs (such as the sound card of TIM-8) so there is nothing groundbreaking here. However, since it's my first relay-analog converter, a log was important! I had shelved the galvanometer-hexadecimal-display in the last log, but I now have the voltmeter so I had to test it.

    I chose a model with a wide display area and screws on the front so I can easily modify the display grades. It's lousy but it seems to work.

    Then I tested the display against a known good source and it actually works well.

    The resistance is measured with an ampmeter in series at 10V: 0.976mA, or R=10245 ohms. This gives an estimate of the required resistors in the R/2R ladder, the relative error and the power that it draws (hint: low).

    I don't know exactly yet how I'll provide 16V (the galva uses 15V but the R/2R ladder drops 1V minimum) but several rails that can be combined, for example the difference between the +6.6V and the 24V rail is about 17V, a series potentiometer (5K ?) will adjust the needle. The differential supply will certainly fluctuate quite a lot and heavy filtering (regulation, capacitors and/or diodes ?) will be required...

    The display is quite large and slow but cheap and easy to use so it is not suitable for the main display but can serve for auxiliary display...

  • Instruction display panel

    Yann Guidon / YGDES4 days ago 0 comments

    After I completed the instruction switch panel, came the necessity to build the corollary: the panel that displays the instructions. I had a sketch but soon realised that the system used too many relays, making it both power-hungry and expensive. For example, the hexadecimal display with 4 digits requires 16×4 LEDs, no big deal, but also 15×4=60 relays to demultiplex the nibbles ! According to the display:

    there are

    • 2 × MUX4 (3 relays each)
    • 2 × MUX8 (7 relays each)
    • 2+4 × MUX16 (15 relays each)
    • 1 × MUX32 (31 relays)

    so the total is 141 relays, or 4 boxes of 36 pieces, with some pretty high fanouts (despite knowing strategies to balance them). This also uses a significant amount of PCB surface !

    Discussing with @Dr. Cockroach about a similar concern with his #IO - The Inside Out Cardboard Computer - bis, (he uses a servo to point to one out of 16 numbers), I came to the conclusion that I should try a galvanometer. It's reasonably cheap and simple : a R/2R network driven by one relay per bit, and you're done.

    However readability is not great and despite having found a 0-15V model (which is great for displaying from 0 to F), this causes the other problem of getting 15V (actually 16 !) in the first place... See the rest in the log Relay DAC

    Then I realised that I got the initial MUX thing wrong.

    The light dots can be either a LED (which is a diode) or a Glühbirnchen (which can be wired in series with a diode). I couldn't find suitable flipdot elements (too large, harder to drive) so let's stick to diody elements.

    MUX4 isn't really a problem with only 3 relays but... This can be reduced to only two ! The LED can be arranged in a 2×2 array with one relay for the rows and another for the columns. It's only one relay saved per MUX4 but the fanin is just one coil per bit.

    The same idea can be extended to the MUX8 : one MUX2 for the rows and one MUX4 for the columns. But wait ! the MUX4 is already an array, so we need to go in the 3rd dimension... With LED, this is easy as connecting them in pairs with reverse polarity. As a result there is one relay for the 2 rows, one relay for the columns, and one relay that selects between +3V and -3V. 8 relays are saved. Splendid !

    For MUX16 however, I'm not sure a 4th dimension exists... This forms the bulk of the display, the CND and SRC fields can use single-dotted display but the IMM field (4 hexadecimal digits) would be awesome with 7 segments (I'm ok with the diode matrix). At this point I'm forced to use a "standard MUX4" for the row, with 3 relays instead of two, and one bit has a higher fan-in than the others (which is quite annoying because I'd love all the board's bits to have a single coil fan-in). I could cheat with a DPDT relay but no model matches the RES15's characteristics. Anyway, MUX16 is reduced from 15 relays to 5, thanks to diodes !

    MUX32 would use two standard MUX4 and total 3+3+1=7 relays instead of 31. Impressive what some careful design can do :-)

    Total : 2×2 + 2×3 + 7 + 6×5 = 47 (instead of 141), this is totally reasonable....

    I'm concerned however about the imbalance of fan-in between the various bits, this makes the design more complex. I could add resistors in series to balance the single coil signals but it's wasteful...

    Another concern is the digital display : bipolar matrices don't ease 7-segments decoding. I'm thinking about the #"Lixie", an LED alternative to the Nixie Tube approach but I'd need a tiny version and readability would be worse than the large displays...

    20170323 : OK, another simplification : what if the digital display was in octal ? This would save 4 relays (though unlike Seymour Cray I'm not an octal guy).

    Even more desirable: more input signals will have a fan-in of one coil.

    This leaves a couple of MUX16 and one MUX32...

    I'm trying to come up with a "4th dimension", and I was thinking about voltage or current. It's easy to turn a light above a higher threshold (add some diodes in series) but not to turn another off....

    Read more »

  • I can see now

    Yann Guidon / YGDES04/26/2017 at 17:59 2 comments

      @roelh was suspicious that my "new DRAM array" would work.

      It took him a while and conviction, and it was difficult to wrap my head around it.

      I'm too lazy to finish the prototype, but it would be useless for 2 reasons :

      1. Probing the capacitors would disturb the array and storage
      2. I don't have enough channels to observe a 16×16 array !

      So I resorted to simulation.

      Spoiler alert : @roelh was right. But why ?

      After I did the experiments, I realised that I was influenced by the flipdot array and impressed that it could drive several rows at the same time. Using the re-steering diodes makes sense.

      But the rows are always driven so the current "loop" that roelh identified don't occur. In my case however I leave many rows undriven. And the simulation shows really bad consequences.

      In practice...

      Just go to and "import from local file" the circuit that I have uploaded.

      Click on the push buttons and the SPDT switches to steer the current. You'll see the capacitors' charges vary. I added a bit of ESR to reduce the pulses. Be ready for some ... lag. The simulator gets confused after a few manipulations and I have already encountered errors...

      I have "probed" all the capacitors (with virtual scopes) to check that charging one doesn't influence the others.

      I have chosen a topology of double binary tree because I don't want the data to have too much fanout. Using the recent tree command topologies, the double tree is actually practical and has a fairly balanced fan-in.

      Conclusion : I must reorganise the DRAM geometry.

      The double-tree that selects the row is a big burden which shouldn't increase so I consider reducing the rows to only 8 per bitplane. In parallel, there are 18 bitplanes with 8 rows each, which amounts to 18×14=252 relays.

      As a consequence, the backplane must handle more columns : 512/8=64 columns, or 64 relays. It must withstand the simultaneous switching current of 18×100µF so I consider using a small series resistor to mitigate the transients.

      I think about building DRAM modules made of 8 rows and 16 columns.

  • Now it should be enough

    Yann Guidon / YGDES04/22/2017 at 09:03 2 comments

    That moment when you order 5 lots of 2K diodes, and you receive a pretty large reel of 10K diodes.

    "normal" reel size for scale.

    The DRAM should be covered now, and there is only 1 part and 3 soldering joints instead of 4 soldering joints and 2 parts.

    I also received the KOA diodes in SSOP24. The 1100 pieces should be enough for about 730 instructions. Good thing I extended the PC to full 16-bits width :-)

  • The instruction register (cont'd)

    Yann Guidon / YGDES04/20/2017 at 09:41 2 comments

    Here is one of the 24 bits of the instruction register.

    3 relays each amount to 72 relays.

    The instruction bus uses 6V signaling to provide more swing into the capacitor, but not enough to damage the diodes (the KOA diode networks are limited to 7V in reverse polarity).

    The sensor is made more sensitive by charging the capacitor with a higher voltage swing, bringing more charge to upset the coils. The middle point is centered by resistors, but large capacitors are required to keep the ends at a somewhat constant voltage. I got a stock of 1500µ capacitors so the swing ratio is at least 1/10.

    The reduction of the current on the instruction bus is pretty important. If 60mA per bit was required, then a INV instruction (FFFFFFh) would draw 1.5A ! Hopefully this is now reduced to about 10mA, or 240mA for a full FFFFFFh instruction. This increases the longevity of the parts...

    I'll have to prototype the above circuit !

  • I hope that's enough this time

    Yann Guidon / YGDES04/17/2017 at 21:23 1 comment

    I just received a pretty large package.

    That's 750 8-positions DIP switches.

    with 24-bits words, that's approx. 256 instruction words, or 4 boards of 64 instructions...

    Or 8 boards of 32 instructions, to fit in a 16×20cm board :

    However there's a little gotcha:

    The DIP package must be slightly too large because they don't fit well on a 2.54mm pitch board.

    Once again this proves that you must have your definitive parts before you commit to a final design ! I'll have to adjust the snap grid size when I do the PCB layout. This also shatters my hope to make a nice compact prototype, 2.4mm will be lost for every row...

  • Carry chain considerations

    Yann Guidon / YGDES04/17/2017 at 09:48 0 comments

      The incrementer and the ALU are becoming the critical parts of the whole system and the length of the carry chain will affect the operating speed. In itself, the clock speed is not a goal (the thing is already sooo sloooow that you can see it think, which is all the point). However, the faster it runs, the faster it can scan and refresh the memory, which is quit a big deal. If I can manage to get 25IPS (approx 2× faster than the Harvard Mark II), then it still requires 10 seconds to scan 256 words, 1/3 of a minute to refresh the whole 512 words of DRAM. And refresh only happens when the processor doesn't access the memory, a full refresh could last one minute. I haven't yet evaluated the retention time of the DRAM but I feel I'm pushing the design in uncharted territories.

      With 100µF capacitance, a 1µA leakage will make a time constant of approximately 100s which, depending on parts tolerance, where the leaks go, the actual rate and current of leakage etc. This is pretty close to the above quoted minute and I'm concerned.

      The new instruction register introduces a "latched sensor" which has several interesting benefits but one major consequence over the overal design: the processor is now pipelined, with fetch, execution and DRAM cycles being overlapped. The clock sequencing is pretty simple now : 2 phases, which directly drive the temporary storage caps of the DFF. There is no funky sub-cycles anymore. The complexity is now relegated to the software because data access and jumps are now delayed. I should add a 25th instruction bit to tell the program sequencer to wait for one more cycle until data are available...

      The speed is now limited by two main factors:

      1. the carry chain delay
      2. the time to fully charge the latching capacitors of the DFF

      As I have already examined, the charge time depends on several factors, such as the charging voltage and the series resistance, so they can be somewhat adapted. The carry chain length is however a more structural problem. If a relay switches in 4ms, a chain of 4 relays will need 16ms to propagate, and I would ideally keep it under 20ms. Add to this about 10ms to charge the caps then switch them to the coil, and we have about 30ms of cycle time, or 30Hz.

      To reach this speed, the critical datapath must be under 6 relays.

      My problem is that the РЭС has a rather low fanout capability and it wouldn't drive 15 coil loads. I guess a reasonable fanout is 4, though I remember I estimated 3 when I started the #SPDT16: 16-bits arithmetic unit with relays project.

      Of course, less fanout is better and the LSB relay (bit 0) will take all the heat, vibrations and load so it must be particularly carefully designed (or it might break).

      @Tony Robinson has explored a particularly interesting approach: a OR-chain made of diodes that could greatly accelerate the propagation in my case. However the diode drops are significant, let's assume 0.8V for the 1N4148 and this becomes quicly impractical. And the fanout problem is not solved, the first diode will take all the current to drive all the coils in the chain... I could cheat by using high power Schottky diodes though but it wouldn't remove the high current draw when all the chain is ON.

      Apparently I am forced to use a segmented approach. Naturally the 16-bits incrementer is split into 4 equally sized segments, but not identical: the LSB have a high fanout while the MSB have a high fanin. I can also mix with a diode here and there to reduce the complexity/size/cost/consumption a bit. With this scheme, the propagation time might drop to 2 coils delay, but the incrementer will use a LOT of relays...

      The linear approach is slow, the fast approach (O(n²)) is prohibitive, so a hybrid approach is considered, using 4-bits segments. Hopefully, the fanout is not excessive and the cascade time is 4 coils (in the 16ms range).

      I have a drawing in my head, I'll need to refine it...

      Update 20170420: I made the pictures !

      So it started with the carry chain of Tony Robinson's...

    Read more »

  • Programming the YGREC

    Yann Guidon / YGDES04/14/2017 at 09:17 0 comments

    So far the instruction format and datapath are well defined and it's time to think about the programming paradigms used by the YGREC.

    The architecture does every important thing (as far as I'm concerned) and I notice that it has no opcode.

    That's a bit unusual though it's reminiscent of the "Move Machine" ou "Transfert Triggered Architecture". Where the TTA/MM starts operation when operands are available and there are only 2 register addresses, the YGREC has 3 addresses and the operation is immediate.

    How should instructions be written ? There are two schools : the algebraic form (used by ADi DSPs) and the direct form (mapping the hardware fields). I like the ADi style (ah, the memories of the SHARC and ADSP2105)

    R1 = D1 or T1 SHR (IFZ)
    but it's more coherent to stick to the representation of the hardware assembler board...
    T1 SHR or D1 => R1  (IFZ)

    That's where I see that I should swap the ALU field and the SRCX field on the assember board. Too laaaaate... But I can move the ADD/ROP2 button. You will not notice much.

    There, I fixed this :

    The disassembly board must also be swapped :

    So there, you have everything clearly laid out, just write the code and enter each column in order, and you have your instruction in binary !

    Almost in the same vein, there is another question : how to encode NOP ?

    Starting with the #YASEP Yet Another Small Embedded Processor I set the following convention:

    • NOP is all-zeroes.
    • INV is all-ones

    NOP does nothing so it should be encoded in a way that does not modify the state of any register. Let's see how each field is affected :

    • SRC, SRCX, DEST = 0 should not trigger a memory access. For now 0000 points to A1 and it's not good, so let's swap A1/D1/A2/D2 with R1/R2/R3/R4.
    • LIRP : should be in PASS mode, R1 is not modified
    • CRSZ field : not affected because LIRP=PASS, but let's say 00=ZERO
    • ROP2 mode should be either PASS_SRC or PASS_SRCX. However these codes are assigned to 1100 or 1010 so two bits must be inverted...
    • The condition could be "NEVER" if there was one anymore so it's "always", so CND=000="always"
    • The Imm flag is 0, which says it's a register source

    In the end, NOP is equivalent to

    R1 PASS R1 => R1

    INV however requires a sort of reset of the program. This corresponds to hitting a place in EEPROM that has not been programmed and reads 0xFFFFFF.

    • The Imm flag is 1, which says it's a IMM16 source, which is set to 0xFFFF. Let's use this as the address to jump to and restart the program. A sort of implicit jump vector.
    • The condition is 111, which is the opposite of ALWAYS. We don't have "NEVER" anymore but we have "CALL" !
    • Call is a bit messy because it swaps the destination register. The result (IMM16=0xFFFF) will go directly to the PC while its old (contents+1) is written to the destination register, which is IO4 for now.
      Nobody knows what is hooked to this output register and it'd be a shame if something happened there. This is easily solved by swapping the IO and the T quatuors of registers, so PC becomes 1111.

    INV is now equivalent to

    FFFFh => PC (CALL)
    And the new register map is:


  • The assembler and the instruction register

    Yann Guidon / YGDES04/14/2017 at 07:24 0 comments

    I just finished the assembler board !

    I had to remove all the diodes and put new ones in the reverse (appropriate) direction.

    I'll need to label the buttons... but it's a hack ;-)

    I also wired everything, which makes the other side quite pretty as well :-D

    The shift registers are in parallel with the buttons, they are not completely wired because I'm waiting for their delivery. The 2×16 outputs drive the 24 bits of the instruction as well as disable the switches (through the small relay). 7 outputs are still available for other functions. It looks a bit like a mess because I tried to map the pins to the actual instruction bit number. There's no magic there, I should draw some schematic though. One day.

    And after all was said and done, I realised I should have put diodes on the outputs of the shift registers...

    Too late, I'll just remove the DIP chips from their sockets when they're not in use :-)

    But now I have to test the board and the instruction register's latch. This means, prototyping the 3-relays sensor and latch...

  • How to drive РЭС15 relays with a computer ?

    Yann Guidon / YGDES04/13/2017 at 07:18 7 comments

    The last log 10. Electromechanical User Interface : the Assembler board raises an interesting and important question : how can I control the relay-based computer with something like a Raspberry Pi ?

    I'd like to control and spy on the machine with a modern computer, replace the DRAM and the PROM with user-controlled modules that emulate them with SRAM, write or read registers, see the result of instructions, upload and save programs...

    I need to interface hundreds of signals from a 3-6-12-24V system (requiring 60mA drive currents) with the meek 3.3V CMOS GPIOs of today's generation.

    The last log implied that the instruction bus would "switch the high side". I already have the signal distribution paths figured out but I didn't think too much about the most favorable direction of the data signals. I just assumed the sense coils to be wired to 0V and the data coming from +Vcc. Simple.


    Then the building of the Assembler board made me reconsider my assumptions because I would like to "upgrade" the board to add a shift register that takes over the switches.

    All the practical electronic/IC solutions I could find are referenced to GND and "switch the low side". The sense relays require some significant current (60mA without prebias). In particular, this part is very well suited to the task:


    This obsolete chip is a 16-channel constant-current sink LED driver in 24-pin DIP. It runs up to 20MHz with 3V-5.5V logic supply but can sink up to 80mA per channel (20V maximum on the pins). I need 1 and half to drive the instruction sense relays... From the lower side.

    I have already wired the diodes of the switches for high-side, I can change them. But the ROM and PROM boards already have some parts in stock, that are meant for high-side switching !

    The solution comes again from exdwh's store !

    Isn't this cute ? Inside the KOA DN5Q24T, you'll find 36 diodes !

    DN5 diode network

    That's a big jump from the previous 2 diodes per package...

    The even funnier thing is that you can configure it however you want, with low side or high side: just connect the appropriate common rail to the proper voltage. The circuit is also (almost) symmetrical so a single footprint/PCB can accomodate both uses, just solder the package in the appropriate direction ! (ooooops I realise now it's a miroring and not a rotational symmetry)

    The leakage is too high and the voltage rating too low to help with DRAM. But if the voltage is kept low enough (less than 7V) this is totally suitable for the PROM boards, as the current is just enough and the spikes shouldn't last long enough to damage the diodes.

    Now, I must find a way to increase the sense coils' sensitivity...

    The current and voltage can be reduced with a switched capacitor cell which is almost the same circuit as the typical latch.

    • The hysteresis is held by 2 coils in series, so there is one output for the datapath control lines, and one for the disassembly board.
    • The middle point is tripped by a capacitor, switched by another relay. Just like the latch circuit.
    • The other side of the relay is held high by a pull-up to 6V. Value: t=RC, R=t/C, the charge is held in a 100µF capacitor (like most others). It must be charged in 20ms, which gives about 500 ohms. Rounding up to 600 Ohms gives 10mA when shorted to 0V, instead of the 60mA we wanted initially... the added diodes will reduce the current a bit more.
    • To increase sensitivity, the sense middle point is held at 3.3V by 2 resistors (on the 0V and 6V rails). In parallel with the resistors, capacitors stabilise the relays...
    • The input is held high by the pull-up, but overriden by the low-side switches (either solder blots, switches, N-channel FETs....)

    The sense coils become "instruction register" (using no less than 3 caps, 3 relays, 3 resistors).


    This is interesting because the capacitor switching can be controlled by the same clock as the register set (when enabled). This creates some pipelining, which makes scheduling more interesting... there is a fetch during exectution.

    Very interesting....

    Read more »

View all 20 project logs

Enjoy this project?



Frank Buss wrote 04/30/2017 at 07:40 point

Are you sure about 10000×100µF 25V electrolytic capacitors? Looks like they are surprisingly cheap, found them for 3 Euro-cent at Digikey ( ), but why not ceramic capacitors? Self discharge would be much lower and they would last forever. If you don't need 100 µF, it can be even cheaper, and smaller, e.g. 10 µF for 2.6 cent and 0805 package ( ). But of course, for such a quantity it might make sense to ask the manufacturer or search on AliExpress.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/30/2017 at 09:12 point

Hi Frank !

For the DRAM : 100µF is the result of my early experiments with CCPBRL. And yes they're cheap, I got them on eBay but at that price, ESR and leakage are not guaranteed :-P

Ceramic capacitors : not for this case, for several reasons. Main one being that capacitance drops with voltage. Ceramic capacitors can sustain the rated voltage OR preserve capacitance, not both for high value. 

25V is required because I need to charge the capacitor as much as possible to a) allow for some leakage and b) store as much energy as possible to upset the sense relay. The sense coil is biased around 12V so it needs a strong pulse to change state, lower than 12V or higher than 12V. So I charge the capacitors to 0V and 24V.

I should experiment with it soon...

  Are you sure? yes | no

Ulysse wrote 04/21/2017 at 16:34 point

I love relays.  Bravo !

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/21/2017 at 22:07 point

Who doesn't ? :-)

  Are you sure? yes | no

thekidtonystark wrote 04/20/2017 at 23:28 point

Do I have to put everything to a pitch board?

  Are you sure? yes | no

Dylan Brophy wrote 04/11/2017 at 13:15 point

Hey, I noticed you wrote "Kids, don't waste your time with SPDT relays ! Use DPDT instead ;-)". I'm just curious, but why?

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/11/2017 at 23:46 point

I explained this on the #SPDT16: 16-bits arithmetic unit with relays project :-)

SPDT is one switch per coil, DPDT is 2 switches per coil, better "fanout" and a direct reduction in the cabling and drive current. A MUX or adder uses half the number of relays compared with SPDT. You don't need hysteretic hacks. Etc.

But well, I chose the rope that will hang me in this project and I must stick to it :-D

Learn from my mistakes, kids ! :-P

  Are you sure? yes | no

Hacker404 wrote 04/05/2017 at 10:09 point

You've probably already though of this but ... 

You can get switch banks that are actuated from above rather than from the side. There are press toggles and slide on - off and they will bunch up more closely. 

Are the switches for the bootloader? It would be great if they were. 24 to 32 words could do it or even less with the instruction bit width you have chosen. 

All looks great!!!

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/05/2017 at 19:29 point

Well, I did the rough placement with the switches I have in stock, and I have 41 of these. what matters is the width, I wanted to see if it fits.

I'm expecting to receive a "suitable quantity" of "normal" switches (I bought the piano because "hey, it's unusual, it could be a lifesaving part, you never know" :-D)

There is no bootloader : execution starts at address 0 and reads whatever instruction is stored in the board plugged in the corresponding slot.

There will be several slots with detachable cards, so you can put "PROM" (programmable with switches) or "ROM" (soldered diode arrays), change their address... Maybe even create a small library (in the physical sense of the term) of routines that you will plug when you need them :-D

But that's for a coming log...

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/17/2017 at 21:11 point

Look at the latest log, you'll see what I mean with "a lot of switches", as I just received them ;-)

  Are you sure? yes | no

Hacker404 wrote 04/17/2017 at 22:17 point

Wow!! You could put the entire boot code in DIP switches and still have most of them left. 

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/17/2017 at 22:36 point

I don't consider this as "bootcode" but enough for a small but interesting program :-)

I'll spread the switches over several independent modules so I can pull one, program it and put it back, to test code  before I solder it with diodes...

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates