Print

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

[Miuramir]

Can you really do ternery computing, though? My understanding is that binary is easy because of the small number of logic gates. You'll have to design a lot of new ones for ternery.

The main reason to use ternary computing is to take advantage of balanced ternary, usually represented as "-1, 0, +1".  If you are talking about DC voltages in analog circuits, this translates very easily to "-voltage, no voltage, +voltage'; and has some neat advantages.  With somewhat more work, you can use it with mechanical shaft/gear logic, with "counter-clockwise, stopped, clockwise" rotation; however, the inherent "cancelling" of the -1 and +1 which is one reason to use ternary in the first place tends to be hard on physical gears, loosing most of the advantage.  There have been proposals to use polarization states in ternary optical computing, but that has other issues. 

However, the most obvious fundamental logic state set in DF cart logic is "no cart, cart" which is a natural mapping to "0, 1" binary bit.  A more complex design could use "north-heading cart, stationary or no cart, south-heading cart" as a trit, or if you zoom out slightly and consider the storage loop the basic memory cell you could have "counter-clockwise cart, stopped cart, clockwise cart" as your trit; something similar has been hypothesized for superconducting loop storage. 

Of course, a true Dwarven computing device would be in base 8 (0,1,2,3,4,5,6,7), as every dwarf knows that that's the fundamental way the universe works.  An... octary? computing device would be a true megaproject!  More realistically, however, four binary bits stage easily up to base 8 (a nibble), while it would be much harder to do that with ternary.  Aiming for a one octal digit (4 bits) adder is probably a good starting point for binary computing cart logic designs, and then working up from there (carry bit, multiple digits, subtraction, and so on). 

[rtg593]

Guys, you're way overthinking the memory cell. It's very easy.

Roller-pressure plate-roller. 2 carts, 1 full, one empty. Set the plate to read one or the other, rollers shift carts back and forth between 2 positions. Closest thing to a binary memory cell you can get.

EDIT: with a toggled gear to one roller, you can make a very simple repeater, as well, toggling the carts back and forth every time the plate disengages/reengages. no, cart going in a circle is easier.

[zach123b]

could make a ramp with a booster and have it cradle over a pressure plate, maybe several plates, possible but maybe not logical

could make it have 5 states, n/s/e/w/standstill by bridges and boosters

probably easier to have a tree logic kind of system, easiest if carts can't take up the same spot; using dead ends, bridges, boosters and pressure plates

[Kel]

From previous page: I like the sound of a mechanical laser! Fear me goblins!
*ahem*
The loaded/unloaded cart is a good way to do a memory cell, though it might be fiddly making sure the weight is set up correctly. 'Tapes' could probably work on the same principle of loaded/unloaded carts... although Idk how useful they'd be compared to just sending one cart down a track with a bunch of pressure plates linked as necessary.

...hey, we could create dwarven movies! Send a cart down a track with a bunch of pressure plates on it, with each new pressure plate updating the status of a set of 10x10 doors appropriately. Would require careful timing/latches so the deactivating of the previous pressure plate doesn't get in the way of the activating of the next. Hmm... I can think of a way of doing 3-colour displays:

Spoiler (click to show/hide)

Code: [Select]

Looking sideways on:
Hatch
Hatch
Water (or Lava)

The viewing level would be the one with the second hatch. If both hatches are open, then you can see the blue/red dots from the liquid below. If the bottom hatch is closed but the top open, you would see that. If the top hatch is closed, you see that. Shame it has to be dots and not more-coloured-in tiles, but I can't think of a way round that.

As for sorting carts by weight:

Spoiler (click to show/hide)

Code: [Select]

Side on view again:
-------                           /
---------                        /
-----------                     /
-------------             ▲----/

Key:
- Track
▲ Ramp

Basically, heavier carts don't fly as far and hit one of the lower-down ones first.

[Sadrice]

that's exactly what i posted yesterday, except that your has ramps instead of rollers.  it's likeley that all objects will accelerate the same going downhill, assuming toady will use a vastly simplified model for friction.

I like the idea of a tape, though.  It could be a string of minecarts moving along, the rear one pushing the whole string. This would even be a case where ternary simplifies things (empty displays top plate, light load displays lower plate, heavy load displays liquid underneath).  As someone mentioned earlier, it might be fiddly to separate the front cart from the rest for analysis, though.

[Kel]

Ahh, silly me for using ramps instead of rollers. If DF uses real-world physics, I think using ramps would mean all the carts end up in the same place... yes, assuming rollers impart a force, not a velocity, then they should be used.

And yes, I know the idea of a weight-separator was brought up earlier, but I don't think anyone mentioned the levels-with-different heights as being where you the pointed the thing. Not that I saw, anyway. Apologies if you did.

[Sadrice]

I was thinking about height levels when i wrote it, but it looks as though i didn't actually mention them.  And no! Totally unacceptable!  Every post in this thread contained fresh and original ideas that had never even been thought of before, until you came and RUINED it!  RUINED!  I sentence you to 500 hammer strikes with a featherwood training hammer.

[kaenneth]

Of course, a true Dwarven computing device would be in base 8 (0,1,2,3,4,5,6,7), as every dwarf knows that that's the fundamental way the universe works.  An... octary? computing device would be a true megaproject!  More realistically, however, four binary bits stage easily up to base 8 (a nibble), while it would be much harder to do that with ternary.  Aiming for a one octal digit (4 bits) adder is probably a good starting point for binary computing cart logic designs, and then working up from there (carry bit, multiple digits, subtraction, and so on).

An Octal digit is only 3 bits, but otherwise yeah.

I was thinking of the 'Newtons Cradle' effect to store bits:

4 enclosed track tiles, > and < are rollers, P's are pressure plates, carts are not shown.

>PP<

0's are carts, overlayed on the above configuration:

">0P0"  is one state, when triggered the rightmost roller shoves it's cart into the the other cart, knocking it onto the other roller, ending up with "0P0<"

Trigger the other roller to set the bit the other way, potentially could get stuck in a bad state "0PP0", "00P<" ">P00" or "0PP0" however.

Also might need more run up space to knock the other cart off it's position: ">>PP<<"

[Sadrice]

 I don't quite understand your design, so this might be the same thing, but you could do it like this:

Code: [Select]

# - wall
A and B - pressure plates
0 - cart

No carts:
#>===AB===<#

State 0
#0===A0===<#

Power is provided to the lefthand roller, flipping it to:
State 1
#>===0B===0#

Powering the righthand roller would reset it to 0

It could be made with separate write and clear inputs by linking the rollers to separate inputs.  Powering the righthand roller when it is in state 0 would do nothing.
It could be made with a single input that sends a toggle signal by linking both rollers to the same input, though you would need to make sure the rollers are unpowered by the time the cart reaches the other side.

This all assumes momentum transfer is complete, and the cart stops dead while the other one moves on.
I also just thought of a way to separate the front cart from the newton's cradle queue.  Slam a cart into the back of the queue to knock the front cart forward, onto the pressure plate.  The hammer cart would have to be distinguishable from data carts by being a different weight, so when one gets dequeued it can be directed away from the reader and another hammer cart launch, to get the real data cart.  If you let your queue get totally filled with hammer carts, it will enter an infinite loop.

You could also make a stack data structure in the same way, but with the input and cart reader as different branches off the same side, with the hammer carts coming in from opposite.  When you push a cart, the hammer cart that comes off gets sent back around to be reused, and when you pop one, a pressure plate aperatus sends any cart going that direction into the cart reader, rather than back into the input.  Just don't run out of hammer carts or you will start losing data.

The hatch display mentioned earlier would benefit from a circular queue that uses the last data cart as the hammer cart.  For speed and viewability you would probably have to make a separate queue to control each pixel.  With enough spare time (probablt way less than is required to build a decent fluid logic adder) you could build a display that plays a looping animation, or if the data carts are sent to separate storage rather than looped back around as hammer carts, any one of several selectable animations.

[rtg593]

From previous page: I like the sound of a mechanical laser! Fear me goblins!
*ahem*
The loaded/unloaded cart is a good way to do a memory cell, though it might be fiddly making sure the weight is set up correctly. 'Tapes' could probably work on the same principle of loaded/unloaded carts... although Idk how useful they'd be compared to just sending one cart down a track with a bunch of pressure plates linked as necessary.

...hey, we could create dwarven movies! Send a cart down a track with a bunch of pressure plates on it, with each new pressure plate updating the status of a set of 10x10 doors appropriately. Would require careful timing/latches so the deactivating of the previous pressure plate doesn't get in the way of the activating of the next. Hmm... I can think of a way of doing 3-colour displays:

Spoiler (click to show/hide)

Code: [Select]

Looking sideways on:
Hatch
Hatch
Water (or Lava)

The viewing level would be the one with the second hatch. If both hatches are open, then you can see the blue/red dots from the liquid below. If the bottom hatch is closed but the top open, you would see that. If the top hatch is closed, you see that. Shame it has to be dots and not more-coloured-in tiles, but I can't think of a way round that.

As for sorting carts by weight:

Spoiler (click to show/hide)

Code: [Select]

Side on view again:
-------                           /
---------                        /
-----------                     /
-------------             ▲----/

Key:
- Track
▲ Ramp

Basically, heavier carts don't fly as far and hit one of the lower-down ones first.

Memory cell wasn't toggled by weight, but by load. Toady said plates can be set for empty vs full.

[Sadrice]

He said they could be used for that, I don't think he was very specific about exactly how it's implemented.

[FearfulJesuit]

If you're going to go for a ternary system, wouldn't full cart (1), empty cart (0), no cart (-1) make sense?

[Sadrice]

It would, but it would be hard to implement.  Your system would have to very regularly timed, so it would know when the cart's supposed to show up, and it would have to somehow notice that the cart never showed up.  If the pressure plates are weight based, a weight system would be easier to implement, though you may need dwarves to manually load and unload carts.

[Urist Da Vinci]

(if there's a wall blocking the way the cart would fly off, it will stay on)

Adjust your railgun designs accordingly. If the cart is encased it will keep going around the loop. We know from previous discussion that if there is a only a small gap then mine carts can derail and reattach to the tracks. Perhaps this will be an option:

Code: [Select]

/-HHH-\
|     |
|     |
\-----/

With H being a hatch.

If this circle is walled in, perhaps with a hatch above to deliver the next cart and the hatches drop open, wouldn't that launch the cart at MAXIMUM velocity, since the cart can't derail on those corners?

Why hatches? Assuming that a cart can't derail into a closed door/bridge/floodgate, you could do this:

Code: [Select]

/-----\d
|     |
|     |
\-----/

where d is a door. The cart must be travelling clockwise in this example. New carts are jumped down from above with a slight forwards speed, enough to reach the rollers and get moving. You could possibly add a number of carts to the loop equal to half the length of the loop.

This isn't a laser. It's closer to a particle beam weapon.

[rtg593]

(if there's a wall blocking the way the cart would fly off, it will stay on)

Adjust your railgun designs accordingly. If the cart is encased it will keep going around the loop. We know from previous discussion that if there is a only a small gap then mine carts can derail and reattach to the tracks. Perhaps this will be an option:

Code: [Select]

/-HHH-\
|     |
|     |
\-----/

With H being a hatch.

If this circle is walled in, perhaps with a hatch above to deliver the next cart and the hatches drop open, wouldn't that launch the cart at MAXIMUM velocity, since the cart can't derail on those corners?

Why hatches? Assuming that a cart can't derail into a closed door/bridge/floodgate, you could do this:

Code: [Select]

/-----\d
|     |
|     |
\-----/

where d is a door. The cart must be travelling clockwise in this example. New carts are jumped down from above with a slight forwards speed, enough to reach the rollers and get moving. You could possibly add a number of carts to the loop equal to half the length of the loop.

This isn't a laser. It's closer to a particle beam weapon.

Lasers bounce back and forth between 2 mirrors picking up energy from a crystal, gas, etc. Once it has sufficient energy, it breaks through partly transparent emitter mirror and is released. That's the mechanic I was comparing this system to.

Edit: but ya, a closed loop charging system for a particle beam would be a better analogy.