Minecraft Forums

I have constructed a large device designed to read a series of bits from delay line memory. The device reads from the delay line after receiving an instantaneous pulse, transferring seven (theoretically any amount) successive bits into memory cells. From here, the cells can be read and analyzed by a human operator or another mechanism. The present delay line only holds two seven-bit chunks, which is fine for a prototype but rather impractical for any actual use.

A link to my save. (NOTE: The save was made in a copy of the game with the piston mod installed. I believe I removed all of the pistons from the map (inc. inventory) before making the save, but if it does anything crashy this is probably why.)

FUTURE IMPROVEMENTS:
Automatic reading: Finding the proper N-clock to automatically record every M bits. The bits will still be kept until analyzed, but when the reset signal is sent it will wait until the clock pulse confirms the beginning of a new value in the memory.
Better storage: Using z-levels more effectively (read: at all) allows for a much greater density of memory cells, but needs a different reset mechanism. This is something I would have implemented right away in a production model, but the flat data field is more visible for the prototype.
Multiple-sequence storage: Hoo boy, not even going to think about this yet.
Delay-lane writer: Works on the same principle, but in reverse; the signal is prepared in memory cells and sent to the lane in an instantaneous pulse. This one is a bit harder because it requires a way to easily zero the memory being overwritten.

The eventual intent is to have command codes hooked up to SMP rails, providing a valuable log of who is taking which tracks in which directions, and possibly allowing the construction of a massive railway command centre. Right now, though, just redstone shenanigans.

Thoughts? Did someone already do this? Ideas?

pics would be aweeeesome, other than that, sounds trippy

Quote from Cole_blake »

pics would be aweeeesome, other than that, sounds trippy

I will post some screens tomorrow; it is midnight here and I need to sleep to stay sane.

Quote from fishsicles »

Quote from Cole_blake »

pics would be aweeeesome, other than that, sounds trippy

I will post some screens tomorrow; it is midnight here and I need to sleep to stay sane.

Haha k, I'll chceck it out tmo I guess

This sounds like a very interesting idea. Delay-line memory provides the densest possible redstone memory-storage capability known to man; the main problem is simply in reading it properly, since unlike most other aspects of redstone engineering, it cannot be held static.

I would be very interested in seeing pictures of it and in reading a more detailed description of its operation.

Would it be possible to, for example, make an 8-bit reader to that would display the information from the 1st, 2nd, 3rd, or 4th portions of a 32-bit loop of memory?

I think the biggest challenge though will be in getting the "write" operation to work smoothly, but once read and write capabilities are operational, this will be a great boon to redstone computing.

Quote from Hans Lemurson »

This sounds like a very interesting idea. Delay-line memory provides the densest possible redstone memory-storage capability known to man; the main problem is simply in reading it properly, since unlike most other aspects of redstone engineering, it cannot be held static.

I would be very interested in seeing pictures of it and in reading a more detailed description of its operation.

Would it be possible to, for example, make an 8-bit reader to that would display the information from the 1st, 2nd, 3rd, or 4th portions of a 32-bit loop of memory?

I think the biggest challenge though will be in getting the "write" operation to work smoothly, but once read and write capabilities are operational, this will be a great boon to redstone computing.

The problem with reading uniform bytes is figuring out the timing, which I have not dabbled in yet but should be pretty easy with clock generation. Hooking up a clock and counter that tells you which chunk is in the reader could be used to make RAM, but I am not going to try that until after finals. It should certainly be possible.

Also, pics.

As seen from the front (the tiny line of repeaters is my stock delay line:

As seen from the side (reader inactive):

As seen from the side (reader active):

Reader mechanism from below:

Reader mechanism from above:

Memory field:

Memory reset mechanism (should be called after the code is processed, is just a p. plate):

And last but not least, some scanned bits:


If the images need more explanation, I can write it out; maybe I will have a working writer later today?

Well, I have a working single-bit writer (schematics and pics in this post), but writing a sequence is more challenging. Right now I am trying to use one writer device to transcribe a sequence,

: Delay line repeater (starred repeater should be the regular rate minus the delay of the torches; if this is 0, give it the same delay as other line repeaters)
: Normal repeater, marked with ^v<> for direction and 1234 for counter
: Redstone torch, always attached to a block (will be marked with ^v<> for which if there is a conflict)
: Redstone wire; * indicates the "write all" wire
: Stone with redstone wire on it
: Stone with redstone torch on it
: The input (type of bit to be written)
: Output (to/from delay line)
: Input guard (allows the device to write when off; defaults to on)
: Empty space (put whatever, so long as it does not alter the circuit)

Top layer:


:RFlower:*



Two layers below (middle layer is just the torches on the blocks, [ ] encloses the area under the above):

:RedShroom:*

(repeater v1)
[ (repeater v1)
(repeater ^1)
(repeater ^1)

]


The input guard defaults to on, so that the torches do not interfere with standard operation; when an input is received, it will be ignored unless the input guard is activated. My plans for creating a sequence reader involve constructing a monostable circuit that lasts for the length of the signal; the only real remaining problem is timing it properly. If worst comes to worst, a signal of length N could be transcribed by N bit writers in succession.

Pics of the single-bit writer: (full-size screenshots, so linked rather than [img]'d)
The bit writer:
http://minetrade.danomagnum.com/uploads ... 41Ng==.png
The bit writer with write button and pulse generator visible:
http://minetrade.danomagnum.com/uploads ... 41Nw==.png
The bit writer with input lever and memory visible:
http://minetrade.danomagnum.com/uploads ... 41Nw==.png
Memory containing a single 1:
http://minetrade.danomagnum.com/uploads ... 41Nw==.png
With write-all wire removed; rapidly sets every single bit to the input:
http://minetrade.danomagnum.com/uploads ... 41OQ==.png
The memory after breaking and replacing the write-all wire:
http://minetrade.danomagnum.com/uploads ... 41OQ==.png
After flipping the input lever and pressing the write button, the memory looks like this:
http://minetrade.danomagnum.com/uploads ... 41OQ==.png (the bit looks like it is taking up 2 slots, but this is just because I took the screenshot right as the blocks updated)

Updated save:
http://minetrade.danomagnum.com/files/245/

I've been inspired by this thread to try to see if i could get some delay-line memory working myself. I've sketched out a system that would be able to read from and write to 16 discrete half-bytes on a 64-repeater loop.

Currently the components I have working are a prototype 4-bit "Writer" which can insert a 4 bit sequence into an empty loop:

And a "bit comparer" which goes "ding" when it reads a predetermined bit sequence:

Here is a picture after it went "Ding" when it read "0101" about 1 second prior.

The bit sequence is coming off of a Linear Feedback Shift Register I implemented with repeaters and an XOR gate.

I thought you might like to know that you've inspired a fellow creator and maybe we could share some ideas for designing mechanisms. I actually had to design a brand-new XOR gate to make a reliable "bit comparer"(or whatever the proper name for that device is).

Interesting; how did you get the bit-to-sequenced-data to work properly? In all of my attempts to output a sequence from static bits, they spill over into each other and generally make a mess of the data.

Yeah, I had a lot of problems early-on with the bits bleeding into each other. I use "1011" as my standard test sequence because it contains some rapid changes and is unambiguously 4 bits long. I've found that the fastest repeater-delay you can use for reliable writing is 3 ticks. I did have a 2-tick system working for a while, but sometimes it would output "1111" instead of "1011", so I had to downgrade my speed from 0.2 seconds to 0.3 seconds per bit. Maybe on a machine more powerful than my laptop I could use 2-tick repeaters, but sometimes you just gotta sacrifice speed for accuracy.

Here's a better picture of the device:

The sections are the "Pulse Generator" and its output. By default it remains "High" until you press the button, and then it pulses "Low" for about 2 ticks. Torches don't respond to pulses shorter than 2 ticks.
While the line is High, the Writing-Torches are held low and don't do anything. When the "Disable Line" goes Low though, the Writing-Torches either turn on or stay off depending on what their Data Signal from the switches says to do. The "Write Pulse" is brief enough that the Bits take-on their data before they shift over to the next cell. It doesn't matter that the pulse is shorter than the the repeater-delay, since even the briefest flicker of a torch is enough to turn a repeater "ON".

I've been using colored wool for my devices to differentiate what component does what. Currently my color-scheme is:
For pulse-generators and "disabler" circuitry.
For Data-In and Data-Out. I should probably separate these.
For "Bitstream analysis" like that bank of XOR gates that checks for a matching sequence.
For Flip-Flops for static data storage. (When you read, you need to have something to read TO.)
The color system still needs a bit of work, but after switching away from "Dirt 'n Cobble" construction, I've never looked back. I use InvEdit as my wool-supplier.

Now as for the XOR gate I'm using, here's an image showing its components.

In Green on the left is the "Base unit" of the XOR gate. It toggles between activating one torch or the other one based on the lower input. In Pink and Blue on the right are a full XOR with the "base-unit" simply repeated on 2 levels. Combine the outputs of the two pink torches and you have XOR functionality. The think I like most about this design is its compactness, reliability, and the ability to be crammed together in dense rows. Given its small size, I've been able to construct a bank of Full-Adders that are each only 3 blocks wide...but that's getting away from the point of this thread which is "Delay-Line Memory".

My first attemt (which fialed partially):



The problem with it is that it has a too long delay line (could hold 128 bit), and it was wrote over previous data.
My second attempt was much better: Fully working! :smile.gif:


Therefore, I created a new one: It works flawlessly, and can read/write a total of 16 bits (4 words, 1 word is 4 bits). The reading part was the trickiest, but when you get the hang of it, it is actually pretty easy. Memory gates convert pulses into constant signals for reading words.

A video is coming up very soon! (today or tomorrow) :smile.gif:
ALWAYS REMEMBER: ANYTHING IS POSSIBLE WITH REDSTONE AND SOME MAGIC! <3

Nice work there! I'm glad you'd gotten it working. I have a nitpick and then a few questions.
Nitpick:
-I think that a 4-bit sequence is a "nibble". A "Word" is 16 bits. I might be wrong, but that's my understanding.
Questions:
-What are the "Write port selection" and "Read port selection" doing?
-It looks like you have a loop that's spaced out every 2 repeaters. What is this for?
-Where is the memory itself being stored? Is this the "delay line"? How is data accessed from it/written to it?
-Can you re-write sections of data? Can you write "0000" on a section that used to hold "1111"?
-What delay-setting are you using on your repeaters? it looks like 4 ticks. That's the most stable, but I've found that I can sometimes get away with 3.
-How does the clock determine which data segment can be read-from/written to? It looks like what it's doing right now is simply delivering an "enable" signal every 16 ticks (4 repeaters). How do you know if you're reading from data-segment #3? Can you choose to write to a specific segment?
-Can this design be scaled up to hold more than 4 data segments?
-Also, can it use larger data segments than 4 bits?

I look forwards to seeing your video, and hopefully some of these questions will be answered in it. You've come a LOT further with your design than I have with mine, and I hope I can learn something from your architecture.

Here's a video, where I (try to) explain how the thing works.... Maybe I'm mistanen with the words..... at least it sends 4 packs of 4 bits...


- The 2 repeaters are mirrored on the other side of the and gates; this is to read the correct word from the delay line.
- The "delay line" is the memory storage. It is surprisingly compact!
- You cannot rewrite to ie. you can rewrite a 1 over a 0, ie (0010) --> (0110) works. (0110) --> (0010) does not work. Any '1' that is in the delay line cannot be overwritten with a 0, but any 0 can be overwritten with a 1.
- I have not experimented with 3, but I'm sure it works. The problem with decreasing the number of ticks is that a 0 on the delay line does not become as long as a 1.
- The clock is 16 repeaters in total, 4 bits on the dealy line takes up 4 ticks. Therefore, it takes the same amount of time for the pulse on the clock to go around once as it takes 1 bit of data to go completely around the delay line. The clock sends a signal to one of four AND gates consecutively, and each and gate has a switch input on one and the clock input on the other. When both are activated, a signal is sent to the writing parts, which writes the input to the delay line. It is hard to explain in words, but I think the video shows it better.
- I just saw a different way of setting up the input and writing part of the memory; (saw a guy wome name I dont remember now, who is planning on building a complex minecart system with destinations and lots of cool features, blah blah blah).... Anyways, he had set up a transmitter and reciever, which I modified a bit to hold 8 bits. Now, effecively it is possible to hold 8 bits of memory. However, the reading and writing time takes much longer with a larger amount of memory. A 8 bit signal would also require each segment on the clock to be 8 repeaters (or 32 ticks, the same amount of ticks the 8 bits will take up on the delay line).
- It can also be modified to store more data segments. This would require a longer delay line, with a longer clock as well. The advantage of this is that it is possibe to hold more data, but the disadvantage is that the reading and writing process will take much longer time.

Hope this helps you in your build. I will upload the world save so you can look at the system for yourself when I get home (in 5-6 hours).

Furthermore, I would like to create a system for 1 piece of redstone wire to send information in both directions; an interesting, but challenging idea! Do you have any ideas for this?

EDIT:
World Download: http://www.mediafire.com/?b841vqa8tl1viho

Uh what does it do

Quote from TheMagicalCake »

Uh what does it do

It lets you store 16 bits into it, which you can read later :smile.gif:

I dont really understand this so can someone please tell me how the reader works?

Thanks.

Quote from CEILINGSPY1 »

I dont really understand this so can someone please tell me how the reader works?

Thanks.

I'm not very good at explaining, but I'll try:

The reader part of the system consists of a pulse, and four AND gates (one for each bit)

The pulse goes into one port on each AND gate. The bit goes into the other. The delay on the pulse between each AND gate is equal to the delay between each bit is sent. When both the pulse and a bit is sent to the AND gate, the output of the AND gate is 1; If either the pulse is off, or the bit read is a 0, the output is 0.

I hope this clarifies things.... If not, download my world and try for yourself!

All the AND gates in Nikoboro's design are acting as gates to "Enable Transmission" of a signal through them. When the switch is OFF, nothing gets through, and when the switch is ON, the signal can now pass. For writing, the gates are used to control which segment of the loop gets written to; The clock pulses at 1 of 4 positions, but only the gate which has been "Opened" will let the signal through to tell the writer to write.

I congratulate you Nikoboro on your nearly completely operational Delay-Line memory system. There's just 1 function which I think it's missing: Erasing. If you write "1111" to segment 3, you'll never be able to write anything there again. Erasing is very tricky, though, and I've been pondering how to do it. It's easy to flip a 0 to a 1, but once a repeater is ON, how do you turn it off again? My current idea is to have a section of the loop be inverted, so that any 1's you write into that section will be 0's in the main part of the loop. Getting the timing right is of course still the main problem. With delay-line memory, timing is everything!!!

It's becoming increasingly clear to me that although delay-line memory is compact, what you're really doing is trading space for time. I'm still committed to getting my system working, though. ...Any day now.

Yes, I agree. It is a difficult task to erase memory. It is very easy to overwrite a 0 with a 1, but the other way is difficult. Inverting the pulse is a good idea, but how would you know what part to write to? a 0 is then a 1, and it would only be possible to write to write a 0 over a 1. Including a two inverters in the delay line will also mean that you would have to add a repeater in the clock, which would also have to be intergrated into the read part of the design. I'm sure there are better ways of doing the read part. I have, however found a much more compact and easy way to write more bits: Check out this youtube video, and You'll see it: This guy is a genius!

If you see the sender, that IS a much better sender, which can also send 8 bits really fast!


However, having different delay lines for each segment (port) will enhance the reading speed, but take up more space. The reader sarain007 has designed is also much more compact, but I'm not srue how it would work to read the data. I am worndering to send a 1 before the 8 bits begin, so the 1 activates the reader, in stead of having to activate AND gates.

Back to the deleting part; I believe having an AND gate would enable deletion of data. using the same reference clock tells where the data is. This can be copied to the other side of the delay line (in my design), and a series of AND gates will tell which port to write to. However, a nice function was to automatically delete any data in that section (port) of the delay line just before writing new data. This would act more like a overwrite function rather than a seperate delete function.

Quote from nikobro »

If you see the sender, that IS a much better sender, which can also send 8 bits really fast!

It's similar in architecture to the "writer" that I made in orange and purple wool, except that mine triggered all the write-torches simultaneously, and this one and yours trigger then sequantially.

Quote from nikobro »

However, having different delay lines for each segment (port) will enhance the reading speed, but take up more space. The reader sarain007 has designed is also much more compact, but I'm not srue how it would work to read the data. I am worndering to send a 1 before the 8 bits begin, so the 1 activates the reader, in stead of having to activate AND gates

I was thinking over a similar system. I had the idea that I could send pulses that contain both "Address" and "Data" to different devices on the same line. The Addresses would begin with a 1 which would "wake-up" the receiving units, and then if the rest of the address matched the device's address, it would then proceed to record the data.
Something to keep in mind is that you can grab all the bits in a segment simultaneously by having each bit be read from a different part of the delay-line. If you want to look at the data 4 ticks into the "future", you just move your "looker" 1 repeater upstream.

Quote from nikobro »

Back to the deleting part; I believe having an AND gate would enable deletion of data. using the same reference clock tells where the data is. This can be copied to the other side of the delay line (in my design), and a series of AND gates will tell which port to write to. However, a nice function was to automatically delete any data in that section (port) of the delay line just before writing new data. This would act more like a overwrite function rather than a seperate delete function.

Yes, this was my idea exactly. When new data is being written to a segment, you just make sure that all the 1's get turned into 0's beforehand, and then you'll be able to write to it without problem. "Write" and "Erase" should be part of the same system.

Right now I'm trying to think how you make sure to erase ONLY the segment that you are writing to. You have to erase the whole segment, but nothing before or after. However, given the need to invert part of the loop for erasing, it will be hard to make sure that erasure is in-phase with the rest of the system. What if your erase-signal is half a bit behind? Wait! You can just put a delay on the erase signal to make sure that is stays in-phase with the rest of the system. Hmm...I think I might be able to work on my next prototype with "Over-writing" capability now...