That's very cool! A wolfenstein engine on NuttX is pretty interesting. I figure having a couple games on NuttX could attract some curiosity from hobbyists, and there's no better choice than games from the era of clever, low-resource rendering and physics. DOOM has also become somewhat of a "trend" to port to low-resource devices (not the the Pi4B meets that description). I've seen people run it on disposable vapes, microwaves and even fancy pregnancy tests.
Matteo On Sat, Nov 8, 2025 at 9:16 AM Tim Hardisty <[email protected]> wrote: > Or was it a dos emulator; don’t remember! > > > > On 8 Nov 2025, at 15:03, Tim Hardisty <[email protected]> wrote: > > > > Doom was the first and last “full graphics” I played I think. Doom > feats after hours in the 1990’s maybe? > > > > Bring back Commander Keen lol. > > > > (Yes, have played it some times with Win3 emulators!) > > > > Regards, > > > > Tim. > > > >> On 8 Nov 2025, at 13:20, Gregory Nutt <[email protected]> wrote: > >> > >> * > >> Thanks again everyone for your help so far! One step closer to DOOM on > >> > >> NuttX :) > >> > >> Back in the old days when games were pure software, I enjoyed writing > games for NuttX. I have wolfenstein-like engine and an experimental 3D > ray-casting engine. These used to run on NuttX. The latter was once a > part of the apps/ repository but I removed it when I donated NuttX to > Apache (since I didn't intend to donate that [art). But I suppose it is > still in the GIT history. > >> > >> UNRELATED: When NuttX was donated, there were a lot of files in the > repository that should not have been released and were removed in this > way. Many other files with different licenses were present at the time of > release and these had to be sanitized, to make them Apache correct (thanks > almost entirely to Alin Jerpelea). When we talk about NuttX being Apache 2 > copyrighted by the ASF, we really only the git repository from a certain > point forward > >> > >> Prior to that, checkouts from the repository are BSD licensed and > copyrighted by me. > >> > >> I also used to run the public 2-D Wolfenstein-like screen saver on > NuttX. It worked fine mostly out of the box. > >> > >> ________________________________ > >> From: Matteo Golin <[email protected]> > >> Sent: Friday, November 7, 2025 9:31 PM > >> To: [email protected] <[email protected]> > >> Subject: Re: RPI 4B Roadmap > >> > >> I managed to get something working with the frame buffer interface, so > >> success so far! https://github.com/apache/nuttx/pull/17294 > >> > >> Unfortunately, I encountered an issue trying to compile the LVGL demo > so it > >> hasn't been much more interesting than some test rectangles so far. > >> https://github.com/apache/nuttx-apps/issues/3208 > >> > >> The frame-buffer driver was actually really simple to get working after > >> looking at Lup's blogs, so thank you for the tip Tomek (and Greg, for > the > >> easy-to-implement driver)! I will probably go back and document the bit > of > >> the frame buffer lower-half that I understand, since a little bit of > >> developer documentation for how to write a lower-half and what's exactly > >> needed to get running would be useful. There's also no docs for the > >> framebuffer example application, which I plan to fix shortly. It would > be > >> good to know what the output should look like so I'm not scratching my > head > >> wondering if I got it right or not :) > >> > >> Thanks again everyone for your help so far! One step closer to DOOM on > >> NuttX :) > >> > >> Matteo > >> > >>>> On Thu, Nov 6, 2025 at 2:37 PM Tomek CEDRO <[email protected]> wrote: > >>> > >>>> On Thu, Nov 6, 2025 at 5:53 PM Matteo Golin <[email protected]> > >>>> wrote: > >>>> 1) I am actually familiar with the rpi4-osdev project. In part 5, the > >>>> author uses the framebuffer approach for graphics: > >>>> > https://github.com/babbleberry/rpi4-osdev/tree/master/part5-framebuffer. > >>>> This is actually a really simple approach to implement, which is why I > >>>> imagine it wouldn't be difficult to integrate with NuttX's frame > buffer > >>>> method of graphics. The main problem for me is that it's very slow. I > >>> want > >>>> to figure out how to leverage the actual GPU so that graphics can be > >>> faster > >>>> and more complex. I have not started looking extensively into that > yet, > >>> but > >>>> was mainly wondering how that approach fits into NuttX's graphics > system. > >>> > >>> From the long years on FreeBSD desktop where nvidia is the only vendor > >>> providing native high quality GPU drivers it seems good to have > >>> "generic" framebuffer driver that will work on any hardware in the > >>> first place and then GPU specific drivers with hardware acceleration > >>> where available. This allows not only having graphics on anything, but > >>> more importantly a fallback when GPU drivers fail / buggy / > >>> unavailable. Anything here means not only Xorg (and similar) but also > >>> raw console that can launch framebuffer applications or a mouse > >>> pointer that can copy-paste in the raw console! :-) Console woks on > >>> top of the video framebuffer (i.e. /dev/ttyv0..7), Xorg also works on > >>> top of the framebuffer (when launched it goes to place of /dev/ttyv8). > >>> This is modular and versatile design that allows text mode console on > >>> video display, graphical applications in raw video console, and Xorg > >>> or similar. > >>> > >>> There are two framebuffer drivers on FreeBSD: > >>> 1. VESA (old / bios machines): > >>> https://man.freebsd.org/cgi/man.cgi?query=vesa. > >>> 2. SCFB (new / usefi machines): > >>> https://man.freebsd.org/cgi/man.cgi?query=scfb > >>> > >>> Therer are two console drivers on FreeBSD: > >>> 1. SYSCONS/SC (old / bios machines): > >>> https://man.freebsd.org/cgi/man.cgi?query=syscons > >>> 2. VT (new / uefi machines): > https://man.freebsd.org/cgi/man.cgi?query=vt > >>> > >>> SCFB / VT works also on embedded systems like rPI (over HDMI if that > >>> works). It seems work-in-progress but works for years already. The > >>> only problem I saw so far is the console colors packed into two bit > >>> field (afair) that may need structure changes to get dedicated 8..24 > >>> bit bit field to get more colors that will be breaking change thus it > >>> may be good to think ahead and use this wider field if we want to do > >>> something similar in NuttX :-) > >>> > >>> Here is newcons / vt wiki: https://wiki.freebsd.org/Newcons > >>> > >>> Hope this helps a bit or gives some reference point :-) > >>> > >>> On Linux ~20 years ago it was also possible to draw on raw video > >>> framebuffer using DirectFB (now version 2) even with no Xorg, see > >>> https://en.wikipedia.org/wiki/DirectFB :-) Current DRM/KMS approach is > >>> a moving target and kind of PITA because FreeBSD followed that path to > >>> have GPU drivers compatible with Linux for easier porting and this > >>> only brings problems because things change constantly and are pain to > >>> maintain / use thus I would recommend to avoid this path :-( > >>> > >>> I guess we care most about this design / approach where we have > >>> FrameBuffer that allows drawing directly (i.e. LVGL), having console, > >>> or Xorg or similar (there is example Xorg compatible server in > >>> NuttX!!) :-) > >>> > >>> -- > >>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > >>> >
