dencorso

Yes. That's what one should do. Threads merged. Resulting thread moved. @milan777: do *not* do that again! Consider yourself warned.

Great finding, wsxedcrfv!

@RLoew: I hadn't paid attention to that critical detail. You're right, for sure. I see from the pic that the present 6241 SATA BIOS is v. 4.31 I suggest a BIOS downgrade: either to v. 2.31 (for the 6420, so not 100% guaranteed to work); it is available in the same package that I offered a link to in an earlier post, and the right file to use would be 6420R230.rom... or, an even better choice is here (for BIOS downgrade only, see NOTE, below), the relevant file being 6421Vxxx.rom, which is 6241 SATA BIOS v. 1.20. Of course, it's highly recommendable to backup the present BIOS, before downgrading, just in case. Another option would be upgrading, after backup, to the latest existing BIOS version. @andreainside: Both options may work. Both are somewhat risky. Don't do anything because I said so. If you decide do it, go ahead it if, and only if, you yourself consider it's an idea worthy trying. YMMV. Explore your card manufacturer's site and see whether they offer BIOS upgrades/downgrades and get their BIOS flasher... it's safer to use the card manufacturer's bios than VIA's reference BIOSes for add-on cards. ======= NOTE: In fact the SATA driver it contains is too new, because it only contains VIAMRAID.SYS, which you do not want... what you want instead is VIASRAID.MPD, which exists in the other download I pointed to earlier.

My point is that Gape's SP 2.1a installs VMM.VxD 4.10.0.2226. Somehow you've downgraded to VMM.VxD 4.10.0.2222 somewhere along the way, because 2222 is the only version that (when extracted fom inside VMM32.VXD by RLoew's patcher) has no version info (because, when the windows installer first compiles VMM32.VxD during the installation process it stripes the version info from all the VxD it'll compile, to save space). So, after uSP 2.1a and RLoew's patch, your %WINDIR%\SYSTEM\VMM32 folder should have the contents below: 125,593 CONFIGMG.VXD 186,470 IFSMGR.VXD 69,594 IOS.VXD 195,262 NTKERN.VXD 9,792 QEMMFIX.VXD 36,606 VCACHE.BAK 37,159 VCACHE.VXD 33,115 VCOMM.VXD 77,993 VFAT.VXD 22,615 VMCPD.VXD 472,564 VMM.BAK 472,564 VMM.VXD 33,356 VMOUSE.VXD 47,497 VPICD.VXD 41,615 UDF.VXD With VMM.VxD being v. 4.10.0.2226! Since this is not the case, I do suggest that you make a backup of the contents of that folder. Then get Q288430, open it with 7-zip and get NTKern.VxD and VMM.VxD from inside it. Then reboot to true DOS, uninstall RLoew's patch with the original installer, substitute both NTKern.VxD and VMM.VxD by the ones got from Q288430, then reinstall Rloew's patch and reboot. Let's see whether updating your VMM.VxD will make any difference. I sure hope it will.

This is just to add a cross-reference to the thread where Usher's method was shown to work.

Then, this is not correct: ... it should be: instead, right?

OK! Take your time, JorgeA. It should be a pleasure, not an ordeal.

Well, since your card is set to SATA mode, and apparently cannot be reconfigured for IDE-compatible mode (which is usual for those VIA controllers), I take back what I said before: RLoew's patch won't be of any help to you, because it requires the controller to be in IDE-compatible mode to work. Then again, wsxedcrfv is right: you actually don't need RLoew's patch, because there is a good VIA driver for the card. The correct VIA SATA driver to use is this one: SerialATA_V220E.zip (direct download) Anything newer, despite VIA claiming they support 9x/ME, in fact do not work right. Good luck!

I'm glad to know you don't have the "Restart in DOS Mode" issue. But this led me to think about another possibility: What is the update state of your 98SE? Is it plain-vanilla or do you have one of Gapes's uSP applied? If you don't, perhaps it might solve your issues... Now, take care: save all of autoexec.bat, config.sys, msdos.sys, system.ini, win.ini and control.ini before applying it. And don't do it before we discuss some more, because Gape's uSP will interfere with the RAM Limitation Patch, since it updates VMM.VxD, so we must prepare for that, too. However, it's premature for me to elaborate on this, because you may have it already applied, from before adding RLoew's patch...

Great! And before doing anything, always do 3 sanity checks to get confortable with the multimeter (the manual leaflet is here for all to see): 1) Do the Continuity Check. 2) Set it to ohmmeter 10 and touch the test leads together: if you don't read zero, correct it with the resistance zero adjust. 3) Set it to DCV 10 and measure a brand-new common lantern battery. You should read 1.5V or slightly less. Now, with this out of the way, set it to DCV 25 and proceed the tests puntoMX suggested.

Get RLoew's SATA patch and inf (see RLoew's Software Homepage). Its your best bet (though it's not for free). Then again, it was designed with motherboard controllers in mind, it may not be enough. Why not simply use an IDE HDD partition for booting and move whatever you have on IDE to SATA? It's simpler and time-proven.

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? Moreover I think that the higher the drive number, the most likely their manifestation. For my ancient GeForce 2 MX 400, anything above 29.42 gives both. As one moves to newer cards, higher numbered drivers become a must, and the likelihood of not having any working driver without those issues becomes higher. I think they're most probably due to an increasing lack of interst on the part of nVidia for the 9x/ME family OSes, probably from the 6x.xx drivers onwards. And the 7950 are possibly the most up-to-date cards able to work with 9x/ME... I don't recall anyone having had any success with newer cards. @Cyker: Thanks!

So, now it seems to me that the issue with the network card is unrelated, even if it began on your first installation of the nVidia drivers... As it is relatively harmless, we can troubleshoot it last. The usual workaround for the shut-down issue with nVidia drivers is to set a password in the BIOS. Then, instead of shutting down, you reboot and, when the machine pauses for you to enter the password, you turn it off using the smart-button in the case. BTW, you probably have a third issue you're not even aware of: you probably cannot "Restart in MS-DOS mode" anymore, too. The "Restart in MS-DOS mode" and the much-more-troubleshooted-already shut-down issues have proven unsolvable, up to now, for the 7 series, at least. But now we know 512 MiB is not really an issue, and that's great news! Just to check things out, how does the system behave in case you take your vidocapture card out (just for testing, of course)?

Meanwhile, get yourself also a piece of electric wire 6-8 in. long. One of the insulated conductors from inside the garden-variety 8-conductor ethernet cable would be perfect, but any other similar cable will do. What we want with this is to use the plastic tubing insulator without the internal metal conductor, to insulate securely three of the four conductors in the USB headers, in order for you to safely measure the remaining one, without the risk of short-circuiting it with the one(s) next to it, for they are much thinner than the multimeters probe-points, and we dont want to take any chances, now, do we?

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 guess you could try to actually use the NVAGP.INF from the unofficial 82.69 directly with those not so much older drivers... if so, it obviates having to edit it for each driver set... its worth to try it. Here are pointers to the 82.16 and the 81.98. As for the 77.72, I know you alredy have it, but there seem to be an older and a newer version of it, whatever that may mean. Perhaps one of those does the trick.

Title changed. @jiewmeng: do *not* do that again! Consider yourself warned.

I believe so. He was using /M because of the registry issue (and me too). Maybe he should try it together with ths SPLIT8MB.EXE? BTW, this thread has now been added to: nVidia GeForce and Win 9x/ME - Relevant Threads

Once more, congratulations! You and RLoew are probably the only two users known to have succeded with a 512 MiB card... I hope it may encourage others to try and achieve success with those cards, too. 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. That's one of the variations of the classic shut-down issue the few last nVidia drivers have. It usually can be solved by partial ot total downgrade to an earlier version. Backup. Then... Not that you may have add the card to the inf, for it to work. Note also that this is an extreme solution. RLoew had figured out a way to replace just some files from earlier drivers, which worked in his case. So I trust that may also be possible. This is serious an you've shown it's not a Win 9x/ME issue. I believe alternative software may be found to work around it. However, even if this problem eventually causes you to desist of using the video card (I sure hope it won't), do use it for some more time, at least for long enough for some testing and to solve the 9x/ME issues, please.

Not really. It comes complete with a pair of probe points. I guess it'll be enough. However, you might ask for bundled chips for a full casino night... After all gambling at no expense is a must, too.

The new USB ports would be attached either to one (or two) rear bay-bracket(s) or to a front-panel blind drive-placeholder, if there is one such placeholder still free. Any El-Cheapo Multimeter will do. This is the one I use. It has good enough voltmeter and ohmmeter capabilities, which is all we'll need, and some more nice capabilities, and a very nice price. BTW, I'll move this thread to the hardware forum now, I ought to have done it much sooner, already. And yes, a 1TB Seagate WS110 Black Armor seems quite good. Go for it! :

This means you have four (not two as I first thought) additional unused potential USB ports. Namely F_USB5, F_USB6, F_USB3 and F_USB4. Potential, because it would be necessary to connect the headers to actual ports (say, in a bracket) to put them to use. This sums up to 12, so the 1394a ports are being controlled through an aditional unnamed chip, that must be connected to the southbridge (the ICH9R) via the PCI bus, and not directly by it. If you decide to reclaim them and put them to use, it'll be necessary to establish their pinout, so it would help a lot if you had an inexpensive multimeter handy. The main task consists in finding out which is the +5V pin and which is the ground. If you're interested, I'll elaborate on it. BTW, I'd say a 750 GB Seagate FreeAgent Go might suit you perfectly as your new back-up external HDD, IMHO... Now, after you're safely backed up, then we can try to troubleshoot, and perhaps recover the 2.0 ability of your current Hitachi drive, but I think we'd better not mess with it meanwhile.

What exactly is that, and how do I know if any given system already has it? STFF! ... and do read the fist few posts of the KernelEx sticky thread. BTW, there should be a KernelEx.dll in %WINDIR%\SYSTEM, too.

Good news! There is nothing wrong with your machine. Its southbrige is working as it should. All is well! Bad news: Something *IS* quite wrong with your external HDD. It's controller is not behaving as it should! I'd buy another and backup all that is in your external HDD (or, at least, all that's important) before it fails further... True, we haven't conclusively excluded the cable, but why take any chances? BTW, which, exactly, is the manufacturer and model of your external HDD?

Great, JorgeA! Now that I know which board you have, I can tell you that: 1) It uses Intel ICH9R southbridge, which has internal support for 12 USB 2.0 (forget the other controllers, how many EHC ports does USBView find, regardless of mapping?), which may or may not be *all* available in that motherboard, so that's your *upper* limit. 2) HP says there are 4 USB ports in the back-panel, soldered directly on the motherboard and two USB ports in the front pannel, plus the Pocket Media Drive and the Card Reader... that makes 8 USB ports in total. 3) HP says there are three USB 2.0 headers supporting 6 USB ports or devices, and since we can account for just 8, of which we should subtract the 4 on the back (which are soldered, so they don't have headers), ergo you must have one free header supporting two further USB ports. Now you'll say to me: one free header? two further ports? 8 + 2 = 10... didn't you start talking about 12 ports? Yes, I did. But... HP also says there are one 1394a port in the back and one internal 1394 port header (for one further firewire port) inside. The ICH9R can control up to 12 USB 2.0 or 1394a ports in total. So here are the missing two ports. Now you'll say to me: that means I can have also one further 1394a port, if I find that header? Yes, probably. Here's what you have to do: the headers are in a single row on the lowermost part of the motherboard, just below the PCI connector. They have lables written in white fields, which are illegible in this photo (but the white fields are visible). Open the case read those labels and report. You can ignore any header that has a connector plugged in it. Only the unconnected headers interest us. I'm quite sure those two white headers, with two rows of 5 pins (of which one pin is missing) are USB headers, but probably the two black headers next to them also are and I bet they are used for the Pocket Media and the Card Reader. I bet one of the white connectors will be unused and the other is the one serving the two front USB ports. I'm think the 1394a header is the somewhat higher red header that is to the left of the two PCI-e x1 connectors, just about between them (so it's not shown in the attached picture snippet), but I may be wrong. That is up to you to find out. Take care not to disconnect anything, you just want to take a peek, at the moment, nothing more. A thin hand lantern is most useful to help on your task. Good luck!