Another quick fix made jumps from the overflow/wraparound position possible. In the first design, the cooldown after normal progression obscured the jump signal. This allowed a fully contained division
by addition in eight commands. How do you divide by adding up? Pretty easy - store dividend, divisor and running total in three registers. Add divisor to running total, check if the result is bigger than the dividend. If not, increment the quotient counter by one and add again. If the result is bigger, stop. The result ends up in the counter.
Dividend in Reg. C, Divisor in Reg. A. No further requirements.
#prime counter and running sum register
1. 000 000 - set buffer to zero
2. 001 100 - store buffer to counter O
3. 001 010 - store buffer to reg. B
#main loop
4. 010 000 - Add A+B, store in B
5. 100 000 - compare B>C, skip next if condition not met
6. 111 110 - halt (when done)
7. 011 100 - increment counter O
8. 101 011 - jump to 4.
0101 100 011 : 0000 011 000 = (0000) 001 110 (only six bits countable)
355 : 24 = 14 (after the fifteenth addition, running sum is 360, which is bigger than 355).
It took a while to run. 62 operations required means about 20 days. FPS was complaining bitterly all the way. Seems when 40 hatch covers open all at once, you can't expect double-digit frame rates. It's between 20-25 during less intense operations, ~40 when the computer does nothing.
N.B.: this was a major breakthrough for me. I really just entered data and program, and ordered the "operate" lever pulled. From that point on, the machine did everything autonomously. No malfunctions, no interventions required.
The core of calculations is an instant-result adder following Jong's design: the obvious strength is that it calculates all carries instantly. But you still need to "input" that into the sum calculations. The solution was, (i think) also presented by Jong: you can also instantly calculate the "not-carry" in pretty much the same fashion. This way, you get a sum either when you have a carry-in and A-line and B-line input are equal, _or_ when carry-in is off and A and B are inequal. Result: no need to convert your carries from power to signal for summation, there are no delays. All calculations are effectively done by establishing power paths, which happens instantly whenever inputs change. The result still needs to be converted to a signal, but timing and regulating of that process becomes much easier without delays within the adder itself. Very handy for automated data processing.
Author
Topic: What's going on in your fort? (Read 6102301 times)