In recent versions of MC, you can do a much better delay line memory with comparators. You can actually end up being able to store 2b / block (2 and not 4 because comparators have to be placed on something not a comparator.) - it would be half that but there's a trick you can play to avoid requiring redstone dust between comparators.
The delay is faster too - 1 redstone tick / 4 bits, or 40 bits/sec per line, as opposed to this implementation's 1 bit / 8 redstone ticks / line, or 1.25 bits / sec / line. (Note that this implementation of piston tape is decidedly suboptimal: the maximum is actually 3 bits / 4 redstone ticks / line = 7.5 bits/sec/line, as you can actually check for 8 different block types (glass / solid / sticky/non-sticky piston facing 3 directions) and you can make a faster-resetting piston loop.)
The biggest issue with comparator delay-line memory is that there's no way of pausing it.
There's also a way of storing arbitrary amounts of data per block, and that's to use the fact that items with NBT data will stack only when their NBT data is identical. The easiest way to see this is to try to stack renamed items, but there are others. You can make a hopper or dropper chain and encode data in which line which enchanted item is in.
I have yet to see a practical implementation of the above, though.
As parent said, items with the same name stack together, items with different names don't. There are item testers in minecraft based on whether the item will stack.
I can see several ways that you could implement storage and processing using that, thank you.
For anyone else thinking about the problem, there are two processes that could be used by item sorting to do processing:
1. You can use the stream of items through a pipeline (if deterministic enough) to encode a bit of strings. You can do this without enchanting, because you only need two item types.
2. You initialize an instruction decoder and have it sort the item based on type, which then triggers a command block to decode the instruction further.
The delay is faster too - 1 redstone tick / 4 bits, or 40 bits/sec per line, as opposed to this implementation's 1 bit / 8 redstone ticks / line, or 1.25 bits / sec / line. (Note that this implementation of piston tape is decidedly suboptimal: the maximum is actually 3 bits / 4 redstone ticks / line = 7.5 bits/sec/line, as you can actually check for 8 different block types (glass / solid / sticky/non-sticky piston facing 3 directions) and you can make a faster-resetting piston loop.)
The biggest issue with comparator delay-line memory is that there's no way of pausing it.
There's also a way of storing arbitrary amounts of data per block, and that's to use the fact that items with NBT data will stack only when their NBT data is identical. The easiest way to see this is to try to stack renamed items, but there are others. You can make a hopper or dropper chain and encode data in which line which enchanted item is in.
I have yet to see a practical implementation of the above, though.