To get a working RAM-module or Hard-Drive for your computer, you need 2 blocks per bit + some control logic.
Flip-Flop : Stores the information
AND : required to toggle accessibility
First, make 4,8 or 16 bit storage-rows. I recommend 8 bit per cell because then you can still copy+paste an 8x8 bit + control-logic chunk.
Then connect all storage-row outputs to an Activation-Block-row, which will relay the last input they received.
Connect the row, bit and module controls to the AND of each cell.
8*1 row/address-control for each byte storage.
8*1 column/bitCell-control for each bit in a byte.
1 module-control total.
Note: Even if memory is 8bit, you can get 16 bit by accessing 2 modules in the same way.
Now you can choose which bits to toggle, which address/byte to access and which copy+paste-able module to access.
You write by defining which bits to toggle (needs a read first).
You read by toggling all bits twice, which causes the flip-flops to relay their output over the activation module row.
BTW: A 9th bit which tells wether a storage row is inverted can cut read time into 1/2, but the control logic must account for it.
Note: Reads and writes can alternate between modules to get more bandwidth.
Note:
A great way to reduce lag is to output the module-active control into the row-active and column-active ANDs.
This alone is a good reason to use modules.
Copy+paste-ability is the other reason for modules, reducing number of manual connections by a factor of 3.7.
You could also use 16x16 cells or 8x8x8 cells with 16-bit per row controller and 16 column-controllers, but then you have to do 4x as much work - and in case of 8x8x8, it is difficult to fix errors after testing the function.
The control-logic per module is:
A row of Activation-Button relays (1 per column).
A row of Column-Access ANDs (1 per column).
A column of Row-Access ANDs (1 per row).
A single Module-Access AND.
The Chip-Controller controls the modules which controls the rows and columns which control the cells.
The Chip-Controller is an interface + control logic.
Interface:
Activation modules to relay output/input.
Activation modules to control address (row+module).
Read/Write switch.
Confirm-relay. Turn on to confirm/listen, it turns off when the task is finished.
Control Logic:
Read requires 2 toggles of a row.
Deactivate a module before switching address, else you may reset random stuff,
depending on server-LAG.
An exception is bulk-read inside a single module (faster, because it doesn't require 0.5s to deactivate a module explicit).
Important note: the lower significant addresses activate a row, the more significant ones the module - it is split!
Memory-Controller.
Another controller? Row, Column, Module, Chip, Memory??? YES: Every controller hierarchy
- divides your effort by 4,
- reduces lag,
- and can introduce higher-level logic without increasing block-count per bit too much (above +30%)
Memory-Controllers handle parallel reading/writing.
* It can accept a 16-bit mask which defines which cells to read in order, subtracting work done by the CPU for calculating addresses. (every 4th address, 4 times OR every second address, 8 times, ETC)
* It could take a memory-value as reference to another memory cell if told or check in 0.5 seconds if this speculative execution was a good one.
* It can also have a cache for frequently accessed information (SM-Caches require 8 blocks per bit but are 2x as fast with reading/writing)
* It can provide a RAM-server interface for wireless logic or logic via rails (exchange ship data?).
But no matter how much effort you put into it, you still need 2.3 blocks per bit with control logic and bit-storage.
Which is very inefficient given that full blocks take 24 or soon maybe 32 bit RAM - meta-data not included.
That is a factor of about 1:60, not to mention time spent on processing logic via the CPU.