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 less core issues such as the debug/test access port, the register set's structure, 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)!

I give up on the idea of playing the Game of Life (the forte of #YGREC-РЭС15-bis) but I design a VHDL version because @llo sees the YGREC8 as a perfect replacement for PICs for his #SteamBot Willie !

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 expected to be:

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

I shrunk the instruction word 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 great, 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, 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 (input signals, for register-register form)

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...

Read more »


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



New gates library, better ALU and decoder

x-compressed-tar - 152.59 kB - 04/11/2019 at 23:23



more versions of the ALU8 decoder

x-compressed-tar - 148.85 kB - 04/04/2019 at 23:10


View all 31 files

  • The disassembler panel

    Yann Guidon / YGDES08/08/2019 at 02:31 0 comments

    As you can see at Log: Don't go full Numitron ! Unless... OK whatever.,  I started to design the disassembler and I totally renewed the look:

    This version now shares a pair of Numitrons to display either the SRI or the Immediate field, which saves a bit of room and 2 tubes but adds some complexity in the decoding logic (yet not enough to scare me, of course). The above display is not compliant with the normal assembler but close enough and it gets the job done :-)

    I draw a lot experience from the #Numitron Hexadecimal display module so I know what to expect and what to do to display the desired patterns on the 7 segments. There is no technical challenge anymore to display the CND, SND, SRI and Opcode fields, but it's still a lot of work, in particular for the Opcodes: this decoder not only must display 19 words on 3 tubes, but also sends control signals to enable the other fields.

    It's going to be small and gorgeous but behind the front panel, the electronics will be pretty dense and draw a significant amount of power...

    Damnit I forgot that IN/OUT have 9 bits of immediate address...

    The Imm field will create more problems, on top of the multiplexing with the SRI decoder. The field must select the width between 4, 8 and 9 bits. The last case is not a problem because an address is just a positive number. Imm4 is sign-extended to 8 bits (easy: 4 relays) but should Imm8 be represented as a signed number ?

    Then there is the special case of Add imm4(>=0) where Imm4 is incremented.

    The easy way is to simply display the number as is, and forget about it, though the display would not be accurate. It would even be misleading.

    But then, if the Add correction or the negative display are implemented, an increment unit is required. And negative numbers require a XOR to transpose to positive numbers. This means more circuits in front of the display modules...

    But with negative numbers, the added Numitron can have another segment used, for the sign bit:


  • Updated wiring of the new assembler panel

    Yann Guidon / YGDES08/04/2019 at 16:41 0 comments

    I nailed it !

    I solved a "bug" and I now use "normal" hexadecimal encoding knobs. This required a big redesign... There are now 29 diodes but only one per signal so I can use old, low-current point-contact D9K.

    Another big difference is a rotary 4-poles 3-throw selector ! It selects between the Imm8, Imm4 and Register forms. I could use interlocked switches as well but their mechanical installation might be more complex, more holes and alignment...

    I'm only missing one row of 8 switches for now, but I can start the construction :-)

  • ASM panel dimensions

    Yann Guidon / YGDES07/31/2019 at 00:40 2 comments

    As I received the buttons, I was able to not only get electrical information but also dimensions. I updated the layout:

    The 50 buttons easily fit in a 18×18cm square so 20×20cm is a safe dimension for this panel.

    Remember that it's only the instruction, and more things are done in other panels :

    • The disassembly panel shows the instruction being sent to the core (it's the reverse of the ASM panel)
    • The control panel selects the source of the instruction, generates the clock, sends the clock pulses to the  core (one-shot, several ones or continuously)
    • The debug panel has several event counters that can stop the core...
    • More panels display the inner state of the core

  • Interlocked switches galore !

    Yann Guidon / YGDES07/29/2019 at 01:44 1 comment

    I received quite a few switches and more will come later !

    These are 10 interlocked switches, with their caps, and they are just like I wanted :-)

    2 of them will be used for the opcode selector.

    For the other selectors I needed somethign more simple and pre-made, and I have found it in the form of the 8-channels video selectors. And I have a good surprise ! Look:

    I expected the box to contain a single PCB but there are two, making the switches assembly very easy to remove !

    2 screws and 2 connectors to remove, and there you have the module :-)

    The traces are easy to follow and they are already conveniently wired for my purpose :

    The SRI, SND and CND fields are 3 bits wide, and the selector outputs 3 bits, which is a great match.

    I can wire the switches' inputs to a common rail, such that the 3 output bits will contain the binary code of the selected button. I can also bind the boards together to make a more sturdy structure (I have 2 but need a 3rd for the conditions).

    There is a last technical problem though, with the hexadecimal encoder : the lower nibble requires a type of switch I don't own... But @Artem Kashkanov has the perfect part ! From Russia, of course ;-)

    This selector has individual SPDT switches for each bit, making my diodes hack possible :-)

    I'm still missing a few extra switches but they'll come soon enough.

    At least I successfully designed a fully-passive assembler panel, with only one diode drop on certain signals, and no requirement of external power (no relay or other logic). The panel can work with relay logic, transistors, TTL...

    Time to think about the disassembler panel now ;-)

    I have easily modified 2 8-ways selectors !

    I can say it works very nicely :-)

    I'm waiting for the delivery of the 3rd module so I can have all the necessary buttons for the SND, SRI and CND fields.

  • More wiring of the new assembler panel

    Yann Guidon / YGDES07/23/2019 at 02:32 0 comments

    I figured a few things...

    Here is the aggregated schematic for the opcode field :

    It might look complex but most of the complexity has been examined in the previous log and it's basically a pair of binary encoders that have been chained through the XT button.

    The tricky part is the simultaneous selection of buttons from both rows : some combinations would disrupt the binary code. This occurs when the "lower row" (AND through CALL) has one button pushed with a code that has more than one set bit (ADD, SUB, CMPS, ANDN). There is a potential path that is now broken by 10 diodes. And since the locked switches work together, only one switch is now required.

    The "upper row" OTOH doesn't need diodes because the switches are interlocked. There is no place where different signals are brought together, except when a switch is pushed.

    I'm working on the other switches...

    More schematicsing :-D

    Going further, I added the dual hex encoders and tried to join everything together:

    It's almost complete. b2,b1,b0 didn't change, nor did b15,b14,b13,b12,b11. The SRI field (and the LSB of the condition) can be combined with the lower half of the immediate field, while the condition field (plus a couple more bits) can be combined with the higher half.

    However the simultaneous activation of the lower half for both Imm4 and Imm8 is more complicated and not yet implemented. The trivial version would use another diode, so the total drop would be 3 diodes !

    I need a method to reduce this drop, I suspect there is a way to keep it down to 1 drop but I need to test it...

    And I should switch from dia to EAGLE :-D

    I solved a potential problem caused by several diode drops in series :

    The free switches for the XT button isolate the main signals and prevent the use of diodes. The hexadecimal encoder requires separate switches, so each signal can be driven by a pair of diodes (instead of one diode at the output).

    There is one remaining switch and I wonder how to use it to remove more diodes...

  • Wiring the new assembler panel

    Yann Guidon / YGDES07/20/2019 at 20:28 0 comments

    As mentioned in A new assembler panel, I'll soon (hopefully) get a bunch of 4PDT interlocked buttons !

    I have already assigned their function but how will I make them work ? Electrically, I only want to have switches, eventually some diodes, and I would love to have the panel use the least power possible, which means ideally no relay. I hope that the panel can be reused for other technologies with the least amount of changes.

    The critical information is contained in these 2 diagrams :

    Already we can see 2 fields that are (almost) fixed :

    • The SND field uses 3 bits and a row of 8 buttons that can directly encode the binary code. The 4PDT switches are enough to encode the 3 bits easily. The question is settled and the same system will be used for the SRI sub-unit.
    • The Opcode field has 19 codes (and as many buttons). Only RC and INV use 4 set bits so the 4PDT has some spare room, that we need indeed !

    There is no interlocked switch with 19 buttons. The most I have found is 12 so I have chosen to use a pair of 10-buttons rows.

    • The upper row contains the SH/SA/RO/RC/LDCL/LDCH/IN/OUT/INV opcodes. That is 9 opcodes. Each 4PDT switch can directly encode the binary value, except bit 15 which is always 1.
    • The 10th button of the row is not an opcode but an "escape" button. Let's call it XT, it's an extention that selects the other row (which is the most used anyway) so it's not operated often. The 4PDT switch sets bit 15 to 1 when released (selecting the above opcodes), and otherwise activates the I8/R and Imm8 field.
    • The lower row contains the AND/OR/XOR/ANDN/CMPU/CMPS/SUB/ADD/SET/CALL opcodes. Only 3 of the dual-throw switches are needed. The 4th bit remains unused.

    How will this work, electrically ?

    The panel uses "positive logic" where you implement a bit set to 1 with an electrical contact to an extra signal (usually a bus/rail, such as a positive voltage source). The switches will steer each instruction signal to the common voltage, depending on its encoding.

    We can already write some truth equations for the most significant bits of the instruction word :

    • b15 = ( XT & (SET | CALL))
      | /XT
    • b14 = ( XT & (CMPU | CMPS | SUB | ADD))
      | (/XT & (LDCL | LDCH | IN | OUT | INV) )
    • b13 = ( XT & (XOR | ANDN | SUB | ADD))
      | (/XT & (SH | SA | RO | RC | OUT | INV) )
    • b12 = ( XT & (OR | ANDN | CMPS | ADD | CALL))
      | (/XT & (RO | RC | IN | INV) )
    • b11 = ( XT & I8/R)
      | (/XT & (SA | RC | LDCH | ( IMM9 & (IN | OUT) ) ) )

    As usual the OR operator "|" is implemented by parallel switches, while the AND operator "&" connects switches in series.

    The terms contain XT  which means the Normally Open side of the XT switch. So XT is a MUX for two sub-buses (b14,b13,b12).

    Due to the interlock mechanism, /XT is redundant because it is always off when SH/SA/RO/RC/LDCL/LDCH/IN/OUT/INV opcodes are selected. However the 10 other opcodes are not interlocked and XT must disconnect the affected bits to prevent the other row from interfering.

    Updated equations:

    • b15 = ( XT & (SET | CALL))
      | /XT
    • b14 = ( XT & (CMPU | CMPS | SUB | ADD))
      | LDCL | LDCH | IN | OUT | INV
    • b13 = ( XT & (XOR | ANDN | SUB | ADD))
      | SH | SA | RO | RC | OUT | INV
    • b12 = ( XT & (OR | ANDN | CMPS | ADD | CALL))
      | RO | RC | IN | INV
    • b11 = ( XT & I8/R )
      | SA | RC | LDCH | ( IMM9 & (IN | OUT) )

    This is translated into the following diagrams :

    The good news is : there is apparently no need for a complex switch for XT because its signal can be shared with several subsignals, thus saving switches...

    The bad news is : to prevent certain cases of feedback/bypass (despite the use of independent switches) the output of XT must be guarded with diodes.

    However, there are multiple switches per button so the number of diodes is kept low. Here is...

    Read more »

  • A new assembler panel

    Yann Guidon / YGDES07/19/2019 at 23:11 0 comments

    A few days ago, I had a blast from the past !

    While looking for a multi-position switches in the local store, the clerk proposed a type of switch I had totally forgotten !

    The impressive interlocked switch !

    I initially wanted to use rotary buttons but you can't find all the options and it takes some turning...

    These buttons solve most of the problems I had, they use more room but they provide a direct access to everything. With about 50 buttons (and 2 rotary Hex encoders) one can select a whole instruction with a few pushes. Some rows or selectors can be enabled or inhibited, the conditions and the IMM knobs can be selected depending on the format selectors...

    Here is the first sketch :

    I just ordered more parts to start prototyping...

    These switches are quite awesome. There are rotary switches but turning them all the time would quickly become ... hmmm...

    I keep the rotary selectors for the numbers but the opcode, the condition and register names now have their own button. These are not inherently linear things but symbols. So it's good to point directly at them and push the right button right away, instead of blindly turning a selector until it reaches the desired position.

    The other advantage is more technical : these switches can come in 2PDT, 4PDT, 6PDT and even 8PDT ! This means that a lot of signals can be encoded directly at the mechanical level, reducing the amount of diodes and relays ! For the main parts I have chosen 4PDT and the IMM4/IMM8/REG selector is 8PDT.

  • The nexus

    Yann Guidon / YGDES04/24/2019 at 18:37 0 comments

    As the register set and the ALU are (mostly) ready, now comes the time to connect them. This raises many questions that I hadn't considered fully until now and even though they are not really hard, they deserve to be treated carefully and independently from the rest. This is why I create a specific unit, which I name "nexus".

    The primary purpose of the nexus is to gather all the operands and to fan them out to the sink units. So it's basic wiring, with the newly added twist to "control gate" the datapath ("data gate" ?). So it's wiring plus extra latches. And MUXes too...

    This is the part that mixes the immediate value from the instruction, with the SRI read port of the register set. With size selection and sign extension. And it must also handle the low/high part of the instruction word for LDCL/LDCH. Oh and it also must manage the crossover with PC (see the log Now faster without the "PC-swap" MUX)

    Let's first solve the easy case : SND is available directly from the register set and distributes it 8 bits to 3 ports, each with a latch:

    • the I/O "OUT" port is transparent for b15.b14.b13./b12
    • the "Shift" port (SH/SA/R0/RC) is enabled by b15./b14.b13
    • the ALU port (CALL and SET don't use SND so it's simply decoded as /b15)

    These latches isolate the buses and help solve fanout problems, on top of reducing spurious toggles in units where the result would be discarded. It looks great so far.

    The SRI part is more complex... So let's look at a drawing:

    The top half is the easy part:

    • The register set provides the 8 bits on the SRI port
    • SRI is latched to the shifter input, for the SH/SA/RO/RC instructions (b15./b14.b13)
    • SRI is also latched at the input of ALU for 8 opcodes (/b15)

    The other half is more sophisticated and subtle.

    There is the part that writes to PC and sends the value to the program memory address bus. The PC is first incremented, then mixed with SRI for the SET and CALL opcodes so jumps and calls use only one cycle. But as explained earlier in Now faster without the "PC-swap" MUX, there is a 3rd case where the other opcodes write to PC but have a longer latency, the result bus goes to a bypass (btw, PC has its own write port).

    Meanwhile, the incremented PC also goes to the result MUX (now called SUXEN, yes, it's a reverse NEXUS) because CALL must be able to write PC+1 to the result bus. This completes the crossover.



  • Census of the gates

    Yann Guidon / YGDES04/21/2019 at 20:05 0 comments

    It's time for a little census.

    [yg@Host-002 VHDL]$ grep -r 'entity' * |grep 'port' |grep 'map' |sed 's/.*entity //'|sed 's/ port.*//'|sort|uniq 

     (I removed the complex unit names by hand)

    There are 20 gates so far, more, and more complex, than what #Shared Silicon provides (only INV, NOR, NOR3, NAND2, NAND3 and some T-gates).

    I believe that by using more complex gates with more inputs (but reasonably so), there is a bit of performance and size benefit. I don't see any roadblock to get the missing gates : either I can make mine easily, or I borrow from existing free libraries.

  • How to divide the register set's power consumption by about 5

    Yann Guidon / YGDES04/21/2019 at 17:50 0 comments

    The latest source code archive contains the enhanced decoder for the register set, including 3 strategies:

    • Straight (fast)
    • update only meaningful control lines
    • update only meaningful control lines when the related field is used

    I provide a pseudo-randomised test to compare these strategies and the outcome is great:

    [yg@Host-001 R7]$ ./ 
    Testing R7:
      straight decoder:R7_tb_dec.vhdl:165:5:(report note): 100000 iterations, 702273 toggles
      latching decoder:R7_tb_dec.vhdl:165:5:(report note): 100000 iterations, 301068 toggles
      Instr-sensitive :R7_tb_dec.vhdl:165:5:(report note): 100000 iterations, 160231 toggles
    R7: OK

    There is a ratio of approx. 1/5 between the first and third result, which I explain below :

    • Given that the probability of one bit being set is pretty close to 1/2, it makes sense that the first "straight" decoder toggles the output bits every other time in average. There are 14 control lines to drive and with a 1/2 probability, 7 lines change.
    • The next method gives a better result, that you can understand using similar logic : we get 3 toggles per instruction, which makes total sense. There are 2 decoders but only 1/2 chance of change, so we can focus on one decoder. Each decoder updates only 3 of the 7 control lines because the other 4 give results that will not be used. So far, so good, no surprise at all.
    • The last method gives an average toggle rate of 1.6 per instruction. This is one half of the previous result and though it should be taken with a lot of precaution, the benefit is clear. Some instructions (about 1/4) don't use the SND field, and the SRI field is not used when Imm8 or Imm4 fields are used, giving a further significant reduction of toggles.

    Of course, these numbers are NOT representative of real use cases. I used pretty uncorrelated bits as sources, while real workloads have some sorts of patterns. The numbers will certainly increase or decrease, depending on each program.

    There is a compromise for each situation and the 3 methods are provided in the source code, so you can choose the best trade-off between latency and consumption. The numbers are pretty good and I think I reached the point of diminishing return. Any "enhancement" will increase the logic complexity with insignificant gains...

View all 77 project logs

Enjoy this project?



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