Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Son of The Return of Dwarfputing Part Two: chewing honeycombs and taking numbers  (Read 1203 times)

Larix

  • Bay Watcher
    • View Profile

Thanks to Snateraar, who suggested an rng, inspiring me to actually try and put the circuit into use:

Spoiler (click to show/hide)

Behold: Roll a Number! The powered minecart randomiser drunkinator



That's all there is to it on this z-level.
Spoiler (click to show/hide)
Memory to store four Drunk Bits:



EDIT: Wow, was that a bad design. The decision to let 'off' carts freely cycle through the arrays until the doors closed fouled up the storage on a regular basis - seems that if a door tries to shut while a cart tries to pass through (may be made worse by possible diagonal movement), the door jams and the cart gets stuck, i.e. stops dead. It needs to be manually replaced onto a roller and the door signal fully cycled. Don't use this design, it's botched.

Spoiler (click to show/hide)
My first stab at the matter used my beloved perpetual-motion minecarts:

Spoiler (click to show/hide)
« Last Edit: July 31, 2013, 03:26:05 pm by Larix »
Logged

Crashmaster

  • Bay Watcher
  • CARP, Canada's new helth care plan for the elderly
    • View Profile

Awesome. I'm going to try and understand this later.

wierd

  • Bay Watcher
  • I like to eat small children.
    • View Profile

I still think he should try building a MOS 6502.

Giving it a small memory bank, and an output array of hatch covers for simple 1bit/pixel graphics, would let a real compiler make initial programs to run sandboxed in DF stop being just an idle question, but a reality.

Even if the execution speed is painfully slow, even just running a simulation of "life" on a real GP cpu implemented in dwarfputer logic would be a big accomplishment. 

That's the real beauty of a real GP cpu. It can run a slower simulation of any other device, if it has instructions on how to do so. EG, it could produce random numbers if fed an appropriate algorithm. :D

Logged

Drazinononda

  • Bay Watcher
  • I'm really too normal to play this game so much.`
    • View Profile

I hate threads like this because they always remind me of how unskilled and ignorant I am.
Logged
Children you rescue shouldn't behave like rabid beasts.  I guess your regular companions shouldn't act like rabid beasts either.
I think that's a little more impossible than I'm likely to have time for.

Remuthra

  • Bay Watcher
  • I live once more...
    • View Profile

This is awesome. Post to Watch.

Larix

  • Bay Watcher
    • View Profile

I messed around with the parts and built a somewhat smaller four-step incrementer:

Paths: functional buildings fully installed and operational .

Spoiler (click to show/hide)
So the proposed parts of my Drunk Number Generator are:

Pressure plate in a place where it's frequently and not-predictably activated, the ticks of operation are turned into on or off signals by this splitter:

     

then transferred to memory cells like these:

       

Edit: suggested design for four bits of memory:

Paths: with rollers and doors: complete, powered from the centre, above:

NB: haven't tested it yet, but i can see no errors in the design. Checking any individual power-requiring item gives the same 45 requirement, so everything is connected. Added bonus is of course the 100% usage of allocated floor space, although you'll have to include a one-tile perimeter to other cells - everything on the outside apart from the doors will provide power.

Sending the input to the individual memory cells would be handled by an 'incrementer' like the one presented above.
« Last Edit: July 31, 2013, 03:27:24 pm by Larix »
Logged

Larix

  • Bay Watcher
    • View Profile

I buckled down and built the thing properly.

Roll A Number, or Let them Eat Dwarven Wine Roast, or How to Make a Drunk Byte

A pressure plate is installed where many dwarves can pass across it. The signals produced by the plate are fed into this binary splitter which reacts to "off" signals, turning their exact moments into left-or-right decisions:



The inner rollers work against each other, the outer rollers outwards. The cart keeps bouncing between the two inner rollers until an off signal is received, pass the left or right pressure plate (depending on the last push they received before the rollers turned off) and is cycled into a holding loop shut by an outward-pushing roller in opposite phase to the split roller. Once the signal plate sends an "on", the holding roller switches off and lets the cart return into the split stretch.

Each signal will cause the 'stepper' to advance once:

      

Definitely not optimal, but i was trying to save space and machinery. Each sequence of roller-with-door and roller with a loop counts _one_ signal pair from the binary splitter - the signal sent is always a pair of one "on" and a following "off" ~100 steps later. The cart arrives at a door, landing on an always-on roller pushing forward. Once the splitter sends an "on", the door(s) open. The cart passes through, activates the pressure plate and enters the loop, held shut by a roller which is also on as long as the door is open. Once the incoming signal turns off, the roller switches off and lets the cart advance to the next door (which is closed now). Eight "on" and seven "off" signals let the cart pass the entire cycle and pass a single-action switch which re-starts the whole process on any lever switch.

Spoiler (click to show/hide)

Each pressure plate in the counter loop activates _one_ door in the memory array, and the left-hand pressure plate in the binary splitter activates _every_ corner roller in it:



Maximum space efficiency, yay! It gets difficult to spot the actual paths the carts take (see below), but according to the test run it works accurately. Each single circuit reacts to a proper "on" - door opens while the roller is active, this only happens when the left-hand pressure plate fires and the cart in the counter loop opens the circuit's door - by sending the cart into the holding loop, where it is kept by the forward-pushing roller, as long as the main power stays connected. If the roller is off while the door opens, the cart remains on the corner spot and doesn't activate. The array notionally holds eight bits of information, but there's no distinction between 'has been activated to an off signal' and 'hasn't received a signal yet', so i guess it's not a full eight-bit memory. The device must be observed directly to verify the number generation cycle has executed fully.

The memory is reset by cycling the power of the entire array and opening all doors.
Spoiler (click to show/hide)

The numbers generated are displayed here:
after reset:

They can be interpreted whichever way you wish, with closed hatches as zeroes or ones. Thanks to the super-tight layout of the memory, i accidentally linked the hatches in a different order than they're activated in the generation cycle - they activate in the sequence (counting the hatches, left to right, upper row then lower) 2-3-4-1 8-5-6-7. I'll just pretend shuffling the order of presentation is another measure of randomisation.

I had a hell of a time debugging this thing, i kept messing up toggle rules of the mechanisms, forgot to pre-toggle all of the gears powering the corner ramps in the memory, toggled the main re-cycler wrong and even mis-carved a bit of track resulting in the counter minecart going off course.

Still, i found the whole exercise worth it, i learnt quite a bit about powered minecart usage and the possibilities roller switches offer for DF logic. And once again i'm surprised so few people have really tried using moving minecarts for dwarfputing applications. After all, the full glory and transparent design of the finished machine speaks for itself:



(Still with the fully-installed and operational, but not operated four-step counter relying just on roller-operated holding loops for the step separation)

EDIT: I wasn't entirely happy with the eight-step counter, although it does work adequately. But it looks untidy and definitely wastes space. So i tightened it up a bit, but only as a test/demonstration rig, i didn't go and hook it up to the actual machine (would have taken way too long to rip out all the old connections and tie in the new). Here goes:

Paths: with doors and rollers: complete:

Including the full same-level power supply, it takes up 6x19 5x19 floor space, and has only six track grids and one enclosed floor grid that aren't functionally indispensable. I had to fiddle a bit with the power train, because rollers _can_ transmit power along their front and back ends, the rules just are somewhat funky. Total power consumption is about 170.

Will the postEdits never end? Since in the counter, the rollers pushing against doors only really need to be powered when the door is open, they can also be built switchable, in phase with the holding rollers, or powered by connecting through them. I had originally included a power train to the right, taking up another column of space. In the revised version, all power to the door-pushing rollers is routed through loop-holding rollers, and the entire right-hand power train scrapped, reducing the floor space consumption to 5x19 instead of 6x19. That was enough of an improvement to warrant a re-edit. The design has been tested through lever pulls and works.

A few more odds and ends:
Spoiler (click to show/hide)
« Last Edit: August 03, 2013, 03:43:06 am by Larix »
Logged

Gentlefish

  • Bay Watcher
  • [PREFSTRING: balloon-like qualities]
    • View Profile

You, sir, are a gentleman scholar. I applaud your Scientific research done here! There designs are super compact!