Scratch Build – In Progress Project Transistorized - Updated 29th October, Build started!

UPDATE

Right, it's time for a (very overdue) update

I do however have a very good excuse for my absence of updates though; Firstly my copy of Operation Flashpoint arrived from amazon on the 1st september, which took a fair amount of time to complete on hardcore mode

Secondly, a lovely box arrived from amazon on the 5th containing BF:BC2, which needless to say has been incredibly addictive
(if anyone's seen a complete newby called joey9801 crashing hundreds of heli's; thats me )

Last but far from least, I've just started sixth form to do my A-levels, so I no longer have the endless expanse of the summer holidays to design stuff in

Anyways, back to the update:

If you remember from last time, we completed the design for the ALU (which is gonna take up more than 600 transistors on it's own ), and we laid down the foundations for the rest of the computer with the first revision of the instruction set. having a set of instructions is no good if you have nowhere to put them, so the first thing I am going to be designing today is the program memory.

The first thing I am going to be designing is the program memory. I previously stated that it would be made out of SR latch based registers, but even for a small 32 line program, this would take up more than 1.5 thousand transistors; I simply dont have the sanity to connect that many components up. Instead what we can do is use DIP switches such as these;

and put an N-channel Mosfet between them and the bus.
Instruction Memory by joey9801, on Flickr
3 potential lines of program

Then with 5 D-latches in a counter (like in the programmable clock) plus some other circuitry reminiscent of the ALU instruction decoder, I can activate one line at a time, at a speed governed by an adjustable clock source. This circuit creates a form of decade counter - http://www.youtube.com/watch?v=VxckVE0sSiY
Decade Counter by joey9801, on Flickr

Next we need a simple instruction decode to trigger the relevant events that the instruction dictates. This works in a very similar way to the ALU decoder, except it can handle far more commands as well as shuttling address and 8 bit values through the network of registers.

The last 8 bits of the instruction always represent either an eight bit value, or a two 4-bit addresses. Each of the general purpose registers has an input enable line, and an output enable line, so to copy a value from one to another, we just enable the output line of the first, and the input line of the second. This calls for two, 4 bit decoders which we will wire up to bits 4:7, and 8:11 of the instruction bus, plus an enable line controlled by the main instruction decoder.
For example, for instruction 0:001 (write addr0:addr1 to 0111) we simply connect bits 4:11 of the instruction bus, to the general purpose bus, and send a high to the input enable line of register 0111.
Instruction decoder by joey9801, on Flickr

While this design works very well for simple programs that run one instruction after another, it does not take into account the instructions that move the program onto a different line, such as the GOTO-esque command some of you may have noticed in the instruction set from the last update. Adding the ability to jump around the different sections of the code though, is fairly simple as the instruction counter can be set to any number through direct stimulation of the slave SR latches in each bit. If we are to jump around the program with this method, we need to change the instruction set slightly so that instead of jumping backwards/forwards by a set amount, we actually GOTO a particular line.

As the goto command now works through the asynchronous parts of the D-latchs, there isn't need for much circuitry to support it apart from the relevant bit of the instruction decoder to trigger the connection from the instruction bus to the instruction counter. In fact, all the commands are based around moving numbers through the registers, which is an asynchronous process and should, in an ideal world at least, take zero time to complete. We do not live in a mathematically ideal world however, and transistors do not switch instantly, switching them too fast can result in metastability. To combat this, for every command that is not part of the ALU we will have to have a clock to regulate how much time is given to each command. The ALU based commands have their own clock however. To accommodate this we simply add a huge OR gate to all the d-latch stages of the ALU, so that whenever the ALU is busy doing something, a logic high is sent to the instruction counters 'pause' input.

For those of you who are interested, metastability is what happens when you join the mathematically ideal world of 1's and 0's, with the veritable mess of continuous voltages present in real life. In real life transistors do not switch instantly, so after changing the inputs of a system, you have to wait a certain amount of time for the circuit to settle down. This period of time is called the “Metastability resolution period” and if the inputs are changed during this period, there is a good chance that the output wont be a 0 or a 1, but something inbetween. Clearly this is a problem which is why virtually every transistor computer ever has had a speed limiting clock source. That said, there are computers in existence that don't have a clock and operate asynchronously http://tiny.cc/fdae0

Once again, i do apologize for the delay in posting this update, i blame bfbc2

Unless I've forgotten to design something vitally important, this should be the last schematic related update before this thing actually gets built!

 

AWESOME! Roughly how big will it be when it's done?

I'm going to hate myself for this but... I'm assuming it won't run Crysis?

 

If all goes to plan, the whole thing should fit onto 3, maybe 4, 30cm x 30cm boards, all stacked on top of each other to form a sort of 'transistor cube'.
Maybe I'll add some funky lights and turn it into some form of art

To your second point, YES! It will definitely run crysis.......

 

Part 4 - sample circuit

Project log 4

It's been a few weeks since I last posted on this thread but fear not, I have been quite busy.

Obviously buying over 4000 components is no small deal. To minimize any chances of ordering either grossly too many or too few, or simply the wrong ones, a small sample of the circuit must be built and tested.
The section of the circuit I have chosen to test is the program counter. This is because it contains just about all the different logic stages I’ve designed in one place, making it the ideal testing grounds for finding all the possible problems with my designs.

To give you an idea of what I’ve been up to, I’ve written up a small timeline below:

October 12th – After meticulous checking of the program counter designs, and several minor modifications, a sample batch of 100 transistors and 100 resistors was ordered

October 15th – A lovely box of transistors, resistors and LED's arrives on my doorstep

Sample batch of components by joey9801, on Flickr

October 19th – The wire wrap tool and 100ft of 0.2mm wire arrived all the way from radio shack in America, work starts on the sample piece of circuit.

Wire wrap tool and 30 gauge wire by joey9801, on Flickr

October 26th - sample circuit largely finished after roughly 14 hours build time, started writing this...

Sample topside by joey9801, on Flickr

after looking at the top of the circuit board some of you are probably thinking 'hmm that doesn't look too bad'. To those people, I challenge you to look at the bottom of the board and maintain that stance.

Underside of sample board by joey9801, on Flickr
in the circuit at the moment, there is only a meagre handful of components, around 65 transistors, and 35 resistors – in other words, there are about 25 more of this scale of circuit still to be built.


Now these pictures don’t really give an accurate impression of scale, so there is one more photo of the board below with a finger for size comparison....

size comaprison by joey9801, on Flickr
Each of the holes on the board is 0.1” away from the next, we therefore call this 0.1” pitch board. The wire is 0.2mm, however for some peculiar reason, we do not call this 0.2mm wire, but 30 gauge wire. The gauge system works in such a way that the higher the value, the thinner the wire is. The gauge system is not a linear scale either, for example 15 gauge wire is not twice as thick as 30 gauge, but 7.25 times thicker, and 5 gauge is 3 times thicker again.

With so many leads poking up, and such a veritable rats nest of thinly insulated wires, you'd probably be expecting it not to work at all. Well I have news for you gentlemen, for the large part at least, this circuit worked first time!
Take this here youtube video as proof -


The eagle eyed among you may have noticed the D-latches in the sample circuit each contain 5 more transistors than in the original design. One of these is to supply enough current to the LED so we can see when it's on, the other 4 however are there to correct a minor flaw in the original design, whereby the slave SR latch would receive an illegal 1, 1 input whenever the clock was pulsed.


Check back here sometime soon for some photos of bazillions of transistors!

 

Great idea! I'm old enuf to have done these kinds of circuits in college. I watch

john

 

Aw my head hurts from all the circuits... I'll try to back read later. I'll sub to this.

 

Hi,

first, this is amazing, even if don't really understand what's going on. But it's something I've never seen before in project logs, so I'm gonna watch it for sure...

second, you was joking about that crysis right?

 

Ahhhh, this reminds me of last week when we were making AM (grrrrrr) Radios at the local Science Centre called INTECH. Mines was the only one to work first time

 

Of course I was joking about crysis..... or was I?

I remember going to a science master-class back in 2006, we made AM radios as well, though I had no idea how they worked. If I recall correctly the circuit they gave us wasn't adjustable so it could only pick up 5 live

 

wat