if I understand this correctly, this patent is about security. the inventor of the HTTPS connection could get sued for making secure connections, they can sue banks for not allowing them to access other people's accounts, they can sue the government and military for having classified documents! this patent makes no sense whatsoever!
this company is almost as bad as Apple!
I do hope they loose every case with every company for having the world's dumbest patent. sometimes, the modern legal system just makes no sense...
-
- dudearent006
- Registered Member
-
Member for 13 years, 1 month, and 2 days
Last active Sat, May, 9 2015 03:53:09
- 2 Followers
- 1,138 Total Posts
- 238 Thanks
0
Well, this was your first sentence in your topic is:
I'm pretty sure that counts as arrogance.
In an effort to help you, people are telling you this isn't a calculator because this is a terribly inefficient way of doing things. While a lookup table is technically still a calculator (Many systems use lookup tables for sine, for example), it's not as impressive as something that actually works out the answer.
Nice lookup system, though. The design might be usable with a different purpose, for example choosing X and Y co-ordinates for something and having the lookup table trigger setblocks in those positions, or similar. I can't think of a use for that right now, but I'm sure there is one. 3D printer? a drawing machine?
1
- 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.
Choosing a file is now much easier if you keep your programs in a different folder than where the SDK is located, e.g. your documents folder. You can just drag and drop the file in now!Also, I uploaded part 1 of the tutorial 2 days ago:
and part 2 is still uploading, and will be up here:
2
Due to how Minecraft lighting works, I think a lot of adjacent pixels that are supposed to be off are being dimply lit by the ones that are supposed to be on. Perhaps you could make a tunnel of black wool for every pixel to have better colour contrast? That might reduce the viewing angle of the display though...
0
Everything's dynamically clocked (runs for different amounts of time based on what function is running) which means changing the clock in code is pretty much impossible, and is all pipelined. It's hard to see, but it loads the next instruction while the current one is being executed. Most commands also have a 3 stage pipeline, all GPU commands and most RAM using commands like copy and store.
I'm planning to improve speed in a later update. You may notice a fast GPU command; I might add faster commands like that in the future. Right now, it isn't even supported in the compiler yet, but it will eventually.
0
Unfortunately no, the ALUs don't work at the same time. But I'm glad you managed to make use of both of them, or at least attempted to!
I can certainly swap those around, but the commandore 32 has a pretty big focus on the GPU and putting the advanced GPU functions after basic GPU would make more sense IMO. I'll see what happens. I'm going to try and make an at least slightly functional program for each episode, and the program may need certain functions that I would then need to explain at that point.
EDIT: episode 1 uploaded:
0
Glad to help! It seems my goal to inspire other people to finally start realizing the potential of command blocks for REAL computers has been reached.
The big spaces between components in mine was partly because I wasn't used to how much space command blocks used. They also use space...differently from normal redstone circuits, in a way I can't really explain. a future attempt would certainly have better component placement.
At least there's literally room for improvement! I might add more system peripherals inside the computer shell to make better use of the space.
Working on the tutorial series again now, finally. Episode 1 is rendering as I type this.
Episode 1 will be installing the computer and using blockloader (since people seem to be having problems with that)
episode 2 will be on setting up the SDK
episode 3 will be your first program and expaining the language format
episode 4 will be loops and I/O
episode 5 will be if statements and perhaps basic GPU
episode 6 will be more advanced GPU functions
episode 7 will be user functions and misc (e.g. random numbers and arrays)
episode 8 will be optimizing programs (might do arrays here)
episode 9 will go over assembly structure and conversion
episode 10 will further explain coding in assembly
That's the plan for the 10 part tutorial series, anyway. This might all change, episodes 1 and 2 are finalized/recorded and episode 3 and 4 are already planned out, so they will probably be correct too.
0
What I did is first design all the components the computer will need, and then lay them out in a logical manner. The only things that are still big with command blocks are things like decoders, so be sure to leave vertical space for those. Once the components are designed, draw a
However, all other components can pretty much be built in any shape you need because unlike normal redstone, the components take up only 1 block and busing is never a problem with scoreboards, nor do you need to worry much about repeater signal delay when placing components at a distance due to how small these components are, and wireless transmission being possible.
One thing I do HIGHLY recommend, however, is keep a text file with the co-ordinates of all the setblock "destinations" and what they if you're using wireless signals, so you can copy paste them into command blocks. Or do the reverse: to find out what a command block is triggering by the co-ordinates it's set to. Also use some sort of identification block (I used polished andresite or something, you'll see a lot of that around this build) so you can visually see where the wireless redstone blocks will be placed so you don't get confused.
0
I'm not in charge of what becomes standard, but minecraft computers are still too basic to have a fully standardized system.
The big problem is in those who build MC computers. Know that most people who build computers in video games do so because they want to learn how computers work. Most of them would've never designed a computer before. If we set a standard too high, they won't be able to attempt it with their limited skills, or simply not be experienced enough to follow a standard. If the standard's too low, then nobody will use it because you would end up with a very weak beginner's computer that can't use advanced instructions or features.
In real life, those designing x86 and ARM processors have legitimate degrees in computer science and are getting paid to follow and expand on the standards, not to design new systems. But designing new systems is fun.
If people want to use this instruction set as a standard, that's fine by me. They'll get to use the compiler (with credit) but know that this system design is flawed. I realized this about halfway through it's construction, but I couldn't just stop because I wanted to know if it would all really work. I have this realization with all my computers while building them, I'd realize that this section would be much more powerful if I did X, or due to my design section Y would actually be bad for most cases, or performs terribly if you want to do Z.
0
The problem was actually described correctly by tonkku107:
Sorry for not actually testing it myself on the latest snapshot!
Point is, version 1.1.1 of both the blockloader and SDK have fixed this issue. I've also improved the upload reliability of blockloader to be on par with that of the SDK.
Another new feature is "cmds to clipboard" in the SDK. This will copy all the needed scoreboard set commands to your clipboard, without the leading "/". The purpose of this is so you can right click and paste this into a minecraft server console and instantly upload a program. This is also very reliable, meaning multiple uploads isn't necessary. It's a beta feature, but it should work fine. I'd recommend it if you're making really big programs or you're just tired of uploading times.
So yea. if you're having problems, please download the latest version! Sorry for the inconvenience.
0
That's exactly what it SHOULD be doing, actually. It will rapidly start typing scoreboard set commands setting scoreboards named ROMA, ROMB and ROMC, and it should type "done" when it's done. Once a program is uploaded, you press the OFF button to reset it, and once that's done, you can press the ON button to run your new program (if it uploaded in 1 piece, if not upload the same program again)
You might be better at this then. It's possible to code something that isn't a mod or game script, by the way, like standalone programs.
Anyway, read the manual and look at the example programs or wait for my programming tutorial series to learn how it works. Or if you really don't like programming, that's fine too, you can just use the included programs or upload programs other people make (though there's only one ATM).
0
You'll need the latest snapshot for it to work. Your render distance should also be reasonably high for the whole computer to be loaded.
At the very least, it should say something in the chat once it's turned on. Even if it's "core system error". If you've done the above and it still doesn't work, try downloading the world again. And if THAT didn't work, I'll need more details to find the problem.
There are "preset functions", if you mean it comes loaded with a program. Once you turn it on, it will start up the paint program. Read the manual for instructions on how to upload a different program, and read programs/games/paint/readme.txt for instructions on how the paint program works. Alternatively, watch this video:
(sorry for double post, didn't see there was a new page and the forum post editor wasn't co-operating so I had to make a new post to reply to this one)
0
All it uses from the snapshots is some new command block commands. The latest one will work fine; unless you're reading this in the future where the latest snapshot broke some important redstone stuff.
But, at the time of writing, all recent snapshots have worked fine. Once 1.8 is out you can just use that too.
0
Alright, so the user clicks the "Go button, and the following will happen":
The selected code file is loaded, tokenized and goes through a series of processes that analyze and translate the code. I won't go over this in detail, but the code it eventually generates is completely different from the code it started with. All commands are translated into opcodes for the commandore 32. Every opcode consists of 3 numbers, each is 32 bits in size.
These numbers are now put together into minecraft commands for insertion. If you've seen the uploader in action, you would notice that it only ever uses scoreboard set commands.The commandore 32 has 3 massive scoreboards, called ROMA,ROMB and ROMC, which hold the program.These scoreboards contain 256 players, named "0", "1"...all the way up to "255". The scores of these players will be set to the desired opcode.
Once these numbers have been generated, the compiler tells the user there were no errors, how big the program is and how well the optimizer did it's job. The user is then given 3 seconds to select the Minecraft window and unpause the game. Once this is done, the uploader system kicks in.
The uploader system uses 2 techniques simultaneously to inject the code into Minecraft. The first is called the Robot class, which allows a Java program to "pretend" to be a keyboard. It can send keystroke commands and the OS will respond as it usually does with new key presses; it sends them to the currently selected program, in this case Minecraft.
The second method is the Clipboard. This allows a program to set the currently copied data. When you right click and click copy, or you select text and press CTRL-C on windows, that text will be transferred to a special place called the Clipboard, which can later be retrieved when you press CTRL-V or right click and paste. But the cool thing about the Clipboard is that is works between programs. If you copy something in Word you can paste it in Chrome, or vice versa.
With these 2 systems active, the compiler first uses the Robot class to press (and release) the "t" key in Minecraft, which will open the text entry box. The program now waits a little for Minecraft to respond. It can't see when Minecraft has finally opened the chat menu, so it has to guess. While it's opening, it writes the current command to the Clipboard. Once it assumes its open ,it sends key press commands for CTRL and V, and then releases both keys. This obviously inserts the clipboard's contents into the Minecraft chat window. With the desired command in the chat box, the compiler finally presses and releases RETURN, or enter, which executes the command. This process is then repeated for as many commands as the program needs.
Once all the code is finally uploaded, the user is required to press the reset button, which loads entry 0 from the scoreboard ROM into the instruction buffers, rombuffA to C, ready for execution. Whenever the computer needs an instruction, it reads the instruction number as a player from ROMA, ROMB and ROMC scoreboards, decodes what the numbers mean, and follow the instructions.
And that's the whole story! I left out the compiler bit (which is where most of the magic happens) since your question was more aimed at the uploader system.
0
Also, we have our first user submitted program, by Fez5577! It's a text drawing program, pretty much like my number rendering program but with text instead. Here's what it looks like:
It renders letters A through I (and space), and has auto newlines! I thought it was pretty darn cool. Unfortunately, there's not enough program memory for more letters, perhaps if the program were more optimized.
You can download it, pre-compiled and with source code, here: https://dl.dropboxusercontent.com/u/43744321/commandore/textDrawer.zip
There's also a download link on the main post.
0
The next video should be an installation tutorial. I've attempted the tutorial twice now and the first time I left out important stuff and the second attempt I made too many mistakes in my explanation. It's harder than it looks!
Finally, I'm doing some stuff to get arrays working so this computer becomes turing complete, and finishing the peripheral protocol. About the peripheral protocol, there will be a standard system. All peripherals will be wireless and require an on-off swictch, and all peripherals will have a unique 31 bit ID code. There will also be 3 classes of peripherals:
class A: only takes input from the computer, does not output or return information to the computer in any way.
class B: returns data to the computer on request or when a command is given to it that needs to return information
class C: returns data whenever it wants, and can modify the system's registers.
It's safe to communicate to many class A devices without having to worry about the return messages getting overwritten (there's only room for 1 message at a time), class B devices are your standard peripherals that need extra code to check the return data, and class C devices are dangerous in some cases, which is why they'll be required to have on/off switches. I'll see if I can make my own peripherals. I plan to make a class A 3D printer peripheral and class B external RAM addon.