Jump to content

Ext HDD's greater than 137GB under Win ME


piikea

Recommended Posts

That's good to know that option (iv) works.. thanks! I've created a custom CONFIG.SYS file with multiple menu items for the various driver combinations and I'd like to edit it to add the additional options but I'm not sure if there's a limit for the number of menu items. I'll have to do some research into that.

Have you run into the "divide overflow" error cited earlier? The only time I've encountered that was trying to access a 1.0 TB external HDD. Every driver gave that error except ASPIDISK.SYS as I recall. I think you said you've successfully accessed a 1.5 TB external HDD?

Maybe you can post your "custom CONFIG.SYS file"? I was unsure if it would work properly with all the drivers (i) through (iv) all on the same floppy(s).

Link to comment
Share on other sites


My comparisons are done with Beyond Compare 3.2.3 (not freeware) on Win XP SP3. It's not expensive, and worth the cost. I'm not sure which is the last version of it that runs on 9x/ME, since I never tried to install it there.

Thanks Den, I'll have to look into this, it looks extremely useful (especially if there's a 9X version, although KernelEx can probably assist if there isn't).

Joe.

Link to comment
Share on other sites

Just a quick update. Apparently loading the drivers in upper memory DOES have an effect, especially with GUEST.EXE. I now have to do more extensive trial and error troubleshooting to narrow down where and how the errors are occurring. It also may involve the particular memory managers/drivers that I'm using. And I still cannot detect any USB devices with ASPIEHCI.SYS for some reason, even though I can detect them with Iomega's USB 1.1 drivers.

Edited by Prozactive
Link to comment
Share on other sites

Another brief update. Utter failure. After extensive trial and error testing, changing various parameters, etc., I cannot get options (iii) and (iv) to work whatsoever. I'm completely baffled how dencorso and others (?) are able to do so. Loading the various drivers "low" vs. "high" does have an effect but does not allow GUEST.EXE to work with the Panasonic USB drivers. DI1000DD.SYS still causes a hard lockup with ASPIEHCI.SYS no matter how the drivers are loaded ("low" or "high"). And ASPIEHCI.SYS cannot detect any of my USB 2.0 devices. I may fill in some of the details later but that's the bottom line. I'd be interested to hear how anyone is able to get those options to work.

Edited by Prozactive
Link to comment
Share on other sites

And I still cannot detect any USB devices with ASPIEHCI.SYS for some reason, even though I can detect them with Iomega's USB 1.1 drivers.

Are you sure your hardware actually *has* USB 2.0 aka EHCI capabilities, to begin with?

If you cannot get ASPIEHCI.SYS to detect any devices, all options involvig it are just empty theory, in your case.

Now. do create a boot diskette. Let it have only IO.SYS, COMMAND.COM, HIMEM.SYS, DEVLOAD and DEVLOD, and the USB driver files inside. Remove even DRVSPACE.BIN and MSDOS.SYS. Create a single-line CONFIG.SYS, containing DEVICE=HIMEM.SYS.

Reboot from this diskette. When you get the A:\ prompt, use DEVLOAD to load ASPIEHCI.SYS /int /all and let's see what happens: If nothing gets detected, you're limited to USBASPI as the aspi stack.

You may have described your relevant hardware previously... if so do point me to where you did it, if not, do describe it. I mean motherboard exact model, and any PCI add on-card, whatever provides the USB hardware we're interested in. Please. :)

Link to comment
Share on other sites

My comparisons are done with Beyond Compare 3.2.3 (not freeware) on Win XP SP3. It's not expensive, and worth the cost. I'm not sure which is the last version of it that runs on 9x/ME, since I never tried to install it there.

Good news, the current version of Beyond Compare seems to work happily in W98SE (although I must confess I have KernelEx installed, however I suspect it would also work without it).

Just a quick update. Apparently loading the drivers in upper memory DOES have an effect, especially with GUEST.EXE. I now have to do more extensive trial and error troubleshooting to narrow down where and how the errors are occurring. It also may involve the particular memory managers/drivers that I'm using. And I still cannot detect any USB devices with ASPIEHCI.SYS for some reason, even though I can detect them with Iomega's USB 1.1 drivers.

If it's any consolation, I've never managed to get GUEST to work with USBASPI either, nor have I managed to get either ASPIUHCI or ASPIEHCI to load on relevant hardware.

I'm sure USBASPI isn't worried about the size of your hard drive and doesn't care about the size of your partitions. However, both DI1000DD and ASPIDISK seem unstable for partitions of 64G or larger (from my own experimentation), so that leaves one possibility for you to try : ASPIUHCI with GUEST. If I recall, all Intel and Via EHCI host controllers also support UHCI, so apart from the performance drop, this will at least allow GUEST to be tested to see how it handles larger partitions.

Joe.

Link to comment
Share on other sites

Thanks dencorso and jds for the replies, info, and advice. I think I'm throwing in the towel, as I've spent far too much time and effort in this ultimately futile quest to get those combinations of drivers working. And it's not even necessary, as I'm able to use the Panasonic drivers with DI1000DD.SYS to access all of my USB 2.0 devices so far. I was just baffled how dencorso was able to get options (iii) and (iv) to work, while I was not able to.

@dencorso:

Yes, as I stated in another recent thread, I just installed a new Syba VIA VT6212 USB 2.0 PCI card so I definitely have USB 2.0 capability which I've used and verified numerous times. My statement about being able to detect USB devices with Iomega's USB 1.1 drivers (ASPIUHCI and ASPIOHCI) was premature. As it turned out, that only occurred once and I could never get it to happen again. So to summarize the current situation, I cannot detect any USB devices connected to the Syba VIA VT6212 USB 2.0 PCI card with any of Iomega's drivers. I'm increasingly convinced that their drivers are incompatible with this particular hardware. I have, however, successfully used Iomega's ASPIUHCI.SYS driver countless times to access USB 1.1 devices connected to my motherboard's (ABIT KG7-RAID) USB ports.

Also, I don't think the hard lockups/incompatibility between DI1000DD.SYS and ASPIEHCI.SYS are affected at all whether the Iomega driver detects or fails to detect any USB devices. Maybe I'm wrong, but that's how it appears to me watching the drivers load and the status messages. Thanks again for your advice about using DEVLOAD to load the drivers. I may eventually do that just to see if it makes any difference.

@jds:

I encountered the exact same nonsensical error message you cited after loading the Panasonic USB drivers and GUEST.EXE "low" into conventional DOS memory:

Write protect error reading drive A

Abort, Retry, Fail?

The system became extremely unstable and generally crashed at varying points afterwards, requiring either a warm or cold reboot.

Interestingly, I initially got this slightly different error message when loading all of the drivers "high" into upper memory: (EDIT: I believe that is incorrect. I loaded most/all of the DOS USB drivers "low" but used JEMM386 and other memory managers to enable upper memory for other drivers.)

Write protect error reading drive 9

Abort, Retry, Fail?

Selecting "Retry" immediately generated a fatal exception 06 error in JEMM386.EXE (one of the memory managers that I use).

I also did note your past statement about DI1000DD.SYS and ASPIDISK.SYS being unstable for partitions 64GB or greater in size. That's interesting, and I'm not sure my personal experience completely corroborates your statement. I'll have to pay close attention to that in the future. Offhand, I can think of several examples where I've accessed and written to partitions considerably greater than 64GB, both FAT32 and NTFS formatted.

Edited by Prozactive
Link to comment
Share on other sites

I was just baffled how dencorso was able to get options (iii) and (iv) to work, while I was not able to.

Don't ever let hardware/software combinations/behaviour baffle you in this matter. Those drivers do work here and don't work there. It just means they're actually blorked, and of this fact I'm pretty sure.

Thanks for pointing me to the right previous thread.

I'm getting forgetful... (either too much work or the sign of aging... or both!)... :D

In any case, do read this interesting page on even more drivers, just for the sake of completeness.

Link to comment
Share on other sites

In any case, do read this interesting page on even more drivers, just for the sake of completeness.

If we are allowed to go Commercial :ph34r:, here:

http://www.dosusb.net/

(the "original" home page is sort of botched):

http://www.georgpotthast.de/

I missed if these also were tried :blushing::unsure: :

http://bretjohnson.us/

(same info on the page given by dencorso direct links for the record)

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Thanks dencorso and jaclaz. Coincidentally I read that first referenced link shortly before you posted it. And I'll try those new switches and see how they work.

Also, I edited my previous post for the interest of technical accuracy. I no longer think I loaded all of the DOS USB drivers "high" when I got the second error. I did so many combinations it's become very confusing.

Edited by Prozactive
Link to comment
Share on other sites

I have a question about my USB HDD usage experience under Windows 98. Couple of times it behaved very strangely.

The motherboard on this PC has only USB 1.1 ports (it is Intel D815EPE2U) and usually the data is read/written with a speed less than 1 Mbyte/s. However when I unpacked files from the archieve that was located on USB memory stick to my internal IDE HDD and then copied the files to my USB HDD, whey were copied with a speed about 20 Mbyte/s. There were about 50 Mb in these files. After reboot they were on there and were read correctly. The situation was reproduced four times. I'm just curious - how is this possible with USB 1.1? I understand that files were cached in RAM, but were they somehow cached in USB devices? There were no these files on the USB HDD before, they were stored in archieve on USB memory stick.

Another case was less successful. I have copied some files to USB HDD folder, then I noticed that they were not the files I wanted to copy. I deleted them, copied correct files there and then tried to pack them to archieve on USB memory stick. Everything stopped responding, and I pressed Reset. After I rebooted, I have not seen the new files on USB HDD in this folder! There were the files I copied there the first time, that I already deleted before reboot. And before reboot there were no old files, only new ones. May someone tell me what happened?

All operations were performed with recent Total Commander.

I still experience problems when copying data from one USB device to another USB device, hangups often occurs. And when I'm writing some data to USB HDD and another application tries to access other files on it, Windows stops responding too. Can this be helped? Using NUSB 3.3.

Link to comment
Share on other sites

I also did note your past statement about DI1000DD.SYS and ASPIDISK.SYS being unstable for partitions 64GB or greater in size. That's interesting, and I'm not sure my personal experience completely corroborates your statement. I'll have to pay close attention to that in the future. Offhand, I can think of several examples where I've accessed and written to partitions considerably greater than 64GB, both FAT32 and NTFS formatted.

Interesting that you had success with these drivers beyond 64G. There must be some other factor that I don't know, next time I get a new HDD, I'll have to test some more. Note that most of my testing was with ASPIDISK, so I'll concentrate more on DI1000DD when I do.

Also interesting that these drivers support NTFS. I wasn't aware of this.

The motherboard on this PC has only USB 1.1 ports (it is Intel D815EPE2U) and usually the data is read/written with a speed less than 1 Mbyte/s. However when I unpacked files from the archieve that was located on USB memory stick to my internal IDE HDD and then copied the files to my USB HDD, whey were copied with a speed about 20 Mbyte/s. There were about 50 Mb in these files. After reboot they were on there and were read correctly. The situation was reproduced four times. I'm just curious - how is this possible with USB 1.1? I understand that files were cached in RAM, but were they somehow cached in USB devices? There were no these files on the USB HDD before, they were stored in archieve on USB memory stick.

Yeah, if the little info. I could find on your MB is correct, the chipset is ICH2, which indeed is UHCI, so 20 MB/s is indeed beyond the laws of physics. My thoughts are that the files were cached in RAM beyond those 2.5s that the copy appeared to take. You rebooted some time after this, enough time for the actual transfer to your USB HDD to complete (actually, I would hope that W98 would wait for the transfer to complete before actually rebooting, although I've never pushed my luck on this). That's the only explanation I can think of.

Joe.

Link to comment
Share on other sites

@dencorso:

I've now done a fair amount of testing and can report that loading ASPIEHCI.SYS with those switches (/D1 through /D3) still does not allow it to detect any USB devices connected to my USB 2.0 PCI card. However, coincidentally or not, DI1000DD.SYS is now successfully loaded without the hard lockups I experienced earlier.

I've also noted that the Panasonic USB drivers (especially the MDGx modified 2.28 driver) tend to hang at the point while scanning for USB devices after initializing all detected USB controllers. Replugging a USB device seems to consistently unfreeze the system and allow normal bootup to continue, albeit without the replugged USB device subsequently being detected. Yet another example of the quirky nature of this entire process.

@jds:

As I thought more about it, I've definitely used DI1000DD.SYS numerous times to access and write data to a 120GB FAT32 partition without any problems. I've also used ASPIDISK.SYS once to access and write data to a 1.0 TB NTFS partition via Ghost 2003. That's been the only time I've successfully used ASPIDISK.SYS to access any HDD, by the way. And I didn't think the formatting of a partition affected whether the driver could successfully access the USB device but I could be wrong.

Edited by Prozactive
Link to comment
Share on other sites

In any case, do read this interesting page on even more drivers, just for the sake of completeness.

If we are allowed to go Commercial :ph34r:, here:

http://www.dosusb.net/

(the "original" home page is sort of botched):

http://www.georgpotthast.de/

I missed if these also were tried :blushing::unsure: :

http://bretjohnson.us/

(same info on the page given by dencorso direct links for the record)

jaclaz

The only good commercial solutions:

http://www.tssc.de/products/enablers

http://www.tssc.de/products/enablers/usbmass/default.htm

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...