Post by NeevorPL in please add bigger rom sizes or customizable rom sizes, like 1024x16 rom or smth

Viewing post in please add bigger rom sizes or customizable rom sizes, like 1024x16 rom or smth

Hi, To be honest, managing multiple memory components and designing proper address decoding logic is a fundamental part of building any complex digital logic circuit. If handling, placing, and wiring 16 ROM chips is considered too tedious, boring, or overwhelming, then digital logic simulation and DLS might simply not be the right hobby for you. This discipline is all about building complex systems from basic blocks.

If you want to keep your main canvas clean, the proper way to handle this is by encapsulating those 16 ROMs and your decoding logic inside a single Subcircuit. You do it once, and you get a clean, reusable custom component with the exact capacity you need. Because of this, I highly doubt customizable or massive native ROM sizes will ever be added to DLS. There is simply no need for them when you can easily build them yourself using the components already available in the tool.

421Dungeon13 days ago

i dont mind placing and wiring stuff infact i find it satisfying but having to copy and paste data to 16 individual roms is really annoying and is why i made a python script to inject rom data into the JSON chip files i do enjoy this but more as a thing to do not really as a hobby but repetitive tasks are really annoying for me

and im probably gonna just mod the source code to have a bigger rom because having an external python script for this is kinda cheating and strips away the satisfaction

NeevorPL13 days ago

Haha, okay, now we are on the same page! To be honest, I use exactly the same approach.

I wrote a microcode compiler for my CPU, and filling a matrix of 3x8 ROM chips by hand was a massive pain in the ass. So, I also ended up writing a Python script to handle it. I even named it nero_burning_rom.

However, looking at it from the developer’s perspective, keeping data formatted in a single, massive native ROM file so that DLS understands it correctly is going to be just as much of a headache to maintain.

That being said, I am actually planning to run the original Commodore PLUS/4 ROM on my processor in the future, so I will eventually need a proper 64KB ROM block anyway just to make things easier. But even when I get to that point, I will still use an external script to parse the raw binary ROMs and inject them straight into the DLS project JSON. It’s just more efficient.

If you do end up messing with the source code and come up with a clean solution for a bigger ROM component, let me know! Unless, of course, I beat you to it and implement it first—though that’s unlikely anytime soon, as I’m currently stuck deep in RST/IRQ/NMI interrupts and replicating the TED chip.

421Dungeon13 days ago

oh yeah also the reason i need 16 roms (64 now) is for colour data for a 128x128 display i made

421Dungeon13 days ago

also planning to hook this up to a graphics processor to display stuff in real time instead of using ROM data so i might mod the game to have 12 bit input and outputs because i would need an ADDR bus that goes 0-4095

NeevorPL13 days ago

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. ;)

NeevorPL13 days ago

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!

421Dungeon9 days ago

yeah too be fair that actually would be nice thanks for the suggestion!

itch.io

Viewing post in please add bigger rom sizes or customizable rom sizes, like 1024x16 rom or smth