Right now, I'm using the port closest to the original Doom as my base. There are ports for retro computers and even one for the Raspberry Pi Pico, but while those ports are very functional, they're heavily modified and adapted to those architectures. My intention is to see if I can make it work well without touching the original code as much as possible (except basically for the video and sound drivers; that is, modifying what the hardware and operating system would handle).
Currently, PSRAM is already being used as a framebuffer, which is why you see the curtain during rendering. Doom uses a triple framebuffer: one renders, another holds the finished frame while preparing the next, and then the one that's actually rendered (currently, this last one is the PSRAM of your system). This is great because it's helping us see that the more or less optimal PSRAM module is working perfectly :). One of the problems is that Doom works in 32-bit color, and all the operations for calculating lighting, rendering, BSP trees, etc., are being done in full color. Then, the video driver applies dithering, which is no small feat. I've implemented 5 dithering algorithms, from the most faithful to the one that is basically black or white.
Lighter, but not very functional. In the demo, you'll see an intermediate level that balances the image recognition with resource consumption, making the demo more or less visible.
On the other hand, we have the game's bottleneck: it's 5MB packaged in Doom's own WAD format. The textures are 320x200. Many ports for smaller machines use modified WADs with reduced texture resolution. For now, I want to stick with the original WAD; in fact, I'll share it separately. But a software module has been released that, combined with Flashcache, is very interesting for real-time, on-demand decompression.
The issue is that between framebuffers and other variables, Doom needs almost 7MB of memory, leaving only 1MB of free PSRAM, and even less once the music is improved.
The initial plan was to load the WAD into PSRAM and run from there.
But right from the start, the WAD file doesn't even fit in the Alhambra's flash memory (4MB).
The magic has been developing an LZW4 software module which, along with your flashcache, allows me to map the WAD file to PSRAM, decompressing it in chunks on demand, and it's working surprisingly well. In fact, in the demo you see, the problem isn't the PSRAM or the real-time decompression; it's the rendering itself.
In principle, Doom requires a 486 with 66MHz, assuming the RAM is also faster... but anyway, I have ideas, and we'll see how far we get until we've pushed them to their limits. One idea I'll try soon is to work at a lower overall rendering resolution and then increase it, even if it pixelates, and then convert it to color to avoid the dithering conversion.
I also want to try making a kind of "GPU," let's call it that, to do hardware dithering and see what happens.
I don't know, it's been a fun trip, let's see if I can organize the code a bit and send it to you.