Print

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

[M_Gargantua]

Posted something in the suggestion forum, got a bunch of instant positive feedback. Figured I'd post it here.

I plan now on having a giant water/pump/mechanic powered computer. It will have the following:

Syncronous clocked, little-edian, alot like x86 architexture.
Giant water punchcards, same design likely to end up acting as both Ram and ROM
A 16 bit parallel bus
15 registers
128 bytes of L1 Cashe
no L2 cache unless I find it nessessary
256 maximum possible instructions/operations
As many floating point units as I can figure out how to squeeze together.

I'm Already working on the test computer "Tyro", just trying to find optimal ways to setup the bianary addition and subtraction units. Eg, the adder uses two XORs and two ANDs per bit. Its pretty much the most efficient gate useage, but Trying to shrink and combine all 4 is my chalange right now.

The one thing I really do need is someone who knows something about this to help me design the Floating Point unit. I don't even know where to start for that. And without it, division, Pi Calculations, Square roots, all of that nice stuff is out of the picture. As you can see that means considerably less programing options.

Once the tests are completed "Deep Thought will be built on the west face of a crater lake I have in my world, There is apsolute maximum vertical difference, with every square being a big * for change in height. Then I'll build "Hactor" on the east side after revising and bug fixes. Beyond that the sky's the limit.

And just for the hell of it, I already have the shells of plans for giant screens made out of hatchs. A GPU and monitor if you will.

[nagual678]

Your insanity is inspiring. Godspeed.

[I3erent]

I would add [SPEED:1] tag to your dwarves dude or this will take forever....

[DreaDFanG]

Reminds me of something I participated in, it included the entire populus of a moderate town. It was called the "HBC" which meant human binary complex, was the record holder for largest binary computer using humans for a long while. It was very fun, we showed computasions to a passing satalite with live feed...using only one foot wide spray painted cardboard squares, and a numbered shirt that got told what to point up. It looked like wiggly patterns but worked wonderfuly...we did 50 different math problems, which took around three hours...

[JOKE]until someone had the idea to play DF on it and totaly killed the framerate...

[slimtim]

What kind of gates are you using?
because i've been working on a series of water/mechanic gates wich take a little work at the beginning to make a frame to put them on bu take verry little space, but a few z levels.

e:
if you don't mind me asking, where did you find out how these systems work internally, because i've been looking for this for quite some time.

[ April 05, 2008: Message edited by: slimtim ]

[M_Gargantua]

quote:if you don't mind me asking, where did you find out how these systems work internally, because i've been looking for this for quite some time.

Three ways, Figuring things out logically on paper, Wikipedia, and:
http://home.pipeline.com/~hbaker1/hakmem/hakmem.html  was especially helpful.

[Nadaka]

That is an impressive goal. Probably a little too impressive. You are going to have huge latency and timing issues. Thats not even counting the complexity an space limitations. You are going to have to build in 3d as a single level will just not have enough space for all the gates you need, not even counting the circuitry.

You mentioned you wanted floating point math? I would suggest against it personally. The added complexity probably beyond whats practical. Now I am going to have to pull out my micro computer architecture book.

also note that a 16 bit bus is not needed either, at only 128 bytes of  memory, you only need 7 bits to address the entire space. besides that a 16 bit bus will be 33 tiles wide. that is a lot of area. especially when you consider that to reference your memory you will need both an address bus and a data bus.

My suggestion is a 10 bit bus, as it allows you to address the intended 128 bytes and even lets you have up to 1k memory if you need to expand.

[ April 07, 2008: Message edited by: Nadaka ]

[numerobis]

Is there a demonstration of a 4-bit ALU even?  To go from there to a programmable computer is a heck of a stretch.  Let's not mention the 16-bit bus.

[M_Gargantua]

The bus is going to be a teleportation thanks to the grand power that is pressure plates.

Currently I'm working on instruction and memory decoders. Its easy enough open the proper floodgates given a single input, but I'm trying to figure out the best way to 1) Pass the 4 bit register address, brute forcing it is easy since its only four bits, but 2) Passing the 8bit command instruction may prove a bit more complex since, while I won't need them all right away, I can't think of any efficent way open the proper rout out of the 128 possibilities given 8 inputs. That I could use help with.

And the FPU is a later project, but still always in the back of my head.

[Nadaka]

The punch card idea one way of doing it. Another is to use a shared memory architecture where both the program and data are in the same addressable memory. over all this would be a more flexible design and would actually make working with the system a bit easier.

you mentioned registers, l1 cache and possible l2 cache... Why? what benefit will this more complex configuration provide? the difference between registers, l1 cache, l2 cache and RAM is only distinct due to cost and speed. is making "faster" memory sufficiently more difficult that you want to maintain that distinction? Why not just use a single addressable expanse if the "cost" of creating each memory cell is similar.

Do you know how to implement a good clock? That was the biggest stumbling block I had when I tried to fiddle with anything more than basic circuitry.

Will you implement a PCR, stack machine? Will you be using micro instructions? Plenty of other questions here...

I highly recommend finding a copy of "Microcomputer Architecture and Programming", the one I have is for the 68000 family by John F. Wakerly ISBN 0-471-85319-4. the 68000 (used in the PDP-11) is a far better design to base your work on than the x86 architecture IMO. Another good reference is "The Principals of Computer Hardware" by Alan Clements ISBN 0-19-856454-6.

[ April 08, 2008: Message edited by: Nadaka ]

[Vodalian]

Here's a working computer using cellular automa:
http://www.quinapalus.com/wi-java.html

[M_Gargantua]

Well the L1 cashe was less highspeed memory and really more like ram. While the punchcards were just for storing all the information possible, I'd be pretty easy to make 1 or 2 MB of it and have it able to be read into the Ram/Cache as needed (Also one of the reasons for the 16 bit bus). I'm designing it as Register -> Cache -> memory instead of shared just for future expandability.

The clock was going to be water based, not all that hard of a part. Kind of the same concept I used for the stack machine. The clock was two of SL's repeater logic gate with the outputs hooked up to gates controling the flow of water into a vertical tube. The water would rise according to their occilations, and as the water rose it triggered plates off to the side, with the top plate causing multiple gates at all heights to open up and quickly drain it to start again. The system would have two of these so while one filled the other drained.

The stack machine was kind of like that but on its side. Two parrallel tubes on top of one another with series's of gates and plates, with hatches controlling the vertical. The top tube controlled the offset, the bottom tube the actuall slot that the water was stored in.

No Pconrol register if thats what you were refering too. And as far as micro-instruction, not really. Since the entire thing will be built on a memory -> bus -> Alu -> memory system I was just going to have one single 8bit instruction to pass the two registers (or register+value) to the proper ALU, which would then return the result to be passed back to the first register.

[Kaelem Gaen]

So, will we get to see an "In-progress" picture?

[Nadaka]

I still do not see a reason for complicating your memory system. You don't really need to separate registers, cache and ram in this system at all. if you have space to expand, all you have to do is dig out your memory units and "wire" it to your data + address bus.

[I3erent]

Remind me never to read this thread if ive been hangin out in the meadhall....goes off to lay down cuz of all the spinny words.