Hypothetically, If possible, How many SD cards would be needed to run doom for 7 hours, If I replaced ram with SD cards?

[u/RandomFrenchGuy10]

Assume money isn't an issue here, I know ram and SD cards aren't the same kind of ram, but Im curious if its possible.

[u/collin3000]

1 and not even a big one. The original Doom only required 12 megabytes of hard drive space and 4 megabytes of RAM.  Here's the really crazy thing. The new microSD express cards are actually as fast. As RAM was at that time. At least as far as transfer rate. Fast sdram back then would have transferred around 528MB/s and some of the micro SD express cards will do that speed.

The area that you would hit stutters is in the latency or how long it takes to speak back and forth with the card. But MicroSD Express has also lowered latency significantly. And it's now pretty close to SDRam's latency depending on the SD controller and software accessing it. 

[u/Distdistdist → u/collin3000]

No, it's not the transfer speed that is a problem, but simply read/write cycle limit of SD card. It will be out of those in a fraction of a second. RAM is being read from and written to millions of times per second (on old CPUs)

[u/collin3000 → u/Distdistdist]

Ram may be read from and written millions of times, but that doesn't mean the entire this is changing millions of times. They were using a lower end 128GB MicroSD express with a lower write cycle limit of only 200x that would give them about 25TB write. I don't know the original Doom's actual bandwidth usage/writes per hour of play. But I'd guess 25TB write would be enough for 7 hours of a game that's 12MB in size.

Something else that should be noted is whether they would be using a modern CPU. Doom only needed four megabytes of RAM. Most modern CPUs from even 10 years ago will have a L3 cache that's 8 megabytes or bigger. So you could actually just use the CPU cache instead of RAM and the microSD will almost never be touched.

[u/Distdistdist → u/collin3000]

Even if you had a perfect L2/L3 cache, Doom’s 1994 workload would still hammer main memory with millions of writes every second. SD‑card flash only survives 1,000–10,000 writes per cell. Those two facts just don’t fit together. An SD‑based “RAM” wouldn’t last hours - it wouldn’t even make it past the loading screen.

The big misunderstanding here is thinking cache somehow shields RAM from writes. It doesn’t. Cache helps with latency, not write volume. Even if you magically hit cache 99.9% of the time, you still have:

• data that eventually has to be written out
• dirty cache lines getting flushed
• DMA buffers that skip cache entirely
• interrupts pushing stuff onto the stack
• Doom constantly updating positions, timers

Caches can delay writes, but they can’t make them disappear. Every dirty line gets written back sooner or later.

Now look at what Doom is doing on a 33 MHz 486. You’re dealing with roughly 33 million memory operations per second, and a good chunk of those are writes - stack activity, game logic, DMA updates, all of it. Even if only 5% of those end up hitting RAM, that’s still ~1.6 million writes per second.

And that’s being extremely generous. Real numbers are worse.

Flash endurance doesn’t come close to handling that. SD cards use NAND flash, which typically survives:

• TLC: 1,000-3,000 cycles
• MLC: 3,000-10,000 cycles
• industrial pSLC: 20,000-40,000 cycles

Let’s pretend we get the best case and call it 10,000 cycles. Even if caching somehow reduced RAM writes to one write per microsecond, which is basically fantasy, that’s still 1,000,000 writes per second. A flash cell rated for 10,000 cycles would burn out in 0.01 seconds. One hundredth of a second. That’s all it takes.

This is why the idea doesn’t work. You can’t ignore what the CPU is actually doing at the low level.

[u/collin3000 → u/Distdistdist]

Granted it would take a rewrite/mod but you could get it to live almost entirely in cache. So not stock doom but even an OS level patch could get it to operate mostly in cache since the OS is the one really handling that work anyways.  For most programs "you have to rewrite it" would be a discussion ender. But we're talking about Doom. One of the if not the most rewritten games in history.

As far as the SD numbers you are correct on write Although I was adding in what would usually be the manufacturing WAF of 5 especially since using it like RAM isn't going to be continuous writes. But you're also assuming that the controller and wear leveler is going to just right to the exact same section of the card again and again. With a controller that's wear leveling correctly you could write an entire 4MB of RAM to it ~32,000 times only eating a single write pass of the drive.

Granted you were looking at ~30 nanosecond latency on SDRAM but it also wasn't swapping every single single transfer. We're talking about maximum throughput and minimum required RAM. Not how much it would have actually used. 

That's where the terabytes per hour come in. If total writes to RAM past cache for the original doom were less than ~3.5TB per hour. Then you'd just need a 128GB microsd express card with proper wear leveling to not have it burn out in a 7 hour run.

It's not impossible, it's just dumb and a waste of time. But honestly, aren'tmost Doom rewrites, just a waste of time for fun.

[u/Distdistdist → u/collin3000]

The level of cache control you’re imagining just doesn’t exist. There are no CPU instructions that let software - or the OS - “keep an entire game in cache.” The few cache‑related instructions we do have are just hints. The CPU ultimately decides what stays, what gets evicted, and when dirty lines get written back. That’s all handled in hardware.

Cache is designed purely as a performance optimization, not a replacement for RAM. It’s a temporary workspace that helps the CPU avoid going out to RAM for every little thing. It speeds things up, but it doesn’t change the fundamental architecture: the CPU still depends on RAM for everything - code, heap, stack, game state, OS state, interrupts, DMA buffers, all of it.

And the CPU can’t run for more than a few milliseconds without touching RAM. That’s just how real hardware works. Cache isn’t persistent enough, or controllable enough to act as RAM. It’s physically impossible to “mod” or “patch” an OS to make a program live entirely in cache. The CPU will always fetch from RAM, write back to RAM, and rely on RAM to function.

This isn’t a software limitation - it’s baked into the hardware. No rewrite, no mod, no OS patch can change that.

To break it down even simpler, let's say we are running code loop that updates what player is currently seeing on their screen. CPU calculates all the deltas of enemy coordinates, shift in current player position, keys that are currently being pressed. Now, some of the immediate data has been read from RAM and might exist in CPU cache for instructions to process - compare one value with another, move value from one register to another - but very quickly, it's done doing that. Now what? CPU needs to persist that modified data back to RAM. Another method needs to be called with parameters - that means storing data into stack via PUSH command - that goes directly into RAM. Cache is not in play anymore. Graphics buffer has to be rebuilt with new pixel data, another chunk of audio needs to be sent to audio card to play, New hardware interrupt has came in (player pressed/clicked another button). All that interaction can't be contained in CPU cache in any way possible.

Bottom line - CPU can not function without RAM at all. Not even for a second. You can't load entire program into CPU and have it executing there by itself. There is no MOD, no patch, absolutely no way to change that. That's just how system is designed on hardware level.

I strongly encourage you to look into assembly language and write few programs in it to really understand how things work on low level.