Very dense memory (6 blocks/bit)

Very dense memory (6 blocks/bit) - Printable Version

+- Forums - Open Redstone Engineers (https://forum.openredstone.org)
+-- Forum: ORE General (https://forum.openredstone.org/forum-39.html)
+--- Forum: Projects & Inventions (https://forum.openredstone.org/forum-19.html)
+---- Forum: Completed Projects (https://forum.openredstone.org/forum-21.html)
+---- Thread: Very dense memory (6 blocks/bit) (/thread-13098.html)

Very dense memory (6 blocks/bit) - minestyler007 - 09-10-2017

Hey guys,

I just finished a project I was working onfor quite some time now and it may be a possible way to do mass storage (even 16kB if I'm guessing correctly here).

first of all here are some pictures with 64 bytes of storage and decoders already attached.

[Image: nidr7Z3.png]

The stairlike things are the memory cells and everything to the side of it are decoders. It consists of memory cells and cell stacks. Each cell stack is made up of memory cells and can be expanded indefinitely. These cell stacks can be stacked next to each other every 6 blocks. You could also make more than one layer of this.

Now there are a few different ways to set this up but they do change how much storage you can have.

-The easiest setup is just like ram (but really slow ram) where you just enter your data and the place you want to store it. That would half the number of bytes that are bossible to store but you don't have to worry about timing as much and it probably lags less.

-But you can also store 2 hex values in one cell which would allow for the 64 I mentioned. You need to worry more about timing and maybe there will be more lag because the signal is constantly sent in a circle. I tried very long to store 4 hex values in one cell but it didn't work out yet - theoretically you could do it which would make the memory in the pictures be able to store 128 bytes.

-if you take binary as inputs you can even speed up the access time for large numbers but you would further increase the lag because you need many bin2hex decoders.

If we ignore lag we can achieve reasonable access times with very high storage capacity.
Access times and storage of this relation can be achieved: accesstime = sqrt(bytes*2) + constant (max 30 ticks) so for 2^13 bytes we would have an access time of sqrt((2^13)*2)+constant = 128 + constant

one cell is 6*8*1 = 48 blocks per byte or 24 blocks per hex value. Which also makes it one of the smallest memories ever.

I think this might be a possible setup for the MMM Smile

RE: Very dense memory (6 blocks/bit) - Matthew - 09-15-2017

Quote:If we ignore lag we can achieve reasonable access times with very high storage capacity.

well we can't... this will never be usable because of that Sad

it's really neat just way to laggy. That's why capo banned this. It can't sit around, it can only be pasted in game for short amount of times, and that's for only small amounts as well.

Quote:one cell is 6*8*1 = 48 blocks per byte or 24 blocks per hex value. Which also makes it one of the smallest memories ever.

"one of the smallest", kind of odd to use a superlative adjective that way but whatever. The actual smallest memory would be just any hex tape. (medium - large hex tapes are also banned due to lag)

Its really cool memory, i'm surprised you got 1x1 hex to work ;p if you made some 1x1 that didn't store multiple hex values in a single loops that would be awesome and usable ;p

RE: Very dense memory (6 blocks/bit) - minestyler007 - 09-15-2017

you can also just store one value per loop which would half the number of bits that can be stored... that would also be way easier to use Smile

and I'm not a native speaker in german you can say ot like that Big Grin

RE: Very dense memory (6 blocks/bit) - QSmally - 11-29-2018

I’m getting sick of your FOV.

RE: Very dense memory (6 blocks/bit) - konsumlamm - 11-29-2018

(11-29-2018, 10:33 AM)QSmally Wrote: I’m getting sick of your FOV.

dat bump