Getting started with minecarts can be quite confusing and frustrating. It took me a good while to get past the quirks of track engraving and route management. Good luck!
I think the wiki page could profit from being more of a presentation of minecart logic approaches and possibilities. There's Bloodbeard's and Tinypirate's power-and-indirect-pushing approach which makes for very small and configurable powered latches and can be used for an incrementer.
There's the approach with moving minecarts, still just converting roller activity into signals but with various practical applications. I often use variations of the most minimal minecart/power interface for various signal processing purposes:
#===# #R^R#
Just three tiles of straight track between two walls, rollers pointing inside, a pressure plate in the middle. A single minecart. Depending on how you wire up the power supply of the rollers, this can be used as a power-to-signal converter, as a repeater or to convert "held" signals or lever-pulls to signal-pair "pulses" (what's often called an "edge detector"). The PSC and repeater can even be built with only one wall, although that'll consume power while idling and has a longer period on the repeater (~108 instead of ~105 steps, so not a huge deal).
I think that'd be a pretty useful thing to put on the wiki, considering how large and unwieldy these things can become under other logic doctrines. It's still just an extension of mechanical logic.
Then there are the various ways of turning minecart path decisions into logic, and that's where my hatch/ramp stuff comes in, but the same basic principle's also used for derail-speed switches and the switching of powered minecarts. I actually think my shift register is a good example of powered minecart logic - there's a lot of mechanical machinery involved, but the actual information is held by absence or presence of minecarts in the memory rows, a memory status is not represented by gear states.
There's also the question whether to show off a bunch of standard "computing components" like latches, logic gates, repeaters, or larger-scale applications like a clock or dwarven lunar calendar. Or some sort of mix between the two?
Spin memory - i'll try to demonstrate its workings from the ground up:
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.
#▲▲# #==#
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:
╔==╗
╚▼▼╝
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:
╔=╗ ╔▼▼
▼▼╝ ╚=╝
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:
.╔=╗
╔▼▼╝
╚=╝
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:
.╔=╗
╔▼¢╝
╚=╝
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.
Author
Topic: re minecart logic, am i smoking crack? (Read 3561 times)