I've been thinking about memory storage in Minecraft and how our ability to tell items apart using hoppers could lead to much better memory storage. Has anyone built a system for storing memory in chests or minecarts with chests yet, and reading it with hopper sorters? Sorters send out a pulse of redstone as they consume their item, which we can hold for a while.
To implement the simplest mechanism I can think of, we'd need a set of N (<= 27) unique stackable items. The presence or absence of each item would carry a bit of information content. These could be normal game items, or customised (anvil or otherwise named) items, which will only stack with items of the same name.
A cart with chest would run on tracks over N hoppers rigged to only take a single item type and feed a pulse in to an R/S latch if it picks up its target item. A detector rail at the start would reset all the R/S latches, and another detector rail at the end would send an "enter" pulse to whatever is consuming the data. If the cart contains the sorter's item, its line will be high when the enter line is pulsed, otherwise low.
The rail could then loop back down a rewrite track. The pulse out of each sorter would also feed a single item from a dropper in to a hopper above the rewrite track. The cart passes under those hoppers, getting back the same items it had as it came in.
More complicated mechanisms to boost storage beyond that could have more than 27 items, but have an encode/decode stage which ensures we only ever store 27 items in any given chest. An example would be that by storing an "invert" bit which inverts all the others, we could safely store up to 52 bits (26 * 2; 1 item reserved for the invert). If more than 26 bits were set, we would invert the bits so that fewer than 26 were set. For 32 bits we would invert if all of the top 6 bits were set.
Mechanisms exploiting the order of items could store 94 or more bits in a single cart, but needing to scan each item individually would make it very slow.
The carts themselves could be arranged in a stack (sure I've seen pre-hopper cart deployers that do this) or even via addressable memory. I've built a mechanism at http://imgur.com/a/3YZpn which uses items in a cart to route it through a junction. Something similar could make such memory addressable (albeit expensively).
interesting topic. if you do not get a lot of supporters besides me, i have a team of pro modmakers that could develop this for you. i like it and support!
I think you git the numbers wrong. With each wool block reperesenting a different bit you get 2^16 = 65536
different possible combinations aka you can store numbers ranging from 0 - 65536. But with the more complicated mechanism we vould have 16^27 combinations if we just used wool blocks but up to like 100^27 if we use 100 different stackable items, although using sequenses of bottles and showels (reprecenting 1s and 0s) and decoding that to redstone signals using n00b_asaurus design is much more compact than 16 item sorters and can hold as much data as the first simple method you suggested. I will use this in a redstone computer and can link it when i get done, if ypu request it :).
Although the more complicated method could, if we used 100 different items amd 100 differents item sorters to decode, give us 100^^27 = 1000000000000000000000000000000000000000000000000000000 different combinations in a single chest, witch is incredible compared to 65536
To implement the simplest mechanism I can think of, we'd need a set of N (<= 27) unique stackable items. The presence or absence of each item would carry a bit of information content. These could be normal game items, or customised (anvil or otherwise named) items, which will only stack with items of the same name.
A cart with chest would run on tracks over N hoppers rigged to only take a single item type and feed a pulse in to an R/S latch if it picks up its target item. A detector rail at the start would reset all the R/S latches, and another detector rail at the end would send an "enter" pulse to whatever is consuming the data. If the cart contains the sorter's item, its line will be high when the enter line is pulsed, otherwise low.
The rail could then loop back down a rewrite track. The pulse out of each sorter would also feed a single item from a dropper in to a hopper above the rewrite track. The cart passes under those hoppers, getting back the same items it had as it came in.
More complicated mechanisms to boost storage beyond that could have more than 27 items, but have an encode/decode stage which ensures we only ever store 27 items in any given chest. An example would be that by storing an "invert" bit which inverts all the others, we could safely store up to 52 bits (26 * 2; 1 item reserved for the invert). If more than 26 bits were set, we would invert the bits so that fewer than 26 were set.
For 32 bits we would invert if all of the top 6 bits were set.Mechanisms exploiting the order of items could store 94 or more bits in a single cart, but needing to scan each item individually would make it very slow.
The carts themselves could be arranged in a stack (sure I've seen pre-hopper cart deployers that do this) or even via addressable memory. I've built a mechanism at http://imgur.com/a/3YZpn which uses items in a cart to route it through a junction. Something similar could make such memory addressable (albeit expensively).
Anyone done anything like this? Thoughts?
I have been working on a design. You can see part of it on the Video on OREs homepage.
Slabs- Bring easily place able upside down slabs back to minecraft!
I think you git the numbers wrong. With each wool block reperesenting a different bit you get 2^16 = 65536
different possible combinations aka you can store numbers ranging from 0 - 65536. But with the more complicated mechanism we vould have 16^27 combinations if we just used wool blocks but up to like 100^27 if we use 100 different stackable items, although using sequenses of bottles and showels (reprecenting 1s and 0s) and decoding that to redstone signals using n00b_asaurus design is much more compact than 16 item sorters and can hold as much data as the first simple method you suggested. I will use this in a redstone computer and can link it when i get done, if ypu request it :).
Although the more complicated method could, if we used 100 different items amd 100 differents item sorters to decode, give us 100^^27 = 1000000000000000000000000000000000000000000000000000000 different combinations in a single chest, witch is incredible compared to 65536