A byte-wide stripped-down version of the YGREC16 architecture

Similar projects worth following
YGREC can stand for many things, such as "YG's Relay Electric Computer", "Yann's Germanium and Relay Equipped Computers" or "YG's Ridiculous Electronic Contraption". You decide !

#YGREC16 is getting pretty large and moving away from the original #AMBAP inspiration, making it less likely to be implemented within my lifetime. So here is a "back to minimalism" version with
* 256 bytes of Data RAM (plus parity ?)
* 8 registers, 8 bits each (including PC)
* fewer relays/gates than the YGREC16
This core is so simple that I focus now on other issues, such as the debug/test access port, the register set's structure, I/O, power reduction...
Like the others, it's suitable for implementation with relays, transistors, SSI TTL, FPGA, ASIC, you name it (as long it uses boolean logic)!

After the explorations with #YGREC-РЭС15-bis, I reached several limits and I decided to scale it down as much as possible. And this one will be implemented both with relays and VHDL, since the YGREC8 is a great replacement for Microchip's PICs.

A significant reduction of the register set's size is required so I/O must be managed differently, through specific instructions. The register map is now:

  • D1  <= for NOP
  • A1
  • D2
  • A2
  • R1
  • R2
  • R3
  • PC  <= for INV

The instruction word is shrunk down to 16 bits. It is still reminiscent of the YGREC16 older brother but I had to make clear cuts... The YGREC8 is a 1R1W machine (like x86) instead of the RISCy YGREC16, to remove one field. Speed should be decent, with a pretty short critical datapath, and all the instructions execute in one clock cycle (except the LDCx instructions and computed writes to PC).

The fields have evolved with time (I have tried various locations and sizes). For example:

20171116: The latest evolution of the instruction format has added a 9-bits immediate field address for the I/O instructions.
20180112: Imm9 is now removed again...
20181024: changed the names of some fields
20181101: modified the conditions to change Imm3 into Imm4
20180112: Imm9 back again !

There are 18 useful opcodes (plus INV, and the pseudo-opcodes HLT and NOP), and most share two instruction forms : either an IMM8 field, or a source & condition field. The source field can be a register or a short immediate field (4 bits only but essential for conditional short jumps or increments/decrements).

The main opcode field has 4 bits and the following values:

Logic group :

  • AND
  • OR
  • XOR
  • ANDN

Arithmetic group:

  • CMPU
  • CMPS
  • SUB
  • ADD

Beware : There is no point to ADD 0, so ADD with short immediate (Imm4) will skip the value 0 and the range is now from -8 to -1 and +1 to +8. (see 17. Basic assembly programming idioms)

Shift group (optional)

  • SH/SA direction is sign of shift, I/R(bit9) is Logic/Arithmetic flag.
  • RO/RC direction is sign of shift, I/R(bit 9) allows carry to be rotated.

Control group:

The COND field has 3 bits (for Imm4) or 4 bits, more than YGREC16, so we can add more direct binary input signals. CALL is moved to the opcodes so one more code is available. All conditions can be negated so we have :

  • Always
  • Z (Zero, all bits cleared)
  • C (Carry)
  • S (Sign, MSB)
  • B0, B1, B2, B3 (for register-register form, we can select 4 bits to test from user-defined sources)

Instruction code 0000h should map to NOP, and the NEVER condition, hence ALWAYS is coded as 1.

Instruction code FFFFh should map to INV, which traps or reboots the CPU (through the overlay mechanism): condition is implicitly ALWAYS because it's a IMM8 format.

Overall, it's still orthogonal and very simple to decode, despite the added complexity of dealing with 1R1W code.

1. Honey, I forgot the MOV
2. Small progress
3. Breakpoints !
4. The YGREC debug system
5. YGREC in VHDL, ALU redesign
6. ALU in VHDL, day 2
7. Programming the YGREC8
8. And a shifter, and a register set...
9. I/O registers
10. Timer(s)
11. Structure update
12. Instruction cycle counter
13. First synthesis
14. Coloration syntaxique pour Nano
15. Assembly language and syntax
16. Inspect and control the core
17. Basic assembly programming idioms
18. Constant tables in program space
19. Trap/Interrupt vector table
20. Automated upload of overlays into program memory
21. Making room for another instruction
22. Opcode map
23. Sequencing the core
24. Synchronous Serial Debugging
25. MUX trees
26. Flags, PC and IO ports
27. Binary translation (updated)
28. Even better register set
29. A better relay-based MUX64
30. Register set again
31. Rename that opcode !
32. Register set again again
33. Yet Another Fork
34. What can it run ?
35. More register set layout
36. More VHDL and more...

Read more »

x-dia-diagram - 7.42 kB - 09/29/2019 at 05:07


x-dia-diagram - 4.74 kB - 09/29/2019 at 05:07



R7 decoder in A3P tiles

x-compressed-tar - 174.65 kB - 04/22/2019 at 01:39



a better decoder for the register set

x-compressed-tar - 173.01 kB - 04/21/2019 at 17:58



Redesigning the register set

x-compressed-tar - 155.92 kB - 04/21/2019 at 00:13


View all 33 files

  • Decoding the register names

    Yann Guidon / YGDES2 days ago 0 comments

    In the log Don't go full Numitron ! Unless... OK whatever. I examine how to reuse the techniques developed in  #Numitron Hexadecimal display module  and apply them to decode all the fields of the Y8 instruction.

    For the register name I came up with this diagram :

    This decodes to the following symbols :

    The segments E1 and G1 are always on (for A, d, r and P) so I modified the diagram a bit, later.

    I didn't optimise the replicated 1 and 2 because it would make the relay side too complex for little gain (I only have to build 2 decoders). Here is the result :

    To test the circuit, I have built a test device with a "standardised" 26-pins connector and 3 Numitrons. To inject data, I will reuse the connector and pinout of the existing Numitron hexadecimal modules.

    Note : the module can be powered down by disconnecting the +3.3V power line. The diodes will prevent shadow segments anyway, even if another decoder is connected in parallel to the Numitron (for example to share the Imm4 and Reg formats).

  • Sensing relays

    Yann Guidon / YGDES3 days ago 2 comments

    The RES15 relay is nice but requires way too much current to operate, in particular in some circuits where low current is necessary : the DRAM sense circuit as well as the instruction sense circuit, because 16 bits multiply the coil current, that reaches a value that can't be reliable...

    Another type of relay is required and @Artem Kashkanov  suggested the RES55 : a reed-type relay with the typical fast operation and low operating current, though at a higher voltage.

    I couldn't find a suitable lot of this reference on eBay but found 2 other things :

    • RES-64A rated 9-11V : vintage, pretty bulky, only SPST but 2K ohm coil so it must be pretty sensitive
    • 1A12 : miniature SIP chinese reed SPST relays, rated 12V, 1K ohm coil, very cheap

    I just tested the 1A12 and I am impressed : the contact closes at about 5V (varies with the piece) and opens at about 3V, with a current under 2mA. With such a hysteresis and low power, it even becomes interesting to use them for the register set...

    I still have to receive the RES-64A, which would look way better, and I'll have to compare it to the modern miniature version. However there is now a good solution to the problem I had before : I can switch 16 bits on, and draw at most 2×16=32mA, which will not strain the address decoder's contacts much.

    Oh and I still have to design that automated relay tester...

  • Assembler panel working

    Yann Guidon / YGDES5 days ago 0 comments

    I made it !

    I had to correct a couple of blunders (see the diagram below) and now the system woks (almost) as expected !

    Not all the forbidden/impossible codes are prevented :

    - IN and OUT seem to allow the IMM4 and REG modes, though the output binary code will be decoded "correctly"

    - INV allows SND to be output

    - probably some other obscure combinations are possible

    However this panel is only one half of the ASM equation : the disassembler display will prevail over the buttons configuration.

    This is why some markings are missing : when programming, look at the output and trust the display, don't stare at the buttons.



    (I'll have to shoot a video...)



  • More progress with the assembler panel

    Yann Guidon / YGDES10/06/2019 at 15:07 4 comments

    It took a long while, efforts, expenses, and a full disassembly of my laser printer but here it is !

    The look/aspect is great ! I had some little issues with the size (maybe due to slight resizing somewhere) and there are a few hicups with some mounting screws.

    However the toner ink sticks rather well to the vinyl sheet and glueing didn't leave bubbles. The alu face plate can remain (mostly) clean and it adds a lot to the ergonomics :-D

    Locating the "right" plastic sheet took a while...

    And here it is in all its glory !

    All the switches are soldered but the assembly/wiring is not complete, I need to add another board to really get all the signals together. So I created a small board with 16 Glühbirnchen to ease the tests :-)

  • Progress with the assembler panel

    Yann Guidon / YGDES09/29/2019 at 05:26 0 comments

    I tried to fight procrastination and while it's fun to prepare, gather the parts and imagine things, implementing is still important, despite the higher efforts... I think I solved most of the issues so I decided it was about time for action, instead of starting yet another sub-project :-D

    One part (the ROM/ASM switch) is still missing and might be delivered late but it is not essential and it can be added later. All the other switches are here so let's go !

    I have uploaded the DIA files for the layout of the buttons and switches. They are laser-printed on normal paper, which is then glued (with a glue spray) on a suitable aluminium plate (found in my archives). So far the expense is about 8€ for the glue spray :-)

    Once glued, the centre of each hole is punched to help later with the drilling.

    Drilling took "some time" because of the required precision and odd diameters but my neighbour Alex greatly helped ! Thanks dude ;-)

    Overall, the result is surprisingly satisfying and close to my expectations :-)

    The action of the buttons is great and I did my best to not make it too compact, which also helps for the wiring on the other side :

    The two hex encoders don't have the appropriate nuts and can't be fastened to the alu plate, so I made a mezzanine PCB, which will later host diodes as well.

    The 3 lower rows of buttons have some alignment issues and need filing and adjustments, that's more work but the rest was almost smooth :-)

    Better pictures :

    Nothing is wired yet : I need a way to "laser print" the marks on the alu plate.

  • Project organisation

    Yann Guidon / YGDES09/10/2019 at 23:24 0 comments

    People are (rightfully) confused with this project, and I understand why: it's ambitious and covers many aspects at once.

    For other projects, I have split the whole project into several sub-projects, for example into an architecture ( #YASEP Yet Another Small Embedded Processor) and various implementations ( #microYasep, #Discrete YASEP...). Even for the precursor ( #YGREC16 - YG's 16bits Relay Electric Computer/ #YGREC-РЭС15-bis) I created several sub-projects ( #YGREC-Si , #YGRECmos, #YGREC-ECL... ) that clearly separate the architecture from the various technologies I wanted to explore.

    But designing a new microprocessor is more than defining an ISA and making the prototype work: it's a complex ecosystem that must be carefully crafted and every piece of the puzzle must fit right into place. I think that the following sketch give a taste of the ambition of the project :

    In fact it's not so much different from the YASEP and F-CPU, except that I can go deep in the design of everything, thanks to the simplicity of the core.

    The immediate use of Y8 would be as a softcore in FPGA projects where a tiny but easy-to-use and expandable microcontroller is required. However getting there also paves the way to more sophisticated cores and technologies...

    I admit that at this moment, I focus mostly on the ASIC and relay implementations, which hold the whole project back and I need to progress on other fronts. However some tools (such as the #VHDL library of ProASIC3 gates) are in development and should be short-term only, but are very important for the rewrite of the core in VHDL.

    Stay tuned...

  • Need help with RES60 / РЭС60 relays

    Yann Guidon / YGDES09/04/2019 at 23:35 17 comments

    At the start of 2019, I found a very interesting item on @qro_team 's eBay store : a single box of 40 low-voltage РЭС60 relays. I wish there were more !

    It's the real deal : it's DPDT (unlike the РЭС15 which is only SPDT), it's very small (great for density) and the version I have can turn on at around 2.5V at half the current of the РЭС15.

    The DPDT part is very important for several circuits, for example the incrementer for PC and the ALU. But today I focus on other less visible parts : the bit sense circuits for the memory arrays. The DRAM uses capacitors that will discharge in the coil and the lower current increases the reliability of the whole system (less sensitive to current leaks in the capacitors). The instruction PROM (on which I work at the moment) also benefits from a lower current because each line drives 16 bits and the aggregate current is then handled by a single relay... So if a current of 10mA is enough to trip one line sensor, the worst case scenario for the main driver is 160mA, which is within the tolerance of the РЭС15. It remains to be seen how long it remains reliable but this is another debate. I could make the "single point of failure" easy to replace.

    The РЭС60 I have are sold as "6 to 8V" with a coil that measures about 66 ohms. It's a -02 type (?) and all the others I find on eBay have a much higher voltage : 18V, 23V, 27V, 34V... They would certainly have a lower driving current but the voltage swing is not practical. I could try my luck if there are "12V" versions but I need another box because the 40 pieces I have at the moment is barely enough for the various circuits that require it... Who could help me ? @Artem Kashkanov  ? @[skaarj] ? ...

    According to this datasheet (and many others found online),

    there must be a marking error on my box because the -02 is rated at 270 ohms and I measured coils in the 65 ohms range... but apparently I need a 12V version, with -02 or -08 type (I still can't get the difference).

    I might have found -04 (lower voltage) that would be useful in the ALU so my -03 would be used as sensors, probably using pre-biasing, unless there is some magic reed relay that could save the circuit ? (Artem ? ;-) )

    Correction : the box is marked "00.02" so according to the references I have found, it should be a 23-34V version. Measurements disagree... I don't know what happened or if the parts were repackaged but anyway, I have them :-D

  • A Diode (P)ROM was (almost) built in a day

    Yann Guidon / YGDES09/03/2019 at 12:35 0 comments

    So I tried to build a prototype and it was almost finished in a day :-)

    32 instructions, 64 DIP-switches with 16 pins each, that's already 1024 soldering joints.

    Then 512 diodes (LL4148), linked in 8 rows, make another kilojoints :

    but it's not as hard as it sounds.

    What is still missing is the 64 column wires and the connectors. I'll also add one LED per line.

    Of course a dedicated PCB would ease assembly but this

    1. would be very costly
    2. I have more important other expenses
    3. I already have these parts in stock
    4. I don't want to waste money with a flawed PCB design that a prototype could solve.

    Anyway with 32 instructions I'll have enough room to test interesting things and it's not as hard as it looks.

    I want to make the board design modular, each board can be relocated physically on a backplane to change the address. There are 2 decoders, large MUXes for the lines and columns, that will not need changes, while the data boards can be of any type (DIP switches, solder joints or anything else I come up with).

  • Diode (P)ROM wasn't built in a day

    Yann Guidon / YGDES08/27/2019 at 21:52 0 comments

    As I build the instruction assembler and disassember, I must also provide a way to store instructions. This was already covered in #YGREC16 - YG's 16bits Relay Electric Computer in the log PROM boards.

    Things have evolved since 2017 and I now have a whole bunch of DIP switches (Log: I hope that's enough this time) and pretty large proto boards... I have just what is required to build boards with 16×4=64 instructions :-)

    But let's look at how these boards must be organised. The YGREC8 has 16-bits instructions so a higher density than the 24 bits of the YGREC16. And there are only 256 addressable instructions. That's 256×2=512 DIP switches, I have more than 700 in stock these days :-)

    Then the topology must be optimised to reduce the number of relays : how many lines and columns ?

    • 1 column and 256 lines : 1 huge MUX256, or 255 relays. HUGE...
    • 2 columns and 128 lines : 1 huge MUX128 and 16 relays to select the column, or 143 relays. Better but still not optimal.
    • 4 comumns and 64 lines : 1 large MUX64 and 16×MUX4, or 63+(16×3) = 111 relays. Good.
    • 8 columns and 32 lines : 1 MUX32 and 16×MUX8 = 31 + 16×7 = 143 : the column MUX gets too large now.

    So be it : the PROM cards are organised with 4 columns.

    I'll try to build a 8×4 board to get started... because I also need to build the 2 big MUXes for lines and colums. Where are my boxes of SMD diodes ? :-D

  • More assembler panel stuff

    Yann Guidon / YGDES08/25/2019 at 13:09 12 comments

    I have received and tested all the interlocked switches :-)

    and I'm updating the layout and dimensions, using the diagrams I have found on the web:

    So far the layout of the panel is:

    but many questions are still in the air...

    I can print with my laser printer to the exact scale so this will be very useful: no need of a CNC ! but it only moves the problem around.

    How can I transfer the toner to the front panel (aluminium) for the labels of the buttons ?

    I added the "SEL" button : it's a SPDT switch that selects which circuit gets the power/signal, either the assembler panel or the program ROM. That makes now 3 switches (IMM8, NEG and SEL) and I haven't decided/found which model to use. I need a low-force, high-endurance switch with a long lever (10mm or 12mm ?) so the drill diameter is undetermined (until I find THE model that fits).

    The SEL button changes several things, because initially I wanted to use a 16-pole dual throw switch to select the value sent to the instruction decoder. The operating force and endurance would not be satisfying because I want to alternate between both sources easily and fast. Now the instruction bus is shared between the ASM panel, the instruction ROM and the eventual electronic/remote interface.

    For the YGREC16 with 24 instruction bits, I started with positive logic, then realised it would be more complex for the driving electronics so I changed to a different driving system where PNP transistors just pull the signal to 0V. But overall this is not easy to manage and a return to "positive logic" seems unavoidable.

    Another consequence is that the outputs of the asm panel must be "diode protected" because some signals can be shorted by the switches. This is not a problem when the panel is operated alone but it will interfere in some cases with the ROM and the external interface. Another version of the diagram is necessary... So here it is!

    There are now 38 diodes now. It is not a tragic increase but there is a good side effect : all the signal paths have one diode drop, everything is now balanced !

View all 87 project logs

Enjoy this project?



salec wrote 10/09/2019 at 09:18 point

YGREC can stand for so many things, but since my wife has been learning French on Duolingo I can't avoid noticing that it is also a wordplay on French spelling of "Y". 


  Are you sure? yes | no

Yann Guidon / YGDES wrote 10/09/2019 at 10:03 point

oh, of course, yes, too ;-)

  Are you sure? yes | no

salec wrote 10/09/2019 at 12:04 point

always have an opening joke/tease for audience :D

  Are you sure? yes | no

Yann Guidon / YGDES wrote 10/09/2019 at 12:46 point

@salec  always !

  Are you sure? yes | no

castvee8 wrote 04/13/2019 at 22:57 point

I so love your commitment and enthusiasm ! I was playing with vacuum tube calculators a bit since last year an just keep going down the rabbit hole. Your projects seem to at least make purposeful sense.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/14/2019 at 08:56 point

That "purposeful sense" may look drowned into the proliferation of projects, angles and ideas but it is still clear to me since it's my main hobby since 1998 at least :-D

I'm glad you enjoy !

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/04/2018 at 07:11 point

Another note for later :
writing to A1 or A2 starts a fetch from RAM. In theory the latency is the same as instruction memory and one wait state would be introduced. However the processor can also write directly so the wait state would be only on read to the paired data register...

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/04/2018 at 06:55 point

Note for later : don't forget the transparent latch on the destination register address field, for the (rare) case of LDCx, because the 2nd cycle doesn't preserve the opcode etc.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/04/2018 at 07:18 point

OK, not a transparent latch, but a DFF and a mux, plus some logic to control it.

-- DFF, every cycle :

SND_latched <= SND_field;

LDCx_flag <= '1' when (LDCx_flag='0' and opcode=opc_LDC and writeBack_enabled='1')   else '0';

-- MUX2 :

WriteAddress <= SND_latched when LDCx_flag = '1' else SND_field;


Note : LDCx into PC must work without wait state because it's connected directly to SRI, as an IMM8, and no extra delay is required. PC wait state is required for ADD/ROP2/SHL and IN.

  Are you sure? yes | no

Frank Buss wrote 10/27/2018 at 12:51 point

Do you really plan 8 byte-wide registers? This would require thousands of relays :-)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 10/27/2018 at 14:26 point

no :-)

8 registers, 8 bits each = 64 storage bits.
1 relay per bit => 64 registers

The trick is to use the hysteretic mode of the relays :-)

  Are you sure? yes | no

Frank Buss wrote 10/27/2018 at 16:17 point

Ok, makes sense. Maybe change the project description, someone might think you are planning a 64 bit architecture.
BTW, could this be parametrized for the address and data size? If you implement it in VHDL, you could use generics for this, would be no additional work to use just the generic names instead of hard coded numbers. Except maybe some work for extending the instruction opcodes.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 10/27/2018 at 17:16 point

Frank : DAMNIT you're right !

I updated the description...

  Are you sure? yes | no

Yann Guidon / YGDES wrote 10/27/2018 at 17:19 point

For the parameterization : it doesn't make sense at this scale. Every fraction of bit counts and must be wisely allocated.

Larger architectures such at #YASEP Yet Another Small Embedded Processor  and #F-CPU  have much more headroom for this.

  Are you sure? yes | no

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

this will working on epiphany or oHm or other cheap machine?

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/08/2017 at 18:07 point

I'm preparing a version that would hopefully use less than half of a A3P060 FPGA, which is already the smallest of that family that can reasonably implement a microcontroller.

But it's a lot less fun than making one with hundreds of SPDT relays !

  Are you sure? yes | no

Bartosz wrote 11/14/2017 at 14:13 point

Question is price and posibility to buy

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/14/2017 at 16:08 point

@Bartosz : what do you want to buy ?

If you can simulate and/or synthesise VHDL, the source code is being developed and available for free, though I can't support all FPGA vendors.

If you want a ready-made FPGA board, that could be made too.

If you want relays, it's a bit more tricky ;-)

I have just enough RES15 to make my project and it might take a long while to succeed. There will be many PCB and other stuff.

However if, in the end, I see strong interest from potential buyers, I might make a cost-reduced version with easily-found minirelays. I don't remember well but the Chinese models I found cost around 1/2$ a piece. Factor in PCB and other costs and you get a very rough price estimate... It's not cheap, it's not power efficient, it's slow and won't compute useful stuff... But it certainly can make a crazy nice interactive display, when coupled with flip dots :-D

So the answer is : "it depends" :-D

  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