The OS/2 Display Driver Zoo • Hacker News Board

Re: The OS/2 Display Driver Zoo

#11

Post by peter_d_sherman » Sat, Oct 25, 2025, 2:09 AM UTC

userbinator wrote: post #9

peter_d_sherman wrote: post #4

>"GRADD [display] drivers worked the other way around and a basic driver did almost nothing except provide a dumb framebuffer and indirectly let SOFTDRAW do all the work. An accelerated driver could hook out certain operations that hardware could do much faster than software, such as screen-to-screen copies, hardware cursors, or bit blits with color conversion. Anything the driver didn’t explicitly ask to handle was…

5MB of Asm sounds like they really didn't know what they were doing, given that MenuetOS/KolibriOS is also 100% Asm and contains quite a lot more than a display driver, more like an entire OS, in a fraction of that size. Then again, I have seen the Windows example display driver code from roughly the same era, and it's also insanely bloated. I've written a VESA + (Intel) GPU accelerated driver for Windows, and it was…

It doesn't surprise me (in the least) that the display driver code from that era was insanely bloated!

Hey, if your VESA GPU accelerated driver for Windows is open-source, I'd love to take a look at it.

No worries if it's not... But if it is open source, then I'd love to take a look!

I'm also a big fan of MenuetOS/KolibriOS (and any other small OS that can fit on a 1.44MB floppy! Remember the original Damn Small Linux (DSL) anyone?)

Re: The OS/2 Display Driver Zoo

#12

Post by userbinator » Sat, Oct 25, 2025, 11:53 PM UTC

peter_d_sherman wrote: post #11

userbinator wrote: post #9

Earlier quoted context omitted.

5MB of Asm sounds like they really didn't know what they were doing, given that MenuetOS/KolibriOS is also 100% Asm and contains quite a lot more than a display driver, more like an entire OS, in a fraction of that size. Then again, I have seen the Windows example display driver code from roughly the same era, and it's also insanely bloated. I've written a VESA + (Intel) GPU accelerated driver for Windows, and it was…

It doesn't surprise me (in the least) that the display driver code from that era was insanely bloated! Hey, if your VESA GPU accelerated driver for Windows is open-source, I'd love to take a look at it. No worries if it's not... But if it is open source, then I'd love to take a look! I'm also a big fan of MenuetOS/KolibriOS (and any other small OS that can fit on a 1.44MB floppy! Remember the original Damn Small Linu…

Sorry, it's currently not open-source but perhaps in the future; it's actually quite simple, using DPMI functions to call the VBIOS for modesetting and then passing the framebuffer address to Windows' DIBENG for the drawing. If an Intel GPU is detected then it sets up the ring buffer and handles some of the drawing functions by writing commands to the GPU and waiting for them to finish. No 3D acceleration (yet) but I imagine it wouldn't take that much more code to essentially translate a higher level graphics API to the appropriate GPU commands.

Re: The OS/2 Display Driver Zoo

#13

Post by peter_d_sherman » Tue, Oct 28, 2025, 6:30 AM UTC

userbinator wrote: post #12

peter_d_sherman wrote: post #11

Earlier quoted context omitted.

It doesn't surprise me (in the least) that the display driver code from that era was insanely bloated! Hey, if your VESA GPU accelerated driver for Windows is open-source, I'd love to take a look at it. No worries if it's not... But if it is open source, then I'd love to take a look! I'm also a big fan of MenuetOS/KolibriOS (and any other small OS that can fit on a 1.44MB floppy! Remember the original Damn Small Linu…

Sorry, it's currently not open-source but perhaps in the future; it's actually quite simple, using DPMI functions to call the VBIOS for modesetting and then passing the framebuffer address to Windows' DIBENG for the drawing. If an Intel GPU is detected then it sets up the ring buffer and handles some of the drawing functions by writing commands to the GPU and waiting for them to finish. No 3D acceleration (yet) but I…

No worries on your code not being open source!

I'm always interested in old graphics drivers, that's because they apparently lived in "two worlds" -- the world of "framebuffer is on the GPU and the GPU can perform the required graphics function being requested by the driver" and the second world of "framebuffer is of necessity in main RAM, the GPU doesn't support the required graphics function being requested(!) -- so let's use the CPU and the CPU's RAM and software on the PC side of the equation (as opposed to hardware on the GPU) to emulate in software the required hardware graphics function being requested (in your driver's case, this would be using the Windows DIBENG / Windows code -- for that functionality).

That dichotomy, from an OS/graphics driver/engineering standpoint -- is fascinating...

These days of course, we have shared (CPU/GPU) memory and GPU's where all graphics drawing operations are implemented on the GPU side -- so there's little need to set up an additional unshared frame buffer in PC memory, draw on it with software ran by the CPU, then copy it to the graphics card to update the old graphic's card's then unshared frame buffer -- as was apparently necessary in very old PC's with very old graphics cards...

But from an (old) OS/graphics driver/engineering standpoint -- it's fascinating!

Ya gotta love the old stuff! :-)