Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Larix]

Fuck, took too long to compose the message and the forum swallowed everything i typed upon asking for a preview. So this is gonna be a bit terse:

I built an adding machine. All based on perpetual-motion minecarts and hatch-operated pathing logic.

Spoiler (click to show/hide)

Display after adding 1111 1111 1111 and 1:

Looks like the propagation of the carry bits works alright. Now, let's go for an actual addition.

Status of the main memory. All dwarf-operated controls of it are visible in the picture, a general brake (orthoclase) and one 'set to zero' lever, the marble one to the east. The western one was just for testing the operability of the first cell, to make sure the concept worked before building fourteen of the things and linking in ~ 150 mechanisms.

All input to the main memory comes from here, the 'read-write cart':

Starts from the northwestern corner and goes once around, in this order:
start -> 12 - 12 - 11 - 11 -
       - 9 - 9 - 10 - 10 <-
      -> 8 - 8 - 7 - 7 -
       - 5 - 5 - 6 - 6 <-
       -> 4 - 4 - 3 - 3 -
end - 1 - 1 - 2 - 2 <-
(back to start)

It can accept two inputs for every bit (and the main memory will actually _add_ them to its currently stored number, including the carry operations, which is why the cart moves from highest to lowest bit).

Of course, the cart must have its own input as well:

Yep, the 18 levers in the top left are the entire dwarf-operated controls of the machine. There are twelve input levers, 'highest' bit in top, 'smallest' on the bottom, currently, all levers are set to 'off', but the memory banks don't care, because they have their own control levers currently set to 'store' their old input. The northern memory bank can only be cleared by directly entering 0000 0000 0000 into the levers and switching its 'store' lever off, the southern array can be cleared by switching its 'store' and 'read' levers off. The northern array currently stores the number 1101 0001 1100, the southern one 1011 1001 0011. Those added to 2^13 should give 10 1000 1010 1111, right? Well, pull the lever (the rutile one), and hey presto! (two days later), we got our result. To test the limits of the machine, i just added the same number again, and raised a red flag, it seems. So i ordered the reset lever pulled twice, and the main memory was cleared.

Result: too much: after reset:
It's better at binary than i am I actually mis-calculated both results and only got the correct result (which the machine of course got) after going through the number twice.

[Larix]

Inner workings of The Marble Bookkeeper:

Counting numbers:

Spoiler (click to show/hide)

The heart of the main memory is this array:

with buildings:

It's a counting circuit. The three-part ramp is engraved with a w-e track on the western, a n-s track on the norther branch, and a NSE track t-junction on the 'corner', the tile covered by the hatch. The peculiar thing is that when the hatch is open, carts will pass straight through the ramp, but if the hatch is closed, they will invariably be sent out to the north. In the circuit seen here, a cart entering the counter while the hatch is open will pass w->e through the ramps, into the booster pit in the SE corner (for speed regulation, cart gets too fast otherwise), around the loop and back into the pit. Once the hatch closes, the cart is diverted to the north and starts bouncing back and forth between the wall/up ramp and the closed hatch in the pit. Once the hatch opens again, the cart leaves the circuit to the south. It was the most reliable way i found to count distinct signals. It will not accidentally 'double-count' a single signal, because it's only ready to process a new 'on' once it has received an 'off'.

To actually count with this circuit, you have to stick at least two of them together with appropriate paths and link an input to all hatches. You can build arbitrarily large counting arrays, but linking up ten at once is already a chore. Operating directly in decimal would also be quite difficult, because you'd need to add pathing that allowed 'setting' the cart to a specific cell or somesuch, and i've no idea how actual mathematical operations would have to take place. It's much easier in binary:


Two basic counters leashed together. When the cart's in the left-hand cell, like now, the 'bit' is at zero, no output is sent. When a signal arrives, both 'operation' hatches open, and the cart moves through the top 'switchover' loop into the right-hand cell. As long as it's there (regardless of hatch status), the bit is 'on' and the pressure plate is kept active constantly. When the cart receives another signal, it returns to the 'zero' half, but this time through the southern half-loop. There it enters a straight two-ramp pit, bounces back and circles around over the pressure plate before arriving in the left-side counter. The pressure plate sends the 'carry' signal to the next higher binary counting array. The ramp in the southern loop is there for the 'reset' functionality. The 'reset' lever opens the _right-hand_ hatch and the hatch in the switchover loop, allowing the cart passage _without_ touching the 'carry' plate. This way, all carts currently in the 'on' cells can be ordered back into the 'off' cells without sending erroneous carry signals messing everything up.

In principle, this array could be 'set' to one or zero at will, by linking it to one device which sends a signal exclusively to the hatch in the 'off' cell (to set the bit to 'on') and to another device which resets the cell (to set the bit to 'off'). I didn't do this, because i had a crazier idea.

Automated input:

Spoiler (click to show/hide)

Since my basic premise was an adding machine, i didn't bother with subtleties like 'writing to memory', since 'add to memory' did exactly what i wanted and writing to memory can be simulated by simply resetting the main memory before reading the input (proper writing to input would still be possible by running a circuit that takes an input and 'sets' the memory to the values found, as pointed out above).
Since i was sending signals to an adding machine, i needed to make sure the inputs from signals read weren't too close to each other - without an 'off' signal, the adder doesn't accept new input. Fortunately, with perpetual-motion minecarts, there's an easy solution. Self-timing.


The cart arrives from the west. If the hatch is closed (input is off), the cart bounces back out of the ramp, around the corner and on to the east without sending a signal. If the hatch is open, the cart passes through the pit, onto the pressure plate (on top of a SW track corner) and into the pit. The pressure plate operates both the actual output _and_ the hatch-cover on top of the pit. As long as that hatch is open, the cart is caught in a closed circle composed of the flat tiles south of the pit and the two ramps inside the pit. Once the pressure plate resets, an off signal is sent both to the proper output (switching the binary counter cell back to readiness) and to the hatch cover, which closes and forms a bridge over which the cart passes to the north and then east, to the next input check. My double-input reader has twenty-four of these arrays, each linked to one of the input providers and one of the binary counters in the main memory.

I thought about splitting up the read-write process into smaller sections, but couldn't come up with a viable way to prevent errors from signal intersection - the 'carry' signals propagate 'up the ladder', so would almost certainly get all in the grill of a cart processing the higher bits. My single loop is quite time-consuming, but seems to work accurately. The built-in delay was long enough to flawlessly add two different inputs to a sizable number already stored in memory.

Writeable "memory":

Spoiler (click to show/hide)

The input providers - detachable memory cells.

To the left the simpler design, to the right the one with an extra hatch that can be switched off entirely. You might notice the three-part angled ramp from the basic counter, and indeed, it makes an appearance here. It's what allows me to keep the carts away from the actual input, the unassuming N-S ramp-pit to the far left. If the hatch there is open and the cart passes through (from the north), it passes through the southern loop, through the s-n stretch, around the northern loop and N-S through the angled pit. If the hatch over that pit is open, it will stay in this loop and won't return to the input ramp.
If the input is 'off', the cart will bounce out of the N-S pit, gets bended around east, goes w-e through the pit, bounces against the eastern wall and gets pulled back into the angled pit from the west again (there's a s-e track corner underneath the marble boulder). Once again, as long as the hatch over the angled pit is open, the cart will stay in the loop and won't return to consult the input.

If the 'store' hatch over the angled pit is closed, the cart is sent to the north out of the pit, around to the west, and where it ends up thereafter depends on the input's status again.

The simple design has only the 'store' hatch for control. When it's open, the cart keeps its status, when it's closed, the cart acquires the status prescribed by the input.

The 'advanced (?)' design has an additional downward ramp visible - that's the southern half of a N-S double-ramp pit, and this tile can be closed by a hatch. If the 'store' hatch is closed and this hatch, the 'kill' hatch, is closed as well, the cart bumps into the wall and comes to rest on top of the hatch, effectively turning the cell off. Once the hatch opens again, the cart falls into the pit, picks up speed and moves out to the south, to proceed as normal.

This 'memory cell' can store its once-acquired status for an arbitrary time, regardless of later input changes, because as long as it's ordered to 'store', it completely ignores all input. It can send signals for both 'on' and 'off' signals if desired - a cell set up like this would in fact need the 'kill' hatch to send no signal at all.

This detachment from the input allowed me to set up these two memory arrays in such a manner that they use the same array of twelve levers for input. In addition, a memory's contents only matter to the machine itself if the read-write cart actually processes it and sends the derived signals to the main memory.

So the adding-up was mostly to have a presentable metric while playing around with comput-ish concepts like memory, defined processes to operate on it and of course 'writing' to different storage arrays using the same input mechanism. I even found the time to add a little 'error' signal - the malachite bridge over the clay floor that gets retracted when the 14th bit wraps around. If i hadn't linked the reset of the main memory to a lever already, i might have tried concocting a device to force a reset. But i just wasn't going to link all those 28 hatches up again, finding individual hatches to link in that list of well over 200 would have been a nightmare. On the whole, the Marble Bookkeeper was built without any real setbacks - two misplaced pressure plates, one hatch overlooked in the display link-up and three hatches wired up wrong - but everything was found in the preliminary testing and corrected with minimal fuss. I was using components that had already proved their functionality, but the exact circuits shown here were all designed for this project, so i built a few test rigs for troubleshooting and attempts at optimisation. This allowed spotting a serious bug in my first design for the read-write array. The full 24-part array was built using the corrected design and worked flawlessly. It took several game years to construct and the total material consumption was around 600 mechanisms, 200 hatch covers and not much else. Well, apart from the 40 minecarts. When a lot of bits were being processed at the same time, the game did slow down notably, level-changing minecarts eat a fair bit of FPS, as do opening and closing hatches.

Of course, that's still all little fishes compared to the true behemoths of dwarfputing, like the great dwarven calculator (i haven't the first idea how to do anything but adding in binary) or the eight-instruction computer (i'm not entirely sure what a bit shift really is, nor what good it is).

[wierd]

This one's just a simple integrator, but impressive all the same.

I'd be much more impressed with an instruction pipeline, and a microcode array based general purpose cpu design though.

Say, an implementation of MOS6502.

It would probably bring df to its knees though.

[Larix]

Inte-what? What kind of pipeline? Microcode?
I don't understand a word. I was just banging stuff together and having fun. If this gives anyone ideas to follow up on, so much the better.

Just a word of warning - thirty to forty carts buzzing around simultaneously already make DF pretty unhappy, even more so when several additions take place at the same time. Sometimes i was worried the read-write cart was going too slowly and might just stop, but it was only the game slowing down...

[Tevish Szat]

Dwarven computing (that is, building a functional computer inside DF) is, surprisingly, decently developed.

Some day, we'll develop a dwarfputer capable of taking complex enough input to run Adventure, though I shudder at the size of embark that would be needed for the RAM and processor.

[wierd]

*bah.

Double your pleasure, double your fun; android phone makes doubleposts, son!

[wierd]

Inte-what? What kind of pipeline? Microcode?
I don't understand a word. I was just banging stuff together and having fun. If this gives anyone ideas to follow up on, so much the better.

Just a word of warning - thirty to forty carts buzzing around simultaneously already make DF pretty unhappy, even more so when several additions take place at the same time. Sometimes i was worried the read-write cart was going too slowly and might just stop, but it was only the game slowing down...

in computer lingo, an "integrator" is a simplistic computer capable of doing "integration", eg, very basic mathematics, like addition and subtraction, in an ordered and programmable manner.

"Mircocode" is a programmable set of what are essentially switches, that controls what gates inside a processor engage when presented with an instruction word on the instruction pipeline. Errors in the way a CPU processes data can be corrected by updating the CPU's microcode, which is why it is used. It is basically a very tiny EEPROM adjacent to the main ALUs inside the CPU's processing center. Some CPUs, like the NEC V20, did not use microcode, and instead used hard wired logic. That cpu was measurably faster than the intel chip it was competing with, because the processor didn't have to evaluate the microcode in order to perform an operation. But, because it was hard wired, the chip could not be corrected if an error in that logic was discovered. Thankfully for NEC, they never found one.

And, an "instruction pipeline" is an ordered list of computer "words" (2 byte being the smallest usually used) that tell the processor what to do with data presented to it on its input registers, which gets pushed and pulled as needed as the computer executes the instructions in the list.

One of the most well known and replicated general purpose processing chips that has all of those features is the MOS6502 cpu, created by MOS semiconductor in the mid 70s.  It was the heart and soul inside a great many devices for quite some time, including but not limited to, the Nintendo NES, the C64 home computer, the first apple macintosh, and many others. (Modern implementations of the cpu are still frequently fabbed for embedded devices! It's just that awesome!)

The wiring diagram and logic table for the MOS6502 is widely available, and is a favorite for cpu hobbyists to replicate using discrete logic components, to better understand the way that general purpose CPUs operate.

It is one of the few general purpose cpus that are simple enough inside for a single person to fully grasp what it is doing at all stages of execution.

Implementing a MOS6502, and a simple 2D bitmap array (say, a field of raising drawbridges) with an instruction pipeline and a memory array would allow the resulting computer to run quite a number of existing software programs from yesteryear pretty much out of the box.

You might even be able to find an implementation of ROGUE. . It is about the right era.

[InfinityOrNone]

It's threads like these that make me want to steal a Cray and do unspeakable things to it until it will play DF, then use it to create a Dorfputer able to play a smaller game of DF on itself.

[Snateraar]

Now, make a random number generator.

[Larix]

EDIT: simple randomish bit generator, one of my first designs:

Takes any input, opens both hatches and the cart more-or-less-randomly ends up either in the left or the right loop. On an 'off' signal, the cart returns to the middle stretch, bouncing between the hatches and awaiting new input. With a counter and 'programmable' memory, this could be used to set individual memory cells either on or off. Four steps should generate a four-bit random number.

Circuits used in the Trinity Clock

The Oscillator:

Spoiler (click to show/hide)

I had promised/threatened more detailed stuff on this machine, mentioned somewhere on the 'what's going on' thread. Here goes:

The heart is the assembly of _three_ oscillators working in parallel. I had stumbled over a very small repeater with a very long period (720 steps), so had decided to use this for a clock. 720:3 is 240, a fifth of a dwarf day, thus the decision to use three of them and feed their signals through a non-distinguishing five-step counter.

The driving force between the main oscillator is the self-derailer:


Two of them, the southern one sends its 'output' cart to the north, the northern one to the south. The ramps are engraved with a hanging track loop, the southern one NW-SW, the northern one NE-SE (from bottom to top). It's rather fiddly to hand-engrave, but you can get the hang of it, it just takes knowing what track bits you want in the end and liberal use of the 'remove designation' command. The cart keeps getting sent into the pit, but the ramp glitches cause it to pick up speed in there, sending it back out - onto the top level most of the time, because the 'forward' ramp is a corner ramp connecting back up, in the southern derailer that leads the cart to the northern bit of the loop. _But_ the cart will eventually pick up enough speed to derail, off the corner ramp, straight north, if an exit is provided. Such an accelerated cart can then be used by other circuits, the derailer can e.g. be used as a simple delay construction, holding a cart up for between 80 and 150 steps (roughly, depending on the speed and direction in which it entered).

In the clock repeater, the derailer sends the cart into another derailer:


The northern derailer sends its cart to the south, on the eastern track. It passes a medium-friction track stop and then enters the southern derailer through the nw corner bit, onto the ramp in the _middle_ of that array. In the picture, the cart currently is on the 'middle' pit of the northern derailer, a ramp with SE track. I had observed that high-speed carts entering a derailer from this location, preferably sped up by another derailer, move so quickly in the derailer they're fed into that they tend to derail on the _upper_ level, i.e. they fail to enter the downward pit properly, instead jumping over it, slamming into the wall and falling into the 'forward' pit directly. Since they're picking up speed from nothing after that, they take a remarkably long time to work their way back up to derail speed.

The cart takes a whopping 360 steps for each half of this repeat cycle, for a total of 720. The track stop is there to slow the cart down a single step, it'd take 359 steps for a half-cycle otherwise. This repeater has proven 100% reliable, the clock hasn't moved off its midnight point in a year and a half (an error of a single step would have caused an error of a full day by now).

Adding up:

Spoiler (click to show/hide)

The oscillator bank produces one signal every 240 steps. Those steps must be counted individually, and five of them assembled to make a day. All individual oscillators must be linked to all counting cycles, because the 'identity' of each signal inside a day keeps switching. Eh, it still only required fifteen plate-hatch links.



From left to right: top level of the oscillator bank, connections on the level below, counting array. The counting array is very poorly constructed, because there's another minecart pathing array of the older clock on the level above, and i couldn't exclude the possibility of falling minecarts - those cause collisions on the level below the place where they land - through solid floors. I had several accidents of that type on the site. The solid walls i left in place are below potential 'falling minecart' locations and seriously gum up the workings of this counter.

Better-constructed counters look like these two:



The northern one counts weeks and sends a 'switch' tick whenever it loops around (after four successful advancements) to the southern one which counts to three and outputs the months - and a once-per season signal for the season counter. Just for the hell of it, i built four 'count to ten' arrays so the entire clock keeps track of the years as well and will only wrap around in the year ten thousand.

Counting the hours:

Spoiler (click to show/hide)

Counting days is relatively simple and practical. So why not go more detailed and shoot for the impractical, like the fleeting (50-step) 'hour'? I couldn't come up with a derailer-based or hatch-timing-based way to produce signals so close to each other - both have stable output times of 90 (derailer) to ~130 steps (self-timered through hatch). There might be ways to get a two-part counter to 'time itself' into alternating signals less than 100 steps apart, but i haven't looked into it yet and it would probably not get quicker than about 70 steps. So the recourse was the simple long-path loop:



Two of them, the one to the left is a bit more complicated, since i had to cram in an ungodly number of medium-friction track stops to slow the cart down enough to produce a usable signal - the active plate to the left. The cart is kept moving at a regular speed along the track by the combination of 'booster pit' (N-S,always only one ramp visible, the ones with the SE track corners leading out of them) paired with a straight accelerator pit (E-W ramps along the track one tile north and three east of the booster exit). This produces a speed of ~ 48000, always.

The carts take about 390 steps for a complete round of the circuit, with a tiny bit of fiddling such loops could be used as a saner basis for a clock. Since the start/end point is a simple E-W booster pit into which the returning cart falls from a NS track, a lowly hatch is enough to turn it into a solid end point which the cart will only leave after a control signal opens the hatch again. Thus, a precise return time is unnecessary, all you need is a precisely-measured point for a 'stepping' pressure plate sending a start signal to a similar loop (which in turn may, after the appropriate exact time, provide the start signal for this array again). I actually went and calibrated two loops to serve as the startup timers for the main clock oscillator, i.e. i built a pickup pressure plate which sent a signal precisely 240 steps after the cart started (on the same lever pull as the first oscillator), sending a start tick to the second oscillator and the second timer array, which would, after another 240 steps, provide the starting signal for the third oscillator.

In total, there are five of these loops, each linked to one of the five 'advancement' signals of the five-step counter turning the raw clock signals into days. In theory, individual 'hour' signals come out of these five loops every fifty steps. In practice, the imprecision of the five-step counter, owed to its poor design, messes up one of the switch signals quite badly, i think there's a delay of almost fifty steps in one case. Whoops. At least the individual hours 'inside' each counting loop are fairly well-defined (49 to 51 steps, most are the exact 50). Since the control signals are theoretically 240 steps apart, which doesn't divide into 50, the arrangement of pickup pressure plates is different in each hour-counter loop.

Display:
A single-'dial' clock face for the hours, 'sliders' for the longer units:

Spoiler (click to show/hide)

The vaguely circular thing is the collection of hour hatches. The signal moves around counter-clockwise and the 'leading edge' open hatch marks the 'local time' hour. I couldn't properly test the signal locations before firing it up, so the game's calendar switches days at the 19 o'clock point (one past the three-quarters point), the clock's own day counter switches around 22 (two hatches to the right of the top). These midnight points have proven absolutely precise so far - the game calendar switch was about ten steps after the opening of hatch #19 one and a half year ago, and it's still at this moment now.

To the south, there's the in-year calendar, counting, from left to right, seasons, months, weeks and days. It gets its inputs from pressure plates constantly held down whenever a cart in each counting array is in the respective cell.

There's also the chronicler somewhere far to the north, but it's just four rows of ten hatches each. I goofed on the years count and linked them up one hatch too high - consistently, so with a tiny bit of mental acrobatics, the readout can be read properly. Decades, centuries and millennia are all linked correctly.

Timely processes

Spoiler (click to show/hide)

Now, just keeping track of time is all fine, but with that many signals flying around, the opportunity to run time-based effects presents itself. Unfortunately, fiddling around inside an active clock isn't really feasible, since it all runs on aggressive minecarts _that never stop_. So you'd have to link everything up before starting the clock itself, or stop and re-start the clock (an unbearable chore when aiming for reliable timing _within the day_ - getting a dwarf to launch a cart within a desired day is already very much hit and miss) or - use relays:



This is the main relay bank for in-year processing, it provides signal pickups for days (left), weeks (top right) and months (bottom right). There's also the season relay bank further southwest. Each circuit's hatch is linked to one associated input and stays open during that period. If there's a cart in the circuit, it will start cycling around the loop, keeping the pressure plate active. The pit contains plain straight E-W ramp leading out into a closed loop. When finishing the loop, the cart gets dropped into the pit again and will _always_ try to leave via the hatch-closable hole. Once the hatch closes again, the cart bounces between the wall and the ramp, sending no signal.

The upward ramps seen are completely useless, i accidentally designated more memory banks on the level directly above and the channelling of course removed the floor and created pointless up ramps on this level. They do play a role for the functioning of the relay banks, however - the day relays were plagued with strange bugs, carts stopping dead or flying out of the circuit. It appears that this was caused by there being _open space_ directly above the hatch-covered ramp and the tile behind it. There's no understandable reason why this should be so, but the open space two z above seems to accelerate the cart so much it gets airborne upon leaving the pit. Once i walled over the holes on the level above, the relays started working properly.

Yes, there are twenty-four relays for the hours, looking even more cramped than the relay banks in this picture. There's no need to put a cart in a relay when you don't need its output for anything: only the relays for the first, sixth and seventh day are actually 'live', the other four are currently empty.

The actual processing:

With the relay-derived signals, all manners of processes are possible. Due to the nature of signals in DF, linking multiple inputs to the same device is of dubious value - the device's position will always correspond to the _last_ signal which called for a position _change_. I.e. if you link the 'first month' and 'summer' signals to the same door, the door will always open on the first day of the first month of each season and close once the first month of a season ends, summer or not. Similarly, since off signals take longer to register (100 steps waiting required opposed to instant 'on' signals), linking directly adjacent time periods to the same device is a bad idea - it will usually close after the first of the two ends and remain closed. For proper time processing, it's thus necessary to link almost every processable signal separately. The resultant circuits can become somewhat byzanthine, especially with hatch-pathed minecarts.

Individual circuits/logic gates i used:

four-input AND gate, to check for a specific day (checking 3rd season, 1st month, 2nd week, 6th day to only return true when it's the 13th of limestone).


three-input AND, to check for a specific week (1st season, 1st month, 1st week). All ramps straight EW, the cart's on a NW track corner, the first input is on (might be spring).


Two separate AND gates, built next to each other to save space (parallel ramp-pits can be placed right next to each other, they won't interfere).

Spoiler (click to show/hide)

 On the top, third week of a month and third month of a season are checked for, the time during which caravans tend to arrive (actually, you'd want to build it so it includes half of the second week as well but i only cared for the principle). The one below takes this input and second checks a hatch simply linked to the season of winter. If the first hatch returns true and the second false - it's the middle of the last month of the season and it's _not_ winter - the cart returns from the second pit, is diverted via the SW track corner it's on right now and crosses the pressure plate directly south, sending an 'on' signal to the 'inner' bridge, separating the trade depot from the fort proper. At the same time, only during this time the cart stays away from the other pressure plate, which normally keeps the 'outer' bridge lifted, thus turning it off and granting access from the outside world to the depot.
This could also be done in a three-input AND gate, with the 'relevant' diversion at the third hatch, obviously.

The output of the three-input AND gate checking for the first week of the year is checked in a similar array against a 'first day of the week' signal, returning true when it's the first day of the week but _not_ the first of granite. This signal, together with the four-input AND signal and a simple signal from the seventh day of the week are linked through the three hatches of this NOR gate:


The circuit only returns true when all inputs are off and all hatches closed. Its output is combined in an AND gate with the signals of the fourth and sixteenth hour, activating the hatches on the train stations, sending the cart either up to the magmagate depot or down to the lakeside station. Here, i linked both hour signals to the same hatch, since there's no risk of signal intersection.

This exact design is unsatisfactory, however, since it slows down the cart too much. In fact, only the first true/false check passed needs a speed regulator, all other carts reacting to an 'on' signal go through a pit/linear accelerator sequence, guaranteeing the ~48k speed mentioned in the hour counter loop. The circuit built here has a much too long return time on the second and third check, and thus there's no monday morning train service. Of course, that was totally intentional

An improved and tested three-input OR/NOR gate:

Cart is on a SW track corner right now, the NOR pressure plate would be on the tile directly to the west, the OR plate on the NW track corner directly southwest of it. I tried both options for the return track of the second check (going straight east) and the southern return loop works better. The circuit has return times between 46 and ~65 steps.

A tested and proven four-input OR (with limited NOR functionality):

This thing _does_ work, but the return time for the NOR signal is impractically long - i counted 99 steps. The return times for OR signals are a bit more useful, being 46, 62, 62 and 87 steps, depending on which is the 'earliest open' hatch. The NOR plate is the northeastern, the OR plate the southwestern one.

[Larix]

EDIT: I got the fake negative display fixed. Only took a few hours Scroll down, way down.

Update:
The Marble Bookkeeper has proved its abilities at adding up, accepting 12-digit binary numbers and being capable of adding up to 14 bits (-1, so 16383 decimal), rating it at 'high' precision. Since then, i've once again browsed The amazing account of the Almighty Dwarven Calculator. While i lack the expertise and ambition to rival that achievement, i decided to add (rudimentary) subtraction and multiplication capability to what i've built, just to see if i could get my head around the principles.

I think i've had some success.

The whole extra part is operated from here, an eastern annex of the adder read-out:

Spoiler (click to show/hide)

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.

When looking at the operative abilities, the Marble Bookkeeper's precision in subtraction and multiplication is quite poor - 'low', with maybe 40% done towards medium. I'm being magnanimous when looking at multiplication, assuming that precision here should take into account the products that can be derived, not the factors taken as base.

EDIT - probably final update on this calculations stuff:

I ran the same calculation as above, 42 - 81, and this was the result:
(EDITedit: i later noticed i hadn't returned the 'reset' lever of the 1-bit to closed. This theoretically _shouldn't_ have any effect, but i ran the calculation again anyway and got the proper result there, as well)



Yay! The solution was indeed sending an extra 'subtract' signal to the processing memory, through this contraption (made much more confusing by space contraints):



The ramp opening in the upper northwest corner is the mouth of a N-S booster pit, covered by a hatch activated by the 'negative overflow' plate (actually, the latch which reacts to the overflow plate, so as long as the top bit and the connected latch haven't been re-set the hatch may remain open). In addition, it's activated by the normal subtraction starter signal, which also operates the malachite hatch straight east and the marble hatch directly south of the single pillar, the 'original' start location. When the overflow bit is set, the northwestern hatch is open, the cart leaves to the south, enters the eastern pit and, if the hatch is closed (because it's the overflow and not the start that sent the signal), it bounces back out, around the corner, over the plate, sending the 'subtract' signal and onto the secondary starting location. If the malachite hatch is open at well, the cart just starts the course directly without touching the plate.

EDIT to the third: Ahahaha, i browsed through some of the older dwarfputing threads and their wikipedia links and it seems i kind of re-invented the two's complement for handling of negative numbers in binary and applied it through a display hack. Well, it seemed just the way to solve the problem of negative results in subtraction...

[Di]

Rather impressive.