We also need to create BAD APPLE on NuttX as our ultimate multimedia portability benchmark :D :D
Some examples: https://www.youtube.com/watch?v=nNC6aTSKiwk https://www.youtube.com/watch?v=MEmF7eNj5U8 https://www.youtube.com/watch?v=cd5iEeIe7L0 https://www.youtube.com/watch?v=4kdtiOyJgtc https://www.youtube.com/watch?v=R6myIbJpUWo https://www.youtube.com/shorts/ObM7cnKjjY8 https://www.youtube.com/watch?v=B9TrOxXer4E https://www.youtube.com/watch?v=xazooShtoTM https://www.youtube.com/watch?v=5NXSMdUH_Cg https://www.youtube.com/watch?v=i0NjDNyZfbY https://www.youtube.com/watch?v=dx76YPgZviE And many many many more :-) https://www.youtube.com/results?search_query=bad+apple+hardware Tomek On Sat, Nov 8, 2025 at 5:16 PM Matteo Golin <[email protected]> wrote: > > 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 > > >>> > > -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
