Awesome! A huge amount of work must have gone into this.<p>I did some playing around with VGA graphics from the Pico when it first came out (wrote a simple library to produce SNES like graphics, wrote it all up on my blog <a href="https://gregchadwick.co.uk/blog/playing-with-the-pico-pt6/" rel="nofollow">https://gregchadwick.co.uk/blog/playing-with-the-pico-pt6/</a>). It felt like Doom should be doable but I figured you'd need an off chip RAM expansion interfaced via the PIO. Clearly not.<p>The Pico really is a very fun board to play around with. Could be a great target for a retro style mini console thing.
That's cool, it's Doom in a completely self-contained cartridge size. Would it be possible to just hook up a cartridge like this to a monitor (through e.g. usb-c) directly?<p>Also if the RP2040 is just $1, does this mean we should be able to get e.g. Doom on cheap handheld single-game devices like the old Game & Watch and similar machines? I remember spending hours on these "racing games" or 12-in-1 Tetris LCD machines from the toy shop. How much does a small (2-4") color OLED or backlit LCD cost these days? Actually, what is the cheap handheld market looking like these days? I had a boggle at the local toy shop's website, VTech is still going for it but mainly with baby toys it seems, and those Tetris handhelds are still the same from 20-30 years ago, they cost just €3,99 these days. I'm also seeing some products from a company called Wonky Toys, and miniature Atari arcade cabinets.
What a coincidence, I was working on porting doom to the e-ink badger2040 last week. Getting doom to fit into memory was fairly straightforward, but they did a better job than me. I'm very impressed they got the original WADs and networking going as well. Great work!
This is impressive.<p>I'm wondering about a few things:<p>- "I decided to leave the XIP cache to do its thing, and select a few small areas of hot code or data to promote to RAM manually"[1]: I understood this as you leaving the XIP cache activated. But this seems at odds with "16K of flash XIP cache, that we’ve talked about, but decided not to use."[also 1], which I'm interpreting as "decided not to make use of the XIP cache (i.e. turn it off)" (maybe I'm misreading).<p>- I thought ARM32 has 12(-14) usable registers (compared to 14-15 in x86-64), so why these mentions of "scarce Cortex-M0+ registers"? (Does FIQ mode reduce the number of usable registers?)<p>- "not good on a Cortex M0+ where the overhead of a function call is generally 30-40 cycles, with the corresponding loss of most of your precious “in-register” state": are function calls <i>disproportionally</i> slower on Cortex M0+? (Certainly 30-40 cycles seems high.) Why is that? (Registers r4-r11 are callee-saved[2], thus not lost; mutable data might have to be re-read from memory, though--just like on other architectures, but maybe CPU caches are faster on those.)<p>- "These OR values can be stored in a lookup table indexed by higher bits in the sample position, and thus the 8x space savings can be realized without needing any branches in the code!"[3]: Cortex-M0+ has a 2-stage pipeline[4], I'd hence expect the cost of a jump to be just 1 additional cycle, for the re-processing of the 1st stage for the next instruction (maybe I'm wrong), which would be the same as a memory access. (Maybe multiple jumps can be saved this way, though.) Did measurements show the lookup table to be faster?<p>[1] <a href="https://kilograham.github.io/rp2040-doom/speed_and_ram.html" rel="nofollow">https://kilograham.github.io/rp2040-doom/speed_and_ram.html</a>
[2] <a href="https://en.wikipedia.org/wiki/Calling_convention#ARM_(A32)" rel="nofollow">https://en.wikipedia.org/wiki/Calling_convention#ARM_(A32)</a>
[3] <a href="https://kilograham.github.io/rp2040-doom/sound.html" rel="nofollow">https://kilograham.github.io/rp2040-doom/sound.html</a>
[4] <a href="https://en.wikipedia.org/wiki/Cortex-M0%2B#Cortex-M0+" rel="nofollow">https://en.wikipedia.org/wiki/Cortex-M0%2B#Cortex-M0+</a>
> You can refer to Doom Wiki - WAD section to get a bit more detail about the types of lumps mentioned below.<p>I just HAVE to nitpick on Fandom/Wikia search term squatting. There is a real Doom Wiki at doomwiki.org.
The Pi Pico reinvigorated my love of tinkering with electronics. I can hack my way through C on an Arduino (and would probably still use it for any serious deployment that I didn't expect to turn into a big community effort) but for standing up quick proof of concepts, embedded python is outstanding. Incredible for $4.<p>These newer compatible boards being released are awesome.
Fun stuff, it always amazes me that people are surprised. Not having lived through it is a part of that I'm sure.<p>The RP2040 is more powerful than an 80286. The PC/AT which was hugely more powerful than the original IBM PC (on which DOOM also ran). Put a keyboard, mouse, and an frame buffer on an STM32F4 or F7 and you've got the computational and capability equivalent of the PC's that powered the world in 1985. People did accounting, CAD, spreadsheets, email, all sorts of things on them. Amazing I know, but here we are.
Stacksmashing was able to get Doom running on an RP2040 with an LCD screen. I'd love to see it running on the Lily-GO board.
<a href="https://usa.banggood.com/LILYGO-TTGO-T-Display-RP2040-Raspberry-Pi-Module-1_14-inch-LCD-Development-Board-p-1915490.html?cur_warehouse=CN" rel="nofollow">https://usa.banggood.com/LILYGO-TTGO-T-Display-RP2040-Raspbe...</a><p>It has two buttons built-in and support for LiPo batteries.
It might be possible to make this a teeny-tiny handheld device.
This is really nice. Trying to port Doom to RP2040 was on my on my todo list, but all along I feared that the SRAM would simply not be sufficient for a port with authentic feel and original assets. I'm glad to be proven wrong. I wonder if DEH support is out of question.<p>I can't wait to see what kind of a chip they make after the RP2040.
> RP2040 Doom supports up to four players in regular/deathmatch mulit-player over a two wire I2C connection.<p>I thought I had done something worthwhile with I2C.<p>I was wrong, and I am a bad person.
So I just got my hands on a couple of Picos. I was so excited to find a RPi board in stock, that I forgot to check if it has WiFi or not. I would like to run some form of OpenSprinkler on that (even if not OpenSprinkler, I can use cron jobs to control the sprinkler relays by hand).<p>Any tips on how to get WiFi working on Pico?