If we want to continue to use Win98se on newer hardware this will have to be done...

SciTech has a 915 driver, but doesn't have a driver for the newer chipsets e.g. the 945GM in my laptop and I've had no success in attempting to unpack the installer and force-install 945G drivers manually (I doubt there is much difference between the G and GM anyway). They do not support 3d acceleration, and 2d acceleration support is supposed to be minimal.

The Intel i800-series (e.g. 865) drivers might be worth trying to force install; although it did not work in my case, I have not investigated the issue further and it may be due to the driver looking for specific device IDs before it will operate. Providing there is sufficient backwards compatibility between the 900 and 800-series, in this case it should be trivial to edit the driver so it will recognise the device ID of the 900-series chipsets. 2d acceleration should be possible, and maybe even 3d.

I have found the i810 and i815 programmer reference manuals but little documentation for the newer chipsets. The closest to documentation would be Intel's open-source Linux drivers, which, while they do show the programming interface of the GMCH, have not much in the way of explanation. That driver supports a whole range of Intel integrated graphics controllers (all the way up to the newest Q965) and if a Win98se "port" of it could be done we may have a solution. However the Linux driver architecture is substantially different, so this is going to be quite a bother...

The Windows 2000 and XP drivers for the 900 series chipsets are WDM drivers; recalling Win98se supports WDM drivers, maybe it would be possible to once again force the driver to work with a little bit of editing. The only problem would be missing APIs from 98se's implementation of WDM

Another method would be to disassemble the default VGA drivers and add the code (obtained from either the Linux or Win2K/XP driver) necessary to handle the 2D functions. This way we should be able to get 2D acceleration, or at the very least, framebuffer mode, working at anything other than 640x480x4.

I have given up on the SuperVGA+ project (writing a generic driver for almost all VESA chipsets) but this project may take off given the fact that the 900-series chipsets are becoming quite popular (in fact mobos with 915G are cheaper than those with the 865G now) and I myself now own a 945GM to experiment on.

Assistance or comments/suggestions from any users here knowledgeable in Win9x driver architecture is welcome.

Hello!

There is another option...
Maybe IBM will buy the source code and open source it:
http://www.scitechsoft.com/news/press/sale_of_snap.html



Or maybe Google will buy it for their GoogleOS ...

Regards, Roman

Like I'd even want to pay anything for that

Their drivers are a bit bloated and have no acceleration support.

I don't really see IBM buying and then opening it...

Currently my best solution would be to use both the open-source Linux driver and the 2K/XP driver to write the whole driver myself. A friend says that device drivers are more straightforward to write once the method of building them has been figured out, as unlike an ordinary app where you have to think about the functionality, a device driver already has a purpose and aim, and you essentially write instructions to interact with the hardware in predefined ways.

Reading the DDK documentation and looking through the VGA driver makes me believe this is so. The display driver just has to export several functions for initialising the hardware, enabling/disabling it, and drawing pixels, bitblts, etc.

The driver inf's for Win2K would probably be the most likely ones to work on Windows 98/ME. The oldest Win2k 915 chipset driver that I see on Intel is version 6.3.0.1007. The oldest Win2k 915 integrated graphics.. version 14.4. Maybe start with these on a 915 board, do some mish-mashing of older inf's with newer driver files, and work your way up?

Also, I can't remember, is WDM support between Win98SE/WinME essentially the same?

Intel provides 2K and XP with a WDM driver that supports all the Intel chipsets from 810 to latest Q965.

Attempting to force-install this on 98se results in BSOD. There are definitely differences between the NT and 9x versions of the driver besides the INFs.

The wdmcheck utility might be useful for displaying unresolved imports, which can be resolved by defining a stub for the kernel mode routines (used to port kernel mode functions from nt to 9x/me).

I noted several inaccuracies in this thread including the one quoted here and wanted to clear them up.... First of all to characterize SNAP as bloated is a gross misrepresentation no matter how you slice it. If you look at the downloadable file on the SciTech website you will see that the package itself is no more than 11.5mb for our largest package - the package contains support for hundreds of chip sets (more than 250). A single accelerated chipset diver can still be delivered via floppy disk. If you look at memory foot print here again SNAP has proven to be amazingly small - though tough to accurately gauge memory usage of a driver from home, I would be amazed if anyone could find a windows driver that has a smaller memory footprint then SNAP, while still offering acceleration DDC, plug-n-play..... (Read not a DFB driver) .

In terms of acceleration our win9x driver for the i945 matched up very well to the OEM driver and in many real world examples was significantly faster.

Where we did experience some bloat was in our optional GUI based control center (based on wxHTML) if memory serves this component required a minimum of 5mb of memory when idle , and required another 5mb when in use (not exactly what we had hoped for when we built it)

SNAP drivers themselves are today running on embedded systems with less than 32mb of total sys memory available (in some DOS cases far less memory) and still offering very "SNAPy" 2D accelerated performance! Infact in one PPC Linux example a SNAP driver for an ATI graphics chip is providing full 2D video acceleration (HW motion comp and scaling) on a PPC chip clocked at less then 350mghz with no floating point processor, 64mb of sys memory and if memory serves 32mb of graphics memory - not a lot of room for bloat here.