Minecraft Computer v5, 8bit addition, 5bytes RAM 8 bytes ROM, HEX 7seg Lamp Screen, Branching and Looping Capable

This is version 5 of my Minecraft Computer, which includes the following things:

a revised adder, which uses the same XOR gates as the old version, but fits them closer together, making it thinner and much faster than the older one, incorporates "instant carry" by ohmganesha

a new piston-powered register system, including piston row selector. again, much faster and smaller than the old system. This system uses two-wide RS NOR gates, which can be stacked to make each slice of the adder 2 blocks wide, with 1 block between each slice. This system was designed by me.

A new ROM system, which replaces the stacked RS NOR gates with a binary decoder, much like those found in a screen decoder. This reduces the complexity and gives huge speed gains, as there is no longer a torch stack adding two ticks between each line of ROM. This is controlled by a 6 bit version of HansLemurson's Branch-Capable Program Counter, which can be used to jump to a line of ROM from another. I've also used this to implement If statements, which i'll explain later :)

A new RAM system, which stacks the RAM horizontally next to each other, rather than on top of each other. Again, this removes the need for laggy torch-stacks which speeds things up massively. I designed this too.

A new screen design, which speeds up the decoding massively thanks to removing the idiotic design choices I put into the first model. The whole thing takes up half the horizontal space and should be able to decode any hexadecimal digit in 3-4 ticks. The wiring between the screen itself and the decoder has also be shrunk into about 4 blocks of width, which reduces the footprint a little. The decoder is a lot taller than the old model, but since its no taller than the screen, it can now be stacked into an infinite uniform grid of 7 segment displays!! if you should want such a thing... I did the rewiring, but the decoder design was pinched from HansLemurson, who cites a user called Grimmelcarr (sp) as the original creator.

A new command decoder, which combines the two from the previous version into a single huge decoder, which stretches out across the top of the computer. This model uses a new decoder design that I invented, which allows it to output every other block without requiring extra width as other models do.

IF statements. If the numbers stored in the two input registers and equal, the ROM controller can be told to go to a different line within the ROM. This has some limitations and problems as it stands, which ill go into later.

The instruction set is as follows:

00000001 = toggle register input
00000010 = select register A
00000011 = select register B
00000101 = clear both registers
00000110 = clear register A
00000111 = clear register B
0001AAAA = if register A == register B, ROM_ADDR = 0?AAAA
001AAACC = memory operation, MEM_ADDR = AAA, command = CC: 00 = nothing, 01 = read, 10 = clear, 11 = write
1NNNNNNN = numeric input to a register, N = number

The map available for download is preconfigured with a program that will constrantly add 1 until something breaks, which I used to demonstrate the looping ability and also to test the screen

Known bugs:

the ROM controller can bug out sometimes, with the pistons dropping blocks and suchlike. This is a fault of the controller and not my implementation :P *Fixed in v6*

IF statements are bugged if they are applied after line 16 in the ROM (ie 010000), this is because the IF statement can only set the first 4 bits of the decoder (which is 6 bits wide), and the last 2 bits are not properly zeroed by the mechanism. This should not be a problem since the model provided only has 8 bytes of ROM, but should you choose to extend this to the point where it becomes a problem, jumping with the full 6 bits can be used to ensure IFs are only placed within the first 16 lines of the ROM. *fixed in v6*

only the first byte of RAM is addressed. This is due to me being unhappy with the fact the super-shrunk-down command decoder is still to big to uniformly address all the memory. however if youd like access to it, the decoder can be extended, if you can figure out how to build my super-annoying decoder model :P

NOTE: i have now addressed this problem, and all RAM can be addressed uniformly in v6. i accomplished this by lowering the number of instructions to 2, combining clear and write into the same instruction. this also means i have an extra bit for addressing memory, so v6 will be able to address up to 16 bytes.

I think thats about it, let me know in the comments if there is anything I have forgotten, or you'd like something explained in more detail. Other comments/suggestions/criticisms are also welcome :)