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.
I have created a address (the first two bits of the input memory), which decides which delay line to write to. (choice of four delay lines). Its in the save file.
Right now I'm trying to think how you make sure to erase ONLY the segment that you are writing to.
I am able to delete only one segment, but the problem is that it messes up the reading. An AND gate in the middle of the delay line acts as a deletion gate, and deletes as the writer is writing the new data. However, it is very buggy, and often messes up the time pulses on the delay line itself. This must be dealt with. Underneath the delay loop (if you follow the stairs down, there is a pulse lenghtener, which can be tweeked and fiddled with so that the delete port on the AND gate is only on for exactly 16 ticks! However, i still have some problems with the reading.
I was inspired by your method where you trigger the bit-inputs in sequence (my design did it simultaneously), since I think doing it that way might allow me to use 2-tick repeaters rather than the slower (but more stable) 3-tick ones. The utility of delay-line memory depends on speed of access.
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
I am able to delete only one segment, but the problem is that it messes up the reading. An AND gate in the middle of the delay line acts as a deletion gate, and deletes as the writer is writing the new data. However, it is very buggy, and often messes up the time pulses on the delay line itself. This must be dealt with. Underneath the delay loop (if you follow the stairs down, there is a pulse lenghtener, which can be tweeked and fiddled with so that the delete port on the AND gate is only on for exactly 16 ticks! However, i still have some problems with the reading.
You're right! Adding in a "deletion" unit can mess up the data, since torches don't play nicely with short pulses. Torches will often "clip" pulses so that the output isn't the same as the input. So long as your pulses are at least 4 ticks long though, there's not much of an issue with that. The main problem I'm having is that I'm trying to get my system to work with 3-tick repeaters.
A trick that has worked for me for minimizing data corruption is to have a "full delay" repeater come after each torch. This way, shortened pulses get re-lengthened to the delay-setting of the repeater. This works because repeaters respond differently to "On" signals than to "off" signals. A repeater will turn on from a brief flicker from a torch, but requires the full time off before it turns off.
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
After much frustration, I have concluded that it is currently impossible to build a memory-loop that has a "delete" function. You can't delete without sending the memory loop through torches, and you can't send pulses through torches without slowly corrupting your data.
Memory loops will therefore be of limited utility, since although segments can be written to when blank, they cannot be reliably re-written, and once a memory loop is full, the loop must me manually broken in order to erase it.
With pistons though, it should be possible to use their block-moving ability to temporarily break a signal loop (removing a block that a repeater is pointing into) and use this as the "delete" function. It will be an amusing way to incorporate mechanical parts into an otherwise solid-state device. Also possible with pistons is the creation of space-efficient ROM "Punch-cards" out of stone and glass to store program data.
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
After much frustration, I have concluded that it is currently impossible to build a memory-loop that has a "delete" function. You can't delete without sending the memory loop through torches, and you can't send pulses through torches without slowly corrupting your data.
Memory loops will therefore be of limited utility, since although segments can be written to when blank, they cannot be reliably re-written, and once a memory loop is full, the loop must me manually broken in order to erase it.
With pistons though, it should be possible to use their block-moving ability to temporarily break a signal loop (removing a block that a repeater is pointing into) and use this as the "delete" function. It will be an amusing way to incorporate mechanical parts into an otherwise solid-state device. Also possible with pistons is the creation of space-efficient ROM "Punch-cards" out of stone and glass to store program data.
I have been thinking about the pistons that are coming out (hopefully soon). Having repeaters sending signals through pistons is a great way to delete data, as the data does not have to pass through any torches to be deleted. However, there cannot be any delay for the piston to extend and retract, as this may corrupt the data.
An possible alternative to pistons is the new trap doors. I have not tested to see whether they allow a current to pass through them when they are up as well as when they are down. However, I think they do. If they dont though, we effectively have a a block with the same function as a piston, only more compact.
I have had very little progress on the programmable ticker, and have still not figured out how to write to different delay line memories for different areas on the screen in a reliable way.
Punch cards is another great idea, where the piston can send a 1 or a 0. I am not that familiar with ROM, but have a basic idea of how it works, just not how to build one.
I foresee use of pistons in the sending system as well, for a more compact sender. I think I'll wait until pistons are part of the actual game rather than installing it as a mod. :wink.gif:
I have been thinking about the pistons that are coming out (hopefully soon). Having repeaters sending signals through pistons is a great way to delete data, as the data does not have to pass through any torches to be deleted. However, there cannot be any delay for the piston to extend and retract, as this may corrupt the data.
An possible alternative to pistons is the new trap doors. I have not tested to see whether they allow a current to pass through them when they are up as well as when they are down. However, I think they do. If they dont though, we effectively have a a block with the same function as a piston, only more compact.
I have had very little progress on the programmable ticker, and have still not figured out how to write to different delay line memories for different areas on the screen in a reliable way.
Punch cards is another great idea, where the piston can send a 1 or a 0. I am not that familiar with ROM, but have a basic idea of how it works, just not how to build one.
I foresee use of pistons in the sending system as well, for a more compact sender. I think I'll wait until pistons are part of the actual game rather than installing it as a mod. :wink.gif:
It doesn't matter that the pistons have delay in extending/retracting, so long as the time it takes to do so is constant. Even if it varies a little bit, we're still mostly ok, since data will only be in danger of being corrupted when you attempt to delete a section, as opposed to every single cycle. Given that it took something like 50 passes for corruption to become noticeable, I think we should be ok. The biggest advantage will be that the system isn't being constantly exposed to the random torch updates.
Trap doors I sincerely doubt would work. 2 reasons, firstly I think they won't conduct redstone charge at all similar to how glass doesn't. Secondly the redstone signals we'd be hoping to interrupt will themselves cause the trap door to open and close.
Let me clarify what I was talking about with "ROM" and "Punch-cards". ROM stands for Read-Only-Memory, something which will contain data, but cannot itself be modified by the system. Punchcards ARE a form of ROM. Placing torches over wires is another form of ROM used in most 7-segment decoders and for the program memory of one computer I saw.
Your comment about the difficulty on precision-writing for the Ticker made me realize that I still haven't completed the timing portion of my delay-line system. That's going to be my next project. I had become disheartened when I realized that you couldn't delete data, and went to work on other stuff for a while, but I think that this would be a good challenge.
My plan is to implement a "Linear Feedback Shift Register" with repeaters which will produce a steady 15 bit repeating pattern that can be used to provide unique addresses for 15 memory segments. http://en.wikipedia.org/wiki/Linear_feedback_shift_register
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
Interesting. Good to see that there are other people working on this challenge too.
I have a few questions:
-I assume the massive device in the background is NOT the delay-line memory unit?
-Where is the data itself actually stored?
-Why so many edge-triggers?
-How much memory does this device store? 4 bits, or Four 4-bit segments? I'm unclear on this.
-What do you mean by "each storage segment takes as many ticks to respond as many bits it can hold"? Does this mean that your memory-loops are using 1-tick repeaters to store their data? I didn't think it was possible to do that stably.
-How are the memory-loops arranged? Is it One 16 bit loop, or Four 4-bit loops?
It's clear that you've put a lot of work into this, and I really do appreciate how difficult designing time-sensitive redstone systems are, but I'm having a little trouble understanding exactly what you did here, and won't be able to give you good feedback until then.
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
i've never tried to work with delay line memory. mainly because i see it as making red stones greatest weakness (it is really, REALLY slow) even worse.
compared to an array of flip flops, it has the added disadvantage of not retaining the data after you close the game. this means you would have to re-enter the data every time you load the world.
i'm sorry to say, but i don't see delay line memory replacing flip flops/levers/torches as a memory storage medium any time soon.
but i would still say congrats to anyone who got one fully working. :biggrin.gif:
@karm_beat
I think I understand how your device is working. Many parts of it I believe could be made vastly more compact. Have you looked at some of the pictures earlier in this thread? I think that my "writing unit" rendered in purple and orange wool could be used directly in your design. It uses just 1 edge-detector to control all 4 bits of input.
Though actually, that brings up another important question: The 4 bits that are stored in the loop, are they all part of the same piece of data, or are they each 1 bit from 4 different pieces of data?
If it's the latter, then my suggestion on compaction won't quite work. Instead, I'll simply have to point out that since the data is continuously cycling, you don't have to be able to write to each segment of the loop individually, so your data input mechanism could be considerably smaller. Also, I've found that you can actually reduce the delay on the repeaters to 3 ticks each without compromising their ability to store data reliably, and it speeds up the entire system.
@Salaja
Everything you say about Delay-Line memory is completely valid. They trade space for time in an environment where Time is the most valuable resource. Their other two crippling weaknesses are that they can't over-write data that they hold, and most importantly, LOSE THEIR DATA UPON EXITING MINECRAFT.
However, I find the concept intruiging, and I'm doing my best to try to think of ways to make their memory faster and more compact. I currently have a 7-byte system sketched out that would have a 2.1 second cycle-time for the data and be considerably smaller than 56 D Flip-Flops. Not nearly as fast, though, but larger devices do have some inherent slowness to them.
Another thing that this delay-line memory research is "useful" for is sending packets of data down a single line of wire, but that's again with the speed/size trade-off.
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
I see. First you need a "proof of concept" device before you can go about refining it. No point in refining something that's impossible.
The challenge that I'm working on right now is selecting specific data segments for reading/writing. I'm using a Linear Feedback Shift Register for my "counter", but I'm having a bit of trouble with getting the reading device to recognize that the proper segment of the loop has come up. XOR gates don't like rapidly changing inputs.
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
I'll try to see if I can get a good picture of my device up tomorrow. The only truly working part I have is the ability to write 4-bit inputs and have them cycle in a 28 bit loop. I've been testing components and just recently had a setback with the "deletion" unit I was trying to add. It can also grab a segment of 4 bits and store them in some D-Latches that will make my output, but nothing is synchronized yet and must depend on my reflexes.
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
I made a new design for 8bit per level multi-story memory bank. Writing and reading 1 high current (1 out of 8 repeaters on) gives the right answer. When I try more happens this: 01010000 gives 01110000 when read, whereas 01001000 gives the right 01001000 answer. Currently trying to find a solution, but quite out of ideas. Might have to make a new design.
Bits "bleeding" into each other is a big problem. What you need to do to avoid this is to make your "write pulse" as brief as possible. A 4-tick repeater will produce a 4-tick pulse even if its input was only a 2-tick flash.
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
My last test has proven that using my design I can't be 100% sure that stored data will be output right. I know a solution, but it would slow down my system very much and defeat the point of it. If you could tell me how to stop signals bleeding into eachother, I could give you back a working compact memory bank using delay-line memory. Edge trigger didn't help, so I'm out of ideas.
What you need to do is have all of the inputs controlled by a single pulse-generator, and make the input-torches flash as briefly as possible when stimulating the repeaters. I think I may have to make a video on the subject to properly explain what I mean.
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
My last test has proven that using my design I can't be 100% sure that stored data will be output right. I know a solution, but it would slow down my system very much and defeat the point of it. If you could tell me how to stop signals bleeding into eachother, I could give you back a working compact memory bank using delay-line memory. Edge trigger didn't help, so I'm out of ideas.
I also tried to build a similar design to yours, with the read and write protions of the memory unit in the same area. However, I got the same problem with bits bleeding into each other, and I think the design would have to have the separation of the bits done at the clock of the AND gates, rather than in the line itself.
Hans Lemurson states: "make the input-torches flash as briefly as possible when stimulating the repeaters", and is right. A repeater can make a pulse longer, but it cannot make it shorter. Therefore, to be on the safe side, all input signals should be shorter than the delay line repeaters.
In solving a separate and related problem i have a solution to having reliable and rewritable delay line memory. I've only followed this thead and delay line memory development loosely. So before i go all out and type up a lengthy post no-one has reliable rewritable memory yet, right?
Correct, my attempts to make the delay-line memory "Re-Writeable" have resulted in unacceptable degradation of the data due to the influence of torches. It works, and can write and write and over-write data without problem, but the torches that the signal must pass through to allow deletion result in data segments becoming randomly truncated over time.
Have you found a way to delete/over-write data in a repeater-loop without it passing through torches?
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
Looking at Jeb's implementation of pistons, I was impressed by how quickly and reliably they operated, much better than the piston-mod!
This means that pistons will be a viable tool for implementing a "delete" function in Repeater-Loop memory, and may even be able to replace Torches in many timing-sensitive applications.
I think that semi-mechanical computers may become possible and even practical.
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
Here we go. Sorry i took my time. I decided to increase the capacity of the memory so i could include the neccesary adjustments to the addressing part of the circuit of an non-rewritable one.
16bit - 4bit words.
Overhead view:
...
The overwriting works by essentially diconnecting the head and the tail of the delay line overlapping them and mux-ing between writing the input or the tail of the memory onto the head. This way, the delay line has at most only 1 torch (that is unshared and of timing importance) inserted into it. Even still, there are measures taken in the circuit to nullify the timing inaccuaracy of that torch and of the shared torches.
...
The memory and integrity of the delay line can be visualised on a per redstone tick basis on the string of 1RT repeaters
This has been built on SSP and SMP. I haven't seen the memory corrupt unless /time commands are used. By increasing the length of each data bit so there is more 'padding' between the edges and the center of the bit, further stability may be achieved.
Very impressive, sir! I hadn't thought implementing over-writing/deletion by actually RE-WRITING THE ENTIRE SIGNAL every cycle. I suppose that if your writer is precise enough in the first place, that it should be able to re write without too much difficulty. Maybe. I'm still a little incredulous about this given my own experiences with data corruption.
Your pulse-lengthener in part 13 is something I hadn't thought of. First you're making sure that the 1's are exactly 3 ticks long, and then you re-lengthen them to 4 ticks. I can't help but feel though that this won't work quite as intended for signals with two 1's in a row.
1101 has been my default "test sequence" since it contains both rapid changes AND sustained 1's, which are the two areas where the data tends to get corrupted. Whereas 0100 can easily have the pulse-length of its 1 repaired after any clipping, 0110 will be much more resistant to this, since the pulse-width of the 1's is now greater than the delay-time of the repeaters making length-restoration a little dodgy.
What sequences have you tested for stability, and how long have you tested it for? Have you tested the integrity of multiple adjacent words? You said that the /time commands will corrupt the memory, do Dawn and Dusk have similar effects? What sort of corruption occurs? What happens if there are a bunch of other redstone components nearby increasing the system load?
I don't mean to rag on your system though. I recognize how much effort went into designing this system, and I'm truly impressed by your ability to synchronize so many different timing-cycles and integrate them into a coherent whole. Also, I never thought of re-writing each word!
I'll give your system some study.
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
In pursuit of solving the problem of corruption i neglected to test the device as a whole and i've discovered it can't write two adjacent 1's across words. This is becuase of repeaters being unable to react to a 1 RT ON pulse that immediately follows a 1 RT OFF pulse. Why? I'm not quite sure. This can be solved by extending the length of the repeaters in pulse generators #8 and #9 to being 4 RT long. This will make the pulse outputed by the writing torches 3RT long (previously 1RT); long enough so that the repeaters can catch it.
Interestingly, even simluators exhibit this problem too.
[edit] Ah ha of course! The reason is becuase block updates cannot be stacked. So whether the repeater is due to turn on or off at some time what happens to it's input before then is irrelevant.
So, in this case, since these repeaters concerned are set to 3 ticks, an 1 OFF then an 1 ON pulse happens entirely within the duration the repeater is scheduled to turn off. By setting the ON pulse to be 3 long the repeater will read it's input as on in the tick is is due to turn off, the 6th RT. In the 7th tick it's input will have reverted back to off. This is precisely what happens when a string of 1's occur together within a word. No problem was seen to occur (when the input pulses were still 1RT long) becuase the repeater resposible for the left-most 1 will naturally extend the 1 RT ON pulse to 3 RT for the repeater receiving the second left-most 1. No such repeater exists for 1's occurring across a word.
Fascinating. You really have a much deeper understanding of the timing-mechanics of Redstone than I do. I understand how it behaves empirically, but you seem to understand the theory behind it.
With the changes you've made, does it work properly in all situations now?
Also I have a question: Why are you using repeaters for parts 10 and 11 rather than having the writing-torches controlled by 1 wire running over the tops of their blocks? Does timing work better that way?
Rollback Post to RevisionRollBack
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
I have created a address (the first two bits of the input memory), which decides which delay line to write to. (choice of four delay lines). Its in the save file.
I am able to delete only one segment, but the problem is that it messes up the reading. An AND gate in the middle of the delay line acts as a deletion gate, and deletes as the writer is writing the new data. However, it is very buggy, and often messes up the time pulses on the delay line itself. This must be dealt with. Underneath the delay loop (if you follow the stairs down, there is a pulse lenghtener, which can be tweeked and fiddled with so that the delete port on the AND gate is only on for exactly 16 ticks! However, i still have some problems with the reading.
World Download: http://www.mediafire.com/?upkhb435q3dscdj
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
You're right! Adding in a "deletion" unit can mess up the data, since torches don't play nicely with short pulses. Torches will often "clip" pulses so that the output isn't the same as the input. So long as your pulses are at least 4 ticks long though, there's not much of an issue with that. The main problem I'm having is that I'm trying to get my system to work with 3-tick repeaters.
A trick that has worked for me for minimizing data corruption is to have a "full delay" repeater come after each torch. This way, shortened pulses get re-lengthened to the delay-setting of the repeater. This works because repeaters respond differently to "On" signals than to "off" signals. A repeater will turn on from a brief flicker from a torch, but requires the full time off before it turns off.
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
Memory loops will therefore be of limited utility, since although segments can be written to when blank, they cannot be reliably re-written, and once a memory loop is full, the loop must me manually broken in order to erase it.
With pistons though, it should be possible to use their block-moving ability to temporarily break a signal loop (removing a block that a repeater is pointing into) and use this as the "delete" function. It will be an amusing way to incorporate mechanical parts into an otherwise solid-state device. Also possible with pistons is the creation of space-efficient ROM "Punch-cards" out of stone and glass to store program data.
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
I have been thinking about the pistons that are coming out (hopefully soon). Having repeaters sending signals through pistons is a great way to delete data, as the data does not have to pass through any torches to be deleted. However, there cannot be any delay for the piston to extend and retract, as this may corrupt the data.
An possible alternative to pistons is the new trap doors. I have not tested to see whether they allow a current to pass through them when they are up as well as when they are down. However, I think they do. If they dont though, we effectively have a a block with the same function as a piston, only more compact.
I have had very little progress on the programmable ticker, and have still not figured out how to write to different delay line memories for different areas on the screen in a reliable way.
Punch cards is another great idea, where the piston can send a 1 or a 0. I am not that familiar with ROM, but have a basic idea of how it works, just not how to build one.
I foresee use of pistons in the sending system as well, for a more compact sender. I think I'll wait until pistons are part of the actual game rather than installing it as a mod. :wink.gif:
It doesn't matter that the pistons have delay in extending/retracting, so long as the time it takes to do so is constant. Even if it varies a little bit, we're still mostly ok, since data will only be in danger of being corrupted when you attempt to delete a section, as opposed to every single cycle. Given that it took something like 50 passes for corruption to become noticeable, I think we should be ok. The biggest advantage will be that the system isn't being constantly exposed to the random torch updates.
Trap doors I sincerely doubt would work. 2 reasons, firstly I think they won't conduct redstone charge at all similar to how glass doesn't. Secondly the redstone signals we'd be hoping to interrupt will themselves cause the trap door to open and close.
Let me clarify what I was talking about with "ROM" and "Punch-cards". ROM stands for Read-Only-Memory, something which will contain data, but cannot itself be modified by the system. Punchcards ARE a form of ROM. Placing torches over wires is another form of ROM used in most 7-segment decoders and for the program memory of one computer I saw.
Your comment about the difficulty on precision-writing for the Ticker made me realize that I still haven't completed the timing portion of my delay-line system. That's going to be my next project. I had become disheartened when I realized that you couldn't delete data, and went to work on other stuff for a while, but I think that this would be a good challenge.
My plan is to implement a "Linear Feedback Shift Register" with repeaters which will produce a steady 15 bit repeating pattern that can be used to provide unique addresses for 15 memory segments. http://en.wikipedia.org/wiki/Linear_feedback_shift_register
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
I have a few questions:
-I assume the massive device in the background is NOT the delay-line memory unit?
-Where is the data itself actually stored?
-Why so many edge-triggers?
-How much memory does this device store? 4 bits, or Four 4-bit segments? I'm unclear on this.
-What do you mean by "each storage segment takes as many ticks to respond as many bits it can hold"? Does this mean that your memory-loops are using 1-tick repeaters to store their data? I didn't think it was possible to do that stably.
-How are the memory-loops arranged? Is it One 16 bit loop, or Four 4-bit loops?
It's clear that you've put a lot of work into this, and I really do appreciate how difficult designing time-sensitive redstone systems are, but I'm having a little trouble understanding exactly what you did here, and won't be able to give you good feedback until then.
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
compared to an array of flip flops, it has the added disadvantage of not retaining the data after you close the game. this means you would have to re-enter the data every time you load the world.
i'm sorry to say, but i don't see delay line memory replacing flip flops/levers/torches as a memory storage medium any time soon.
but i would still say congrats to anyone who got one fully working. :biggrin.gif:
I think I understand how your device is working. Many parts of it I believe could be made vastly more compact. Have you looked at some of the pictures earlier in this thread? I think that my "writing unit" rendered in purple and orange wool could be used directly in your design. It uses just 1 edge-detector to control all 4 bits of input.
Though actually, that brings up another important question: The 4 bits that are stored in the loop, are they all part of the same piece of data, or are they each 1 bit from 4 different pieces of data?
If it's the latter, then my suggestion on compaction won't quite work. Instead, I'll simply have to point out that since the data is continuously cycling, you don't have to be able to write to each segment of the loop individually, so your data input mechanism could be considerably smaller. Also, I've found that you can actually reduce the delay on the repeaters to 3 ticks each without compromising their ability to store data reliably, and it speeds up the entire system.
@Salaja
Everything you say about Delay-Line memory is completely valid. They trade space for time in an environment where Time is the most valuable resource. Their other two crippling weaknesses are that they can't over-write data that they hold, and most importantly, LOSE THEIR DATA UPON EXITING MINECRAFT.
However, I find the concept intruiging, and I'm doing my best to try to think of ways to make their memory faster and more compact. I currently have a 7-byte system sketched out that would have a 2.1 second cycle-time for the data and be considerably smaller than 56 D Flip-Flops. Not nearly as fast, though, but larger devices do have some inherent slowness to them.
Another thing that this delay-line memory research is "useful" for is sending packets of data down a single line of wire, but that's again with the speed/size trade-off.
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
The challenge that I'm working on right now is selecting specific data segments for reading/writing. I'm using a Linear Feedback Shift Register for my "counter", but I'm having a bit of trouble with getting the reading device to recognize that the proper segment of the loop has come up. XOR gates don't like rapidly changing inputs.
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
Bits "bleeding" into each other is a big problem. What you need to do to avoid this is to make your "write pulse" as brief as possible. A 4-tick repeater will produce a 4-tick pulse even if its input was only a 2-tick flash.
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
What you need to do is have all of the inputs controlled by a single pulse-generator, and make the input-torches flash as briefly as possible when stimulating the repeaters. I think I may have to make a video on the subject to properly explain what I mean.
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
I also tried to build a similar design to yours, with the read and write protions of the memory unit in the same area. However, I got the same problem with bits bleeding into each other, and I think the design would have to have the separation of the bits done at the clock of the AND gates, rather than in the line itself.
Hans Lemurson states: "make the input-torches flash as briefly as possible when stimulating the repeaters", and is right. A repeater can make a pulse longer, but it cannot make it shorter. Therefore, to be on the safe side, all input signals should be shorter than the delay line repeaters.
Correct, my attempts to make the delay-line memory "Re-Writeable" have resulted in unacceptable degradation of the data due to the influence of torches. It works, and can write and write and over-write data without problem, but the torches that the signal must pass through to allow deletion result in data segments becoming randomly truncated over time.
Have you found a way to delete/over-write data in a repeater-loop without it passing through torches?
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
This means that pistons will be a viable tool for implementing a "delete" function in Repeater-Loop memory, and may even be able to replace Torches in many timing-sensitive applications.
I think that semi-mechanical computers may become possible and even practical.
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
Very impressive, sir! I hadn't thought implementing over-writing/deletion by actually RE-WRITING THE ENTIRE SIGNAL every cycle. I suppose that if your writer is precise enough in the first place, that it should be able to re write without too much difficulty. Maybe. I'm still a little incredulous about this given my own experiences with data corruption.
Your pulse-lengthener in part 13 is something I hadn't thought of. First you're making sure that the 1's are exactly 3 ticks long, and then you re-lengthen them to 4 ticks. I can't help but feel though that this won't work quite as intended for signals with two 1's in a row.
1101 has been my default "test sequence" since it contains both rapid changes AND sustained 1's, which are the two areas where the data tends to get corrupted. Whereas 0100 can easily have the pulse-length of its 1 repaired after any clipping, 0110 will be much more resistant to this, since the pulse-width of the 1's is now greater than the delay-time of the repeaters making length-restoration a little dodgy.
What sequences have you tested for stability, and how long have you tested it for? Have you tested the integrity of multiple adjacent words? You said that the /time commands will corrupt the memory, do Dawn and Dusk have similar effects? What sort of corruption occurs? What happens if there are a bunch of other redstone components nearby increasing the system load?
I don't mean to rag on your system though. I recognize how much effort went into designing this system, and I'm truly impressed by your ability to synchronize so many different timing-cycles and integrate them into a coherent whole. Also, I never thought of re-writing each word!
I'll give your system some study.
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
Fascinating. You really have a much deeper understanding of the timing-mechanics of Redstone than I do. I understand how it behaves empirically, but you seem to understand the theory behind it.
With the changes you've made, does it work properly in all situations now?
Also I have a question: Why are you using repeaters for parts 10 and 11 rather than having the writing-torches controlled by 1 wire running over the tops of their blocks? Does timing work better that way?
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.