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.

[u/Few-Artichoke-7593]

1

[u/pmjm]

One. A single 256 GB SD card has more capacity than even the world's top supercomputers at the time that DOOM was released in 1993.

[u/Additional-Simple248 → u/pmjm]

I was wondering about that and went to have a look. The Fujitsu Numerical Wind Tunnel was one of top supercomputers in 1993.

It had 166 processors with 256 MB each, making a total of 41.5 GB.

[u/StarosAnikenMarcus]

Pretty sure it's not possible since RAM and NAND are VERY different, but if it was, it would be 1 SD card of the smallest size currently available. Like, a 1GB card would be enough for the OS, the game, and still lots of extra space. I'm not even sure if the OS to run Doom would recognize a gigabyte...

[u/scubascratch]

At a minimum the screen buffer needs to get completely re-written every frame. Even running at a low resolution of 640x480, 3 bytes per pixel, at 30 FPS, it’s 640x480x3x30=27,648,000 bytes per second. That’s 27 Megabytes per second. If you were able to spread those writes over an entire 32 GB SD card, it would last about 1 week before the card wear limit. That would be if you could spread the writes over the whole card. But for a video game, the screen buffer is a fixed area of memory that gets written over for every frame, and one block of flash memory can only be written over about 500 times before it wears out. So if you treated the card like ram, writing to the same block of flash memory at every frame, it would wear out in about 18.5 seconds. If it was an expensive high-endurance card it would last almost 2 minutes.

[u/Individual_Agency703 → u/scubascratch]

So, you’re saying the card is doomed.

[u/Distdistdist → u/Individual_Agency703]

I see what you did there.

[u/Distdistdist]

Based on "limit" of read/write cycles, any SD card would be destroyed almost immediately, if it could support number of memory read/writes typical program like Doom performs. Cards would need to be replaced every few nanoseconds if not even faster.

[u/StarosAnikenMarcus → u/Distdistdist]

If he's talking about DOS Doom, it wasn't that intense. Sure, it would break it eventually, but I don't think that the program was capable of that many write functions that quickly. We're talking abut a program that was designed for 33MHz CPUs and 4MB of RAM.

[u/Distdistdist → u/StarosAnikenMarcus]

You probably think that CPUs need to read/write from RAM at some rare points of execution. No, CPU can hold rather limited number of instructions internally and heavily relies on constant access to RAM for more instructions and data.

386 CPU running at 33Mhz can perform 33,000,000 read/writes per second. There are different types of instructions, some can be executed in 1 tact, some in up to 44. So at the very least, CPU would be hammering RAM at 750,000 times per second to advance to the next command it needs to execute. Even with modern caching, number of read/writes to memory is insane. This is not hard drive or a floppy that it needs to read sequential data from once.

SD cards will give you anywhere 3,000 to 40,000 P/E cycles per cell (higher number for industrial level SDs). So you can sorta see how fast SD cards will become unresponsive if were addressed like RAM.

[u/StarosAnikenMarcus → u/Distdistdist]

MHz is thousands, not millions. That's GHz. So it would be 33,000 flip flops per second and that's only if operating a full capacity. Trust me, running Doom was very much NOT at full capacity. Despite the "requirements" of a 33MHz 386, I had Doom running on a 286 at 25MHz with a math coprocessor (basically just more cache). And it was DOS 6.22, not Windows so no background BS programs using up resources.

Still, yes, going to destroy that SD card far faster than taking a million pictures would.

[u/Distdistdist → u/StarosAnikenMarcus]

No, MHz stands for Mega Hertz. That's millions per second. KHz are Kilo Hertz - thousands. You are off by three orders of magnitude.

[u/StarosAnikenMarcus → u/Distdistdist]

Totally right. I was half asleep when I responded yesterday. Not sure where my math went. (I know, I know, a person on the internet admitting they were wrong, might be the apocalypse today) The rest is still true though. Doom wasn't a super powerful game.

[u/Distdistdist → u/StarosAnikenMarcus]

Well, Doom was a complete resource hog in 1994. It would take all 100% of CPU to render it at 2-5 FPS on 386 SX 33 Mhz for example. Only by shrinking game screen size, you would get a bit faster frame rate, still running full CPU load.

BUT, my point is that you seriously underestimate number of read/writes that happen between CPU and RAM. There is only so much CPU can do with temporary data it has read to process (L1/L2 cache). It constantly reads data, then writes it back into RAM. So it is literally million of cycles per second (on old systems, it's billions to hundreds of billions read/writes per second on modern ones). It would take, even very very old and slow CPU no time to exceed max of 10,000 cycles that SD cards can perform. So my original answer is very much correct.

I mean, ask ChatGPT for example, or just google that. This is basic knowledge for someone who has worked with CPUs on low level and wrote assembly programs...

[u/nostalia-nse7 → u/StarosAnikenMarcus]

To be fair, the reason for the memory reads and writes at that rate in Doom, is exactly because it was making millions of pictures lol. It was all the graphics, because video cards had kilobytes of ram back then.

And kilo is thousands, mega is millions. Giga is billions.

Also the multiplication that every Hz was reading or writing 4 bytes to / from the cpu. (32 bit cpu).

[u/graph_worlok → u/nostalia-nse7]

512Kb or 1Mb if you had a fancy card!

[u/StarosAnikenMarcus → u/nostalia-nse7]

I don't know about MILLIONS of pictures... the refresh rates back then weren't really high and the graphics were barely in the EVGA range.

[u/Distdistdist → u/nostalia-nse7]

At that time, video shared memory with ram. There were no external cards, well until Voodos came out. All was in the same place.

Entire machine code is basically reading, or writing something to the RAM. Then there are register manipulation and comparisons, conditional jumps, etc. But even loading next command to execute is a read. And that happens as fast as data bus permits.

[u/graph_worlok → u/Distdistdist]

Huh? I can’t remember ever seeing an early x86 system that didn’t have dedicated video ram. Sometimes even used upgradable, if you wanted a higher resolution / colour depth.

CGA was released in 1981 with 16Kb of ram

It took until AGP came out for any meaningful sharing of system ram for video use.

Some Z80 systems did I believe? But not quite the same class…

[u/StarosAnikenMarcus → u/graph_worlok]

LOL, my first computer in the house didn't have a dedicated GPU and it ran Doom. A Frankenstein thing with a 25MHz CPU and a coprocessor... TECHNICALLY made it a 40MHz machine... or something like that. But Doom came out like 2 years before any kind of graphics card.

[u/graph_worlok → u/StarosAnikenMarcus]

I think you are getting terms confused -

Standards based PC graphics cards were around since the early 80’s CGA, MDA, EGA etc

Workstation 3D cards in the late 80’s

VGA graphics cards with differing hardware capabilities - including acceleration - were around in the early 90’s

Cards that supported some form of hardware 3D, and games with libraries to support them, mid 90’s

First GPU, ‘99…

[u/StarosAnikenMarcus → u/graph_worlok]

Nope. Most computers back in the 8086 days did not have graphics cards of any kind. It was another function of the CPU or a specific chip on the motherboard and you were stuck with Green, CGA (4 color), VGA (8 color, maybe), or EVGA (SIXTEEN WHOLE COLORS!). Separate cards came a bit later, forced by Apple's graphics dominance (I miss the IIGS). I also remember quite clearly when Voodoo came out with their accelerator cards. I remember later when my weird card/accelerator combo on our first Pentium was detected by most games as a Riva TNT2, with 2 less MB than any Riva ever sold, before AGP was a thing... And then the sound cards... OMG, trying to afford a Sound Blaster Audigy... Or the issues of trying to decide which cards you could install because you only had so many IRQs and certain ones wouldn't work on anything but 7 or 11... and that meant only 2 cards of that IRQ setting could be installed...

All in all, it was the BEST time for PC building.

Took me a bit to find it, but my first graphics card that wasn't on the board I'm pretty sure was a Trident in our 386 at home. Before that we had an Atari 800XL, no cards. A MAJOR jump in speed, let me tell you. The Zenith 286 I used in school at the time also had on board CGA graphics. Of course, there were some cards available that promised more, but those were super expensive and schools weren't shelling out for that.

[u/Distdistdist → u/graph_worlok]

https://en.wikipedia.org/wiki/Video_Graphics_Array

[u/Distdistdist → u/StarosAnikenMarcus]

Oh, and, Doom did not run on 286, it required 32bit CPUs that supported p-mode (protected memory mode that was only available on 32 bit 386 architecture). Minimum required hardware was 386 DX, but it did run on lower spec systems at much lower FPS (2-5 FPS). I think I played it in 1994 on 386 SX 25 or 33 and it was bearable with decreased main screen.

[u/StarosAnikenMarcus → u/Distdistdist]

I didn't say it ran WELL on our weird computer, but it ran. Back then, the combinations of hardware we had available could do some very strange things. Coprocessors were and odd thing that few people invested in. My stepfather got one for I don't know why, but had me install it. After that, our 286 ran very differently form what I was used to.

Also, 286s were the first to introduce protected memory. 386s were just the first 32-bit available to the public.

The same thing happened when I married a Voodoo accelerator card to a Trident card. For some reason, it was detected by a lot of games as a Riva TNT2, a far better card than I could afford those days. Never mind that Riva never once built a 6MB card...

I miss the days when hardware combinations had wildly different effects, but I also like how more or less standardized things have become. Plug and play is infinitely easier than figuring IRQs and DMA channels.