Print

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

[Larix]

I have devised and built and successfully tested a programmable dwarven computer. As opposed to the legends of the older days, who decided to built a _fully_ programmable computer, i wisely decided to pick a language that's easy to program in, and found - hq9+!

Spoiler (click to show/hide)

Yes, it is a joke language. Consequently, the entire computer is a cheap if somewhat elaborate joke.

hq9+ has several advantages: it does everything it does with a mere four instructions, and requires nothing but the instruction list as input. No declaration of variables, no data structures, no true-or-false decisions. And it can do all the things typically done when demonstrating the capabilities of a freshly-minted programming language: it can print "Hello World", it can add one to the accumulator, it can print its source code and it can print the text of "99 bottles of beer".

Spoiler (click to show/hide)

It can do absolutely nothing else, but what else do you really need?

So, investing a few dwarf years and about 600 mechanisms, i built a dwarven computer which reads and executes hq9+ programs. It runs programs consisting of exactly eight instructions. Non-input is not admissible, the interpreter treats it as a "h" instruction but it makes the "q" output inaccurate.

The complete display before the testing run, with the test program already entered.


The bridge array in the middle is already set to the actual source code, the retracted bridge corresponds to

Code: [Select]

h+
q9

in each cell; however, the source is not being output - the bridges to the north and south are all raised and thus the dwarfs cannot read it.

The hatch in the south is the indicator from the accumulator, it gets opened for about 100 steps everytime one gets added.

Program input and regulator:



One individual lever for each of the four possible instructions and each of the eight positions within the program. Only one instruction per position.
The bauxite lever advances the program execution by one position every time it is pulled.
The petrified wood bridge to the east lifts and lowers once every time the program has been executed in full.

So, let's run the program! First instruction: "h"



Yay! The computer printed "Hallo WELT"!

Spoiler (click to show/hide)

Admittedly, it's not easy to recognise it as such, even when told what it's supposed to be. I found it quite bad enough that it took 28 link jobs just to get this shitty thing to retract/extend, i wasn't going to kill my brain by creating a display needing a hundred or more.

Second instruction: "q"



The extended cobaltite bridge signifies that the raising bridges are all lowered, so dwarfs can go and read the source code. "q" successfully executed.

Third instruction: "9"



"99 !", i.e. ninety-nine flasks (of booze) are clearly printed. Yay! The cobaltite bridge to the north-east is no longer visible - the source code display is no longer accessible.

Fourth instruction: "+"



One has been added to the accumulator, therefore the hatch cover has temporarily opened.


The actual interpreter looks like this:



The biggest part is the input reader to the left, a loop of eight reading cells.




The cart comes from the east, passes two of the three roller switches (resulting in a four-way split) and is sent back and forth over a pressure plate by a pair of opposing rollers, sending the signal corresponding to the instruction at the current location to one of the four outputs. When the next instruction is to be read, the "exit" roller is deactivated and the cart proceeds to the next cell.

Three of the four outputs simply lower/extend a bunch of bridges, thus they're simply powered NOT gates: a 2x2 round track holding down a pressure plate unless a signal comes from one of the inputs and disengages the powering mechanism.

The fourth output is the accumulator:

 

A perpetual-motion counter circuit, which simply returns to its original state whenever it receives an advancement signal. Ramps in the three-part angled pit in the west are E-W, NSE (with hatch cover operated by the "+" signal), and north a NS ramp under a closed ceiling. There's a half-covered EW pit to the east, although a ramp with wall would have worked as well.
When the hatch is closed, the cart bounces back and forth in the angled pit, between the northern wall and the closed hatch cover. When the hatch opens, the cart exits south, goes through the southern loop and is fed back into the angled pit, which it will pass in a straight e-w line back and forth until the hatch cover closes again.

The basic design is that of a counter but here, adding one to the counter just returns the counter to its previous state. That's because this is a _unary_ counter with a memory capacity of one unit. The held information never changes, but for demonstration purposes i've added a signal whenever it receives an advancement signal.

[evictedSaint]

This makes me want to cry, but I'm not sure why.

[Larix]

That's becuase your (sicx2) jealous.

I admit it's a stupidly overengineered joke.

The only valid piece of dwarfgineering in it is the input reader. The presented design isn't quite right for the output i'm producing - the fact that the signal is held all the time until the next cell is read can mess up the bridges indirectly operated from the plates. It's perfectly adequate for operating instant-response devices: gearboxes, hatches and doors. For delayed-response devices, this design might[1] work better (producing a 'pulse' - a single on followed ~100 steps later by an off) - mockup of a single cell, requires 47 power:

paths:   rollers: full installation:

Cart passes from east to west, the switch rollers work W->E. After the cart touches one of the four plates, the track is united again and the cart is held between the always-on E->W roller and the switchable W->E roller just northwest of it, until the latter switches off and the cart proceeds to the next cell.

[1] i'm not totally sure - in the given example, the signals are sent through a NOT gate, which adds even more signal delay weirdness. But i _think_ the pulse signals should result in properly operating bridges.

Edit: no, thinking about it, we need to delay the following 'on' signal from the NOT gate, else the bridge will just lower/extend and the raise/retract won't be processed.

Thus, the delayed NOT:

paths: rollers and pressure plates:

The northern and middle rollers work N->S, main power to the cell is regulated by the input signal - when the signal is 'on', the powering mechanism gets disengaged, and the cart comes to rest on the northern roller. When the signal times out, the cart is re-started and moves over the northwestern pressure plate, linked to the mechanism powering the southern roller, switching it off. Once that pressure plate resets, the roller activates again and the cart returns to cycling between southern and central roller, keeping the southeastern pressure plate active. _That_ plate operates the bridge.

So, the logical procession is:
power on - cart bounces between southern and central plate, bridge-control plate is active, bridge raised/retracted.
1 - Incoming signal - power turns off for 100 steps, cart sits still on the northern roller. After the 100 steps are over, the bridge plate resets and sends a signal, the rollers re-activate.
~ 100 - Cart moves over the northwestern pressure plate, switches the southern roller off for 100 steps and comes to rest on top of it.
~ 200 - After 100 steps, the bridge lowers/extends, and shortly after, the northwestern pressure plate resets, reactivating the southern roller.
Cart returns to bouncing between southern and central plate, a new 'raise/retract' signal is sent, processed by the bridge around step 300.
P.S. Tried and proven.

To avoid possible entanglement of signals, you could even send the cart around an extra loop, so the southern roller is switched off a bit later, like so:

Put the pressure plate for the southern roller on the crossing: the roller re-activates 100 steps after the cart leaves the plate, and the re-activation is the critical event. This extra loop is _probably_ unnecessary, though.

[Button]

This is my new favorite thing.