defuser

Most likely, some volume is reserved by the built-in graphics. This value can usually be changed in the BIOS. I also have 8GB, but the ramdisk size is different: However, no values in the registry had to be changed. It immediately took up all the available space and was automatically formatted in FAT32. Perhaps, in your case, the crucial role was played by changing the amount of RAM from 6GB to 8GB.

I suspect that your problem may be related to the wrong file name. The patch works correctly, even if I execute it like this: D:\PTCHNVSZ>PATCHNVC 1 NVCORE.VXD or even so: D:\PTCHNVSZ>PATCHNVC 1 2 The driver versions that I successfully checked with this patch are 82.69, 81.98 and 77.72. I applied the patch to these files under Windows XP (From there, it's easy to immediately replace the driver files in the target system, so as not to do it under DOS). The patch worked correctly in all cases and there were no more 512MB issues with these fixed versions. Some time ago, I just tested all three versions with a 512MB card.

In the menu settings of the monitor itself, it would also be worth looking for energy-saving functions.

Hmm, then I don't even know, this is some strange, very exotic mistake. I've never seen anything like it. You can then try turning off DDC. And also in the properties of the screen, try to turn off the power saving functions (Maybe they don't work correctly) by removing all three checkboxes and then performing a reboot:

And if you just go in with the usual resolution (Which definitely works for you) and run this shortcut by clicking the mouse, the resolution should change to 1440x900. Does it change so much for you? If so, then there shouldn't be any problems in theory. You just need to add this shortcut to autorun.

Hi. I also have the pleasure of encountering the problem of a black screen when logging in. To deal with this, I'm still using a workaround (temporary solution). Added a shortcut to "C:\WINDOWS\Start Menu\Programs\StartUp" that reads as follows: C:\WINDOWS\RUNDLL32.EXE NvCpl.dll,dtcfg setmode 1 1920 1080 32 144 And it works. After logging in, the permission specified in the shortcut is automatically applied and the image appears. In your case, replace the last digits with "1440 900 32 60" or " 1440 900 32 75 "(try this or that). And replace the number "1" at the beginning with the number "2", if the monitor is connected to your second number. At the same time, the specified modes must also be entered in the register: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Display\0000\MODES\8\1440,900] @="60" "ModeRefreshRateList"="60,75" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Display\0000\MODES\16\1440,900] @="60" "ModeRefreshRateList"="60,75" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Display\0000\MODES\32\1440,900] @="60" "ModeRefreshRateList"="60,75" And here you may need to replace "0000" with some value of your own (0000, 0001, 0002, and so on), corresponding to the serial number of the video card you are using. Look up this number at this path in the registry. You can also initially modify the installation INF for the driver by adding these modes there and reinstalling. The disadvantage of this solution is that the "StartUp" folder is processed AFTER logging in. Therefore, if you do not have automatic login configured and you need to enter your username and password manually every time - you will have to do it blindly. I'm not sure, though, if there is an option in 9x to execute a command BEFORE logging in. If this is the case, then in principle you can try to avoid this problem. You can view everything that your monitor supports in EDID: https://raw.githubusercontent.com/linuxhw/EDID/master/Digital/Dell/DELF00A/B10E0A4F3801 Everything in the "Standard Timings:" and "Detailed Timing Descriptors:" sections should be added to the registry or initially registered in INF. Since you are using a modified driver, also check if you have DDC enabled: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Display\0000\DEFAULT] "DDC"="1"

A bit offtopic, but for the sake of fairness, I also checked what would happen if a full-fledged CRT monitor (based on Mitsubishi DiamondTronNF) was connected under the same conditions. What it will look like. And here's what came out of it: VGA NV34 with CRT: 320x200 => 640x400@71 Aspect 360x200 => 640x400@71 Aspect 320x240 => 640x480@72 Aspect 360x240 => 640x480@60 Aspect 320x350 => 640x400@70 Aspect 360x350 => 640x400@71 Aspect 320x400 => 640x400@72 Aspect 360x400 => 640x400@71 Aspect 320x480 => 640x480@60 Aspect 360x480 => 640x480@60 Aspect 640x400 => 640x400@72 Aspect 640x480 => 640x480@72 Aspect 800x600 => 800x600@72 Aspect 1024x768 => 1024x768@72 Aspect 1280x1024 => 1280x1024@72 Aspect As you can see, the number of playable modes immediately increased. Moreover, in each case, the aspect ratio is now correct (Which is achieved due to more subtle settings of the monitor itself, which, as it turned out, allow significantly more than the LCD. For example, completely arbitrarily narrow-expand any image horizontally and vertically, regardless of each other). And another thing that immediately caught my eye was that, unlike the LCD, the lubrication was completely lost when driving. Three-dimensional space moves like something real behind glass. There was no such effect on the LCD, and with any settings and connection methods, there was always a barely noticeable smudge when strafing near a wall or any object, which causes noticeable damage to realism. But nevertheless, returning directly to the topic, I managed to find out that this problem has already been encountered and tried to solve it with a hardware DVI cable mod (Which in general is almost the same as I have already done, only without flashing the modified EDID directly to the monitor itself). They also tried to modify the BIOS, but these are all half-measures. This is not flexible, difficult, and requires significant intervention. Therefore, it is difficult to consider all these solutions as full-fledged and easily accessible to everyone. I would still like to find ways to make do with purely software tools.

I didn't have to do anything on the 98FE - the network was always configured automatically (Connecting to the router by wire), without user input. But about TCPIPOptimizer is quite fair. Out of the box, the maximum speed was about 512KB, but it was also about the same on the 98SE. After the fix, the download speed of torrents becomes like in XP. True, I have a full proprietary driver package from Intel for the network card. It automatically installs drivers and pulls up all the necessary network system files (and, apparently, missing components), asks for the 98FE distribution. It also appears to be performing the configuration. The only thing is that the user is given a choice of which of the drivers included in the package should be used: - Enchanced mode (32 bit and 16 bit) NDIS driver - Real mode (16 bit) NDIS driver - Real mode (16 bit) ODI driver By default, the first one. And it usually works on compatible hardware, with a few exceptions. And if you have problems, you can switch to the second option, and then to the third (This depends on the overall curvature of the BIOS and available resources, interrupts, and so on). I've tested all three options and they all work well. You also have in the adapter settings (In the network components, in one of the lines "Realtek 8139...", in its properties, there should also be about the same choice). I can say that it was the first option (By default) that turned out to be the most capricious, in terms of compatibility with the new hardware (I had to dance a lot with tambourines to make it work fully), while the second and third worked flawlessly right away (Although they ate quite a lot of DOS memory, which they could not work out correctly some other large programs from auto-loading). Therefore, in the future, I had to make the first option work (Which does not consume DOS memory at all and works best, providing more fine-tuning of the network adapter). However, in everything else for the entire time of their use, there were no complaints (the Internet worked almost the same). I won't say anything for 95, because I don't know, I didn't have any cases. But it should also have such a choice: Try switching over (You will need to insert the CD into the drive and reboot).

Thank you for the detailed explanation. I also managed to find out that this patched version crashes when trying to download to Mega.nz not only under Windows 9x\Me, but also on pure Windows XP SP2. The drop occurs exactly in the same place. However, there the problem is successfully solved by installing the update "kb959426" with the parameter "/b:SP2QFE", which actually updates only one file in the system - "KERNEL32.DLL" from version "5.1.2600.2180 (xpsp_sp2_rtm. 040803-2158)" (SP2, August 18, 2004), to version " 5.1.2600.3541 (xpsp_sp2_qfe. 090321-1324)" (SP2 QFE, dated March 21, 2009). After that, it downloads normally (I note that the "RaiseException" is also fixed here, since for the purity of the experiment, the same browser build is actually used as under Win98). It turns out that there are some corrections in KERNEL32.DLL they potentially solve our problem as well. It is worth noting that some later programs were compiled by too new compilers and do not work at all without this fix. At the time of the release of this fix, Windows 98 was already removed from support (so it could not receive it in a timely manner). So this issue is obviously a bit beyond the scope of 9x\Me.

Opera 9 also opens up something else, it is ideal for reading off-line MHT pages and archived old sites and simple forums (And it is also very convenient for downloading files, as it has a good download manager, much more convenient than in any modern Firefox or Chrome). Sometimes, in order to reach the site, you need to use an online proxy (This is due to the lack of TLS or switch to HTTP, if supported). Opera 9 does not require KernelEx.

Unfortunately, modern browsers running on Windows 98 don't work without KernelEx. As for KernelEx, schwups has already described everything quite correctly (see above). I have one of the assemblies working like this (According to the instructions from this topic): At least it allows you to open this forum, expanded assets on GitHub, and generally display most sites fairly correctly. But when you try to download something from Mega.nz it crashes at the very last moment (At least on my 98FE right now). Maybe on ME everything is different, I haven't checked it yet, because I haven't had time yet). For these or other reasons, or if you simply do not want to use KernelEx, there is another alternative option that does not require the presence of KernlEx - this is using Virtual PC 5.1-5.2 (Patched 5.2 is faster than anyone else, supports up to 2GB of RAM on guest VMs and is best suited for this application). The fact is that I have only one working PC used at one time and I use, among others, this option also under Windows 98, when you need a modern browser, and I don't want to reboot to another OS (XP+) (So as not to interrupt the current work in another OS): There are no more problems here and everything works correctly. An important caveat is that the processor must support SSE3 (Unfortunately, modern browsers require it), as well as enough memory (So that at least 1GB can be allocated for the needs of the guest OS). During a working session, the VM can be paused or even saved state, so that if necessary, in a matter of seconds, you can restore the guest VM at any time, with browsers, sites in them, and other programs already open inside (I just set a low priority through Process Explorer and it sits in the background and does not interfere). For faster swapping and generally accessing the disk subsystem, you can also use RamDisk64 for the needs of the guest OS. Purely as an option.

Try checking just in case in XP on the same computer, if possible. If there is no problem there, you will have to search in more depth for what the problem might be. 98FE itself is hardly directly related to this problem. You can also switch to PIO mode and change the settings for the drive in the BIOS. Usually, there are different options for xDMA, 32-bit mode, and others. Go through all of them. Also check whether the jumpers are installed correctly on the CD drive itself. Third-party patches and drivers are often used for the disk subsystem as a whole under Win9x. I don't know what effect this might have on CD drives or whether ESDI_506\AHCI drivers are associated with it at all, but it's possible that everything and some exotic errors are possible (especially for early devices). So you can still check on the original clean system (Excluding all drives larger than 128GB). PS: I looked at it now and yes, the AHCI driver is directly related to the DVD-ROM drive, which I now have under 98FE. Before that, there was an old PC with an ESDI_506 driver from Rudolph and another drive. The problems you write about were not observed in both cases. If only the CD itself is damaged\dirty and poorly readable. But this is also evident in XP. Therefore, it is worth checking to exclude hardware problems, at least. PSS: The fact that you have a different behavior under DOS, just the same, hints at the drivers... It is also possible to oxidize the contacts on the memory strips if the computer has been idle for a long time.

It's clear. It turns out that there are several possible scenarios at once. Older vBIOS can understand PTB EDID values, such as those that correspond exclusively to GTF. But don't quite understand CVT, CVT-RB and CVT-RBv2 (Specified in the EDID for DVI \ HDMI of a modern monitor). Therefore, the BIOS chooses something from the standard values when it suddenly encounters an unfamiliar "CVT", and even at 16:9. Hence, 1024x768 (apparently GTF) is forced. Another option is that 1024x768 can simultaneously be a certain " vBIOS Default "and it is always reset to it when it cannot set the requested"CVT". This can be easily checked, but you will need to modify the EDID again. Replacing 1600x900_CVT with something not quite standard, something like 800x600_GTF. The old vBIOS should understand this if it really accesses this block (PTB). And instead of 1024x768 at the input, if everything is really so, it should immediately become 800x600. Otherwise, this mechanism does not work at all in NV34 (not implemented yet\Disabled by default\Disabled for this particular monitor\Works differently than expected). Well, accordingly, the resulting option may be just the same in the fact that the old vBIOS may not read this block at all and just choose something from the standard values at once. But then again, why is only one single value always used? There are also a lot of them (There is, by the way, and 1280x1024@75hz, why not choose it, for example?). Judging by this behavior, it seems to me that it still uses internal values from vBIOS (Choosing only one of them). And what it starts from then, choosing this "only correct" value, if not from EDID, remains a mystery. I also looked a little bit at UniVBE on NV34 (So far only superficially, it is quite buggy and it has two different recommended versions, the behavior of which is slightly different, as well as their glitches. Therefore, all the following observations are only preliminary). With DVI allows you to still change the frequency up to 75hz at 1024x768, but only if the game itself is selected exactly 1024x768. When you select any other modes, the input to the monitor remains as before 1024x768@60hz. Also such an option. It's just a coincidence that the game has such a display mode. Some games can't even exceed 800x600_Vesa2 (or even even less), which means they're all out of whack? Well, the limit of 75hz is clearly not hardware. But on the G70, of course, this does not work at all, because the game does not support 1920x1080 or even 1600x900 (Which UniVBE or vBIOS chooses). Accordingly, it cannot be selected in the game. And if you wind up even just 60HZ at the same 1024x768 or 800x600 and select it in the game, it immediately writes that there is no signal (That is, it tries to do something there, but it clearly breaks off about something and flies out of the range). I will dig up this effect in more detail. Notably, UniVBE itself acts similarly to VBIOS in both cases, setting hard-coded 1024x768 for NV34 and 1920x1080\1600x900 (depending on the EDID) for G70. That is, it does not bring anything new in this regard. Presumably, if you set EDID 1024x768 as preferred (PTB), then the G70 will be able to work similarly to NV34. But this solution, again, is not perfect, for the same reasons. Along the way, I also managed to find out that data from the EDID is read every time the video mode is changed in the game. Thus, on the fly, in principle, it would be possible to change the preferred mode and refresh rate so that the video card would actually use it. But this requires a powerful software tool that allows you to modify EDID data on the fly (something like "EDID override for DOS"). Or a deep revision of UniVBE could also be a good solution to quite a few similar problems, because, among other things, it also added new modes to the game (Which were not originally available), and also includes support for VBE 3.0 (Where it is not yet\no longer yet), although it actually turns on not everywhere (at least as far as the refresh rate is concerned) and usually doesn't work on anything higher than NV3x (at least on VGA. On DVI, as you can see, too, a positive result has not yet been achieved). I also checked "Aspect". The actual aspect ratio (If measured with a measuring tape) of the 1024x768 video mode under DOS, embedded in 1600x900 (Which the video card outputs) and applied to it by the "Aspect" monitor, is 4:3 (400x300 millimeters physically). Of course, when in Windows, in the same framework, the size of 400x300 millimeters, 1600x900 remains embedded - this does not look natural. But this can be easily corrected even in several possible ways (by setting the video driver zoom, changing the refresh rate to a different one than used under DOS, or by setting the monitor itself). So this is just not a serious problem here (Just an annoying flaw).

A small correction. I just checked the whole thing again and no, it really goes out fine in DOS. It's just that for some reason the USB keyboard doesn't work there and therefore nothing can be done. It looks like a hang, but in fact it is not a hang. You can add the program to DOSSTART.BAT and it will run successfully after exiting DOS. It seems to me that the USB driver captures the keyboard under Windows and does not want to give back control of the CSM (Which works before Windows starts). Something like that. However, this is more than enough to perform the specified check. I set the monitor zoom mode in the driver (the third option), added Quake to DOSSTART. BAT, and exited in DOS. Quake started. But the input of the monitor still receives 1600x900@72hz (Registered by me in the EDID, at the moment, in the "Preferred Timing Block" section). The same mode is applied to the monitor both in pure MS-DOS 6.22 and in the DOS window of Windows 98. Regardless of what is installed on the desktop. And by the way, the" wrong " proportions (Typical for 4: 3, stretched by 16:9) they are saved for this mode and only for it (If you specify a different one in the EDID, it will be different). Apparently, due to the fact that at an early stage of loading, the monitor ALREADY works with this video mode and applies this "wrong" scaling to the "correct" video modes of early DOS embedded in it, and this is apparently remembered somewhere. They've made a lot of sense out there... Just as planned, I checked the NV34 again and compared it with what the G70 has. The first value is what is selected in the game; the second value is what actually goes to the monitor input. "Aspect" - indicates that there is an active option to enable aspect ratio support in the monitor menu. Underlined - playable modes (No lags. Frame synchronization works). In all cases - UniRefresh set to 72hz; Quake 1; MTRR LFB WC. VGA NV34: 320x200 => 720x400@70 360x200 => 720x400@70 320x240 => 848x480@72 Aspect 360x240 => 640x480@60 Aspect 320x350 => 640x350@70 360x350 => 640x350@70 320x400 => Out of range 360x400 => 720x400@70 320x480 => 640x480@60 Aspect 360x480 => 640x480@60 Aspect 640x400 => Out of range 640x480 => 848x480@72 Aspect 800x600 => 800x600@72 Aspect 1024x768 => 1024x768@72 Aspect 1280x1024 => 1280x1024@72 Aspect VGA G70: all the same, except: 320x240 => 640x480@60 Aspect 320x400 => 720x400@70 640x400 => 720x400@70 640x480 => 640x480@60 Aspect 800x600 => 800x600@60 Aspect 1024x768 => 1024x768@60 Aspect 1280x1024 => 1280x1024@60 Aspect DVI: NV34 (Default EDID) - all modes (except 1280) => 1024x768@60hz Aspect NV34 (Modified EDID) - all modes (except 1280) => 1024x768@60hz Aspect G70 (Default EDID) - all modes => 1920x1080@60hz G70 (Modified EDID) - all modes (except 1280) => 1600x900@72hz Aspect As for the "Aspect" mode, in fact, with it, the standard 4:3 modes stretched at 16:9 seem to look, oddly enough, approximately correct. But NV34 in DVI, for some reason, not only ignores UniRefresh, but also what the monitor itself requires from it. Perhaps this is just the case when the value is hardcoded in the BIOS (Apparently, ATI does about the same), or it takes this value from some alternative location.

At the moment, I can change the update rate under DOS via DVI connection in only one way - by changing the EDID and flashing it to the monitor. But this method does not seem ideal to me, for the simple reason that it is somewhat tedious to flash the EDID for each DOS program that needs its own frequency. Isn't there a simpler, programmatic way for DOS to change the frequency in any way (Programmatically redefining the EDID under DOS would be a perfectly suitable solution if it existed). By the way, are there any tools for flashing the monitor's EDID under DOS that use the i2c bus and support 256-byte EDID images?

It thus scales 1600x900 under DOS (And in the DOS window of Windows), in the case when it is entered in the standard 4:3 (For example, 1024x768). And after completing the full-screen DOS application and returning to Windows, these "incorrect" proportions are preserved for 1600x900 installed on the desktop (Texts and shortcuts are narrowed, and black bars remain at the edges). At the same time, from a "clean slate" under Windows, the monitor does not allow you to set the "Aspect" mode (Other options are available besides this). For this zoom mode to become available again, something must be written in 1600x900 under DOS. It looks very confusing. Most likely, this still corresponds to some interaction specification. Somehow, the monitor under DOS determines the parameters and the ratio of the entered resolution. But this is not the right behavior. It is necessary that the video card outputs, for example, 800x600, as it is (As it is selected in the application), as it happens with a VGA connection. UniRefresh + Quake 1. What other apps can I try for this purpose? The output in DOS does not work for me (It exits and freezes). Only a separate MS-DOS 6.22 (Multiboot menu of Windows 98) works, in which I test all this. The DOS window also works under Windows 98 (Also used). Running DOS received with "BootGui=0". As well as DOS, located on the OEM CD of Windows 98. Everywhere the picture is almost identical. The scaling settings, in turn, apply to the DOS window of Windows 98. But only the first two options work (Enter in the center or Stretch). The third option (Passing native permission) doesn't work. For pure MS-DOS 6.22, the tool mentioned above (In the sixth message) is used: http://rayer.g6.cz/programm/nvsc.zip It also allows you to use only the first two options (Fit or Stretch). At the same time, under any DOS, the above method of scaling the monitor is always used, determined by the entered resolution. The monitor input is always supplied with what is specified in the monitor's EDID (including the refresh rate). And so it happens. I try changing the refresh rate as usual using UniRefresh, but it doesn't work for DVI connectivity. Only for VGA (and even then, not on all VBE 3 compatible nVidia video cards).

VBE 3.0 support is generally available. But in the case of DVI, this is not enough. We need something else. Or something interferes with full-fledged work (What exactly?). This generally exists and works fine over a VGA connection. At least in combination with some VBE 3.0 compatible nVidia-based cards, such as NV30, NV31\NV34 (Only some vBIOS implementations actually allow this capability) , and NV38, from the ones I've tested. For the first three, the UniRefresh utility is suitable, and for NV38, the patched UniVBE is suitable. However, in none of these cases is it possible to change the refresh rate exactly when DVI is connected (Always remains 60hz). As for the G70, which I'm tormenting at the moment. Using a DVI connection under DOS, it always remains 60hz by default (Or another value that is explicitly specified in the monitor's EDID (In the Preferred Timing Block)). And it doesn't change to anything else with the help of these utilities. Alas! As specified in this EDID block, it remains under DOS in all cases (and in the DOS window of Windows 98, too). I should probably try switching back to NV34 (where VBE 3.0 is guaranteed to work via a VGA connection) and think carefully about why this doesn't happen with DVI... What else can I try to do? Here by the way there is a link to this: "Bit 11 Refresh rate control Select. If set to 1, use usеr specified CRTC values for refresh rate, otherwise use BIOS default refresh rate." Maybe somewhere you need to switch to 1 by hand? This is via RU.EXE is it changing or is it being changed in vBIOS? If the former, how do I get to this place? I would like to see what the G70 value is now.

I suggest, for the convenience of research, that for the time being we put out of brackets everything that concerns scaling (We will return to this if anything later). How do I resolve the issue with the refresh rate? Having decided at least for the beginning of this issue, you can move on. This is more important in the context of application compatibility. A simple example is that the game requires setting 72hz, instead of 60hz (by default), so that it works correctly under DOS. For another game, 75hz is good. What should I do if I connect DVI? What other options are there?

Moreover, even the monitor scales native 1600x900 approximately exactly as it is drawn on this preview, if you select "Aspect" in the settings of the monitor itself. Thanks, but it doesn't help.

Hi. The question is a bit different. For clarity, I will now try to explain first with an example of how this works in Windows. And then we can move back to DOS. So, in the nVidia settings, we have the ability to adjust the zoom (Different options), let's look at the first three of them: DVI connection. On the desktop, we now have 1600x900. - when you select the first option (Display adapter scaling), it turns out that the input to the monitor is actually 1920x1080 (1600x900 scaled by means of the video card to 1920x1080); - when you select the second option (Centered output), it turns out that the input to the monitor is actually 1920x1080 (1600x900 inscribed in 1920x1080 in the center, using the video card, with black stripes on the edges); - when you select the third option (Monitor Scaling), it turns out that the input to the monitor is actually 1600x900 (1600x900 as it is, scaled by the monitor's tools as set in the settings of the monitor itself). Now we go back to DOS and see at the input to the monitor 1920x1080@60Hz (The first or second option, depending on the settings in nvscaler). How do we get the third option here? What would be the input to the monitor actually served what the software requires? The second part of the question is how to change the screen refresh rate under DOS, with a DVI connection? For comparison, we connect via VGA, go to DOS and see-just the third option (Honest 720x400@70hz is fed to the monitor input). On DVI it is necessary as well that would be. How do I do this? Here's the question.

The monitor scales what the video card gives you. And if it gives 1600x900 (In which 800x600 is scaled, by means of the video card), then the monitor works with it as with 1600x900, offering options available for this resolution for further scaling (Emulation 17", 19", 4:3, for example, and so on). Nah, well, it's not like that at all... We may also want to change the refresh rate (and not just change the resolution\disable zooming). How will the monitor handle this? I didn't find anything about this for DVI (There are solutions for VGA, they are tested and work. Such as UniRefresh, UniVBE, VBEHZ), but for DVI, the frequency specified in the monitor's EDID (Preferred Timing Mode) is always used, at least for nVidia. I haven't found any utility that allows you to switch refresh rates (For DVI) yet. There is another idea here - to make several versions of EDID, prescribing in each your preferred video mode and refresh rate (So that you can choose your own for each case). But how to re-shoot EDID under DOS? Where is it actually stored in memory (so that it can be replaced and reinitialized)? Of course, outside the monitor. After all, it comes from the monitor to the computer and is stored somewhere in a volatile part of the memory. I will later try to test one hypothesis, whether it is even possible in principle to initialize (And force to use) another EDID in one day, without rebooting the PC (So far over the wire, with the actual transfer of another EDID). If the experiment is successful , the possibility of redefining the EDID under DOS in memory may theoretically exist (which is at least somewhat encouraging). PS: I have already found information about the existence of hardware solutions that allow you to replace the EDID. But for now, I would like to try to limit myself exclusively to software tools (After all, with VGA it is possible to do this. Why all of a sudden such difficulties with DVI?). ___________ Checked it out. And it really can work that way. Loading any compatible VBIOS image file under DOS (Using RamBios\VGABios) causes the video card to read the EDID in a new way (While RamBios\VGABios, along with the image, can be unloaded immediately after that, so as not to take up memory). It remains to find a way to replace the EDID data sent by the monitor with your own (custom) ones, and then you can load any custom EDID under DOS (With the necessary video modes and update frequencies). There are no other software solutions to the problem yet. Tested on GeForce PCX 5900 (PCI-E x16).

Yes, all these modes work fine (including VESA), but all of them are forcibly scaled by the video card to native under DOS, if connected via DVI. Via VGA, all modes (VESA, at least) are displayed "as is", as set by the software. I would like to do the same for DVI connection. Yes, that's right. When connecting an nVidia video card via DVI, from the moment the PC is turned on, the video mode specified in the monitor's EDID ("Detailed Data" -> "Preferred Timing Block") is set and what resolution and frequency are specified in this block, these will be used in the future under DOS (And in the DOS window of Windows 98, too). And all other modes that the DOS software requests are forcibly scaled to this previously set resolution (and frequency). What you need to specify in this EDID block will happen. When the video driver under Windows 98 is included in the game, other (Extended) EDID blocks (which can also contain other video modes) are also taken into account, which allows you to set custom permissions that the monitor can accept natively (As is), if they are listed in these blocks. Otherwise, you are forced to scale to the native video mode of the same or the nearest supported video mode specified in these extended EDID blocks. The highest resolution specified in these blocks (CEA Extension) is considered the native monitor resolution for the nVidia video driver under Windows 98. Here the question remains, why do DOS ignore the standard modes listed in the main EDID section ("Standard Data" - > "Established Timings" + "Standard Timings") and immediately switch to "Detailed Data"? This is also the most basic thing, and it should be taken into account first of all. I haven't checked yet, but I suspect that this may be due to the flag set under "Feature Support" -> "Preferred Timing Mode" (Preferred Timing Mode includes the Native Pixel Format and Preferred Refresh Rate of the Display Device). I'll have to try turning it off. PS: When creating this topic, I was just hoping that maybe someone knows some low-level DOS tool that allows: - adjust EDID data in memory. - manage the DVI connection in real time (changing, for example, the refresh rate). - enable / disable forced scaling by the video adapter. On the last point, there is indeed such a tool, but it works a little differently than expected. Namely, the video mode remains the same (For example, 1600x900), set according to the EDID at the start of the PC (As described above), only 800x600 scaled to it (For example) are obtained in the center or from the edge, instead of stretching (By default) completely. That's all the management. This is a bit different.

Greetings. Faced with a problem related to DVI connection. It appears both in pure MS-DOS 6.22 and in the DOS window of Windows 98. I used different nVidia graphics cards and everywhere the picture is almost identical. Namely, when I set any resolution and refresh rate (640x480; 800x600; 1024x768), it is reset to native for my monitor, determined by the EDID for the DVI port. Monitor, any selected input resolution defines as 1600x900@60hz. Naturally, I would like to put something else. For example, 800x600@72hz. but the input is still the same 1600x900@60hz. When I connect via VGA, everything works correctly. What resolution and frequency I set - this is displayed. As far as I understand, the nVidia video card scales any outgoing resolution to native, if connected via DVI. Is it possible to somehow disable forced scaling under DOS\9x for DVI connection or somehow explicitly set the required mode?

Yes, the Quadro FX 4500 (G70) works acceptably with 512MB of video memory on board, at least with ForceWare 77.72 drivers (and higher), but only after installing a special patch. For ForceWare 8X drivers.XX you will need the "PTCHNVSZ" package (By Rudolph R. Loew). With this package, you can fix the driver and/or the videobios so that it works correctly with this volume. It may also be necessary in other cases, as it contains several related fixes (FIXINTR, FIXEOI, Patch PCI.VxD) and other things that may be useful in some other cases (for more information, see MANUAL.TXT). For the most trouble-free 9x compatible ForceWare 77.72 driver, you can use a different patch (Created by analogy with "PCHNVSZ", but suitable for the 77.72 version of the driver): http://windows98.xf.cz/index.htm#NV7722PATCHED I use a combination of these two options - "FIXEOI" and "PATCHOPT" from the "PCHNVSZ" package + the corrected NVCORE.VxD (From the link above), together with the ForceWare 77.72 driver (The latest version with which D3D\DirectDraw still works without problems). And also nvOpenGl.DLL from version 71.84 (As newer ones caused problems in OpenGL). And MTRR correction (Without which the speed of some indicators in 2D and under DOS on PCI-E cards is extremely low). For G71 PCI-E, you will need at least ForceWare 8X. XX (With which there are a lot of still unresolved problems, in particular, with D3D\DDRAW). 77.72 doesn't have these issues yet.

Nothing is necessary, I already understood how to do it. Thanks for the tip. The reason is quite obvious - the name is long and the last letters of the name are still not visible: I just wanted to make the name a little shorter. RamDrive for example fits: I have only one RamDisk on the system, so it's hard to confuse anything.