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 >>>
