From left to right: marble lever for multiplication, graphite lever for subtraction, big positive/negative sign, eight malachite hatch covers displaying the memory status, reset levers for every cell directly north of each hatch. The whole linking up took so godforsakenly long that i didn't use a single big reset lever and built them as the usual shitty 'must cycle back and forth' type, which causes even more operation delay. They can't be cycled by multiple commands because those'd likely catch the carts mid-transit, you have to wait until the 'on' command has taken before issuing a whole new 'off'.
Well, to subtract, we need some numbers. Let's pull some numbers out of a hat: ask the DNG (Drunk Number Generator). As per usual, the first pair of numbers was completely useless for our purposes : 1110 0111 and 0010 0101. Not a single carry needed to process. I ordered a third number, and while that was similarly shitty, i stopped fishing for interesting numbers and just punched it in: 0001 0001. Subtract that from the second Drunk Number above means we're calculating 37-17.
By the way - snapshot of the DNG display:
Yeah, putting it right into the meeting hall wasn't such a bright idea.
The numbers were entered into the double memory array explained in earlier posts, and the bits 8 to 1 were transmitted to this read-write loop:
Snapshot made with the first pair of numbers. The cart starts in the northwestern corner and goes from highest to lowest bit, checking the first memorised number and setting the processing memory to one if an on bit is encountered, then checking the second memorised number and sending a 'subtract' signal to the proc.mem. when an 'on' bit is found. Any following carry operations are resolved by the processing memory itself. It consists of eight such cells:
The core is a binary counter cell, but it has a binary branch built into each of its 'switch' loops, sending a further signal or not. The 'on' half is on the right, where the pressure plate sits right next to the upwards ramp. The cart is currently in the 'off' half. An 'add' signal opens the southwestern hatch cover, allowing the cart into the southern switch loop, and the southmost hatch, allowing the cart to pass the loop without touching the pressure plate. In addition, it opens the northeastern hatch cover, allowing a cart in the 'on' half to pass into the northern switch loop, but doesn't open the northmost hatch cover, so the cart passes over the northern pressure plate, which works as 'carry' trigger and sends another 'add' signal to the next higher bit cell. Subtraction does basically the same, just in reverse - allow passage from on to off without sending a carry, send a 'subtract' up the chain when passing from off to on.
So what the read-write loop does is just read signals from the write-able memories and send them to the processing memory as simple instructions, all the proper adding up is done by the memory itself.
All numbers have been entered properly, so it's time to Pull the Lever. Incidentally, any lever pull is acceptable for starting the subtractor, because the lever pull is sent through here:
A very simple switch that sends an intermittent 'on' on each lever pull - when the lever turns on, it opens the hatch cover on which the cart sits, the cart falls into a booster pit, leaves to the east, over the plate, and starts cycling around the closed loop. When the lever is switched to off, the cart bounces out of the pit, around the corner, over the plate and back onto the closed hatch. The lever is, of course, linked to _both_ hatches, or this wouldn't work. The plate opens the hatch on which the cart in the processing loop sits, and obviously closes it again after a hundred steps, so the cart is guaranteed to return to a closed hatch and won't accidentally run the operation twice because Urist McLeverpuller was too drunk to show up and close the lever again.
So the lever (graphite) was pulled, and this is the result:
'Off-colour' spots are 'on' bits, so 0001 0100 = 20.
Time to re-set the memory, get some fresh numbers and run the multiplication.
The DNG was a bit less of an arse this time and offered 1110 0101. Since i went for a very rudimentary proof-of-concept with multiplication, this is already enough - two four-bit numbers, all the multiplier can handle. I ordered the 1110 entered into the first memory, 0101 into the second, and, after the processing memory was reset, ordered the marble lever pulled, starting the cart in this loop:
The top row was built with my normal design - on adding/subtracting loops, the diagonal offset doesn't matter - but of course, for multiplication, i needed a proper return track to the next 'first number bit' check. The first (leftmost) gates in each row check whether the first factor has its bit set here, and if this isn't the case, skips to the next row. The 'set-ness' of bits of the second factor is checked in all 'on' rows, and for each 'on' bit, an 'add' signal is sent to the processing memory, to cell (i factor 1 + i factor 2 -1), so the second plate in the second row sends its signal to (3 + 3 - 1) cell five of the processing memory.
The plates in the top row don't send 'add', only 'set' signals, and the last plate also only sends a 'set' signal. We're starting from an empty memory, so there should be nothing to add _to_ in those locations at those times.
Result:
14x5=70, or 1110x0101=0100 0110.
But what if we subtracted a large number from a small number? Hmm, let's try: growing impatient with the DNG, i picked 42 as first number and 81 as second.
0010 1010 - 0101 0001 = ?
Yadda yadda, clear processor, enter numbers into writeable memory, pull the lever.
Oh-ho! The sign turned to a minus, and the colour scheme inverted. Since off-colour tiles are supposedly 'on', that means our result is ... -38?
Yes, i've been my usual stupid self and didn't account for the one-point offset when inverting binary. It would be possible to correct this by sending an extra 'subtract' when getting a negative result, but i don't know how to set this up properly - the 'overflow' could happen quite early, long before all bits have been processed, so a -1 could overlap with other signals, cancelling them out and producing false results. It could also happen quite late, long after the cart has finished its loop (e.g. when subtracting two from one, carries take quite a while to propagate up the chain).
The only safe way i can think of right now is too horrible to contemplate: eight of these things
in sequence, and _two_ subtractor loops. This is a case-sensitive equality/difference-gate - it gives one output when both inputs are equal, and if the inputs are different, it will output one of the two paths north of the 'double hatch', depending on which input is on and which is off. At heart, it just determines which of two numbers is bigger, and this entire contraption only checks a single bit, so it'd have to activate yet another such gate when both bits checked are equal. _Then_ a cart would be sent on one of two subtraction loops, just calculating the absolute difference between the numbers and presenting it with a positive or negative sign. As a small consolation, the subtraction loops would only need seven bits to operate on (if there _is_ a difference on the first bit, that would already be known without comparing the numbers) and the cart wouldn't need to process at all if there was no difference before the smallest bit is checked.