Jump to content

Ext HDD's greater than 137GB under Win ME


piikea

Recommended Posts

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.

Have you tried the "USB hub trick" I mentioned earlier? Flash support is much more consistent via a compatible hub, so the same should be true for HDD support.

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.

Well, I assumed the problems I encountered when reaching 64G were due to the size of the FAT, in which case NTFS (which I didn't even realize was supported) is probably not similarly affected. While I concentrated on ASPIDISK, I definitely did try DI1000DD with the same outcome. If you didn't encounter this same limitation (using FAT32), there must be some other factor involved.

Joe.

Link to comment
Share on other sites

  • 2 weeks later...

Well this thread kind-of fizzled out. I got burned out from all the time-consuming trial and error testing without any success, and the OP apparently completely lost interest too.

Have you tried the "USB hub trick" I mentioned earlier? Flash support is much more consistent via a compatible hub, so the same should be true for HDD support.

No I have not yet but I plan on doing so. I do remember you mentioning that and I wanted to test it out for myself. I'll report my experiences when I get around to it.

Well, I assumed the problems I encountered when reaching 64G were due to the size of the FAT, in which case NTFS (which I didn't even realize was supported) is probably not similarly affected. While I concentrated on ASPIDISK, I definitely did try DI1000DD with the same outcome. If you didn't encounter this same limitation (using FAT32), there must be some other factor involved.

Yeah, I don't know. I can't think of any particular reason offhand why you're experiencing those problems either.

Some brief updates:

I was able to successfully use ASPIUHCI.SYS with DI1000DD.SYS on my laptop to access and write to an external USB HDD at USB 1.1 speed. It was quirky however in that my external USB HDD showed up twice (duplicate entries) within Ghost 2003 in the Check Disk option.

As I previously mentioned, loading ASPIEHCI.SYS with the switches /D1 through /D3 allows DI1000DD.SYS to be successfully loaded without the hard lockups I experienced earlier. However I still cannot detect any USB devices connected to my USB 2.0 PCI card.

I was able to do some more testing on that Verbatim 1.0 TB NTFS-formatted external USB HDD again. Both DI1000DD.SYS and ASPIEHCI.SYS caused a "divide overflow" error. Again, only ASPIDISK.SYS allowed successful access to the HDD.

Edited by Prozactive
Link to comment
Share on other sites

I was able to do some more testing on that Verbatim 1.0 TB NTFS-formatted external USB HDD again. Both DI1000DD.SYS and ASPIEHCI.SYS caused a "divide overflow" error. Again, only ASPIDISK.SYS allowed successful access to the HDD.

I believe the divide overflow is due to the Software trying to compute the number of logical Cylinders and getting a number over 65535. This will occur around 507GiB. I have seen this happen with some SATA Drivers.

It would probably not be too hard to fix.

Link to comment
Share on other sites

I have isolated code that wil cause a Divide Overflow above 507GiB in DI1000DD.SYS.

To prevent the Overflow replace the Bytes F7 F1 at Offset 2896 with EB 06.

This Mod will cause INT 13 AH=8 to report 1024 Cylinders regardless of the true size.

Link to comment
Share on other sites

Wow. Great work rloew! :thumbup I've located the specific bytes you cited but unfortunately I'm not able to test the patched driver as I do not have a HDD larger than 320 GB. The 1.0 TB HDD on which I got the "divide overflow" errors belongs to a friend. Maybe someone else can test the patch and report their experiences.

On a related note, I meant to mention this earlier... I'm puzzled how dencorso is able to access his 1.5 TB HDD without any such errors. And as I discussed in an earlier thread, Ghost 2003 apparently has a "hard" 1.0 TiB size limit in its coding. I don't think dencorso specifically stated that he used Ghost 2003 to access his 1.5 TB HDD but I know he uses that program. And I don't know if he used DI1000DD.SYS but I also experienced the "divide overflow" error with ASPIEHCI.SYS and GUEST.EXE.

Edited by Prozactive
Link to comment
Share on other sites

Wow. Great work rloew! :thumbup I've located the specific bytes you cited but unfortunately I'm not able to test the patched driver as I do not have a HDD larger than 320 GB. The 1.0 TB HDD on which I got the "divide overflow" errors belongs to a friend. Maybe someone else can test the patch and report their experiences.

On a related note, I meant to mention this earlier... I'm puzzled how dencorso is able to access his 1.5 TB HDD without any such errors. And as I discussed in an earlier thread, Ghost 2003 apparently has a "hard" 1.0 TiB size limit in its coding. I don't think dencorso specifically stated that he used Ghost 2003 to access his 1.5 TB HDD but I know he uses that program. And I don't know if he used DI1000DD.SYS but I also experienced the "divide overflow" error with ASPIEHCI.SYS and GUEST.EXE.

Didn't have ASPIEHCI.SYS last night. Now I do.

Replace Bytes F7 F1 at offset A950 with EB 06 in ASPIEHCI.SYS

Link to comment
Share on other sites

I have isolated code that wil cause a Divide Overflow above 507GiB in DI1000DD.SYS.

To prevent the Overflow replace the Bytes F7 F1 at Offset 2896 with EB 06.

This Mod will cause INT 13 AH=8 to report 1024 Cylinders regardless of the true size.

Fantastic work (as usual) Mr. Loew!

It's also encouraging that more people have managed to get this driver to work OK beyond 64G [edit: 64G partition size, that is].

I don't think dencorso specifically stated that he used Ghost 2003 to access his 1.5 TB HDD but I know he uses that program.

As an aside, I notice that Ghost 2003 (which was based on Ghost 7.6) gets a lot of mention around here. Yet the latest in that original line of Ghost S/W was version 8.3.0.1331, so I don't understand why.

Joe.

Edited by jds
Link to comment
Share on other sites

I also experienced the "divide overflow" error with ASPIEHCI.SYS and GUEST.EXE.

Didn't have ASPIEHCI.SYS last night. Now I do.

Replace Bytes F7 F1 at offset A950 with EB 06 in ASPIEHCI.SYS

Again, great work Mr Loew! :yes:

I hope I'm not being a nuisance here, but whilst you're playing with this stuff, is there any chance you could also look at Adaptec's AFDISK.EXE, which can be found in any of the archives 'aspidos.zip', 'dosdrvr.zip', or 'scsilite.zip' (or the EXE versions of same)? If you try to define/change partitions with this, using the Panasonic USBASPI.SYS driver (don't know if it's OK with ASPIEHCI.SYS and the like, since only the Panasonic driver works for me), it crashes (divide by zero error, if I recall). I suspect AFDISK may be relying on some ASPI parameter or function that USBASPI doesn't provide, but that is pure speculation.

Joe.

Link to comment
Share on other sites

I also experienced the "divide overflow" error with ASPIEHCI.SYS and GUEST.EXE.

Didn't have ASPIEHCI.SYS last night. Now I do.

Replace Bytes F7 F1 at offset A950 with EB 06 in ASPIEHCI.SYS

Again, great work Mr Loew! :yes:

I hope I'm not being a nuisance here, but whilst you're playing with this stuff, is there any chance you could also look at Adaptec's AFDISK.EXE, which can be found in any of the archives 'aspidos.zip', 'dosdrvr.zip', or 'scsilite.zip' (or the EXE versions of same)? If you try to define/change partitions with this, using the Panasonic USBASPI.SYS driver (don't know if it's OK with ASPIEHCI.SYS and the like, since only the Panasonic driver works for me), it crashes (divide by zero error, if I recall). I suspect AFDISK may be relying on some ASPI parameter or function that USBASPI doesn't provide, but that is pure speculation.

Joe.

I couldn't find AFDISK.EXE but I observed the same Problem with my RFDISK.EXE Partitioner. DI1000DD.SYS does not properly report an error when attempting to access the Drive after the Drive(s) it mounted.

RFDISK, and probably AFDISK, did a divide by zero when DI1000DD.SYS reported a Zero Sector per Track Drive instead of an Invalid Drive. I have fixed RFDISK to handle this better.

Patch DI1000DD.SYS by replacing 76 with 72 at offset CE6. This will eliminate the spurious Drive reports.

Link to comment
Share on other sites

I couldn't find AFDISK.EXE but I observed the same Problem with my RFDISK.EXE Partitioner. DI1000DD.SYS does not properly report an error when attempting to access the Drive after the Drive(s) it mounted.

RFDISK, and probably AFDISK, did a divide by zero when DI1000DD.SYS reported a Zero Sector per Track Drive instead of an Invalid Drive. I have fixed RFDISK to handle this better.

Patch DI1000DD.SYS by replacing 76 with 72 at offset CE6. This will eliminate the spurious Drive reports.

OK, thanks! That should help for some other FDISK programs.

However, AFAIK (actually, I'm pretty sure) AFDISK interfaces directly with the ASPI driver, so why this is important, is that if your disk is not properly initialized, then DI1000DD.SYS will typically crash, so you are then unable to use a standard FDISK program to correct the problem (Catch 22).

I could give a direct download link, but to play nice with the "I agree" stuff from Adaptec, here's the page you need : http://www.adaptec.com/en-us/speed/scsi/dos/dosdrvr_exe.htm

Edit 1 : Hang on a second, just downloaded and it's not the 'dosdrvr.exe' with the right goodies that we need. Will investigate.

Edit 2 : OK, panic over. When looking into 'dosdrvr.exe' using PK-Zip, Info-Zip, TugZip or 7-Zip, only the three files SCSIFMT.* are visible. However, if you run this executable, all the goodies appear, including AFDISK.*.

Joe.

Edited by jds
Link to comment
Share on other sites

WinRAR 3.93 can open correctly 'dosdrvr.exe'. I confirm 7-zip 4.65 cannot.

Yeah, the auto-detection for TugZip and 7-Zip gets it wrong. The archive is actually LHA, and that (I used LHA version 2.12) can see and extract all the files within.

Strange that the three SCSIFMT.* files show up and are successfully extracted with PKUNZIP and UnZip32 (Info-Zip).

So one mystery solved and another created. The three files in question are compressed with LHA method 5, but so too are all but one of the other files in that archive. BTW, it seems LHA method 5 must be equivalent to PKware's DeflatN method (which I think is based on LZ77).

Joe.

Link to comment
Share on other sites

  • 2 weeks later...

Related to the initial issue of this thread -- (& this may be a crazy / stupid question) but it is it possible to convert 1 partition of this 1TB ext HDD from FAT32 to NTFS? (Not necessarily as a permanent "configuration" but for data transfer to an NTFS HDD).

Link to comment
Share on other sites

I have isolated code that wil cause a Divide Overflow above 507GiB in DI1000DD.SYS.

To prevent the Overflow replace the Bytes F7 F1 at Offset 2896 with EB 06.

This Mod will cause INT 13 AH=8 to report 1024 Cylinders regardless of the true size.

I'm having this overflow problem with di1000dd.sys as well, and I'm using a Western Digital 750Gb external USB HDD.

I've run out of options so I would like to try your suggestion above, but how do I actually modify the file?

Thanks in advance, if you can point the way.......

Link to comment
Share on other sites

I have isolated code that wil cause a Divide Overflow above 507GiB in DI1000DD.SYS.

To prevent the Overflow replace the Bytes F7 F1 at Offset 2896 with EB 06.

This Mod will cause INT 13 AH=8 to report 1024 Cylinders regardless of the true size.

I'm having this overflow problem with di1000dd.sys as well, and I'm using a Western Digital 750Gb external USB HDD.

I've run out of options so I would like to try your suggestion above, but how do I actually modify the file?

Thanks in advance, if you can point the way.......

You need to use a HEX Editor to modify the file. DEBUG can be used if you don't have any other.

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...