Project Red cpu build

[steve g]

some of you might know me...i've been out of the ftb/modded mc scene for a while due to Real Life(tm)

but I'm back in it..with a nice machine to play all these new packs with. While im messing around with SkyFactory...i found a redstone pack which is absolutely *perfect* for building all sorts of cool redstone/pr stuff.

I started on the idea of a very simple cpu, something that could implement BrainF*ck (google it...not hard to find info on it one component this cpu needs is a binary counter. playing around with PR's toggle latches, I came up with this

Spoiler

just a basic +1 counter. it works very similar to a piston based counter...but without the cool 'instacarry' traits you could get with normal redstone

That's neat...but it needs a reset function:

Spoiler

simply adding AND gates to the toggles between their outputs and the reset line will reset the toggles. The logic there is to only toggle the latch if it's on

But that's not enough...we need to be able to load in a value (aka load branch)

Spoiler

I'm using xor's on the toggle output and branch inputs...the xor determines if the toggle needs to be
switched if the toggle output and the branch input are not equal. Had to add buffers to keep the signals from the xor's triggering the clock line

We're almost there. The circuit can count up...but not down. lets add that as well:

Spoiler

here the green wire controls an xor gate on each toggles output. if the green wire is off, the signal from the toggle goes through unchanged. if on, the xor inverts the outputs...causing the circuit to count backwards!

I came up with this pretty much by trial and error. I tried implementing a counter using a ripple carry adder and wasn't too happy on its size and complexity (needed latches, output fed back to inputs, busing inputs/outputs all over the place, timing issues...yaaaa). This circuit is not easy to look at either but it does exactly what a bidirectional binary counter needs to do, with all the functions you'd expect

As you can see it's easily tile-able, the image only shows 3 bits implemented. I have an 8 bit version of this for the cpu build im attempting:

Spoiler

This is being built bitslice style...each layer is one bit of the cpu, and 8 layers making this an 8bit cpu (makes busing *much* easier). On the left side is the topmost slice of the binary counter. just after that are 2 registers and the edge of the ram array (64 bits per slice, x8 for 64 bytes of ram) and far down on the bottom you can see part of the ram address decoder.

still needs quite a bit:
rom space for bf programs
cpu controller
and something to track jump points in the bf code

If you look at how a bf program is written, the '[' and ']' commands are the loops. a very simple interpreter would simply scan forward or back for the start/end of the loop if needed...more advanced interpreters maintain arrays on where loops start/end or break out the loops into their own sub blocks of code. I like the jump table idea...and i think i have something for that:

Spoiler

this is what i call KVROM (unless someone knows of a device that does this): key/value rom. The idea is an input value comes in on the input bus. There are xnors on top paired to latches and the inputs. if the input value matches whats latched on the input side then the blue wire becomes active and enables the outputs for the second set of latches on the bottom. If you're familiar with javascript..this is almost like assigning properties with values to an object. You would program one of these with 2 values: a key, and its associated value. This requires 'precompiling' the code as you cant access this memory like normal ram. but it would be highly convenient so that, for example, if i'm at rom location 12 and the instruction is a '[' opcode...the value 12 would be on the input bus for several of these roms...if one responds to the value '12' then the output will show the address of the other end of the loop. Id have to use computercraft anyway to load the scripts into the computer...so programming the kvrom can be part of the loading process. more coming as i work on it

 

[steve g]

I made a bit of progress

Spoiler

i color coded stuff to make it easier to see whats what. (thats why this redstone pack is wicked cool...worldedit ftw! should give it a try, its in the twitch launcher)

orange is the counter
magenta is pc address register
light blue is mem address register
lime is ram. 4 banks, 16 bytes each
cyan is kvrom. 1 bank of 16 key/value pairs
black is busing and random bits

Spoiler

testing area...theres a bit going on in this build, need to make sure everything behaves. added some lamps on the counter to see what value is currently in it.

Spoiler

close up of one of the kvrom cells. this was optimized a bit from the first version i showed you. xors do the comparison now (was using xnor+invert cell in the original...derp) . what you cant see is the blue lines connect to a not gate underneath the stack before it comes back up again on the output side. the bundles in the center is the programming interface. i have a cc script that can load a bf file, convert it into opcodes and figure out the jump addresses. the cc computer will talk to this bus..the cpu itself never touches this line.

Spoiler

the ram address decoder. its 2x 4-16 decoders. the left most handles the lower 4 bits of the address and control which of the 16 bytes in each bank is active. the right most handles the upper 4 bits, and controls which bank is active. the black wire going around the whole thing is the clear ram signal..it just turns on all the banks/bytes and sends a clock pulse to clear the whole lot.

program rom is up next, stay tuned

 

[steve g]

and program rom is in place!

Spoiler

its all that red area on the left. 128...half-bytes? nibbles? the opcodes for this processor are only 4 bits so didnt need to build full 8bit cells. and 128 because well..bf programs are a bit...verbose. a basic 'Hello, World!' program takes at least 80 bytes (and thats highly optimized). the rom is pretty much an exact copy of the ram...same logic, same busing. even has the same decoder logic underneath it. the system can support up to 256 bytes of ram..and 256 rom instructions. as for the kvrom..it will use 2 cells per loop...so if a bf program has 4 loops, it would take 8 kv pairs to store the start and end points of the loops (the cpu would need 1 kv for the '[' op, another for the matching ']' op). i will probably throw another bank in there just in case.

notice how the only part of this build that does any form of calculation at all is just that little orange bit? brainf*ck is a very minimal language...so is this.

next up...cpu control. stay tuned

 

[steve g]

getting there, slowly but surely

Spoiler

had to add a zero flag line to the register...its the brown line going down vertically. a buffer gate (hanging on the sides of the orange blocks by the output lines) on each toggles output and a not gate at the bottom handles the logic for the zero flag. this is needed when doing loops..the loop instructions check if the current mem value is 0 and act accordingly

Spoiler

starting to implement the actual instructions. this circuit decodes the value coming in from program rom and one of those 6 lines will go active. the opcodes are set up as:

0000  halt
0010  +  // mem[ptr]++
0011  -  // mem[ptr]--
0100  >  // ptr++
0101  <  // ptr--
0110  [  // while (mem[ptr] != 0)
0111  ]  // end while
1000  .  // write mem byte to output
1001  ,  // read input byte to mem

the lines you see on the decoder are (from left to right)
halt, +/-, >/<, [/], . and ,

the +/- and >/< opcodes are implemented and working. i can do the pairs of opcodes on one line because the least significant bit of the opcode controls the counting mode of the counter...very convenient

when the opcodes are done, eventually the ends of those control circuits will connect to a final circuit that increments the code pointer in rom and advance it to the next instruction, and repeat the process until the halt line goes active.

and soon ill need to get computercraft going. ill need a big screen going so we can see the program output and other bits..possibly have some debug info displayed as well.