oh yeah also the reason i need 16 roms (64 now) is for colour data for a 128x128 display i made
The inputs and outputs for components are actually implemented quite nicely in DLS. I haven’t tried modifying them myself, but from a static code analysis, it looks like just adding the appropriate new ChipType to the ChipDescription method should do the trick. Most of the magic happens right at the beginning of the SimChip method in Assets/Scripts/Simulation/SimChip.cs.
Adding a larger ROM size shouldn’t be too painful either. The UI editor for it is written in a very elegant, clean way, so it should theoretically accept data arrays of any arbitrary size without breaking the layout.
The real question is how the simulation engine itself will handle the performance overhead once you start cycling through that much data in real time. ;)
Actually, now that I think about it… since you are already prepared to break open the source code and add custom components, why settle for just a bigger generic ROM?
There is a much better, high-performance architectural solution for your 128x128 setup: write a custom ColorROM component directly in C#.
Instead of forcing DLS to simulate a massive grid of thousands of virtual gates and memory cells (which will inevitably tank your simulation frame rate), you can implement the entire memory array as a native C# multi-dimensional array or dictionary inside your custom chip class.
This approach gives you two massive advantages:
A native C# memory lookup is orders of magnitude faster than a gate-level ROM matrix simulation. Your 128x128 display will actually run smoothly in real time.
Since it’s pure C#, you aren't limited to just spitting out raw static data. You could easily implement real-time color space conversions (like HSV to RGB), masking, or mathematical transformations directly inside the chip's logic before outputting the signals to your display.
If you are going to mod the codebase anyway, writing a dedicated, optimized graphics helper chip is definitely the most elegant and “engineer-approved” way to solve the VRAM bottleneck!