PC Let's Make Some Hard Drives!

[Chase Brower]

So with the new 1.3.1 update, we have these amazing new logic gates. And we all know what that means... Computers!

Tons of ALU's have been built already, and i even built one of my own, as well as clocks, password gates, and even a serializer to put multiple data inputs into 1 wire (seriously sick, you should check it out at this thread), but i haven't seen much of one computer part that personally interests me, at least, the hard drive.

The idea is to be able to have, say, 8 bits of data, but have tons of memory modules to store groups of these, which can be accessed individually and displayed in some basic manner.

Whoever creates the best hard drive and posts it to this thread.... gets............. uh......... um........... bragging rights?

I'm excited to see what some people might come up with, and i've also been working on a little something of my own

 

[CometStreakTheDragon]

so basically create a bunch of 8 bit sections that can be accessed or written onto by using a multiplexer and an enable read/write function? that's What I got out of this.

 

[ManaUser]

Hard drive huh? I donno about that. Logic lamps are already RAM (or Flash Memory?)... but I do have an idea for a tape drive.

So far all I have is a looping "tape" made of water.

As you can see, it's a stack of alternating active/inactive stone. That's on a timer. When the water gets to the bottom, a water sensor (kinda hidden in that last tile of water) lets another tile of water in at the top. Obviously this whole thing is fairly slow, so that's a major downside. But the cool thing is you can make it as big as you want, without adding anything but cheap active stone and wire. To speed it up, you could run say, 8 of them in parallel, that would give you a byte of memory at a time.

I still need to add a way to actually read and write to it, which obviously is the most complicated part, but I have an idea how that'll work.

 

[Chase Brower]

Pretty interesting. To add reading and writing, to start off, you would probably want to wire the logic sensor into an AND gate which would allow you to throw in some input for writing, and reading could be as simple as switching to a digit for each 8 bits, then when the water (or air) comes through, deciding whether it is a 1 or a 0.
[doublepost=1464143216,1464142361][/doublepost]

so basically create a bunch of 8 bit sections that can be accessed or written onto by using a multiplexer and an enable read/write function? that's What I got out of this.

Pretty much.

 

[ManaUser]

Pretty interesting. To add reading and writing, to start off, you would probably want to wire the logic sensor into an AND gate which would allow you to throw in some input for writing, and reading could be as simple as switching to a digit for each 8 bits, then when the water (or air) comes through, deciding whether it is a 1 or a 0.

Pretty much what I was thinking, basically I intend to "virtualize" the the looping step, so the last bit will be held in a logic lamp where it can easily be manipulated before being "written" as water (or air) back at the top.

 

[nilepereiraa]

If this gets done, i'm pretty sure that we will be able to compete with Minecraft's Hard Drive. More space = better?

 

[ManaUser]

And it's done. Kinda.

Right now, it's "read" by a torch, and "written" by a switch, but I think that's enough for a proof of concept.
There's another switch to advance the tape one cell (as an alternative to the timer). I haven't made it any bigger yet, the current model holds only 6 bits, 5 as water/air, and one "virtual" bit, whose state is shown by the torch. Meaning that if the torch is lit, then when the tape advances, water will drop in at the top.

If anyone wants to build this, here's a tip: build all the logic gates and lamps before you connect wires to them. Otherwise they will trigger random stuff as you attach the lamps. It's really late so I think I'll leave it at that for now. Good luck.

Edit: I expanded it to 36 bits, and now I'm noticing a serious problem. It can't loop two 1 (i.e. wet) bits in a row. I don't think the length of the tape should make any difference, so this defect is probably present in the version I posted too. It doesn't seem like it should be super hard to fix, but I'm still getting the hang of logic gates.

Edit 2: Okay, it turns out I didn't need to mess with the logic gates any more after all. All I had to do to correct it was move the sensor one half cell down. In other words, referring to the picture above, the corrected version should have one more inactive stone block, just above the bottom pump, and the sensor should be on top of that.

By the way, now that I have this working to my satisfaction, can anyone offer a suggestion of something relatively simple, but interesting to hook up to this? Remember the storage size is nearly unlimited, but access time is fairly poor. Although it could easily be modified to read from a whole section of tape at a time (multiple water sensors), writing pretty much has to be at the top only.

 

[Chase Brower]

Ok, my "little something" i was working on is finally done. (Sort've, you could technically add more storage if you wanted, but mine is fully functional with 2 bytes).

It functions with 2 memory cells (which can be added to) that each store 8 bits of binary info. The switches on the left write to any open memory cells, and the switches on the right open/close their respective memory cells. I can save one number to one memory cell, close it, save memory to another memory cell, close it, and when i re-open the first memory cell, the same data is still there (Fully tested ).

I spent a LOT of time getting this to work, and it was mostly research and testing, the build itself isn't actually that big.

Theoretically, you could add on infinitely more memory cells, the only limit is the bottom of the world, as logic gates and wire seem to function no matter how far away from them you are. (My day/night detector works even when i am in ocean or dungeon, both really far away from my house).

And here we go, the wired version. (For non-apparent reasons the wire cut off in the top left, and bottom left when i took the pic, but it's there lol you can probably imagine how it is supposed to be hooked up).

You might notice some logic gates in the memory cell output that look out of place, those are just there because i needed to flip the wire color from green to red because my display input took green and yellow wires, and having 2 greens next to eachother would cause problems)
EDIT: I have AND gates in the top left that are there for no reason. I sometimes wonder about my thought process.

 

[Statue of Libroty]

I've decided to try to make a more satisfying sort of RAM. One that can theoretically support however many word lines one wishes to build.

Here's my current iteration of a single bit. I still need to improve the build quite a lot, but here it is, anyhow:

The bottom right two faulty logic gates are where the actual bit is stored. Everything else facilitates reading and writing.

Here it is with wiring. Sorry about everything being smooshed together, I tried to make this as compact as possible. Inputs come from the top left, outputs on the bottom right.

The yellow input wire acts as a "gate" of sorts. I imagine that it comes straight out of a decoder that allows one to select a specific byte to access.
The green input wire is a "data" wire. When one wishes to write data to a bit, this is where the data should go!
The red input wire is a "write enable" wire. If you just want to read and not write, leave it off. Otherwise, turn it on.

The red output wire acts as a data output. If a signal travels down from it, then the bit is high. Otherwise, the bit is low. Or, nothing was read. During a write command, it outputs the data just written to it.
The yellow output wire acts as a "ready" wire. A signal is sent through it as soon as the read or write is finished, one logic gate before the data is sent down the red wire. It lets a receiver tell the difference between "low" and "taking a while".

There's several diodes in there for seemingly no reason. That's because I don't want an issue with order of operations.

For larger systems, I'd imagine a single red "write enable" wire would be connected to every bit, while several yellow wires are connected one to a word line, and eight (probably) green "data" wires run along each bit position. Meanwhile, a single yellow output wire runs from every bit, telling the receiver to get ready to accept data, and eight red output wires run along each bit position, taking the data read from each bit out.

I've got two main problems that I want to solve with this build before I do any more with it. First, it requires every signal be sent at exactly the same time. It should be possible to accept inputs from different times with a couple transistors and an AND gate, and a more convoluted required input, but that seems a bit... silly. Secondly, there's smoke absolutely everywhere! I'm okay with it on a fundamental level, since it functions perfectly fine, but it still kind of bothers me a little.

 

[ZeroGravitas]

Good stuff going on, although a little diverse for one thread, arguably. Interesting to bounce around ideas, and better out than in.

@ManaUser pursuing a liquid logic tape drive.

@Chase Brower having dived right in and built a fully gate, 2 byte (but extendable (with a lot more wiring and space)), working storage system.

@Statue of Libroty focusing on a detailed bottom-up component design process.

How about, for a little demonstrator, storing 4 (binary coded decimal) digits, and then having them automatically read back out, say into something like @DicemanX's recent display system...? (The stage after would be creating a scrolling message board, that read in a few bytes per second, decoded to alpha numeric characters.)

I think it's good to be branching out in different directions, at this stage, seeing what kinds of storage systems are possible and how they'd work. But ultimately, I think it would be great to also have a significant push towards a collaborative (general purpose) computer project. There we'd need to also design and plan from the top down, thinking about it's instruction set and desired capabilities. Then attempt to standardize the components, have then well explained, as simple as possible, even modular. With the ultimate goal of making a user programmable machine, map download, that could be played with by others. Sorry, getting ahead of things

Anyway, it strikes me that there's an awful big loom of wires in your current build, Chase (and potential for even more still, with Statue's design). Can things be arranged in a far more compact fashion, in adjacent rows? Can the same bus be used for writing to, and reading from memory (to/from user input area)? Is this undesirable? Also, could @NiraExecuto's serial transmission be used to greatly reduce the amount of wiring, either to each byte store (or to sectors of storage areas in bigger implementations)?

And side question regarding:

the wire cut off in the top left, and bottom left when i took the pic

Does it only appear glitched in camera mode shots? (Notorious for graphical glitches.) Not in regular game view?

 

[Niranufoti]

Anyway, it strikes me that there's an awful big loom of wires in your current build, Chase (and potential for even more still, with Statue's design). Can things be arranged in a far more compact fashion, in adjacent rows? Can the same bus be used for writing to, and reading from memory (to/from user input area)? Is this undesirable? Also, could @NiraExecuto's serial transmission be used to greatly reduce the amount of wiring, either to each byte store (or to sectors of storage areas in bigger implementations)?

For reference: http://forums.terraria.org/index.php?threads/serializing-data-save-wire-space-and-nerves.43886/

Then attempt to standardize the components, have then well explained, as simple as possible, even modular.

Great to know that someone else shares my opinion of Abstract and Expandable.
I'd say we split everything up into multiple steps: First, a single one-byte storage cell with three wires: Two as a serial connection (read and write) and one to prompt a read. If data is sent directly, the current data is overwritten, if the read wire gets a signal, the current data is sent through the data wires. Then, once that is done and can be massively reproduced, a bigger memory unit can be built that listens to a memory address and then gets either new data to write or a read command. That could then be hooked up to actual processing or I/O devices - a ripple-carry adder, a Binary ↔ BCD converter and BCD ↔ Decimal display and keypad, a password-protected mainframe that reads its password from the drive when someone attempts to log in - anything anyone of us can think of. I'll give a hundred virtual internet points to the first person to implement a Brain interpreter with displays for command stream, input stream and output stream that anyone can download and use without any mods.

 

[Chase Brower]

And side question regarding:

Does it only appear glitched in camera mode shots? (Notorious for graphical glitches.) Not in regular game view?

Yeah, it's just when i use the camera. I'm kinda new to all of the computer-making area, i mainly just threw the logic gates and wiring and everything together to create something that functioned, i'll try to work on making it more compact, as my build is probably horribly space inefficient.

 

[Bahamut2001]

For non-apparent reasons the wire cut off in the top left, and bottom left when i took the pic

I believe that happened because there was no light on the wires. You can see the wires in game without light when you have them set to 'bright', but the camera doesn't seem to pick them up. Mecmod had a setting almost exactly like this and had the same problem.

 

[idkwhoiam129]

Here's what I've got for you It's a "hard drive" with a 1 byte bus, 4 different memory paths to store 4 different byte values, and both read and write functions.

Here is the whole thing (picture of the map):

Here is a single 8-bit storage cell

The whole thing is comprised of D-flip flips. Here's a single one:

Hope this is of interest to you

 

[Chase Brower]

Anyway, it strikes me that there's an awful big loom of wires in your current build, Chase (and potential for even more still, with Statue's design). Can things be arranged in a far more compact fashion, in adjacent rows?

Okay, i managed to compact it (a little bit more), but with all of my attempts i run into problems with 4 wire limits, even with using junction boxes.

Spoiler: Compacted Hard Drive (Without Wiring)

Spoiler: Compacted Hard Drive (With Wiring)

If only there were just 1 more wire color, i could collapse my output length and have all of the memory cells almost right next to each other, and probably hold nearly a kilobyte of storage without even taking up much space in the world. (Each memory cell is now only 6 blocks tall).

Also, could @NiraExecuto's serial transmission be used to greatly reduce the amount of wiring, either to each byte store (or to sectors of storage areas in bigger implementations)?

Yeah, i'm going to be spending some time looking into that. If i can get a good understanding of it, maybe i could use it to, like you said, significantly reduce the amount of wires, therefore compacting the drive.
[doublepost=1464482133,1464481512][/doublepost]

Here's what I've got for you It's a "hard drive" with an 8 bit bus, 4 different components to store 4 different 8 bit values, and both read and write functions.

Here is the whole thing (picture of the map):

Here is a single 8-bit storage cell

The whole thing is comprised of D-flip flips. Here's a single one:

Hope this is of interest to you

Personally i find it interesting. All mine is is 2 AND gates tied to eachother to store data for each bit. You've got an actual d-flip-flop for yours! XD

 

[idkwhoiam129]

Personally i find it interesting. All mine is is 2 AND gates tied to eachother to store data for each bit. You've got an actual d-flip-flop for yours, lol

They might be different in functionality.. Is yours able to write and read for each bit? It has to write the current state of the input, but also, after it is saved, be able to retrieve it from the output..
Unless you're doing it a different way that I'm unaware of... I'm unaware of another way you could store/read/write bit memory without a D flip flop.

Here' I made a quick video to try to show what mine does:

 

[Chase Brower]

They might be different in functionality.. Is yours able to write and read for each bit? It has to write the current state of the input, but also, after it is saved, be able to retrieve it from the output..
Unless you're doing it a different way that I'm unaware of... I'm unaware of another way you could store/read/write bit memory without a D flip flop.

Here' I made a quick video to try to show what mine does:

Through the new discovery of the transistor (any gate with on lamp on top of it, then faulty lamp on top of that) i was able to create my drive using just the and gate, because the transistor functions a little bit odd, and simulates a flip-flop mechanism without having to actually create the system. There are several threads on the T-MEC forums talking about these new transistors. And yes, i can store/read/write individually to different memory cells, and read/write while still having data stored on all of my memory cells

 

[idkwhoiam129]

Through the new discovery of the transistor (any gate with on lamp on top of it, then faulty lamp on top of that) i was able to create my drive using just the and gate, because the transistor functions a little bit odd, and simulates a flip-flop mechanism without having to actually create the system. There are several threads on the T-MEC forums talking about these new transistors. And yes, i can store/read/write individually to different memory cells, and read/write while still having data stored on all of my memory cells

I thought the transistor thing acted as a T flip flop and not a D flip flop though. At least to my findings.

 

[Niranufoti]

I thought the transistor thing acted as a T flip flop and not a D flip flop though. At least to my findings.

The transistor doesn't need to act like a flip-flop at all - it only does when a single input connects both the "base" (regular lamp) and the "emitter" (faulty lamp), in which case it's a T-flip-fllop. But without that, it can simply act as a switch.
I'd build a memory cell with two (or maybe three) transistors, as I did in my serialization concept: the cell's state is stored in the transistors' bases. One transistor resets the cell by connecting its output to the input wire, the other is used to check the cell's state. An optional third transistor could be added that's triggered when the read transistor is, but with an inverted base, i.e. "if the cell is not set".

 

[ninjofes]

We now have readable memory! You guys are amazing.

This might not be the best thread to post in. I'm posting this anyway.

Now: screens and displays!
It would be amazing if we could store a register of characters (end goal, copy 0-127 of unicode?) and map them onto a screen using some sort of read-only drive with characters stored inside.
A problem comes quickly; the data required to transport the signal to this screen would be huge and awkward to carry across large distances.

Even if we were to use 'blocks' for each character as small as 8x8, we would need 64 wires to carry the mapping from the read-only memory to the display.
If we were to stack wires, this large wire would still be 32 blocks thick, unless we build some sort of timing load-unload thing (gaps in time between signals, either one length or another for every pixel on the screen?), which could be done across a single wire (although for now, I'm not even going to try building one [EDIT: I might have to]).

Edit, thanks to NiraExecuto who has built a transmission system using one wire for any amount of signal, I will be using to use 8 wires per 'block'/character.

A second problem, how do we build this screen?

In real life, our screens are two dimensional, with the data flowing in from the behind, in the third dimension. In three-dimensional games like minecraft, this can be easy enough to recreate.

However, Terraria is far less three-dimensional. The transparency of wires and the presence of multiple colours help, however a large two-dimensional screen would require massive amounts of signal travelling through every part of the screen.
If someone could make such a screen, I'd be astounded.

We should instead try to use a one-dimensional screen.

Yes, it sounds boring. But then I realised that there are four colours of wire, each of which could form a row in the second dimension.
On top of this, there can be both a top and bottom input section, increasing the height to 8.
Granted enough space between 8x8 'Blocks', we could make it a proper 2D screen,
although for now, an 8-pixel thick screen, longer across the other dimension using a load-unload system involving timing seems to be the way to go.

Edit: ZeroGravitas suggested using junction boxes to modify the display, this could make it smaller. However, this would also make it look less pretty, we'll see how it goes.

Should be able to use junction boxes to duct adjacent wiring of the same colors, compress it a bit, yeah.

Here's a sneak peek at my current screen, as a mini-upadate while I work on the character loading system. I recommend this as an 8x8 display.

Spoiler: My Display

Now, to build "this" in-game. I'll give an update if I work something out.