Dipping in and out here as I’m supposed to be on holiday lol. If the framebuffer is the low level interface to the hardware (?) what would be the right NuttX/portable graphics intermediate language?
Regards, Tim. > On 8 Nov 2025, at 19:28, Tomek CEDRO <[email protected]> wrote: > > 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
