I built a digital clock, but two things ruined it.
Firstly piston lag, which made the display not show the correct arrangement of blocks. It never really displayed the numerical character properly, bits were missing.
Secondly I had MASSIVE problems with redstone currents inverting themselves crossing chunk boundaries, it made it extremely hard to get the pistons which pushed the memory loop round to work in the correct sequence across all memory banks. I'd trace the redstone wire which would be off at source then on a chunk boundary suddenly the redstone wire was energised. Pistons that should have been off were on.
I was using a piston engine to create a pulsing current, maybe if I'd have used a 5 clock repeater it might have worked better. I've never had problems with chuck boundaries and redstone currents before, in fact I have a central station with redstone wiring going off for miles in all directions working points and junctions for branch lines with no problems at all.
Maybe someone who has built a good working version can shed some light on what the Xbox version of a digital clock needs to work properly.
I have had a few problems with piston engines myself so I decided to stop using them. but then again even the smallest repeater/torch clock I have on my 7 row cobblestone machine has quit randomly 3 times. and I mean really randomly. funny thing is the clock on my single row cobble stone machine has never quit and it is the same exact clock mechanism. I am starting to think the more a clock circuit is hooked up to the more likely it is going to glitch.
Rollback Post to RevisionRollBack
I tried to sign my name here, but all I managed to do was ruin my computer screen.
ive built a 2 repeater, 1 redstone torch clock and had the redstone torch fail, replacing it works once then fails again, but is supposed to be really stable, in the early pc vids i see the same thing happening, hoping theres a fix for it in the next few updates
I hope so too. on the other hand I havn't had torch fails. my one repeater one torch clock always fails on and stays on even when I hit the cut off lever (runs power into the block the torch is on) and that should just not be possible. defys all redstone laws. but only on my 7 row cobblestone machine. It's completely stable with everything else I have used it for. and it has only failed 3 times and that was only upon loading the map.
ive built a few complex redstone creations, one being a memory bank, i did have issues with pistons 'staying extended', managed to resolve this by using a piston to cut the power so the main pistons retract instantaneously, this has saved alot of my work, never got as far as the digital display though, waiting for creative for that,
but currently working on trying to find a way of making a 4 piston memory bank run a 7 sector digit display...(on paper)
In that case, what you probably want is binary-coded decimals (BCD). Each set of 4 bits represents a decimal digit, though it can actually store 16 different values. You still need to create a decoder, though. The beauty of using 8 bits is that it allows you to store each digit already decoded for 7 segments, plus the rollover bit for the next digit.
Redstone works fine for me as long as you do not save/load .. when you save and load every clocked system is very likely to produce "glitched" redstone (exactly what xYOSSARIANx describes) that is on or off where it shouldn't, thus killing the clock. You have to deactivate your clocked circuits before saving... and no, even very slow clocks are producing that problem for me.
Maybe Nose_Job_For_A_Cowbay can explain how he keeps his computer working safely %)
It doesn't work perfectly at all. I clear my cache every single time before I load the computer world. It runs with decent reliability for a few minutes, I'd say 80 to 85% accuracy. After that the glitches start to completely cripple the whole machine, it's kind of like a real life computer virus in a way. Somebody needs to invent anti-virus programs in Minecraft. xD
One reason it works as well as it does may be because I rarely play it in online mode.
A clock is going to have more problems, because all the designs I've seen use pistons. You could make data roll style memory without the pistons. Keep in mind the design is going to be probably 2 to 3 times larger, and will still have some issues. I would just build the piston design and wait for the update that fixes our redstone.
In that case, what you probably want is binary-coded decimals (BCD). Each set of 4 bits represents a decimal digit, though it can actually store 16 different values. You still need to create a decoder, though. The beauty of using 8 bits is that it allows you to store each digit already decoded for 7 segments, plus the rollover bit for the next digit.
I've been at odds with binary to BCD decoders for awhile. They're just WAY too slow and huge, nobody wants to build that many adders for a decoder. I never did understand why everybody uses them so much.
But anyway, you don't need a decoder for a clock. The best design I've seen used a series of data rolls for the display's memory. The input is direct, there is no need to convert anything. Signals are sent to each segment when necessary, when not needed a glass block is used.
EDIT: Didn't mean to double post. Usually when I post right after my previous post it combines them. :S
No matter what you will need a 10-tick clock if you want it to be accurate. This sounds slow, but believe me, when every data roll "rolls" at the same time it's going to be Lag City. It will probably give your circuit a few errors as well.
I've been at odds with binary to BCD decoders for awhile. They're just WAY too slow and huge, nobody wants to build that many adders for a decoder. I never did understand why everybody uses them so much.
But anyway, you don't need a decoder for a clock. The best design I've seen used a series of data rolls for the display's memory. The input is direct, there is no need to convert anything. Signals are sent to each segment when necessary, when not needed a glass block is used.
EDIT: Didn't mean to double post. Usually when I post right after my previous post it combines them. :S
Right. That's what I meant. Hence the 8 bits per digit for 10 digits (piston-rolling array is 8 blocks wide X 10 blocks long). 7 bits are direct segment data, 1 bit is the carry to the next digit. For 0-5, you use a 12-long roll which runs through those digits twice, as well as the carry bit. I was just addressing his desire to use a 4-wide array. I'm not sure he's trying to do a clock. I considered 4 bits/digit myself, but realized the complexity of a decoder would negate the advantage of smaller arrays.
but this is what i was trying to say, sorry, i didnt get it across properly, someone on youtube has done it with a 4 roller per digit, ive looked at it so many times and cant fathom out how hes done it, i dont think its binary cause its too small for that
check it out here
See his thread. Scroll down to Post #18. Look at his 2nd "spoiler". That sheds some light on what he's doing. Looks like the encoding for the 5 is the only one that has an "on" bit in the nearest layer (the red block). My guess is he pulls double duty with that, using that as a carry/rollover bit at the back while the 0 is displayed at the front. I still don't see how he's doing his decoding, but what I see in that image looks nothing like BCD. There is some devious cleverness going on, I think. Props to him for making this work so compactly.
I have had a few problems with piston engines myself so I decided to stop using them. but then again even the smallest repeater/torch clock I have on my 7 row cobblestone machine has quit randomly 3 times. and I mean really randomly. funny thing is the clock on my single row cobble stone machine has never quit and it is the same exact clock mechanism. I am starting to think the more a clock circuit is hooked up to the more likely it is going to glitch.
I tried to sign my name here, but all I managed to do was ruin my computer screen.
I hope so too. on the other hand I havn't had torch fails. my one repeater one torch clock always fails on and stays on even when I hit the cut off lever (runs power into the block the torch is on) and that should just not be possible. defys all redstone laws. but only on my 7 row cobblestone machine. It's completely stable with everything else I have used it for. and it has only failed 3 times and that was only upon loading the map.
I tried to sign my name here, but all I managed to do was ruin my computer screen.
In that case, what you probably want is binary-coded decimals (BCD). Each set of 4 bits represents a decimal digit, though it can actually store 16 different values. You still need to create a decoder, though. The beauty of using 8 bits is that it allows you to store each digit already decoded for 7 segments, plus the rollover bit for the next digit.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffIt doesn't work perfectly at all. I clear my cache every single time before I load the computer world. It runs with decent reliability for a few minutes, I'd say 80 to 85% accuracy. After that the glitches start to completely cripple the whole machine, it's kind of like a real life computer virus in a way. Somebody needs to invent anti-virus programs in Minecraft. xD
One reason it works as well as it does may be because I rarely play it in online mode.
A clock is going to have more problems, because all the designs I've seen use pistons. You could make data roll style memory without the pistons. Keep in mind the design is going to be probably 2 to 3 times larger, and will still have some issues. I would just build the piston design and wait for the update that fixes our redstone.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffI've been at odds with binary to BCD decoders for awhile. They're just WAY too slow and huge, nobody wants to build that many adders for a decoder. I never did understand why everybody uses them so much.
But anyway, you don't need a decoder for a clock. The best design I've seen used a series of data rolls for the display's memory. The input is direct, there is no need to convert anything. Signals are sent to each segment when necessary, when not needed a glass block is used.
EDIT: Didn't mean to double post. Usually when I post right after my previous post it combines them. :S
-
View User Profile
-
View Posts
-
Send Message
Retired StaffRight. That's what I meant. Hence the 8 bits per digit for 10 digits (piston-rolling array is 8 blocks wide X 10 blocks long). 7 bits are direct segment data, 1 bit is the carry to the next digit. For 0-5, you use a 12-long roll which runs through those digits twice, as well as the carry bit. I was just addressing his desire to use a 4-wide array. I'm not sure he's trying to do a clock. I considered 4 bits/digit myself, but realized the complexity of a decoder would negate the advantage of smaller arrays.
See his thread. Scroll down to Post #18. Look at his 2nd "spoiler". That sheds some light on what he's doing. Looks like the encoding for the 5 is the only one that has an "on" bit in the nearest layer (the red block). My guess is he pulls double duty with that, using that as a carry/rollover bit at the back while the 0 is displayed at the front. I still don't see how he's doing his decoding, but what I see in that image looks nothing like BCD. There is some devious cleverness going on, I think. Props to him for making this work so compactly.