View unanswered posts | View active topics It is currently Thu Mar 28, 2024 2:45 pm



Reply to topic  [ 71 posts ]  Go to page 1, 2, 3, 4, 5  Next
 G6A-RISC Relay Computer 
Author Message
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 328
Location: Girona-Catalonia
This will be my attempt to design and build a relay based computer.

I have already some specs defined:

- RISC based, 16 bit instruction set. Strictly constant number of cycles per instruction.
- Up to 8 registers including the PC. This can be reduced if constraints appear later on physical space or total number of relays, but that's what the instruction encoding will support.
- Only 16 bit native operations, no 8 bit ops available. 32 bit operations can be performed by chaining 16 bit instructions through 'carry' flags.
- Harvard Architecture with separated program and data memory.

It will not be a "pure" relay based computer, as some concessions to modern technology will be allowed. The "concessions" are the following:

- Memory will use standard IC's. The main goal is to build a relay based CPU, so let's do things a bit easier by allowing "modern' memory.
- Diodes will be used to help some logic functions if that reduces the total relay count, but actual relays will be always preferred if possible. Functions that mostly benefit from diodes are OR gates and encoders (diode arrays). Diodes can also protect registers from feeding back their values into their sources.
- The main clock signal will be generated with TTL logic.
- The computer/cpu will be assembled with double sided pcbs and modern miniature relays.

Auto imposed "constraints":

- Single voltage source for relays (12V)
- No fancy playing with relay coil ends. For example a xor function can be performed by connecting each input to one side of a relay coil. These kind of things will not be allowed. In fact one side of all relay coils will be always connected to ground. A flyback diode will be mounted in all cases.
- No playing with voltages and resistors to get logic levels and logic functions. Logic levels will be only defined by actual relay contacts driving the single voltage source. 12V is the "1" state. A floating contact is the "0" state.

Sources of inspiration. Over the last decade, a number of "modern" relay computers have been made or initiated and there's plenty of information on the internet. I have been attracted by the following ones, although I have some constructive criticism to contribute on all of them (my own point of view, of course):

1 - Mercia by Jeroen Brinkman: http://www.relaiscomputer.nl/index.php

This is the most impressive one, and yet unfinished. The project is very well thought of, and there's a great deal of detail and useful info on every aspect of the computer. Still, I think some design aspects are more complicated than they need to be, starting by the CPU architecture itself. It's interesting that there's a limited use of modern technology except for diodes and leds.

2 - Harry Porter relay computer (do not confuse with Potter) http://web.cecs.pdx.edu/~harry/Relay/

I regard this one as the "de facto" reference. Probably one of the first "modern" relay computers, as many other designs seem to have based on this one. It is made of big relays so it literally takes a room despite the total number of relays is average (415 relays according to the author). Aside of the relay size, I think this is a "classic" that possibly quite mimics the architecture of real relay computers that were available in central Europe early in the 20th century. One criticisable aspect of this computer is the reliance on a long "sequencer" which requires many clock cycles to execute a very simple instruction set.

3 - The Relay Computer UK by Paul Law. https://relaycomputer.co.uk

Well, this is probably a clone of the Harry Porter one, maybe with some modifications and improvements, but basically doing the same with much smaller and faster relays, mounted in nice PCB designs. The same comment about the "sequencer" would be applicable here. I think it's not finished yet.

4 - Zusie by Fredrik Andersson http://www.nablaman.com/relay/about.php

Another implementation of a 'classic' relay computer, with many aspects shared from the Harry Porter one but with a fewer number of relays (268 relays) put in a nice enclosure where all relays can be seen operating without having to turn around an entire room. With an online simulator too.

5 - Clickety Clack https://www.youtube.com/channel/UC5-_rpS40owFzVVuxDF70Tw/videos

This one is only available on youtube. The project is not finished and it even looks stalled to me. The interesting aspect of this one is the great attention to detail at making nice pcbs and good looking layouts, but I think it suffers from some poor architecture design decisions that make it using far more relays than necessary for what it does.

6 - The Single Board Relay computer http://relaysbc.sourceforge.net

This is an interesting, compact design, which is a fresh departure from all the earlier architectures. In this case, the instruction encoding is 32 bit long (!), but the reason for that, is not complexity but just the opposite. The idea is that all individual control signals are directly encoded as single bits in the instructions, so that the cpu lacks an actual 'decoder' because the instructions just deliver the required control signals directly. This is interesting and quite RISCy but of course this can't be applied on more complex architectures with more evolved instruction sets. Also, this particular build relies too much to TTL circuits for my liking, which makes it slightly less appealing for a Relay based computer.

7 - The RISC Relay CPU by roelh http://enscope.nl/rrc/

Well, this one surely beats in performance all of the 'classic' ones above by a great extend, and maybe even the "Single Board" one. Interestingly, the author is an active member of this forums (roelh) which is also the author of the "Kobold" TTL computer. I very much like the overall design, most of the architectural aspects, as well and the attention to performance that has been put into it. It is a mostly RISC computer but not a "pure" one because it still has a couple of instructions that require extra cycles to be completed. On this design, performance has been clearly put as top priority, and this means that some of the rules that I posted above had to be broken, particularly the use of voltage trickery to get instant logic functions instead of actual relay logic. That's fine for the purposes of it, but I would rather go for a design that results in a cleaner schematic even if some more relays are required. Another (constructive) criticism is the missed opportunity to put it all in a nice, solid enclosure as opposed to the rather fragile arrangement that it is now. As another positive, the availability of an online simulator is great!.


I will follow with more details about what I did so far in the next couple of days.


Last edited by joanlluch on Wed Jan 22, 2020 10:52 pm, edited 1 time in total.



Fri Nov 29, 2019 3:31 pm
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
Great collection of predecessors! Hope to see you build something excellent.


Fri Nov 29, 2019 4:56 pm
Profile

Joined: Wed Nov 20, 2019 12:56 pm
Posts: 92
I'm finding myself grinning at the names of these projects - that's got to be a good sign!


Fri Nov 29, 2019 10:36 pm
Profile
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 328
Location: Girona-Catalonia
I found that it is possible to simulate the relay computer in the venerable logisim. The software does not have 'native' relays but I am using the following models to simulate them:

Attachment:
DPDT.png
DPDT.png [ 6.62 KiB | Viewed 5915 times ]

Attachment:
DPDTr.png
DPDTr.png [ 6.75 KiB | Viewed 5915 times ]


This uses either multiplexers or demultiplexers to simulate what a relay would approximately do. The main differences with respect to an actual relay are that logisim will add a 'contact' delay, which a physical relay won't have, and that the logisim model only works form left to right.

The reason for having two models is because physical relay contacts work in both directions, but not the logisim models. Both models represent the same relay type, but I need to use the one or the other, depending on what side of the 'contact' is supposed to be the input and output.

One nicety of logisim is that it properly manages Z-state conditions. This is perfect for relay logic because logic '1' is relay "connected to Vcc" (1-state in logisim), and logic '0' is relay "not connected" (Z-state in logisim). This means that Relay Latching circuits work perfectly with the models above.


Sun Dec 01, 2019 5:27 pm
Profile
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 328
Location: Girona-Catalonia
Registers are modelled in this way in logisim:

Attachment:
RegBase16.png
RegBase16.png [ 31.35 KiB | Viewed 5913 times ]

Attachment:
Reg16bit.png
Reg16bit.png [ 9.62 KiB | Viewed 5913 times ]


The first image represents a 16 bit register with the essential control lines briefly described below:

- Input Enable (IE): Connects the register to the input bus, thus updating the register value when IE is 'On'.

- Output Enable (OE): Connects the register to the output bus.

- Hold (H): If 'On' the value on the register is kept (stored) after IE goes off. For the register to get the input value, H must be set to 'Off' while 'IE' is on. Then, 'H' must be set to 'On' before IE goes off, and the input value must not change at any time during that.

The second image is the complete register incorporating two additional relays to help manage the control signals. The box labeled 'R' is the first circuit above. During normal CPU operation, IE and CLR will be set simultaneously to store a value to a register. These additional two relays just make sure that H (Inverted CLR) goes 'off' slightly after IE goes 'on', to prevent an initial glitch on the register relays. The CPU controller already makes sure that CLR goes off before IE, to properly keep the new register contents.


Last edited by joanlluch on Fri Dec 06, 2019 7:58 am, edited 1 time in total.



Sun Dec 01, 2019 6:11 pm
Profile

Joined: Mon Oct 07, 2019 1:26 pm
Posts: 46
Hi Joan, your register has a problem. Suppose 00000011 is stored, then it will connect both outgoing lines D0 and D1 to each other, also when the output enable is not activated, due to the backdriving effect. Thats one reason why I use diodes ;)

For simulating the low-level circuits of a relay project, I recommend the Falstad simulator: http://www.falstad.com/circuit/

The relays can be selected in the "Draw" menu under "Passive components".

An example of using the Falstad simulator for relays can be found in my Simple Relay ALU project, https://hackaday.io/project/162246-simple-relay-alu (Scroll to the end of the Details section).

Advantages of the Falstad simulator:

1) It will also simulate 'backdriving', current that flows through a contact in the direction that was not intended,

2) It shows the actual position of the contacts.

3) You can edit the relay symbol to set the resistance and attract current.

Do you know HAD page: https://hackaday.io/project/11798-relay-based-projects ??

You might also like my relay-ALU without diodes: https://hackaday.io/project/162246-simp ... ny-dollars


Mon Dec 02, 2019 12:12 pm
Profile
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 328
Location: Girona-Catalonia
roelh wrote:
Hi Joan, your register has a problem. Suppose 00000011 is stored, then it will connect both outgoing lines D0 and D1 to each other, also when the output enable is not activated, due to the backdriving effect. Thats one reason why I use diodes ;)
For simulating the low-level circuits of a relay project, I recommend the Falstad simulator: http://www.falstad.com/circuit/


Hi Roelh,

Thanks for your insights and pointers.

I'm aware of relay back-driving and I attempt to design my circuits with that in mind, including diodes in cases where I can't solve it by adding a contact.

In the circuit I showed above, I used diodes to prevent backdriving to the input lines. Since logisim does not have actual diodes, I placed a buffer gates to simulate them as shown in the drawing above. The diodes at the input gates prevent any input register to change when this register is updated.

However, I don't see the problem with the outputs. It is true that D0 and D1 will get connected through the OE line in the example you posted, but I can't currently think on any negative consequences of it. Why is this bad if I systematically place the shown diodes on the Inputs of all registers, and I follow the rules that I mentioned on the opening post? please can you clarify?. Thanks

John


Thu Dec 05, 2019 10:03 pm
Profile

Joined: Mon Oct 07, 2019 1:26 pm
Posts: 46
Hi Joan, I suppose this is the output circuit of your register: (2 bits shown)

Image

And I suppose you want to connect the output of two (or more) registers to a bus like this:

Image

Now suppose register A has both bits set, and register B has only bit 1 set. The picture shows the
flow when we want to put register B on the bus:

Image

So both bits on the bus get a 1, where the upper bit should be 0 !

(Don't pay attention to the "register D0", "register D1" comments at the reset inputs, they are left-overs from an orignal drawing where the registers were called D0 and D1)


Fri Dec 06, 2019 9:59 am
Profile
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 328
Location: Girona-Catalonia
Hi Roelh,

I understand what you mean, but in my case I think the problem you describe will not happen because register outputs do not directly connect to the same bus. Stored values end going to ALU input-bus A, or to ALU input-bus B, through a 'select circuit' like this one:

Attachment:
BusSelect2.png
BusSelect2.png [ 19.53 KiB | Viewed 5755 times ]


Each register has its own 'select circuit' connected to the outputs, which allows them to be connected to either the A-Bus or the B-Bus or both. On that circuit, SA or SB (or both) can be selected to present register outputs to the ALU inputs. Registers that are not selected get totally isolated from the output buses.

The register OE signal can be even set always to "1" because the 'select circuit' already isolates register outputs from ALU input buses. In this context, I could just have used SPST relays and pick the register values from their bobins, but I chose to standardise everything on DPDT relays and to get the register values from actual contacts. This makes sure that any glitches down the signal chain could never affect stored register values. I still may be missing something, so I sincerely appreciate your comments.

Thanks,

John


Fri Dec 06, 2019 3:44 pm
Profile

Joined: Mon Oct 07, 2019 1:26 pm
Posts: 46
Well, the OE signals suggested that the register would be connected to a bus. But if only one register connects to that bus there will be no problem, and you can indeed have the OE's active all the time.


Fri Dec 06, 2019 4:12 pm
Profile
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 328
Location: Girona-Catalonia
roelh wrote:
Well, the OE signals suggested that the register would be connected to a bus. But if only one register connects to that bus there will be no problem, and you can indeed have the OE's active all the time.

Well, I guess I initially named it OE because that's what it was supposed to be. The bus select circuits were supposed to be just single 'switching' relays that would connect outputs to either bus A or Bus B. In this scenario, the relay OE signals still were what their name suggest. But then I wanted to be able to drive the same register to both buses simultaneously and thus replaced the 'switching' circuit by the 'select circuit' shown above.


Fri Dec 06, 2019 5:15 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
I like the idea of a relay based computer. I’ve been following these posts.
I got a small bag of PC mount telephone relays at the surplus store a while ago. I had planned on using them in a robot. They are potted to look like dips. And I was wondering how difficult it would be to create a computer using them.

_________________
Robert Finch http://www.finitron.ca


Sat Dec 07, 2019 4:29 am
Profile WWW
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 328
Location: Girona-Catalonia
Hi Rob,

Thanks for your interest. I am also reading your new micropo 6502 thread with great interest, particularly since member Drass is attempting a fully pipelined 6502. (I just commented on your thread). I must admit that both these projects are significantly above my head, but I understand that they are two different approaches to get the thing running as fast as possible, and that some architecture constraints interleave between these approaches, such as "branch prediction". I find both your thread and Drass's one on the 6502.org forum quite fascinating.

About relay computers, well, I enjoyed playing with relays and lamps when I was a child and I learned on my own the very basic principles of electric switching circuits, however then moved to automation software for my living. I guess that now that I'm semi-retired is my opportunity to seriously play with them. In principle, I will be using either the Omron G5V-2, or the more expensive G6A-2, which looks like that:
Attachment:
G6A-274P_02.gif
G6A-274P_02.gif [ 23.93 KiB | Viewed 5722 times ]

Both have identical footprints, but I like most the latter because it's less than 9 mm tall (which should allow me to stack more pcbs in a smaller space) and it has a longer specified duration.

Relay logic is different in many aspects than logic gates made with transistors: you can generally create logic gates with less relays than the equivalent transistor gates, but they behave in peculiar ways compared with TTL. Relays also allow for some trickery that is not possible with TTL gates, and the rules are not quite the same. For example, you can create a latch circuit with a single relay, and a register with just one relay per bit, but the latched relays will feed back their stored values back to the inputs, which may turn into unintended consequences. Particularly, connecting a source register to a destination register will result in both of them being updated with the logical 'or' of both values, which is definitely not the intended behaviour...

Another peculiarity is that it is not generally reliable with relays to create edge triggered circuits, or to move a register value back to the same register after some computation. So relay based computers must implement approaches involving register duplication and 'sequencer circuits' that prevent unintended behaviour when moving data around.

That's what I learned after reading and studying the previous work made by the relay computer authors that I mentioned on the opening post, including of course the excellent work of forum member Roelh.

For those who really like relay computers, I think that this video posted just one week ago about a still running and maintained relay computer in a Japan museum, is both informative and fun to watch (though a bit long, sorry). Narrated in English by someone who sounds to me like some central-to-northern European accent, which I particularly find easy to understand:

https://youtu.be/_j544ELauus

Joan


Sat Dec 07, 2019 10:35 am
Profile
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 328
Location: Girona-Catalonia
I have now the essential ALU components defined, and it looks like this in Logisim:

Attachment:
Alu16bit.png
Alu16bit.png [ 9.73 KiB | Viewed 5721 times ]

Attachment:
AluController.png
AluController.png [ 6.91 KiB | Viewed 5721 times ]

Attachment:
AluBase4bit.png
AluBase4bit.png [ 6.5 KiB | Viewed 5721 times ]

Attachment:
AluAdd6.png
AluAdd6.png [ 9.49 KiB | Viewed 5721 times ]

Attachment:
AluSub6.png
AluSub6.png [ 13.37 KiB | Viewed 5721 times ]

Attachment:
AluBase1bit.png
AluBase1bit.png [ 25.5 KiB | Viewed 5721 times ]


The ALU was implemented in logisim using hierarchical circuits. The hierarchy is not explicitly stated on the drawings above but I hope it is obvious enough based on the file names. The first drawing is the entire ALU and the following ones are sub-circuits or sub-sub-circuits. Generation of status flags and status register are not yet implemented.

In anticipation to the instruction set that I will possibly post late next week, the ALU has the following functions:

Ld A. Selects ALU input A and places it to the output. Will be used by 'MOV' and the 'SELECT' instruction, (similar to CPU74 architecture)
Ld B. Selects ALU input B and places it to the output. Used by 'SELECT' in combination with status flags.
And, Or, Xor logical functions
Add, Sub without carry. Carry/borrow is ignored for these two, forced to 0 for add and forced to 1 for sub (borrow == not-carry)
Rsb. Reverse sub. Used by the reverse immediate sub instruction (similar to ARM).
Adc. Add with carry
Sbc. Sub with borrow (== not-carry)
DAdd. Decimal addition, aka BCD with carry. There will be no equivalent no-carry instruction, so carry must be explicitly cleared before decimal addition if necessary.

The basic 1 bit ALU is no less than the Dieter Mueller implementation, which already has all the required functions for this CPU including "select" and "reverse subtract" among others that are not used in this case. It uses 5 relays per bit.

BCD arithmetic is implemented on sets of four, 1-bit ALU slices, also following the excellent Dieter Mueller's articles. The trick here is to add +6 to one of the 4 bit inputs (input B in this case) so that the carry flag is generated appropriately. The result must be corrected by -6 if carry was not generated. The +6 circuit uses only 3 relays per digit including the optional enable of the circuit (as it must be transparent for non BCD data). I didn't manage to achieve such compactness for the minus-6 circuit, as it requires six relays per BCD digit, although three of them only use one of their contacts. So that's a total of 36 additional relays in the ALU for supporting 16 bit BCD addition.

One interesting aspect of Relay based arithmetic, is that Carry propagation does not cause any delay, regardless of the CPU word size. So it doesn't matter if the CPU is 8, 16, or 32 bits. All of them will take exactly the same time to complete an addition of their word size.

Finally, the ALU decoder just implements a diode array that will translate specific ALU functions from the Instruction Decoder (yet to be designed/disclosed) to the required set of signals for the 1-bit ALU to work. There are 11 exclusive control signals for the ALU including BCD add, and carry-ignoring arithmetic. In principle, I will not attempt to encode/decode them to save control lines because, well, even long wiring is cheap and inconsequential on a relay computer, and it does not use relays!

Joan


Sat Dec 07, 2019 1:09 pm
Profile

Joined: Mon Oct 07, 2019 2:41 am
Posts: 585
As reminder complex relay computers used some sort of error checking code, just keep things safe
if you had a bad relay.


Sat Dec 07, 2019 8:45 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 71 posts ]  Go to page 1, 2, 3, 4, 5  Next

Who is online

Users browsing this forum: No registered users and 13 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software