The graphics driver became a bit more mature since my last life sign in here. Here is the summary:

5.00.2196.0022

• Bug fix: The mysterious blue screen bug was fixed. Switching from one Gen7LC-display mode directly to another Gen7LC-display mode is now possible.

5.00.2196.0023

• Bug fix: Some invalid clock generator speeds were available.

5.00.2196.0024

• Bug fix: A validity check was incorrect implemented which allowed using too big image buffers.
• Bug fix: The compatibility with some screens was improved (which caused a black screen instead of seeing the payload)
• Bug fix: The graphics circuit "ValleyView" has serious problems with VGA. The support for VGA is now deactivated when handling this graphics circuit. Maybe a better work-around comes somewhen in the future.
• New: the driver now offers Gen7LC-display modes defined by the driver author.

The list of display modes defined by the driver author is generated by iterating over all possible combinations of color resolutions, image refreshing rates, x-resolutions and y-resolutions. The driver iterates over

• 3 color resolutions: 256 colors, 16 bits and 32 bits
• 13 image refreshing rates: 25, 30, 50, 56, 60, 70, 72, 75, 85, 100, 120, 144 and 240 images per second
• 16 x-resolutions: 320; 360; 640; 720; 768; 800; 960; 1,024; 1,280; 1,440; 1,600; 1,920; 2,048; 2,560; 3,200 and 3,840 pixels
• 21 y-resolutions: 200; 240; 350; 400; 480; 576; 600; 768; 900; 960; 1,024; 1,050; 1,080; 1,152; 1,200; 1.440; 1,536; 2,048; 2,160; 2,400 and 3,072 lines

The driver has some limitations at the moment. This is why only about 10,000 of these ~13,000 display modes are valid and exposed to the operating system.

However, this approach already shows one big benefit of the direct communication compared to using the VESA BIOS Extension (VBE) where one can easily be stuck with 5 to 15 display modes.

The driver needs about 290 machine cycles per valid list entry (including the time to read the registry for concealed display modes, which is quite a percentage of these cycles) to generate/write this list. However, the display program of the control panel needs about 190,000 machine cycles per list entry to read the list. When the display program opens (right click on the desktop and then select "properties"), then the programm asks the driver for the list not just once but 4 times. So there is a delay of about 5 seconds to open the program. If this is too long, then the registry can be used to conceal unneeded display modes (see the help file). Fortunately, this "5 seconds"-delay is only in the display program of the control panel and not in the boot time nor when setting up a display mode.

These new versions are a step forward in maturing the Gen7LC support. But there are still some bugs left and some limitations to be lifted.

I don't fully understand this driver technically, but I know your work needs to be noticed more. Do you have any thoughts on putting this topic and driver somewhere more suitable like Google Drive and MSFN forum? I tried to download the driver from ftp server, but some files which have german umlauts in their name are not accessible because UTF-8 is not supported (maybe). MSFN is more familiar with NT-based Windows than VOGONS, and probably has more people who can help with this project.

R1600 wrote on 2023-08-24, 14:47:

... your work needs to be noticed more. Do you have any thoughts on putting this topic and driver somewhere more suitable ...

Well, I can admit, that I'm a horrible publisher:

• The project actually addresses those who use their computer for productive purposes - not gamers. Gamers would be disappointed by the speed Microsoft's framebuff.dll delivers, which has a big impact on the driver's overall speed. But here on Vogons many try to get their games running.
• The project has an Odysee channel but no Youtube channel. Youtube has much more users and Odysee suffers from the Youtubers who automatically mirror their content on Odysee, but don't care about their viewers on Odysee. So on Odysee the supply of content exceeds by far the demand.

But it would be most unfortunate if this project get's lost. There aren't many left who still do serious driver development.

I am not so happy with the idea of spaming the whole internet with this project. But here on Vogons this project did not attract many interested. To be honest, from the feedback I got so far, I am not sure if anyone in here has a real interest in this project at all.

So far, I do not have an account at the MSFN-forum nor on any social media site (except on Odysee). Actually, I would prefer it, if I would not have to do the publishing work myself, but can't afford to hire a publisher.

R1600 wrote on 2023-08-24, 14:47:

I tried to download the driver from ftp server, but some files which have german umlauts in their name are not accessible because UTF-8 is not supported (maybe).

That's a pretty close guess. But it's actually the HTTP-server which has no UTF-8 support and has exactly the problem you mentioned. The FTP server should be fine. If you experienced this problem via FTP, then please let me know which FTP client you used so I can look into this issue.

More bug fixes for the graphics driver:

5.00.2196.0025

• Bug fix: When using the graphics standard "Gen7LC", image buffers bigger than 8 MB are now possible. The first 8 MB are in the graphics circuit; the rest is in the main memory.

5.00.2196.0026

• Bug fix: When using the graphcis standard "VGA", the calculation of the registry value "current mode\x.output unblackend back porch size" was buggy and had a wrong value in some cases.

@Start me up

There is a small community over at MSFN that has interest in seeing more windows 2000 drivers.
Assuming they're your target audience for these drivers.

I'll just throw this out there. The Tandy 2000 loaded it's bios (except for the boot loader obviously) from floppy/hard disk. I am not even going to pretend to be knowledgeable at all of these subjects, but what about loading a bios from some modern removable media. BIOS is just code. Ah but it isn't64 bit code.

This subject is very interesting to me. Maybe when my resume is updated I'll be able to contribute more then just hypotheticals.

Personally my goal is to not have to rely on old h/w to run older apps. There is a good deal of older h/w out there still, NOS, so it doesn't hurt to have an extra box or two around to run the old wares. But it's always better to have it all running in one place.

I like NT, although there is so much in the way of resources these days there seems to be little need to run such a tight, compact operating system. But I still like it. It's still cool in my book.

Start me up wrote on 2023-08-24, 23:31:

That's a pretty close guess. But it's actually the HTTP-server which has no UTF-8 support and has exactly the problem you mentio […]
Show full quote

---

R1600 wrote on 2023-08-24, 14:47:

I tried to download the driver from ftp server, but some files which have german umlauts in their name are not accessible because UTF-8 is not supported (maybe).

That's a pretty close guess. But it's actually the HTTP-server which has no UTF-8 support and has exactly the problem you mentioned. The FTP server should be fine. If you experienced this problem via FTP, then please let me know which FTP client you used so I can look into this issue.

---

Strange. I tried with latest version of FileZila and WinSCP, and both failed. FileZila reported that the server does not support non-ASCII characters. If there's no problem on your side, it's probably because ISO-8859-1 is automatically applied. But that doesn't work for Asians 🙁

R1600 wrote on 2023-08-25, 10:50:

Strange. I tried with latest version of FileZila and WinSCP, and both failed. FileZila reported that the server does not support non-ASCII characters. If there's no problem on your side, it's probably because ISO-8859-1 is automatically applied. But that doesn't work for Asians 🙁

Thank you for reporting. Yes, I think you are right. Btw: It doesn't happen too often that someone gives a bug report this detailed. Anyway, I think I have fixed the bug and the FTP server should have UTF-8 support now. It would be nice, if you could retry.

Now I can access your FTP server, but it would be much better if you add UTF-8 support to HTTP server or offer files via Google Drive. If updating files is annoying, why not try rclone? And as someone above mentioned, there are a few people on the MSFN forums who will recognize the value of your driver. I highly recommend posting this topic on MSFN.

Why promote google drive? Nobody can download anything from there without JS, cookies, and being tracked by google. The FTP link works fine for me in three web browsers that I tried. One of them showed some incorrect characters but it still can access the files.

The future is now, old men. Get with the times and open up a Discord. /s

bakemono wrote on 2023-08-27, 10:18:

Why promote google drive? Nobody can download anything from there without JS, cookies, and being tracked by google. The FTP link works fine for me in three web browsers that I tried. One of them showed some incorrect characters but it still can access the files.

I'm not defending Google's tracking, but I think it's a bit much to make a fuss over JavaScript. Whatever it is, I just want to be able to download the OP's files (in modern UI would be better) within a web browser. Google Drive is just one of examples(MEGA, MediaFire, or whatever). Technically, you accessed link via HTTP, and I still cannot access file via HTTP because of Asia's character encoding system. Not every system supports ISO-8859-1.

No, I used this link ftp://ontheserver.de/entpackt

Verified in wireshark that it was FTP protocol, not HTTP. (And this is on a Japanese PC with Japanese Windows. If that matters.)

R1600 wrote on 2023-08-27, 04:59:

Now I can access your FTP server, but it would be much better if you add UTF-8 support to HTTP server

Thank you for your feedback so far. It improved the accessibility of the files.

Let's try to get UTF-8 support on the HTTP server, so that the HTTP directory listings work, too. Could you test, whether the second setup works, please? It should have UTF-8 support.

1http://ontheserver.de:80
2http://ontheserver.de:81

If it does work and there are no other regressions, then I can make this to become the default setup for the HTTP server.

bakemono wrote on 2023-08-27, 10:18:

Nobody can download anything from [Google Drive] without JS, cookies, and being tracked by google.

I agree: A solution that needs no Javascript, no cookies and has no tracking is better.

I think the work on Gen7LC is finished for now. A few days ago I ordered the next graphics circuit to continue with the next graphics standard.

bakemono wrote on 2023-08-28, 13:12:

No, I used this link ftp://ontheserver.de/entpackt

Verified in wireshark that it was FTP protocol, not HTTP. (And this is on a Japanese PC with Japanese Windows. If that matters.)

Wait what? Firefox and Chromium dropped FTP support a year or two ago. How is this possible...

Start me up wrote on 2023-08-29, 01:19:

Let's try to get UTF-8 support on the HTTP server, so that the HTTP directory listings work, too. Could you test, whether the se […]
Show full quote

Let's try to get UTF-8 support on the HTTP server, so that the HTTP directory listings work, too. Could you test, whether the second setup works, please? It should have UTF-8 support.

Copy code to clipboard

1http://ontheserver.de:80
2http://ontheserver.de:81

If it does work and there are no other regressions, then I can make this to become the default setup for the HTTP server.

I just tried second link, and now I can access to german umlaut filenames in my setup. Great!

R1600 wrote on 2023-08-29, 13:04:

I just tried second link, and now I can access to german umlaut filenames in my setup. Great!

Thank you for testing again. The UTF-8 support is now available for everyone.

5.00.2196.0027

• New: The graphics driver can now detect and announce graphics circuits, which are compatible with the graphics standard "generation 4.0" from Intel Corporation.

Here is a small update for those who are still interested in this Windows 2000 fan project:

The development of the universal graphics driver went forward. The support for the graphics standards

• "generation 3.5" (Pineview; Calistoga/Lakeport/Pine Trail) and
• "generation 7.0 low cost" (Valleyview; Bay Trail)

was completed, at least for now. This means, that the major functional need for these graphics standards is met by being able to drive a lot of displays at their native resolution.

There is also a new video presentation out which covers the new versions of the driver (version 19 to 35), which brought this progress.

There is a low quality version on odysee:

1https://odysee.com/@startmeup

and a medium quality version in the FTP-account and the HTTP-directory listing:

1http://ontheserver.de/Downloads/entpackt/Pr%C3%A4sentationen/004%20-%20der%20universelle%20Grafiktreiber%20f%C3%BCr%20Windows%202000%20-%20Version%2019%20bis%2035/

Feel free to comment.

Start me up wrote on 2023-12-14, 06:05:

Here is a small update for those who are still interested in this Windows 2000 fan project: […]
Show full quote

Here is a small update for those who are still interested in this Windows 2000 fan project:

The development of the universal graphics driver went forward. The support for the graphics standards

• "generation 3.5" (Pineview; Calistoga/Lakeport/Pine Trail) and
• "generation 7.0 low cost" (Valleyview; Bay Trail)

was completed, at least for now. This means, that the major functional need for these graphics standards is met by being able to drive a lot of displays at their native resolution.

preview of presentation 4.png

There is also a new video presentation out which covers the new versions of the driver (version 19 to 35), which brought this progress.

There is a low quality version on odysee:

Copy code to clipboard

1https://odysee.com/@startmeup

and a medium quality version in the FTP-account and the HTTP-directory listing:

Copy code to clipboard

1http://ontheserver.de/Downloads/entpackt/Pr%C3%A4sentationen/004%20-%20der%20universelle%20Grafiktreiber%20f%C3%BCr%20Windows%202000%20-%20Version%2019%20bis%2035/

Feel free to comment.

Any update with USB3/SATA/NVME/ACPI support ?

TheFighterJetDude wrote on 2023-12-22, 19:05:

Any update with USB3/SATA/NVME/ACPI support ?

Well, kind of. Someone from the MSFN forum is currently trying to get some developers together.

1https://msfn.org/board/topic/185942-join-our-community-for-windows-2000-software-and-driver-development-interested-join-us/

We are currently discussing whether we should start with a SATA or a NVMe driver or both.

The USB problem is noted also over there but noone had a bigger interest in giving this problem a priority.

Regarding ACPI: Someone came up with the idea to backport an ACPI driver which works in XP. But I don't think that anyone is really on this, either.

People with some programming experience are very welcome in the discord channel which was set up. Observers with no programming experience are also free to join.

Start me up wrote on 2023-12-22, 23:48:

People with some programming experience are very welcome in the discord channel which was set up. Observers with no programming experience are also free to join.

followed the discord link and got an error page saying it's no longer valid