rloew

The Kernel fix only improves handling of Files from 2GiB to 4GiB, and only does it partially. I have written a better Patch but it still is limited to 4GiB. The API and the internal structures do not support more than 4GiB so a major change to the Kernel would be required to handle more than 4GiB.

That Video card appears to be problematical. There is already a thread about it. "Best Graphics Card With Win98se Drivers" It is in the Main List of the Forum. The last post was August 09.

There are PCI-E Video Cards that work with Windows 9x such as the 7100 GS. Some 512MB AGP Video Cards work with Windows 9x such as the 6200. I've created Patches that allow Windows 9x to work with 4GiB of RAM. They are quite stable. Dencorso maintains a thread listing people who routinely use Windows 9x on Computers with more than 1GiB of RAM. Many EPIA motherboards have a bug that can corrupt large Hard Drives. There may be others. I have had problems with some of the SATA Drivers for Windows 9x. I have a Patch that works with nearly all SATA Controllers.

May be this can also help for Win98. I haven't seen the Drive for sale locally and I'm not sure if Windows 9x USB Drivers can handle it, but the format is compatable with my Large Sector Patches. It appears from the Identification Data on the Drive inside it, that it uses 512 Byte Logical Sectors and requires more than 32-Bits to address. I do have Patches for supporting more than 32-Bit Addressing but with less capability.

The Windows 95 Speed limitation has been resolved. Look for FIX95CPU on this Forum.

I run Win98 on a dual core desktop. It's a pity to leave one core unused under Win98. I would be very interested in a program, like taskassign or S.A.D Dualcore Tuner under WinXP, to manually set under Win98 programs to run on specific cores. Maybe some day it will be possible. Those Programs only work because Windows XP already supports Multi-Core. They just tell XP which one to use. Other than a major rewrite of the Windows 98 API, you need to Write to and Compile Programs with my SDK or equivalent to use Multi-Core. All System Calls have to be performed on the Base Core. I have a Gateway Call that facilitates doing this.

That is most interesting. As you you may have read I've linked to Mandelbulb 3D in the post just above and in case it pick your fancy to investigate the feasability for other apps, I can think of Incendia http://www.incendia.net/ which is another awesome free 3D fractal application of which I have the single core version installed and which runs fine on stock 98/ME despite it is labeled as an XP/Vista software only. The free 3D renderer Kerkythea http://www.kerkythea.net/joomla/ featuring cutting edge physically accurate unbiased rendering engines, which runs only with KernelEx would certainly also be a candidate in my book. And I am sure there is no lack of audio/video transcoders running on 98/ME that are multicore capable on NT systems, I'll have a look at that eventually. I've also mentioned above the old versions of flagship Adobe products which I believe are multi processor capable but I am unsure whether they are capable of using multiple cores on current hardware when run on NT systems. What I said still stands. The applications you described may run on Windows 9X and may be multi-core capable, but not at the same time, or not the same version. I haven't worked with NT or XP so I'm not sure how they provide multi-core support. In any case, the issues I described before remain as there could any number of System Calls within the various cores Threads that would need to be hooked.

Is this something that is eventually going to evolve into a driver that allows the use of multiple cores by programs not written with your SDK? No. Explicit code is needed for inter-core communication so the Program needs to be coded for it. And no hope either a specially written dll could intercept, translate and redirect calls from already existing multicore capable applications to and back from your driver? I had some hopes I could look for an FX-60 to replace my FX-55 as to boost rendering speed of a few cool multicore capable apps I am using but I understand chances are slim this will be possible. Anyway all you are doing is very interesting. Cheers. B) I wasn't aware of any multi-core applications that run under Windows 9X. In any case, they probably would use a proprietary interface so I would probably have to Patch them on a case by case basis.

Is this something that is eventually going to evolve into a driver that allows the use of multiple cores by programs not written with your SDK? No. Explicit code is needed for inter-core communication so the Program needs to be coded for it. Same problem. Same problem, plus I don't think the OS uses that much CPU time. I was able to split DOS 7 between two cores, with Interrupts handled in the Base Core and everything else in another. There was no noticeable speed improvement. Not much simpler. Once you implement multiprocessor scheduling and inter-core communication, there isn't much left to do.

I don't know about any Russians working on it, but RLoew sure is/was! I have written a Multicore SDK so people can write Programs using Multiple Cores. A Demo is available on my Website.

The SATA Patch I normally distribute is designed only for Native (IDE) Mode SATA Controllers. I have other versions for the other three modes. These can be used for Cards that do not have Windows 98 Drivers such as the JMicron Cards. I did not suggest my SATA Patch, when this thread started, because the above quote implies that the Computer was freezing during bootup long before the Drivers would be loaded.

The 7100 GS PCI-E Card, which works with the 77.72 Driver, does not have the shut-down issue. It is only 128MB though. What about the "Restart in MS-DOS mode" issue? I never used the "Restart in MS-DOS mode", so I knew nothing about it. I tried it on my 7100 GS System. It switches to MS-DOS without problem. It does not switch back. I have had problems restarting Windows, usually after Graphics Settings Changes, on many Computers. I tried "Restart in MS-DOS mode" on my 8400 GS System, with STD VGA Driver. It only restarted once in three tries. In all other cases it froze loading VMCPD.

The 7100 GS PCI-E Card, which works with the 77.72 Driver, does not have the shut-down issue. It is only 128MB though.

I'm not so sure. According to my > 1 GiB list, Multibooter uses a: It's possible that 256 MiB x 512 MiB be the main problem, but if not, if 77.72 worked with a 7800, there is a chance that it'll also work with 7950 (despite your negative result with the 7200). And, then, there are both the 81.92 and the 82.16 as further alternatives, besides the BFG custom driver for the 7800 Cyker mentioned some posts above. @Cyker: could you please give us a link to that driver? I wasn't implying that the 77.72 Driver doesn't work with 7xxx Cards, I use it with a 7100 PCI-E Card. I was implying that it probably won't work with Dave-H's 7950, based on his two failed attempts to use it. 512MB could be a problem, at least with the 7xxx Cards, with the 77.72 Driver.

The simplest way to add the ID is as follows: 1. Locate the two lines in NVAGP.INF that contain the number 221. 2. Duplicate each line, putting the copied line immediately after the original line. 3. In the two copied lines, replace the three instances of 0221 with 02E4 4. Replace the number 6200 with 7950. 5. Save the File. Replacing those four files effectively downversioned the Driver. Further experiments did not find any advantage to doing this over just using the older version. I suspect that 77.72 simply will not work. It didn't work with a 7200 GS. I don't think the problem is related to RAM as using the PATCHMEM Options, or reducing the available RAM, didn't help solve any problems with any NVIDIA Card.

There is at least one other. When you posted a request to the Forum last year for experiences with 512MB cards, someone contacted me who had succeeded with a 7600. This is news to me. Never heard of it. I have some faint suspicions about what can it be due to, but I'll wait for RLoew's opinion, before saying anything. This may be related to the Low 16MB Memory issue that I added the /M Option for, but Dave-H may already be using it.

jaclaz I tried it in my ECS 6100SM-M Computer with a NVidia 8400 Video Card. When I opened a DOS Box, I got a blank screen just like the previous Version. Disabling Hardware Acceleration and setting 640x480 did not help.

I'm not sure that a "raid" driver is needed, as opposed to just a win-98 driver for the SATA controller. SATA and RAID are two different things. The SATA Drivers I have seen all have been described as RAID Drivers. There is no need to actually implement a RAID configuration. In addition, if the BIOS is not set to RAID mode, the ESDI_506.PDR Driver is likely to take control of the SATA Drive(s). The ESDI_506.PDR Driver requires my SATA Patch and Large Hard Drive Patch to properly support SATA Drives.

Windows 98 will not have a problem with large SATA Drives only if a RAID Driver is available for the SATA Controller. Otherwise you will need the Large Hard Drive Patch and most likely my SATA Patch as well.

I have an Assembler that requires DOS 6.2 and quite a few Programs Compiled by it. A few of them also require DOS 6.2. I saw no reason to limit myself to 8GiB of shared space, per Drive, when a simple Patch made it unnecessary. The Patch has been in my Development System since the beginning of the Millennium. In addition to being able to create the necessary custom Partition configuration, my RFDISK Partitioning Tool has a DOS 6.2 Compatable Boot Function that allows Multi-Booting DOS 6.2 and DOS 7/Windows from the same Paritition sharing all resources.

The 8GiB Limitation is due to the lack of LBA Support, not the FAT16 Limitation. I wrote a Patch and Drive Overlay that remaps a larger Hard Drive into 8GB Virtual Drives. Using a fairly complex Partitioning scheme I was able to support more than 8GiB in both DOS 6.2 and Windows 98.

Not really, but you get immediate feedback when you do. You probably need the /M Option. MaxPhysPage and MaxFileCache cannot fix this issue. You probably don't need the SPLIT8MB.EXE Program as the /M Option usually is enough. @Dave-H I added the /A Option to fix a potential problem I saw with ATI Cards. Since it appears to be of no value with these NVidia Cards I would not use it. It alters Memory Allocation so it might cause exhaustion of the Shared Memory Arena. It also may cause a problem if it moves a Memory Allocation that must be in the System Area. This is why it is an Option, not a built in feature.

@lesmond74 Did the Patch help?

Yes, it does sound as if patchmem is perhaps not doing what it should do (I assume that you are using one of the correct versions.) The VMM BSODs you're getting now can happen in my experience if you've got too much RAM and/or a very large registry. Patchmem has cured all that for me. I'm sure you've tried this, but when it hangs on the restart, have you tried restarting in Safe Mode? I have known Windows 98 hang on reboots after installs, but Safe Mode starts OK and does the registry updates etc., and it will then boot OK in normal mode. Worth a try if you haven't tried that. The only other thing I'd now try before reinstalling Windows is to go to the system\vmm32 folder (in DOS), and restore the backups that should be there of your vcache.vxd and vmm.vxd files. These should have been made by patchmem and have a *.bak extension. Then boot into Safe Mode with the original graphics card installed and use the system configuration editor to limit the memory to 512MB. With a bit of luck the system should then boot into normal mode again and you can reinstall patchmem and take it from there. Patchmem, and it's /A and /M options, doesn't help or hinder operation of the NVidia Drivers. The BSOD's and Windows Protection Errors are probably caused by the Driver being incompatable or misconfigured. I have seen this occur during ny experiments with various Cards. You can uninstall Patchmem simply by running it again. It runs from DOS. If you uninstall it, I doubt you will be able to run Safe Mode. You will have to limit RAM by setting MaxPhysPage and MaxFileCache in the SYSTEM.INI File from DOS. You will not be able to reach the System Configuration Editor. I would recommemd not using the /A Option as it probably does not help and may cause unwanted side effects.

I have not yet created an Installer for my IO.SYS Patch. I have attached a simple Patcher that can be used to do the Patch. Edit: This Patch is obsolete. It has been removed.