Thank you so much for demonstrating this! I am just barely getting into FPGA programming, and I instantly am falling in love with the iCE40 series. Their ease of use compared to larger chips, the QFN or TQFP formats, low price, open-source toolchains, all feel very alluring! I was initially worried about how much you can do with 5K LUT since I hear people describing it as small, but seeing all of Doom running here?? An entire RISC-V softcore and more? That is SO exciting, and just solidifies my idea that I'm going to have a lot of fun with this :D ((I often work with MCUs in the ~100MHz clock region, and am not chasing much performance, so the iCE40 will fill the gap for better timing precision SUPER nicely
I take my hat off to you Sir. For a 'small' project you have certainly excelled with the results speaking for themselves. I may try the Synth integration code myself although I suspect you'll have it done a lot quicker and streamlined well before I finish. Grats!
Thanks. You should join the discord if you want to try your hand at the synth code. I see two approaches : * Just add a dumb UART to send midi commands, purely timed by the software. Issue with that is that the time resolution you get would be basically the frame rate which is variable and only around 10 fps. Not sure if that would be enough for music to sound decent. I guess you could add some checks in the middle of the rendering loop to get a bit more control but still not great. * Add a special FIFO with "time commands", so you queue things like "send XX to MIDI" "Wait X cycles", ... and you just try to keep that FIFO filled enough in advance at each loop. In both cases, you'd need to decode the MUS files in the WAD into MIDI command. The music code was never part of the OSS release of doom so it's completely empty atm. But the internal MUS format is pretty close to MIDI already.
Amazing. I love FPGAs, I finally really got into them because the MiSTerFPGA project. This is amazing. I was looking at the iCE40 for a smaller project I got going rn.
Amazing getting that level of performance out of such a relatively low spec board! Hats off to you sir. I recorded a video playing through the first episode of Doom earlier this year on an FPGA (MiSTer's 486 core) along with a raspberry pi doing full mt-32 emulation (mt32-pi project) over an i2c connection. Couldn't have been happier with the result. Cheers to the positive future where we build cool shit and share it.
Just discovered your video, great work! I have implemented the TI-99/4A home computer for the ICE40HX4K and the ECP5 85F on the ULX3S board about 3 years ago. Then been more designing MCU boards. After seeing this I need to get my icy99 core running on the ice40up5k; I have a couple boards with this FPGA and I have the TMS9900 CPU running on the up5k but I didn’t go for the full computer back when playing with them. If you can fit doom on the riscv on them I need to get the plain old home computer fit in it 😂
as neophyte to FPGA world, it didn't occur to me that SPI could suffice for interfacing to RAM memory, which gives me hope for possibility of devising a pmod connector that integrates an old school ISA bus where things like soundblaster cards and i/o interface cards might reside (the project goal is to recreate the functionality of the motherboard of a 1988 IBM PS/2 Model 30 (which had the 16 bit AT bus). That model year had vga graphics, which my FPGA board has a hardware port for, and it has several pmod connection points. No GPIO though so was considering interfacing a bus cage via pmod
Well you can do it without the M extension but it's going to be much much slower just because there is so much multiplications involved in the render code and emulating them purely in software is going to suck. You can do away without the div hw instructions though, that shouldn't be much of an issue.
A little notice from me: 486DX2-66 has 33Mhz FSB, it has ~30-32MB/s with good Chipset with 2-1-1-1 Timing. Slow Chipset has often only 20MB/s. Thumps up for your works with Lattice iCE40
Thanks for the information. Yeah the numbers were just reflecting the theoretical peak burst rate given a timing set rather than real-world benchmark. This is also the case for the SPI PSRAM, you wouldn't reach those 50 MB/s in practice. It's not always easy to find what would have been "period correct". Lots of stuff you find now is people building retro gaming computer today and of course using pretty much the best parts they can get and tuning them in detail. Which is not always the same as what a typical system of a Joe Average user would have been back in 1993 :)
>486DX2-66 has 33Mhz FSB >~30-32MB/s with good Chipset >20MB/s Slow Chipset Iv seen as bad as ~15MB/s for DRAM. Then there is >60MB/s L1 >50MB/s L2 cache. Video shows Doom running at ~10 fps (update every 3 frames), thats 486DLC40 speed. 66mhz DX2 usually gets >25 fps. Of course its still _very impressive_ because: original DOS DOOM draws directly to mode-X chained/planar video memory using triple pageflipped hand optimized assembly, this part was never released as open source. What we got was a dual page Linux port rendering to ram with copy to vram once per frame, ~30% slower. Even today the fastest Doom source ports (MBF) are 25% slower on 486 hardware compared to the original. Sylvain oil up your microphone, its periodically squeaking :) artefact of low bitrate audio codec?
@@rasz Thanks for the numbers, interesting to see real world perf. And yeah, indeed it's about 10 fps. I think a timedemo shows ~10 - 11 fps IIRC, and that matches a quick "live" fps counter I made, complex part can dip to 8 while more easy scene can do 15. I think it should be possible to get it to 15 realistically with some "spot" optimization not needing huge rework if one wanted to pursue that. And yeah, I know, there is a periodic high pitch sound :/ I only noticed after having recorded the whole voice over track and I didn't have the courage to re-do it. I couldn't track where it comes from. I tried notching it out in post, but couldn't fully get rid of it. It's present even in the raw .wav pcm recording I made for the voice track, so not a codec issue. I have a new microphone and audio interface on the way, hopefully that'll help audio quality on future video. (Won't do much for my pronunciation though, I'll have to work on that).
An FPGA is a chip designed to implement circuits. Microprocessors are chips designed to run software. The title will hence automatically lose anyone who's technically inclined right off the bat.
Thank you so much for demonstrating this! I am just barely getting into FPGA programming, and I instantly am falling in love with the iCE40 series. Their ease of use compared to larger chips, the QFN or TQFP formats, low price, open-source toolchains, all feel very alluring!
I was initially worried about how much you can do with 5K LUT since I hear people describing it as small, but seeing all of Doom running here?? An entire RISC-V softcore and more? That is SO exciting, and just solidifies my idea that I'm going to have a lot of fun with this :D
((I often work with MCUs in the ~100MHz clock region, and am not chasing much performance, so the iCE40 will fill the gap for better timing precision SUPER nicely
Awesome Project. I want to learn FPGA to this extend.
I take my hat off to you Sir. For a 'small' project you have certainly excelled with the results speaking for themselves. I may try the Synth integration code myself although I suspect you'll have it done a lot quicker and streamlined well before I finish. Grats!
Thanks.
You should join the discord if you want to try your hand at the synth code.
I see two approaches :
* Just add a dumb UART to send midi commands, purely timed by the software. Issue with that is that the time resolution you get would be basically the frame rate which is variable and only around 10 fps. Not sure if that would be enough for music to sound decent. I guess you could add some checks in the middle of the rendering loop to get a bit more control but still not great.
* Add a special FIFO with "time commands", so you queue things like "send XX to MIDI" "Wait X cycles", ... and you just try to keep that FIFO filled enough in advance at each loop.
In both cases, you'd need to decode the MUS files in the WAD into MIDI command. The music code was never part of the OSS release of doom so it's completely empty atm. But the internal MUS format is pretty close to MIDI already.
Amazing. I love FPGAs, I finally really got into them because the MiSTerFPGA project. This is amazing. I was looking at the iCE40 for a smaller project I got going rn.
Amazing getting that level of performance out of such a relatively low spec board! Hats off to you sir.
I recorded a video playing through the first episode of Doom earlier this year on an FPGA (MiSTer's 486 core) along with a raspberry pi doing full mt-32 emulation (mt32-pi project) over an i2c connection. Couldn't have been happier with the result. Cheers to the positive future where we build cool shit and share it.
Getting Doom running on an FPGA? Cool!
Getting Doom running on the iCE40 up5k with very little resources? Awesome!
Nice avatar :)
(Also in another style, your channel banner looks pretty good :p)
Nah, getting Doom running on a RISC-V on an FPGA.
I am so excited to take a look at the verilog for this. Thanks for sharing. Subscribed!
Wow! Fantastic effort there!!!! Thanks for sharing the source and for the great run-through! Bravo!
That is soooo crazy! Well done. Amazing you squeezed that onto an iCE40. ;-)
So technical yet entertaining to a layman. Great project.🧙♂
Good work, well done!
This must be the first time a youtuber tells me NOT to click the bell icon. 😆
Love your content!
Fantastic effort & informative video. Now to read your source code :)
Just discovered your video, great work! I have implemented the TI-99/4A home computer for the ICE40HX4K and the ECP5 85F on the ULX3S board about 3 years ago. Then been more designing MCU boards. After seeing this I need to get my icy99 core running on the ice40up5k; I have a couple boards with this FPGA and I have the TMS9900 CPU running on the up5k but I didn’t go for the full computer back when playing with them. If you can fit doom on the riscv on them I need to get the plain old home computer fit in it 😂
Damn fine work!
Awesome, unbelievable!
as neophyte to FPGA world, it didn't occur to me that SPI could suffice for interfacing to RAM memory, which gives me hope for possibility of devising a pmod connector that integrates an old school ISA bus where things like soundblaster cards and i/o interface cards might reside (the project goal is to recreate the functionality of the motherboard of a 1988 IBM PS/2 Model 30 (which had the 16 bit AT bus). That model year had vga graphics, which my FPGA board has a hardware port for, and it has several pmod connection points. No GPIO though so was considering interfacing a bus cage via pmod
That start looks like the snes version frame rate wise
Hey Sylvain, nice video! Quick question, is it M(mult/div) - extension required or it can be done using just RV32I?
Well you can do it without the M extension but it's going to be much much slower just because there is so much multiplications involved in the render code and emulating them purely in software is going to suck. You can do away without the div hw instructions though, that shouldn't be much of an issue.
@@smunaut thanks for the reply!
VESA provides definitive timings exactly for this reason.
Great!! Could dive a little bit more deeper into the whole system architecture for newbees?
Welcome to 1993
I wish :) Simpler times ....
Like the capability of ice40 ultra
Liked, commenting, and sub'd; and I hit the Bell Icon!
So basically you build a gpu and emulate doom code ? On this virtual gpu
Ждём дум на микроволновке XD
A little notice from me: 486DX2-66 has 33Mhz FSB, it has ~30-32MB/s with good Chipset with 2-1-1-1 Timing. Slow Chipset has often only 20MB/s.
Thumps up for your works with Lattice iCE40
Thanks for the information. Yeah the numbers were just reflecting the theoretical peak burst rate given a timing set rather than real-world benchmark. This is also the case for the SPI PSRAM, you wouldn't reach those 50 MB/s in practice.
It's not always easy to find what would have been "period correct". Lots of stuff you find now is people building retro gaming computer today and of course using pretty much the best parts they can get and tuning them in detail. Which is not always the same as what a typical system of a Joe Average user would have been back in 1993 :)
>486DX2-66 has 33Mhz FSB
>~30-32MB/s with good Chipset
>20MB/s Slow Chipset
Iv seen as bad as ~15MB/s for DRAM. Then there is >60MB/s L1 >50MB/s L2 cache.
Video shows Doom running at ~10 fps (update every 3 frames), thats 486DLC40 speed. 66mhz DX2 usually gets >25 fps. Of course its still _very impressive_ because: original DOS DOOM draws directly to mode-X chained/planar video memory using triple pageflipped hand optimized assembly, this part was never released as open source. What we got was a dual page Linux port rendering to ram with copy to vram once per frame, ~30% slower. Even today the fastest Doom source ports (MBF) are 25% slower on 486 hardware compared to the original.
Sylvain oil up your microphone, its periodically squeaking :) artefact of low bitrate audio codec?
@@rasz Thanks for the numbers, interesting to see real world perf.
And yeah, indeed it's about 10 fps. I think a timedemo shows ~10 - 11 fps IIRC, and that matches a quick "live" fps counter I made, complex part can dip to 8 while more easy scene can do 15. I think it should be possible to get it to 15 realistically with some "spot" optimization not needing huge rework if one wanted to pursue that.
And yeah, I know, there is a periodic high pitch sound :/ I only noticed after having recorded the whole voice over track and I didn't have the courage to re-do it. I couldn't track where it comes from. I tried notching it out in post, but couldn't fully get rid of it. It's present even in the raw .wav pcm recording I made for the voice track, so not a codec issue.
I have a new microphone and audio interface on the way, hopefully that'll help audio quality on future video. (Won't do much for my pronunciation though, I'll have to work on that).
An FPGA is a chip designed to implement circuits. Microprocessors are chips designed to run software. The title will hence automatically lose anyone who's technically inclined right off the bat.