Print

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

[Nil Eyeglazed]

I should've asked in this thread.  I'm reproducing what you wrote about spin memory in the wiki forum thread so I can ask questions in the proper place.

Spoiler: Wall of text; i've no idea how much of this is helpful and/or understandable. I consider putting this somewhere on my user pages, as an example of circuit construction. (click to show/hide)

The basis is a straight pit containing two straight track ramps, let's say EW.

All pictures as viewed from above; first on the level below, with the "upwards" ramps and bordering walls, all others show the "upper" level, where only the holes leading down can be seen of the ramps.

Code: [Select]

#▲▲#  #==#
Ramps     Track

The ramp to the west is thus "west up, east down", the eastern ramp "west down, east up". Each has connection to one wall and one non-wall, so can accelerate minecarts.

A cart entering the western pit from above, either from the west, from the south, the north or straight above (dropped in) will accelerate towards the east and move to the eastern ramp after five or six steps, after gaining a few ten thousand speed. It will spend _one_ step on the eastern ramp due to flaky ramp teleportation, losing very little speed and then move out of the pit to above-east. The analogue happens when a cart enters the eastern pit from the east/south/north/above.

Now, let's expand it a bit - we can use the acceleration to send the cart on a permanent loop:

Code: [Select]

╔==╗
╚▼▼╝

If a cart enters the pit from the west, it gets accelerated, leaves the pit to the east, cycles back around to the western pit entrance and keeps cycling counter-clockwise. If a cart enters from the east, it'll cycle clockwise.

This design by itself is completely useless. The cart will accelerate so much in the pit that it'll soon reach derail speed and shoot out of the circle, collide with walls and ceilings or come up with some other operation failure. There's also no distinction between the two senses of circulation. You can establish a one-direction stable circuit by speed reducers, but that's beside the purpose of this treatise.

The predictable directed output from the pit doesn't only work with "straight" input, as i said above; it also works when the cart enters from the side:

Code: [Select]

╔=╗     ╔▼▼
▼▼╝     ╚=╝

Still using the straight ramps below.

On the left hand: a cart entering the western pit from the north once again leaves to the east, goes around the loop and enters from the north again.

A cart entering the eastern pit, however, will still leave to the west, not to the north.

On the right hand: a cart entering the eastern pit from the south leaves to the west, goes around the loop and enters the eastern pit from the south again.

A cart entering the western pit will leave straight east.

Carts on stable loops of these types will remain there indefinitely, they will not gain enough speed to derail.

This way, we have two different counter-clockwise minecart loops, using the same type of ramp-pit but having otherwise not a single piece of track in common. In fact, we can just go and stick them together on one and the same ramp-pit:

Code: [Select]

.╔=╗
╔▼▼╝
╚=╝

A cart thrown into the circuit so that it takes the southeastern ramp entrance will always use the southwestern loop, a cart first taking the northwestern entrance will be restricted to the northeastern loop.

Now let's assume we don't want our cart just to cycle for all eternity. Perhaps at some point we want to extract it from the circuit. Well, an humble hatch cover over one of the ramps can do just that:

Code: [Select]

.╔=╗
╔▼¢╝
╚=╝

When the hatch cover is open, the cart will cycle harmoniously. If it closes, a cart on the southwestern loop cannot roll into the western pit, rolls over it and leaves the circuit on a northward heading. A cart on the northeastern loop can still enter the western ramp, but cannot leave from the eastern ramp, thus gets reflected, leaves to the west, around the southwestern loop and also leaves to the north.

This is the core of the spin memory, the rest is just machinery needed to properly enter a cart into the loop and making extraction from the loop meaningful. In the given example, i decided to only keep one loop stable - the other, "off" results in the cart never establishing a stable loop and leaving right away.

For the actual functionality of memory cells in my array, i could have taken the simple straight latches used in the memory buffer, for an even smaller layout (10x1 tiles on two levels when packed as tightly as possible) and somewhat easier operation. Definitely something to keep in mind for future projects.

Let's start with a clarification, requoting from inside the spoilers:

Code: [Select]

.╔=╗
╔▼¢╝
╚=╝


Let's recap: the hatch covers a ramp down; both ramps have EW track.  This puts any cart rolling onto the impulse ramps onto a counterclockwise rotation around the circuit.  When the pictured hatch cover is open, the direction of entry into the impulse ramp pit determines whether the cart will be rolling around the northern circuit or the southern circuit.

When the hatch cover is open, the cart will cycle harmoniously. If it closes, a cart on the southwestern loop cannot roll into the western pit, rolls over it and leaves the circuit on a northward heading. A cart on the northeastern loop can still enter the western ramp, but cannot leave from the eastern ramp, thus gets reflected, leaves to the west, around the southwestern loop and also leaves to the north.

I didn't find this, so there's something I didn't understand.  When the cart is moving counter-clockwise around the southern loop and the pictured hatch is closed, the cart continues north from the hatch.  In my first trial, this meant that it ran into a wall.  On getting rid of that wall and making an extra bit of track so that the minecart re-enters the loop, it meant that the minecart stays on the southern track, because that's where the only exit from the impulse ramp pit leads.  (Likewise, closing the western hatch constrains the minecart to the northern loop, not the southern loop.)

I think that's just a little typo that I wanted to clarify.  I'm finding larger problems with signal management.  It seems to me that it's simple enough to put a pressure plate on one arm of the loop for output, but how do you input?  Because it looks to me like you need to send "off-on" signal cycles rather than "on-off" cycles.  While not completely impossible, that takes all of the simplicity, speed, and ease of design out of the memory.

Or else....  This confuses me further:

two zinc (teal) hatch covers are operated by the clear/write lever

Since I don't understand how everything works, I'm probably wrong-- but that sounds like a single lever is used to either set or clear the memory (that is, write true or write false).  An 'on' signal does one and the 'off' signal does the other.  But in that case, it's hard for me to imagine what use the memory is.  Anything it could possibly remember is already being remembered by its input.

Heh, your user pages have been a source of encouragement for me more than once. It didn't cut out any of the learning process to me, what counted was that they demonstrated that there's quite a lot of potential in DF logic, and it all starts with very basic concepts.

It makes me really happy to hear that   I'd written all that in a hypomanic haze and had long since given up hope of it ever being useful to anyone.

[Larix]

    When the hatch cover is open, the cart will cycle harmoniously. If it closes, a cart on the southwestern loop cannot roll into the western pit, rolls over it and leaves the circuit on a northward heading. A cart on the northeastern loop can still enter the western ramp, but cannot leave from the eastern ramp, thus gets reflected, leaves to the west, around the southwestern loop and also leaves to the north.

I didn't find this, so there's something I didn't understand.  When the cart is moving counter-clockwise around the southern loop and the pictured hatch is closed, the cart continues north from the hatch.  In my first trial, this meant that it ran into a wall.  On getting rid of that wall and making an extra bit of track so that the minecart re-enters the loop, it meant that the minecart stays on the southern track, because that's where the only exit from the impulse ramp pit leads.  (Likewise, closing the western hatch constrains the minecart to the northern loop, not the southern loop.)

The purpose here is not moving the cart from one half-cycle to the other (one cycle switch would be possible, but not the other, and it'd probably be not very useful), but removing the cart from the circuit entirely, so it can either react to a new data input or be "read" (produce a signal cycle output).

The cart needs to get an "off" signal to leave the circuit and can only stay in circulation if the hatch cover is "held open", i.e. is recipient of a held "on" signal. This definitely reduces the efficiency of this memory cell - you have to send a signal cycle and the cart will only react to the "off" part of the cycle. Latency ho!

    two zinc (teal) hatch covers are operated by the clear/write lever

Since I don't understand how everything works, I'm probably wrong-- but that sounds like a single lever is used to either set or clear the memory (that is, write true or write false).  An 'on' signal does one and the 'off' signal does the other.  But in that case, it's hard for me to imagine what use the memory is.  Anything it could possibly remember is already being remembered by its input.

I'm terrible with terminology. It was my first testing rig, still fully lever-operated. The lever indeed operates two hatch covers at once: the "write" hatch allows the cart to evaluate the status of the "data input" (the neighbouring hatch) and dependent on that state enters one or the other half-loop in the spin cell. If the write lever doesn't activate _or_ if the cart is alread spinning, the data input is ignored. Differently put, the cell remembers the state of its data input at the time the last "write" was sent.
Due to the double link, the write process happens when the lever is set to "on", the memory is cleared when the same lever is set to "off". This was o.k. for testing, but for an actual memory, i wanted the functions separated.

So the functionality of the "write" here is not a "set" but more of a "write to (state of data input)", perhaps an "enable"?

[Nil Eyeglazed]

I just finished testing a different minecart-based memory circuit.  You might like it.  It is:
 
 *Low latency
 *Powerless
 *Compact and easy to tile
 *Built on a single z-level
 *Easy to manage signals with

Code: [Select]

circuit ramps + furniture
 |╗      A.
 ╗|      A.
 =╝      A^
 ..      ++
 ╔=      .A
 |╚      .A
 ╚|      .A

. is unsmoothed floor; A is upward ramp (nonfunctional); + is door (input); ^ is pressure plate (output)

My apologies for the ugliness of that circuit diagram.  You've got two loops, but one half of each loop is made out of impulse ramps, so it looks all screwy.

Minecart travels through one of two circuits-- north (true) or south (false).  Three impulse ramps give it derailing velocity.  Opening the west door puts it on the southern path-- thus, opening the west door writes false.  Opening the east door writes true.  Opening doors, of course, is a zero latency operation.  Pressure plate is output-- if memory is false, last signal from plate is off; if memory is true, last signal from plate is on.

Don't even need any walls; I've got one circling right now.  That's 14 tiles per bit, rectangular package, more compact than hydromechanical, just as fast or faster than hydromechanical, no power.  Discounting linkage, 3 stones and a minecart (want to say 2 logs?) per bit.

Oh, and I'm awful with using the right jargon too.  I try to say things in multiple ways because I want to try to use the right terms-- and I want people to know what I mean in case I use the wrong terms   I hope it doesn't sound like I'm ever correcting anyone's usage.  Outside of DF (and inside of it, frequently), I understand this stuff only very, very poorly.

[Larix]

Interesting. I find it curious that a 2x2 loop doesn't work (cart can't leave). Well, the design above requires _some_ walls - ramps, impulse or not, need contact with a solid wall to provide acceleration. Doors need adjacent walls for construction, but constructed walls can be removed afterwards without making the door fall over.

A nice compact set-reset latch. I'm always a bit uncomfortable with impulse ramps - i learnt my stuff on dug ramps which mandate below-derail speeds and have relatively clear pathing rules around the ramps themselves.

As a two-input latch, it still is not very applicable for multiplexed data - it needs an individual "set" or "re-set" signal. If you, say, collect eight bit values and want to write that information to one byte in your eight bytes of adress space, you still need to turn your generic information into a specific signal that causes only this specific memory cell to acquire the value. That was what i wrangled with in the memory bank: being (notionally) able to write the "fourth-bit" information to one and only one of eight possible fourth bits without needing eight separate input generators. I think this requires a "write enable" switch separate from the data input itself. The spin memory cells do this in a convoluted way, a simple linear latch should be more effective:

Code: [Select]


#▼▼=▼▼=▼▼=▲#

##¢=▼¢=¢▼^▲#
  E  S R


E - write Enable
S - Set
R - Reset

All track on ramps and floor is ordinary EW. The westernmost ramp is underground (just mine out one tile from the channelled ramp, then construct an EW track ramp there). It stretches over two levels, but can be stacked to 10x1 tiles.

If the cart's write is not enabled, it doesn't care about data input. If write is enabled and set is activated, the cart moves to the eastern "on" holding cell and bounces against the wall there, keeping the pressure plate active, until it receives a reset signal. As per usual, if both set and reset are on, you get a nonsense signal ("on", in this case, unless enable is off). The whole thing has the advantage of reacting to "on" signals, which would spare me the contortions i went through to keep a hatch open by the memory-holding cart and having to trigger an "off" for the reset. Latency would be somewhat mediocre - ~40 steps for an "on".

[Nil Eyeglazed]

Thanks, yeah-- I only tested for accidental derailments, didn't actually remove all walls.  You're right that side walls are necessary, making each bit 3x7 (comparable to hydromechanical still).

The design you have is funny, because that's exactly what I was going to test next   Minus the write enable part.  Something like that is nice and small, and really fast, and general purpose.  Let me draw it from the side just to make sure we're on the same-ish page:

Code: [Select]


 % h_h %%
 %\/%\^/%

Which is also an edge detector with the pressure plate moved to the top; and can be made circular and directional, for separate rising and falling edge detection; pretty sure a repeater can be made out of it too.  Latency is reasonable (I consider <100 ticks to write true acceptable, <200 ticks to write false acceptable).  At worst, I see 4 tiles travel to write true (+0 ticks latency to pop a hatch), and 3 tiles travel before the plate has a chance to send an off (+100 ticks latency on that).  Sound like you're saying it should take about 10 steps for this minecart to travel one tile?

I don't quite understand the write-enable thing, because it seems to me that to disable writing, you need to lose your value.

My approach to addressable memory has been to stick an extra step between my write-to-memory and require a write-to-memory AND address position bit 1 AND address position bit 2 AND....  Every bit of addressable memory needs this relay, at least with the way I think about it.  Building a 5*AND circuit can usually be done a lot more simply than 5 complete, independent ANDs in series, of course.  (5 because that seems like a nice amount of memory to address at once for a DF computer, and lets you pull 3 bit instruction with 5 bit argument.)  In these systems, I've been assuming 8 bits per byte, and figuring on a bit shift if I ever needed to, say, write a bit to an alternate position.  I'm not sure if I understand what you mean with 4th bit (what are 2nd and 3rd bits?).  EDIT: NM on that, I see you were using 4th bit as an example.

EDIT: Okay, just skimmed wikipedia/latch, I see what you're saying.  If you want an Enable input, it seems to me that the best way to do that is with a door on top of the circuit like so:

Code: [Select]


 % h+h %%
 %\/%\^/%


I find it curious that a 2x2 loop doesn't work (cart can't leave).

It might.  I've had inconsistent results with experiments and how many impulse ramps to force derailment.  Didn't do everything I possibly could to optimize this design.  Which is fine, because this other memory you mentioned is probably better in every way

EDIT AGAIN: Doesn't quite work; cart settles onto pressure plate.  Slight rework:

Code: [Select]


 # hdh ^  #
 #\/#\/#\/#

That one works.  That puts size at 18 tiles.  A bit easier to build a bajillion of them than other varieties though (just a bunch of N/S track).

[Larix]

Code: [Select]


 % h_h %%
 %\/%\^/%


Yup, apart from the placement of the pressure plate (the problem you worked out later), that's what a minimal hatch-based minecart latch looks like.

Sound like you're saying it should take about 10 steps for this minecart to travel one tile?

Actual movement speed is kind of complicated with those designs. When dropped from a hatch into the "front" end of a pit (so that it has to bounce into the back wall and roll back to the front before leaving), it'd add up like this:

Hatch opens - cart starts to fall
8 steps to land on the ramp below
7 steps to roll off the ramp, onto the neighbouring ramp
1 step trying to roll "up" that ramp, but gets blocked
7 steps to rolle off the back ramp
1 step rolling up the front ramp
cart leaves. That's 25 steps to get out of the ramp. Some of the summands may be off, but the sum of 25 is correct for a hatch that was installed after the cart was built.

If the cart's already moving and testing the open-or-closed status of a ramp exit, it takes 6 or 7 steps from entering the ramp to leaving it through an open exit, and about 15 steps to return from a closed exit. It'll move over flat floor at speeds somewhere between two and four steps per tile, depending on the exact speed it gained. The final turn requirements of circuits are rather difficult to work out on paper, i usually just build it and see if it works, and if so, count steps at that stage.

EDIT AGAIN: Doesn't quite work; cart settles onto pressure plate.  Slight rework:

Code: [Select]


 # hdh ^  #
 #\/#\/#\/#

That one works.  That puts size at 18 tiles.  A bit easier to build a bajillion of them than other varieties though (just a bunch of N/S track).

Good idea. I had thought about including a door in it (i mean, a data input plus enable _is_ effectively an AND operation and hatch+door combined can do just that with a single ramp-pit) but discarded the idea because it didn't quite fit the exact use doctrine i had applied for my memory bank. For a memory design which sends a, say, "adress" signal to the byte/bit to allow an operation, your design allows to send both Set and Reset from common signal providers and only process them in those cells that are being adressed.

One minimal possible improvement:

Code: [Select]

#?hdh ^/#
#\/#\/##

Instead of another ramp-pair, use a ("unusable") ramp against a wall for the return. With a wall instead of open air in slot ?, this should be tileable to 7x1 on two levels, i.e. 14 tiles per cell. Hmm, i'll have to check whether it's fully operable this way, it feels almost too good to be true.

With the impulse ramp circuit - i _think_ i know why a 2x2 cart cannot (normally?) leave, but it's hard to even try to explain. Basically, if you build the circuit like this:

Code: [Select]

╔=    ╔▲#
╚╚    ╚▲#

the cart completely stops and re-starts on each ramp and thus never gains much speed. Should be the same with a NS ramp in the southeastern corner btw - as far as i can tell, the "wall" direction of an impulse ramp is usually irrelevant, what matters is the "floor" connection, because that's what determines in which direction the cart accelerates. If the cart isn't moving in that direction already, it either goes on a diagonal or (if it comes onto the ramp with little speed) moves in the new ramp's direction as though it started from a standstill. I'm not sure what exactly goes on with the longer loop - that the cart actually follows the track behind the "jump" suggests the west-ward acceleration either is discarded or so small compared to the northward thrust that the diagonal component gets neutralised by the later track. Strange, but it gets results.

[Edit: whoops, overlooked one "quote" level]

[Nil Eyeglazed]

Good idea. I had thought about including a door in it (i mean, a data input plus enable _is_ effectively an AND operation and hatch+door combined can do just that with a single ramp-pit) but discarded the idea because it didn't quite fit the exact use doctrine i had applied for my memory bank. For a memory design which sends a, say, "adress" signal to the byte/bit to allow an operation, your design allows to send both Set and Reset from common signal providers and only process them in those cells that are being adressed.

Yeah, certain bits of how your addressing system is designed have become more apparent to me throughout this discussion.  I want to mention that for your system, you could be using these latches we're discussing most recently with a slight change.  In addition to a "write enable" input, you can have a "read enable" input that opens doors allowing minecarts to loop through a side passageway, hitting a pressure plate that thus sets/resets the appropriate register bit.  Top down, would look something like:

Code: [Select]

%%%%
%╔d%
%^▲%
%╚▲%
%%%%

That's a small circuit intended to replace the reset pit the minecart oscillates around in; should it receive a "read-enable" input, the door opens, minecart rolls around over a pressure plate resetting (since we're in the reset pit) register at, say, bit position 1.  The set pit needs to be modified similarly-- output to set register, but input still from read-enable.  Doubles the size of the cell, but should allow fast, non-destructive read-to-register operations that can be addressed in the same manner as you address your write (with one extra bit describing write/read).  Not sure that that impulse ramp/pit is sufficient for purposes, but I'm sure that some design would be.

This is assuming that your memory is needed for output as well as processing.  If your memory is only used for processing, you don't really need three different outputs.  You only need two: read-true-on-read-enable, read-false-on-read-enable.  (This is easier for me to think about when I describe reads as "write-x-to-register".)  That means the pressure plate in the set part of the original design doesn't need to exist.  It sounds like that's how you've been handling things, and one reason why I had a lot of trouble understanding the spin memory.

One minimal possible improvement:

I'll test it out; I trust your experience with this stuff that works though.

With a wall instead of open air in slot ?

You need open air for minecart changing from true->false to drop into the reset pit-- but I suppose you don't actually need to drop into the reset pit until you need to be accelerated into the set pit.  Should work, although I doubt anybody would get any use out of the single tile saved.  Even if I was making kilobytes, I'd probably prefer to keep my memory aligned rather than staggered.  Would also interfere with the read-enable circuits I describe above, but those might not be the ideal solution anyways.

Also increases latency on set operations.  Maybe good: latency becomes constant and predictable.  Maybe bad: latency becomes worst possible.

[Larix]

Completely changing topics for a moment: i've been fiddling with a very peculiar subset of minecart logic and got the first rudimentary result, which is as yet impressively unpractical for any purposes.

Spoiler: Reasons? (click to show/hide)

The core idea i started with was the consideration of using other bases than two for computing. That's already been tried in the real world; mechanical calculating machines were usually decimal, and there was even a programmable ternary computer in the Soviet Union. The obvious big problem is that in DF, signals and power know only two states, on and off. Thus, representing a three-value digit with signals or power would require at least two signal generators, discarding one of the possible constellations. A serious waste, obviously. Liquids can take on seven different depth values (eight including zero), but different heights of liquid cannot directly produce very many effects, apart from the "build site submerged" and "dangerous terrain" cancellation reasons, which are... difficult to translate to further data.

Minecarts can have a slew of different weights, but how to translate those to different outcomes? - By collisions, of course. Well, i say "of course", but it's probably not that obvious:

when two minecarts collide, impulse is transmitted from the donor to the receptor of the push. This process takes the relative weights of the carts into account, reducing the resultant speed if the receptor is heavier than the donor (but not increasing speed in the opposite case).

Raw speed can be "measured" by minecart paths without any dedicated buildings, producing different, speed-dependent paths. Trivially, you can force a binary switch decision - send a cart over a corner tile with open floor behind; if it's at derail speed, it'll pass over the corner and carry on in a straight line, if it's slower, it'll follow the corner (if the corner was properly aligned). In addition, some downward ramp constructions are speed-sensitive and will produce different outputs depending on different _below-derail_ input speeds, letting a cart pass in a straight line if fast enough, but bending it around a corner if slow:

Code: [Select]

=▼=   =╦=
 ▼     ║
 ║     ║

a moderately-fast cart passes through from west to east (or vice-versa), a slow cart changes direction in the pit and leaves to the south. And a derail-speed cart will jump over the ramp entirely and ignore most corners behind it.

This way, you can construct a three-way switch, turning input speed (or indirectly, input speed as an expression of relative cart weight) into three different outputs without signals or activatable buildings involved. For a simple demonstration, i built a "signal-less" ternary memory cell, which while idiotically large and unwieldy, can be read conservatively, read destructively and incremented, depending on the weight of the "operator" cart. Information is stored by the location of one "memory" cart. Of course, right now, its input must be run through dwarven push commands and output consists of nothing but more minecarts, but who knows, maybe someone gets an idea to make something of it:



The copper minecart is in one of three possible positions. A speedy "operator" minecart bumps into it, and depending on this cart's weight, the copper cart starts to move slowly, very slowly or at the same speed as the operator cart. The operator cart drops into the ramp adjacent to the memory location after the collision, leaving through one of three possible paths, comprising a "read" output.

Three different-weight operator carts are thrown in from eight levels above, going down a straight ramp rail. Theoretically, using fewer operators and using different amounts of acceleration could work, but since carts flying over pits get airborne, that's troublesome - the operator cart can _fall_ into a ramp-pit if that's where its flight ends, and different-speed carts jump different distances. Using a shared accelerator rail with different carts is saner.

The three operator carts are:

aluminium - copper cart moves at appreciable non-derail speed, passes through the splitter ramp northeast of the memory location and cycles back to the memory spot. Conserving read.
wood - copper cart moves at very low speed, gets diverted to the east by the splitter ramp and moves into the "next" memory location. Increment (with read)
heavy metal (lead in the given case, but several other metals should be acceptable as well) - memory cart moves at derail speed, letting it jump over any possible later downward ramp. It slams into the wall at the eastern end of the array, where it then rolls down a NS ramp and cycles back to the first memory position. Reset/set to zero/destructive read.

The actual memory could of course be built in various sizes - with only two memory locations for binary, ten for decimal etc.

This thing really got me wondering if it'd be possible to make any kind of actual logic machine that'd depend on operations of this kind to process data, using only a few "set" signals/commands and a few output plates to make it operable and readable, but with the actual operations taking place producing or evaluating not signals but rather location/weight/speed of minecarts. And if something similar could be done with water wheels/pumps (i.e. pumps move water or remove water, which provides/cuts flow for waterwheels, which powers/depowers other pumps etc).

[Larix]

Two other ideas, concerning using minecarts to store information:

one idea that looked very attractive was _stacking_ minecarts: if you drop a minecart on top of another minecart, the second minecart will sit in the tile above and will patiently wait for the cart below to vacate its position before it falls down. If you drop additional minecarts on top of the second minecart, it will end up in the same location, and in theory, it should be possible to stack an arbitrary number of carts in one tile like this. With weight-dependent plates and different-weight carts, you can actually store binary information like this, not just "yup, there's a minecart here", or "this tile contains n minecarts" (would be unary information, pretty wasteful). E.g., carts of four different weights can be "read out" by two pressure plates, holding two bits of information per cart.

In practice, however, i haven't had any success with this idea. Perhaps i'm delusional again, but it seems that carts take longer to fall into larger minecart stacks, which promises to shoot reading speed to hell (it's likely to be quite glacial anyway, you'll have to drag out the carts one after the other and employ some kind of reading machinery to tell which cart represents which bit of your stored information).
I tried to keep the reading speed in check by pulling four carts at once out of storage, but that puts them too close to each other, so they're unreasonably difficult to get back into the stack. In my test, the leading cart was eventually caught by the second before it finished falling from the feeding hole into the stack and got wedged in place, never falling down at all and blocking the entire machine.

It may be possible to get this scheme to work, but i don't have much hope. It promises to be completely useless for actual data storage outside of archiving anyway, but it _might_ be possible to use it as storage medium for "graphical" information - when you only cycle one cart per 110 steps, the drop might still work, and the processing machinery per stack is fairly small, while storing, say, twenty or so carts could still be practical; notably, increasing the stack doesn't require more buildings, just more minecarts.

While the stacking approach shows little promise and seems to have added practical difficulties, another doctrine for using cart weight for data storage shows more promise - just using a cart's weight, as readable by pressure plates, as information. Minecarts come in the following weight brackets (only looking at empty carts for now, giving examples for every bracket but not listing every possible material):

0-50 - wood
50-100 - blood thorn (also included in wood)
100-150 - aluminium
250-300 - pewter (all types), zinc, tin
300-350 - bronze, brass, nickel silver, iron, steel
350-400 - copper, nickel
400-450 - silver
450-500 - lead
550-600 - electrum
750-800 - gold, rose gold
850+ - platinum

Aluminium, platinum and electrum are notable, because they're uncommon materials which are the only examples in their weight brackets. Blood thorn is similarly unique, but _also_ activates 0-50 pressure plates, making it less than practical for data processing.

Discounting blood thorn (not easy to procure and difficult to test for), that gives ten different weights. Three minecarts can come in 1000 possible combinations of weights, which'd be almost ten bits in binary. Restricting the weight spread to eight possibilities would mean three bits stored per minecart, which'd be easy enough to translate into binary. Properly reading those different weights takes a bit of effort, but if you adress memory cells independently and run them through a shared reading array, the cost should be pretty low compared to fully binary memory storage. I built a test rig to see how well reading these things works, and while tricky, it's doable.



Each "kilo" consists of three carts, sitting on the same 3x1-sized roller pushing north and held back by a door. Once the door opens, the carts leave to the north and file through two rollers (each activated by the first cart that passes it, going north); the first roller redirects carts two and three to the west, the second roller gets activated when cart two passes it and pushes cart three off to the west again. The first cart ends up in the top, the second in the middle and the third in the bottom reading row. I built one pressure plate for every possible weight (since there are only three carts per position in this thingy, i even only built three plates each in the top and middle row), so that's the output here. It'd need to be fed into a latch for further data processing, possibly after converting it to binary.

Starting on the same roller makes the exit of carts from the holding cell difficult, they start out almost on top of each other and can collide in the three-way splitter. The leftmost cell gave the most trouble. I eventually used a medium-speed roller for it and added a few rollers to ensure sufficient speed/movement inside the splitter. The carts are sorted into the cell they came from upon return, once again by roller switches run by the same lever that adressed the releasing door. The door must shut by the time the carts return and the switching rollers in the return branch must be operative when the carts pass it; that suggests either a longer delay for the roller logic or some fancy timing work.

"Writing" to this kind of memory would clearly be rather difficult, you'd need minecart magazines holding the required-weight carts and would need to pull out the desired carts in the proper order (and file the former memory contents back into the magazines). There wouldn't be much you could do directly with the memory, just reading, writing, and reordering the carts. The main attraction is that the memory itself could be quite compact, taking only four tiles, one roller, one door and three carts to hold ~10 bits of information.

EDIT - reading eight different cart weights to give a clean three-bit output is remarkably easy, come to think of it; it takes no more than four pressure plates, directly linked to the bit states.

Spoiler: really obvious for people who are fluent in computer, i should think (click to show/hide)

Let's say we have weight groups one through eight, each heavier than the one before. So we'd set up our pressure plates like this:
Pressure plate A - highest bit: activates for weight groups five through eight
Pressure plate B - middle bit: activates for weight groups three through six
Pressure plate c - lowest bit: activates for weight groups two and three
Pressure plate C - lowest bit: activates for weight groups six and seven

Cart 1 activates no pressure plates - binary value 000
Cart 2 activates pressure plate c - binary value 001
Cart 3 activates plates B and c - binary value 011
Cart 4 activates plate B - binary value 010
Cart 5 activates plates A and B - binary value 110
Cart 6 activates plates A, B and C - binary value 111
Cart 7 activates plates A and C - binary value 101
Cart 8 activates plate A - binary value 100

Plates A and B are only linked to one bit each and are thus naturally unambiguous, c and C are both linked to the same bit, but cannot be active at the same time since their activation ranges do not overlap. At worst, you'll need to make sure there's enough cooldown time for pressure plates to reset between readings.

Evidently, any number of different-weight carts can be clearly distinguished using no more than half the cart number in pressure plates, rounded up. This is not likely to be particularly useful at 16 minecarts, though, since that would still mean eight plates to generate four bits of data, not to mention balancing cart weights by coming up with adequate cargo loadouts for six additional weight groups, although that might be easier than expected by loading carts with water or magma.

I'm seriously considering ironing out the bugs on this one and implementing it for main data storage; 96 minecarts could be held in 32 memory stores, each holding 9 bits of information, just over a byte. In theory, you'd still need to have up to 768 carts available to be able to store every possible memory state, although some states should be much less likely, so you might get away with, say, 100 carts of minimum weight (wood) to stand for bin000, if that's your basic "empty" state of memory, while other types wouldn't need to be nearly as abundant. Compared to bitwise data storage, this could save a lot of space and machinery, but would be quite a bit slower to respond and limited in the operations that could be done on stored data directly.

[Larix]

Toggling bridges with a lever-flip

Isn't it inconvenient to have to memorise the proper "on/off" lever states? Wouldn't it be easier to have a simple "flip and it's open/flip and it's closed" lever logic? To simply toggle a bridge's state when a creature passes a pressure plate _and keep it in the toggled state_?

It's actually easier than one might imagine in the case of bridges and other delayed-reaction buildings. The basic rule of signal/building interaction in DF is
- a building assumes the state of the last valid signal it received.
In the case of doors and hatches that is just the last signal, but in the case of delayed-reaction buildings, it's the last signal received _while no reaction delay was running_. Thus, to cause such a building to toggle, all you need to do is send it an opposed signal pair separated by less than the delay. This is relatively easy to do, although not 100% reliable when working with a dwarf-operated lever - just issue a pair of "pull lever" tasks. Usually, the dwarf who takes the first job will simply remain at the lever and perform the second pull as well.

It takes a bit more construction for other types of signals used, but really only a bit.

MPL bridge toggler, run by a signal cycle (e.g. pressure plate):

Code: [Select]

#▲═▼▼═▼▼     #══════╗     #▲^▼¢═▼¢
      ╚╝           ╚╝       a b ╚c
Structures    Track       Buildings
a - pressure plate (Track) linked to bridge and hatch at c
b - hatch linked to input pressure plate (not visible, _must_ be something sending a short on-off cycle, e.g. a plate activated by a passing minecart or dwarf)
c - hatch linked to pressure plate at a

While awaiting input, the cart bounces between the left pit and the wall at the outer western end, keeping the pressure plate active and the hatch at c open. When the input turns on, the hatch at b opens, the cart leaves the pit to the east and cycles through the eastern pit (stable loop as long as the hatch at c is open). After ~100 steps, the pressure plate at a resets, the operated bridge receives an extend/lower signal and the hatch at c closes. The cart can no longer cycle but instead leaves the eastern pit going straight west, re-activating the pressure plate (sending a retract/raise to the bridge) and will settle into the western "holding cell", if the input has re-set in the meantime and the hatch at b is closed again. The "off" signal is sent first and comes ~20 steps before the renewed "on" signal, thus a bridge run from the circuit will turn each input signal cycle into a toggle.

This circuit can fail to work properly when the input pressure plate is occupied for longer times - 20 steps or more. It works reliably when the input comes from a minecart-operated pressure plate; guided minecarts are fast enough to produce 100% reliable toggles.

MPL bridge toggler, turning single lever pulls into bridge toggles

Code: [Select]

#▼═▼▼     ════╗     ▼¢^▼¢
   ╚╝        ╚╝      ab╚c
Yes, there's a ramp below the wall on the eastern end.
a, c - hatch covers, both linked to the input lever
b - pressure plate linked to output
This uses the "fast pass" behaviour discovered by itg in the construction of the lunar calendar - the pressure plate reset time is 99 steps, while the reaction delay of bridges and many other buildings is 100 steps. If a pressure plate's trigger condition is only fulfilled for a single step, the re-set "off" signal will be issued _just_ before the building's ready to register it. A previously-off building will thus only execute the "on" command and will ignore the "off". A previously-on building won't react to the "on" and will thus perform the "off" action just fine.
The ramp bugs treat tiles past ramps as much shorter than they actually are, thus a cart coming from a self-lift pit will only ever spend a single step on the tile behind the ramp. By combining those two peculiarities, a very compact device could be built that turns a single lever pull into a state toggle of a bridge, regardless which way the lever is switched:

A cart starts out (and if the lever is pulled to off, will always arrive and stop there) on top of hatch a. When the lever is turned to "on", the cart falls into the pit, self-lifts out of it, passes over the pressure plate (sending the toggle) and settles into a stable loop in the eastern pit/track cycle. When the lever is turned to "off", both hatches close, the cart reflects off the closed hatch at c, leaves the cycle going west and passes back over the pressure plate (sending a toggle to the bridge) and comes to a stop on top of hatch a. This design won't work properly when the input switches quickly.

Final thoughts:
These designs not only allow lazy bridge management (just pull the lever, it'll switch the state just fine), it could also be implemented in logic by building a logic cell holding an on/off directly dependent on the bridge's state, a kind of toggle flip-flop, if you will. You could build two such devices, link one to a bridge, the other to the same _and_ to a second bridge, to have a double-bridge toggler. Through the first (single-linked) one, you could switch the bridge pair between equal phase and opposite phase at will (and once again, this switch'd only take a single "toggle it" operation, no need to check bridge vs. lever state). I like the first design especially, because it really turns a signal _pair_ into a state toggle, something that sets it apart from gear assemblies, which can be toggled freely by single signals.
Downside is that due to building reaction delays and dependance on plate-recovery "off" signals, response times are quite long - you can't extend/lower a bridge in less than 200 steps this way. In unpowered systems, the bridge reactions will also take significantly different times to execute: with the second design, you'll have an "on" response after ~120, an "off" only after ~220 steps. In powered collision-based systems, this difference could be reduced to five steps or less.

Standard disclaimer: this isn't theoretical speculation, both designs were built and have proven functional.

[Nil Eyeglazed]

Toggling bridges with a lever-flip

I think it's worth commenting a little bit on this problem and your solution from a more general perspective.

DF (wiki and forum) has adopted the jargon of electronics for talking about machinery like this, but this is a place where different terms would clarify things.

We use the term memory (or flip-flop, or latch), but another word that describes what it does is signal division.  Memory takes an on-off signal and returns either an on or an off.

Edge detection, on the other hand, can also be seen as signal multiplication.  It receives an on or an off and returns an on-off signal pair.

What you have here is a memory cell and edge detection built into a single device.  The tightness of the signal means that only a single half of the signal is getting through.  However, a more general purpose solution to this problem, and one that can be built using any discipline, any set of modular components, is to build input->edge detection->flip flop (toggle memory).

Also, I'm not sure this works as advertised.  Consider lever->bridge.  There are two times it doesn't act as you'd like.  First, when input follows input too rapidly.  Second, when the bridge is controlled by multiple inputs.  The first is never going to be solved by machinery, which can only exacerbate this problem.

But the second isn't actually solved by your circuit either.  When multiple levers control your inputs (hatches), it's easy to reach a situation where changing the state of one lever doesn't change the state of your circuit or trigger edge detection.  This problem cannot be solved without dedicated edge detection of each lever.

Where edge detection of a lever pull is necessary, this is the device I've settled on:

Code: [Select]

####
 ^ó#
####

The lever is totally superfluous, and exists only to drive a dwarf over a pressure plate.

(Edit: removed a bunch of stuff, a new thread is more appropriate place for what i was talking about)

[Larix]

Toggling bridges with a lever-flip

I think it's worth commenting a little bit on this problem and your solution from a more general perspective.

DF (wiki and forum) has adopted the jargon of electronics for talking about machinery like this, but this is a place where different terms would clarify things.

I think it was worse in the olden days. There are some old wiki articles (40d mechanical logic e.g.) that are hard to make sense of because they're using electronics terminology exclusively.
That's not to say it's good now.

With "toggling" in this case i meant quite precisely what i've been doing here - make a bridge change its state to the opposite, whichever that may be. The possibility of running a memory-like device from it is a minor curiosity, it'd be ridiculously inferior to more appropriate designs like Newton's cradle cells.

The second design incorporates an edge detector, so that it can work with each type of lever pull or other single input signal. The first doesn't include an edge detector - it responds to an on-off cycle, allowing it to accept "logic" input (e.g. from a minecart circuit or whatever). 

The crux is the output - an on-off signal cycle, spaced tightly enough that delayed-response buildings can only process one. The result is signal separation, although it's achieved through signal obscuring (sneaking the possible second signal into the "blind spot"). And it serves a very practical purpose - make a bridge change, from a single lever flip or pressure plate pass.

Also, I'm not sure this works as advertised.  Consider lever->bridge.  There are two times it doesn't act as you'd like.  First, when input follows input too rapidly.  Second, when the bridge is controlled by multiple inputs.  The first is never going to be solved by machinery, which can only exacerbate this problem.

If i only want my bridge "flipped", that's not a big problem

I thought i mentioned that input coming too fast will mess up the devices, but o.k., to say it explicitly -

Neither device operates properly when input comes too quickly. The bridge will typically end up in some "default" state or other or oscillate very slowly and haphazardly. Any new input must come after the bridge has flipped and the switch device has settled into a stable state.

Furthermore (ad 2?) a switching device can only handle one input. Multiple devices can be linked to a single bridge (tested and proven; and yes, you'll need to keep inputs _to_ these devices sufficiently far apart that the bridge can react in the meantime), but running the second switch device from multiple levers doesn't make much sense. (I had actually thought that'd stand to reason??)

I had already built a synchronous door-toggler, but in that, door states were still linked strictly to pressure plate states (and it took two pressure plates, each linked to a different door). I quite like that here, several bridges can be operated by a single pressure plate and their states after each switch activation will change, although the operating pressure plate will always end up in the same state.

Code: [Select]

####
 ^ó#
####

The lever is totally superfluous, and exists only to drive a dwarf over a pressure plate.

I used this to generate signal cycles:

Code: [Select]

═^═

Minecart track, two route stops, push when empty after two days. Hey, i always have minecarts to spare.

EDIT: i edited my description to make clearer that the first design takes input from a pressure plate linked only to the eastern hatch, and sending a short on/off cycle (e.g. from logic circuits based on moving minecarts), the second from a lever linked to both hatches.

Final Edit: while my first impression was that you'd been somehow missing the point, i realised i hadn't been clear enough in my descriptive post and had started rambling in silly directions. It's quite correct that this bridge toggling thing has little merit and large complications if applied for computing purposes, for pretty much the reasons you pointed out. I designed both devices to serve a very strictly circumscribed practical purpose (switching bridges) and should have stuck closer to that purpose instead of getting carried away and babbling about logic stuff. And that i shouldn't take so much of the stuff for granted that i have come to understand about DF logic - doubly so since i myself occasionally forget those things when building circuits So - thanks for the input, much appreciated.

[Nil Eyeglazed]

I'm suddenly afraid I sounded critical.  Please forgive me-- I'm not very good with social graces.

I only meant to examine your device's operation at a different level-- with a different vocabulary-- than what you were doing.

(I had actually thought that'd stand to reason??)

Oh, I guess it does, I'm just good at missing the obvious!  Didn't realize you intended it to be per lever.