DOOM + Alhambra-II + Multimedia Shield
59 views
Skip to first unread message
charli va
Dec 30, 2025, 9:51:41 AM (12 days ago) 12/30/25
to fpga-wars-explora...@googlegroups.com
EN ESPAÑOL DEBAJO
It's too early to have anything playable, but... I couldn't contain my excitement to send you this with the first visible screenshot... A picture is worth a thousand words.
There's still work to be done to make it playable (the framerate is currently 1 fps) because, since we can't use the SD card and the PSRAM simultaneously, and the WAD file containing the game, music, textures, etc., takes up almost 5MB, and we only have 4MB of flash memory for the firmware and bitstream (effectively just over 3MB), I've set up a real-time LZ4W chunk decompression system (the WAD file is converted to 2MB and decompressed on demand).
And while I finish a full-color graphical mode for Jesús's system, I've decided to use the current 1bpp mode with real-time dithering.
It's a lot of work for Larva at 25MHz with relatively slow memory (PSRAM).
But I have ideas for getting a working version so I can say, "Doom also runs on the Alhambra...but with super mega shield powers XD"
I'll keep you updated on my progress because this will help improve the PSRAM interface, which currently has some significant shortcomings. I'm working on this to then move to a double-buffered graphical mode, similar to what Jesús implemented in Defender (amazing mental synchronization), which is revealing problems in the current PSRAM modules. So, it's a fun way to advance in blocks that will give us superpowers.
Thank you so much, Jesús, for starting the shield project, and to everyone who's contributing ideas, comments, and testing things out...
I'll soon be posting a form for those who want one and play in this "party" , to sign up for a bundle we're organizing shortly.
Big hugs to everyone!
It's a lot of work for Larva at 25MHz with relatively slow memory (PSRAM).
But I have ideas for getting a working version so I can say, "Doom also runs on the Alhambra...but with super mega shield powers XD"
I'll keep you updated on my progress because this will help improve the PSRAM interface, which currently has some significant shortcomings. I'm working on this to then move to a double-buffered graphical mode, similar to what Jesús implemented in Defender (amazing mental synchronization), which is revealing problems in the current PSRAM modules. So, it's a fun way to advance in blocks that will give us superpowers.
Thank you so much, Jesús, for starting the shield project, and to everyone who's contributing ideas, comments, and testing things out...
I'll soon be posting a form for those who want one and play in this "party" , to sign up for a bundle we're organizing shortly.
Big hugs to everyone!
ESPAÑOL.
Es pronto para tener algo jugable pero..... no he podido aguantar la emoción de poder mandaros esto con el primer pantallazo visible.... Una imagen más que mil palabras (la imagen la tenéis arriba).
Aún queda trabajo para que pueda ser jugable (ahora el framerate es a 1 fps) porque como no podemos usar la SD al mismo tiempo que la psram y el fichero WAD que contiene el juego, la música, texturas,etc ocupa casi 5MB y solo tenemos 4MB de flash en la que tiene que habitar el firmware y el bitstream (efectivos algo más de 3MB) , he tenido que montar un sistema de descompresión LZ4W por chunks en tiempo real, (el WAD se convierte en 2MB que se va descomprimiendo bajo demanda).
Y mientras termino un modo gráfico a todo color para el sistema de Jesús, he decidido utilizar el modo actual de 1bpp haciendo conversión en tiempo real a dithering.
Mucho trabajo para larva a 25Mhz con una memoria relativamente lenta (PSRAM).
Pero hay ideas para conseguir una versión funcional y poder decir "Doom también corre en la Alhambra...aunque necesito de una mega shield XD".
Os iré contando progresos porque esto va a ayudar a mejorar la interfaz con la psram que ahora mismo tiene algunas carencias importantes y estoy trabajando en ello para luego saltar a un modo gráfico con doble buffer , parecido a lo que Jesús ha implementado en Defender (sorprendente sincronización mental), y que está destapando problemas en los módulos actuales de psram, así que bueno es una forma divertida de avanzar en bloques que van a darnos superpoderes.
Muchísimas gracias Jesús por arrancar el proyecto de la shield y a todos los que estáis dando vuestras ideas, comentarios, probando cosas....
Pronto os lanzaré un formulario para los que quieran apuntarse para un lote que estamos organizando en breve.
¡Un gran abrazo a todos!
Maximiliano Simonazzi
Dec 30, 2025, 10:18:27 AM (12 days ago) 12/30/25
to FPGAwars: explorando el lado libre
GOOOOOOOOOOOOOOOOOOOD, i like it.
I can’t wait to see how the project evolves.
Jo mo
Dec 30, 2025, 10:53:14 AM (12 days ago) 12/30/25
to FPGAwars: explorando el lado libre
Huuuu, So Carlos, you decided to climb the Everest this time ;-)
I specially like the case who make your setup fully transportable :-)
Any way, this doom port on the Alhambra is a really nice/fun challenge !
Have a good evening guys.
charli va
Dec 30, 2025, 11:27:30 AM (12 days ago) 12/30/25
to fpga-wars-explora...@googlegroups.com
Nice picture!! XD
It's an ambitious but very interesting project that will push our beloved motherboard to its limits and allow us to experiment in many areas (compression, graphics, sound, hardware/software architecture...). We'll see where it ends up!
As soon as it's a bit more developed, I'll share it with anyone who wants to take a look, lend a hand, or offer ideas.
As soon as it's a bit more developed, I'll share it with anyone who wants to take a look, lend a hand, or offer ideas.
Nice evening!!
--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/1d53697e-1846-4e5d-9cea-45ea644be61bn%40googlegroups.com.
charli va
Dec 30, 2025, 11:40:10 AM (12 days ago) 12/30/25
to fpga-wars-explora...@googlegroups.com
Although it sounds terrifying, I've just managed to get the first "moderately audible" audio. Keep in mind that the music is in a "Mus" format, and I've just built a mini synthesizer, simplifying everything to square wave generators and reducing the voices from 8 to 4... I hope to get better results, but... the thing is starting to talk...
I'll leave it here for today :)
I'll leave it here for today :)
charli va
Jan 8, 2026, 1:59:43 PM (3 days ago) Jan 8
to fpga-wars-explora...@googlegroups.com
New episode with Doom working!
Although slow, Doom starts up and is fully functional.
LaRVa is performing better than expected.
First, I'm focusing on pushing the game to its limits with maximum resources/resolution, etc., even if it's slow, just to get the system running smoothly.
I'll move on to software optimizations and then hardware optimizations; we'll see how far we can get.
Cheers!
LaRVa is performing better than expected.
First, I'm focusing on pushing the game to its limits with maximum resources/resolution, etc., even if it's slow, just to get the system running smoothly.
I'll move on to software optimizations and then hardware optimizations; we'll see how far we can get.
Cheers!
Jesus Arias
Jan 9, 2026, 4:36:08 AM (2 days ago) Jan 9
to FPGAwars: explorando el lado libre
Nice port ;) Even if not playable it is a good demo. It also shows what would be desired:
- More bits per pixel. That means: moving the framebuffer to the PSRAM
- Faster memory. If the game is executing code from the PSRAM some sort of cache will be desired. The LaRVa core has more or less the computing power of a 25MHz 486 that was a typical platform for this game.
Nice day
charli va
Jan 9, 2026, 5:24:13 AM (2 days ago) Jan 9
to fpga-wars-explora...@googlegroups.com
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.
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.
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.
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.
Reply all
Reply to author
Forward
0 new messages