I just wanted to show you the 16bit computer I've been building with redpower over the pas few months.
I know redpower is regarded as cheating by most, but I hope that some might still find it interesting - it was a pain in the butt to build regardless of redpower :smile.gif:
Just to get the numbers out of the way: It is a fully functional computer with 10 instructions, 32 bytes of ram, 64 bytes of rom, user input, numerical output and (of course) the 16x16 pixel graphics display.
In total this took around two weeks to build. I started back in december but had it collecting dust until this week when I finally got around to finish it.
The CPU is sort of inspired by the MIPS architecture - mainly the fact that most instructions allow you to specify the target register, instead of the destination register being fixed to one of the source registers or to a special register like the accumulator, for example.
The command set has a few quirks, mainly that the program counter is in fact just a normal register that you can read from and write to, just as you would with any other register. This means that there aren't any jump instructions, since you can write to the program counter with any of the move instructions (or even the arithmetic instructions).
Since conditional branches are required for most programs, these are of course implemented. But instead of just having conditional jumps, all of the instructions are augmented with a condition code, allowing their conditional execution (I had bits left over in the instruction encoding, so I thought that would be pretty neat).
Have a few pictures:
I have a short video with a quick tour and showing the thing in action:
In theory I could run pong on this (and I originally planned to do that), but I would have had to build a lot more ROM and the program would be extremely slow, so I dropped the idea and went for a DVD-screensaver-ish program instead.
If anyone is interested, I'll try to upload the map somewhere so you can take a look. Note that I'm still using 1.7.3, since that was the only version I could get redpower to run on back then.
I'd be happy to answer any questions you might have.
Cheers!
Now, I know that CPUs have been done quite a few times in Minecraft, so this probably won't strike you as mindblowing, but I still had a fun time making it and I thought I'd share it with you guys.
So over the last three days, I've been building an 8-bit CPU in Minecraft using the magnificent Redpower mod.
It has 4 8-bit registers, 20 bytes of program ROM, an adder/subtracter unit and 4 instructions. Have a few screenshots before I go on with my rambling:
Click the images for larger resolutions.
Top left: ALU/multiplexers
Top middle: Instruction decoder/control unit/incrementer (for the program counter)
Bottom Middle: Register file/BUS
Middle right: Register address decoder
Top right: ROM
Closer look at the ALU and multiplexers
Closer look at the ROM.
So of course, the CPU has a lot of limitations - with no RAM to speak of and only four registers available (or three, actually, since one of them is reserved for the program counter), it's a bit hard to do something useful for it.
But still, I was able to write a program on it calculating the Fibonacci numbers, so I guess that's something.
To give a small overview, the instructions it currently supports are:
Add dest, regA, regB: Set the contents of the register at 'dest' to the result of 'regA' + 'regB'
Sub dest, regA, regB: Set the contents of the register at 'dest' to the result of 'regA' - 'regB'
Mov dest, reg : Copy the contents of register 'reg' into the register at 'dest'
MovImmediate dest, Immediate: Copy the 4-bit immediate value (constant value coded into the instruction) into the register at 'dest'
'dest', 'regA' and 'regB' are two bit addresses of registers, so you are free to combine any register in any instruction. You could even add the contents of a register to itself and store the result in the same register, for example.
All registers (including the program counter) are both readable and writable. This is to bypass the limitation of not having jump instructions - just add/subtract/move a value into the program counter register and you're good.
The control unit will increment the program counter at the end of the cycle, but only if you didn't write to the program counter. This means basically: If you executed a regular instruction, the next instruction is fetched and executed. But if you wrote something to the program counter (i.e. you jumped), the contents of the program counter are left as is.
It runs at 1/8 Hz right now to ensure nothing breaks, but it could probably go faster than that. I just have to check where the critical code path is and calculate how many ticks it needs to execute to come up with a more accurate (and faster) clock.
I'll probably work on this thing over the next few weeks if I find the time. Extending it to 16-bit is definitely on the todo list, since pretty much everything is in place for 16-bit support - I just have to duplicate the registers and put down a few more wires. Adding more registers is also something I had in mind, as well as some sort of I/O interface, since right now I have to hover above the registers to see what value is stored inside them.
I'll upload the map once I cleaned up the whole thing. Until then, feel free to post your feedback/questions.
Just a small project I've been working on over the last three days.
It's a binary counter going from 0 to 9 (and restarting at 0) while displaying the current number on a seven segment display. The focus of this thing was to keep the design neat and compact, while getting as much speed out of it as possible.
It took a LOT of patience to get this to work :biggrin.gif: There was so little space that the redstone constantly connected with things it shouldn't, and halfway through completion I noticed I had to fit in repeaters at the most inconvenient places. Anyways, it was worth it - the whole thing is hooked up to a 4-clock corresponding to 0.4 seconds per cycle (I couldn't get it faster without the torches burning out), there's no flickering on the display and it looks quite neat from above too.
Just to compare, here's the previous version of the counter, which was not only a whole lot larger, but also really really slow (about 4 seconds for one cycle): Screenshot 1 Screenshot 2 Screenshot 3
After finishing the second version I'm already working on a newer one which is making use of a shift register, which should again make the whole circuit a lot smaller and faster. That should allow me to hook up several digits next to each other and make some sort of digital clock... in Minecraft.
If anyone is interested in the map file, just tell me - uploading shouldn't be a problem.
I'm a huge fan of the lighting in Minecraft (is there any information on how it works? It resembles radiosity, but it's way faster than that), but it always bothered me that it's lacking and ambient occlusion term.
For those that don't know what it is, ambient occlusion (short AO) is a technique to make lighting more realistic by using the fact that surfaces get darker the closer they are to other surfaces. It is commonly used in todays games because it helps improving the visual quality a lot. Just do a quick Google search to see what AO looks like.
The main problem with AO is that it is very expensive to calculate, especially in real-time, so it is normally not used on anything other than static geometry (let's forget about SSAO for now), making it unusable for Minecraft where changing the level is the whole point of the game. However, the special geometry of Minecraft leaves a lot of room for optimizations; the fact that we only have to deal with grid-aligned cubes makes it a lot easier.
To demonstrate, I wrote a quick prototype to test it out and it actually is possible to precompute the ambient occlusion terms for all possible cube constellations and then apply it in real-time.
The precomputed ambient occlusion texture looks like this:
Applying AO in the game takes no toll on the performance at all. It is merely a texture multiplied on the color texture. If a block is removed/placed, applying the changes in AO are as easy as changing the UV-coordinates of the 8 adjacent blocks.
I'd absolutely love to see advanced lighting in Minecraft, but those are just my two cents. I'd like to hear your opinion on this.
6
I just wanted to show you the 16bit computer I've been building with redpower over the pas few months.
I know redpower is regarded as cheating by most, but I hope that some might still find it interesting - it was a pain in the butt to build regardless of redpower :smile.gif:
Just to get the numbers out of the way: It is a fully functional computer with 10 instructions, 32 bytes of ram, 64 bytes of rom, user input, numerical output and (of course) the 16x16 pixel graphics display.
In total this took around two weeks to build. I started back in december but had it collecting dust until this week when I finally got around to finish it.
The CPU is sort of inspired by the MIPS architecture - mainly the fact that most instructions allow you to specify the target register, instead of the destination register being fixed to one of the source registers or to a special register like the accumulator, for example.
The command set has a few quirks, mainly that the program counter is in fact just a normal register that you can read from and write to, just as you would with any other register. This means that there aren't any jump instructions, since you can write to the program counter with any of the move instructions (or even the arithmetic instructions).
Since conditional branches are required for most programs, these are of course implemented. But instead of just having conditional jumps, all of the instructions are augmented with a condition code, allowing their conditional execution (I had bits left over in the instruction encoding, so I thought that would be pretty neat).
Have a few pictures:
I have a short video with a quick tour and showing the thing in action:
In theory I could run pong on this (and I originally planned to do that), but I would have had to build a lot more ROM and the program would be extremely slow, so I dropped the idea and went for a DVD-screensaver-ish program instead.
If anyone is interested, I'll try to upload the map somewhere so you can take a look. Note that I'm still using 1.7.3, since that was the only version I could get redpower to run on back then.
I'd be happy to answer any questions you might have.
Cheers!
2
Now, I know that CPUs have been done quite a few times in Minecraft, so this probably won't strike you as mindblowing, but I still had a fun time making it and I thought I'd share it with you guys.
So over the last three days, I've been building an 8-bit CPU in Minecraft using the magnificent Redpower mod.
It has 4 8-bit registers, 20 bytes of program ROM, an adder/subtracter unit and 4 instructions. Have a few screenshots before I go on with my rambling:
Click the images for larger resolutions.
Top left: ALU/multiplexers
Top middle: Instruction decoder/control unit/incrementer (for the program counter)
Bottom Middle: Register file/BUS
Middle right: Register address decoder
Top right: ROM
Closer look at the ALU and multiplexers
Closer look at the ROM.
So of course, the CPU has a lot of limitations - with no RAM to speak of and only four registers available (or three, actually, since one of them is reserved for the program counter), it's a bit hard to do something useful for it.
But still, I was able to write a program on it calculating the Fibonacci numbers, so I guess that's something.
To give a small overview, the instructions it currently supports are:
Add dest, regA, regB: Set the contents of the register at 'dest' to the result of 'regA' + 'regB'
Sub dest, regA, regB: Set the contents of the register at 'dest' to the result of 'regA' - 'regB'
Mov dest, reg : Copy the contents of register 'reg' into the register at 'dest'
MovImmediate dest, Immediate: Copy the 4-bit immediate value (constant value coded into the instruction) into the register at 'dest'
'dest', 'regA' and 'regB' are two bit addresses of registers, so you are free to combine any register in any instruction. You could even add the contents of a register to itself and store the result in the same register, for example.
All registers (including the program counter) are both readable and writable. This is to bypass the limitation of not having jump instructions - just add/subtract/move a value into the program counter register and you're good.
The control unit will increment the program counter at the end of the cycle, but only if you didn't write to the program counter. This means basically: If you executed a regular instruction, the next instruction is fetched and executed. But if you wrote something to the program counter (i.e. you jumped), the contents of the program counter are left as is.
It runs at 1/8 Hz right now to ensure nothing breaks, but it could probably go faster than that. I just have to check where the critical code path is and calculate how many ticks it needs to execute to come up with a more accurate (and faster) clock.
I'll probably work on this thing over the next few weeks if I find the time. Extending it to 16-bit is definitely on the todo list, since pretty much everything is in place for 16-bit support - I just have to duplicate the registers and put down a few more wires. Adding more registers is also something I had in mind, as well as some sort of I/O interface, since right now I have to hover above the registers to see what value is stored inside them.
I'll upload the map once I cleaned up the whole thing. Until then, feel free to post your feedback/questions.
1
It's a binary counter going from 0 to 9 (and restarting at 0) while displaying the current number on a seven segment display. The focus of this thing was to keep the design neat and compact, while getting as much speed out of it as possible.
It took a LOT of patience to get this to work :biggrin.gif: There was so little space that the redstone constantly connected with things it shouldn't, and halfway through completion I noticed I had to fit in repeaters at the most inconvenient places. Anyways, it was worth it - the whole thing is hooked up to a 4-clock corresponding to 0.4 seconds per cycle (I couldn't get it faster without the torches burning out), there's no flickering on the display and it looks quite neat from above too.
Have a few screenshots:
Display:
Lower left: Decimal-to-segment-decoder, right: binary-to-decimal-decoder, upper left: T-flipflop counter with lookahead-carry.
Closer look at the flipflops:
Just to compare, here's the previous version of the counter, which was not only a whole lot larger, but also really really slow (about 4 seconds for one cycle):
Screenshot 1
Screenshot 2
Screenshot 3
After finishing the second version I'm already working on a newer one which is making use of a shift register, which should again make the whole circuit a lot smaller and faster. That should allow me to hook up several digits next to each other and make some sort of digital clock... in Minecraft.
If anyone is interested in the map file, just tell me - uploading shouldn't be a problem.
2
I'm a huge fan of the lighting in Minecraft (is there any information on how it works? It resembles radiosity, but it's way faster than that), but it always bothered me that it's lacking and ambient occlusion term.
For those that don't know what it is, ambient occlusion (short AO) is a technique to make lighting more realistic by using the fact that surfaces get darker the closer they are to other surfaces. It is commonly used in todays games because it helps improving the visual quality a lot. Just do a quick Google search to see what AO looks like.
The main problem with AO is that it is very expensive to calculate, especially in real-time, so it is normally not used on anything other than static geometry (let's forget about SSAO for now), making it unusable for Minecraft where changing the level is the whole point of the game. However, the special geometry of Minecraft leaves a lot of room for optimizations; the fact that we only have to deal with grid-aligned cubes makes it a lot easier.
To demonstrate, I wrote a quick prototype to test it out and it actually is possible to precompute the ambient occlusion terms for all possible cube constellations and then apply it in real-time.
Here, have a few images to show what I mean:
Close-up view
Complex scene with AO
The precomputed ambient occlusion texture looks like this:
Applying AO in the game takes no toll on the performance at all. It is merely a texture multiplied on the color texture. If a block is removed/placed, applying the changes in AO are as easy as changing the UV-coordinates of the 8 adjacent blocks.
I'd absolutely love to see advanced lighting in Minecraft, but those are just my two cents. I'd like to hear your opinion on this.
Cheers,
Noobody