HIBADIG: Memory-Registers

[ginkgo]

This is a 16-Position Read-only memory-bank:

hibadig

You input lookup-adresses and get a copy of the block in the corresponding position.

The machine is quite large. Maybe there are still ways to get it smaller.

I'm curious, if it's possible to make rewriteable Memory in Rubicon. At least a few memory-cells. Anyone in for a challenge? 

[Otto]

gocypyg

This is my first attempt at read/write memory. However, it has a bug which I can't figure out without more sleep.

Anything dropped into the space below the yellow striped column causes a read. It'll spit out a copy of the existing value.

Anything dropped into the space below the gray checkered column will cause a write. Unfortunately, causing a write also causes a read as well.

I have another idea that may work... but.. later.

[ginkgo]

This is my design for a single RAM-Cell:

nudebok

It is slower than ROM(not a big surprise to me) , and you have to remember, that all read-operations have to be finished, before you can change the content in the cell.

Now, I only have to find a way, to stack several copies of these and feed them the correct operations.. 

[Djonn]

This is my attempt at a RAM cell cinazyg (in crosses). Anything on the left triggers a read, anything on the right overwrites the cell value. max speed for read/write is one every other cycle. If a read and a write are executed in the same cycle, the new value is read. These cells should be easy enough to stack, but I don't know how to feed them the correct operations either.
note: for the demonstration one read is triggered every other cycle (stripped), and one write every four cycles (checkered).

Update: if you use the new physics model (type 'P' after loading an old level, see should packers be slowed down), when you read and write at the same cycle, you get the old value. This is however very easy to tweak by removing one pipe from the "read" entry if you prefer the other behaviour.

[Otto]

This is my attempt at a RAM cell cinazyg (in crosses). Anything on the left triggers a read, anything on the right overwrites the cell value. max speed for read/write is one every other cycle. If a read and a write are executed in the same cycle, the new value is read. These cells should be easy enough to stack, but I don't know how to feed them the correct operations either.
note: for the demonstration one read is triggered every other cycle (stripped), and one write every four cycles (checkered).

Update: if you use the new physics model (type 'P' after loading an old level, see should packers be slowed down), when you read and write at the same cycle, you get the old value. This is however very easy to tweak by removing one pipe from the "read" entry if you prefer the other behaviour.

Wow. I really like that design. I never considered copying into a furnace before. Good job!

[ginkgo]

Yes, your version is awesome, Djonn.

I guess I tried to hard, to modify my existing ROM cells.

[Djonn]

OK, here is my attempt at stacked RAM registers: caranym, unfortunately, I didn't find a way to have a two crates code, so everything is muxed in 1 crate, which means 4 binary registers (could do ternary, kinda easier actually but, this is neater). The two msb code the register index, the 3rd bit is 0 for read and 1 for write, and the lsb is the value for the write.

The input is on the left (from top to bottom: value, read/write, index), in the middle is the muxer, top right is demuxer, bottom right are the actual registers (the soon-to-be-burned crates give their index), and the output.

If anybody finds a way to use a two-crates code, that would be much much nicer (e.g. up to 8 16-valued registers with 1 crate for register index and read/write, and 1 for the value).

Note: the new version: caranym has a neater (and more compact) demuxer than the previous one (pysizeb).

[Gameman]

Here's mine:nedukix[move][/move[] [u][/u]And then there was one...