[peter_d_sherman]

>"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 done by SOFTDRAW."

[...]

"To give a sense of the complexity of the drivers, the 16-bit VGA driver was over 5 MB of assembler code, heavily macro-ized. The 32-bit VGA driver was over 6 MB of assembler, again using lots of macros. The 32-bit accelerated driver was about 1.5 MB of assembler and 3.6 MB of C code.

In contrast, the accelerated S3 GRADD driver was a little over 200 KB of C code, and the generic unaccelerated GRADD driver was only 30 KB of C code!"

[userbinator]

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 only a few KB of Asm.

[peter_d_sherman]

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

[userbinator]

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.

[peter_d_sherman]

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! :-)