Scientific calculator with a brain built out of relays.

Similar projects worth following
This project is about building the fastest relay-cpu in the world.

Once you have a homebuilt CPU (and also before it is ready), everyone will ask: What can it do ? So it is important to have a good application to show what the CPU can do. That will also give some focus for the design. I took a calculator as application. So the device should have calculator keys and a display.

It will be a scientific calculator, using floating point calculations, and capable of logarithms and trigonometric functions. The aim is a speed of a at most a few seconds for add and multiply, and at most 5 to 10 seconds for the scientific functions.
The design will have solid state memories, but might be prepared to work with a diode-ROM and/or capacitor-RAM if the application does not need too much memory.

EDIT: 8-bit version is working, see video:

How will the fast speed be accomplished ?

Relays are slow, and to get acceptable performance, many measures must be taken.


  • Microcode will not be used
  • Harvard architecture, so fetch and execute will be in parallel
  • Have enough registers so we're not loading and storing all the time
  • Have a good instruction set
  • Some special instructions tailored to the algorithms that are used


  • Design in such a way that for executing an instruction a very low number of consecutive switching relays is needed. At this moment, there are only four consecutive switching relays for an instruction.
  • Use small relays, these can be fast (datasheets show 2 msec switching time). Using small relays means they take less space on a pcb, so not much pcb area will be needed.

The design is shown in the following block diagram (click on it for a larger version):

The block diagram also shows which functions the twelve PCB's and the backplane contain.

Now that all schematics and also all pcb's are designed, I can give a quite accurate listing of the number of main components:


There is an online browser-based Assembler and Simulator that simulates the calculator application (or any other application that you could make). Just press "Assemble" and then "RUN", and start making calculations on the calculator keyboard that is on the screen. (After each button click, have some patience until the script halts and the number (hopefully) appears.) The calculator program does not give messages yet for overflow, or out-of-range input (including zero divide). Trigonometric functions don't work yet, all others do.


The architecture is explained in the architecture document (see Files section). Highlights are:

  • All instruction, register, word and memory sizes are 16 bit.
  • Most instructions operate in a single cycle.
  • There are eight 16-bit registers, one of them is the PC.
  • Six registers can be paired to form three 32-bit registers (like the H and L registers in the 8080 / Z80 ). Many instructions have a 32-bit variant that operates on register pairs (using 2 cycles but single instruction word).
  • It is a 2-operand design, 1 operand is a register and the other one can be register, memory, or immediate. If the immediate is only 8 bits (7bits + sign), it is included in the 16-bit opcode and the instruction executes in a single cycle.
  • Memory addressing always has a small displacement within the instruction opcode, facilitating addressing of variables in a stack frame, or addressing of structure members. Instructions that use this need only a single cycle.
  • The ALU has also decimal instructions (in addition to the normal binary instructions), to support the calculator functions.
  • There is a special instruction to support (decimal) multiplication.
  • The ALU has special instructions to convert the 4 nibbles in a register to bits that control a 7-segment display.

The architecture is independent from the technology, so it could also be used for a TTL or FPGA design. It can be upgraded to a full 32-bit design. Actually, since there are 32-bit register pairs, it would be easy to support a 32-bit address bus.

Use of the architecture is free for non-commercial use :), but I would like to get a mail when you are going to use it.


What has to be done:

  • Have an architecture.
  • Have a schematic.
  • Have a simulation. The 4-bit boards have been low-level simulated in Logisim. I do not have a good logisim model for a relay, so the simulation might not catch all problems. Many instructions have also been simulated.
  • Built an assembler and simulator. Simulating the application before the design is finished gives a chance to optimize the CPU for the application. Available HERE.
  • PCB design 
  • PCB ordering
  • Build an 8-bit version (this does not need all PCBs)
  • Build a programmer...
Read more »

Adobe Portable Document Format - 145.89 kB - 01/06/2019 at 13:15


Risc Relay CPU gerbers

Gerber PCB design files of all 9 pcb's

x-zip-compressed - 960.40 kB - 05/05/2018 at 20:12


x-zip-compressed - 849.16 kB - 05/05/2018 at 19:54


PCB signals

A collection of spreadsheets with quite accurate description of the signals at the connectors of the pcb's

x-zip-compressed - 76.96 kB - 10/14/2017 at 15:25



Schematic that shows essentials of the datapath and instruction decoder.

Adobe Portable Document Format - 45.87 kB - 05/24/2016 at 20:15


View all 7 files

  • This project in TheNewStack

    roelh07/25/2022 at 12:58 0 comments

    I Was very surprised to see my project in an article about the CPU Webring in The New Stack !

    The article can be found HERE.

  • Loading a constant from program space

    roelh01/07/2020 at 19:53 0 comments

    Someone asked how the LDC instruction works. The LDC is needed for the Harvard architecture, were the program memory is separated from the data memory. So when you have a table of constants in program memory, you can not use a normal memory instruction to get such a constant into your processor. That is why there is a special LDC (Load-Constant) instruction. 

    The short version is this:

    The LDC instruction uses the fact that the 12 bit program counter consists of two 12-bit wide latches. The first latch group is called the master PC, and the second latch is called slave-PC. The slave PC can be loaded with an incremented version of the master PC, and then the master PC can be loaded from the slave register to increment it. The slave PC also directly drives the address bus of the program memory.

    Like most instructions, the LDC uses one of the address registers. In this case, the contents of the selected address register is loaded into the slave PC, while the actual PC value stays available in master PC. The address is now connected to the address bus of the program memory. In the next cycle, the contents of the program memory will not go to the instruction register (that will be cleared, and execute a NOP), but it will go to the DH register. Then, the slave PC is reloaded from the master PC (that still contains the programcounter value), and the next instruction will be executed as normal.

    And now the detailed version:

    The LDC is decoded on the Clock&Control pcb, by RL170 on the schematic. Normally, this relay is attracted but for the LDC instruction it is not. When the LDC is detected, this relay causes the following actions:

    • The slave PC is not loaded from the master pc, because the PC_TO_SLAVE signal is blocked by RL170.
    • The LDC_TO_SLAVE signal is activated in phase 3. This goes to the Program-counter PCB, where it cause that the signal group LDC_D0 to LDC_D5 is transfered into the slave register. This signal group comes from the 96 pole connector pin B9, C9, B15, C15, B17, C17. On the backplane this connects to REG_PB bus (register port B) that is connected to the selected address register. The first PC program counter board connects to the bits D0 - D5 and the second board connects to D6 - D11.
    • RL170 also causes that relay RL171 (on schematic next to RL170) is set. This causes that in the next cycle, RL172 prevents loading the master PC from the slave PC, and the instruction register is not loaded. RL171 also activates the signal LDC_WR, going to pin A17 of its connector.  On the main board this connects to pin C10 of the lower program counter board. On the schematic of the PC, you see it on page 3 where it controls RL341. This relay will block the clearing of the master PC (because it does not get its incremented version from the slave PC, and it must keep the same value), it will clear the DH because that will get a new value, and it will generate the CODE_TO_DH activation signal. This will go to pin C29 of the connector, and over the main board to the PROG "Program memory and instruction register" board on pin A28. There it will, on page 2 of the schematic, connect the codeword (from the program memory) to the LINK bus. The LINK bus connects directly to the 16 bit DH register. (The same LINK bus is used to transfer the pc value to DH when a subroutine is called).

  • Simulation of display segments, and more debugging

    roelh01/06/2019 at 15:56 0 comments

    For the simulator of #1 Square Inch TTL CPU, I used real graphics for the segments of the clock. Since the relay cpu can also control each segment of the display independently, I also added this feature to the simulator of the relay cpu ( Assembler and Simulator ).  To use it, just press "Assemble" and then "RUN", and start making calculations on the calculator keyboard that is on the screen. Since the segments of the display are directly connected to the register bits, you will see the same wild patterns during calculation as you would on the real CPU. Trigonometric functions don't work yet, all others do. (After each button click, have some patience until the script halts and the number (hopefully) appears.) The calculator program does not give messages yet for overflow, or out-of-range input (including zero divide).

    The off-by-one error in the return address of a subroutine (reported in a previous log) is now handled by a workaround: A NOP instruction should follow each CALL instruction. 

    Three small problems were found (but chasing them was a lot of work):

    • The CL register can not be used in the DSUB DL,CL instruction (and similar instructions). But the assembler allowed it, causing the simulator to work correctly while the real cpu did give a wrong result. Solved by letting the assembler produce an error in this case.
    • The AND instruction did not work with a zero-page operand. This had upper instruction byte pattern x010xxxx, and the cause was that all instructions with memory operand and this opcode pattern were decoded (on the clock & control pcb) as STORE instructions, so no read from memory was possible. It could simply be solved by changing the instruction pattern for zero-page-AND to x110xxxx, that was unused. No hardware modification was needed, because the decoder was not connected to the changed bit in the instruction (it was an unused, mirrorred code).
    • The DL register can not be used as pointer in the ST [DL],CL instruction (and similar instructions). But the assembler allowed it, causing the simulator to work correctly while the real cpu did give a wrong result. The assembler should have given an error message in this case, but the STORE was handled differently because of the deviating operand sequence, and that part did not check the pointer. So the check was added there.

    Main obstacle for finding these problems were that the design was done so long ago (between one and two years) that several details had slipped my mind and had to be reverse engineered from the schematics.

    The relay calculator now sometimes gives a good calculation result for basic operations (digit entry, number display, addition, multiplication). More bug hunting is needed.

    The "Architecture and Instruction list" in the file section was updated according to this log.

    The online simulator-assembler was updated, but the source in the file section has not been updated yet.

  • Simple Relay ALU

    roelh11/08/2018 at 14:33 3 comments

    Since you are all Relay Computer builders or fans, you might be interested in the new extremely simple Relay ALU, that provides 10 functions with only 2 DPDT (or 3 SPDT) relays and a few diodes ! 

  • Off by one error

    roelh07/04/2018 at 20:47 0 comments

    The Risc Relay CPU is in the Homebuilt CPUs WebRing now !!  Celebrate !!

    In the last weeks I did build most remaining boards and did more testing. All registers are available now, and the second ALU board is ready, so the full 16 bit data handling is in place.

    The new ALU and register cards were first tested with the test device, and the soldering problems that were found were corrected.

    Then everything was put together. (Only the second Program Counter board, and the keyboard are still missing.) This was too much for my 2A benchtop power supply, it showed the LED's slightly dimming during operations. So I changed to a beefy 24V 10A supply.

    This was tested:

    • 32 bit decimal addition, working
    • bit shift unit, working (after fix)
    • load constant from code space, working (but not supported by assembler yet)
    • subroutine call, problem !

    All tests only worked after one or a few soldering issues were fixed. In the shift unit, one of the diodes (D609) was not connected on the schematic, so a short wire was needed. On the boards with 3 registers, 8 short wires were placed (this was planned), to enable register DH to receive input over the LINK bus (return address). The register pcb uses almost all 96 connector pins. Therefore, the link bus was connected to the output of register C (register C is not placed on these pcbs), and on the pcb there are wires from the register C outputs to the relay coils of register DH.

    The subroutine call placed the return address in register DH, fine. But when, in the return instruction (LD PC,DH), the DH register is moved to the PC, the PC is incremented before the next instruction is fetched. That means that the instruction after the call is skipped ! A classic off-by-one error. I have not yet decided what to do about this, there are several possibilities.

  • Good progress

    roelh05/21/2018 at 17:40 0 comments

    A few weeks ago, I connected a Raspberry Pi to the program flash memory of the computer. The Raspberry Pi runs the assembler-simulator in its webbrowser. The assembler-simulator has buttons for upload and download from/to the RPi. The RPi is connected with a 16-bit data connection to the Flash program memory, through a small pcb (containing resistors for level conversion). The PROG pcb, that contains the flash chips, also has two 74HC574 registers to store the address for writing the flash. The RPi has a small Phyton program that burns the generated binary in the two Flash memories of the relay CPU. 

    From that moment on, I could run real programs on the computer, although the cpu is only partially built: The data is only 8 bit wide (in stead of 16). Only 4 8-bit registers are present, and it does not run at full speed. 

    Then came several days of serious debugging. Several problems could be fixed by changing the instruction encoding or changing the simulator:

    • In conditional branches, true and false were swapped
    • After a branch or jump, the first instruction was skipped because the hardware first increments the PC and then fetches an instruction
    • The 7-segment decoder had the two segment groups swapped. So the X register got the segment bits that were intended for the Y register and the other way around. So the single segment instruction was now split in two segment instructions, with the segment group specified in instruction bit 5 (this was an unused bit for zero page addressing). Small hardware change.

    The architecture and instructions document was updated with the encoding changes.

    Several instructions were working unreliable. All these problems were fixed by changing the hold resistor (2K on the schematics) to 1K5.  One non-soldered diode was found.

    Not all instructions are tested yet, but all tested instructions work now. I made a small demo program that calculates Fibonacci numbers.

    This weekend, I gave the RISC Relay CPU its own website: RISC Relay CPU Website. Some things on the website might still be a bit quirky.

    A video of the working computer is on the new website (including sound ;) !

  • First instructions executed

    roelh05/05/2018 at 20:28 0 comments

    Annoying how slow the progress is if you can not spend enough time on your project....

    Just a few days after the last update, I also connected the 8-bit ALU board and the 4x8 bit register board to the motherboard. This should make 8 of the 16 databits and half of the registers operational.

    I could enter instructions manually with the buttons connected with a flatcable to the PROG pcb (described in previous log). And YES, I could execute several instructions successfully, like addition, saving to RAM, loading from RAM !  I did not test all instructions, but I do not remember an instruction go wrong (that may be selective memory, it's already a few months ago).

    Anyway, testing branches can not be fully done in this way. The control system will not load the instruction that follows a branch, so that it executes as NOP. But it has no way to prevent me from entering instructions manually...  So there is no escaping, it is time for a real program to be run from flash memory. 

    So the next sub-project is a flash memory programmer. I intend to do this with a Raspberry Pi. It can connect to my website that provides the javascript assembler. It could simply write the object code to its own filesystem, and then a Python program could program the parallel flash through RPi I/O.

    The javascript SIMAS (simulator-assembler) had an annoying 'feature', it did run quite slow. I examined it, and found that for small programs it was OK but with longer assembly programs it became slow. I suspected the Angular framework code. So I threw that out, I didn't understand it very well anyway. But it did not help.

    Then I switched from Chrome to FireFox, and suddenly the speed problem was gone...  I don't know why. But I'm not interested in investigating it further. There are enough other things to do.

    The SIMAS ( simulator-assembler ) had one of the first versions of the instruction set. So I updated it to the newest instruction set. It has two memory spaces now (program and data). To have initialized data, the assembler simply copies the first few hundred bytes of program space to the data space. This is something that a real program will have to do itself.

    The layout of the program was also changed. The left side of the screen now has a textfield for entering your program. The center has a bigger textfield, that shows the source code together with the assembled machine code. And the nicest feature...  in the center window, all program lines that were executed get a blue background, and the current line after the program halted is red. So the blue background shows you the execution path that the software has taken after the last keypress of the calculator.

    The buttons that simulate the calculator were re-ordered, to be similar to the pcb that I designed for the keyboard a few months ago.

    Finally, I worked on the calculator application. It will now do all functions, except the trigonometry functions. The latest code is now automatically loaded when you load the webpage. You can try it at  Before operating the calculator, first press "Assemble" and then "Run".

    I updated the HAD file section. The architecture and instruction listing are now in a single document. The schematics are updated and are according to the pcb's. Gerbers of the pcb's are also provided.

  • Assembling and testing pcb's

    roelh12/30/2017 at 19:16 2 comments

    Around two weeks ago I ordered all remaining pcb's and a lot of parts. They arrived just in time for some happy soldering in the days after Christmas. Each pcb was (sometimes partially) built and then it's main functions were tested, revealing soldering errors but also a few design errors. This is the state today (click it for bigger version):

    1) clock and control pcb

    2) program counter pcb (6 bits) 

    3) instruction decoder pcb (only it's LED's are visible)

    4) program memory and instruction register pcb

    5) RUN button

    6) STOP button

    The pcb's are connected to the main pcb with DIN41612 connectors.

    I started with the program memory and instruction decoder. (All pcb's in this project were intended to have a white color, but apparently I forgot to select the color when I uploaded the gerbers of this pcb). The flash memory itself is not yet assembled. There is a connector (where the ribbon cable connects) that is intended to connect to a flash memory programmer. It is now connected to 16 pushbuttons, to control the contents of the instruction register manually. The instruction register worked (but several of the 2K2 resistors in the hold circuits had to be lowered in value, apparently the current was not enough to keep the relays attracted).

    Next was the clock and control pcb. The clock circuit did not work as expected and had to be modified. Two 100uF elco's (visible on top of the pcb) set the clock to approx. 5 instructions per second, slow enough to have a sense of what is going on during testing. Asymmetry in the clock signal will have to be solved (and higher speed will be set at a later time). One of the board's input signals was not connected, a wire was needed to correct this. Another problem: The single-step button should start executing one instruction and then stop. Unfortunately, the stop function works too well, so much that pressing the single step a second time does not run a next instruction... 

    The program counter pcb also has decoders for reading and writing to the registers. Only the program counter section was mounted for now. After re-soldering a resistor, I started the clock and watched the PC counting...  0, 1, 2, 4, 8, 16 ....  Oh what's wrong ?  Did I build a shift register instead of a counter ?  After following the signals on several wires, it occurred to me. The PC has a master and a slave section, they each have a CLR signal. If one of the registers is not cleared, the bits stay 1 and you get this behaviour.  This is not visible on the LED's if the leds are connected to the slave section and the non-cleared part is the master section. Well, the CLR of the master could be interrupted by relay RL341, and that was not placed because it was considered part of the decoder section. After placing RL341, it was happy counting !

    Now the instruction decoder. It has led's that show the addressing mode ( Memory, Zero page, Immediate, register, test-and-branch) and the instruction ( LD, ADD, AND, OR, XOR ) and a few other output signals. This was simply tested by letting the clock run and manually put something in the instruction register. Many instructions could be tested this way. It revealed an error in the decoding for the DMPY instruction, were inputs to a diode gate had to be connected to IR_Y0 instead of IR_Y0_N. This diode gate was on the pcb with the instruction register, leading to a small modification there. For a LD instruction, also the OR led was on, could be corrected with an extra diode. The led for the PC was connected to a wrong point, not changed yet.

    Some changes were made in the schematics and pcb design files before they were ordered, so the file section is no longer uptodate. One of the changes was another change in the instruction set...   New instructions to subtract two registers without storing the result, providing compare instructions. Logic instructions (and, or,...

    Read more »

  • All design work has been done !

    roelh10/14/2017 at 16:55 0 comments

    All schematics and pcb designs are finished now. But I will do several checks before I send the PCB's out for production. (I already found some mistakes, can you find them too ?)

    Today I uploaded in the file section:

    • The schematics of all pcb's
    • A block diagram that clearly shows the main functions of the pcb's
    • An accurate description of pcb interface signals
    • Updated instruction list and architecture description

    This info should be enough to understand the design.

    I also posted the number of main components (327 relays). On the MEM pcb, I used BAW56 double-diodes because 1N4148 would cost me too much pcb area.

  • Speed Limit !

    roelh06/10/2017 at 20:43 2 comments

    Time to check the maximum reachable speed !

    The CPU needs 4 clock signals:

    • Phase 1 CLR
    • Phase 1 Activate
    • Phase 3 CLR
    • Phase 3 Activate

    There are also phase 2 and phase 4, but they have no clock signal, these phases are the relay 'layers' that follow the state of the relays that are switched by state 1 and 3.

    As the name implies, a CLR pulse clears a relay, and an Activate pulse can set a relay (if its input signal is true). But the CLR only disables the hold circuit of the relay. At the same time, the activate signal can be busy setting the relay, and even the circuits that follow the relay can already start switching while the CLR is still active ! So the clearing of a relay does not take time because it takes place at the same time as the activation (see technology file in the file section). The phase 1 CLR pulse falls within the phase 1 Activate pulse (so CLR can only be active if Activate is also active). And also, the phase 3 CLR pulse falls within phase 3 Activate.

    I did built a clock generator that has 4 relays (one for each clock signal), driven by a few transistors, and the transistors driven by a function generator. I attached the new clock to my test-setup (that has an ALU and a Register pcb). Phase 3 loads the ALU latch A with the data from register D, and phase 1 loads register D with the ALU output.

    On the test pcb, setting function to ADD and loading 1 in ALU latch B. This lets the ALU increment at each clock pulse.

    Well thats nice... what they call blinkenlights.... see the bytes incrementing at 3 places: at the ALU output, in register D, and at ALU input A.

    Yes and that sound.... Ohhhh...

    Cranking the frequency up, until errors begin to occur.... then a little bit down again where everything seems ok.... 136 Hz !!

    Power consumption around 600mA at 24 Volt. It's not really optimized for watts per megahertz....

    The other circuits in the CPU ( like instruction decoder, and PC incrementer ) will operate concurrently, and have the same technology as the ALU and registers (so they will reach the same speed). Most instructions use a single cycle, so the CPU could reach a speed of 136 instructions per second ! Probably will have to run it slightly slower for good reliability.

    The used relays have 2 mSec operating time. Relays with 1 mSec exist ( like IM06N ) but I found these too expensive. These could double the speed....

View all 18 project logs

Enjoy this project?



joan lluch wrote 12/04/2019 at 10:38 point

Hi Roelh, How does the TEQ work for 32-bit instructions?. According to the docs, the lower 16 bits are processed first. Carry will be used to compute the 16 upper bits if it is an add or sub instructions. But what about TEQ? The teq is a xor that does not store the result, but does the 32 bit version take into account both halves of the operation to correctly set the T flag? Thanks   

  Are you sure? yes | no

roelh wrote 12/04/2019 at 17:48 point

Hi Joan, 32-bit TEQ will not work correctly because the two zero-conditions are not combined. For TEQ the 32-bit mode was considered not needed. But you could quite easily add one or two relays to combine the z-flags of both halves and make it work. (The cpu has a single T flag that is used as z-flag or cy-flag, dependent on the instruction that writes it).

  Are you sure? yes | no

joan lluch wrote 12/04/2019 at 22:22 point

Ok, thanks for that. I am attempting (strong emphasis on "attempt") to design my own Relay based cpu. Currently studying yours as I think is one of the most clever implementations!. But, I am going to diverge on several aspects based on personal preference. For example, I will have pairs of instructions to work with 32 bit values, including a "cmp cc" and "cmpc cc" to produce a valid T flag after the second one, like my CPU74 architecture, and similar to the AVR processors.

  Are you sure? yes | no

roelh wrote 12/05/2019 at 17:40 point

Thanks for your praising words ! I am curious how your design will develop. Having separate instructions for the high part of the 32bits is surely a good way to follow.

  Are you sure? yes | no

joan lluch wrote 11/16/2019 at 18:39 point

Hi roelth,

Acordiing to the instruction set, I noted that you incorporated instructions to perform 32 bit ALU operations. The docs state that they will take two clock cycles (instead of one). However, by looking at the schematics, I can't figure out how this works. Are these really encoded as single instructions that take 2 cycles (in a CISC like fashion), or does the assembler encode them as two separated RISC instructions that are executed consecutively (such add followed by add-with-carry) ?


  Are you sure? yes | no

roelh wrote 11/16/2019 at 20:27 point

Hi Joan, the several addressing modes have different instruction bits (bit4 or bit7) that indicate 32bit mode. On schematic PROG1750 on page 2 the signal LONG32 will be pulled down for 16bit ops and left open for 32bit, depending on the relays of the instruction register on page 1. This signal goes to schematic CC1750 on page 1 at the left bottom side to relay RL174. This has several effects for 32bit mode:

- The PC will not be incremented, so in the next cycle the same instruction will be read in the instruction register. This works as follows: RL174 and RL170 will normally be attracted, connecting the ACT_PH3 signal to PC_TO_SLAVE. For 32bit, PC is not copied to slave, so PC is not incremented.

- Instead of loading the PC-slave, RL175 will be activated. Its output 32BIT_H will set bit0 and bit8 in the instruction register (PROG1750 schematic), so the next instruction acts on the next register and the next address. And in that next instruction, RL176 is activated, that connects the ALU CY-IN to the Carry bit, for 32bit addition.

I hope this made it clear !

  Are you sure? yes | no

joan lluch wrote 11/16/2019 at 21:14 point

Ok thanks. Did you consider having instead instructions that will handle the second half of the operation, such as add/sub with carry?  Given that the processor takes 1 cycle per instruction, is there really any advantage on having single 32 bit instructions?  

  Are you sure? yes | no

roelh wrote 11/16/2019 at 21:30 point

If I did not have the 32-bit mode, I could have used this instruction bit to encode ADC or SBC. The only advantage for 32bit mode, is that 32bit instructions code in a single instruction, giving shorter code. But for the relay CPU this advantage is indeed questionable since the flash memory is large enough for the application. However, for a more serious 16bit CPU that does a lot of 32 bit work, this could mean more speed since there are less instructions to fetch. 

  Are you sure? yes | no

joan lluch wrote 11/16/2019 at 21:55 point

Another advantage of  “carry” instructions is that there’s no limit on the number of bits for integer alu ops. You can chain 4 instructions on a 16 bit cpu to perform for example 64 bit operations. 

I have another question. How do you handle shifts in 32 bit mode.  This requires the temporary storage of the bits being shifted to or from the second register, right?

  Are you sure? yes | no

roelh wrote 11/16/2019 at 22:22 point

When shifting a register pair, the two registers will be sequentially filled with the new contents, lowest register first. This only works in one direction. For the other direction, you can simply select another register pair as destination.

  Are you sure? yes | no

Bartosz wrote 11/08/2017 at 16:46 point

lufa ot contiki works on this machine?

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/24/2017 at 22:30 point

It's looking better every day !

  Are you sure? yes | no

Yann Guidon / YGDES wrote 12/20/2016 at 01:33 point

I looked at some of the PDF (webpages/logs are more practical though) and I appreciate the efforts you made to polish your design :-)

Now tell me : did you prototype some of the circuits you designed, with real parts ? Even a small subset... Relays can have surprising behaviours !

  Are you sure? yes | no

roelh wrote 12/20/2016 at 14:55 point

Thanks for the compliment...

  Are you sure? yes | no

roelh wrote 12/20/2016 at 14:58 point

No I did not test anything yet... When problems occur I hope to fix them with extra parts or wires on the pcb....

  Are you sure? yes | no

Yann Guidon / YGDES wrote 12/20/2016 at 15:12 point

Hi :-)
I advise you against this approach: you might discover big problems after you have soldered everything. You would lose both all the relays and all the PCBs...

Testing small circuits, such as the ring oscillator, helped me uncover many issues I hadn't considered while drawing on paper. It made my design more reliable and I even ended up with configurations I had never seen in the litterature.

One example is the problem of fanout (which is, funnily, very similar to the issues in transistor-based circuits).

At least now I have characterised my parts beyond the mere indications of the datasheet and can estimate delays and consumption with good confidence.

Get that soldering iron and oscilloscope to work ! :-) Who knows what mistake you will find and how this will influence your next revision ? For example, how did you estimate the latches' feedback resistors and did you measure all the currents in all the driving combinations ?

  Are you sure? yes | no

Alex Martin wrote 12/19/2016 at 23:43 point

Great project! I like the ambitious goal of "fastest relay cpu in the world".

  Are you sure? yes | no

Yann Guidon / YGDES wrote 12/20/2016 at 04:29 point

I'll see if I can run #YGREC16 - YG's 16bits Relay Electric Computer faster ;-)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 12/18/2016 at 00:04 point

Ohhhhh... I just notice today, only now... Your sick trick for the 32-bits mode. Do you mind if it inspires me ? :-)

  Are you sure? yes | no

roelh wrote 12/18/2016 at 20:57 point

Hi Yann, your question triggered me to update this project...

Yes, I like sick tricks. Of course you can use the 32-bit mode. What will be your instruction set ?

  Are you sure? yes | no

Yann Guidon / YGDES wrote 12/18/2016 at 21:07 point

your "32 bits mode" looks to me like a "microvector", but I suspect is has already been used in other systems, such as the 68K.

For now, I have no target for this trick because 1) #AMBAP: A Modest Bitslice Architecture Proposal and #YASEP Yet Another Small Embedded Processor have too few registers 2) #F-CPU has a different approach (superscalar) 3) There is no need of dual-sized registers in pure RISC systems...

But it's good to know and I had actually considered an architecture with maybe 1K registers to create a "pseudovector" machine, using something along these lines.

For F-CPU this made me think about "binding" ou "pairing" execution units to increase throughput if the computations are identical in two globules... but this remains "single cycle", not "hold on a cycle and toggle a bit" :-)

Damn, there are so many possible combinations !

Regards :-)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 05/22/2016 at 22:30 point

The online JS assembler and simulator is sick.

You have done some awesome work ! I'm jealous :-P

  Are you sure? yes | no

roelh wrote 05/23/2016 at 16:12 point

Thank you Yann. But the Javascript simulator is not very fast. The relay computer ifself would probably be faster...

  Are you sure? yes | no

Yann Guidon / YGDES wrote 05/23/2016 at 16:57 point

At least I can compute Mandelbrot sets with my own simulator ;-)

  Are you sure? yes | no

Winston wrote 04/13/2016 at 23:31 point

Very much looking forward to seeing (and hearing) this after you build it.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/18/2016 at 22:23 point

Yep. The noise it makes will sound like music...

  Are you sure? yes | no

roelh wrote 05/22/2018 at 08:42 point

The computer is now partially built and working ! The CPU has its own website now:

The website has a video with sound !

  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