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

  • A proper reset for the double-coil latch

    Yann Guidon / YGDES11/09/2019 at 07:35 0 comments

    A DPST relay can be emulated with two SPST relays, with their coils in series (one coil replaces the pull-up resistor so energy efficiency is increased). However there are two problems :

    • the high-side relay gives an inverted value
    • the power-up value of the complementary latch gives a non-complementary value, both relays are left open.

    The first problem is somehow "easy" to solve with the YGREC8 : the inverted value will go to SND because there is a XOR/inverter in the datapath. We just need to invert "in the other case".

    The 2nd problem is solved by a diode, connected to a common /RESET rail that is momentarily connected to 0V during the power-up sequence. This means more diodes, but the power-up sequence can be shorter than some code scanning the register set and writing to each of them...

    I just tested my system with the RES64 and it works well. The only problem is the capacitance of the RS flip-flop, the 47µF capacitor I tried is too large and 5µF would be good (a discharge time of 10ms) though I can't find the appropriate part.

    The discharge time will determine the max. switching frequency (?), I think 10µF would still take a full clock cycle to discharge at 50Hz, and nothing prevents us from aborting the discharge. So I ordered more Russian 10µF tantalum caps.

    This is also interesting because the much higher resistance of the RES64 coils keeps us from having to use large capacitors for timing purposes. For example, the POR (Power-On-Reset) could be controlled by a large capacitor (1000µF ?) discharging in a coil...

    Experiments have shown very interesting results... Such as a 100µF capacitor with an internal 6K Ohms resistance ???

    Because of this leakage current, the sensitive timing relay was still partially energised and wouldn't turn off after the RC time... Check your parts before using them !!!

    No trick, I swear !

    I make a 2-relays POR circuit now... Here is the schematic :

    I botched the manual reset, is should be a SPDT switch so the 470µ capacitor is discharged fast (through 200 ohms or so).

    The output has a weak pull-up resistor to backwards-bias all the diodes and (hopefully) reduce the crosstalk between all the latches.

    3 more diodes help with discharging the capacitor or to prevent reverse-charging.

    The 470µF cap provides a good 1s pulse.

    The output RES64 could be buffered with more and stronger relays (like 3×RES15)


    The only problem is with the voltage trigger : this voltage changes with time and self-heat... I'll have to find another system.

    Oh and the trigger voltage varies with the ramp-up speed...

    But this system is still more reliable than nothing. And I can select how many Ge diodes are in series to tune the voltage.

    Another challenge : how do I detect that the voltage has dropped below 5.5V ?

  • A new system for the register set

    Yann Guidon / YGDES11/05/2019 at 21:24 0 comments

    With the new RES-64 reed relays, the intended circuit must be adapted. Then with the experience gained with the other circuits, I came up with a different system that has several significant advantages over the prototype I made 2 years ago... But there is one drawback : it takes MORE RES-64 and more room !

    The write section doesn't change : each bitplane requires a MUX8 to steer the bit to the appropriate coil, plus the latching relay+capacitor, that's already 8×RES15 and 8×RES64.

    Reading however is different ! I simply took the large MUXes away, and I decode 3->8 with bipolar signals to select a whole register. I must add one diode per relay to prevent feedback loops but they are pretty small and cheap.

    However there are 2 read ports and each latch must be duplicated because the RES64 are not DPST... that means a total of 144 RES64 !

    Nothing crazy here, it's simply that I moved the MUX8 from the last to the first side, so it can be shared among the 8 bitplanes, which saves a significant number of relays.

    Fewer relays make the system more dependable/reliable. The "sense buffer" (the same RES64 as the latches) needs less than 3mA and the MUX switches less than 3×8=24mA, the contacts are safe.

    Of course it's not so simple : so many switches in parallel make feedback loops so we need diodes, one per switch, or 8 per bitplane, or 64 overall... But they are small and cheap so it's tolerable.

    with the diodes, it might even be possible to use a bipolar system to save some decoding relays (MUX4 instead of MUX8), though it might be tricky...

    It is also possible to latch the read bit, in case we need a pipeline latch or timing isolator.

    But each RES64 is only a single switch and we need 2 of them, so unless I find a DPST reed relay that is similar enough, there are few choices :

    - use/find/buy MORE RES64, which will take a lot of room

    - use/find/buy more SIP reed relays (such as the Chinese ones I have found) because they are small and still cheap, though they break the "all-Russian style"...

    - find a dual-switches reed relay... => unlikely.

    This problem is specific to the register set because it has two read ports.

    I/O and other registers have only one port (usually) so we can still use this method, for example for the scratchpad area.

    Anyway, the huge parallel MUX8s were big annoyances and I'm glad I reduced their quantity. But I find myself with more questions to solve...

    Lacking a proper, cheap, well-behaved DPST relay is not a catastrophe in itself. We can build one from two SPST relays by replacing the resistor with another coil, as in the sketch below:

    The system will be less "clacky" because reading one operand will switch far fewer contacts. Maybe it's for the best for our ears, but it's certainly better for the overall reliability : the fewer energised relays, the fewer power it draws, the fewer points of failure...

    Furthermore : this diode-OR system could be useful to save a few relays here and there, because the SRI operand gets data from a MUX in the datapath. The "read enable" can be disabled if an immediate value (or anything else) is required by the instruction.

  • A "hub" for the instructions

    Yann Guidon / YGDES10/25/2019 at 20:44 0 comments

    In the Y8, instructions come :

    • from the program memory / PROM
    • from the assembly panel
    • from eventual "modern" sources

    Then the instruction bits are amplified, eventually latched, and sent to :

    • the processor's instruction decoder
    • the disassembly panel
    • eventually something else such as a semiconductor device...

    This is a bit more complex than just plugging things together because all the electrical signals must be at the proper levels...

    For now I have built the assembler panel and I start building the disassembler, and I'd love to test them together, but the levels are not compatible :

    • The input is a low-current (2mA), medium voltage (about 6V) signal
    • The output must be able to drive a string of RES15 coils (50 to 60mA max)

    The RES64A is appropriate to buffer the signals and even latch them, if appropriate biasing is enabled.

    The latch feature can be enabled on demand, for example during sensitive phases of the instruction cycle.

    Another row of relays can also (dis)connect the RES64's coil from the input, to freeze the state of the processor while the memory and other circuits are in transient phases. The RES60 would be appropriate because it's small and DPDT so only 8 relays are needed, which uses much less room than the other methods. The 16× RES64 will use quite a lot of room, in comparison...

    For convenience the latch doesn't use an intermediary capacitor because some operations require a direct connection to the core.

    Now I have to find a PCB that can host 16× RES64...

    20191118: I drop the idea of the RES60 latches because there must be a proper "instruction register".  Program memory can also contain data that must be read by LDCL/LDCH and an early latch would make it harder later...

    It also saves some of these precious relays.

    So I started building the hub board on a smaller board, with only 3 connectors and their 48 diodes. More diodes provide the latching for the RES64. The relays will not be placed yet because I need to bin/sort the whole lot and I have not received everything yet. The preliminary data is in the log First plots.

    The relays will be placed on staggered positions on both sides of the board to save space, just like it will be for the register set.

    Hopefully I'll have some room left in the corners for mounting holes...

  • RES64 > RES15 (somewhat)

    Yann Guidon / YGDES10/25/2019 at 03:02 2 comments

    I received 72× RES64A from Moldova and I'm pretty happy and lucky :-)

    @Artem Kashkanov  praised the RES55 he uses : the lower current and the higher hysteresis compared to RES15 would be great and I was eager to test something.

    The log 86. Sensing relays explored the question of the reed relays and found that even cheap 12V relays from China have desired features for certain circuits of the YGREC8 : mainly as sensors/amplifiers because they require much less current for activation.

    I just measured a RES64A and the reference I received is pretty awesome !

    • Von : 4.3V
    • Ion : 2.1mA
    • Voff : 1.7V

    The case is pretty bulky but this adds to the charm. With a suitable price, I'd get more of them and use the high hysteresis to build the register set as well.

    Even at 2.5mA (worst case), the gain is really significant ! It is less than 1/10  the current required by the RES15 and the hysteresis is somewhat higher, which means : much more stability ! And no need to bin the parts !

    Total current : 2.5 × 8 × 8 = 160mA max !

    This considerably relaxes the constraints on the power supply, the ripple (and filtering capacitance) is much less and the whole is less sensitive to interferences...

    However the supply voltage would be 4.3 + 1.7V = 6V and I'll have to find/design the proper power supply and transformer... But 6 × 0.16 = 1W max !

    Now I have to find enough vintage Russian 2K resistors...

    There is another change : the RES64 is SPST so it's only on or off... the RES15 is SPDT and can switch the output from +Vcc to -Vcc so it's pretty convenient for the output levels. A register set made of RES64 will require some sort of buffer (maybe another RES64 per bit, so I'll need 72 of them)

  • Condition codes : decoder & display

    Yann Guidon / YGDES10/24/2019 at 23:41 0 comments

    This other module is now OK as well !

    What a mess... There were a number of blunders but I managed to find and correct them all.

    The component side is nice but the wire side is ... less nice.

    I somehow managed to swap and invert some signals so it is not an exact copy of the schematics (shown below again for reference)

    This circuit decodes 3 input bits to the following symbols on 7 segments :

    A 4th bit is inverted with a relay to drive a small Glühbirnchen and signal inversion. Maybe I should also output the "NEVER" condition on the last signal of the connector...

    The system is shown and operated in this short video :

    I hope you enjoy hearing the relays' clicks :-)

    Update :
    I also added an auxiliary output to help signal the "NEVER" condition.
    However the polarity is inverse (compared to the hexadecimal modules) and can't be displayed on the usual test module.
    A reversed diode and a Glühbirnchen are enough but I'll see later how to better exploit this signal (in conjunction with the 4th "neg" bit).

  • Register name display : OK

    Yann Guidon / YGDES10/24/2019 at 17:45 0 comments

    Hi dear reader ;-)

    Some pictures would probably please your eyes, I hope you enjoy the sight !

    It was quite some work but the result is nice. The only gotcha was a forgotten diode/segment in the decoder at NU2.A:

    Here is a video of one unit under test :

    I reuse the same pinout and test board as the #Numitron Hexadecimal display module for convenience :-)

    I'll have to do some "optical design" to prevent glare/reflections and keep the Numitrons readable, but this is for another time. As you see, I use a separate connector for modularity so I can design the front panel independently.

    I'm already working on the condition display...

  • Decoding the register names

    Yann Guidon / YGDES10/16/2019 at 02:06 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 / YGDES10/15/2019 at 00:28 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 / YGDES10/12/2019 at 23:23 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 :-)

View all 93 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