First of all:

I know there is a forum explicitly for "all things minecraft related" but it just seemed to projecty to remain in that forum (If you're a mod feel free to move this post if you feel otherwise.)

Second of all:

I'm not using any command blocks period. Pure redstone ladies and gentlemen.

###

I have already constructed the following components:

-Seven segment display with operation display and error message display
-16 byte ram module for multiple operation use
-Control center with keypad, ram reset, etc.
-1 byte adder/subtractor
-Decimal to binary encoder
-Data bus
-BEC to 7 segment display module (this took ages)
-Programming chip (more like a city) with 10 serial ports
-Universal clock

Take a look at the below posts for MUCH more information on where i've gone with this.

Dang, this sounds complicated. But really neat!

If you are using xbox one, you take a screenshot by double tapping the Xbox button

If you have a 360, could you just take a picture of the screen with your phone and upload it?

I'm working on it.

I am interested in seeing this! Good work CalcMeister!

On the x-box? I haven't been keeping up to date a lot, but aren't they behind in redstone updates?

Not on the 360; I'm completely up to date with the latest addition being End Fortresses, Elytra, and Potion Arrows.

I haven't posted in this topic for a while, but I've still been working on it. One of these days I'll wrap up one of these projects. Anyway, I've worked a lot on the program interpreter, or "chip" of the computer. I've outfitted the program interpreter with a series of 16 serial ports. The program interpreter currently has six commands, Input, Output, Repeat, If, End, Quit. Each command is currently 19 bytes maximum. The program interpreter also includes one byte of memory built in (does not require a serial port) which is queried and edited exclusively by the program interpreter. I'll just call it temporary memory.

Each command is structured as follows:
Bits 1-3: Specifying command to be used
Bits 4-11: Argument 1
Bits 12-19: Argument 2

Input---
Command number: 000
Arg 1: Serial port to query
Arg 2: Unused
Sends specified serial port input to temporary memory.

Output---
Command number: 001
Arg 1: Serial port to send to
Arg 2: Unused
Sends temporary memory to specified serial port.

Repeat---
Command number: 010
Arg 1: Byte to be equal to
Arg 2: Serial to be equal to
Repeats a loop until either Specified Byte or Specified Serial is equal to temporary memory.

If---
Command number: 011
Arg 1: Byte to be equal to
Arg 2: Serial to be equal to
Skips the following commands until End if Specified byte and Specified Serial are both not equal to temporary memory.

End---
Command number: 100
Arg 1: Unused
Arg 2: Unused
Ends a Repeat loop or If statement

Quit---
Command number: 101
Arg 1: New byte
Arg 2: Unused
Restarts the program to the beginning and sets the temporary memory to Arg 1, unless Arg 1 is 256

The idea is that the serial ports will be connected to things like screens and math chips, making the calculator more of a computer and having have the ability to be very modular. I'm working on a rudimentary command line interface as well that will interact with the program interpreter.

Here's a list of the components that I plan to build that will interact with the 16 serial ports:

6-8 digit 8 segment display (for floating point operation output)
2 byte Addition/subtraction module (may require 2 serial ports for the different addends)
Multiplication module (may require two serial ports)
Division module (may require two serial ports)
Random number generator
Input device (keypad, etc.)

I've rebuilt most of the program interpreter to run on 5 byte commands (40 bits) due to the fact that I will almost certainly be dealing with computing numbers above 255. The new integer cap will now be 65535, which should be enough for my purposes. I'll also be upgrading the one byte of built-in memory to 16 bits, for obvious reasons.

Command Map:
Bits 0-3: Specifying command
Bits 4-7: Unused (Will most likely be used for boolean arguments sometime in the future)
Bits 8-23: Argument 1
Bits 24-49: Argument 2
Again, each argument is 2 bytes maximum.

P.S. I'll get around to screenshots at some point, gimme some time!

I've gone about as far as I'm going to go with addressing the elephant in the room. How am I going to build a h*cking binary to decimal converter? I can very easily do binary to hexadecimal, simply converting in groups of four, but that's not the elegant way to do it. As much as I wish it were true, the worlds number system is based around decimal, not hex. I've read about using hex as a sort of liaison between binary and hex, but I don't exactly know how that makes the problem ay simpler. Does anyone have any ideas at all?

P.S. This is my fourth post in a row without a reply. I'm begging you.

I actually think this is pretty freaking awesome! I had the time/patience/dedication to pull off something this awesome!! You are cool, CalcMeister

Hexadecimal is just another way of representing numbers; if you have a binary representation of your number in redstone as a series of on and off signals, with each place twice as significant as the previous one, then simply grouping those into sets of 4 gives you hexadecimal nibbles, but you still have the problem of actually displaying the results, which I assume is why you want to turn the binary into decimal in the first place? A common approach is to turn your binary number into a series of BCD (binary-coded decimal) digits, then feed those to 7-segment decoders, which in Minecraft would activate seven-segment-redstone lamp digits.

I did something like this in the past, and did something similar.

I had *memory banks* with piston feed tapes, and one of these was my output/display ROM. It had 9 rows, and each corresponded to a digit, and the other two were cauldrons indicating which number it was on.

I also had other ROMs for displaying math 'n' stuff, and had a semi-working RAM system (BAD IDEA DON'T EVER DO THIS, IT'S A HUGE PAIN) that had long feeds of glass and stone, and it worked like a punch card system. If I wanted to use a different operator, I'd input a different section of blocks. (Not manually, of course, I had some hard-wired systems do it. I tried to get the blocks to sort and go back into the feed tapes, but I never got around to that)

Indeed, implementing a ROM (not RAM) of sorts as a translation table is how actual hardware does it. Take a look at pages 4 and 8 of this datasheet of a real IC that does binary-to-BCD translation (and note how many of them it takes to decode 5 decimal digits (decades)):
http://www.utm.edu/staff/leeb/DM74185.pdf

I took a look at it, and it seems that this issue is not going to be fully solved anytime soon. I've decided to take the easy route and simply convert binary to hexadecimal, and then output that on a something-larger-than-7 segment display. This doesn't contain the computer at all except on the terms of output, as all the math will be done with binary logic.

P.S. I've done a great deal of work on the program interpreter, though it takes horribly long to build. To put it into perspective, I have to create a minimum of 64 programmable lines (128 blocks), each of which are 40 bits long (80 blocks), with rows of redstone above and below them (3 blocks). The result is having to place approximately 30,000 blocks, not including other components of the program interpreter such as the temporary memory, general bussing, and mechanical instructions for each command.

Couldn't you use clone commands to speed up this process? Technically it is only using commands to help build the redstone, and the redstone itself is still legitimate.

Remember, I'm doing this on an Xbox 360, which doesn't have access to a command line in Minecraft.

I've divided this project (making a redstone powered Turing Machine of sorts) into different stages that I'll tackle in steps. Here's a list of what I'm working on:
Not started
In progress
Complete

Creating the program memory (waffle ROM)
Creating temporary memory register
Hardwiring command instructions
Input
Output
Repeat
If
End
Quit
Hardwiring looping and line advancement tools
Connecting command arguments to specifically clocked serial ports
Parallel to serial converter (and vice versa)
Connecting command arguments to temporary memory
Creating command line interface

Current step: Hardwiring command instructions

I've decided to switch from serial ports to parallel ports, because it just doesn't make sense to have a port send a set of bytes over and over with a complicated and not entirely reliable converter. Parallel ports eliminate the need for a converted, and allow the data to be read at any time without waiting for the signal to start over.

Also, once I'm finished with this project, what do I do with it? I'm not sure if there's any way to export Xbox 360 game files, but if there is then please tell me! I don't think there's a proper place for this in the archives but I'll find some way to make a download.

I don't know off the top of my head an easy way to do it, but I found several tutorials here
Keep it up! now if I only had Minecraft...

ps. don't question my search engine.