In recent versions of MC, you can do a much better delay line memory with comparators. You can actually end up being able to store 2b / block (2 and not 4 because comparators have to be placed on something not a comparator.) - it would be half that but there's a trick you can play to avoid requiring redstone dust between comparators.
The delay is faster too - 1 redstone tick / 4 bits, or 40 bits/sec per line, as opposed to this implementation's 1 bit / 8 redstone ticks / line, or 1.25 bits / sec / line. (Note that this implementation of piston tape is decidedly suboptimal: the maximum is actually 3 bits / 4 redstone ticks / line = 7.5 bits/sec/line, as you can actually check for 8 different block types (glass / solid / sticky/non-sticky piston facing 3 directions) and you can make a faster-resetting piston loop.)
The biggest issue with comparator delay-line memory is that there's no way of pausing it.
There's also a way of storing arbitrary amounts of data per block, and that's to use the fact that items with NBT data will stack only when their NBT data is identical. The easiest way to see this is to try to stack renamed items, but there are others. You can make a hopper or dropper chain and encode data in which line which enchanted item is in.
I have yet to see a practical implementation of the above, though.
As parent said, items with the same name stack together, items with different names don't. There are item testers in minecraft based on whether the item will stack.
I can see several ways that you could implement storage and processing using that, thank you.
For anyone else thinking about the problem, there are two processes that could be used by item sorting to do processing:
1. You can use the stream of items through a pipeline (if deterministic enough) to encode a bit of strings. You can do this without enchanting, because you only need two item types.
2. You initialize an instruction decoder and have it sort the item based on type, which then triggers a command block to decode the instruction further.
That video on their main page is mind-boggling to me.
I have a friend who's a regular on that server, and he would occasionally explain to me things like how they take advantage of how Minecraft's redstone handling works to shave precious ticks off the latest ALU design's return time, or how they created a fully vanilla-compatible "internet," to pass data through wires between different people's machines.
They've got mods set up to copy and paste blocks, so you can build modular systems out of components and avoid repetitive block-placing, but AFAIK, everything else is vanilla. It's incredible.
Interesting fact: If ENIAC was tasked with calculating the current Bitcoin hashrate, it would have to mass as much as the world's oceans and would require an earth's surface worth of solar panels to power it.
Provided you set the input block, the implementation shouldn't be too hard. You need an incrementing counter included in the input, some feedback that will stop it and a huge field implementing the hashing. Likely much less complicated than the drive presented here... but much larger.
For people interested in how computers work, I recommend the book/course "From NAND to Tetris - Building a Modern Computer From First Principles"[1]. It starts of with boolean logic and NAND gates, and it steps you through making a computer that can play tetris.
I haven't read that one, but I'll definitely check it out. I'd also recommend Charles Petzold's book called "Code". One of the best technical books I've ever read!
Besides "Code," I highly recommend "The Pattern on the Stone" by Danny Hillis, who also happens to be the designer of Thinking Machines' massively parallel supercomputer, the Connection Machine. It covers more material than Code in a lot less time.
In "Code," Petzold makes sure to cover the material exteremely slowly so that you won't miss any details, so it may get boring for some, but I would also read Code if you have the time and interest.
Thank you so much. I have been looking for something that explains these principles to a non developer but technically interested designer this looks like it will do the trick.
My nephew and his friends are 8-9 years old, and they're masters at building this stuff. The redstone, the logic, the machines, all of it. It's all they think about, all the time. Imagine what potential this early compsci education is fostering?
We just have to remind them when they're older and are running things and building amazing stuff that it's NOT OK to blow up other people's stuff with tnt.
When I was taking a digital electronics course in high school, Minecraft was getting huge. We would spend hours playing and usually try to build the stuff we learned about in class. It was an incredible teaching tool, tbh.
I hope it's enough. It's not like young hackers can easily disassemble/reassemble stuff in the real world like we older guys did.
And yes, you can take apart a cell phone or a tv or whatever. But the risk:cost ratio isn't nearly as favorable as it was for the previous few generations. The chance of irreversibly breaking it is far higher, and the chance you'll learn very much by just looking are much lower. Likewise, nobody's stopping you from wrapping wire around magnets to make your own memory... but it's not like that's a "thing" kids get exposed to now. But it's all there in minecraft.
(It's also seriously hard to find children's science kits worth buying as the culture of extreme protection of children have turned them into junk. This is one of the only frontiers I'm aware of that's open to children (without the guiding hand of a science-mentor) to learn and play and create in this way)
I've never understood why people think gaming or play ever forms the justification or basis for learning. Decade of nonsensical "gamification" studies has had zero effect no matter what Jane McGonigal says.
Might get an interest or passion going but it has near-zero lasting educational value.
I think there's a difference between "gamification", i.e. doing tasks for currency, points or prizes, and "video gaming", i.e. creating a circuit so that your house door in Minecraft opens with a switch.
A Life acceleration algorithm would help with that, but each cell would still require 4Tb of storage (though that storage could be shared by all cells, II think).
It is a simulation of Game of Life in Game of Life. They did loop the video though. Obviously it's not possible to fully simulate such a huge machine. You could do it with sufficiently clever optimization, but the result would be equivalent to video editing.
This will not work as described.
I think his design is a good idea, but still does not work.
I build a better harddrive (with 4 kb storage!) over a year ago, imgur link will follow.
Now to the design problem in this HDD:
see that all the blocks are blue in the platter?
No way to swap each of the bits without magically creating new green blocks.
My hdd solves that problem by having BOTH block types available on the platter. But see for yourself:
I know very little about Minecraft, but if this doesn't work, it pretty much has to be trolling. (No way you build something like this and not notice that it doesn't work.) And then I wouldn't expect them to offer a link to download the map, and I wouldn't expect someone else to say they've got it working: http://www.reddit.com/r/Minecraft/comments/2e0ghk/fully_func...
I don't know much about MC or computers, but as far as I understand each bit has both blocks, shift up for blue=0, shift down for green=1. Here: http://i.imgur.com/rqZm4DU.gif
Yes, but you don't see BOTH block types on the big tape. Swapping bits requires one block for each state, but the green ones are missing from the tape screenshots.
I don't think that they have to necessarily be green. So the fact that you don't see them may not mean that they are not there. He may be using blocks the same color as the structure for aesthetic purposes.
This concept is known as a delay line memory, although this particular implementation doesn't need any refresh, like a chain of shift registers: http://en.wikipedia.org/wiki/Delay_line_memory
Although: no need for someone immortal with infinite time and energy to run the simulation, rather lots of people each devoting a small amount of both to it...
This is really cool. I really like Minecraft computer components, but I could never help to think that if the guys who build them, started playing with something practical, the results might be more tangible.
Think of it more like a better UI on top of EE307 or whatever your local equivalent is for low-level hardware design. I had to scratchbuild a functional CPU using nothing but NAND gates to pass mine. I got through it, somehow, producing a CPU which would run minimal assembly-esque programs but which existed on no physical hardware and wouldn't be for for any purpose if it did. If you can do it with red stone I think any rational person would say you have all the knowledge my class tried to impart.
It's the old Church-Turing thesis in a way; instead of using logic gates implemented with silicon transisters, they're using physical blocks and switches in minecraft. The principals are the same, just a different 'substrate'. DNA can be used as a computing substrate[1], and at a more macro level, the structure of cells[2]. The minecraft guys have a lot more in common with the early computer engineers who used relay switches and diodes on rotating drums.
I have a friend who used to keep excitedly showing me his crazy, impressive redstone ALU/CPU designs. I kept trying to get him to buy an FPGA and build out something with real hardware, but he maintained that a big part of why it was fun was because of the environment and community that came with Minecraft. That might go some way toward providing an explanation.
So, did anyone do a Minecraft-to-VHDL transpiler yet? :) Sneak up on them and convert their in-game creations to something that can be synthesized into actual hardware.
I've worked in hardware, and think this kind of play is meaningful.
You confront many of the engineering challenges you'd face (in terms of line routing, timing challenges, design concerns, modularity, etc), but they have simpler and more straightforward constraints because of the different medium.
You're also really unlikely to get results using exactly this same skill set when trying to work with real hardware. The immediate need for programming and complicated tools becomes apparent when you try to grapple with the complexity of modern ICs.
If you're just going to have them blink LEDs using logic gates, I fail to see what you think you're getting from hiding all the logic circuitry in little black boxes and making the parts harder to work with. I've encountered all the engineering concepts (minus some physics concerns) I learned in several quarters of circuit design as an undergrad.
The reality is that Minecraft actually is a very good tool for introducing hardware concepts, because it removes the dependence on understanding software to do something.
(Really, the tooling around hardware needs to be better, particularly for things like FPGAs. Raspberry Pis and Arduinos are making good inroads.)
The relationships between those not-necessarily related words would need considerable detail for the claim to mean anything.
Play doesn't require results, a virtual world in a computer will never be tangible and is likely used by people uninterested in being tangible, practical things usually aren't involved in playing, it goes on and on.
This is a great learning experience for anybody, young or old. Maybe the builder in the screenshots is a carpenter and just trying to learn how hard drives work. Maybe he's a kid who will build the next gen drive in 20 years based on his ideas seeded here. How do you know?
Or not. I think that the medium plays a very big part here. It's the essence of hacking, twisting something like Minecraft engine to run processors, and hard drives, and stuff. Doing the same on VHDL? Boring.
I always wonder when I see these things, are players placing each block individually? Or are they mapped out in some file and fed to the server to render?
In classic minecraft there used to be a convenient command where you could type /cuboid or /z and then place or destroy two blocks, and it would fill the area in between. There were countless more server-side commands and mods that let you build large scale structures. Copy and pasting sections, building spheres or cylinders, making shapes hollow, etc. Flying was much easier and faster too, although it did required a mod.
Minecraft now has so many more features and block types. But I miss some of those features, and building large scale structures is much more difficult.
In addition to MCEdit, which reads and writes Minecraft worlds offline, there is WorldEdit, which can be used in-game (whether via a client-side mod such as Single Player Commands or via the official server-side plugin). If I recall correctly, with CraftScript installed one can also automate block placement. With the right config you can make this all work in SSP or SMP - WorldEdit will use blocks from one's inventory instead of creating them ex nihilo.
Really nice, however I there is some buggy behavior in this logic simulation:
It can end up in an inconsistent state:
I have a little Robot Odyssey experience where it would loop forever between inconsistent states. However that design is not perfect either, it's still much better than this in my opinion.
What Minecraft could really use would be a scripting capability of some sort. Basically, once you've figured out how to do something, you should be able to build a machine that does it for you. That would be a pretty sweet game.
What minecraft needs is a way to speed up the game. There have been quite a few people who have made calculators and "electronic" components, which would be a lot more cooler if they could work faster.
What type of circuits are technically possible to build in Minecraft? Could one build a basic CPU with RAM, HDD, and BUS? What is the limit of what one could build?
It hit me on a walk last night: What this needs to be truly complete, more than more KBs or other computer components (like the competing HN article), is the click-of-death when it dies of old age!
Cool, makes me want to start tinkering with Minecraft, but can't really afford anymore time sinks in my life. Still its amazing what people can do with it.
It's a hard drive. The storage is persistent. Assuming your argument is that the world the device is constructed in isn't guaranteed to be persistent, then that renders physical hard drives in our physical world as non-persistent; let's see how persistent our data is when Sol goes red giant... ;-)
jeremycole is correct, its closest real world analogy is a bubble memory or the short lived fad of using CCDs as a large linear memory (that went nowhere around the mid 80s) or most accurately its compared to an ancient mercury delay line (although Hg delay lines and CCDs are/were not persistent but their mechanical operation is similar)
There was a fad of endless loop tapes in the 80s... Exatron stringy-floppy. That is probably the closest physical analogy. Think "cassette tape interface" with electrically controllable R/W on an answering machine cassette, all conceptually of course this isn't how it actually worked. It had nothing to do with a floppy other than storing about the same amount of data, very java vs javascript like.
It's a sign of the times. "Hard drive" has come to mean simply "nonvolatile local storage." Some people who know better even talk about "SSD hard drives" without snark or irony.
It wasn't that long ago that "hard disk" meant "3.5 inch floppy disk" to many people. Pedantically speaking, they were wrong, too, but the little floppies were hard to the touch and they did store files. It made sense.
It's a triumph, in a sense, that so many people are at least able to grasp the function of this invisible machine (the hard drive) even if they aren't using the term in an engineer's excruciatingly precise and correct way.
The delay is faster too - 1 redstone tick / 4 bits, or 40 bits/sec per line, as opposed to this implementation's 1 bit / 8 redstone ticks / line, or 1.25 bits / sec / line. (Note that this implementation of piston tape is decidedly suboptimal: the maximum is actually 3 bits / 4 redstone ticks / line = 7.5 bits/sec/line, as you can actually check for 8 different block types (glass / solid / sticky/non-sticky piston facing 3 directions) and you can make a faster-resetting piston loop.)
The biggest issue with comparator delay-line memory is that there's no way of pausing it.
There's also a way of storing arbitrary amounts of data per block, and that's to use the fact that items with NBT data will stack only when their NBT data is identical. The easiest way to see this is to try to stack renamed items, but there are others. You can make a hopper or dropper chain and encode data in which line which enchanted item is in.
I have yet to see a practical implementation of the above, though.