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.


Logs:
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)


Let's build a computer. A funny computer, that must be 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 RAM, a bit more instructions), ridiculously unreliable (I added 2 parity bits), ridiculously useless (except 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 (with the progressive invention of CCPBRL and balanced command trees, to name only a few) have slowly changed my approach and fueled my perfectionist leanings.

Today (20170404) I have a complete architecture, an instruction set, all the needed relays, and I continue to put things together in the next logs.


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 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 other things are possible). The result is checked for being zeroed, and sent back to the register set.

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. 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 usual operations can be achieved with a combination of the available fields and special registers. All the instructions are predicated, except CALL which is replaces the condition "NEVER". In this case, the result goes to PC and PC+1 goes to the register set.

Such a presentation shows that 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) :


Usually, one prototypes a circuit in FPGA before implementing it in other technologies. Here, I seem to do the reverse :-D


This project also taught me an important historical lesson : electricity-based computers could be made without transistors, but they are insanely hard without diodes. Diodes are what made computers practically possible, one century ago, and they needed to become reliable enough and cheap enough to be deployed en masse, paving the way for the transistors...

Without diodes, the AMBAP's memory systems couldn't work (1 diode per bit for the instruction PROM, 2 diodes for the DRAM). The input panel couldn't work either. The logic/datapath can work but would not have anywhere to store the vast informations it needs to process, thus reducing it to a dumb FSM...

This assertion is confirmed by the #Hot logic project.