5 ms·

Doom 1 itself has 4MB of RAM as a minimum requirement: https://www.computerhope.com/games/games/doomx.htm#doom https://www.computerhope.com/games/games/doomx.h

Doom 1 itself has 4MB of RAM as a minimum requirement: https://www.computerhope.com/games/games/doomx.htm#doom https://www.computerhope.com/games/games/doomx.htm#doom

billyhoffman 5y ago
The article talks about this and allows you access Flash as if it was very slow RAM (fronted with a 16K cache of actual RAM). This allows the author to do many things like directly access the levels and textures without loading them into RAM, And in fact storing them compressed and using the second core to uncompress them on the fly
- numpad0 5y ago
  In layman’s approximation, could this be exactly how modern x86 CPU with multi-level caches work, or is it completely different from such things?
  - erosenbe0 5y ago
    Not the same but not totally different. MCU abstraction is simple and more like vintage stuff. So it would closer to an 80s system that executed many routines from memory mapped ROMs -- in addition to system RAM -- with an instruction cache on CPU. MCUs can have on chip RAM/ROM and off chip [quad] serial RAM/ROM, and even parallel access RAM/ROM like FRAM. Several ways to skin the cat. Or cut the pie, as it were.
vikingerik 5y ago
Much of that is for art assets. Do it with fewer or lower-resolution textures and sprites, and you could get away with quite a bit less. The executable code can fit in well under one megabyte. You could even procedurally-generate the art, if you've got way more CPU core available than storage. The SNES ran Doom with two 64k RAM banks (albeit with textures and data such as level geometry running directly from ROM.)
- WithinReason 5y ago
  The SNES used a dumbed-down version of Doom: https://doom.fandom.com/wiki/Super_NES https://doom.fandom.com/wiki/Super_NES While this port makes it a point to port everything accurately, including multiplayer.

5 ms·

Doom 1 itself has 4MB of RAM as a minimum requirement: https://www.computerhope.com/games/games/doomx.htm#doom https://www.computerhope.com/games/games/doomx.h

by WithinReason 5y ago

Doom 1 itself has 4MB of RAM as a minimum requirement: https://www.computerhope.com/games/games/doomx.htm#doom https://www.computerhope.com/games/games/doomx.htm#doom

billyhoffman 5y ago
The article talks about this and allows you access Flash as if it was very slow RAM (fronted with a 16K cache of actual RAM). This allows the author to do many things like directly access the levels and textures without loading them into RAM, And in fact storing them compressed and using the second core to uncompress them on the fly
- numpad0 5y ago
  In layman’s approximation, could this be exactly how modern x86 CPU with multi-level caches work, or is it completely different from such things?
  - erosenbe0 5y ago
    Not the same but not totally different. MCU abstraction is simple and more like vintage stuff. So it would closer to an 80s system that executed many routines from memory mapped ROMs -- in addition to system RAM -- with an instruction cache on CPU. MCUs can have on chip RAM/ROM and off chip [quad] serial RAM/ROM, and even parallel access RAM/ROM like FRAM. Several ways to skin the cat. Or cut the pie, as it were.
vikingerik 5y ago
Much of that is for art assets. Do it with fewer or lower-resolution textures and sprites, and you could get away with quite a bit less. The executable code can fit in well under one megabyte. You could even procedurally-generate the art, if you've got way more CPU core available than storage. The SNES ran Doom with two 64k RAM banks (albeit with textures and data such as level geometry running directly from ROM.)
- WithinReason 5y ago
  The SNES used a dumbed-down version of Doom: https://doom.fandom.com/wiki/Super_NES https://doom.fandom.com/wiki/Super_NES While this port makes it a point to port everything accurately, including multiplayer.