I really wanted to make a Hard Drive for Minecraft that was not only fast but searchable AND modular. This design makes it so that you could fairly easily build it out to be 16 or even 32 bits wide with some mild modification. The trick was to build it so that everything synced up properly with a minimum of delay but still be a quick as possible.
This is my Beta 2.2 unit. My first was a vertical design that was actually quite nice, but impractically large and difficult to wire. This is still incomplete as there need to be a few timing tweaks, but those will come in time.
This is the Version 2.2 unit:
This is the new SEARCH circuitry. Now it works!
Input lines and WRITE COMMIT line.
New wiring to account for a single clock source.
Output lines structured to output all 8 bits at once instead of rippling down the line.
Thank you! Squeezing all the logic inside a space only 4 wide was a challenge, but worth the effort. I'll do more refinement on it and see if I can get the search function to be more accurate. It's useable as it is now, but you have to compensate by subtracting 2 from whatever bit you want to reach. Annoying, but meh... Maybe I'll post a video for it too. I've never done one before, but I'm sure some people would like to see this thing functioning.
I'm a little confused about the different piston rotators. Why are there a bunch of one bit red ones, and some purple ones? How do you read/write the purple ones, or for that matter the red ones?
The purple ones are read only because they're there for the purpose of keeping track of what bit you're currently on. Purple = part of the COUNTER circuit.
You'll notice the RED and GLASS lines. Each row of these represents 43 bits in total. The red and glass blocks will be swapped by the WRITE heads. This is all automated, so you don't have to do anything.
To write 8 bits, all you need to do is activate whatever bits you want on the write lines and then activate the COMMIT line. The rest of it will take care of it's self.
It's not currently timed to both WRITE and RUN at the same time, so in order for it to write correctly and not botch the rotation, the unit has to be stopped. My vertical model was fast enough to write on the fly, but I ran in to an issue with this design that can crash your map!
The only way I was able to keep that from happening was to slow down the WRITE function. Apparently in this configuration, if you write too fast, the glass block "disappears" and is replaced by some kind of ghost block.... The ghost block crashes Minecraft whenever anything interacts with it. That includes any block updates that take place next to it. VERY strange... I had to use MCedit to fix the map. Note: WorldEdit did NOT fix this problem.
Also note: WorldEdit has an issue with piston placement. whenever you copy/paste anything with pistons in it, it places ALL the new pistons facing downward. This was incredibly frustrating having to go back through and replace all the pistons...
If you're facing the whole device from the front (facing the READ lines) You'll see that the glass blocks are all aligned to the right. The right side of the red/glass row is the READ row. Hence, Glass = 0 and RED = 1. Here's what happens when you WRITE:
The device takes it's input from the WRITE lines on the back of the unit.
When the COMMIT line is activated, it first reads the output of the bit on the READ line (in front of the unit) It checks to see if it's the same as what you've put on the WRITE line for that bit. If they're the same - Do Nothing. If they're not the same - Swap the red/glass at the write heads.
A = READ bit
B = WRITE bit
C = Commit
if A = B AND c = 1 then WRITE = 0
if A != B AND c = 1 then WRITE = 1
if ( A = B ) OR ( A != B ) AND c = 0 then WRITE = 0
This means it writes only what you input on the WRITE lines and doesn't accidentally change a bit that you didn't want changed.
I would be happy to take any suggestions on how to improve this unit, OR if you wish to tinker with this one, please feel free! I think it's about as compact as it's going to get with the exception of the search logic..
I tend to favor speed over compactness most of the time, but if I can do both it makes me very happy. I'm going to remake the search unit so that it stops on the correct search bit - so expect an update to this maybe even sometime tonight.
If you're facing the whole device from the front (facing the READ lines) You'll see that the glass blocks are all aligned to the right. The right side of the red/glass row is the READ row. Hence, Glass = 0 and RED = 1. Here's what happens when you WRITE:
The device takes it's input from the WRITE lines on the back of the unit.
When the COMMIT line is activated, it first reads the output of the bit on the READ line (in front of the unit) It checks to see if it's the same as what you've put on the WRITE line for that bit. If they're the same - Do Nothing. If they're not the same - Swap the red/glass at the write heads.
A = READ bit
B = WRITE bit
C = Commit
if A = B AND c = 1 then WRITE = 0
if A != B AND c = 1 then WRITE = 1
if ( A = B ) OR ( A != B ) AND c = 0 then WRITE = 0
This means it writes only what you input on the WRITE lines and doesn't accidentally change a bit that you didn't want changed.
The block switcher is a 3-stage process and consists of 4 pistons. 2 sticky and 2 non-sticky. They all work from the same single power line and are timed at the ends where they meet the pistons.
It relies on a mono-stable circuit for the leading input pulse. A: B:
C::
D::
A top down view of it LIME = sticky, Dirt = non-sticky. All pistons face toward RED/GLASS.
STAGE 1: B goes first, grabbing the glass and pulling it back.
STAGE 2: Timed with 2 repeaters. First repeater closest to power gets clicked 2 times. Second repeater stays normal. C and D go next. D pushes the RED to the ON position and C grabs the glass.
STAGE 3: A is timed with 2 repeaters. First repeater closest to power gets 3 clicks. Second stays normal. A pushes the glass to where RED used to be. This completes the WRITE.
So I've managed to fix the search function. I've had to slow it down a bit and rearrange some stuff, but I figured while I was at it, I'd upgrade the unit to 46 bytes.
I also changed the timing circuit to use one set of "perpetual" pistons. Once I have the rest of the upgraded device in working order, I'll post it up here.
EDIT:
ALSO! I'm tying everything to the main counter in order to keep the bits aligned with everything else. This way you can still run it at full speed and not lose your place on the counter.
I like it, the counter is the address where the data is stored if I understood this correctly since I only skimmed the text and looked more at the pictures.
Rollback Post to RevisionRollBack
Here is my simpe Paint application in Minecraft.
Above is my old 2011 project that I liked, I don't play that much minecraft anymore but I occasionally help out on the Redstone forum. Hope my answers can be of help, let me know if I am unclear, and a +REP would be nice for me.
I know these things are REALLY cool and all, but what purpose do they acheive?
Well, *IF* we can manage to make these things fast enough, they'll be great for animations OR to store programs that people write for Minecraft computers. Anything having to deal with sequential data storage, really.
I like it, the counter is the address where the data is stored if I understood this correctly since I only skimmed the text and looked more at the pictures.
I was thinking that if we maybe standardize these things that they would be used to store and maybe share programs. Although, it would make sense that we'd also have to standardize a language or instruction set for that to work :/ Ah well...
I think it's best use right now would be in playing back animations. It seems suited for that kind of thing. I'll work on getting it work work in reverse and maybe speeding up the seek time again.
I suppose I *could* do an overhaul on the search function to include <> and add/subtract functions along with reverse and be able to make it determine which way would be faster to search and then just count out how many it needs to move? THAT would be interesting.
Upgrades:
Faster write speed!
Faster seek time for searches!
Accurate Searching!
---------------------------------------------------------------
Before I get started, I should note that I was greatly inspired by this thread here:
Compact 46 byte writable memory
by: ohmganesha
I really wanted to make a Hard Drive for Minecraft that was not only fast but searchable AND modular. This design makes it so that you could fairly easily build it out to be 16 or even 32 bits wide with some mild modification. The trick was to build it so that everything synced up properly with a minimum of delay but still be a quick as possible.
This is my Beta 2.2 unit. My first was a vertical design that was actually quite nice, but impractically large and difficult to wire. This is still incomplete as there need to be a few timing tweaks, but those will come in time.
This is the Version 2.2 unit:
This is the new SEARCH circuitry. Now it works!
Input lines and WRITE COMMIT line.
New wiring to account for a single clock source.
Output lines structured to output all 8 bits at once instead of rippling down the line.
The new Clock and counter assembly!
Here is the schematic: 8 bit horizontal HD
Tell me what you folks think!
You'll notice the RED and GLASS lines. Each row of these represents 43 bits in total. The red and glass blocks will be swapped by the WRITE heads. This is all automated, so you don't have to do anything.
To write 8 bits, all you need to do is activate whatever bits you want on the write lines and then activate the COMMIT line. The rest of it will take care of it's self.
It's not currently timed to both WRITE and RUN at the same time, so in order for it to write correctly and not botch the rotation, the unit has to be stopped. My vertical model was fast enough to write on the fly, but I ran in to an issue with this design that can crash your map!
The only way I was able to keep that from happening was to slow down the WRITE function. Apparently in this configuration, if you write too fast, the glass block "disappears" and is replaced by some kind of ghost block.... The ghost block crashes Minecraft whenever anything interacts with it. That includes any block updates that take place next to it. VERY strange... I had to use MCedit to fix the map. Note: WorldEdit did NOT fix this problem.
Also note: WorldEdit has an issue with piston placement. whenever you copy/paste anything with pistons in it, it places ALL the new pistons facing downward. This was incredibly frustrating having to go back through and replace all the pistons...
The device takes it's input from the WRITE lines on the back of the unit.
When the COMMIT line is activated, it first reads the output of the bit on the READ line (in front of the unit) It checks to see if it's the same as what you've put on the WRITE line for that bit. If they're the same - Do Nothing. If they're not the same - Swap the red/glass at the write heads.
A = READ bit
B = WRITE bit
C = Commit
if A = B AND c = 1 then WRITE = 0
if A != B AND c = 1 then WRITE = 1
if ( A = B ) OR ( A != B ) AND c = 0 then WRITE = 0
This means it writes only what you input on the WRITE lines and doesn't accidentally change a bit that you didn't want changed.
EDIT: Stupid smileys...
I would be happy to take any suggestions on how to improve this unit, OR if you wish to tinker with this one, please feel free! I think it's about as compact as it's going to get with the exception of the search logic..
I tend to favor speed over compactness most of the time, but if I can do both it makes me very happy. I'm going to remake the search unit so that it stops on the correct search bit - so expect an update to this maybe even sometime tonight.
I meant the mechanism, I got this.
Ahh, okay!
The block switcher is a 3-stage process and consists of 4 pistons. 2 sticky and 2 non-sticky. They all work from the same single power line and are timed at the ends where they meet the pistons.
It relies on a mono-stable circuit for the leading input pulse.
C::
D::
A top down view of it LIME = sticky, Dirt = non-sticky. All pistons face toward RED/GLASS.
STAGE 1: B goes first, grabbing the glass and pulling it back.
STAGE 2: Timed with 2 repeaters. First repeater closest to power gets clicked 2 times. Second repeater stays normal. C and D go next. D pushes the RED to the ON position and C grabs the glass.
STAGE 3: A is timed with 2 repeaters. First repeater closest to power gets 3 clicks. Second stays normal. A pushes the glass to where RED used to be. This completes the WRITE.
So it's: B, C&D, A. in rapid order.
I also changed the timing circuit to use one set of "perpetual" pistons. Once I have the rest of the upgraded device in working order, I'll post it up here.
EDIT:
ALSO! I'm tying everything to the main counter in order to keep the bits aligned with everything else. This way you can still run it at full speed and not lose your place on the counter.
Above is my old 2011 project that I liked, I don't play that much minecraft anymore but I occasionally help out on the Redstone forum. Hope my answers can be of help, let me know if I am unclear, and a +REP would be nice for me.
Well, *IF* we can manage to make these things fast enough, they'll be great for animations OR to store programs that people write for Minecraft computers. Anything having to deal with sequential data storage, really.
Yes, you are quite correct :smile.gif:
It is now 47 bytes.
It runs on a single clock even at full speed.
The search function works perfectly!
It's simpler and has less clutter.
Pics and schematic soon to follow.
I think it's best use right now would be in playing back animations. It seems suited for that kind of thing. I'll work on getting it work work in reverse and maybe speeding up the seek time again.
I suppose I *could* do an overhaul on the search function to include <> and add/subtract functions along with reverse and be able to make it determine which way would be faster to search and then just count out how many it needs to move? THAT would be interesting.