_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML The OS/2 Display Driver Zoo
fithisux wrote 7 hours 5 min ago:
We need OS/2 to come back. The arcanoae offering while good works only
for 4GB and 32bits.
Newer software needs more than this.
starik36 wrote 13 hours 4 min ago:
I've also lived through that era and used OS/2 extensively. Display
drivers were always the weak point of the system.
At one point, after a very prolonged struggle, I managed to get 800x600
resolution working (standard was 640x480). The gigantic sense of
achievement I felt at that moment hasn't been repeated in 30 years
hence.
jmspring wrote 12 hours 57 min ago:
Warp on, I didn't have video driver issues. I had a personal machine
as well as a work machine (actually ran win32 and win16 builds onthe
work machine) that never really had an issue.
From the article, it does look like things got better around then. I
do recall running 2.1 as well but was more of a try it out thing. I
actually miss OS/2
peter_d_sherman wrote 14 hours 19 min ago:
>"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 wrote 9 hours 27 min ago:
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.
Mountain_Skies wrote 16 hours 49 min ago:
Device drivers are the sanitary sewage systems of modern computing.
They're a stinky mess to design, build, and maintain, but modern
civilization/computing would be near collapse without them. They're
also something the average person doesn't want to ever have to think
about directly. Those who ensure it all works correctly aren't given
enough credit for their essential role.
bluedino wrote 10 hours 13 min ago:
In the early-ish days of Linux (2001 or so), I had a friend who
wanted to use certain scanners and modems and things that didn't have
any support. I used to always tell him 'just write a driver for it',
not realizing how complicated it would be.
I was always frustrated when we'd try to install Linux on some cheap
PC from Best Buy that had a newer integrated video card that wouldn't
run X at anything other than 640x480 with 16 colors, if even that.
I knew a little VGA programming from my DOS days but an actual video
driver was a mystery. It was probably the guys who used to work on
stuff like these OS/2 video drivers who ended up writing those things
for Linux.
trollbridge wrote 14 hours 16 min ago:
They're way, way easier than they used to be. In the example from
that article, by the time we got GENGRADD, writing a driver was easy
enough that I did it (I wanted to make a display driver that made
everything green since at the time I heard everything-green is easier
on the eyes, and it was a few hours of work to cook up a driver that
did that).
In contrast, I worked on a driver about 4 years earlier and the
amount of labour was utterly crazy. A Windows 3.1, 95, or OS/2 system
needed, at a minimum, these drivers:
- The base BIOS necessary for booting
- A VESA implementation in the BIOS (optional, but would mean the
below code could be copy-and-pasted far more easily from a generic
SVGA driver)
- (OS/2 only) a "BVH" driver which would set full screen modes,
although the default VGA/SVGA was usually enough. Windows 3.1 and 95
would just use the BIOS.
- A 32-bit "virtual" device driver to handle DOS sessions which want
to talk to the display adapter, basically making a working VM
environment for that specific hardware. The codebase for this was
different on Windows 3.x, Windows 95, and OS/2, even though the
actual function would be nearly identical. (A Windows 3.x virtual
driver could in theory be used on Windows 95, but these usually had
odd stability problems.)
- A 16-bit Windows 3.x display driver (could be re-used for OS/2)
- Another 16-bit Windows 3.x display driver for sharing the display
between a Windows and the OS/2 desktop, known as "seamless" - these
were notoriously difficult to write
- A 32-bit Windows 95 and/or 32-bit OS/2 display driver for the main
session... except in the OS/2 2.0 era, the OS/2 display driver would
have to be 16-bit, even though the rest of the OS was 32-bit. Windows
95 could use the 16-bit display driver, albeit at reduced
performance.
Another frustrating quirk was that the display driver (for both Win
3.1, 95, and OS/2 before version 4.0) would require an implementation
of pretty much all of the graphics primitives, even ones that just
rendered to a buffer in memory. Most people would write their display
driver by taking Microsoft's Video 7 sample code and re-use the
primitives in there.
dfe wrote 5 days ago:
This was an especially interesting read, having lived through using
these versions of OS/2 on varying hardware.
I think the unfortunate answer is that two if not three drivers are
going to have to be written to support the differing generations.
GRADD to satisfy Warp 4 (and 3 w/ FixPack) is probably the easiest and
most useful.
The way I see it, if I want to have some Workplace Shell nostalgia, but
with modern amenities, I'm ok being limited to at least Warp 3 +
FixPack. OS/2 2.1 and 3 are hardly different. A few colors changed
for the better, and you gain the application's icon instead of the
circle. Warp 3 still has the floating launcher thing introduced in 2.
Having to track down all the FixPacks to make the system work on
hardware even slightly newer than what was available when that OS/2
version first shipped is part of the nostalgia. Put a 28.8k modem
simulator in there, and we can really party like it's 1994.
Along those lines, if I really want OS/2 version 2 nostalgia, how badly
do I want modern amenities like high-res, high-depth graphics? Whereas
for OS/2 version 3 or 4 nostalgia, I would like to experience what
those might have been like on newer hardware.
DIR <- back to front page