Hi! I’m starting a separate thread so I don’t clutter the Spectrum and Amstrad one. For now I’m just reporting small progress — I’m starting to understand the ins and outs of the machine and things are beginning to move.
https://www.youtube.com/shorts/XpRSEr-jYdE
It’s really interesting how the game is set up. I’ll document it for you later, but basically it uses a couple of interrupts to generate the gameplay sequence and the drawing, both running asynchronously in parallel.
Right now I’ve already solved the rendering part (Jesús, a huge inspiration — the Defender line buffer, thank you so much), but the interrupt that manages the little aliens is still giving me problems. That’s why, as you can see in the video, the animation starts but then gets stuck (in fact, at first I thought the game had frozen, because I was getting frozen screens right after the first frame).
But… oh! surprise! I mapped “insert coin” to SW1 and it turns out it’s not dead!! It’s just that, let’s put it this way, one of the threads — the one that moves the bad guys — is dead.
In any case, I’ve gone from a broken frame sequence full of artifacts and frozen garbage pixels to a clean image where things are starting to move.
Just out of curiosity, another thing that gave me a hard time — and that’s now working properly — is memory. With this port I’m testing the new PSRAM modules I’ve made, which are much simpler than the initial ones and are proving to be very stable (with the first ones I got carried away and hadn’t debugged them enough, and by building on other code I ended up with a house of cards that fell apart at the slightest issue).
This game is serving as a real trial by fire, because another “curious” thing about Invaders is how it handles collisions with the enemies. Instead of keeping an internal memory map like would be typical in more modern games (even today), what it does is read the screen and check whether there’s white or black where the laser is going XD — which makes things even more complicated because the CPU and the VGA have to compete for the PSRAM.
I’ll keep telling you about the adventure.
And a reminder for anyone interested: I’m collecting names in a form for those who want to get a Shield. For now there are already quite a few people signed up, but not enough for a batch. As soon as I finish a few more demos I’ll start moving things forward, but in case someone missed it, here’s the link:
https://icestudio.io/buygroup-alhambramm
Some people asked me why I’m asking about the price. We don’t want to “make money” from this — we’ll add a small margin to fund new boards and prototypes — but the idea is that everyone who wants one can enjoy it and that we can get a fair price. I already have several quotes with manufacturing locked in, but prices vary a lot depending on quantity. For example, if everyone gives a target price range X and, imagine, reaching that requires 100 boards, then the idea is to reach 100 — because ordering fewer than that doubles the price.
I just wanted to clarify that the idea and goal of asking you all is to find a price point that fits what interested people can comfortably pay, if possible.
Big hug!

Hi everyone! I’ve almost wrapped up the development and, honestly, I got a bit carried away. This kind of work, as we’ve already discussed, is a treasure trove for learning — I’m really happy with the journey.
First and most important: the progress video. If you can, please watch it all the way to the end because it comes with “EXTRAS” :)
Screenshot 2026-01-28 at 22.39.47.png
https://www.youtube.com/shorts/pXO2FJ8BNLw
On the other hand, I’m leaving you space_invaders_v1.bin. It includes PS/2 support but I haven’t been able to test it — it’s “untouched,” so there’s a good chance it won’t work. But if you can confirm it does, that’d be awesome. If it doesn’t, you can still test it using SW1: the first press inserts a coin, and the second press starts Player 1. That way you can at least get into the game to hear the sound.
I mapped the keyboard like this:
1, 2 -> enable 1 or 2 players
Enter -> Insert coin
Left Arrow / Right Arrow -> movement
Space -> Fire
Put on headphones so you can hear the audio — it only activates when you’re actually playing; in demo mode the original Invaders has no sound.
If any of the 6 samurais who have the shield can try it and give me feedback, I’d really appreciate it! I’m working on fixing the keyboard situation, and in a way I think you’re going to really like, but I still need a few days to have it fully closed. For now, if those of you with a compatible keyboard can confirm it works, I’d be grateful.
And now, some war stories — for whoever’s interested.
I’m using this development to test board-related things. Specifically, I improved and simplified the PSRAM modules. The ones I’d done before were very unstable and as soon as I put them under heavy load they’d lock up, return wrong data… a disaster. For example, I put DOOM on hold because of this, and I’ll pick it back up soon thanks to what I’ve refined in Space Invaders.
I simplified and reduced the PSRAM modules and I’m going to polish and stress-test them one by one. In this case we’re only using “word” mode, meaning we write and read one 32-bit word at a time. Possibly, using the next modules I’ll work on — in burst mode or with CDC to raise the PSRAM frequency — we’ll be able to get better performance, but for now this little module has behaved like an absolute champion.
Once I got past the adaptation hurdles and a few bugs that almost drove me insane… I’ll mention one really funny one: the sound. As soon as it booted there was a super loud phone-like buzzing — everything was awful. A thousand changes to the sigma-delta, tests everywhere, nothing, impossible, not a single improvement… and suddenly I decided to start a game and… everything sounded fine XD WTF!!! I couldn’t understand it: only horrible sounds in demo mode, but if you played everything was perfect… I’m losing my mind: “this has to be the CPU, I’m misaligned, some race condition, I’m overwriting data…” and when I had nothing left to explore, I went to look for the game source code (the community has disassembled it in several places). I check the code… damn… in demo mode there is no sound… the machine has a register to literally “turn off the speaker,” and when it’s in demo it saves sound cycles to do funny little animations… XD
Anyway, adventures to tell in the documentation. Now, in the video you’ll see several things:
Normal — Space Invaders was designed so you’d literally rotate the monitor and take advantage of the vertical length, so naturally on our monitors it will appear sideways. It runs super smoothly; in the video I left demo mode running for a while so you can see how fluid it is. This is because I don’t have a PS/2 keyboard right now and I haven’t been able to test movement in-game; that’s why in the other screens you’ll see the ship staying still (I have no keyboard, controller, or button option to move it XD).
I enabled gameplay even though the ship stays still so you could hear the sound, but it was useless because the sounds are generated with very harsh square waves, and modern phones filter them as if they were noise XD. As soon as I can, I’ll make a small amplifier with a buzzer and see if that can be recorded properly. In any case, I’m not especially proud of the sound — it’s motivated me to improve it in the mid-term. I’m working on sound generation stuff, and when that advances elsewhere I might try to apply it here. I’m very motivated to replicate the original sound chip of this machine; it’s really curious and educational. I’ll tell you about it later. For now, even if it’s very dirty, it “sounds.”
You can use SW1 and SW2 (the Alhambra buttons): with SW1, the first press inserts a coin and the second starts the game (if you don’t have PS/2). With SW2 you change video mode.
Video modes — motivated by Jesús’s suggestion to run it horizontally, I got carried away and wanted to squeeze PSRAM in word mode to see how far it could go, and one mode led me into another, each time trying to get a little more. As I’ve done in other works like Jesús’s Mandelbrot conversion, I try not to touch the original things. For example, there are software emulators that modify the Space Invaders core to make it horizontal, and the same with sound — it was hard to find a video with original sound. In the end, tuning things so they look “better” doesn’t interest me much unless there’s a concrete reason behind it. If Space Invaders sounded tinny, then it has to sound tinny XD
In the video modes you’ll see:
Horizontal mode: what we do is rotate the original framebuffer into another framebuffer (both in PSRAM — managing this makes you feel like… wow…) because if it’s sideways and VGA runs at its own pace, we can’t convert on the fly; we need “a rotated copy.” The problem… PSRAM is very slow and now we have three things competing for it: the 8080, which wants its chunk to draw the little aliens (it writes and reads because it checks shot states from the pixel states), our rotator that needs pixels to rotate them (reads one buffer and writes another), and then a line buffer (based on Jesús’s “defender” idea) that takes from the rotated buffer and paints it to VGA… a beautiful dance :)
In this mode, one detail is that scaling is done with Bresenham — that’s me going the extra mile. Documentation-wise it’s a great example of what an FPGA can do: real multitasking. Space Invaders doesn’t fit into 480 lines of height — it’s missing a few lines — but it doesn’t fit. Simple solutions would be to literally remove some lines or increase resolution. Increasing resolution would break my timing assumptions because PSRAM is already very tight and that would require more bandwidth, plus the resolution wouldn’t fit as nicely. Removing lines felt bad — we would have ended up either without scores or without the credits/lives line… With Bresenham, I interpolate, so it doesn’t matter if the resolution isn’t a clean multiple. You’ll see the image a bit more squashed, but it’s very reasonable.
Horizontal mode with procedural background: basically I wanted to test adding a hardware process that computes the background and overlays it with the game. If you like it, we can run a “background contest” once I share the code xD. Honestly the motivation was to try Jesús’s 144-color mode… wow, total success — I was blown away. With a 6-bit DAC, the color richness is incredible. This doesn’t show up in the video, but I implemented a couple more backgrounds too; it’s fun.
Image mode: this is the super bland one you’ll see, with three color bands: red band, blue band in the play area, and green band on the right side. The background (the bands) is an image. This mode is slower — you’ll see the game struggling — because we’re really pushing it and PSRAM is like… I can’t anymore (and in burst mode, by theoretical calculations, it wouldn’t be enough either). This will be a test once I finish the CDC module and we can try whether higher memory clocks are possible — it’ll be a good benchmark. The key is that here we add one more competing buffer: the image buffer.
In this mode we have the game buffer, the rotated buffer, the image buffer, and the mixing buffer (rotated + image) that the line-buffer draws to the screen. In any case it’s almost playable and it helps validate that PSRAM is more than valuable and effective. And like I said, if we manage to get the higher-speed mode working and the design allows it, we could squeeze it even more.
Anyway, as I said, I’m super happy with the result. I still have to improve a few things — like the image loading (I have some issues there and I want to leave you something nicer than three color bands) — and I’m not sure if I’ll revisit the sound a bit. The thing is, since this already made me half-crazy, I preferred to park it for now with the results already achieved.
And on the other hand, I’ve been thinking about a possible adaptation for the Alhambra without the shield — a more compact version with fewer features, but functional and, from a learning perspective, very useful (or at least that’s how it seems to me). The idea is to have an Icestudio version soon. At this point, if you’re interested, let me know so I can keep it in mind; otherwise I can leave it more or less parked around the point I currently have it.
Good night!!
--
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/5ff621d7-b786-4e13-9dd2-8e8c906383d6n%40googlegroups.com.
|
LED |
Efecto |
Duración |
Pausa |
|
0 |
Trigger (láser) |
2 seg |
2 seg |
|
1 |
Invader Hit |
0.5 seg |
2 seg |
|
2 |
UFO Hit |
0.6 seg |
2 seg |
|
3 |
UFO (sirena) |
3 seg |
2 seg |
|
4 |
Flash (explosión) |
2 seg |
2 seg |
|
5 |
Extended Play |
1.5 seg |
2 seg |
|
6 |
Step 1→2→3→4 |
2 seg |
2 seg |
|
7 |
(marcador loop) |
1 seg |
2 seg |

--
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.

--
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.


--
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.

English below.
Buenas! abro hilo para no contaminar el del Spectrum y el Amstrad. De momento solo os reporto pequeños avances, voy entendiendo los entresijos de la máquina y empieza la cosa a moverse.Es muy curioso como está planteado el juego, ya os lo documentaré pero básicamente utiliza un par de interrupciones para ir generando la secuencia de juego y el pintado, ambas en paralelo asíncronamente.Ahora mismo ya tengo solucionado la parte de pintado (Jesús una gran inspiración el linebuffer del Defender mil gracias), pero la interrupción que gestiona los marcianitos aun me está dando problemas, por eso como veis en el vídeo, la animación comienza pero se queda clavada (de echo pensaba de inicio que el juego se me había quedado congelado ya que venía depantallas congeladas tras el primer frame.Pero... oh! sorpresa! asocié el insert coin al sw1 y resulta que no está muerta!! solo que digámoslo así , uno de los hilos, el que mueve a los malos , está muerto.En cualquier caso he pasado de una secuencia de frames rotos y llenos de artefactos de pixels basura congelados, a imagen limpia en la que ya empieza a moverse .Por curiosear un poco otra cosa que me ha dado guerra y que ya está funcionando bien es el tema de la memoria. Con esta adaptación estoy testeando los nuevos módulos que he hecho de psram que son mucho más sencillos que los iniciales y están demostrando ser muy estables (los primeros me pudo la emoción y no los había depurado lo suficiente y al partir de otros códigos había construido un castillo de naipes que a la mínima se rompió).Con este juego me está valiendo como prueba de fuego ya que otra cosa "curiosa" del Invaders es como gestiona las colisiones con los bichos, en lugar de llevar un mapa interno de memoria como sería habitual en juegos más modernos o incluso actuales, lo que hace es consultar la pantalla, ver si donde va el laser hay blanco o hay negro XD , punto que complica aun más las cosas porque tienen que competir por la psram la cpu y la vga .Os seguiré contando la aventura.Os recuerdo para los interesados que estoy recogiendo en un formulario a los interesados en conseguir una Shield de momento ya hay unos cuantos inscritos pero no suficientes para el batch, en cuanto termine algunas demos más empezaré a moverlo pero por si a alguien se le coló, dejo el enlace:
https://icestudio.io/buygroup-alhambrammHay gente que me preguntó sobre por qué pregunto por el precio. Con esto no queremos "ganar dinero", añadiremos un pequeño margen para financiar nuevas tarjetas y prototipos, pero la idea es que podáis disfrutar de ella todos los que tengáis ganas de ello y consigamos un precio justo, ya tengo varios presupuestos con fabricación cerrada pero los precios varían muchísimo en función de la cantidad, si por ejemplo todo el mundo da un baremo X e imaginaos para conseguirlo hacen falta 100 tarjetas pues la idea es llegar alas 100 porque pidiendo menos de eso el precio se duplica.Era solo por aclarar que la idea y objetivo de tantearos es el poder conseguir encontrar un precio que se ajuste a lo que la gente interesada pueda pagar cómodamente si fuera posible.Un gran abrazo!EnglishHi! I’m starting a separate thread so I don’t clutter the Spectrum and Amstrad one. For now I’m just reporting small progress — I’m starting to understand the ins and outs of the machine and things are beginning to move.
https://www.youtube.com/shorts/XpRSEr-jYdE
It’s really interesting how the game is set up. I’ll document it for you later, but basically it uses a couple of interrupts to generate the gameplay sequence and the drawing, both running asynchronously in parallel.
Right now I’ve already solved the rendering part (Jesús, a huge inspiration — the Defender line buffer, thank you so much), but the interrupt that manages the little aliens is still giving me problems. That’s why, as you can see in the video, the animation starts but then gets stuck (in fact, at first I thought the game had frozen, because I was getting frozen screens right after the first frame).
But… oh! surprise! I mapped “insert coin” to SW1 and it turns out it’s not dead!! It’s just that, let’s put it this way, one of the threads — the one that moves the bad guys — is dead.
In any case, I’ve gone from a broken frame sequence full of artifacts and frozen garbage pixels to a clean image where things are starting to move.
Just out of curiosity, another thing that gave me a hard time — and that’s now working properly — is memory. With this port I’m testing the new PSRAM modules I’ve made, which are much simpler than the initial ones and are proving to be very stable (with the first ones I got carried away and hadn’t debugged them enough, and by building on other code I ended up with a house of cards that fell apart at the slightest issue).
This game is serving as a real trial by fire, because another “curious” thing about Invaders is how it handles collisions with the enemies. Instead of keeping an internal memory map like would be typical in more modern games (even today), what it does is read the screen and check whether there’s white or black where the laser is going XD — which makes things even more complicated because the CPU and the VGA have to compete for the PSRAM.
I’ll keep telling you about the adventure.
And a reminder for anyone interested: I’m collecting names in a form for those who want to get a Shield. For now there are already quite a few people signed up, but not enough for a batch. As soon as I finish a few more demos I’ll start moving things forward, but in case someone missed it, here’s the link:
https://icestudio.io/buygroup-alhambramm
Some people asked me why I’m asking about the price. We don’t want to “make money” from this — we’ll add a small margin to fund new boards and prototypes — but the idea is that everyone who wants one can enjoy it and that we can get a fair price. I already have several quotes with manufacturing locked in, but prices vary a lot depending on quantity. For example, if everyone gives a target price range X and, imagine, reaching that requires 100 boards, then the idea is to reach 100 — because ordering fewer than that doubles the price.
I just wanted to clarify that the idea and goal of asking you all is to find a price point that fits what interested people can comfortably pay, if possible.
Big hug!
--
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.



