defuser

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.

Hello. Is there a standard way to assign a different default name? I changed the name several times in the disk properties, but it is not saved and each time from a cold start it is assigned the original one. Is it hardwired somewhere deep in the driver code? I tried changing everything I found in the registry, but also to no avail. Another question concerns access from DOS to a previously created disk under WINDOWS. Do you need a separate 16-bit client?

Quote from Readme: I checked and noticed the following. The contents of the RamDisk are preserved even after rebooting to XP and back. But if the PC is turned off (Even for a short time), the information is permanently deleted. That is, within the framework of a working session, you can safely make reboots, including rebooting in XP and returning back, and the information on the RamDisk remains. However, this does not work if RAMDRV4M is used on top of RAMDSK64 (which may be necessary if you need to copy something to RamDisk already at the DOS stage). It only works when using the pure RAMDRV4M variant. But it still works well. My checks showed complete data safety (based on the results of checking checksums) even after returning from WinXP. In XP itself, of course, PAE\PSE is disabled (Not used).

A very interesting decision. It seems that this is the first full-fledged PSE ramdisk in history that installs and works directly under WINDOWS! No more downloading of HIMEMEX (by Rudolph R. Loew). HIMEMEX itself, by the way, is not full-fledged: the PREALLOCATION function stated in the Readme does not work in it, as a result of which you have to use them together with BURNMEM (the first, in fact, for the RamDisk; the second for limiting memory). And, as it turned out during operation, the order in which they are launched (Together with HIMEM) in CONFIG.SYS is crucial. The most stable sequence turned out to be HIMEMEX > BURNMEM > HIMEM. This solved most of the problems associated with it. Now, thanks to RAMDRV4M, in the future it will be possible to completely exclude HIMEMEX from this scheme. But first you need to make sure that RAMDRV4M works as well, does not cause problems and is compatible with all the programs you use, and this will take time. Also, knowing a little history of the development of RAMDSK64 and its performance, depending on the newness of the hardware and, apparently, the BIOS version, the question also arises of the compatibility of RAMDRV4M with more promising hardware (In particular, based on LGA1700, in combination with the CREGFIX necessary there to fix VCACHE). It would be nice if someone (who already uses such hardware) checked this right away. I'm starting testing on HASWELL. And I’ll check the speed first: initial results with RAMDSK64: result with RAMDRV4M installed on top of RAMDSK64: clean result with RAMDRV4M: Amazing! Which, by the way, is quite remarkable, when I deleted the HIMEMEX boot line from CONFIG.SYS, rebooted and saw the drive letter "G:", instead of "M:", I expected to see it, of course, empty. As usually happens with RAMDSK64 after a reboot (If you don’t copy anything to it at the DOS stage or immediately after starting WINDOWS). But when I opened it, I was quite surprised: all the files and folders that were on the "M:" RamDisk before the reboot remained (On "G:")! Even the folder "CrystalDiskMark22_9x" was already there! It turns out that this data was stored somewhere during the reboot? But where? Is it really in RAM? I definitely didn’t have enough free space on the "C:" drive to store a backup of the appropriate size there. Simply fantastic. Well, okay, I will now test the pure version (Without RAMDSK64) under real conditions of use with regular programs. This may take a long time. Thank you. PS: How can I change the drive letter? I want to change it back to "M:", my software is copied when loading to "M:" and the shortcuts also lead to "M:" and all sorts of "TEMP", "Temporary Internet Files" are also registered there. I looked in the Readme and didn't see it. I opened the disk properties - there is a gray "G:" there. I understand that you need to install LetterAssigner? PSS: There was also a funny incident. When I installed it (Directly on top of RAMDSK64, without disconnecting the existing disk) - at first it seemed that the system was frozen (Everything froze and nothing could be done) and, after waiting a little, I was already reaching for the reboot button, when suddenly everything came to life and a message appeared on a blue background "Windows The volume that was removed had open files on it. Next time please check first to see if the volume can really be removed. Press any key to continue." Nevertheless, even in this situation, everything went well and the system continued to work normally after that, and the installed RAMDRV4M appeared in the device manager.

Yes, thank you, I tried it and this version really works well (Showing itself much better in some usage scenarios). However, there is a problem with Direct3D \ DirectDraw in the 8X.XX driver versions (including 82.69) still remain. NVOPENGL.DLL from version 82.16, it was not compatible with the 77.72 driver (Applications crash with the error "abnormal program termination").

Has anyone already tried to build a hybrid version of the driver that combines the advantages of version 77.72 and version 82.69? I tested version 82.69 some time ago and found good support for OpenGL 2.0.1, while Direct3D applications worked crookedly, ran slowly, or even crashed at startup (the same NFS2000 for example). DirectDraw performance also suffered. While version 77.72 lacks all these disadvantages, Direct3D\DirectDraw works fully, but OpenGL version 2.0.0 and its performance is lower. In addition, NVOPENGL.DLL most often, it was necessary to roll back to version 71.84, to achieve the greatest stability and compatibility, in combination with PCI-E cards. But this was already disliked by some new programs that require a newer OpenGL (From version 82.69). Based on all these observations, it is quite natural to build a single version of the driver based on 82.69, consisting of several versions, which will take into account and correct all these shortcomings. Or somehow fix Direct3D in 82.69. Has anyone already tried to do something like this, does it make sense to start it at all (Or none of this will work and everything has been tried for a long time)? What other general practical recommendations do you have for PCI-e GeForce 6\7 Series users today?

And yes, some later programs also use this path to place their data folders: C:\WINDOWS\Local Settings\Application Data\ Check just in case your program expects to see the necessary data in the folder located there.

If you like Internet Explorer 4.0 and don't want to update it (or don't want to radically update 98FE while maintaining the most original state), but you need an application compatibility level close to Windows 98 SE + KeX (With up-to-date experimental updates), providing support for, for example, VLC 2\3, Mypal29\FF52 and so on, you can install in a clean Windows 98 FE, at least Windows Installer (InstMsiA.exe), as well as DirectX 7 (Optional). You will only need to update the following system files:: At the same time, the functionality of IE4 is fully preserved. You can also install IE5\5.5 while maintaining IE4 (The system will have TWO browsers at the same time). This is a standard feature provided by Microsoft, eliminated starting with IE6 and higher. To do this, select the appropriate item in the IE 5.X installer: However, the first option seemed more life-saving to me. I use it myself. This is basic. The rest should be viewed locally (each specific program may have its own additional wishlist).

I see. If this is a really general problem and affects other relevant desktop solutions, it is probably not worth making changes until a full-fledged functional fix is found.

Thank you. I tried it. In Firefox 9, the CPU usage is 15-25%. In Opera 12.02, only 7-8%, after the video is fully loaded. Sometimes it takes a few seconds to load or doesn't fully load. In both cases, only HTML5 seems to be used. Switching to HD doesn't work. Opera also requires disguising itself as Firefox or opening the same page in Firefox in parallel (I can't imagine how this can be related, but there is a fact). It's not very stable. In Mypal 29, it works noticeably better and even switches to HD (But not everyone in this browser has sound, so it's less relevant). All that's missing is a button for explicitly switching to FlashPlayer, as well as adjusting the playback speed and quality selection. Otherwise good.

So everything is more or less clear. That is, with this option, the ability to write is saved and thus it works correctly. Questions are removed (This was not entirely obvious to me from the description). Thank you for this valuable clarification.

I have such a question: there in the source it says - " noticed that the cause of the page fault was a write to a non-writeable page while executing in ring 0.". What does it mean? Under "normal conditions", it should have made this recording successfully? What is this entry, how important is it, and what does it affect? Is it possible, instead of eliminating the symptoms, to allow the necessary recording to be performed (If my assumption is correct), by removing write protection to this location? What can be the concomitant consequences of the fact that this record cannot be executed? Even if my concerns are unfounded, I would still like to see a more detailed explanation - what and where it wants to write down, why it can't do it, and what indirect consequences it may have. For clarity, let's say if we take a computer based on 440BX or similar, fully 9x compatible, does this recording succeed there?

When I searched, I didn't find anything easier than LICEcap v1.1, which allows you to write to a regular GIF file with a given refresh rate. It is able to display the passage of time, as well as mouse button clicks: It works on Windows 98 and higher. Sometimes, however, it was still necessary to convert the resulting GIF to MP4 to add to the video hosting service. This was required in cases where the GIF size exceeded the size allowed for adding to the photo hosting site. There are quite a few free converters that allow you to do this, both directly in 9x and in a VM with a later OS, but I made do with free online services. Thank you, this tool really looks great, light, simple and convenient, I will definitely try it out in action.

Is it possible to adapt this WIN.COM patch method to Windows 98 FE? I just tried "fdapm poweroff" from MS-DOS and the machine shut down gracefully. The method of shutting down from Windows with the WINOFF16.EXE program also works, but the method with WIN.COM does not work. Even LOGO=0 (Always used) and BootGui=0 (Disabled for the duration of this test) do not help. I renamed WIN.ENG from the "ACPIOFF4.zip" archive to WIN.COM and put it in the WINDOWS folder (Together with: FDAPM.COM; WINEXIT.BAT; WINOFF16.EXE). Did not help. WINOFF16.EXE shuts down the computer for a long time, but it is guaranteed. As an alternative, is it possible to bind WINOFF16.EXE to "Start=>Shut Down...=>Shut Down=>OK" so that instead of the standard procedure, WINOFF16.EXE will be executed whenever the computer is shut down in the normal way?

I will add to the above from myself. Currently on Windows 98 FE with KernelEx (with the latest changes) and some updates, the following versions work for me: 086i; 1111; 206; 210; 224; 228; 300; 3018. All versions from the PortableApps website (Because different versions have conflicting and mismatched settings, and it's better that they don't intersect). Also VLC doesn't like long paths and folder names with spaces (Which only affects online video streaming). Versions below < 2XX perform better on older hardware, but do not support modern HTTPS video streaming (the old one is unlikely to be seen anymore). Versions 1111 and higher do not play files from NTFS disks. Version 206 supports YouTube and Twitch.tv links, but this requires updating the root certificates, as well as the twitch.luac and youtube.luac files, and on more modern hardware, also turn off AES-NI in the BIOS (Otherwise, VLC fails when you try to open a link to YouTube or Twitch). Versions 210 to 3018 are only suitable for local playback. Everything that is written about VLC at the link above on the WIKI is correct.

This really works for me. For several years I could not fully solve the problem of correctly migrating Windows 98 from an old computer with functional ACPI (Conroe865PE + x6800) to a newer one (Q87 + 4790k), by transferring (Clone) the old IDE PATA HDD to a new AHCI SATA SSD where ACPI is used by default and every time after detecting devices and rebooting, a blue screen fell out. At first, I managed to modify the unofficial Intel INF from LoneCrusader: http://lonecrusader.x10host.com/intel_inf.html in which I deleted the line regarding ACPI. As a result, an unknown device was constantly hanging in the device manager, designated as "%*PNP0C08.DeviceDesc%" under a yellow question mark, and the PCI bus had to be added separately, by hand. This in detail caused some discomfort and attracted attention every time, although it allowed the use of Windows. I was looking for just such a way that does not require reinstalling an already configured Windows. But only recently found it. Used the following values: "IgnorePnPBIOS"="0" "ACPIOption"=dword:00000002 As a result, ACPI disappears completely! Correctly. Finally. Naturally, I redownloaded INTELINF_9.4.0.1017_98SE.ZIP and used it in its original version. And all the devices were correctly detected and installed (Except, perhaps, "PCI Communication Device"). The PCI bus was picked up again and also completely automatically! What didn't exist before. Thus, the functionality of these registry settings under Windows 98 RTM (Gold) is fully confirmed. And my question is this: is it possible to somehow configure or replace the ACPI Table even before Windows starts, so that ACPI still works correctly? To make Windows shut down automatically without pressing a button (This action is still required). Instead of ACPI, this function can theoretically be performed by APM, but it is not at all in Device Manager and it is not even detected when detecting devices. It is not seen among the system ones even when trying to add a device manually (Indicating the path to the INF folder). Is it possible to force install APM (Or fix ACPI)? Support for APM is declared by the manufacturer, but for some reason it is not detected and does not work. I have to turn off the PC with the button (After the inscription "It`s now safe to turn off your computer."). Whereas on the old hardware it turns off automatically by itself. Perhaps here it needs to be somehow previously activated from under DOS (or by means of RU.EFI at the BIOS stage)? Thank you.

I have already thought about the option of purchasing a separate sound card myself, especially for Firefox 52.9 and Mypal 29.3.0, so that there would be sound in the browser. But there was no reliable confirmation. Now, thanks to you, it is there. It's not even difficult to make a shortcut that will switch the sound card by default before launching the browser and return everything as it was after. And the output from this sound card can be combined with the main one (If desired). A complicated scheme, yes, but I don't see any other way out (Except to use the browser in a virtual machine, which negatively affects the YouTube frame rate). But for the successful implementation of this, you need to know exactly which USB card model you should purchase and which drivers to install on it. So thank you for confirming that such a scheme will, in principle, work under Windows 98 and it will be even better if you write with which sound card and which drivers you managed to do it (So that it would be clear what to buy). Thanks. As for YouTube's performance. Firstly, as mentioned above, links can be searched through a search engine, you can also use an alternative muzzle (Links to them can be found on the Internet). In principle, you can also watch there, they do not lag so much and are even less demanding on the browser version (You need to choose the right one among them). Also, you can open the link instead of: https://www.youtube.com/watch?v=XXXXXXXXXXX https://www.youtube.com/embed/XXXXXXXXXXX then only the video itself will open. You can also look in the direction of extensions that change UserAgent. The iPad version is more lightweight, but at the same time it is complete. Mobile version also. But these are all crutches, it's about viewing the YouTube site itself "as is", and nothing can be done here, because browser engines are outdated. If only somehow run Mypal68 (For XP initially which) or MiniChrome from Kafan for Windows XP (Based on Chromium 87). Their engines are better compatible with modern YouTube.

This is very good news! Since there was no sound with any proven drivers under Windows 98 yet. I even tried an unofficial WDM driver for Sound Blaster 16 ISA (From Windows ME, where there is sound with it). Would it be difficult for you to write with which USB headset you have achieved such success (the name of the model at least) and which drivers you put on it (You can specify a link to them or add here)?

And yet, starting from which processor can the problem manifest itself in one way or another? The Readme for the patch says "CPUs - AMD ZEN 2+, Intel Tiger Lake+" and these are apparently the versions from which the problem begins to manifest itself too clearly. However, the problem itself was described back in 2015, respectively, the problem was already on the hardware of that time. Does this mean that the problem is also present on 2015 hardware, but to a lesser degree? Accordingly, the patch should be applied there as well? However, just for testing purposes, I tried to apply the patch on Windows 98 and it didn't seem to work:

Firefox 14. Sound support when using the VxD driver was discontinued in one of the nightly builds between versions 14 and 15. Among all the nightly builds of version 14 that I checked, I came across both supporting sound, and where there is no sound anymore. In version 15, it is no longer completely (Although I did not thoroughly check the nightly assemblies 15 - there are too many of them).