I am rebuilding bennyscube's (link to playlist on Youtube: http://www.youtube.c...9A5CCF920EE78FD) design for a working calculator on the XBox version of Minecraft. I've gotten every part of the calculator working, with the exception of the BCD for the 7 segment display. When adding the last stack of adders for the 64/128 outputs, I don't get 64 on the display I get 72. I tested the calculator and I am still getting the correct binary output, but I just can't figure out where that extra 8 gets added to the 64.
I do have a game capture device so I can capture some video if needed. I am a bit leery when it comes to letting most unknown people into my worlds, but I guess I can put on Host options if anyone is willing to help me with this issue. I've tried rebuilding the last adders (even different ways), and the entire BCD, several times and I still get the same results. It is so frustrating to be so close to the end of this project and not be able to finish. Perhaps there is just some quirk of redstone on XBox that I'm missing... but in theory with the update this should match the version he built this in on the PC.
"'Tis wise to avoid meddling in the affairs of dragons, for you are quite crunchy and go well with ketchup." - Old Maldavian Proverb
Check out my YouTube Channel: http://www.youtube.com/tooligan23
This may be obvious to you, since you can handle this sort of project, but I'll say it anyway: The extra 8 is probably a single bit (the fourth, from the LSB) going high on you, somewhere in the process. That's assuming that I'm reading your post correctly: a decimal-display issue, but correct binary output.
This may be obvious to you, since you can handle this sort of project, but I'll say it anyway: The extra 8 is probably a single bit (the fourth, from the LSB) going high on you, somewhere in the process. That's assuming that I'm reading your post correctly: a decimal-display issue, but correct binary output.
I still think this is exactly what is going on, but I can't seem to trace it down. I even went thru simple calculations on the calculator itself, and thought I traced it down to the stack of adders for the 8 or 16... so I rebuilt everything from that point on again and still got the same results. So I guess I did not track down the actual source of that single bit getting tacked on.
Rollback Post to RevisionRollBack
"'Tis wise to avoid meddling in the affairs of dragons, for you are quite crunchy and go well with ketchup." - Old Maldavian Proverb
Check out my YouTube Channel: http://www.youtube.com/tooligan23
The Meaning of Life, the Universe, and Everything.
Join Date:
1/5/2013
Posts:
455
Xbox:
MaxSterling
Member Details
I just glanced through the first 2 videos and my eyes glazed over from boredom.
Somehow, the 8 bits nibble line is being activated in conjunction with your 64 bits nibble line. Check to see if there is some kind of torch that is activated over the 8 bits nibble line when the 64 bit nibble line is activated. That would be my guess if it only occurs when the 64 nibble is activated.
I just glanced through the first 2 videos and my eyes glazed over from boredom.
Somehow, the 8 bits nibble line is being activated in conjunction with your 64 bits nibble line. Check to see if there is some kind of torch that is activated over the 8 bits nibble line when the 64 bit nibble line is activated. That would be my guess if it only occurs when the 64 nibble is activated.
I'm guessing you don't know what a nyble is. The integer 64 is just represented by a single bit, 7th from LSB. In BCD there is no "64 nyble" all the nyble-sized sections are 4-bit binary representations of a decimal digit, 100, 101, and 102 in OP's case. (ones, tens, and hundreds)
I still think this is exactly what is going on, but I can't seem to trace it down. I even went thru simple calculations on the calculator itself, and thought I traced it down to the stack of adders for the 8 or 16... so I rebuilt everything from that point on again and still got the same results. So I guess I did not track down the actual source of that single bit getting tacked on.
Hang in there, I'm going to go through the process of double dabble and see if I can find where an issue may pop up. To be clear, you're saying that 100000 becomes 0111-0010 instead of 0110-0100?
EDIT: Tried a few different scenarios, couldn't find the issue. There is a large amount of things that could go wrong here, but I still think the problem lies in how the hardware executes the algorithm. It could also simply be a bug, a corrupted block perhaps, could even be that you forgot a block or torch somewhere. I'll give you a scanned image of what the process should look like, it will be easier for you to personally observe the hardware and see where the calculation is failing. If everything seems correct, the problem may be outside of the decoder.
This is what the algorithm should do. BCD on the left, original binary value on the right.
The Meaning of Life, the Universe, and Everything.
Join Date:
1/5/2013
Posts:
455
Xbox:
MaxSterling
Member Details
I know that a bit, is a one or zero.
A byte is a sequence of 8 bits.
A nibble, nybble, or nyble is either the first 4 bits or last 4 bits in a byte.
As I was saying... 64 is represented by
0100 0000
if they're showing 72...
0100 1000
then to me, that would mean something in the 7th bit that activated 64... is also activating that 4th bit to activate 8... to get that result, 72.
The reason I brought up nibbles, is because of the way it's laid out in the first two video in the OP... if you bothered to watch. Each lever activates a row which intersects what is essentially a nibble.... 4 intersecting redstone circuits, each representing a bit in a nibble. The bottom row uses only the first 3 bits which means the 4th bit is turned off. The second row of numbers has the 4th bit always turned on.
Hang in there, I'm going to go through the process of double dabble and see if I can find where an issue may pop up. To be clear, you're saying that 100000 becomes 0111-0010 instead of 0110-0100?
EDIT: Tried a few different scenarios, couldn't find the issue. There is a large amount of things that could go wrong here, but I still think the problem lies in how the hardware executes the algorithm. It could also simply be a bug, a corrupted block perhaps, could even be that you forgot a block or torch somewhere. I'll give you a scanned image of what the process should look like, it will be easier for you to personally observe the hardware and see where the calculation is failing. If everything seems correct, the problem may be outside of the decoder.
This is what the algorithm should do. BCD on the left, original binary value on the right.
That is exactly what seems to be happening. Since the BCD is a rather large component to build, there are several things that could go wrong. I might just have to smash it all down and rebuild it again even more meticulous than the last times... ugh! I was hoping someone had built something like this and had an easy solution that I might have overlooked. I could just be happy with the calculator actually working with the binary display using torches, but having an actual 7 segment display would be a nice addition.
Rollback Post to RevisionRollBack
"'Tis wise to avoid meddling in the affairs of dragons, for you are quite crunchy and go well with ketchup." - Old Maldavian Proverb
Check out my YouTube Channel: http://www.youtube.com/tooligan23
That is exactly what seems to be happening. Since the BCD is a rather large component to build, there are several things that could go wrong. I might just have to smash it all down and rebuild it again even more meticulous than the last times... ugh! I was hoping someone had built something like this and had an easy solution that I might have overlooked. I could just be happy with the calculator actually working with the binary display using torches, but having an actual 7 segment display would be a nice addition.
Well this is a horribly inefficient idea, but you could always use a binary to unary decoder and have the unary outputs controlling ROM lines sending signals to a 7-segment display. I've done it before, but never for something of this size, it's only practical up to around 5 bit data. Don't give up on BCD yet, I've been running the idea through my head of building a machine that processes data based on the double dabble algorithm. Granted, it won't be as fast as Benny's full adder array, as his is an asynchronous design, but you would be more than welcome to use it.
I'm thinking of something like a miniature specific-purpose CPU, built exclusively for this process. It would have a little device like an ALU. It would only take information, send it through a comparator-like device along with a series of 4-bit adders, IF INT >4 output triggers the condition is met for +3. From there, data goes through a left shift mechanism and outputs to a register, the next cycle ticks the Cin of said register, starting the process all over with new data. Number of cycles will be determined by an indexing mechanism, similar to the one I built for the HDD, but in this case, n cycles is determined by an n-bit value. The clock will cease and a control bit will enable the final output. The next time the machine is activated, a reset line to the indexing counter will be activated prior to data being sent to the initial input.
Well this is a horribly inefficient idea, but you could always use a binary to unary decoder and have the unary outputs controlling ROM lines sending signals to a 7-segment display. I've done it before, but never for something of this size, it's only practical up to around 5 bit data. Don't give up on BCD yet, I've been running the idea through my head of building a machine that processes data based on the double dabble algorithm. Granted, it won't be as fast as Benny's full adder array, as his is an asynchronous design, but you would be more than welcome to use it.
I'm thinking of something like a miniature specific-purpose CPU, built exclusively for this process. It would have a little device like an ALU. It would only take information, send it through a comparator-like device along with a series of 4-bit adders, IF INT >4 output triggers the condition is met for +3. From there, data goes through a left shift mechanism and outputs to a register, the next cycle ticks the Cin of said register, starting the process all over with new data. Number of cycles will be determined by an indexing mechanism, similar to the one I built for the HDD, but in this case, n cycles is determined by an n-bit value. The clock will cease and a control bit will enable the final output. The next time the machine is activated, a reset line to the indexing counter will be activated prior to data being sent to the initial input.
I am not giving up on this BCD decoder just yet. I think there has to be something that I keep overlooking. I believe that I am just going to tear it all back down and rebuild it yet again. In theory the way this is built should work correctly on the XBox now, but I could be wrong on that as well. While the BCD isn't that complicated to build once you get the pattern down, it is almost as large as the calculator itself:
Rollback Post to RevisionRollBack
"'Tis wise to avoid meddling in the affairs of dragons, for you are quite crunchy and go well with ketchup." - Old Maldavian Proverb
Check out my YouTube Channel: http://www.youtube.com/tooligan23
UPDATE: On the fourth rebuild I finally traced down where that pesky extra 8 was actually coming from... and it wasn't the BCD. When testing the stack for the 16 input I noticed I was still getting 16/32/72/828 on the display (output on the BCD itself was calculating correctly). After tracing it down I noticed I had the output going into the 3rd 7-segment display wired backwards. DOH! Everything is now working 100% correct finally!!!
Rollback Post to RevisionRollBack
"'Tis wise to avoid meddling in the affairs of dragons, for you are quite crunchy and go well with ketchup." - Old Maldavian Proverb
Check out my YouTube Channel: http://www.youtube.com/tooligan23
To post a comment, please login or register a new account.
I do have a game capture device so I can capture some video if needed. I am a bit leery when it comes to letting most unknown people into my worlds, but I guess I can put on Host options if anyone is willing to help me with this issue. I've tried rebuilding the last adders (even different ways), and the entire BCD, several times and I still get the same results. It is so frustrating to be so close to the end of this project and not be able to finish. Perhaps there is just some quirk of redstone on XBox that I'm missing... but in theory with the update this should match the version he built this in on the PC.
Check out my YouTube Channel: http://www.youtube.com/tooligan23
I still think this is exactly what is going on, but I can't seem to trace it down. I even went thru simple calculations on the calculator itself, and thought I traced it down to the stack of adders for the 8 or 16... so I rebuilt everything from that point on again and still got the same results. So I guess I did not track down the actual source of that single bit getting tacked on.
Check out my YouTube Channel: http://www.youtube.com/tooligan23
Somehow, the 8 bits nibble line is being activated in conjunction with your 64 bits nibble line. Check to see if there is some kind of torch that is activated over the 8 bits nibble line when the 64 bit nibble line is activated. That would be my guess if it only occurs when the 64 nibble is activated.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffI'm guessing you don't know what a nyble is. The integer 64 is just represented by a single bit, 7th from LSB. In BCD there is no "64 nyble" all the nyble-sized sections are 4-bit binary representations of a decimal digit, 100, 101, and 102 in OP's case. (ones, tens, and hundreds)
Hang in there, I'm going to go through the process of double dabble and see if I can find where an issue may pop up. To be clear, you're saying that 100000 becomes 0111-0010 instead of 0110-0100?
EDIT: Tried a few different scenarios, couldn't find the issue. There is a large amount of things that could go wrong here, but I still think the problem lies in how the hardware executes the algorithm. It could also simply be a bug, a corrupted block perhaps, could even be that you forgot a block or torch somewhere. I'll give you a scanned image of what the process should look like, it will be easier for you to personally observe the hardware and see where the calculation is failing. If everything seems correct, the problem may be outside of the decoder.
This is what the algorithm should do. BCD on the left, original binary value on the right.
A byte is a sequence of 8 bits.
A nibble, nybble, or nyble is either the first 4 bits or last 4 bits in a byte.
As I was saying... 64 is represented by
0100 0000
if they're showing 72...
0100 1000
then to me, that would mean something in the 7th bit that activated 64... is also activating that 4th bit to activate 8... to get that result, 72.
The reason I brought up nibbles, is because of the way it's laid out in the first two video in the OP... if you bothered to watch. Each lever activates a row which intersects what is essentially a nibble.... 4 intersecting redstone circuits, each representing a bit in a nibble. The bottom row uses only the first 3 bits which means the 4th bit is turned off. The second row of numbers has the 4th bit always turned on.
You probably know more about redstone circuitry than I do.
What we're discussing is binary math... 1's and 0's... or in basic redstone circuitry terms... on and off.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffDouble dabble is extremely simple, as far as algorithms go. You should see the process of things like division and square root extraction.
That is exactly what seems to be happening. Since the BCD is a rather large component to build, there are several things that could go wrong. I might just have to smash it all down and rebuild it again even more meticulous than the last times... ugh! I was hoping someone had built something like this and had an easy solution that I might have overlooked. I could just be happy with the calculator actually working with the binary display using torches, but having an actual 7 segment display would be a nice addition.
Check out my YouTube Channel: http://www.youtube.com/tooligan23
-
View User Profile
-
View Posts
-
Send Message
Retired StaffWell this is a horribly inefficient idea, but you could always use a binary to unary decoder and have the unary outputs controlling ROM lines sending signals to a 7-segment display. I've done it before, but never for something of this size, it's only practical up to around 5 bit data. Don't give up on BCD yet, I've been running the idea through my head of building a machine that processes data based on the double dabble algorithm. Granted, it won't be as fast as Benny's full adder array, as his is an asynchronous design, but you would be more than welcome to use it.
I'm thinking of something like a miniature specific-purpose CPU, built exclusively for this process. It would have a little device like an ALU. It would only take information, send it through a comparator-like device along with a series of 4-bit adders, IF INT >4 output triggers the condition is met for +3. From there, data goes through a left shift mechanism and outputs to a register, the next cycle ticks the Cin of said register, starting the process all over with new data. Number of cycles will be determined by an indexing mechanism, similar to the one I built for the HDD, but in this case, n cycles is determined by an n-bit value. The clock will cease and a control bit will enable the final output. The next time the machine is activated, a reset line to the indexing counter will be activated prior to data being sent to the initial input.
I am not giving up on this BCD decoder just yet. I think there has to be something that I keep overlooking. I believe that I am just going to tear it all back down and rebuild it yet again. In theory the way this is built should work correctly on the XBox now, but I could be wrong on that as well. While the BCD isn't that complicated to build once you get the pattern down, it is almost as large as the calculator itself:
Check out my YouTube Channel: http://www.youtube.com/tooligan23
Check out my YouTube Channel: http://www.youtube.com/tooligan23