hey mate u have a series i do called redstoned high and i would like to have you there explain some stuff about wiring because the fact that you seem to know alot more then i know. i would also ask if i can have a field trip ( tour. i used that term because it is a school ) on your computer it is pretty insane but i would like to have you there either on a server or you there with me on skype or you teach me how. but i still would like you to be there and teach me how anyways.
Slight necro. Althought it's a bit less of one now than if I posted in the RG2 thread... It's relevant to both, so oh well.
BoxCode is still making progress, and I'm still trying to decide the last few details of the language...
Namely, does anybody particularly want the ability to link in assembly language (or binary) programs into BoxCode programs? I'm not currently sure how to do that, but it could allow more flexibility in using odd hardware features... Or especially for the RG3 access to peripheral devices. If that's desirable... Should I let users implement their own operators / function style programs that return on completion to include those operations? Or link in assembly program files directly?
Also, with the RG3's ALU being capable of using user-defined operations, should I let the user define arbitrary operators in plain binary (with some sort of header) ? Would assembly-programs be enough to use custom operators?
The WIP language-specification is up on the GitHub repo, at https://github.com/Solarspot/BoxCode/blob/master/RedGameCompiler/BoxCode1point0.txt For anyone wondering what I'm doing. Also, if anyone wants to use what exists of my compiler for something else (like a different computer, once the compiler works) feel free to. It's released under a BSD license, don't even need to sell your soul
Rollback Post to RevisionRollBack
The winner of a rat race is still very much a rat. -Lily Tomlin
The same way other people have made many other giant computers in Minecraft. Plan out how the computer should respond to instructions, segment that into modules that do component-tasks of the larger system, plan out the logic those each need to use... And then build it. Construction itself is in Creative mode, often with mods like WorldEdit to copy-paste repetitive parts.
Rollback Post to RevisionRollBack
The winner of a rat race is still very much a rat. -Lily Tomlin
Looks awesome! But it'd just be really really really cool if you extend the ALU with a built in, hard wired, multiplier and division.
like Ralath0n said, it would be too slow. also way too big to fit in the current ALU. an external DPI device can be made to do this job, though, and could allow multiplication/division to happen while the rest of the computer is either waiting or doing something else in the meantime (kind of like some sort of hardware multitasking).
Slight necro. Althought it's a bit less of one now than if I posted in the RG2 thread... It's relevant to both, so oh well.
BoxCode is still making progress, and I'm still trying to decide the last few details of the language...
Namely, does anybody particularly want the ability to link in assembly language (or binary) programs into BoxCode programs? I'm not currently sure how to do that, but it could allow more flexibility in using odd hardware features... Or especially for the RG3 access to peripheral devices. If that's desirable... Should I let users implement their own operators / function style programs that return on completion to include those operations? Or link in assembly program files directly?
Also, with the RG3's ALU being capable of using user-defined operations, should I let the user define arbitrary operators in plain binary (with some sort of header) ? Would assembly-programs be enough to use custom operators?
The WIP language-specification is up on the GitHub repo, at https://github.com/Solarspot/BoxCode/blob/master/RedGameCompiler/BoxCode1point0.txt For anyone wondering what I'm doing. Also, if anyone wants to use what exists of my compiler for something else (like a different computer, once the compiler works) feel free to. It's released under a BSD license, don't even need to sell your soul
awesome! I'd say keep it as basic as possible, and expand it later. I personally woudn't see the need of converting assembly(well, machine code) to BoxCode.
why are there minecarts in the middle of no where?(next to big colorful computer part xD)
pic:
-snip-
off to read manual!(I seriously dont get how you made this without dying )
this is a little copying fault. I used WorldDownloader to get the RG3 off the RDF server so I could put it up for download, and used MCEdit to remove all my other stuff. I forgot to remove entities, so what I think is part of the minecarts of a minecart station remained!
hey mate u have a series i do called redstoned high and i would like to have you there explain some stuff about wiring because the fact that you seem to know alot more then i know. i would also ask if i can have a field trip ( tour. i used that term because it is a school ) on your computer it is pretty insane but i would like to have you there either on a server or you there with me on skype or you teach me how. but i still would like you to be there and teach me how anyways.
well, time-zones is usually a problem for these things. if you live in america then chances are we won't be online at the same times.
awesome! I'd say keep it as basic as possible, and expand it later. I personally woudn't see the need of converting assembly(well, machine code) to BoxCode.
Keeping it basic would be nice. I already have 17 operators that return various values when passed one or two inputs. And four control flow operators (if, unless, while, until) that can be used in prefix and postfix versions, giving seven different meanings ("do@ if..." and "do@ unless..." both act as a do@ The [s]standard[/] spec explains this as checking the condition -after- running the code, which is useless. do@ invokes the immediate function, BTW) So I'm not sure how well I'm doing on that one... The program in general is already way too complicated. I even wrote my own text editor That might be why it's taking so long,
I don't see any real need to convert assembly / machine code into BoxCode either. What I do think would be useful, is using something written in assembly from a BoxCode program. Just since I can't anticipate everything everyone wants to do (by simple nature of this being a programming language for a extensible computer). How many op codes does the ALU support? 500? Most of them probably useless, but still. It'd be nice to let the user expand the language directly, by adding in the definition of some new operator... Maybe they want to do 10101010 with the ALU (just made that up) and assign that operation to some spiral-character in Unicode.
...More importantly, how would they use a DPI device? I definitely can't anticipate every DPI device for the rest of time (unless none ever get made). What kind of interface should I write for interacting with generalized "devices"? Just send-number and check register value? One solution is the assembly-method: Write the parts of the program that deal with DPI devices in assembly, and call them from the BoxCode program. So I'd need a way for them to interact.
I suppose this still falls under input / output. And I can't decide on how to do those yet. BoxCode has no function returns, instead it has "routines" (my name) that simply don't return. Control flow continues past the bottom of a routine down to the next line of code inside the routine it's defined in.
def program
var number
do @
def
do @
def
number = 5
end
end
//number is 5
end
That should be a bit of an optimization, but I can't decide how to link in 'libraries' or user-defined operators ( printf (""); calls return to the caller after printing) without those returning to the calling code. I'm fine with starting the parser proper now, just because I think I know how to compile those to binary (and see what the binary does) even when the programs produced do nothing visible.
Nah, but in all seriousness, how you could accomplish this actually blows my mind, To build a computer in a computer game requires a level of creativity and intelligence that I can't even fathom. Well done and I sincerely hope you keep updating Redgame in the future.
Oh my gosh how the hell did you build that giant Computer?!? D:
Technically this is the smallest computer in the world. (The fact that the world is stored in what? Less than one Megabyte of space, which is like micrometers across of silicone!) Lol
I just had a look back through the Redgame 2 thread. Spotted dude's original assembly syntax, and Zeemvel's post. He asked that compiler writers keep compilers for the platform modular and portable, so they could be run on linux... That point went straight over my head for the first few months. But... my compiler is shaping up to be a standalone Jar file that converts BoxCode text into assembly text. No GUI involved, no literal dependencies other than Java 6. Although you need an assembler. And you need Java 6 anyway to run Minecraft. So I think the BoxCode compiler is sufficiently portable to anything, just as long as my eventual GUI for the thing is in a separate package, and the compiler doesn't depend on it.
On the assembler for this computer, what if I hid the ALU registers and presented operations as [RAM] = [RAM] [operator] [RAM] ? Like... $2 = $5 + $3 to sum Ram 5 and 3, and save the result to 2?
-On that train of thought, How about a statement like that with no further information follows unconditionally to the next line?
-For statements that do some sort of branching, could we follow the above expression with something like |condition ?
:label
$2 = $5 + $3 |> label
To do that operation, then branch to "label" if $5 > $3 ?
-I only presented a conditional branch to one label there... But this computer can branch to two different destinations. I'll just say the above statement branches to the label only if that condition succeeds, and goes to the next line otherwise. But how should we list two labels?
-I suppose you could do user defined functions with a special syntax like {0000000000} for a user-defined operator that does regular-old addition. Similarly to that, you could define entire command lines like that, by writing the entire thing in {}'s.
-nop "No operation" could be a keyword for a command that does nothing, if you need a delay at some point.
Rollback Post to RevisionRollBack
The winner of a rat race is still very much a rat. -Lily Tomlin
yo dawg, we heard you like computers and games, so we put a game in your computer, then put a computer in your game in your ccomputer, then put games in the computer within the game within the computer.I deserve like 9001 rep for that. How obvious is it? HIS SIG IS A FREAKING YO DAWG! I AM A GENIUS! I should make a caption this on memebase by the way. Cool computer. I agree that you have too much spare time. Usually when i want a computer in minecraft i use tekkit, but whatever makes you happy. It certainly shows dedication, and i am impressed that you did it vanilla. Shocked and amused, but impressed.
Hey, dudearent, are you still with the UTD? Just wondering, haven't been that active lately.
Also, is it okay if I add RG3 as a semi-UTD project? I'll link this thread as the download thread. If you want to keep it personal, that's all cool too.
---TheMan2016
Rollback Post to RevisionRollBack
UTD (Union For Technological Development) Administrator & SkyWater Gaming Co-Owner
Hey, dudearent, are you still with the UTD? Just wondering, haven't been that active lately.
Also, is it okay if I add RG3 as a semi-UTD project? I'll link this thread as the download thread. If you want to keep it personal, that's all cool too.
---TheMan2016
I don't do much minecraft anymore, but yes, I'm still with the UTD, and you can add it as a semi-UTD project.
I don't do much minecraft anymore, but yes, I'm still with the UTD, and you can add it as a semi-UTD project.
Thanks. Kindof sucks that you don't do that much Minecraft anymore. The UTD just got a server, and I was thinking of doing a UTD project with all of our best redstone engineers.
Rollback Post to RevisionRollBack
UTD (Union For Technological Development) Administrator & SkyWater Gaming Co-Owner
Holy crap this thing sucks. First off nice try removing it from the RDF where it is viewed for what its worth. the instruction set is stupidly large. the ALU is what 5 wide wtf sucks. 2 goto system lol use a branch register. and slow. probally the worst redstone computer out there
Epic.
I love the programming capabilities of this thing, as well as the way you've come up with the idea to make each module in a different section of it.
Keep up the good work!
Just as an idea for future ones, you could use sticky pistons and blocks with the program arrays, so that instead of ADDING torches, you have the torches already there and when the pistons are extended, it acts as if there was a torch there.
The pistons would be linked to a color-coded switch array in the control room (Likely on the floor) so that you can change the program and control it from the same place, but taking up room in your program arrays.
Don't go to any trouble though.
Thanks for putting these computers out for us to use.
Holy crap this thing sucks. First off nice try removing it from the RDF where it is viewed for what its worth. the instruction set is stupidly large. the ALU is what 5 wide wtf sucks. 2 goto system lol use a branch register. and slow. probally the worst redstone computer out there
Finally some one other than me that has tried to get the public off this horrid piece of ...
pic:
off to read manual!(I seriously dont get how you made this without dying )
BoxCode is still making progress, and I'm still trying to decide the last few details of the language...
Namely, does anybody particularly want the ability to link in assembly language (or binary) programs into BoxCode programs? I'm not currently sure how to do that, but it could allow more flexibility in using odd hardware features... Or especially for the RG3 access to peripheral devices. If that's desirable... Should I let users implement their own operators / function style programs that return on completion to include those operations? Or link in assembly program files directly?
Also, with the RG3's ALU being capable of using user-defined operations, should I let the user define arbitrary operators in plain binary (with some sort of header) ? Would assembly-programs be enough to use custom operators?
The WIP language-specification is up on the GitHub repo, at https://github.com/Solarspot/BoxCode/blob/master/RedGameCompiler/BoxCode1point0.txt For anyone wondering what I'm doing. Also, if anyone wants to use what exists of my compiler for something else (like a different computer, once the compiler works) feel free to. It's released under a BSD license, don't even need to sell your soul
like Ralath0n said, it would be too slow. also way too big to fit in the current ALU. an external DPI device can be made to do this job, though, and could allow multiplication/division to happen while the rest of the computer is either waiting or doing something else in the meantime (kind of like some sort of hardware multitasking).
awesome! I'd say keep it as basic as possible, and expand it later. I personally woudn't see the need of converting assembly(well, machine code) to BoxCode.
this is a little copying fault. I used WorldDownloader to get the RG3 off the RDF server so I could put it up for download, and used MCEdit to remove all my other stuff. I forgot to remove entities, so what I think is part of the minecarts of a minecart station remained!
well, time-zones is usually a problem for these things. if you live in america then chances are we won't be online at the same times.
Keeping it basic would be nice. I already have 17 operators that return various values when passed one or two inputs. And four control flow operators (if, unless, while, until) that can be used in prefix and postfix versions, giving seven different meanings ("do@ if..." and "do@ unless..." both act as a do@ The [s]standard[/] spec explains this as checking the condition -after- running the code, which is useless. do@ invokes the immediate function, BTW) So I'm not sure how well I'm doing on that one... The program in general is already way too complicated. I even wrote my own text editor That might be why it's taking so long,
I don't see any real need to convert assembly / machine code into BoxCode either. What I do think would be useful, is using something written in assembly from a BoxCode program. Just since I can't anticipate everything everyone wants to do (by simple nature of this being a programming language for a extensible computer). How many op codes does the ALU support? 500? Most of them probably useless, but still. It'd be nice to let the user expand the language directly, by adding in the definition of some new operator... Maybe they want to do 10101010 with the ALU (just made that up) and assign that operation to some spiral-character in Unicode.
...More importantly, how would they use a DPI device? I definitely can't anticipate every DPI device for the rest of time (unless none ever get made). What kind of interface should I write for interacting with generalized "devices"? Just send-number and check register value? One solution is the assembly-method: Write the parts of the program that deal with DPI devices in assembly, and call them from the BoxCode program. So I'd need a way for them to interact.
I suppose this still falls under input / output. And I can't decide on how to do those yet. BoxCode has no function returns, instead it has "routines" (my name) that simply don't return. Control flow continues past the bottom of a routine down to the next line of code inside the routine it's defined in.
That should be a bit of an optimization, but I can't decide how to link in 'libraries' or user-defined operators ( printf (""); calls return to the caller after printing) without those returning to the calling code. I'm fine with starting the parser proper now, just because I think I know how to compile those to binary (and see what the binary does) even when the programs produced do nothing visible.
Nah, but in all seriousness, how you could accomplish this actually blows my mind, To build a computer in a computer game requires a level of creativity and intelligence that I can't even fathom. Well done and I sincerely hope you keep updating Redgame in the future.
Technically this is the smallest computer in the world. (The fact that the world is stored in what? Less than one Megabyte of space, which is like micrometers across of silicone!) Lol
On the assembler for this computer, what if I hid the ALU registers and presented operations as [RAM] = [RAM] [operator] [RAM] ? Like... $2 = $5 + $3 to sum Ram 5 and 3, and save the result to 2?
-On that train of thought, How about a statement like that with no further information follows unconditionally to the next line?
-For statements that do some sort of branching, could we follow the above expression with something like |condition ?
To do that operation, then branch to "label" if $5 > $3 ?
-I only presented a conditional branch to one label there... But this computer can branch to two different destinations. I'll just say the above statement branches to the label only if that condition succeeds, and goes to the next line otherwise. But how should we list two labels?
-I suppose you could do user defined functions with a special syntax like {0000000000} for a user-defined operator that does regular-old addition. Similarly to that, you could define entire command lines like that, by writing the entire thing in {}'s.
-nop "No operation" could be a keyword for a command that does nothing, if you need a delay at some point.
Although i have a slight problem.... I am trying to clear the screen but it is not working...
Is this the right way to do it?
Uploaded with ImageShack.us
Also, is it okay if I add RG3 as a semi-UTD project? I'll link this thread as the download thread. If you want to keep it personal, that's all cool too.
---TheMan2016
I don't do much minecraft anymore, but yes, I'm still with the UTD, and you can add it as a semi-UTD project.
Thanks. Kindof sucks that you don't do that much Minecraft anymore. The UTD just got a server, and I was thinking of doing a UTD project with all of our best redstone engineers.
I love the programming capabilities of this thing, as well as the way you've come up with the idea to make each module in a different section of it.
Keep up the good work!
The pistons would be linked to a color-coded switch array in the control room (Likely on the floor) so that you can change the program and control it from the same place, but taking up room in your program arrays.
Don't go to any trouble though.
Thanks for putting these computers out for us to use.
Finally some one other than me that has tried to get the public off this horrid piece of ...