So, a while back, I posted a GPU project I was working on. This thing was fairly fancy... insanely big and slow, though. Neither of those reasons was the reason I quit working on it. The real reason was a certain black, brown and green thing known only as the piston. These buggers make timing near impossible, and so I started from the drawing board again... but this time with a full-out computer.This computer doesn't use a single p*ston (other than the monitor's screen, which is 100% timing-free), in it's architecture. If you want to learn a bit more, then read down. If you just want to see all the redstone... scroll to the bottom. Also, don't forget to check out my YouTube, IceAndMC, where I will be uploading a Let's Program series on the finished computer in which we code addition programs all the way to full-out video games... ception
-------ARCHITECTURE INFO-------
All computers start with an ALU (Arithmetic Logic Unit). Most general ALUs use an instacarry piston-based adder, but the Ice 100 uses a specific algorithm known as Carry Look Everywhere, a fast adder that uses no pistons! There are many youtube videos about this type of adder, go look some up if you want to learn a bit more, especially about their interesting diagonal shape. With that said, let's move on a bit.Next, we have the registers and general purpose registers. When I program the computer, these will be used as RAM, but the definition of RAM is a bit murky and people on ORE get mad when I call it RAM. Anyways, these use repeater locks as their method of storing information... generally very simple. Two registers go to the ALU inputs, two go to the computer's output, and four go to the screen inputs. The general purpose registers lead back onto the main bus.Finally, the screen. This is unfinished at the time of writing, but here you go. The screen is 16x16, which means it only takes 4 bit inputs out of the computer's 8, only using half of its registers. It implements conditional "fill" hardware, which allows you to draw large rectangles with ease! It also uses an inverted white-wool piston screen, probably the most visible screen out there.More nerdiness to come in this section as the build continues <3
-------VIDEOS AND SCREENSHOTS------
A channel update which showcases the computer (you don't have to watch the rest Screenshot detailing all the parts with highlightingScreen capabilities Control room overviewInside the redstone (ALU to be specific)Bussing and non-timing stuff is DONE!The ROM (or memory used for static computations):The program memory, where it allhappens! -------INSTRUCTION SET------
Everything that makes this computer what it is lies within this spoiler. Explanation will be out once the computer is finished.
0000 - JMP to jump code/ARG2 bit with condition ARG1
0001 - RAM->REG ARG1->ARG2
0010 - CLR RAM ARG1
0011 - RAM->RAM ARG1->ARG2
0100 - toggle indicator ARG1
0101 - ALU op:ARG1 to RAM ARG2
0110 - get user input and save to RAM ARG2
0111 - WAIT
1000 - save RNG into RAM ARG2
1001 - ROM ARG1->RAM ARG2
1010 - GPU DRAW
1011 - GPU DRAW-FILLX
1100 - GPU DRAW-FILL
1101 - GPU DRAW-FILLY
1110 - GPU CLEAR
1111 - END
-------DOWNLOADS-------
Good news again! I've completed the instruction set for the computer, and it is now released on the thread! Final computer coming soon, I only have to bus the controller and debug it now
Rollback Post to RevisionRollBack
If the world is square, then it would indeed be flat.
Check out
for a survival let's play, CTM, redstone, and maps!
Alright, take a few more screenshots for the programmers on the computer! I have finished the screen commands within the IS, so there's only 11 commands and a program counter to go before release.
Rollback Post to RevisionRollBack
If the world is square, then it would indeed be flat.
Check out
for a survival let's play, CTM, redstone, and maps!
It's right there in the initial post under "Instruction Set".
Correction:
How many bits long are the instructions? How many registers? What ALU ops are exposed? What are the arguments to the draw* commands? How much memory is addressable?
8-bit answers some of these, but not all. (Especially as many 8-bit instruction sets have an instruction length of >8 bits)
How many bits long are the instructions? How many registers? What ALU ops are exposed? What are the arguments to the draw* commands? How much memory is addressable?
8-bit answers some of these, but not all. (Especially as many 8-bit instruction sets have an instruction length of >8 bits)
Ahh, I catch your drift now. Sorry for my earlier misunderstanding.
Instructions are 16 bits long. This includes a 4-bit instruction, two 3-bit command arguments, and a 6-bit code specific to the 0000 JMP instruction. (There are 64 available instructions, thus decoded with 6-bit).
As for ALU ops, they are controlled via a 3-bit argument, which means I can only expose 8. (I'm not the kind of person to hate command 0, haha). List:
ADD
SUB A-B
SHR
INC
XOR
XNOR
AND
OR
It's essentially enough in that respect... I hope
8 addressable non-general purpose registers:
000 - ALU A
001 - ALU B
010 - OUT0
011 - OUT1
100 - GPU X0
101 - GPU Y0
110 - GPU X1
111 - GPU Y1
And that pretty much explains the GPU draw commands as well, no arguments but based solely on the content of the registers, just like RL interrupts (theoretically speaking).
Finally, 8 addressable GPRs and 8 ROM addresses. Hope I answered all your questions there
Ahh, I catch your drift now. Sorry for my earlier misunderstanding.[snip]
...Sort of?
It actually raises more questions than it answers, though:
How does increment work? Does it simply ignore the second argument?
If there's 8 GPRs and 8 "special" registers, how does that fit in the 3-bit argument? Or are they the start of the general RAM?
What are the condition codes for jump?
Why are you discarding most of the instruction set space by discarding 6 bits with most operations? Or are you?
For the load/store operations, how do you specify the RAM location? ARG1 is only 3 bits, and I doubt that you have 8 bytes of RAM total. Do you access the RAM location specified by the contents of the register? If so, how do you overcome the "chicken-and-egg" problem of "you cannot load the value from memory until you have the memory address loaded from memory"?
It actually raises more questions than it answers, though
INC simply works by carrying in to the adder...
Here's the catch with this computer... it does not have RAM. Now before you ask, this is due to the fact that I just could not think of any general purpose memory usage that would require RAM. It's a bit tricky to implement and bus, and I'm not going to lie and say I'm a master. I understand the concepts of a computer, as I think I've demonstrated, all except for the true definition of RAM. On ORE, RAM is more of a bonus than a requirement within MC computers as, programmatically, it's more practical to use GPRs. If it turns out, as I do the Let's Program series, that I need more memory, I'll just make 16 GPRs, make the arguments 4 bits, and be done with the thing.
JMP condition codes (I should really put this stuff in the "instruction set" section):
000 - unconditional
001 - carry out
010 - shift underflow
011 - shift overflow
100 - ALU A == B
101 - ALU A > B
110 - ALU B > A
111 - ALU A != B
... I just don't need that IS space, and it's always there for me if issues such as the lack of GPRs come up.
Also, since I anticipate you asking, it will be clocked @ ~13 ticks, with a specific manager for the ALU command to allow an extra 6 ticks due to the act that the ALU command is far slower than all others.
Every single command is now bussed. All the memory management, all that fancy stuff, all ready. Release (full, video release) will happen Saturday... at which point I will also begin my programming series for it on YouTube!
Rollback Post to RevisionRollBack
If the world is square, then it would indeed be flat.
Check out
for a survival let's play, CTM, redstone, and maps!
So, a while back, I posted a GPU project I was working on. This thing was fairly fancy... insanely big and slow, though. Neither of those reasons was the reason I quit working on it. The real reason was a certain black, brown and green thing known only as the piston. These buggers make timing near impossible, and so I started from the drawing board again... but this time with a full-out computer.This computer doesn't use a single p*ston (other than the monitor's screen, which is 100% timing-free), in it's architecture. If you want to learn a bit more, then read down. If you just want to see all the redstone... scroll to the bottom. Also, don't forget to check out my YouTube, IceAndMC, where I will be uploading a Let's Program series on the finished computer in which we code addition programs all the way to full-out video games... ception
-------ARCHITECTURE INFO-------
All computers start with an ALU (Arithmetic Logic Unit). Most general ALUs use an instacarry piston-based adder, but the Ice 100 uses a specific algorithm known as Carry Look Everywhere, a fast adder that uses no pistons! There are many youtube videos about this type of adder, go look some up if you want to learn a bit more, especially about their interesting diagonal shape. With that said, let's move on a bit.Next, we have the registers and general purpose registers. When I program the computer, these will be used as RAM, but the definition of RAM is a bit murky and people on ORE get mad when I call it RAM. Anyways, these use repeater locks as their method of storing information... generally very simple. Two registers go to the ALU inputs, two go to the computer's output, and four go to the screen inputs. The general purpose registers lead back onto the main bus.Finally, the screen. This is unfinished at the time of writing, but here you go. The screen is 16x16, which means it only takes 4 bit inputs out of the computer's 8, only using half of its registers. It implements conditional "fill" hardware, which allows you to draw large rectangles with ease! It also uses an inverted white-wool piston screen, probably the most visible screen out there.More nerdiness to come in this section as the build continues <3
-------VIDEOS AND SCREENSHOTS------
A channel update which showcases the computer (you don't have to watch the rest
Screenshot detailing all the parts with highlightingScreen capabilities Control room overviewInside the redstone (ALU to be specific)Bussing and non-timing stuff is DONE!The ROM (or memory used for static computations):The program memory, where it all happens!
-------INSTRUCTION SET------
Everything that makes this computer what it is lies within this spoiler. Explanation will be out once the computer is finished.
0000 - JMP to jump code/ARG2 bit with condition ARG1
0001 - RAM->REG ARG1->ARG2
0010 - CLR RAM ARG1
0011 - RAM->RAM ARG1->ARG2
0100 - toggle indicator ARG1
0101 - ALU op:ARG1 to RAM ARG2
0110 - get user input and save to RAM ARG2
0111 - WAIT
1000 - save RNG into RAM ARG2
1001 - ROM ARG1->RAM ARG2
1010 - GPU DRAW
1011 - GPU DRAW-FILLX
1100 - GPU DRAW-FILL
1101 - GPU DRAW-FILLY
1110 - GPU CLEAR
1111 - END
-------DOWNLOADS-------
Take this for le download! https://www.dropbox....Ice-100 CPU.zip
Check out
Check out
Check out
[emote]Mind_Explosion[/emote]
for you!!!!
Check out
Eviloeraay!
That's the one main idea of this entire computer, thanks for noticing it
It's right there in the initial post under "Instruction Set".
Check out
Check out
Correction:
How many bits long are the instructions? How many registers? What ALU ops are exposed? What are the arguments to the draw* commands? How much memory is addressable?
8-bit answers some of these, but not all. (Especially as many 8-bit instruction sets have an instruction length of >8 bits)
Ahh, I catch your drift now. Sorry for my earlier misunderstanding.
Instructions are 16 bits long. This includes a 4-bit instruction, two 3-bit command arguments, and a 6-bit code specific to the 0000 JMP instruction. (There are 64 available instructions, thus decoded with 6-bit).
As for ALU ops, they are controlled via a 3-bit argument, which means I can only expose 8. (I'm not the kind of person to hate command 0, haha). List:
ADD
SUB A-B
SHR
INC
XOR
XNOR
AND
OR
It's essentially enough in that respect... I hope
8 addressable non-general purpose registers:
000 - ALU A
001 - ALU B
010 - OUT0
011 - OUT1
100 - GPU X0
101 - GPU Y0
110 - GPU X1
111 - GPU Y1
And that pretty much explains the GPU draw commands as well, no arguments but based solely on the content of the registers, just like RL interrupts (theoretically speaking).
Finally, 8 addressable GPRs and 8 ROM addresses. Hope I answered all your questions there
Check out
...Sort of?
It actually raises more questions than it answers, though:
INC simply works by carrying in to the adder...
Here's the catch with this computer... it does not have RAM. Now before you ask, this is due to the fact that I just could not think of any general purpose memory usage that would require RAM. It's a bit tricky to implement and bus, and I'm not going to lie and say I'm a master. I understand the concepts of a computer, as I think I've demonstrated, all except for the true definition of RAM. On ORE, RAM is more of a bonus than a requirement within MC computers as, programmatically, it's more practical to use GPRs. If it turns out, as I do the Let's Program series, that I need more memory, I'll just make 16 GPRs, make the arguments 4 bits, and be done with the thing.
JMP condition codes (I should really put this stuff in the "instruction set" section):
000 - unconditional
001 - carry out
010 - shift underflow
011 - shift overflow
100 - ALU A == B
101 - ALU A > B
110 - ALU B > A
111 - ALU A != B
... I just don't need that IS space, and it's always there for me if issues such as the lack of GPRs come up.
Also, since I anticipate you asking, it will be clocked @ ~13 ticks, with a specific manager for the ALU command to allow an extra 6 ticks due to the act that the ALU command is far slower than all others.
Thanks! It's really not as hard as me and Wolfling are making it out to be, it's a learning curve like anything else
Check out
Every single command is now bussed. All the memory management, all that fancy stuff, all ready. Release (full, video release) will happen Saturday... at which point I will also begin my programming series for it on YouTube!
Check out
Check out
Check out
Cant wait
Check out