After months of development (though most of the time I wasn't actually working on it), it's finally ready for its first public release! The commandore 32 is done!
Comes with paint, pre-installed, and the following that you can upload yourself:
Bar graph (like the classic program for the Redgame 1)
Fibonacci sequence
number renderer
Guess the number game
tic tac toe (w/o AI and win detection, sorry)
more coming soon!
User made programs:
Text Drawer, by fez5577. draws text on screen. For a list of words you can print, click here.
Artist, by fez5577. Draws random shapes on the screen, in random colours...randomly. Kinda fun to watch!
Pong, by mmdangg2. Classic 1 player pong with lives, runs terribly slow but works! (faster version possible in future)
1.1.1:
made blockloader work with latest snapshot (14w24 broke my uploading system)
uploading now more reliable (kinda)
1.1.0:
[MAJOR] Added array support!
cleaned up world a little, some more signs and unneeded stuff removed
added some stuff that will be needed in the upcoming peripheral protocol, but not yet functional
removed some uneeded chunks with MCEdit, world file is now smaller
cleared out inventory and reset initial position and spawnpoint
1.0.0:
initial public release
SDK changelog:
1.1.2:
added drag and drop file selection to SDK (an alternative to the choose file window)
Removed uneeded array and variable in paint program
Moved paint program to "uncommented" folder
Fixed a pretty serious typo about how loops worked, getting "true" and "false" confused!
Manual PDF now compressed slightly. Doesn't make a huge difference, but y'know.
1.1.1:
[MAJOR]fixed uploading in latest snapshots
starting directory when clicking "choose file" is now the directory the compiler is in, instead of your documents folder
added "cmds to clipboard" option, to allow for much faster uploading if you use a server
documented above feature in manual
fixed possible bug with optimising arrays
1.1.0:
[MAJOR] fixed bug related to the assembly linker incorrectly replacing some GOTO/branch flags
[MAJOR] array support! yay!
fixed too many tokens error when the first argument of a function is a negative number, e.g. print(-1);
fixed spelling mistakes in changelog
added documentation for arrays
added rem1() and rem2() to documentation (low level version of remainder functions, AKA modulas)
1.0.1:
compiler:
[MAJOR] fixed serious bug in optimizer that would remove lines updating a variable to another variable it's been set to before in ALL conditions, even when the parent value has been changed.
language reference:
added page numbers
finished an unfinished sentence about the GPU co-ordinate system, and under functions list
added details for general purpose framebuffer, and an example on how to do collision detection.
refreshed table of contents
updated assembly instructions reference to latest version, included version was quite outdated
included changelog
1.0.0:
fixed some spelling mistakes
fixed an issue where trying to upload faulty code caused the program to jam up and not be able to upload anything until it was restarted
other general improvements to prepare it for release
beta:
initial public release
What is the commandore 32?
The Commandore 32 is a brand new type of redstone computer. It's not one of those fake "computers" that have been popping up recently that run paint and have a keyboard and "pretends" to run programs, when it's all hardwired. No, this is still a real computer, like the one you're reading this on, but much more basic.
This computer is much like the traditional redstone computers, but uses command blocks instead. Using fancy tricks and custom command block generation programs, this computer has much more power than any computer you can build with just survival redstone.
In fact, this may very well be the most powerful computer ever built in vanilla Minecraft. And my measure of power isn't just based on the fact that this has 32 bit signed integer math, or hardware multiplication and division support, or that it has a function stack complete with hardware memory allocation. It's probably the most powerful because this computer has a full compiler.
What? A compiler?
Yes, a full high level compiler, complete with tokeniser, assembler and even an optimization stage. This is exactly the same thing used to compile high level languages like C++ and Java, but again, on a much smaller scale (this being my first high level compiler, there are quite a few limitations).
Writing programs for this computer is almost as easy as writing programs for Computercraft computers. Writing programs for vanilla Minecraft is now easy!
Feature list:
GPU:
32x32 pixel
16 colour (all colours of Minecraft wool)
2:1 block to pixel ratio
6KB VRAM*
ANDEX based technology
Double buffered
Frame comparison (for basic collision detection)
Supports overwriting other shapes with any colour, including black to clear
*(4 bit colour 32*32 pixels/2 to get bytes=2KB per frame buffer. Has 3 (final, working, and general purpose) therefore 2*3=6KB)
CPU:
2 stage pipeline (3 stage for many instructions)
Dynamic clock
Hardware local memory controller
Isolated function stack (10 units deep)
Dual core (2 ALUs at least, not capable of simultaneous operation)
32 bit, signed integer math including multiplication and division
Simple instruction set, compared to that of the redgames
Common functions available as single instructions (e.g. increment variable, i+= 5)
Images:
Tic Tac Toe:
Paint, and my amazing abstract art:
Cool looking early rendering tests:
Made a cool program with the SDK?
Please, post it in this forum topic! I'd love to see it, and even put it up for download on the main page if you want!
Having difficulty getting it working or want to learn how to make programs?
Watch the tutorial series here (youtube playlist): Commandore 32 tutorial series
Hellow and great good luck! I have a lot of questions. My biggest one is how are you going to make bit wire functions and the GPU? I am building a graphing processing unit similar to andex (I think I spelt it correctly) exept with comand blocks for coler (no score board). It requires bit wise ops for the filling (if you know what Ime talking about). Ps FIRST POST ON THIS EPIC PROJECT OF YOURS.
My biggest one is how are you going to make bit wire functions and the GPU?
Assuming you mean bitwise math: It probably won't have that, unfortunately. This computer is different in that it doesn't actually work in binary at all. In a very low level sense it does, but at no point in its operation are numbers represented by ones and zeros. There's no real need either, shift left/right is often done to avoid division and multiplication, but multiplication and division is as fast as addition and subtraction on this computer, so there's no need. Bitwise math can be simulated to an extent with the basic math functions.
As for the GPU:
My documents currently plan for me to use a larger version of the Redgame 3 screen system, with the binary decoders replaced with command block lookups and some wireless tricks for increased speed and better wiring. It will have a proper frame buffer and probably colours as well. Screen size to pixel ratio 2:1 (2x2 square of blocks per pixel) instead of 1:1 to keep logic simple.
Assuming you mean bitwise math: It probably won't have that, unfortunately. This computer is different in that it doesn't actually work in binary at all. In a very low level sense it does, but at no point in its operation are numbers represented by ones and zeros. There's no real need either, shift left/right is often done to avoid division and multiplication, but multiplication and division is as fast as addition and subtraction on this computer, so there's no need. Bitwise math can be simulated to an extent with the basic math functions.
As for the GPU:
My documents currently plan for me to use a larger version of the Redgame 3 screen system, with the binary decoders replaced with command block lookups and some wireless tricks for increased speed and better wiring. It will have a proper frame buffer and probably colours as well. Screen size to pixel ratio 2:1 (2x2 square of blocks per pixel) instead of 1:1 to keep logic simple.
Good luck with your own GPU!
cool. don't really understand why you need a frame buffer thou.
Nice! What GPU will it have - piston, fill/setblock or in-chat symbols?
I'm going to use a unique 4 stage system that I've been referring to in my design notes as the "frame factory".
Stage 1 is a normal piston display, hooked up directly to a standard ANDEX tower, with no memory.
Stage 2 copies the blocks pushed forward by the pistons in stage 1 to a seperate area, and replaces the blocks with a different colour, depending on what was chosen.
Stage 3 copies the now coloured blocks into a frame buffer, where the next frame is built.
Stage 4 is what the user sees, and once a frame is finished, stage 4 is cleared and set to the contents of stage 3.
cool. don't really understand why you need a frame buffer thou.
A proper frame buffer (double buffered) is needed to make things look a whole lot better. If you have a game, you usually clear the entire buffer and then place all the objects the game uses on the buffer. Once all objects are on the buffer, you display the buffer on the screen, clear the buffer and start work on the next frame. If you didn't have this buffer, the user would be watching the display get cleared and re-drawn to, with a finished image only being displayed for a very small amount of time before being cleared.
I'm busy with way too many projects right now, sorry. There's a whole lot of requirements there, too! I might be able to get a top down one working, but not with that much complexity.
Assuming you mean bitwise math: It probably won't have that, unfortunately. This computer is different in that it doesn't actually work in binary at all. In a very low level sense it does, but at no point in its operation are numbers represented by ones and zeros. There's no real need either, shift left/right is often done to avoid division and multiplication, but multiplication and division is as fast as addition and subtraction on this computer, so there's no need. Bitwise math can be simulated to an extent with the basic math functions.
As for the GPU:
My documents currently plan for me to use a larger version of the Redgame 3 screen system, with the binary decoders replaced with command block lookups and some wireless tricks for increased speed and better wiring. It will have a proper frame buffer and probably colours as well. Screen size to pixel ratio 2:1 (2x2 square of blocks per pixel) instead of 1:1 to keep logic simple.
Good luck with your own GPU!
Can't you pull values out of the scoreboard into buses using the %, value%2^n. Then you could implement the binary operations by adding the values back up with 2^n*(redstone > 0). That should work if I am not mistaken, and with some know-how it should only take a few ticks.
Can't you pull values out of the scoreboard into buses using the %, value%2^n. Then you could implement the binary operations by adding the values back up with 2^n*(redstone > 0). That should work if I am not mistaken, and with some know-how it should only take a few ticks.
I could, but that would ironically take longer than arithmetic. I could add it later, There's literally millions of unused instructions available (since the instruction ID, like everything, is 32 bits), but it's not on my priorities.
I could, but that would ironically take longer than arithmetic. I could add it later, There's literally millions of unused instructions available (since the instruction ID, like everything, is 32 bits), but it's not on my priorities.
I know it would be slower, but for some opps it would be nice to have. I understand that it is low on the priority list.
I know it would be slower, but for some opps it would be nice to have. I understand that it is low on the priority list.
I'll be sure to add that if I'm bored and don't know what to implement next
Anyway, update time! wow, it's been over a year since I last did this I believe. I've built the main components of the GPU, and 3 of the 4 frame factory stages! The 4th one (final frame buffer) isn't done yet, but it's dead simple and would only take a single command block.
The display is MASSIVE, 64x64 blocks big, 32x32 pixels and 4 bit colour, probably making it one of the most "HD" displays of its class. Here's an image of the first stage rendering a 31x31 square in the center of the screen:
Hard to see the square, I know. It's not supossed to be easy to see, that's what the next stages are for
After implementing stages 2 and 3, here's the first successful colour test:
From another angle, where you can clearly see the different stages:
It supports all 16 wool colours, and even though I expected this result, I was still impressed by how awesome a multi coloured display looks in minecraft.
Here's the current control logic:
The big decoder on the left is for all the wool, and the big repeater chain is for waiting on the 1D line drawer systems. I'll optimise it later. Also, this thing is laggy. Very laggy! Luckily, I was expecting this, and the design allows the CPU to continue working while the GPU does it's thing, and can see when it's done through a status flag. So it can prepare the next pixel/box/whatever while the GPU is still busy!
The CPU can't actually control the GPU yet, though. Right now it's me manually placing redstone blocks. The only thing programs can do at this point is change the coordinates. Of course, I'll be connecting this to the CPU next!
EDIT:
forgot to include a side view:
The 2 near identical things on the bottom left is the 1D line drawers, one for X and one for Y. The top platform is for control logic.
el I regally did not see any need of a frame buffer because I program on my ti 84. TI-Basic is slow and does not support frame buffers so I have evolved to making graphics not use frame buffer.
So instead of clearing EVERY THING and painting the new sprites on, I only change the thing that has moved
(Ex: instead of reprinting the whole screen when say a curser is moved, I only paint the curser in the new position and fill the old position with what is supposed to be there.
The commands for my GPU are (just so you get a feel of the arc.)
Set point 1 (x1,y2)
//set first cordenet
Color (int )
//set color
On (x2,y2)
Off (x2,y2)
Change (x2,y2)
//fill area from (point 1) to (x2,y2) and do the required operation (on off change)
Test(x,y) //get color of x,y
Boolean pixleMode //if true x1 and y1 are replaced by x2 and y2, there for drawing a single pixel at (x2,y2)
EDiT: I have found a command block computer that calculates some useless thingamajigers and draws it on some screen. Here is the vid. Check it out!
Also can I use the "factory" method in my GPU? I will give you proper credit.
el I regally did not see any need of a frame buffer because I program on my ti 84. TI-Basic is slow and does not support frame buffers so I have evolved to making graphics not use frame buffer.
So instead of clearing EVERY THING and painting the new sprites on, I only change the thing that has moved
(Ex: instead of reprinting the whole screen when say a curser is moved, I only paint the curser in the new position and fill the old position with what is supposed to be there.
The commands for my GPU are (just so you get a feel of the arc.)
Set point 1 (x1,y2)
//set first cordenet
Color (int )
//set color
On (x2,y2)
Off (x2,y2)
Change (x2,y2)
//fill area from (point 1) to (x2,y2) and do the required operation (on off change)
Test(x,y) //get color of x,y
Boolean pixleMode //if true x1 and y1 are replaced by x2 and y2, there for drawing a single pixel at (x2,y2)
EDiT: I have found a command block computer that calculates some useless thingamajigers and draws it on some screen. Here is the link. Check it out!
Also can I use the "factory" method in my GPU? I will give you proper credit.
There is a frame buffer on the 84, just can not get to it without asm or a basic library.
I'll be sure to add that if I'm bored and don't know what to implement next
Anyway, update time! wow, it's been over a year since I last did this I believe. I've built the main components of the GPU, and 3 of the 4 frame factory stages! The 4th one (final frame buffer) isn't done yet, but it's dead simple and would only take a single command block.
The display is MASSIVE, 64x64 blocks big, 32x32 pixels and 4 bit colour, probably making it one of the most "HD" displays of its class. Here's an image of the first stage rendering a 31x31 square in the center of the screen:
Hard to see the square, I know. It's not supossed to be easy to see, that's what the next stages are for
After implementing stages 2 and 3, here's the first successful colour test:
From another angle, where you can clearly see the different stages:
It supports all 16 wool colours, and even though I expected this result, I was still impressed by how awesome a multi coloured display looks in minecraft.
Here's the current control logic:
The big decoder on the left is for all the wool, and the big repeater chain is for waiting on the 1D line drawer systems. I'll optimise it later. Also, this thing is laggy. Very laggy! Luckily, I was expecting this, and the design allows the CPU to continue working while the GPU does it's thing, and can see when it's done through a status flag. So it can prepare the next pixel/box/whatever while the GPU is still busy!
The CPU can't actually control the GPU yet, though. Right now it's me manually placing redstone blocks. The only thing programs can do at this point is change the coordinates. Of course, I'll be connecting this to the CPU next!
EDIT:
forgot to include a side view:
The 2 near identical things on the bottom left is the 1D line drawers, one for X and one for Y. The top platform is for control logic.
If you want I could make the binary operations and send them to you in a schematic, I really want them in the RG4.
Sorry, can not spell well, so I always misspell spoiler. (Unless it is their already like now.)
That and I forgot that you had one when I posted before.
GPU is done and wired up to the CPU! I've created a little test program to demonstrate:
If anyone's interested, all 3 shapes took different amounts of time to render. The hollow blue shape taking the longest (renders in 2 steps), the green filled rectangle taking second longest and the red dots being the fastest (bypasses the 1D line drawers, avoiding their delay)
If you want to plot a single pixel, all you have to do is set one set of co-ordinates (example x2 and y2) and set the other to (0;0). That's why coordinates start at 1 instead of 0.
You can use /scoreboard players test <player> <objective> <min> [max] to see if a variable is within a certain range. Using two command blocks you can replace those GIANT 1D line drawers. That's what Ime doing :). Hopfully my GPU will be done soon so I can post stuff about it. (Of course you will know most of what's going on)
You can use /scoreboard players test <player> <objective> <min> [max] to see if a variable is within a certain range. Using two command blocks you can replace those GIANT 1D line drawers. That's what Ime doing . Hopfully my GPU will be done soon so I can post stuff about it. (Of course you will know most of what's going on)
I was planning on using a different method involving replacing the repeater chain with filled redstone blocks, but your suggestion gave me an alternative idea. Thanks!
The poll seems to be doing nicely. So far bottom left origin is winning, which is great, since bottom left is already the origin so less work for me
Of course, moving the origin won't be too difficult as I have fancy custom tools to do most of it for me, so I won't mind top left origin.
You guys all want the control panel raised so it's in line with the center of the screen. This does mean that standing at the far end of the control panel (away from the screen) you won't be able to see all of the display. I hope you guys are OK with this. I'll try make something practical...
I'm now implementing the function stack and local memory system. The function stack is already working, you can call functions and functions within functions, and it will return to where they were called from. You can even pass arguments, and as many as you want! Limited to RAM and program memory size, of course.
I had a last minute good idea about how to access local memory: using negative values. If you look on the big spreadsheet of planned functions on the original post (quite outdated now), you'll see a few copy local->main and main-> local functions, and local/main versions of set. This is all being merged to one copy and one set function, and local variables can now be saved to and loaded from in any function!
It's quite simple. negative numbers refer to local variables while positive ones refer to global ones. so 10 is global variable 10 (EEPROM 1, I believe) while -2 is local variable 2, local to the function running it. You can save and load to and from both 10 and -2 in all functions and the logic will take care of it.
However, the extra delay caused by the local variable checking and correcting logic (it has to convert it to a "global" address in real memory), though the delay is not much, is causing certain functions to act weirdly when using local variables instead of global ones. Particularly when both local AND global variables are involved in the same function. I'm having some problems debugging this, as it's pretty tricky stuff, but I'm slowly making progress.
In my frustration to debugging the above, I've started working on a compiler. It's written entirely in Java, so it's multiplatform. And it's a proper compiler, with a custom tokenizer and lexer written from scratch, proper error detection with line references, and it generates assembly code which is then assembled by my assembler program, so you can further optimise your program when you finnished it by hand.
Here's what the languages syntax looks like:
globalVar1
globalVar2
anotherGlobalVar
function myFunction:
localVar1
moreLocalVars
andSoForth
{
localVar1=5/*multi line comments!*/
globalVar2=moreLocalVars+20;//semicolons optional (for now, might change)
print(anotherGlobalVar)
}
function main:
{
myFunction(5,3);
}
It's pretty different from normal languages, so let me explain some stuff:
all text at the beginning is global variables, that can be accessed by all the functions.
as soon as "function functionName:" appears, lines after that are local variables acessible only to that function
Finally, the currly braces { } contain the function's code. You cannot define more variables in these braces.
This continues for all the functions.
Now, you may notice that myFunction is called and given 2 arguments, but it doesn't look like myFunction takes in arguments. how does this work? Well, all arguments given are stored in the first few local variables. So, in the case of "myFunction(5,3);", "localVar1" is set to 5 and "moreLocalVars" is set to 3. I might add something that allows you to define how many arguments the function needs maximum or minimum and throws errors if you go over those numbers later. Then functions would look like "function functionName 2:" or something like that to optionally allow you to specify how many arguments are needed.
Yes, it's not nearly as high level as modern languages like C++ , but it's better than assembly, right? Also worth noting nested functions(for example "myFunc(add(5,20),10)" wouldn't work) and multiple operation math ("x=6+a*b" would need to be "x=a*b; x=x+6") won't be supported, though I could add it later.
Also, since I'm making this programming language, I'm also adding "until(condition)" which will do the same as "while(!condition)", except be 20 times more readable. I've never really liked while not things, they're so confusing! I also hate using for loops for some reason (specifically Java for loops), and since you cannot declare variables inside of function code as I already said before, there will be no for loops.
So far, global and local variables are detected and assigned IDs, and basic math can be compiled ("a=5-b", or "x=-20") and it can give errors. Not much, but it's a start. Code's a little messy at the moment, first time writing a proper tokenizer and only recently decided to use Java's Exceptions for syntax errors. But it will be awesome!
Making some great progress there.
Will the compiler be open source?
It is a good idea to use Exception how you are using them, similar "hack" to for(String buffer = in.readLine(); in != null; buffer = in.readLine()). Good work.
Making some great progress there.
Will the compiler be open source?
It is a good idea to use Exception how you are using them, similar "hack" to for(String buffer = in.readLine(); in != null; buffer = in.readLine()). Good work.
Possibly. The code is embarrassingly bad, though.
In other news, the compiler can now compile slightly useful programs! if() and print() have been implemented, though the's no else or !=. And no loops yet. After that, GPU functions and user functions (right now it only compiles the "main" function).
Another limitation is this is a purely sequential compiler, there's no linker. This means you need to define all functions before you use them, like in languages such as lua.
The compiler's almost in a state where I can actually start using it to write programs instead of assembly. It has it's limitations, but it's much better than writing in assembly, and infinitely better than writing in machine code like you have to for most redstone computers.
Comes with paint, pre-installed, and the following that you can upload yourself:
Computer 1.1.1: click here! (direct link)
SDK/compiler 1.1.2: click here! (direct link)
computer changelog:
made blockloader work with latest snapshot (14w24 broke my uploading system)
uploading now more reliable (kinda)
1.1.0:
[MAJOR] Added array support!
cleaned up world a little, some more signs and unneeded stuff removed
added some stuff that will be needed in the upcoming peripheral protocol, but not yet functional
removed some uneeded chunks with MCEdit, world file is now smaller
cleared out inventory and reset initial position and spawnpoint
1.0.0:
initial public release
added drag and drop file selection to SDK (an alternative to the choose file window)
Removed uneeded array and variable in paint program
Moved paint program to "uncommented" folder
Fixed a pretty serious typo about how loops worked, getting "true" and "false" confused!
Manual PDF now compressed slightly. Doesn't make a huge difference, but y'know.
1.1.1:
[MAJOR]fixed uploading in latest snapshots
starting directory when clicking "choose file" is now the directory the compiler is in, instead of your documents folder
added "cmds to clipboard" option, to allow for much faster uploading if you use a server
documented above feature in manual
fixed possible bug with optimising arrays
1.1.0:
[MAJOR] fixed bug related to the assembly linker incorrectly replacing some GOTO/branch flags
[MAJOR] array support! yay!
fixed too many tokens error when the first argument of a function is a negative number, e.g. print(-1);
fixed spelling mistakes in changelog
added documentation for arrays
added rem1() and rem2() to documentation (low level version of remainder functions, AKA modulas)
1.0.1:
compiler:
[MAJOR] fixed serious bug in optimizer that would remove lines updating a variable to another variable it's been set to before in ALL conditions, even when the parent value has been changed.
language reference:
added page numbers
finished an unfinished sentence about the GPU co-ordinate system, and under functions list
added details for general purpose framebuffer, and an example on how to do collision detection.
refreshed table of contents
updated assembly instructions reference to latest version, included version was quite outdated
included changelog
1.0.0:
fixed some spelling mistakes
fixed an issue where trying to upload faulty code caused the program to jam up and not be able to upload anything until it was restarted
other general improvements to prepare it for release
beta:
initial public release
What is the commandore 32?
The Commandore 32 is a brand new type of redstone computer. It's not one of those fake "computers" that have been popping up recently that run paint and have a keyboard and "pretends" to run programs, when it's all hardwired. No, this is still a real computer, like the one you're reading this on, but much more basic.
This computer is much like the traditional redstone computers, but uses command blocks instead. Using fancy tricks and custom command block generation programs, this computer has much more power than any computer you can build with just survival redstone.
In fact, this may very well be the most powerful computer ever built in vanilla Minecraft. And my measure of power isn't just based on the fact that this has 32 bit signed integer math, or hardware multiplication and division support, or that it has a function stack complete with hardware memory allocation. It's probably the most powerful because this computer has a full compiler.
What? A compiler?
Yes, a full high level compiler, complete with tokeniser, assembler and even an optimization stage. This is exactly the same thing used to compile high level languages like C++ and Java, but again, on a much smaller scale (this being my first high level compiler, there are quite a few limitations).
Writing programs for this computer is almost as easy as writing programs for Computercraft computers. Writing programs for vanilla Minecraft is now easy!
Feature list:
GPU:
CPU:
Paint, and my amazing abstract art:
Cool looking early rendering tests:
Please, post it in this forum topic! I'd love to see it, and even put it up for download on the main page if you want!
Having difficulty getting it working or want to learn how to make programs?
Watch the tutorial series here (youtube playlist): Commandore 32 tutorial series
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
Assuming you mean bitwise math: It probably won't have that, unfortunately. This computer is different in that it doesn't actually work in binary at all. In a very low level sense it does, but at no point in its operation are numbers represented by ones and zeros. There's no real need either, shift left/right is often done to avoid division and multiplication, but multiplication and division is as fast as addition and subtraction on this computer, so there's no need. Bitwise math can be simulated to an extent with the basic math functions.
As for the GPU:
My documents currently plan for me to use a larger version of the Redgame 3 screen system, with the binary decoders replaced with command block lookups and some wireless tricks for increased speed and better wiring. It will have a proper frame buffer and probably colours as well. Screen size to pixel ratio 2:1 (2x2 square of blocks per pixel) instead of 1:1 to keep logic simple.
Good luck with your own GPU!
cool. don't really understand why you need a frame buffer thou.
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
I'm going to use a unique 4 stage system that I've been referring to in my design notes as the "frame factory".
Stage 1 is a normal piston display, hooked up directly to a standard ANDEX tower, with no memory.
Stage 2 copies the blocks pushed forward by the pistons in stage 1 to a seperate area, and replaces the blocks with a different colour, depending on what was chosen.
Stage 3 copies the now coloured blocks into a frame buffer, where the next frame is built.
Stage 4 is what the user sees, and once a frame is finished, stage 4 is cleared and set to the contents of stage 3.
A proper frame buffer (double buffered) is needed to make things look a whole lot better. If you have a game, you usually clear the entire buffer and then place all the objects the game uses on the buffer. Once all objects are on the buffer, you display the buffer on the screen, clear the buffer and start work on the next frame. If you didn't have this buffer, the user would be watching the display get cleared and re-drawn to, with a finished image only being displayed for a very small amount of time before being cleared.
I'm busy with way too many projects right now, sorry. There's a whole lot of requirements there, too! I might be able to get a top down one working, but not with that much complexity.
Can't you pull values out of the scoreboard into buses using the %, value%2^n. Then you could implement the binary operations by adding the values back up with 2^n*(redstone > 0). That should work if I am not mistaken, and with some know-how it should only take a few ticks.
I could, but that would ironically take longer than arithmetic. I could add it later, There's literally millions of unused instructions available (since the instruction ID, like everything, is 32 bits), but it's not on my priorities.
I know it would be slower, but for some opps it would be nice to have. I understand that it is low on the priority list.
I'll be sure to add that if I'm bored and don't know what to implement next
Anyway, update time! wow, it's been over a year since I last did this I believe. I've built the main components of the GPU, and 3 of the 4 frame factory stages! The 4th one (final frame buffer) isn't done yet, but it's dead simple and would only take a single command block.
The display is MASSIVE, 64x64 blocks big, 32x32 pixels and 4 bit colour, probably making it one of the most "HD" displays of its class. Here's an image of the first stage rendering a 31x31 square in the center of the screen:
Hard to see the square, I know. It's not supossed to be easy to see, that's what the next stages are for
After implementing stages 2 and 3, here's the first successful colour test:
From another angle, where you can clearly see the different stages:
It supports all 16 wool colours, and even though I expected this result, I was still impressed by how awesome a multi coloured display looks in minecraft.
Here's the current control logic:
The big decoder on the left is for all the wool, and the big repeater chain is for waiting on the 1D line drawer systems. I'll optimise it later. Also, this thing is laggy. Very laggy! Luckily, I was expecting this, and the design allows the CPU to continue working while the GPU does it's thing, and can see when it's done through a status flag. So it can prepare the next pixel/box/whatever while the GPU is still busy!
The CPU can't actually control the GPU yet, though. Right now it's me manually placing redstone blocks. The only thing programs can do at this point is change the coordinates. Of course, I'll be connecting this to the CPU next!
EDIT:
forgot to include a side view:
The 2 near identical things on the bottom left is the 1D line drawers, one for X and one for Y. The top platform is for control logic.
el I regally did not see any need of a frame buffer because I program on my ti 84. TI-Basic is slow and does not support frame buffers so I have evolved to making graphics not use frame buffer.
So instead of clearing EVERY THING and painting the new sprites on, I only change the thing that has moved
(Ex: instead of reprinting the whole screen when say a curser is moved, I only paint the curser in the new position and fill the old position with what is supposed to be there.
The commands for my GPU are (just so you get a feel of the arc.)
Set point 1 (x1,y2)
//set first cordenet
Color (int )
//set color
On (x2,y2)
Off (x2,y2)
Change (x2,y2)
//fill area from (point 1) to (x2,y2) and do the required operation (on off change)
Test(x,y) //get color of x,y
Boolean pixleMode //if true x1 and y1 are replaced by x2 and y2, there for drawing a single pixel at (x2,y2)
EDiT: I have found a command block computer that calculates some useless thingamajigers and draws it on some screen. Here is the vid. Check it out!
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
There is a frame buffer on the 84, just can not get to it without asm or a basic library.
If you want I could make the binary operations and send them to you in a schematic, I really want them in the RG4.
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
Sorry, can not spell well, so I always misspell spoiler. (Unless it is their already like now.)
That and I forgot that you had one when I posted before.
Pfft, steal my ideas why don't you...
Just kidding, of course you can use the idea. I haven't patented it or anything.
If anyone's interested, all 3 shapes took different amounts of time to render. The hollow blue shape taking the longest (renders in 2 steps), the green filled rectangle taking second longest and the red dots being the fastest (bypasses the 1D line drawers, avoiding their delay)
If you want to plot a single pixel, all you have to do is set one set of co-ordinates (example x2 and y2) and set the other to (0;0). That's why coordinates start at 1 instead of 0.
THE MICRO$OFT APOCALYPSE IS ON!!!
32 bit redstone computer with 64*64 pixel 16 color gpu:
http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/2116999-computer-command-block-computer-now-running-with
(giant banner removed out of modesty).
I was planning on using a different method involving replacing the repeater chain with filled redstone blocks, but your suggestion gave me an alternative idea. Thanks!
The poll seems to be doing nicely. So far bottom left origin is winning, which is great, since bottom left is already the origin so less work for me
Of course, moving the origin won't be too difficult as I have fancy custom tools to do most of it for me, so I won't mind top left origin.
You guys all want the control panel raised so it's in line with the center of the screen. This does mean that standing at the far end of the control panel (away from the screen) you won't be able to see all of the display. I hope you guys are OK with this. I'll try make something practical...
I had a last minute good idea about how to access local memory: using negative values. If you look on the big spreadsheet of planned functions on the original post (quite outdated now), you'll see a few copy local->main and main-> local functions, and local/main versions of set. This is all being merged to one copy and one set function, and local variables can now be saved to and loaded from in any function!
It's quite simple. negative numbers refer to local variables while positive ones refer to global ones. so 10 is global variable 10 (EEPROM 1, I believe) while -2 is local variable 2, local to the function running it. You can save and load to and from both 10 and -2 in all functions and the logic will take care of it.
However, the extra delay caused by the local variable checking and correcting logic (it has to convert it to a "global" address in real memory), though the delay is not much, is causing certain functions to act weirdly when using local variables instead of global ones. Particularly when both local AND global variables are involved in the same function. I'm having some problems debugging this, as it's pretty tricky stuff, but I'm slowly making progress.
In my frustration to debugging the above, I've started working on a compiler. It's written entirely in Java, so it's multiplatform. And it's a proper compiler, with a custom tokenizer and lexer written from scratch, proper error detection with line references, and it generates assembly code which is then assembled by my assembler program, so you can further optimise your program when you finnished it by hand.
Here's what the languages syntax looks like:
It's pretty different from normal languages, so let me explain some stuff:
Yes, it's not nearly as high level as modern languages like C++ , but it's better than assembly, right? Also worth noting nested functions(for example "myFunc(add(5,20),10)" wouldn't work) and multiple operation math ("x=6+a*b" would need to be "x=a*b; x=x+6") won't be supported, though I could add it later.
Also, since I'm making this programming language, I'm also adding "until(condition)" which will do the same as "while(!condition)", except be 20 times more readable. I've never really liked while not things, they're so confusing! I also hate using for loops for some reason (specifically Java for loops), and since you cannot declare variables inside of function code as I already said before, there will be no for loops.
So far, global and local variables are detected and assigned IDs, and basic math can be compiled ("a=5-b", or "x=-20") and it can give errors. Not much, but it's a start. Code's a little messy at the moment, first time writing a proper tokenizer and only recently decided to use Java's Exceptions for syntax errors. But it will be awesome!
Will the compiler be open source?
It is a good idea to use Exception how you are using them, similar "hack" to for(String buffer = in.readLine(); in != null; buffer = in.readLine()). Good work.
Possibly. The code is embarrassingly bad, though.
In other news, the compiler can now compile slightly useful programs! if() and print() have been implemented, though the's no else or !=. And no loops yet. After that, GPU functions and user functions (right now it only compiles the "main" function).
Another limitation is this is a purely sequential compiler, there's no linker. This means you need to define all functions before you use them, like in languages such as lua.
The compiler's almost in a state where I can actually start using it to write programs instead of assembly. It has it's limitations, but it's much better than writing in assembly, and infinitely better than writing in machine code like you have to for most redstone computers.