Print

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

[jjdorf]

Wow... you post quickly...

Nah, just had that second post ready to go, the forum futzed on me a bit, and I answered with the previous post before pasting the last post in and posting.  I'll be studying your design now to see what I can make of it.  It may end up that your ALU is the ALU to use, mechanically speaking.  Hope you don't mind. 

[Shinziril]

If you look carefully at Jong's carry-look-ahead circuit, what it seems to be doing is taking the input of the adder and calculating *all* the carries in a row by using the previous carry in addition to the input signals, separate from the main adder.  It then reroutes the carry-outputs into the main addition circuit in the appropriate places simultaneously, allowing it to calculate the correct value instantly.  I think I'll mess around with designs for this myself . . . we'll see if I come up with anything useful.

EDIT: I also noticed a slight problem with the design for the rotation sensor.  It should work as specified when filled to 7/7 water in all tiles; however, dwarfs filling a pond zone will only fill it up to 6/7 water*.  This can be overcome by designating the pond zone on the level above and then carefully monitoring the amount of water that has been input until it is exactly full, then deleting the pond zone. 

*That is, they will keep dumping buckets of water into the hole until the tile directly below the hole is at 6/7 water.  Thus, if the hole is an extra z-level above what you are actually filling, they will happily dump buckets into it forever, or until you tell them to stop.

[wallie79r]

Oh, gods no. Its finals week, and now I'm stuck considering alternate design theories for basic mechanical logic. Cease your siren call, dwarven wrench!

[Meteorswarm]

Two things:

I've designed a 32-bit carry-lookahead adder in electric gates for a class (broken into 4-bit tiers for sanity), so if you want to look at my circuitry, I'll be happy to share it, but since there's no gate delay with gears and you figured out how to pass the signals, a ripple-carry adder will be just as good.

But, I'm skeptical of the operability of your pre-toggling.  With doors and floodgates and bridges, pre-toggling has no effect; the first signal is ignored, and then they revert to their normal operation, which is why you need to use floodgates AND bridges in fluid logic designs, since their neutral states have opposite logical meanings.

Have you tested your designs physically?  If they work, I'll be very excited, since it means we can feasibly create real circuits, particularly your adder is much more convenient than usual adders are.

If only there were a way to do all of this without linkages, though, or to have linkages triggered by power.

[Shinziril]

Pre-toggling *only* works in the mechanical logic, as you mention.  You just use the "rotation sensor", possibly with the pressure plate inverted from its normal sense, at the end of the line, in order to convert it into the correct signals to various other components.  Essentially, the ability of gears to "toggle" rather than be state-based is the reason we are using mechanical logic with fluid logic "buffer" gates rather than simply using fluid logic for everything. 

[jjdorf]

EDIT: I also noticed a slight problem with the design for the rotation sensor.  It should work as specified when filled to 7/7 water in all tiles; however, dwarfs filling a pond zone will only fill it up to 6/7 water*.  This can be overcome by designating the pond zone on the level above and then carefully monitoring the amount of water that has been input until it is exactly full, then deleting the pond zone. 

*That is, they will keep dumping buckets of water into the hole until the tile directly below the hole is at 6/7 water.  Thus, if the hole is an extra z-level above what you are actually filling, they will happily dump buckets into it forever, or until you tell them to stop.

Yes... I've seen this also.  I'll have to take the dwarven insistence that 6/7 is full with pond orders into account in my build plans.  Also, at work today (while dead and no business coming in, ugh) I had time to look at and truly understand Jong's solution.  I am IMPRESSED.  It works perfectly as the CLU in a two stage adder circuit.  I tried making the adder one stage only, with direct outputs, but, unfortunately, this is impossible.  A fluid Buffer is necessary per bit of operation.  However, my concept of a triple input XOR gear is more elegant than the equivalent triple input XOR (needed for the final calculation of A + B + Carry) he uses.  Simply, link those inputs to a single gear and have it drive the final output sensor.  I also intend to design a specialized version of the Adder for use in my program counter circuitry, so that I don't have to co-opt the ALU for moving to the next instruction in memory.

I also learned four things:

First, my original plan for an XOR circuit is just as important as the plan currently on my wiki page, since it demonstrates that an XOR can be built of more fundamental gates.  This is what I was not understanding about Jong's adder diagrams.

Second, Gears should be thought of as being of three types:  Driven by an input and non-toggled, Driven by an input and pre-toggled, and Undriven.  Undriven gears are not linked to any lever or pressure plate.  They will always pass power if there is a path.  Driven gears will only pass power if their input source is true (for non-toggled driven gears), or false (for pre-toggled driven gears).

Third, Two gears, both driven by the same input, adjacent, with one pre-toggled, but not the other, will NEVER transmit power from one to the other.  I am going to call this arrangement as being "out of phase", because when one is engaged, the other is disengaged... ALWAYS.

Fourth, To fully understand a gear circuit on paper, make copies.  For each copy, set the values of driven gears appropriately for a given set of inputs to 1 or 0 (by replacing the gear in the diagram).  A gear must be non-toggled and have an input of 1, or pre-toggled and have an input of 0, in order to have a 1 as its value; all other driven gears are 0.  Then, start at the power gear(s) and replace that with a 1 to indicate the circuit has power.  Follow the path of the 1 gears orthogonally until there are no more paths to take.  You cannot transfer power from a 1 gear to a 0 gear.  You cannot transfer power from a 1 gear that is isolated from a power source, i.e.: you must be able to trace back to a power gear.  If an output gear is reached, its output will be 1, no matter what.  If an output gear is never reached, its value is 0.  This allows a person to test and verify a PTML circuit before and without ever building it.

To demonstrate the third and fourth principles listed here, I will diagram and demonstrate an XOR chain.

Code: [Select]

PAb
BaO
P is power, A is non-toggled linked to input 1, B is non-toggled linked to input 2, a is pre-toggled linked to input 1, b is pre-toggled linked to input 2, and O is the output gear.  Note that the A and a gears are out of phase, and thus, will never transfer power to each other.

AB = 00

Code: [Select]

PAb  P01  101
BaO  01O  010

AB = 01

Code: [Select]

PAb  P00  100
BaO  11O  111

AB = 10

Code: [Select]

PAb  P11  111
BaO  00O  001

AB = 11

Code: [Select]

PAb  P10  110
BaO  10O  100


Two things:

I've designed a 32-bit carry-lookahead adder in electric gates for a class (broken into 4-bit tiers for sanity), so if you want to look at my circuitry, I'll be happy to share it, but since there's no gate delay with gears and you figured out how to pass the signals, a ripple-carry adder will be just as good.

No need.  In actual fact, contrary to the nature of electronics, Jong's design is perfect and works even better than the electronic equivalent.  One can easily build an n-bit CLU from his design with minimal complexity.  This is what threw me, as I was expecting to see a great amount of circuitry growing even more towards the MSB of the adder.  With gear logic, more circuitry is not needed.  And what's more important is that the result is a guaranteed two phase process.  The first 100 steps accumulates the carry values all at once.  The second 100 steps adds those values and the original AB inputs.

But, I'm skeptical of the operability of your pre-toggling.  With doors and floodgates and bridges, pre-toggling has no effect; the first signal is ignored, and then they revert to their normal operation, which is why you need to use floodgates AND bridges in fluid logic designs, since their neutral states have opposite logical meanings.

PTML never touches doors, floodgates, bridges, etc., unless you want the end result, say of a computer's GPIO block, to affect the status of such constructions.  And when that happens you are using a truth value from the end result, not from halfway through the calculation.  I think Shinziril may explain this better than I do, too.

Have you tested your designs physically?  If they work, I'll be very excited, since it means we can feasibly create real circuits, particularly your adder is much more convenient than usual adders are.

If only there were a way to do all of this without linkages, though, or to have linkages triggered by power.

Yes, I have tested enough of these designs to know for a fact that they work, and using my methodology for tracing the truth value in a PTML circuit, anyone can verify that a design works, without ever needing to build it in game to be certain.  This methodology is how I verified to myself that Jong's CLU circuitry does function exactly as needed.

Oh, gods no. Its finals week, and now I'm stuck considering alternate design theories for basic mechanical logic. Cease your siren call, dwarven wrench!

  Sorry... I think?

Coming soon:  The full design for my 8 bit adder unit, including details for implementing subtraction.

[jjdorf]

The 8-bit Adder Module, including optional subtraction of input B.

This takes two 8 bit numbers, A and B, and an additional input Z.  Z is false if we are adding, true if we are subtracting.

First, we need the initial carry value as an "endcap":

Code: [Select]

  *ZP

Each bit in the adder is built with the following circuitry, and each A, B, a, and b are for the current incoming bits:

Code: [Select]

  CC
PBAa  PS
  bB
Note that the C gears are undriven, and one is used as the input to a rotation sensor.  Also note that the b and B gears have a second input, Z, the initial carry value.  The final sum gear, S, is non-toggled and linked to the output of the rotation sensor connected to the corresponding C gear, the A input, the B input, and the Z input.  It is, essentially a four input XOR gate.

The complete design, excluding the rotation sensors, is as follows:

Code: [Select]

  CC
PBAa  PS
  bB
  CC
PBAa  PS
  bB
  CC
PBAa  PS
  bB
  CC
PBAa  PS
  bB
  CC
PBAa  PS
  bB
  CC
PBAa  PS
  bB
  CC
PBAa  PS
  bB
  CC
PBAa  PS
  bB
  *ZP
There will be rotation sensors under one of every pair of C gears, and under each S gear.  The sensors under the S gears provide the added value.  Subtraction of B is enabled any time the Z input is on.  This is done because in binary numbers, the negative of a number is the logical inverse plus one.  Thus, any instruction set using this assembly needs to ensure that the opcode for adding uses a zero in a bit that the opcode for subtraction has a one at.  This bit in the opcode can then be used to enable or disable subtraction from just one bit of the opcode.  Jong's instruction set in the Razorlength computer has this feature, and mine will as well.
One can plainly see that this adder can be extended to any number of bits by simply constructing more bits of the CLU and final Summer.  This design could add 1024-bit numbers as easily and swiftly as it adds 8-bit numbers, with respect to the number of frames used.  The actual game, however, would slow down, obviously.

I still have to finalize my idea for a data bus, which, for my design will be 8 bit data, 8 bit address, a power supply line and a read/write signal.  The clock will be co-opted into the power supply line.  I am debating whether I am going to have one quarter of the memory be utilized by CPU registers, or if I am going to leave them off of the data bus.  That's where I'm at at the moment.  A preliminary diagram of a connection to the data bus for the curious:

Code: [Select]

||||||||||||||||||
|D|D|D|D|D|D|D|D|P
A|A|A|A|A|A|A|A|W|
||||||||||||||||||

Funny how it turns out to look similar to the staggered pinout on an actual AGP card....

One of the potential benefits of the data bus will be that I can build a smaller amount of memory initially for testing purposes, then add more to it, by using a sequence of AND gates on the higher portion of the address lines to enable or disable reads and writes.

Something like the following:

Code: [Select]

   __
P7654E
Where the numbers with lines over them are pre-toggled.  The boolean equation for this would be, P AND 7 AND 6 AND NOT 5 AND NOT 4.  Meaning the power would only transfer if we are addressing memory module number 12 of 16.  This AND-chain would be needed on each incoming and outgoing bus line to a device.  Come to think of it.... I may simply eliminate the address lines for the higher bits that address the correct module... nope.  I'll have to.  Now I'm just rambling aloud.  I really should withdraw from society again...

[Shinziril]

Here's a link to my constructed version of that adder (I was working on it at the same time, and apparently came up with the same idea you did).  It's not fully complete yet, and I think I managed to mess up the subtract-selector logic somehow (it seems to be giving me the bitwise inverse of the correct answer), but you can see how I set up the "support framework" around the logic and kept it as compact as possible.  I also like that I managed to use a single powertrain to power the entire assembly. 

If you're having trouble comprehending it due to the fact that all the gears look the same, take the diagram for Jong's carry logic unit and rotate it counterclockwise 90°.  The top three rows of gears are oriented in exactly that pattern, and the bottom row is the triple-XOR combiner unit. 

[jjdorf]

Here's a link to my constructed version of that adder (I was working on it at the same time, and apparently came up with the same idea you did).  It's not fully complete yet, and I think I managed to mess up the subtract-selector logic somehow (it seems to be giving me the bitwise inverse of the correct answer), but you can see how I set up the "support framework" around the logic and kept it as compact as possible.  I also like that I managed to use a single powertrain to power the entire assembly. 

If you're having trouble comprehending it due to the fact that all the gears look the same, take the diagram for Jong's carry logic unit and rotate it counterclockwise 90°.  The top three rows of gears are oriented in exactly that pattern, and the bottom row is the triple-XOR combiner unit.

The biggest problem with DFMA maps is that you cannot tell what gear is linked to what, sometimes even when you use multi-colored gears.  This makes such maps extremely difficult to decipher, even more so than my current method of diagramming.

I'm still trying to decide on my data bus idea.  Three things I need to decide.  First, how many bits of the 8-bit address will reference a memory module.  I'm hovering at choosing 2 or 3 bits, making an address into VVAAAAAA or VVVAAAAA, where the V bits are device selectors and the A bits are address selectors within a device.  The second decision:  Whether I want to include the device selection bits in the data bus physically, or whether they should only be included in AND gates at each bus input section, pre-wired for correct operation.  The third decision:  Whether the CPU internal registers will be memory addressable (though not writable by the memory writing instruction).  If they are memory addressable, I will need extra logic for read/write selections internally.  If they are hardwired and not visible to memory, then they won't be a part of the data bus in any way.

I'm fairly certain that the data bus itself is going to end up as a stack of gears and vertical axles, with devices alternating on either side of the bus structure.  Two device bits will mean the bus will only have four devices allowed.  The bus would end up being at least 4 z-levels high, with the bottom two levels being shared by two devices and the top two levels being shared by the other two devices.  The "connectors" could be spaced apart and even extended if necessary.  Considering this, I'm going to go with a two bit device identifier.  This leaves 6 address bits for device internal memory, and means each device on the bus will have 64 addressable bytes of data.  I think one of the devices I'm going to develop is going to be a display adapter, monochrome.  It will be a 32 by 16 pixel display, where every pixel is a colored floor hatch.  Each row will be 4 bytes.

My first draft design for the data bus is as follows:

8 bits of data, driven through axles and gears.
6 bits of device address, driven through axles and gears.
1 write enable, driven through axles and gears.
1 read enable, driven through axles and gears.
2 bits of device selector, as pressure plate links to the device selector circuitry.

The layers of a bus connection will look like this (with + being a vertical axle, which can be dropped on either the top or the bottom of the bus, depending on where the "driver" of the bus is):

Code: [Select]

y y y y y y y y
X X X X X X X X
D+D+D+D+D+D+D+D+
X X X X X X X X
Y Y Y Y Y Y Y Y

 y y y y y y y y
 X X X X X X X X
+A+A+A+A+A+A+R+W
 X X X X X X X X
 Y Y Y Y Y Y Y Y
This view shows how the device selectors will work.  X and Y inputs are the device selection inputs.  Since the north side of the bus uses X and y gears, it will enable when the device selected is device 10, or 2.  The south side of the bus uses X and Y gears, so it corresponds to device 11, or 3.  The other two devices would use xY and xy gears to enable.  I have dropped my idea for power supply via the data bus.  Instead, I am doing what I needed to do, make separate Read and Write enable lines.

[jjdorf]

A big Major notice to everyone following along.  I just tested the rotation sensor.  Not only does it function, but it conserves water completely when primed with 7/7 water in the bottom layer as I specify in the design.  When the pump gets turned on, the tile where the pressure plate goes gets zero water.  None at all.  Exactly as intended.  I let it run for well long enough to verify that no frames ever allow any water in that tile.  It's as if the pump makes a wall of water right at the edge there.  In fact, just as I planned, you could do maintenance on the pressure plate while powering the pump.  Because there isn't any water in the tile when the pump is on.  I have a movie if anyone is interested in seeing it in action, though my test leaves out the pressure plate as unnecessary.

Edit:  Changed "my design" to "the design", since I actually did not originate this idea.

[jjdorf]

This view shows how the device selectors will work.  X and Y inputs are the device selection inputs.  Since the north side of the bus uses X and y gears, it will enable when the device selected is device 10, or 2.  The south side of the bus uses X and Y gears, so it corresponds to device 11, or 3.  The other two devices would use xY and xy gears to enable.  I have dropped my idea for power supply via the data bus.  Instead, I am doing what I needed to do, make separate Read and Write enable lines.

In retrospect, the read and write lines are also not physically needed.  This will be controlled via another FL Buffer operated signal, which will fan out to all of the devices.  The new design:

Code: [Select]

y y y y y y y y
X X X X X X X X
D+D+D+D+D+D+D D
X X X X X X X X
Y Y Y Y Y Y Y Y

 y y y y y y
 X X X X X X
+A+A+A+A+A+A+ +
 X X X X X X
 Y Y Y Y Y Y

Each input group (the XY gear assemblies) can be moved further from the bus when necessary to make logic work.  Specifically, this will be needed for the data lines if Read/Write access to the module is necessary.  From the side, a data line with Read/Write access will look something like this:

Code: [Select]

D--EXYR
     r
The floor between the Y gear (whether it is pre-toggled or not, based on the device selection) and the lower r gear is channeled out.  On a positive Read signal, the R gear will engage and the r gear will disengage.  When memory access for either write or read is disabled, the E signal, which controls the E gear, will be off.  This will disengage the E gear and prevent writing to the memory bus when not needed.

I am considering, still, whether the bus can/should be used for accessing internal registers.  Though, at this point I am certain I do not want the registers to be readable through the memory address space, I wonder if this bus circuitry is better suited to enabling writes and reads to the registers.

[Jong]

The idea of linking multiple inputs to a single gear is really brilliant. You must direct me to the post where it was first mentioned.

Anyway I was inspired to create a scheme for a single stage carry look ahead adder. The idea was that I could rearrange the gears in the sum circuit such that the C gears were at the root of the logic tree, or in other words closest to the power source. In this manner, the availability of the power supply can substitute for the triggered gear. So I could directly hook up the adder to the output of the carry logic circuit.

However this necessitates the inclusion of an inverse carry logic circuit so that the inverse c gears can also be similarly substituted.

This was the result.



I used a colouring convention here to indicate the default state of the gear, which also indicates whether it is pretoggled or not. The light coloured gears are by default disengaged so they are the pretoggled ones.

I was reading your posts a little more carefully because I was wondering how your adder worked. Then I realized that the single gear labeled S was a triple input gear that substituted for the whole adder. I was pretty astounded.

So I was inspired once again to replace most of my adder's logic with double input gears. The amount of optimization is really staggering.



This modified circuit is identical in function to the previous one and has far fewer gears.

The gears marked A/B # are your pretoggled double input XOR gates. The gears marked AB # are the same but they are not pretoggled. I discovered that this configuration combines an AND gate and a NOR gate, which just so happens to be applied in the adder.

 I believe I have really outdone myself this time.

EDIT: I found the post! Hmm.. I think in most cases it won't be necessary for the inputs to arrive at exactly the same moment. Here's something you can try to see if it breaks. You can link a lever multiple times to the same object before the first link job is completed. I tried linking a gear twice to the same lever to see what would happen. Pulling it didn't do anything as expected. You could try it with more linkings and see if the relationship holds up.

[se5a]

Cease your siren call, dwarven wrench!

I see what you did there.


Man, I wish I had the patience to do a full out dwarven computer.
I've messed around (in my head, don't think I got around to creating it) with AND and OR gates, for just simple water level on a waterfall control.

[Jong]

I noticed you intend to create a display device. 32x16 right?

My concern is that with only 8-bits you may have insufficient memory to store an image to display. I'm not entirely sure how your data scheme works but my computer was also 8-bits and it faces a number of constraints.

The 8-bit instruction size allowed for 8 instructions and 32 memory addresses. With 8-bits each, this comes to a grand total of 256 bits. A 32x16 display has 512 pixels! If you cut down the number of instructions to 4 and the addresses to 64, that comes to 512 bits of memory, at the cost of a truncated instruction set and having no room for programs!

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?

However adding even more memory is a big challenge. My design for memory cells is still a tremendous real estate hog. This is mainly because it uses pumps in its operation. I was thinking a fluid logic inspired system could potentially be more efficient, as it could use hatches or doors, which could take much less space. Its all about the management of the water sitting on the pressure plate, which is just a single tile.

[jjdorf]

The idea of linking multiple inputs to a single gear is really brilliant. You must direct me to the post where it was first mentioned.

Thank Dorf3000 for this idea.

Anyway I was inspired to create a scheme for a single stage carry look ahead adder. The idea was that I could rearrange the gears in the sum circuit such that the C gears were at the root of the logic tree, or in other words closest to the power source. In this manner, the availability of the power supply can substitute for the triggered gear. So I could directly hook up the adder to the output of the carry logic circuit.

However this necessitates the inclusion of an inverse carry logic circuit so that the inverse c gears can also be similarly substituted.

This was the result.

(Big Intimidating Image)

I used a colouring convention here to indicate the default state of the gear, which also indicates whether it is pretoggled or not. The light coloured gears are by default disengaged so they are the pretoggled ones.

I was reading your posts a little more carefully because I was wondering how your adder worked. Then I realized that the single gear labeled S was a triple input gear that substituted for the whole adder. I was pretty astounded.

Yes, I liked that part too...

So I was inspired once again to replace most of my adder's logic with double input gears. The amount of optimization is really staggering.

(Smaller Intimidating Image)

This modified circuit is identical in function to the previous one and has far fewer gears.

The gears marked A/B # are your pretoggled double input XOR gates. The gears marked AB # are the same but they are not pretoggled. I discovered that this configuration combines an AND gate and a NOR gate, which just so happens to be applied in the adder.

 I believe I have really outdone myself this time.

Yes.  Yes you have.  Fewer gears and single stage adding is awesome.  It means my computer architecture will be even safer.  I plan on using a four phase cycle for it: Instruction fetch, Operand Fetch, Instruction Pointer Increment, then Execute.  A single stage adder means all of the things I'm planning on pre-calculating while the timer is progressing through the fetch and increment stages will be completely guaranteed to be done by the execute phase is reached.  More on this later on...

EDIT: I found the post! Hmm.. I think in most cases it won't be necessary for the inputs to arrive at exactly the same moment. Here's something you can try to see if it breaks. You can link a lever multiple times to the same object before the first link job is completed. I tried linking a gear twice to the same lever to see what would happen. Pulling it didn't do anything as expected. You could try it with more linkings and see if the relationship holds up.

Yeah, that was just me worried that the gear might not toggle if two signals are received at the exact same time step.  I tested and verified that the gear toggles correctly, though I never thought to just use a doubly linked lever.

I noticed you intend to create a display device. 32x16 right?

Yup.  In a bit I'll show off the instruction set, the register set, the memory's address space, and my timing cycle.

My concern is that with only 8-bits you may have insufficient memory to store an image to display. I'm not entirely sure how your data scheme works but my computer was also 8-bits and it faces a number of constraints.

The 8-bit instruction size allowed for 8 instructions and 32 memory addresses. With 8-bits each, this comes to a grand total of 256 bits. A 32x16 display has 512 pixels! If you cut down the number of instructions to 4 and the addresses to 64, that comes to 512 bits of memory, at the cost of a truncated instruction set and having no room for programs!

My instructions will be 8 bits for the opcode, and some instructions will have an additional 8-bit operand.  Specifically, memory addresses will be 8, not 5, bits.  This gives me 256 addressable bytes, or 2048 bits of addressable memory.  I do notplan on constructing every last one of these immediately.  Thus I needed to have the bus designed and constructed so that I could, like real memory chips, "plug in" a new bank of memory when I decided to make more.  It also means one of the bus devices will be a 512 bit monochrome display.  Initially, I'm going to place the display in bank 11, and have only one bank of RAM at 00.  That first bank of RAM will actually be slightly special, too, as it will also have a couple General Purpose Input bytes and a couple General Purpose Output bytes.  GPI will be linkable to any lever or pressure plate anywhere.  Such as a lever for controlling the computer.  It'll be like a custom configurable keyboard, of sorts.  The GPO will be used for general operation of hatches, bridges, doors, etc.  I'm putting these in for completeness, more than any other reason.  More on the structure later.

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?

However adding even more memory is a big challenge. My design for memory cells is still a tremendous real estate hog. This is mainly because it uses pumps in its operation. I was thinking a fluid logic inspired system could potentially be more efficient, as it could use hatches or doors, which could take much less space. Its all about the management of the water sitting on the pressure plate, which is just a single tile.

Yeah, real estate is going to be the big problem on this one.  I'll be upping the z-levels between layers greatly in my world-gen when I actually move out of design and into building.  I'll probably end up wanting a good 20 layers of solid rock available to play with.  I'll also be turning off HFS for this.  Now that I think about it, isolated from everything but dwarves would also be a good idea, though that usually results in untamed wilds, and knowing DF2010's military hit and miss bugginess, I want as little fighting to do as possible.

Now... The Instruction Set (Preliminary, not QUITE set in stone yet)
One Byte Instructions
NOP:00000000 - No Operation (WE:-, RE:-,Length:1)
HLT:00000001 - Halt Computer (WE:-, RE:-,Length:1)
SHL:0x000010 - Shift Left Logical (x2) (WE:R0, RE:RSLT,Length:1)
SHR:0x000011 - Shift Right Arithmetic (/2) (WE:R0, RE:RSLT,Length:1)
NOT:0x000100 - Bitwise Not (WE:R0, RE:RSLT,Length:1)
AND:0x000101 - Bitwise And (WE:R0, RE:RSLT,Length:1)
OR:0x000110 - Bitwise Or (WE:R0, RE:RSLT,Length:1)
XOR:0x000111 - Bitwise Xor (WE:R0, RE:RSLT,Length:1)
ADD:0x001000 - Add, R0 = R0 + R1 (WE:R0, RE:RSLT,Length:1)
SUB:0x001001 - Subtract, R0 = R0 – R1 (WE:R0, RE:RSLT,Length:1)
SWP:0x001010 - Swap Registers, R0, R1 = R1, R0 (WE:-, RE:-,Length:1)
NNC:00001011 - Increment Index Register (WE:N, RE:NP,Length:1)
NDC:00001100 - Decrement Index Register (WE:N, RE:NM,Length:1)
Machine Code including x as the second bit disables the WE and RE signals for that operation, which turns ALU commands into test commands that do not subsequently affect the final product of R0.
Two Byte Instructions
LDR [mem]:10000001 [m] - Load Register From Memory (WE:R0, RE:MEM[OP],Length:2)
STR [mem]:10000010 [m] - Store Register To Memory (WE:MEM[OP], RE:R0,Length:2)
LDI [mem]:10000101 [m] - Load Indexed Register From Memory (WE:R0, RE:MEM[OP+N],Length:2)
STI [mem]:10000110 [m] - Store Indexed Register To Memory (WE:MEM[OP+N], RE:R0,Length:2)
LDC [const]:10001000 [c] - Load Register From Constant (WE:R0, RE:OP,Length:2)
NDX [const]:10001001 [c] - Load Index From Constant (WE:N, RE:OP,Length:2)
JMP [m]:11000000 [m] - Jump, IP <= OP (WE:IP, RE:OP,Length:2)
JN [m]:11000001 [m] - Jump Negative, R0 < 0 ? IP <= OP (WE:IP, RE:OP,Length:2)
JZ [m]:11000010 [m] - Jump Zero, R0 = 0 ? IP <= OP (WE:IP, RE:OP,Length:2)
Note that Jumping instructions that test for a condition have an extra requirement for the RE and WE to occur, specifically that the test passes.  If it doesn't pass, the jump instruction will be a glorified NOP, as expected.

Now for the registers:
IP - Instruction Pointer, 8-bit, Memory Access Code: 00, points at the next instruction to fetch in memory
IP+1 - Instruction Pointer +1, 8-bit, Memory Access Code: 01, Virtual register always maintained at IP+1 via a dedicated Adder.
IPI - Instruction Pointer Incremented, 8-bit, Virtual register always maintained at IP+L, where L = Instruction Length.
N - Index Register, 8-bit, used for indexed memory access.
NP - Index Plus One, 8-bit, Virtual register always maintained at N+1 via a dedicated adder.
NM - Index Minus One, 8-bit, Virtual register always maintained at N-1 via a dedicated adder.
IR - Instruction Register, 8-bit, Contains the Opcode of the current instruction to execute.
OP - Operand Register, 8-bit, Memory Access Code: 10, Contains the operand of the current instruction to execute.
OP+N - Indexed Operand, 8-bit, Memory Access Code: 11, Virtual register always maintained at OP+N via a dedicated adder.
R0 - Register Zero, 8-bit, used directly by the ALU, can be semantically swapped with R1 via a simple logic gate.
R1 - Register One, 8-bit, used directly by the ALU, can be semantically swapped with R0 via a simple logic gate.
RSLT - Result Register, 8-bit, Virtual register maintained by the ALU to be the correct result of ALU instructions.
NFLAG - Negative Flag, 1-bit, Virtual "register" maintained by the ALU to be whether the result < 0.  Equal to RSLT's MSB.
ZFLAG - Zero Flag, 1-bit, Virtual "register" maintained by the ALU to be whether the result = 0.  Done with an 8 input NOR gate.

Registers with a Memory Access Code are registers that can be used to address memory.  Addresses are 8-bits.
Virtual registers are Read Only, and can never be selected for a WE with any instruction.  They are maintained by special circuitry to perform their useful functions.

Memory Structure:
Bus Device 00
0-31: DPROM - Dwarf Programmable Read Only Memory.  Essentially a bank of 32 levers properly hooked up to the memory system.
31-59: RAM - Standard Random Access Memory.  Hybrid Logic Memory Cells hooked into the memory system.
60-61: GPI - General Purpose Input.  Reprogrammable buffers that can be hooked up to any desired input signal (lever, plate).
62-63: GPO - General Purpose Output.  Hybrid Logic Cells Driving additional Buffers that can be reprogrammed to control arbitrary mechanisms.
Bus Device 01
64-127: RAM - Initially will be unused.
Bus Device 10
128-191: RAM - Initially will be unused.
Bus Device 11
192-255: MGA - Monochrome Graphics Adapter.  Hybrid Logic Memory Cells preconfigured to drive a set of colored hatches for monochrome display.  Arranged in rows, 4 bytes per row, 16 rows.  32x16 pixel.

Timing Cycle
As stated earlier, the timing cycle will be 4 phase to allow for operation as fast as possible.

IR < MEM[IP]
OP < MEM[IP+1]
IP < IPI
EXECUTE

The Execute phase branches out, based on what opcode is in IR.  For instructions with a RE and WE specified, this is activated here, like so:

{WE} < {RE}

This works because every section of the CPU is running constantly.  Specifically, all virtual registers are updated as soon as possible, and the ALU updates values the moment either R0 or R1 changes, either due to the ALU R0 < RSLT bus write, or due to the SWP instruction.  The design of the ALU does not update RSLT if IR contains a jump instruction.  By the time the updated register is needed, it has been pre-calculated.