defuser

Vendor 10DEh NVIDIA Corporation Device 009Dh G70GL [Quadro FX 4500] Command 0007h (I/O Access, Memory Access, BusMaster) Status 0010h (Has Capabilities List, Fast Timing) Revision A1h, Header Type 00h, Bus Latency Timer 00h Self test 00h (Self test not supported) Cache line size 64 Bytes (16 DWords) PCI Class Display, type VGA Subsystem ID 032210DEh Unknown Subsystem Vendor 10DEh NVIDIA Corporation Address 0 is a Memory Address (anywhere in 0-4Gb) : F6000000h Address 1 is a Memory Address (anywhere in 64-bit space, Prefetchable) : C0000000h Address 3 is a Memory Address (anywhere in 64-bit space) : F5000000h Address 5 is an I/O Port : 0000E000h System IRQ 11, INT# A Expansion ROM of 0Kb decoded by this card (Currently disabled) New Capabilities List Present: Power Management Capability, Version 1.1 Does not support low power State D1 or D2 Does not support PME# signalling Current Power State : D0 (Device operational, no power saving) Message Signalled Interrupt Capability MSI is disabled MSI function can generate 64-bit addresses PCI Express Capability, Version 1 Device/Port Type : PCI Express Endpoint Device Unsupported Request Severity is Non-Fatal Non-Fatal Error Detected Unsupported Request Detected Maximum Link speed : 2.5Gb/s Maximum Link Width : x16 Link Port Number : 0 Common Clock Configuration In Use Current Link speed : 2.5Gb/s Current Link Width : x8 Conventional Memory: INT 12h Memory below 1M: 635 KB (00000000 - 0009EC00 : 0009EC00) Extended Memory: INT 15h, AH=88h Memory above 1M: 0 KB INT 15h, AX=E801h Free between 1M and 16M: 0 KB Free above 16M: 0 KB Configured between 1M and 16M: 15360 KB (00100000 - 01000000 : 00F00000) Configured above 16M: 2812928 KB (01000000 - ACB00000 : ABB00000) INT 15h, EAX=0000E820h 0000000000000000 - 000000000009EC00 : 000000000009EC00 1 (Available) 000000000009EC00 - 00000000000A0000 : 0000000000001400 2 (Reserved) 00000000000E0000 - 0000000000100000 : 0000000000020000 2 (Reserved) 0000000000100000 - 0000000020000000 : 000000001FF00000 1 (Available) 0000000020000000 - 00000000ACBF9000 : 000000008CBF9000 2 (Reserved) 00000000ACBF9000 - 00000000ACC00000 : 0000000000007000 4 (ACPI NVS) 00000000ACC00000 - 00000000AD6B2000 : 0000000000AB2000 2 (Reserved) 00000000AD6B2000 - 00000000AD95C000 : 00000000002AA000 2 (Reserved) 00000000AD95C000 - 00000000BD038000 : 000000000F6DC000 2 (Reserved) 00000000BD038000 - 00000000BE024000 : 0000000000FEC000 2 (Reserved) 00000000BE024000 - 00000000BE038000 : 0000000000014000 3 (ACPI Reclaim) 00000000BE038000 - 00000000BE18B000 : 0000000000153000 4 (ACPI NVS) 00000000BE18B000 - 00000000BF7FF000 : 0000000001674000 2 (Reserved) 00000000BF7FF000 - 00000000BF800000 : 0000000000001000 2 (Reserved) 00000000F8000000 - 00000000FC000000 : 0000000004000000 2 (Reserved) 00000000FEC00000 - 00000000FEC01000 : 0000000000001000 2 (Reserved) 00000000FED00000 - 00000000FED04000 : 0000000000004000 2 (Reserved) 00000000FED1C000 - 00000000FED20000 : 0000000000004000 2 (Reserved) 00000000FEE00000 - 00000000FEE01000 : 0000000000001000 2 (Reserved) 00000000FF000000 - 0000000100000000 : 0000000001000000 2 (Reserved) 0000000100000000 - 000000023E000000 : 000000013E000000 1 (Available) Available: Bytes KiB MiB GiB TiB Below 4GiB: 536472576 523899 511.6 0.5 0.0 Above 4GiB: 5335154688 5210112 5088.0 5.0 0.0 Total: 5871627264 5734011 5599.6 5.5 0.0

In general, I flashed this patched BIOS and after that it booted up immediately in XP without any problems, the memory in the system became 512MB less. But in Windows 98, it loaded only in 640x480@16 colors. In Device Manager, it says "This device cannot find any free Memory Range resources to use (Code 12.)". And if you set resources manually in safe mode, it already writes the following "This device is either not present, not working properly, or does not have all the drivers installed. (Code 24.)". Then I updated the driver to version 82.69 and now it always writes " Protection Error. You need to restart your computer". What I've already tried: - add SPLIT8MB in AUTOEXEC.BAT - limit memory to a safe 2GB (as well as up to 512MB) - apply PATCHMEM /A /C: 128 / M /P - delete EMM386.EXE - register EMMExclude=A000-FFFF in SYSTEM.INI Technical information: NVIDIA Quadro FX 4500 [DISPLAY] ** DEVICE: PCI\VEN_10DE&DEV_009D&SUBSYS_032210DE&REV_A1\000800 ** DRIVER: DISPLAY\0001 ** MFG: NVIDIA ** HARDWAREID: PCI\VEN_10DE&DEV_009D&SUBSYS_032210DE&REV_A1 PCI\VEN_10DE&DEV_009D&SUBSYS_032210DE PCI\VEN_10DE&DEV_009D&REV_A1&CC_0300 PCI\VEN_10DE&DEV_009D&CC_030000 PCI\VEN_10DE&DEV_009D&CC_0300 ** COMPATIBLEIDS: PCI\VEN_10DE&DEV_009D&REV_A1 PCI\VEN_10DE&DEV_009D PCI\VEN_10DE&CC_030000 PCI\VEN_10DE&CC_0300 PCI\VEN_10DE PCI\CC_030000 PCI\CC_0300 ** Registry.MatchingDeviceId: PCI\VEN_10DE&DEV_009D ** Registry.Inf: NVAGP.INF:[NV30] ** CLASSGUID: {4d36e968-e325-11ce-bfc1-08002be10318} ** CLASS: DISPLAY ** CAPABILITIES: 00000014 ** Registry.ProviderName: NVIDIA ** Registry.DriverDate: 5-28-2023 ** Registry.DevLoader: *vdd ** Devnode Status: 18006EA6 ** Problem: Devnode Problem = 0000000Ch (NORMAL_CONFLICT) ** Tree Level: 3 MTRRcap Register: 000000FE 0000000000000D0A Variable MTRR Count: 10 Fixed MTRR Supported: TRUE Write-combining (WC) Memory Type Supported: TRUE SMM Memory Range Registers (SMRR) Supported: TRUE MTRRdefType Register: 000002FF 0000000000000C00 Default Cache Type: 00h Uncacheable MTRR Enabled: TRUE Fixed MTRR Enabled: TRUE Reported Processor Physical Address Size (bits): 39 Variable MTRRs - Base, Mask and Decription: 00000200 0000000000000006 0000007E00000800 8G @ 0 / WB 00000202 0000000200000006 0000007FE0000800 512M @ 8G / WB 00000204 0000000220000006 0000007FF0000800 256M @ 8G 512M / WB 00000206 0000000230000006 0000007FF8000800 128M @ 8G 768M / WB 00000208 0000000238000006 0000007FFC000800 64M @ 8G 896M / WB 0000020A 000000023C000006 0000007FFE000800 32M @ 8G 960M / WB 0000020C 00000000C0000000 0000007FC0000800 1G @ 3G / UC 0000020E 0000000000000000 0000000000000000 Not used 00000210 0000000000000000 0000000000000000 Not used 00000212 0000000000000000 0000000000000000 Not used Has anyone ever encountered something like this? While I would not like to roll back the BIOS back, but first try to fix everything that is already there. Any ideas?

Yes, I'm sorry, I was too quick to ask. This, of course, was about getting out of real DOS...

Greetings. I have a video card with a similar design to yours and it looks like I will soon have to do the same procedure... Let me ask you, after the BIOS patch, do you have a normal exit from DOS (Back to WINDOWS) using the "Exit" command? This is a key issue that the NVCORE.VxD patch failed to address. More precisely, it was this patch that broke the exit from DOS, which was tested on the reference 128MB GeForce 5 video card, first with the original NVCORE.VxD, with which the exit from DOS worked fine, and then with the patched NVCORE.VxD, with which the exit from DOS stopped working, all other things being equal. And even fine-tuning MTRR did not give positive results in this issue (But it repeatedly increased the speed of 2D and page scrolling in browsers, as well as the performance of games under DOS). Therefore, there is only one hope left - a BIOS patch.

And also, even though you only have 512MB of memory, PATCHMEM can still be useful. Try.

Patcher9x is not needed for ancient hardware. It is buggy and causes a lot of problems (and was originally developed for VMs running on the latest hardware). Your problem seems to be in ACPI.SYS, which is not supported or works crookedly on anything newer than Intel i865 chipsets. You need to go into safe mode and turn off ACPI through the registry or start the installation again, with a parameter that disables ACPI (Or turn it off in the BIOS, if there is still such an option, but this is unlikely). I don't understand exactly what you are installing? Windows 98 SE or Windows 98? If the latter, you will also need to update NDIS.VxD to version "4.10.2001 QFE", otherwise the system may not boot on a too fast processor in some cases, but you would see the NDIS error on the screen (Although this may just stop the "Patcher"). This is a very large size. You need to fix large disks, such as ESDI_506.PDR, or switch to AHCI mode in the BIOS, if supported (and then use AHCI.PDR from Rudolph R. Loew). Try both options - on different systems, one or the other option may be more or less problematic, or it may work very stably.

On this configuration, this option does not work, as far as I understand:

Original HIMEM.SYS /v Fixed "1. 1_PS_2" /v "DOS=HIGH,UMB" is removed in this case. Only HIMEM.SYS is loaded with the single parameter "/v". HIMEM.SYS itself writes the same thing in both cases:

"PS/2". And above about the original "HIMEM.SYS".

Can you provide reference results of "A20TEST" when it is guaranteed to work correctly, in the same form as presented above? To understand how it should actually be, under normal conditions.

So which correction option is best suited for this case? I retested in combination with the new "A20TEST" variant and only with the "/V" parameter: However, the error when starting WINDOWS has not appeared again yet.

So he writes the following: and WINDOWS starts normally (without errors). The old "A20TEST" (1996) gives the same as above. And here is the new one, the link to which you gave: But I launched the original HIMEM.SYS (from 11.05.1998), as you wrote, only with the parameter "/V". Although usually (Beyond the current experiment) I also use additionally "/MACHINE:AT" (With it, the ScanDIsk disk check at the WINDOWS boot stage is MUCH faster), as well as the parameter "/NUMHANDLES=64".

For the sake of interest, I checked all this on an Intel H81: 0. 0_FIXED WARNING: The A20 Line was already enabled 1. 1_PS_2 Windows protection error. You need to restart your computer. 2. 2__A20CONTROL_OFF WARNING: The A20 Line was already enabled 2+1. 2_1_PREFERRED WARNING: The A20 Line was already enabled 3. 3__ALWAYS_ON Installed A20 handler number 19. 3+1. 3_1 Windows protection error. You need to restart your computer. (What's surprising is that the error occurs exactly once every other time.). А20TEST.EXE (From the "Undocumented PC" floppy disk from 1996) in any case it gives the following: A20 CONTROL TEST v2.00 (c) 1994, 1996 FVG ННННННННННННННННННННННННННННННННННННННННННННННННННННННННННННННН Tests the A20 gate state and keyboard controller status and the ability of the controller to change the A20 gate. When A20 is enabled, memory is accessable above 1MB. Otherwise, when A20 is disabled, the system acts like an 8088. ДДДДДДДДДДДДДДДДДДДДДДДД Test Results ДДДДДДДДДДДДДДДДДДДДДДДДД Verified ДДД Keyboard Controller ДДД A20 Test A20 State Returned State D0 Value ДДДДДДДДДДДДДДДДДДДД ДДДДДДДДД ДДДДДДДДДДДДДД ДДДДДДДД Initial State enabled disabled 49h D1 Command disable enabled disabled 49h D1 Command enable enabled disabled 49h DD Command disable enabled disabled 49h DF Command enable enabled disabled 49h

I connect to the question. I also faced a similar problem and made all sorts of attempts to solve it. Namely, two audio devices were missing from Multimedia (One on the PCI bus, and the second on the USB). On the new (Test) installation, they were naturally there (the USB device appeared even on the virtual machine). But on the old one, transferred from the previous PC - they did not appear there (And on the virtual machine, too). I've tried everything. The only thing I was able to find out for sure then was that the root of this problem is in the registry files (SYSTEM.DAT; USER.DAT). I don't remember exactly, but I think only the first one had a real impact. And yes, I was never able to beat this problem back then, trying to find the key differences. I had to perform a clean install and apply all the fixes, patches, settings again, and transfer a lot of things from the previous OS installation. But it was easier than I had feared. And it didn't take so long - I managed the main one in a day and about a week more for the final polishing, on the spot, in the process of work. Although not without surprises (It's like walking all the way through a rake again). But now everything is behind us, all the devices are now in place, everything is working relatively smoothly, as planned, and, of course, a working backup has been made.

Everything worked out. Used "LocalLoadHigh=1" + EMM386.EXE (with parameters). Now the game also starts with IO.SYS version 3.0. Returned even the old (more productive) video card. There is now enough memory, and the game starts, but only with the LH parameter (for example: "lh game.exe"). Thank you.

A small note. I checked the operation of the integrated AHCI controller and the BIOS provides a choice of three different modes of operation: "RAID Mode", "AHCI Mode" and "IDE Mode". I compared how the upper memory is consumed when choosing one of them. And here's what came out of it: "RAID Mode": V і A000h to C000h 128K VGA Video RAM і A000h to B000h 64.0K VGA Graphics і B000h to B800h 32.0K MDA Text і B800h to C000h 32.0K CGA Text/Graphics R і C000h to D800h 96K Unknown ROM і Copyright (C) 1996-2006 NVIDIA Corp. - і D800h to E800h 64K <nothing> R і E800h to EE00h 24K Unknown ROM і No copyright notice. First 84 bytes are: і і 15 00 24 00 09 00 E4 02 FF FF 37 E8 07 00 ..$.......7... і 00 00 0B 00 00 01 08 00 60 01 06 00 A0 01 ........`..... і FF FF 00 00 59 F8 00 F0 80 FC 5F 74 05 2E ....Y....._t.. і FF 2E 20 00 3C 00 75 06 BB 02 13 E9 3E 01 .. .<.u.....>. і 3C 40 75 21 80 FB 00 75 04 B0 80 EB 09 80 <@u!...u...... і FB 01 0F 85 25 01 B0 88 E8 CC 01 8A C8 80 ....%......... - і EE00h to F000h 8K <nothing> R і F000h to 0000h 64K System ROM і ROM BIOS: AMI і BIOS Date: 04/13/12 "AHCI Mode": V і A000h to C000h 128K VGA Video RAM і A000h to B000h 64.0K VGA Graphics і B000h to B800h 32.0K MDA Text і B800h to C000h 32.0K CGA Text/Graphics R і C000h to CE00h 56K Unknown ROM і Copyright (C) 1996-2006 NVIDIA Corp. - і CE00h to E800h 104K <nothing> R і E800h to EE00h 24K Unknown ROM і No copyright notice. First 84 bytes are: і і 15 00 24 00 09 00 E4 02 FF FF 37 E8 07 00 ..$.......7... і 00 00 0B 00 00 01 08 00 60 01 06 00 A0 01 ........`..... і FF FF 00 00 59 F8 00 F0 80 FC 5F 74 05 2E ....Y....._t.. і FF 2E 20 00 3C 00 75 06 BB 02 13 E9 3E 01 .. .<.u.....>. і 3C 40 75 21 80 FB 00 75 04 B0 80 EB 09 80 <@u!...u...... і FB 01 0F 85 25 01 B0 88 E8 CC 01 8A C8 80 ....%......... - і EE00h to F000h 8K <nothing> R і F000h to 0000h 64K System ROM і ROM BIOS: AMI і BIOS Date: 04/13/12 "IDE Mode": V і A000h to C000h 128K VGA Video RAM і A000h to B000h 64.0K VGA Graphics і B000h to B800h 32.0K MDA Text і B800h to C000h 32.0K CGA Text/Graphics R і C000h to CE00h 56K Unknown ROM і Copyright (C) 1996-2006 NVIDIA Corp. - і CE00h to E800h 104K <nothing> R і E800h to EA00h 8K Unknown ROM і No copyright notice. First 84 bytes are: і і 15 00 24 00 09 00 E4 02 FF FF 37 E8 07 00 ..$.......7... і 00 00 0B 00 00 01 08 00 60 01 06 00 A0 01 ........`..... і FF FF 00 00 59 F8 00 F0 80 FC 5F 74 05 2E ....Y....._t.. і FF 2E 20 00 3C 00 75 06 BB 02 13 E9 3E 01 .. .<.u.....>. і 3C 40 75 21 80 FB 00 75 04 B0 80 EB 09 80 <@u!...u...... і FB 01 0F 85 25 01 B0 88 E8 CC 01 8A C8 80 ....%......... - і EA00h to F000h 24K <nothing> R і F000h to 0000h 64K System ROM і ROM BIOS: AMI і BIOS Date: 04/13/12 In total, they remain available for user tasks under these conditions when using the built-in AHCI controller (Including +32.0K MDA): - In "RAID Mode" - 104КБ upper memory free; - In "AHCI Mode" - 144КБ upper memory free; - In "IDE Mode" - 160KB upper memory free;

In general, yes, the problem was aggravated by a video card that was too late (I wonder if it is possible to somehow edit its vBIOS in such a way that it would take up a little less address space?). Replaced the video card. I also cleaned it up a little. And now it turned out like this (If you don't ship anything there): It is necessary to take up all this space now in some optimal way... I prefer to play this particular game under WINDOWS (There is already a separate MS-DOS and there are games there, there are no problems, but TBPLus is not needed there). And here we need to somehow make it so that not only our patient fits in this upper memory, but also the regular "EMS Page Frame" (96 KB approximately after loading takes up a sum), so that it would also be there (The game requires it just too)! What is the best way to do this? For example, this is how they managed to take up all the space in DOSBOX (Where the dots are displayed in my screenshot, they just have a PageFrame loaded there)? By the way, while I was testing all this a little, I noticed that in a virtual machine (Virtual PC 5.2) in no version 9x "EMS Page Frame" is loaded (Even in release 95 and the latest updated SE)! That is, games there under WINDOWS on the enable EMS tab are not available. The "1MB" card there, of course, does not look very good under WINDOWS (Although it is better than in some other virtual machines) - literally one small continuous window of 64KB in size, the rest is all smeared I don't understand how. But to load this frame, you probably need a little more (According to my estimates, really, from 72 to 96 KB). So, Windows ME under the same identical conditions manages to load the "Page Frame" into the same small window without any problems and does it quite correctly (Although the "1MB" card itself is almost identical). So, it turns out that in Windows ME this mechanism was really somewhat improved? If so, can this improvement be ported to Windows 98 somehow as well? Or does this idea not make much sense?

LocalLoadHigh=1 is generally initially spelled out. But by itself, it does not affect anything. Apparently, it needs something else to work correctly, the same UMBPCI, for example (But, I hope, not slow EMM386.EXE?). I'm trying to figure out what is missing at the minimum. After all, there is still about 64KB in any case should remain free to support EMS under WINDOWS (Without it, the game simply does not start). I'm also trying to find some substitute for EMS, which would preferably eat 32KB or less (Or even work somehow differently, but could transfer control to WINDOWS).

Given "XMS2EMS.SYS", at least, works correctly on my hardware (Unlike 386MAX, which causes a hang when booting). However, this is at the DOS stage. But when you start WINDOWS, at the very final stage, right before the desktop appears, the following message appears on a black background: and then the computer shuts itself down. After a bit of searching on the Internet, I was able to find out that this problem may be caused by the lack of "XMS2EMS.SYS" support for the Global EMM Import Specification (GEMMIS), which is required for transferring control to WINDOWS. Here, for example, something similar is discussed (About the need to add this function to a similar product): https://github.com/Baron-von-Riedesel/Jemm/issues/5 it also provides links to GEMMIS source code sources and examples of open source products where it has already been successfully implemented (for example, DOSBOX). As part of the package " xms2ems.zip "contains its source code in the file "xms2ems.asm". You can download it, for example, here: https://www.minuszerodegrees.net/5170/ram/5170_extended_memory_use.htm or here: http://files.mpoli.fi/unpacked/software/programm/asm/dosutil.zip/ Do you think it will be possible to add support for GEMMIS to XMS2EMS so that you can boot with it on WINDOWS?

I suspect that this hardware is eating up so much space (video card, first of all). By the fact that under normal conditions, for example, it should be something like this: in this case, I would be able to simultaneously place EMS and HIMEM in the upper memory... Well, in general, okay, the option with different configurations (Game\Working), I quite like it too. Moreover, so far only one such game has come across, for which a rollback was needed IO.SYS, and all the others work. In other words, the situation is quite rare, exceptional, and potentially solvable. If there are no simple obvious paths or updates for IO.SYS, in principle, and so it will do. Thank you all.

Also, on a tip from MERCURY127, I started digging to the side HIMEM.SYS and I found another solution like this: https://www.mdgx.com/umb.htm#HIR And with it, it really turns out to free up quite a lot of memory and memory. IO.SYS from TBPPlus3 becomes less pronounced: but now there is not enough "EMS" memory. As it turned out, this HIRAM+UMBPCI eats up exactly the same area the amount of memory that WINDOWS normally allocated to maintain EMS. Here it is (Marked "PP"): and after applying HIRAM+UMBPCI, this area is already dealing with them: Accordingly, Windows cannot find the required space (a contiguous free chunk). So EMS it becomes no longer available and the game starts swearing again (and of course it doesn't work). I don't succeed place both at the same time..

Thank you for your answer, but what can actually be done in this situation? Rudolph's Readme doesn't say much about it a lot has been written: Yes, so far we have to survive just like that. When I roll back IO.SYS up to version 1.3 the game works no complaints. I haven't ventured to work with large disks with this legacy IO yet... This is the configuration purely temporary and only for running this one problematic game. For normal operation, I return IO.SYS version 3.0 is back in place. It's not very convenient, but at least it works.

Hi. I started the game and it ran out of memory. After looking at what the memory is occupied with, I found that HIMEM.SYS eats up 46KB, while on a clean system (On a virtual machine) about 1KB. I went to look at the difference and found that the culprit of the problem is IO.SYS. As it turned out, this one IO.SYS from the TERABYTE PLUS PACKAGE version 3.0. I have this version 3.0 package installed for a very long time to support large disks and it works otherwise quite stable all this time. I checked previous versions of TERABYTE PLUS PACKAGE and it turned out like this: IO.SYS from TERABYTE PLUS PACKAGE versions 1.0 to 1.3 (Inclusive). IO.SYS from TERABYTE PLUS PACKAGE versions 2.0 to 3.0 (Inclusive). What do you recommend to do in this case? I see a very impressive list of changes there. Can I roll it back IO.SYS before version 1.3? Or are there any other ways to solve the problem? Thank you.

Everything would be fine, but for some reason it constantly loads the processor and periodically accesses the disk: This is rather questionable behavior. Is it possible to use the MultiCore9x SDK to allow the guest OS to manage all CPU cores except the first one (and at the same time redirect all 64-bit memory above 4GB there)? And are there any guest add-ons for this VM at all (Seamless transition, shared folders, dragging files back and forth)? But this module "KQEMU" seems to still not work for me here. I can't even imagine what he still lacks for a full-fledged job.

Greetings. Please tell me how to make sure that the "KQEMU" module has actually started and is functioning correctly? I try the standard WINDOWS command "net start kqemu" under Windows 98 and it returns that " Error 2185: The service name is invalid. Make sure you are specifying a valid service name, and then try again.". In the QemuManager menu, the "Uninstall KQEMU Accelerator" item remains INACTIVE after installing this module (In XP, it becomes active). I also selected "KQEMU-Full Acceleration" in the settings. But I still don't feel any difference in the speed of the guest OS. It feels like it's not working... Maybe I didn't take something into account or do something wrong? Do you have this module running on Windows 98?