Nice thread, im probably going to make something like this.
Also, a system ive tested out on my test file, with a master reset switch which activate when you are coming in, and should no station be chosen you will be returned to the stop.
Gj on explaining this idea.
Rollback Post to RevisionRollBack
Quote from house »
"You talk to God, you’re religious. God talks to you — you’re psychotic."
This is how I connected my buttons so that they were really close together:
Button: Stone: Redstone torch: redstone:
From above:
[]
[]
Side:
And to get things to travel down nicely:
[]
[]
[]
If you have multiple signals next to each other going down, just have every second one facing the other way. I'll get some pictures from the game soon so that you can see what I mean.
Right. My question is how to get a signal to the turned-around torches in a limited amount of space. You can certainly do it without widening the button array if you have at least 4 meters of space behind the buttons to work with, allowing you to simply run every other wire across to the far side of your vertical signal path, drop down, and turn around to come at it from that side. The direct ones have to drop down some as well and have an inverter added. I'll try to depict this the same way you did.
Odd buttons:
[]
[]
[] [] []
[]
[]
Even buttons:
[] [] []
[] [] []
[]
[]
[]
If you need indicator lights coming back up, it'll take at least 6 meters instead of 4. (Since my design used switches, I didn't have to worry about that.) Now that I think about it, it wouldn't have required THAT much more space than what I used... But it still wouldn't have fit without expanding my building. XD
Also, in case you haven't seen it already, this thread has a lot of good design info regarding compact arrangements of buttons and redstone logic that may be of use: viewtopic.php?f=35&t=60816
Right. My question is how to get a signal to the turned-around torches in a limited amount of space. You can certainly do it without widening the button array if you have at least 4 meters of space behind the buttons to work with, allowing you to simply run every other wire across to the far side of your vertical signal path, drop down, and turn around to come at it from that side. The direct ones have to drop down some as well and have an inverter added. I'll try to depict this the same way you did.
Oh okay. Well, I guess that the way in that other thread (which is really cool, thanks) looks pretty space efficient around the buttons. Otherwise, I suppose it could be done like this, if you don't mind the buttons not being in a straight line:
[...] I suppose it could be done like this, if you don't mind the buttons not being in a straight line:
Odd buttons:
[]
[]
[] []
[] [] []
[] []
Even buttons:
[]
[] []
[] []
[] [] []
[] []
That's a good functional setup. But I was trying to avoid having anything staggered. I wanted to combine functional with aesthetically pleasing. And that requires more room, it seems. :smile.gif:
I checked out your video (nicely done, by the way) and save file (20 MB for a <7MB save? Turns out you have a ton of SVN files in that download!). I was trying to figure out how you implemented the encoder and memory under each set of buttons, but... it was just too tightly packed and hard to move around in.
Any chance you could describe or diagram how that part works? I'm trying to come up with an encoder that's upwardly scalable, but what I have so far is very space-intensive: About 8 by N by 4*Log2(N) X, Y, Z dimensions... just for the encoder part.
Any chance you could describe or diagram how that part works? I'm trying to come up with an encoder that's upwardly scalable, but what I have so far is very space-intensive: About 8 by N by 4*Log2(N) X, Y, Z dimensions... just for the encoder part.
Assuming parallel horizontal inputs offset by one vertical space, my current encoder is N wide by 5*Log2(N) by 4 high. Output lines are spaced 5 apart along the top of the encoder, perpendicular to the input lines. It's meant to be tacked on to the back of my button array. There's probably something better out there.
I'll check out the1laz's before posting anything. (Thanks for posting the save!)
edit: another option that just occurred to me is N wide by 4Log2(N) by 5 high. I think I prefer that.
xgkkp wrote :
> Though after digging six channels under my track for two-way 8-station
> selection, I'm starting to wonder if it might be more redstone and
> space-efficient to transmit the data serially - you can safely flash
> torches on and off much faster than a minecart can travel over long
> distances (you would definitely have to stick to a repeating station within
> the chunk limits though, limited tests indicated absolute maximum 12
> chunks=192 blocks) and I can easily imagine one or two less wires is more
> than enough redstone to cover the cost for
> memory+clocks+shifters+(syncers?). Space might be a problem, but it's not
> like space is limited or anything, especially on a large, spread out
> server. On the other hand I could easily see large servers just map editing
> to build the transport network, in which case simplicity probably beats out
> technical wizardry.
>
> Though this would also get you bonus credits for being a cool, ridiculously
> overdesigned system.
Good idea. You're right, though, space IS going to be a problem. Considering how much room is required just for, say, an 8-to-3 encoder or 3-to-8 decoder, I can easily imagine a serial bus repeater station taking up a cavern halfway to bedrock if built underground, or sprawling for some distance across the natural scenic landscape near the tracks... And you'd still need a minimum of two lines each way - one for a timing signal, to synchronize circuits on newly-loaded chunks - unless you came up with a really ingenious system somehow that perhaps combined clock pulses with data pulses... Hmm.
Though this would also get you bonus credits for being a cool, ridiculously overdesigned system.
Wow, that would be crazy ambitious. Since redstone will be unreliable at a distance, I'd consider using a pressure plate on the track to somehow trigger the signal repeater. Maybe have it accept input by default, but switch from listen mode to send mode when the cart reaches the pressure plate?
You might need 3 lines for signal, clock, and synch? The space required might not be too insanely bad, though, since you'd need one D latch per bit, a pulser for the incoming clock, and a clock generator for the outgoing serial signal, and some control logic. I have vertical D latches that chain nicely.
Reliability of just-loaded redstone is a problem, so it'd hard to assume an initial state to the system. It'd double the memory requirement, but if you had an input buffer always listening and an output buffer always sending, then you could have the pressure plate trigger a copy from input to output, which would make the serial repeater pretty reliable.
That'd be an impressive build! Probably beyond my immediate attention span though.
Wow, that would be crazy ambitious. Since redstone will be unreliable at a distance, I'd consider using a pressure plate on the track to somehow trigger the signal repeater. Maybe have it accept input by default, but switch from listen mode to send mode when the cart reaches the pressure plate?
That's an excellent suggestion. I've been trying to think of ways to deal with signal cutoff from unloading chunks without having the received data get overwritten with garbage, both in cases where the distance is great enough to require repeater stations and otherwise. Adding a pressure plate to a location halfway between start and destination, with a booster to push the cart across as well as the usual purpose of adding momentum, might be useful in triggering retransmission or something... Details remain to be worked out, but that's pretty much always the case, right? :smile.gif:
Quote from zorac »
You might need 3 lines for signal, clock, and synch? The space required might not be too insanely bad, though, since you'd need one D latch per bit, a pulser for the incoming clock, and a clock generator for the outgoing serial signal, and some control logic. I have vertical D latches that chain nicely.
You can do it with a single line, using a transmission method that incorporates clocking information into the signal. Since the data throughput doesn't have to be very high - you're just repeating a certain N-digit binary number over and over - the clock period can be comfortably low to allow time for processing each received bit.
Also, I'd LOVE to see these vertical D-latches!
Quote from zorac »
Reliability of just-loaded redstone is a problem, so it'd hard to assume an initial state to the system. It'd double the memory requirement, but if you had an input buffer always listening and an output buffer always sending, then you could have the pressure plate trigger a copy from input to output, which would make the serial repeater pretty reliable.
I like that idea. It'll definitely work, even if nothing better turns out to be viable.
You can do a certain amount just by making sure the encoding and decoding of the transmission leaves no room for ambiguity regarding where the start and end of each frame is located. Have the receiver ignore everything until it has matched its clock to the transmitter and received a specific synchronization code sent at the start of each frame. Only then should it start writing bits to its storage register.
It might also be possible to do without the pressure plate, and use a single register, merely by designing the repeater stations so that they are guaranteed to never overwrite their registers with garbage when loss of signal occurs due to unloading chunks. I've thought of one possible method to accomplish this - put clock pulses after data pulses, and don't write a received data bit until and unless the associated clock bit is properly received. In effect, treat the clock portion of the signal as a "write-enable" as well.
I forget the exact phrasing or who said it, but it's "trivial - it's just an engineering problem"! :happy.gif: In other words... it's a matter of designing and building, not theory.
... Adding a pressure plate to a location halfway between start and destination .... might be useful in triggering retransmission
I like that idea best!
Quote from Tallinu »
You can do it with a single line, using a transmission method that incorporates clocking information into the signal. Since the data throughput doesn't have to be very high - you're just repeating a certain N-digit binary number over and over - the clock period can be comfortably low to allow time for processing each received bit.
Hrrmm, okay, I believe you, but based on the inherent synchronicity in the redstone behavior. If you can get the sender and receiver in synch once, they will stay in synch if using identical clocks. You'd need an extra line if you had that centrally located pressure plate to trigger initial synchronization. I'm worried about the extra logic needed to decode a clock signal, especially since you can't ensure that the receiving station chunk loads in any particular logical state and you might have redstone ticks where only part of the receiver is loaded or running.
Quote from Tallinu »
Also, I'd LOVE to see these vertical D-latches!
I finally got around to posting some of the vertical stuff I've designed. I keep a running 'playground' save game uploaded with the current collection of random toys. (The current one doesn't have the recent decoder work we talked about, my ripoffs of Etho's awesome boat tricks, or my new monster fountain inspired by TyrannosaurusHax's cool mob elevator.)
You had lots of good thoughts. I don't think anyone has done an indefinite-length serial repeater design yet. I am going to try very hard not to get sucked into making one.
....
Awww, crap, I already started thinking about it! Okay, what I would try first if I wasn't forcing myself to go to bed on time is: use pulse-width modulation to carry the signal on the single transmission line:
- Drive the outgoing signal from a fixed PERIOD clock, but send a variable length pulse based on the data to be sent.
- When the receiver sees the line go from low to high, start a clock and measure how long the incoming pulse is before it goes low again.
- If the pulse is longest (maybe 9?) then it is a RESET signal, and indicates the start of bits. Start a counter.
- If the pulse is shortest (maybe 7?) then push a 1 onto the latch chain (pulse the memory clock)
- If the pulse is shortest (maybe 5?) then push a 0 onto the latch chain
- When the expected N bits have been received then the station goes from receive to transmit mode, and starts encoding and sending the bits.
I think this is a truly reliable design that will need only one wire following the minecart track. You need some way to detect that a cart has arrived and that the station should enter write-only mode to ignore the previous repeater as it unloads.
Two new toys that would need to be created would be pulse-width encoder and decoder. But I think that would be doable!
the1laz, this is your crazy thread. What do you think?
It does sound doable, and very interesting. I'm quite busy making a screen for my minecraft CPU whenever I'm free, so I won't be very helpful at the moment. :S
If you can get the sender and receiver in synch once, they will stay in synch if using identical clocks.
[...] I'm worried about the extra logic needed to decode a clock signal, especially since you can't ensure that the receiving station chunk loads in any particular logical state and you might have redstone ticks where only part of the receiver is loaded or running.
As long as both sender and receiver remain loaded, yes. As soon as one or the other gets unloaded due to players vacating the area, synch can no longer be assumed on reload. But since neither station has a way of knowing if it has been unloaded, you just have to design it to automatically resynch (by employing "self-synchronizing" transmission code). Then, the first repetition "heard" may be corrupt due to the receiver getting saved and then reloaded in mid-frame, but subsequently received full repetitions will be valid; and if transmission is cut off mid-frame by unloading the sender, the receiver simply won't overwrite existing stored data.
Quote from zorac »
I finally got around to posting some of the vertical stuff I've designed. I keep a running 'playground' save game uploaded with the current collection of random toys. (The current one doesn't have the recent decoder work we talked about, my ripoffs of Etho's awesome boat tricks, or my new monster fountain inspired by TyrannosaurusHax's cool mob elevator.)
Yeah, I downloaded that save yesterday, and just now I was running around in it looking for vertical D flipflops, to no avail. :biggrin.gif: Thanks for the link - that's a really ingenious design. It will be extremely handy for space efficiency, despite leaving airspace between them!! I'll have to experiment with those.
Quote from zorac »
You had lots of good thoughts. I don't think anyone has done an indefinite-length serial repeater design yet. I am going to try very hard not to get sucked into making one.
It'll be like using FM RLL, except I'm putting clock bit after the data bit (I'll explain why momentarily). The signal line will change state (invert via T flip-flop) with every "1" transmitted, and will remain the same for every "0". Alternating Data1 / Clock / Data2 / Clock / Data3 / Clock / etc (where Clock is always 1, except as noted below) will give the receiver a steady supply of line transitions to synchronize its clock with.
Additionally, I'm adding a "0 0" pair for use as "stop/start bits" - data zero, clock zero. Since this will always be immediately preceded by a 1 from the clock bit, and the normal data stream will never contain that Since the trailing bit of each data frame will always be a 1 clock bit, this code will unambiguously signal the space between bytes. (Characters? Words? Not necessarily 8 bits in a row, I'm planning to start with 3 bits at a time... How about "Message"?)
The reason for putting clock after data has to do with chunk unloading and garbage prevention. When the transmitter gets unloaded, the signal line will stop changing state. If the data bit followed the clock bit, there'd be no way to be certain it was valid - the apparent 0 could be because of the transmission cutoff. This way, the clock transition can be treated as a "write enable" - it will be a reliable indicator that the associated data is valid, since there would be no clock transition if the signal had been lost between the data and clock bits. When the transmission does cease, the apparent string of 0's will simply trigger a harmless "reset", and until transmission resumes, no changes will be made to the data stored at the receiving station.
When either the transmitter or receiver is reloaded, the latter will resynchronize its clock based on the timing of the line transitions. If one or the other was cut off mid-frame, no harm will be done, because any incorrectly aligned data bits resulting from the resumption of a partially-completed transmission will be discarded as soon as the next repeat of the transmission occurs, and overwritten with a correctly aligned, valid message.
Quote from zorac »
- When the receiver sees the line go from low to high, start a clock and measure how long the incoming pulse is before it goes low again.
- If the pulse is longest (maybe 9?) then it is a RESET signal, and indicates the start of bits. Start a counter.
- If the pulse is shortest (maybe 7?) then push a 1 onto the latch chain (pulse the memory clock)
- If the pulse is shortest (maybe 5?) then push a 0 onto the latch chain
- When the expected N bits have been received then the station goes from receive to transmit mode, and starts encoding and sending the bits.
"Latch chain"? That sounds like it might do what I need in order to build the serializer portion of my transmitter station. The modulator portion is already complete, but I've been stymied on how to cycle through the N bits of input and spit them out one at a time, then spit out the reset signal.
All I can find are PISO shift registers - and not much of that, either: I managed to find one single solitary page that shows an example. On wikipedia, of course. What I want is just to step an 'enable' signal through a series of AND gates to a single OR (which presents the currently enabled bit of the message to the modulator's data input), and when that enable bit hits the end of the cycle, it triggers another circuit which disables the output line for two clock ticks. I have those pieces all planned out and mostly set up, I just need a way to cycle that signal through D0, D1, D2, (and "... , Dn," if more bits are added), R, and repeat, advancing once every two ticks... No data needs to be moved around, that would just add unneeded complexity.
Also: Counter? Why? And how would you make use of that?
Yeah, I downloaded that save yesterday, and just now I was running around in it looking for vertical D flipflops, to no avail.
Oops, they're mislabelled as T's. There's 8 of them chained together in a circle to form a rotate register. It'll work as a serial data buffer, as long as you're careful with the NS vertical delay issue.
For the repeater, it occurs to me that if we're only sending a single integer value, we don't need to mess with any kind of binary encoding at all! Just send the value as a single pulse, where pulse width 3 = integer 1, width 5 = integer 2, width 7 = integer 3, etc...
No clock, no synch, and all the serial repeater has to do is transmit a single pulse of the same length as the one it just received!
Decode the pulse width back into a binary value at the destination.
No clock, no synch, and all the serial repeater has to do is transmit a single pulse of the same length as the one it just received!
Decode the pulse width back into a binary value at the destination.
That relies on the ability to have perfect pulse-width-sensing on the receiving end, which I'm very dubious of. And it would have no error tolerance at all - that is, no way for the receiver to know if the transmitter is still transmitting. Each repeater station would still have to decode, store, and then re-encode the detected pulse width, and the receiver portion would suffer from the same drawbacks I just mentioned the end station having.
Quote from zorac »
Oops, they're mislabelled as T's. There's 8 of them chained together in a circle to form a rotate register. It'll work as a serial data buffer, as long as you're careful with the NS vertical delay issue.
Oh? I saw those, but they aren't doing what I want either. And that configuration you had them in looks horribly complicated. I just got done building four of these D's in what I thought was going to be a circuit that would do what I need, but turned out to do nothing but toggle back and forth between 0101 and 1010, or copy the bit from the one on the right, slowly going from all 0's to all 1's and then back the other way.
I know I could do what I need (for the 3 bits and reset signal I'm currently building for) with a counter made of two T's and a 2-bit decoder - but I shouldn't have to set up anything that complex just to get a single 1 sliding from one line to the next in a regular, unvarying, clock-stepped fashion...
Besides, if I wasn't so fortunate as to have a number of bits to send that was a power of two - say I needed to send five bits - I wouldn't be able to use a counter/decoder anyway.
I've built a variable-length pulse encoder! It'll produce a pulse of any odd length (>=3) pulse based on input bits, and somehow I stumbled on a narrow design. It's dimensions are roughly N x (20ish) x (I need to get a life)
Quote from Tallinu »
That relies on the ability to have perfect pulse-width-sensing on the receiving end, which I'm very dubious of.
I haven't built one yet, but I think it would be 100% reliable, unless there are unknown bugs in the redstone implementation. All redstone is running in the same state machine, on the same clock. Absolute clock synchronicity is built into the game engine, because it's Minecraft.
A redstone tick doesn't change because it's 100 squares away, or else things like the1laz's CPU would never work. Since there aren't any random variable involved, if it's possible with redstone, it should be reliable with redstone.
That said, I haven't built a width detector yet, so it could be impractical. I'm hoping it will just consist of a single pulse generator, N RS NOR latches and control logic.
Quote from Tallinu »
Oh? I saw those, but they aren't doing what I want either. And that configuration you had them in looks horribly complicated.
Yeah, that setup was meant to fit inside a cylinder, which made it silly. However, it really IS 8 D-latches chained together and is definitely an 8-bit data buffer. Maybe I don't understand exactly what you need, but I think that's simpler than using a counter to store the actual data bits.
Quote from Tallinu »
Besides, if I wasn't so fortunate as to have a number of bits to send that was a power of two - say I needed to send five bits - I wouldn't be able to use a counter/decoder anyway.
Yeah, or else you'd have to pad it out with zeroes.
OKay, reality check here: what's the absolute max distance between serial repeaters? That should give a clear budget for the amount of redstone and volume we can spend, if we actually want to save materials vs. just running extra lines along the track.
I've built a variable-length pulse encoder! It'll produce a pulse of any odd length (>=3) pulse based on input bits, and somehow I stumbled on a narrow design. It's dimensions are roughly N x (20ish) x (I need to get a life)
Haha! Funny and awesome.
Quote from zorac »
Maybe I don't understand exactly what you need, but I think that's simpler than using a counter to store the actual data bits.
Quote from Tallinu »
Besides, if I wasn't so fortunate as to have a number of bits to send that was a power of two - say I needed to send five bits - I wouldn't be able to use a counter/decoder anyway.
Yeah, or else you'd have to pad it out with zeroes.
OKay, reality check here: what's the absolute max distance between serial repeaters? That should give a clear budget for the amount of redstone and volume we can spend, if we actually want to save materials vs. just running extra lines along the track.
I think someone said around 12 chunks or 200 blocks or something, if you wanted leeway for things to still work at that distance.
I'm not using a counter, and don't want to. It's already taking several seconds just to send three bits.
We'll see how reliable this really turns out to be once I've built a receiver. Right now I have a set of master-slave D flip-flops - all of the "D flip flop" designs I can find for MC seem to be gated D latches instead, so I stacked pairs of them in series (one set for each bit selection line), and the alternating clock signals and two-stage functioning has gotten rid of the runaway cycling I was having trouble with while using latches, where they kept causing my selector to frequently skip ahead of where it should be.
What I really want is a module or series of modules which loop and interact with each other in such a way that it is impossible to find undesired bit patterns scrolling through them such as:
There needs to at all times be a single 1, no more, no less, cycling reliably through the digits.
Basically I need a selector which behaves like a dial that has a certain number of stops, driven by a motor that turns it to the next position every time the clock ticks, looping back from the last position to the first. It needs to be able to have a non-power-of-two number of positions (three, five, or six, for example) and not waste time "selecting" nonexistent message bits and as a result transmitting dead air.
The output is being used like a decoder for a memory address, selecting one bit at a time using a multiplexer - one of several ANDs and then an OR - to get each bit into the modulator and out onto the transmission line.
Anyway, I'm dead tired right now, so I'm heading to bed. More news on progress later! :smile.gif:
Thread's been moved. :smile.gif: I suppose that this thread's probably quite forgettable by now, after seeing some of the subway systems that people have been making.
I've found it useful, I'm currently implementing a system based on this in a small SMP server. Since I'm using 8-way switching and the redstone engineering is getting difficult at best, I reworked the incoming line circuit a bit to make use of reset bus composed of two opposing lines. The plate activates both the lines such that a reset signal never feeds back into the originating node, which saves a lot of delay headaches.
I just finished making it, but without the stop at the station because it doubles the complexity of it. I made 8 destinations and just use 3 switches for the controls, because its easier and lining up 8 buttons isnt ideal.
I used and gates instead of the or and not, simply because i didnt understand how that worked so i made it how i knew it would work.
Heres the diagram
also just to let people know, the latches either have to be close enough together to not need repeaters on the reset lines (because they will start to loop) or all of the reset wires coming from the pressure plates have to meet at one point and then go to the latches, making it so you only need it to flow in one direction so that repeaters can be used.
Also, a system ive tested out on my test file, with a master reset switch which activate when you are coming in, and should no station be chosen you will be returned to the stop.
Gj on explaining this idea.
Right. My question is how to get a signal to the turned-around torches in a limited amount of space. You can certainly do it without widening the button array if you have at least 4 meters of space behind the buttons to work with, allowing you to simply run every other wire across to the far side of your vertical signal path, drop down, and turn around to come at it from that side. The direct ones have to drop down some as well and have an inverter added. I'll try to depict this the same way you did.
Odd buttons:
[]
[]
[] [] []
[]
[]
Even buttons:
[] [] []
[] [] []
[]
[]
[]
If you need indicator lights coming back up, it'll take at least 6 meters instead of 4. (Since my design used switches, I didn't have to worry about that.) Now that I think about it, it wouldn't have required THAT much more space than what I used... But it still wouldn't have fit without expanding my building. XD
Also, in case you haven't seen it already, this thread has a lot of good design info regarding compact arrangements of buttons and redstone logic that may be of use:
viewtopic.php?f=35&t=60816
Oh okay. Well, I guess that the way in that other thread (which is really cool, thanks) looks pretty space efficient around the buttons. Otherwise, I suppose it could be done like this, if you don't mind the buttons not being in a straight line:
Odd buttons:
[]
[]
[] []
[] [] []
[] []
Even buttons:
[]
[] []
[] []
[] [] []
[] []
That's a good functional setup. But I was trying to avoid having anything staggered. I wanted to combine functional with aesthetically pleasing. And that requires more room, it seems. :smile.gif:
I checked out your video (nicely done, by the way) and save file (20 MB for a <7MB save? Turns out you have a ton of SVN files in that download!). I was trying to figure out how you implemented the encoder and memory under each set of buttons, but... it was just too tightly packed and hard to move around in.
Any chance you could describe or diagram how that part works? I'm trying to come up with an encoder that's upwardly scalable, but what I have so far is very space-intensive: About 8 by N by 4*Log2(N) X, Y, Z dimensions... just for the encoder part.
Assuming parallel horizontal inputs offset by one vertical space, my current encoder is N wide by 5*Log2(N) by 4 high. Output lines are spaced 5 apart along the top of the encoder, perpendicular to the input lines. It's meant to be tacked on to the back of my button array. There's probably something better out there.
I'll check out the1laz's before posting anything. (Thanks for posting the save!)
edit: another option that just occurred to me is N wide by 4Log2(N) by 5 high. I think I prefer that.
> Though after digging six channels under my track for two-way 8-station
> selection, I'm starting to wonder if it might be more redstone and
> space-efficient to transmit the data serially - you can safely flash
> torches on and off much faster than a minecart can travel over long
> distances (you would definitely have to stick to a repeating station within
> the chunk limits though, limited tests indicated absolute maximum 12
> chunks=192 blocks) and I can easily imagine one or two less wires is more
> than enough redstone to cover the cost for
> memory+clocks+shifters+(syncers?). Space might be a problem, but it's not
> like space is limited or anything, especially on a large, spread out
> server. On the other hand I could easily see large servers just map editing
> to build the transport network, in which case simplicity probably beats out
> technical wizardry.
>
> Though this would also get you bonus credits for being a cool, ridiculously
> overdesigned system.
Good idea. You're right, though, space IS going to be a problem. Considering how much room is required just for, say, an 8-to-3 encoder or 3-to-8 decoder, I can easily imagine a serial bus repeater station taking up a cavern halfway to bedrock if built underground, or sprawling for some distance across the natural scenic landscape near the tracks... And you'd still need a minimum of two lines each way - one for a timing signal, to synchronize circuits on newly-loaded chunks - unless you came up with a really ingenious system somehow that perhaps combined clock pulses with data pulses... Hmm.
Wow, that would be crazy ambitious. Since redstone will be unreliable at a distance, I'd consider using a pressure plate on the track to somehow trigger the signal repeater. Maybe have it accept input by default, but switch from listen mode to send mode when the cart reaches the pressure plate?
You might need 3 lines for signal, clock, and synch? The space required might not be too insanely bad, though, since you'd need one D latch per bit, a pulser for the incoming clock, and a clock generator for the outgoing serial signal, and some control logic. I have vertical D latches that chain nicely.
Reliability of just-loaded redstone is a problem, so it'd hard to assume an initial state to the system. It'd double the memory requirement, but if you had an input buffer always listening and an output buffer always sending, then you could have the pressure plate trigger a copy from input to output, which would make the serial repeater pretty reliable.
That'd be an impressive build! Probably beyond my immediate attention span though.
That's an excellent suggestion. I've been trying to think of ways to deal with signal cutoff from unloading chunks without having the received data get overwritten with garbage, both in cases where the distance is great enough to require repeater stations and otherwise. Adding a pressure plate to a location halfway between start and destination, with a booster to push the cart across as well as the usual purpose of adding momentum, might be useful in triggering retransmission or something... Details remain to be worked out, but that's pretty much always the case, right? :smile.gif:
You can do it with a single line, using a transmission method that incorporates clocking information into the signal. Since the data throughput doesn't have to be very high - you're just repeating a certain N-digit binary number over and over - the clock period can be comfortably low to allow time for processing each received bit.
Also, I'd LOVE to see these vertical D-latches!
I like that idea. It'll definitely work, even if nothing better turns out to be viable.
You can do a certain amount just by making sure the encoding and decoding of the transmission leaves no room for ambiguity regarding where the start and end of each frame is located. Have the receiver ignore everything until it has matched its clock to the transmitter and received a specific synchronization code sent at the start of each frame. Only then should it start writing bits to its storage register.
It might also be possible to do without the pressure plate, and use a single register, merely by designing the repeater stations so that they are guaranteed to never overwrite their registers with garbage when loss of signal occurs due to unloading chunks. I've thought of one possible method to accomplish this - put clock pulses after data pulses, and don't write a received data bit until and unless the associated clock bit is properly received. In effect, treat the clock portion of the signal as a "write-enable" as well.
I forget the exact phrasing or who said it, but it's "trivial - it's just an engineering problem"! :happy.gif: In other words... it's a matter of designing and building, not theory.
I like that idea best!
Hrrmm, okay, I believe you, but based on the inherent synchronicity in the redstone behavior. If you can get the sender and receiver in synch once, they will stay in synch if using identical clocks. You'd need an extra line if you had that centrally located pressure plate to trigger initial synchronization. I'm worried about the extra logic needed to decode a clock signal, especially since you can't ensure that the receiving station chunk loads in any particular logical state and you might have redstone ticks where only part of the receiver is loaded or running.
I finally got around to posting some of the vertical stuff I've designed. I keep a running 'playground' save game uploaded with the current collection of random toys. (The current one doesn't have the recent decoder work we talked about, my ripoffs of Etho's awesome boat tricks, or my new monster fountain inspired by TyrannosaurusHax's cool mob elevator.)
You had lots of good thoughts. I don't think anyone has done an indefinite-length serial repeater design yet. I am going to try very hard not to get sucked into making one.
....
Awww, crap, I already started thinking about it! Okay, what I would try first if I wasn't forcing myself to go to bed on time is: use pulse-width modulation to carry the signal on the single transmission line:
- Drive the outgoing signal from a fixed PERIOD clock, but send a variable length pulse based on the data to be sent.
- When the receiver sees the line go from low to high, start a clock and measure how long the incoming pulse is before it goes low again.
- If the pulse is longest (maybe 9?) then it is a RESET signal, and indicates the start of bits. Start a counter.
- If the pulse is shortest (maybe 7?) then push a 1 onto the latch chain (pulse the memory clock)
- If the pulse is shortest (maybe 5?) then push a 0 onto the latch chain
- When the expected N bits have been received then the station goes from receive to transmit mode, and starts encoding and sending the bits.
I think this is a truly reliable design that will need only one wire following the minecart track. You need some way to detect that a cart has arrived and that the station should enter write-only mode to ignore the previous repeater as it unloads.
Two new toys that would need to be created would be pulse-width encoder and decoder. But I think that would be doable!
the1laz, this is your crazy thread. What do you think?
As long as both sender and receiver remain loaded, yes. As soon as one or the other gets unloaded due to players vacating the area, synch can no longer be assumed on reload. But since neither station has a way of knowing if it has been unloaded, you just have to design it to automatically resynch (by employing "self-synchronizing" transmission code). Then, the first repetition "heard" may be corrupt due to the receiver getting saved and then reloaded in mid-frame, but subsequently received full repetitions will be valid; and if transmission is cut off mid-frame by unloading the sender, the receiver simply won't overwrite existing stored data.
Yeah, I downloaded that save yesterday, and just now I was running around in it looking for vertical D flipflops, to no avail. :biggrin.gif: Thanks for the link - that's a really ingenious design. It will be extremely handy for space efficiency, despite leaving airspace between them!! I'll have to experiment with those.
That's what you get. ^_~
My plan is to use something much like biphase mark code.
It'll be like using FM RLL, except I'm putting clock bit after the data bit (I'll explain why momentarily). The signal line will change state (invert via T flip-flop) with every "1" transmitted, and will remain the same for every "0". Alternating Data1 / Clock / Data2 / Clock / Data3 / Clock / etc (where Clock is always 1, except as noted below) will give the receiver a steady supply of line transitions to synchronize its clock with.
Additionally, I'm adding a "0 0" pair for use as "stop/start bits" - data zero, clock zero. Since this will always be immediately preceded by a 1 from the clock bit, and the normal data stream will never contain that Since the trailing bit of each data frame will always be a 1 clock bit, this code will unambiguously signal the space between bytes. (Characters? Words? Not necessarily 8 bits in a row, I'm planning to start with 3 bits at a time... How about "Message"?)
The reason for putting clock after data has to do with chunk unloading and garbage prevention. When the transmitter gets unloaded, the signal line will stop changing state. If the data bit followed the clock bit, there'd be no way to be certain it was valid - the apparent 0 could be because of the transmission cutoff. This way, the clock transition can be treated as a "write enable" - it will be a reliable indicator that the associated data is valid, since there would be no clock transition if the signal had been lost between the data and clock bits. When the transmission does cease, the apparent string of 0's will simply trigger a harmless "reset", and until transmission resumes, no changes will be made to the data stored at the receiving station.
When either the transmitter or receiver is reloaded, the latter will resynchronize its clock based on the timing of the line transitions. If one or the other was cut off mid-frame, no harm will be done, because any incorrectly aligned data bits resulting from the resumption of a partially-completed transmission will be discarded as soon as the next repeat of the transmission occurs, and overwritten with a correctly aligned, valid message.
"Latch chain"? That sounds like it might do what I need in order to build the serializer portion of my transmitter station. The modulator portion is already complete, but I've been stymied on how to cycle through the N bits of input and spit them out one at a time, then spit out the reset signal.
All I can find are PISO shift registers - and not much of that, either: I managed to find one single solitary page that shows an example. On wikipedia, of course. What I want is just to step an 'enable' signal through a series of AND gates to a single OR (which presents the currently enabled bit of the message to the modulator's data input), and when that enable bit hits the end of the cycle, it triggers another circuit which disables the output line for two clock ticks. I have those pieces all planned out and mostly set up, I just need a way to cycle that signal through D0, D1, D2, (and "... , Dn," if more bits are added), R, and repeat, advancing once every two ticks... No data needs to be moved around, that would just add unneeded complexity.
Also: Counter? Why? And how would you make use of that?
Oops, they're mislabelled as T's. There's 8 of them chained together in a circle to form a rotate register. It'll work as a serial data buffer, as long as you're careful with the NS vertical delay issue.
For the repeater, it occurs to me that if we're only sending a single integer value, we don't need to mess with any kind of binary encoding at all! Just send the value as a single pulse, where pulse width 3 = integer 1, width 5 = integer 2, width 7 = integer 3, etc...
No clock, no synch, and all the serial repeater has to do is transmit a single pulse of the same length as the one it just received!
Decode the pulse width back into a binary value at the destination.
That relies on the ability to have perfect pulse-width-sensing on the receiving end, which I'm very dubious of. And it would have no error tolerance at all - that is, no way for the receiver to know if the transmitter is still transmitting. Each repeater station would still have to decode, store, and then re-encode the detected pulse width, and the receiver portion would suffer from the same drawbacks I just mentioned the end station having.
Oh? I saw those, but they aren't doing what I want either. And that configuration you had them in looks horribly complicated. I just got done building four of these D's in what I thought was going to be a circuit that would do what I need, but turned out to do nothing but toggle back and forth between 0101 and 1010, or copy the bit from the one on the right, slowly going from all 0's to all 1's and then back the other way.
I know I could do what I need (for the 3 bits and reset signal I'm currently building for) with a counter made of two T's and a 2-bit decoder - but I shouldn't have to set up anything that complex just to get a single 1 sliding from one line to the next in a regular, unvarying, clock-stepped fashion...
Besides, if I wasn't so fortunate as to have a number of bits to send that was a power of two - say I needed to send five bits - I wouldn't be able to use a counter/decoder anyway.
I haven't built one yet, but I think it would be 100% reliable, unless there are unknown bugs in the redstone implementation. All redstone is running in the same state machine, on the same clock. Absolute clock synchronicity is built into the game engine, because it's Minecraft.
A redstone tick doesn't change because it's 100 squares away, or else things like the1laz's CPU would never work. Since there aren't any random variable involved, if it's possible with redstone, it should be reliable with redstone.
That said, I haven't built a width detector yet, so it could be impractical. I'm hoping it will just consist of a single pulse generator, N RS NOR latches and control logic.
Yeah, that setup was meant to fit inside a cylinder, which made it silly. However, it really IS 8 D-latches chained together and is definitely an 8-bit data buffer. Maybe I don't understand exactly what you need, but I think that's simpler than using a counter to store the actual data bits.
Yeah, or else you'd have to pad it out with zeroes.
OKay, reality check here: what's the absolute max distance between serial repeaters? That should give a clear budget for the amount of redstone and volume we can spend, if we actually want to save materials vs. just running extra lines along the track.
Haha! Funny and awesome.
I think someone said around 12 chunks or 200 blocks or something, if you wanted leeway for things to still work at that distance.
I'm not using a counter, and don't want to. It's already taking several seconds just to send three bits.
We'll see how reliable this really turns out to be once I've built a receiver. Right now I have a set of master-slave D flip-flops - all of the "D flip flop" designs I can find for MC seem to be gated D latches instead, so I stacked pairs of them in series (one set for each bit selection line), and the alternating clock signals and two-stage functioning has gotten rid of the runaway cycling I was having trouble with while using latches, where they kept causing my selector to frequently skip ahead of where it should be.
What I really want is a module or series of modules which loop and interact with each other in such a way that it is impossible to find undesired bit patterns scrolling through them such as:
110 > 101 > 011 > 110
111 > 111
1010 > 0101 > 1010
1100 > 1001 > 0011 > 0110 > 1100
0000 > 0000
1111 > 1111
There needs to at all times be a single 1, no more, no less, cycling reliably through the digits.
Basically I need a selector which behaves like a dial that has a certain number of stops, driven by a motor that turns it to the next position every time the clock ticks, looping back from the last position to the first. It needs to be able to have a non-power-of-two number of positions (three, five, or six, for example) and not waste time "selecting" nonexistent message bits and as a result transmitting dead air.
The output is being used like a decoder for a memory address, selecting one bit at a time using a multiplexer - one of several ANDs and then an OR - to get each bit into the modulator and out onto the transmission line.
Anyway, I'm dead tired right now, so I'm heading to bed. More news on progress later! :smile.gif:
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
I used and gates instead of the or and not, simply because i didnt understand how that worked so i made it how i knew it would work.
Heres the diagram
also just to let people know, the latches either have to be close enough together to not need repeaters on the reset lines (because they will start to loop) or all of the reset wires coming from the pressure plates have to meet at one point and then go to the latches, making it so you only need it to flow in one direction so that repeaters can be used.