Print

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

[jjdorf]

Well I think your computer's architecture is rather unusual. Your bus design seems to incorporate separate paths for data and address/instructions I think, which doesn't fit into the Von Neumann model my computer used. Could you elaborate on your overall computer design?

Oh yeah, the data bus.  Forgot to elaborate on that.  The bus will have data lines running to the memory banks, and to each register.  The address lines only run to the memory banks, since only they need them.  The RE and WE of the instruction set and basic timing are used by the control circuit to transfer data on the bus at each time step exactly as needed.  The select which of each membor of the bus drives the data lines, and which one writes those driven data lines to their storage.  Virtual Registers are on the bus, but do not respond to/have WE circuitry.

This includes enabling the correct Memory Access Register to the data bus as well.  I will have to do some special logic to make this work swiftly for the device selector.  If anything, right now, that little chunk of circuitry is the most vital.  Maybe I can devise a scheme to select the memory access code before it is needed.

[Shinziril]

Here's a diagram for a fluid logic memory cell, using only doors. 

Spoiler (click to show/hide)

The red squares are the Input doors, hooked up to whatever input pressure plates you are using. 
The green squares are the Write Enable doors, which should be hooked up to the write decoder. 
The magenta squares are, of course, pressure plates (which should be hooked up to something like Jong's "write condenser", so that the additional hardware needed for selective reading can be placed elsewhere). 
The gray squares are unlinked doors, meant to allow access to the various hardware, with a down-stair for access. 
The white row on the bottom is a row of floor with an up stair on the left- this is the water input pipe.  The z-level above this should have a pipe supplying pressurized water. 
The white squares on the top are channel-drains.  This is the water output, and it requires an output collection pipe on the z-level below it. 

I find that the most effective method for the water delivery system is to pump water from a stream into a cistern for pressure (using a fairly wide pump-stack), and have the output pumped back into the river *upstream* of the intake pump stack (to allow recirculation, while ensuring it will never overflow).  You will of course probably want a lever-controlled hatch as the cistern output, and toggleable gears for the pump stacks, so you can shut it down if you need to. 

[jjdorf]

Here's a diagram for a fluid logic memory cell, using only doors.

Interesting... Definitely nice for saving space on the memory bank floor.  I'm just dead set on having a closed system, and that means no infinite water source.  I WOULD be interested in any memory cell that conserves water, requires very little water, and takes up a minimum of space.  I think my Hybrid Logic memory cell is the closest we can get to it, though.

Also, after studying a bit of my timing cycle, I now know that there will need to be one more register, one I was hoping to get rid of:

MAR - Memory Access Register, 8-bit, Virtual register always maintained one step ahead of when it is needed.  This register, like the ALU flags, is not attached to the data bus.  It must be enabled completely by the time a memory op on the bus is occurring.  Thus, each stage that needs a memory access primes this register on the stage preceding it.

[jjdorf]

In preparation of designing the layout in my 3D program, I have discovered something amusing.  A block of 64 bytes (one of four memory devices) will take 16 z-levels, and at least 56 by 35 tiles.  I plan on having room for four of these, plus the other computer circuitry.  I'm gonna need a big embark. 

[jjdorf]

I have finished my design for the four stage timing circuit.  Diagrammed from bottom level to top level:

Code: [Select]

XXXXXX
D1XX2D
XXXXXX
XXXXXX
D4XX3D
XXXXXX

XXDXXX
X#%>#X
X^XX%D
D%XXvX
X#<%#X
XXXDXX

   1
 4***P
  | 2
  3
The pressure plates numbered 1-4 on the bottom layer are set for 0-3 water.  They connect to the gears labeled 1-4 on the top layer.  These numbered gears are pre-toggled.  After linking the pressure plates to the gears and to the timing circuitry of the computer itself, you turn off the power.  Then fill the 1 pressure plate tile with water.  4/7 will do, but I like it to be full at 7/7.  Turn the power back on and watch as your water visits each pressure plate for 100 steps each, round and round, til you turn off the power.  Water is fully conserved in this setup.  Note... the logic from the pressure plates is as follows:

Code: [Select]

t 1 2 3 4
1 0 1 1 1
2 1 0 1 1
3 1 1 0 1
4 1 1 1 0
Which means logic that activates on the timer needs to flip the toggle state of any gear using the signal if it expects the signal to be active-on.

[Jong]

I see that your timing cycle is pretty short. You need to be careful to avoid conflicts in the various data transfers throughout the CPU, but I see that you have a large number of registers prepared for this. One problem with memory cells currently is that it takes 100 steps to write a zero to a non-empty memory cell.

And your timing circuit has some problems. One thing I discovered when building my computer's clock was that pumps do not turn off instantly when their power is cut. That is bad. Plus, because of the 100 step delay for pressure plates to reset, most of the time when your circuit is in operation, 2 pressure plates will be active. My clock used some null cells to hold the water while the active pressure plate reset.

[jjdorf]

I see that your timing cycle is pretty short. You need to be careful to avoid conflicts in the various data transfers throughout the CPU, but I see that you have a large number of registers prepared for this. One problem with memory cells currently is that it takes 100 steps to write a zero to a non-empty memory cell.

I am accounting for that in the registers.  They should be ready by or before the cycle they are needed at.

And your timing circuit has some problems. One thing I discovered when building my computer's clock was that pumps do not turn off instantly when their power is cut. That is bad. Plus, because of the 100 step delay for pressure plates to reset, most of the time when your circuit is in operation, 2 pressure plates will be active. My clock used some null cells to hold the water while the active pressure plate reset.

Actually, I constructed and tested my timing system.  I have a save, and can provide a video if you want.  However, just to state, there is never more than one pump on at a time, and the pumps only activate for about 6 steps total.  The key to the timer is that the plates are on when empty and the gears controlling the pumps are pre-toggled to invert this signal.  This is the reverse logic that most people expect, however, it is easily accounted for by pre-toggling whatever the signal coming from a stage goes to.  Gears are beautiful things.  To give a run down of how it works, I'll take it step by step.

Step 1: Finish building that timer assembly, including linking the pressure plates to pre-toggled gears for the control circuit.  All pump gears are off because there is no water in the system yet.  Also the power itself is off.
Step 2: Fill timer cell 1 to 7/7 water.  The gear for the next pump in line is engaged, but is still providing no power because the power itself is off.
Step 3: Turn on the power.  The first pump moves all the water into the next cell.  Cell 1 plate turns on, immediately turning off the first pump.
Step 4: After 100 steps, plate 2 turns off.  This turns pump 2 on, draining cell 2 into cell 3.  Pump 2 then immediately shuts off.
Step 5: After 100 steps, plate 3 turns off.  This turns pump 3 on, draining cell 3 into cell 4.  Pump 3 then immediately shuts off.
Step 6: After 100 steps, plate 4 turns off.  This turns pump 4 on, draining cell 4 into cell 1.  Pump 4 then immediately shuts off.
Step 7: After 100 steps, plate 1 turns off.  This turns pump 1 on, draining cell 1 into cell 2.  Pump 1 then immediately shuts off.
Step 8: This continues until we pull the power lever and no pump is capable of getting power.  Unless the power is lost at exactly the right time, water stays in the cell it currently resides in.

Now obviously there is some potential for the timer to get one cell ahead of stage 1, though I think it's about a 1 in 100 chance.  The key to dealing with this is my NOP instruction.  That will be the instruction that is always first in the Instruction Register after power is turned on, so if the system starts after time cycle stage 1, all it does is a null operation, causing the timer to resynchronize and then start from memory address 0.

I think I'll figure out how to upload my timer video.  Be right back.

[jjdorf]

I think I'll figure out how to upload my timer video.  Be right back.

Hmmm... Doesn't seem to like my video.  Is DFMA not compatible with DF2010 movies?

[Mawootad]

Though it would massively increase space and (in a number of respects) material usage, you could probably build an ultra-high-response computer using waterwheels for triggers instead of pressure plates.  I'm currently working on basic designs.  Due to the large space of the individual gates and difficulty in containing fluid, I'm not 100% sure if it's even possible, but I'm looking into it atm.

[jjdorf]

Though it would massively increase space and (in a number of respects) material usage, you could probably build an ultra-high-response computer using waterwheels for triggers instead of pressure plates.  I'm currently working on basic designs.  Due to the large space of the individual gates and difficulty in containing fluid, I'm not 100% sure if it's even possible, but I'm looking into it atm.

Waterwheels?  I'm intrigued... not that I'll end up using them, but any more varieties of logic is a good thing.  Even borg logic is good, since it gets people thinking about a mile outside the proverbial box.  I'd love to see a basic whaterwheel logic design.

[Jong]

Hmm.. Since waterwheels are a kind of "flow sensor" and they output power rather than trigger signals, it could possibly be done if the waterwheels provide barely enough power to operate the logic mechanisms. Also, pumps would be the sole source of input/output control as there won't be toggled gears, doors, hatches, floodgates or other traditional staples of dwarven logic as pressure plates are out.

[Core Xii]

Even if you didn't have enough memory to store an entire picture for the display, you could just generate one procedurally! Dwarven fractals, anyone?

I did think that the gear resistor designs on the wiki were ridiculous, but I didn't actually realize you could do this. It's carved in stone in my head that levers don't toggle, I guess. Thank Toady that gears are the exception to this rule, yes?

Now the real biggest problem here is a practical application for computers in DF. It's cool and all but it's a hell of a lot of work for no real end. Then again, it is a sandbox game...

By the way, I couldn't get heads or tails from your data bus diagrams. It would be advisable to always label such charts whether they are top-down or side-view.

Also, using the teletype (tt) tags instead of code you can include underlines to denote floors while maintaining a monospace font (you can also use colors!):

(side view)
PAB
rZC


Oh, one last thing: For pre-triggering gears, you can link ALL of them to a single lever to flip, and save N-1 mechanisms for constructing all the temporary levers.

[Jong]

Oh, one last thing: For pre-triggering gears, you can link ALL of them to a single lever to flip, and save N-1 mechanisms for constructing all the temporary levers.

You can always deconstruct the levers to get them back!

Besides, its a pain when you can only have 10 jobs in the queue.

[jjdorf]

Even if you didn't have enough memory to store an entire picture for the display, you could just generate one procedurally! Dwarven fractals, anyone?

Not sure how that would work.  I know I could limit the display to a text only display, but that would require a memory bank for the text font.  That bank may, however, not be needed within the Accessible RAM... instead it could just be used by the display circuitry.  Then instead of 32x16, it would be 4x2 or 8x1, or whatever, and an 8x8 block of pixels could be flipped in one instruction instead of 8.  Considering how fast things run, this may even be a better choice.  Since the "video" out is far off in the future for me, I'll be giving this some thought.

I did think that the gear resistor designs on the wiki were ridiculous, but I didn't actually realize you could do this. It's carved in stone in my head that levers don't toggle, I guess. Thank Toady that gears are the exception to this rule, yes?

Yup.  One of the coolest things about gears is the fact that, with the limitation that a gear can't directly toggle another gear, you can build any circuit you can imagine.

Now the real biggest problem here is a practical application for computers in DF. It's cool and all but it's a hell of a lot of work for no real end. Then again, it is a sandbox game...

I've thought about this over and over again, and all I come up with is a devious and insidious trap system that constantly keeps victims running for the exit that changes over and over again.  An evil maze that changes randomly, but always has an exit.  Pit the victim and watch them dance in misery.  Other than that... yeah, it's probably just a big bragging rights parade. 

By the way, I couldn't get heads or tails from your data bus diagrams. It would be advisable to always label such charts whether they are top-down or side-view.

True.  But then, my data bus design isn't 100% set in stone, so to speak.  I'm still figuring out the kinks and timing and delays and other irritations.

Also, using the teletype (tt) tags instead of code you can include underlines to denote floors while maintaining a monospace font (you can also use colors!):

(side view)
PAB
rZC

Okay.... Now that I LIKE.  I'll have to keep that in mind.  Is there an easy equivalent for the Wiki?

Oh, one last thing: For pre-triggering gears, you can link ALL of them to a single lever to flip, and save N-1 mechanisms for constructing all the temporary levers.

Yup.  And you only have to flip it once.  The only thing that matters is that the gear is pre-toggled, not how exactly it is done.  You could, if you were nutty enough, do it with a pressure plate.

Also, earlier Jong brought up the question of my timing circuit, and I dismissed, for a bit, his assertion that it needs extra time.  He is, to some extent, correct.  Thus, I'm adding a delay circuit to my design.  The point of this one is that it will always be delayed by a small amount of time (the duration that 7/7 floats in the air before it drops down to the lower z-level, which I've seen take between 4 and 13 steps).  The Read Enable circuitry will go through the delayed timer.  The Write Enable circuitry will be directly driven by the primary timer.  The end result is that Writes will be guaranteed to complete before the next Read Enable, and that read enable will always be delayed at least one step, and likely no longer than around 13 steps.

The delayed timer will use power from the same source as the primary timer, but the gears powering the pumps will be driven by the primary timer's pressure plates.  I'll have to take a look and get this designed and fully functional, but I think this, the jump control circuitry, and the big huge confusing memory bus architecture are the final kinks to work out before I strike the earth.

[Core Xii]

Okay.... Now that I LIKE.  I'll have to keep that in mind.  Is there an easy equivalent for the Wiki?

Not familiar with wiki markup I'm afraid.