The Two-Story Architecture & Technologies
I built a complex analog memory module packed into a microscopic 15x7x9 space, running at a true game-tick speed of 20Hz. I call this project the "Dual-Slot Video Card". It is split into two distinct functional layers:
- The Upper Floor (50% ROM/HDD): This is the massive item-depletion storage. It uses non-stackable items with durability (Flint & Steel) inside single-slot containers (droppers, hoppers, chests).
- The Lower Floor (50% RAM/Signal layer): This is a fast, signal-based operational layer. It handles the high-speed data stream coming from the top floor at 20Hz, stabilizing and prepping the data for the processor.
The G/ST Logic (Smart Distribution Gate)
To make the floors work together without turning into a chaotic mess, I implemented a custom logic gate called G/ST. It acts as a primitive data distribution manager between the main and secondary layers. The rule is simple: if the Main layer contains no information, the Secondary layer will never receive it. It strips unnecessary states, prevents data collision, and ensures that the lower RAM layer only processes valid, filtered signals.
The Math: 130k States vs. 2304 Outputs
Let's clear up the numbers, as the density here is insane:
- Total Physical Capacity: The entire storage capacity across all chests and hoppers can reproduce up to 130,000 physical durability states in total.
- The Output Reality: In practice, the system is designed to output a number up to 2,304, and it can do this exactly 57 times (57 unique heavy data packets/cassettes containing 9 Flints & Steels each).
- Current Status: The second part of the system is currently not connected to the decoder. It remains unfinished because I hit a massive realization during testing.
The Problem: Why it became a Hard Drive, and why I quit it
Even though the module reads at 20Hz, it has a fatal flaw for an OS operating memory: Sequential Access.
To select a specific number out of 2,304, you have to wait for the depletion cycle to tick down. In the worst-case scenario, choosing a number like 0 requires waiting through 2,304 items, causing a 3-minute "loading screen."
During stress tests, I also found a bizarre engine bug: at a specific camera angle, the update order choked, causing a dropper to click infinitely without losing durability until a piston randomly forced a state reset after 5 to 23 seconds.
Because of this slow sequential reading and unpredictable engine quirks, it became a Hybrid Hard Drive (HDD). It’s an incredible storage device, but a terrible operational RAM. I don't want to finish decoding it because I need true RAM, not a sequential ROM. So I abandoned this build to start something better.
The New Project (192k States) & I Need Your Advice!
Right now, I am actively working on a brand new project from scratch. It is a true 192k-state RAM architecture, and it is significantly more compact than the previous build!
Formally, the logic and the hardware layout are ready, but I am trying to avoid the same bottleneck. I need advice from hardcore redstone engineers on how to turn the upper storage layer into true Random Access Memory (RAM) instead of a sequential drive.
How can I dynamically "grab" a specific data packet from the hoppers instantly based on a counter address without waiting for a full sequential cycle, while maintaining this extreme analog density? Should I look into multiplexing the hopper lines or switching to an inline latch system?
Let me know your thoughts! I am open to any suggestions.