IN PROGRESS
The main problem holding me down before in my last iteration of computing was memory. I came up with an idea for super-dense memory where the memory itself stores 4 bits per-block. Looking around for other RAM implementations brings up quite large circuits.
Originally I used rotating memory with the ability to jump forwards. With /clone, I could handle reverse jumps. The problem was jumping to a variable offset. My current iteration uses a dense cubic volume of multi-colored wool. Each block is 4 bits, 8 blocks per strip, with multiple strips stacked vertically and horizontally. A section of redstone logic seeks along this block of memory in a read/write step by replicating itself alongside the volume. The "head" (can be read or write, changed based on state) is then placed at the correct position and performs its operation. This way, command blocks can access sections of memory from an arbitrary address.
Because a physical head is slow, I'm also planning on having the head work in block operations, allowing data to hit a cache unit. That should speed up read/write speed.
Actual core functionality will happen later. Also, a lot of the logic will shrink in physical size with 1.9 it seems.
The main problem holding me down before in my last iteration of computing was memory. I came up with an idea for super-dense memory where the memory itself stores 4 bits per-block. Looking around for other RAM implementations brings up quite large circuits.
Originally I used rotating memory with the ability to jump forwards. With /clone, I could handle reverse jumps. The problem was jumping to a variable offset. My current iteration uses a dense cubic volume of multi-colored wool. Each block is 4 bits, 8 blocks per strip, with multiple strips stacked vertically and horizontally. A section of redstone logic seeks along this block of memory in a read/write step by replicating itself alongside the volume. The "head" (can be read or write, changed based on state) is then placed at the correct position and performs its operation. This way, command blocks can access sections of memory from an arbitrary address.
Because a physical head is slow, I'm also planning on having the head work in block operations, allowing data to hit a cache unit. That should speed up read/write speed.
Actual core functionality will happen later. Also, a lot of the logic will shrink in physical size with 1.9 it seems.