It has a similar feel to the game of life. I haven't tried, but I'd bet you could make some pretty neat systems by using the cyclic patterns that sometimes appear. You could encode information by setting up cyles of different frequencies, and broadcast these frequency signals down 'wires' (made of ORs) to a signal reciever somewhere.

I got a two-bit adder working, in a parallelogram 60 by 20 hexes ( a four bit one would be around 60 by 40) . I haven't found a way of making nice condensed AND gates though.. mine are pretty big.

The key would be to not build an adder, but a decoder and multiplexer then you could peice those into everything else.

Very cool stuff though. Alternative forms of computation are fascinating to me. I'd read something awhile back about a research group working on computation with self organizing tiles, this might give us a glimpse into something like that.

Hum, a 4 bit adder. I thought this would be easy... <sometime later> It's coming up with a tidy way of doing the carry's that makes it hard. The logic is easy, the layout is the killer. Not sure I have enough time for this.

You can make some nice oscillators in this as well. How about a slow update option, so we can make counters?

Isn't it the opposite? If I place a + above an OR, it will stay off, but it will turn on if I place a + below it.

Yeah, it's.. wrong. I'll fix that.I'll also add some more features, like being able to save the grid as a base 64 encoded rle packed string (and load it again, of course), and an update speed control. :-)

Here's a "leaky intersection" and a NAND gate:

The intersection swaps two pipes, but it leaks three "bits" of data down the wrong pipe when it does so.The NAND is probably close to optimal in size.

I've always had a thing for hexagons. They just feel so LOGICAL.Combine that with an interest in cellular automata (not that this is proper CA) and a fascination with logic gates, and this idea was bound to happen.When I realized that the inputs and outputs would line up perfectly and still allow loops, I just had to implement it.

The carry input is at the bottom, the carry output is at the top. The two inputs are difficult to spot. They are the two '+'s on the lower part of the right hand side. The output of the one bit adder is also difficult to find. Start at the input carry and move 3 spaces up and then one diagonally up to the right. Yep that one!

I had a bit of trouble getting this out of the edit box on my mac. dragging it seemed to do the job.

/Edit: It does work after all. My first post misidentified the data output.

/Edit2: Just spotted Markus' has posted his adder. It's much tidier than mine, with all the inputs and outputs much neater. Bah Humbug

Actually, the GBA has some sections of write-only memory. Certain special memory locations are used to poke commands to the tile hardware, but attempting to read these bits of memory always returns the same value (which, oddly enough, isn't zero).

Actually, the GBA has some sections of write-only memory. Certain special memory locations are used to poke commands to the tile hardware, but attempting to read these bits of memory always returns the same value (which, oddly enough, isn't zero).

Reminds of the C64 where you would have a loop that copies memory overtop of itself essentially like for(int i = 0; i < 16384;i++) mem = mem;

but what you were doing was copying the image of the BASIC ROM from ROM to the RAM that lived at the same address, then you would flip a bit somewhere so reads would also come from the RAM and at that point you had a copy of the BASIC interpreter that you could tweak to add more commands, patch things, etc.The cool thing was that the processor would by default read from teh ROM at that address, but the graphics chip (VIC II rulez!) would read from the underly RAM. So you would store bitmaps and sprites "under" the image of the BASIC interpreter so it took no memory away from what was available to your BASIC program.

That would be inefficient. You see, it's possible to store many more 1's in the same space because they stack more closely, while lots of space between the 0's goes to waste. So the way to go would be to use a harddrive that can only store 1's, then convert them to 0's when read.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org