Hello there.
This is my first post here on forums. I'm quit'a new here. Thanks to EqualsThree, problem with attachment was fixed.

[EXECT TIMINGS]

 [October 20, 2012(first version)]

 15/2: 22.8 seconds

 9/3: 11.2 seconds

 any +: 2.5 seconds

 any -: 5.3 seconds (yea, subtractions is it's weak side. They should be same to "any +", but the time is doubled. Fuuu.)

[COMPONENTS]

For sure you all have seen an outline in the corner of the save. Now I explain what each area contains.

Yellow marks: A, B and Command inputs

1) Register A with invertor

    Your first number gets inside of it. It has 2 implemented commands: send inverted number into (6) and

    send the number without any changes.

2) Register B (simple storage)

    Simply saves and sends second number into (6)

3) Returning bus(return-in-memory wire)

    This bus can easily be detected on the right side of the ALU. It has 2 4bit channels. One of them serves

    as a connection between (2) and (6), and the second one is used to send a result from (6) BACK to (1).

    That second channel is in a hard work while ALU divides by continious subtractions.

4) ALU processor

    The heart and brain, coordination center for all of the components. Uses (5) to send them signals about

    what to do and when. Also stores "IF" and "cycle" instructions for subtraction and division functions. You

    send a command "+" "-" or "/", and it "sparks" all you need by itself. This ALU is the fastest divider in PT,

    mostly because processor is integrated inside of it.

5) Components' inlets

    Simply connects (4) and all other components.

6) Summator

    Adds A to B and stores the result. Is directly in the center of ALU, also the most complicated part of it.

7) Counter

    Counts how many times ALU has subtracted while dividing. The result of division is coming out of the

    counter, not from (6), as for other functions.

I want to add a name. A name of a Guy who inspired me on it a year ago. Mark2222. Respect and memory!

(sorry for bad spelling, not engrishman)

Below are coming tons of text on my daily updates.

[UPDATE 1]

Substraction "bigger from smaller"

 Works fine, i guess. It emmits MINUS ray, and writes a result on modulle!

Also, once again, you press ACTION key THE LAST, after you entered BOTH numbers

[UPDATE 2]
Hey guys, just forgot to mention. It is 4 BIT. If you add, and the answer should be bigger than 15 (4th bit), you should add 16 to what the machine writes. Example 9+9=18, but it says 2, cause it's limit is 4th bit. 16+2=18, so everything is ok.

Also, I will work on inside delays for several days after, i'll for shure make it 2%-10% FASTER, espesially in divisions. It was made waaaay back in versions, so now it's a bit slower than it was back these days.
It IS actually possible to make is without DLAY elements. But it could be 3 times bigger... So yea, no WIFI, but I used some DLAY (also almost-a-cheat for me)

[UPDATE 3]

Okay guys, thank you for such a warm feedback and 20 likes! YAY! Gonna post a huge update now, as you are interested!

First of all: Found bugs. I knew about a loop on by-zero-division, but just forgot to mention it. So yea, it divides by zero forever, cause zero can "fit" in any other number unlimited amount of times))) There came the question - How the hell it divedes? And I'm gonna answer that one.

It was created basically for fast division, and it uses 100% of ALU's current counting power. A half of a year ago I asked my self, if it was possible to divide using summator? For those who don't know binary it seems impossible. But it is achieved now. I'm not any kind of a smartass, I'm just a schoolboy, who is studying computers in school like you all are. And I actually know, that a-b=NOT(NOT(a)+b) for binary numbers. That's all I knew when I started making this ALU. To divide a/b, I subtract B from A as many times as A is still above zero. You see when it divides it makes repeated subtractions and counts the amont of that subtractions. This amount is the final answer, that's it. to divide 6/2 it subtracts 6-2=4; 4-2=2; 2-2=0; 0-2=-2; and the counter stops in the middle of the fourth move, writing answer 3.

This afternoon I found some bugs with subtractions(as separete function). For ex. 0-9=-8 somehow. I already know why it failes and gonna work on it. 90% of all the bugs I were founding in the ending phase of making it were caused by BRAY (ARAYs were crossing each other, causing one of them fail to send a signal). This can be easily fixed with FILT in the right places. Feel free to write if it counts something wrong!

Secondly: It is ALU, not calculator by origin. The keybord and a screen is made/copied just as testing-tools, and I want to say once again, that the whole show is only for that small rectangle complicated scheme in the middle. It was made to be used as a part of a Powder Toy PC, not with directly keybord and screen. It's a binary computer component, and in case you are making one - you can use my ALU as a part of your safe.

It is 4 bit now, and I see you ask if it could be 8 bit and operate with bigger numbers. Defenetly ALL of the components can be extended to any amount of bits, as all of them are made from 1bit elementary blocks. So, I'm thinking about making a 8bit version. There are 2 big obstacles: I have no decoder-to-decimal + screen for such an upgrade. And I'm scaryed about the size of the returning-in-memory-wire, and about the whole size adjustment. I'm working on solving the second problem. But I have no desire to solve the first...

Size is my 2 main target, after speed. It always should be MINIMAL POSSIBLE, no other way. Look carefully while you zoom in, and you'll see that space is used with maximum profit now. Dozen of hours was spent onto making it from nothing, and half of that time I was thinking about making something smaller.

That's it up to now. I'm gonna post more updates later.

[UPDATE 4]

I've started overclocking it. Several minutes of work with summing function - and I've managed to overclock it by 10%, reaching 2.25 seconds time for this action. This made me put some new FILT inside of it, and overall performance is unstable, so I won't publish owerclocked version untill I see that everything works smooth.

It has really great overclock potencial, but on the other hand it becomes really risky and unstable. In a current(first) version all the delays set in order to let BRAYs disappear. But when you push it to the max, previous BRAY lines are not in time to disappear and the new come out. But of course I'll find a way to make fastest possible stable version soon, and update all the timings!
While working with delays, I found a terrible structural error in an ALU's processor. When your summ result should be more than 15 (out of memory), it partly activates subtraction functional line. This does not affect the result, but affects the next operation you gonna do. This is why right now I want to ask you to reload the simulation and try again if something gone wrong. Actually summing and subtraction is more unstable than division now. Espesially "out of memory" and "minus result" cases.

[UPDATE 5]

First of all quick tip: press 8 ingame, increases fps to 61 even on my shitty laptop! And looks better!

Tycjan13 is absolutly right about the shitty way I chose to divide numbers, continious subtractions... I could not do bigger and more complicated ALU, that uses other, faster way to divide, back these days... Remember I said it's the fastest and most compact divider in PT. It's true, because It operates only with small numbers. Now I see, that making it 8bit has 1 new biggest obstacle: increasing division time. For answers more than 100 it will take several minutes to divide. Now I'm paying for such a small and nice construction. I like how small it is. But It has no future in 8bit, if I just extend all components by 4.
Mark2222's awesome PTPC was 4bit on the whole, and even now I think that 4bit is how the data should be stored in PT, due to the small working screen. For those who think as me - I'll leave this version free to use for you (I'll finish debug and overcloking). For others, who want 8bit ALU - I think it's possible to make only-summator-binary-big numbers-divider, but It will definitly be different in it's core and processor. Division time definitly should not go to the amounts, when you'll fall asleep, while waiting for result). Maybe my next ALU going to be first-ever-double core/flow-processor in Powder Toy. Maybe It's goint to divide like real PC do (I'll figure out how).
All I know now is, that if i'll make a 8bit ALU, it is going to be electronic revolusion. Or I won't make it at all. All I need now is time, which I can spend on making it (too few spare time now), and I won't make shit.

EDIT: I found the way I can divide REALLY fast any number by any number. BUT it's EXTREMELY hard to achieve it PT. I'll start working on it when the holydays come (soon). Also, I'll post all the components' description just now. See you!

@Potbelly (View Post)

 Man, really appreciate your work about testing!!! Thanks for the comment, i'll now write an update about bits number and zero division!

Only now I realize how buggy it is... Not on a level of quality, that I wanted it to be... But as soon as I realize that I've used unextendable to 8bits division tecnology, I lost a desire to fix it, or overclock. Why should I work and lose time to improve a tecnology, that can't be used in high-numbers division?

I'll just leave it here, nostalging from time to time how small a WIFI-less divider can be.