Ext HDD's greater than 137GB under Win ME

[jds]

I don't know whether (iv) works. (i), (ii) and (iii) I can vouch for.

Versions are important here... USBASPI.EXE (Panasonic, v. 2.28) is findable at MDGx's.

And any GUEST prior to v. 8.5 is useless (except, perhaps, v. 8.0, if it exists).

NJ32DISK.SYS is, for all I know, just a previous, older version of DI1000DD.SYS (or, at least, is derived from the same common source... the Copiright dates are somewhat confusing as to which is newer, but version number and size point to DI1000DD.SYS as the newer one (see the ASCII comparison attached).

BTW, ASPIDISK.SYS v. 4.01b Copyright 1989-1997 by Adaptec, is that it?

Never have actually used it. Now that you mention it, it opens up still more combinations, right?

In any case, this is a trial and error game, where patience pays, and getting irritated leads one nowhere.

Even my two external Seagates behave differently.

Workbit's NJ32DISK.SYS seems to be derived from Novac's DI1000DD.SYS (or an earlier work perhaps) and the dates I have for these files are 2002/04/03 and 2001/08/16, respectively. (This is contrary to your indication that DI1000DD.SYS is newer, perhaps you've found a newer version of this?)

However, NJ32DISK.SYS only supports "superfloppy" format, whereas DI1000DD.SYS only supports "hard disk" format. They cannot be considered alternatives of each other!

Adaptec's ASPIDISK.SYS supports both "superfloppy" and "hard disk" formats.

FWIW, I have found both DI1000DD.SYS and ASPIDISK.SYS to be stable only with partitions up to 64G in size. I prefer ASPIDISK.SYS for its versatility and stability, however, it doesn't provide an INT13 interface, so if I want to use FDISK, then I revert to DI1000DD.SYS (however, there's a Catch 22 in that).

I have never had any luck with IOmega's GUEST.EXE, although I don't know which versions I've tried.

- I'm using both the MDGx modified version 2.28 and the original 2.27 version of Panasonic USB drivers.

......

- And YES, the entire DOS USB access is certainly one big trial and error process!

Does anyone know, what exactly was the modification mentioned above? While I found two links for "More Info" at MDGx's site, neither of them explained about this modification.

Also a tip. The Panasonic driver works VERY well via a USB hub. So well in fact, that many USB drives that won't work when connected directly to the root hub, WILL work via an external hub. However, not all external hubs seem compatible (eg. I have two hubs based on two different NEC chips, one works beautifully, the other won't work at all). Find a hub that's compatible (most seem to be), and your success with different USB drives will improve dramatically.

So your Guest is v. 8.5! But to have ASPIEHCI.SYS v.13 09-May-2003 you must have at least performed LiveUpdate2 (bumps Ghost up to revision 789) but you've probably done that and LU3, too, so I'd guess you've got it, too. BTW, I've run a quick test and Guest does work with USBASPI.EXE 2.28, so option (iv) also works.

Also BTW, thanks for the heads up on USBASPI.SYS 2.27! It's actually newer than USBASPI.EXE 2.28... I've just got it from the Panasonic Japan site (the English version, of course).

The latest ASPIEHCI.SYS that I have is dated 2003/05/28 and has a CRC32 of BE9DA061. It came from Ghost 2003 update file '1165278149jtun_ng2003b789_en.x86.full.zip'.

Do you have a later one dated 2003/09/13 or is it the same (per CRC32)?

Incidentally, Symantec dropped these IOmega drivers for Ghost 8.3.1331 (because they were unhappy with their hardware compatibility) and built USB support directly into Ghost and GDISK. For some strange reason, Ghost's inbuilt USB support doesn't work for me, yet with GDISK, it does!

BTW, GDISK (8.3.1331) is what I now use to "FDISK" a new USB drive, since the USBASPI+DI1000DD combination (well, DI1000DD really) will crash if it doesn't like the existing partitioning. (Sometimes I also use the USBASPI driver by itself, read and write the MBR with a couple of my own utilities, and edit the MBR image with DISKEDIT from Symantec's 'ned_2001.exe'.)

Joe.

PS. @piikea: ASPIDISK .SYS is available in archives ASPIDOS.ZIP and DOSDRVR.ZIP, one or both of which should be available at Adaptec's site.

[dencorso]

Here: dosdrvr.exe... You'll get to a page in Japanese, but the drivers are in English.

Problem is, when you hit "Download Now" you'll be taken to a licence page that is actually in Japanese, too. No prob, just scroll down and notice a gray box with the default selection next to "いいえ"... that means "I don't agree", so just click on the next radio-button, which is not selected by default, which is next to "はい", which means "I agree". Then click on "I agree and answer truthfully" and you'll be given the download. So, click on "Primary" and the download'll begin. Once you get dosdrvr_exe, don't run it, but instead open it with 7-zip or WinRAR and grab ASPIDISK.SYS v. 4.01b from inside it. You need to improve your Google-fu, piikea!

The latest ASPIEHCI.SYS that I have is dated 2003/05/28 and has a CRC32 of BE9DA061. It came from Ghost 2003 update file '1165278149jtun_ng2003b789_en.x86.full.zip'.

@jds: I don't happen to have it at hand right now to calculate the CRC-32, but that's the same file I have and use, too. And it came from the same place. And it's the latest version of it that I know of. As for Guest.exe v. 8.5, that's the one that comes in the distribution CD of Ghost 2003.

[Prozactive]

Does anyone know, what exactly was the modification mentioned above? While I found two links for "More Info" at MDGx's site, neither of them explained about this modification.

Excellent technical discussion. I only have time to quickly address this particular question for now. The following is from the readme file from MDGx's modified driver.

USBASPI.EXE is a modification of the recently released Panasonic native DOS USB driver USBASPI.SYS ver 2.28.

I found a reference to that new version on a recent MSFN post:

http://www.msfn.org/board/index.php?showtopic=40561

http://www.msfn.org/board/index.php?showtopic=114868&pid=753965

The modification was necessary as I experienced system lockups on PCs where the BIOS supports some USB mass storage devices, such as USB floppy drives, USB ZIP drives and USB CD-ROM drives, but, for example, not all USB memory sticks or hard drives.

With the command line switch /w the driver now pauses *after* the USB controllers have been initialized. When USB mass storage devices are connected at that point, the lockups no longer occur.

The original functionality, that is, the driver pauses *before* the controllers are initialized is still possible with the following command line switch:

USBASPI.EXE /w /w

[piikea]

Here: dosdrvr.exe... You'll get to a page in Japanese, but the drivers are in English..... ......Once you get dosdrvr_exe, don't run it, but instead open it with 7-zip or WinRAR and grab ASPIDISK.SYS v. 4.01b from inside it. You need to improve your Google-fu, piikea!

My previous Google-ing had only found discussions of the problem & links that didn't work. I did get to Adaptec site initially as well but even then couldn't locate it! Not sure I would've discovered it inside dosdrvr.exe.

Anyway, I hoped Prozactive's experience would've been a "quick solution" to mine but aspidisk.sys ultimately did not work in my case. Same "overload" error.

I will still have to try another combo.

EDIT:

Or better yet stick w/ my current back-up "protocol" which uses the Panasonic USB Drivers disks & an 80GB ext HDD - I know it works properly (since I have had to use it a couple times to restore my system). IF the 1TB ext HDD is going to be "iffy" or less stable/reliable it isn't worth the headache.

Edited December 14, 2010 by piikea

[dencorso]

IF the 1TB ext HDD is going to be "iffy" or less stable/reliable it isn't worth the headache.

True. But even if you decide to sell it and maybe get another one, perhaps smaller... or none at all, in any case, now you know all you need to partition / format your next HDD to suit perfectly your needs. During the 1 TB disk tenure with you you probably learned many things you'd never envisaged you one day would. So it's not a total loss.

BTW, I'd give options (i) and (ii) a try. I think ASPIEHCI.SYS/GUEST.EXE may work.

[jds]

Does anyone know, what exactly was the modification mentioned above? While I found two links for "More Info" at MDGx's site, neither of them explained about this modification.

Excellent technical discussion. I only have time to quickly address this particular question for now. The following is from the readme file from MDGx's modified driver.

USBASPI.EXE is a modification of the recently released Panasonic native DOS USB driver USBASPI.SYS ver 2.28.

I found a reference to that new version on a recent MSFN post:

http://www.msfn.org/board/index.php?showtopic=40561

http://www.msfn.org/board/index.php?showtopic=114868&pid=753965

The modification was necessary as I experienced system lockups on PCs where the BIOS supports some USB mass storage devices, such as USB floppy drives, USB ZIP drives and USB CD-ROM drives, but, for example, not all USB memory sticks or hard drives.

With the command line switch /w the driver now pauses *after* the USB controllers have been initialized. When USB mass storage devices are connected at that point, the lockups no longer occur.

The original functionality, that is, the driver pauses *before* the controllers are initialized is still possible with the following command line switch:

USBASPI.EXE /w /w

Thanks! Sounds like a useful hack, however I'm still puzzled by the version numbering.

The current official version is available via the web page : http://panasonic.co.jp/pcc/products/drive/other/f2h_usb.html (You can use 7-Zip to extract 'USBASPI.SYS' from 'f2h_usb.exe') This contains the string "Version 2.27 ©Copyright Panasonic Communications Co., Ltd. 2000-2008". [ Edit: The download page is now: http://panasonic.jp/com/support/drive/other/f2h_usb.html ]

OTOH, the modified version (once you unpack it with UPX) contains the string "Version 2.28 ©Copyright Panasonic Communications Co., Ltd. 2000-2007".

Trying to search for the origins of the modified version is unfruitful. However, it seems version 2.24 had the copyright "2000-2007", so that's a possibility ...

Strange.

Anyway, I hoped Prozactive's experience would've been a "quick solution" to mine but aspidisk.sys ultimately did not work in my case. Same "overload" error.

As I said, I found both ASPIDISK.SYS and DI1000DD.SYS to only be stable for partitions less than 64G (although I didn't do exhaustive testing of primary vs. extended/logical partitions). Just partition accordingly and you don't need to hunt down a smaller disk (the extra space could be used for NTFS or EXT3, I suppose).

IF the 1TB ext HDD is going to be "iffy" or less stable/reliable it isn't worth the headache.

True. But even if you decide to sell it and maybe get another one, perhaps smaller... or none at all, in any case, now you know all you need to partition / format your next HDD to suit perfectly your needs. During the 1 TB disk tenure with you you probably learned many things you'd never envisaged you one day would. So it's not a total loss.

BTW, I'd give options (i) and (ii) a try. I think ASPIEHCI.SYS/GUEST.EXE may work.

I tried GUEST.EXE again, this time I know it was version 8.5. No good. Assigns a drive letter OK (J:) but then constantly gives a nonsensical error message "Write protect error reading drive A:".

Joe.

Edited June 22, 2012 by jds

[piikea]

IF the 1TB ext HDD is going to be "iffy" or less stable/reliable it isn't worth the headache.

True. But even if you decide to sell it and maybe get another one, perhaps smaller... or none at all, in any case, now you know all you need to partition / format your next HDD to suit perfectly your needs. During the 1 TB disk tenure with you you probably learned many things you'd never envisaged you one day would. So it's not a total loss.

BTW, I'd give options (i) and (ii) a try. I think ASPIEHCI.SYS/GUEST.EXE may work.

No, not at all. I am still using the 1TB drive for data storage so I am grateful to have it (& for everyone's help here in formatting it, etc). Ideally I could also store system back-up image on it but I can continue using the 80GB ext HDD for that. I will still fiddle around w/ the various driver combo's & post results if I am successful!

[Prozactive]

@dencorso:

I tested the various new combinations of drivers but I was unable to get options (iii) and (iv) to work.

Option (iii), ASPIEHCI.SYS + DI1000DD.SYS, froze the system after loading the Iomega ASPIEHCI.SYS driver, displaying the status "No Devices Found." That was the step in CONFIG.SYS where it loaded DI1000DD.SYS. This was a hard lockup too, where ctrl-alt-del did not reboot the system, requiring use of the reset button to reboot the system. I was unable to detect any of my USB 2.0 test devices with the Iomega ASPIEHCI.SYS driver either, further confirming my experience that the driver has very limited compatibility.

Option (iv), Panasonic USB drivers (either USBASPI.EXE or USBASPI.SYS) + GUEST.EXE, stalled after detecting USB devices, displaying the status "Finding a drive letter for your Iomega drive..." This was not a hard lockup. The keyboard was still responsive and I could use ctrl-alt-del to reboot the system.

I'm puzzled how you and others were able to get these combinations to work.

[dencorso]

Are you loading the iomega ehci driver like this?

DEVICE=<Drive:\<Path\>>ASPIEHCI.SYS /int /all

If not do try it. And you may try using /norst with either USBASPI

Then again, you may try loading them after DOS is fully booted, by using either DEVLOAD or DEVLOD. Both are great.

Well, I fear I've just added some more variables to the problem...

Later edit:

As requested, these are the drivers I spoke of, so that we can be sure we're testing the same drivers:

ASPIEHCI.SYS v. 13 52,106 bytes CRC32: BE9DA061

MD5: A21BDF09885668D49EE7CA60B4AA899E

GUEST.EXE v. 8.5 32,396 bytes CRC32: 4F3CD18D

MD5: B3194E47B7087D1DA32D1C885BAA6A18

NJ32DISK.SYS v. 1.06 15,808 bytes CRC32: 61575716

MD5: B9211CE1938663E80914C95F4A08E2C2

DI1000DD.SYS v2.00 16,368 bytes CRC32: F9F9E011

MD5: 662FF106A2C4012D212E8F99B62EC6E0

This is just for completeness, because I'm pretty sure we're all using the same ones.

[Prozactive]

Thanks dencorso for your reply and the info. I am loading ASPIEHCI.SYS with the /int /all switches. I am also loading the Panasonic USBASPI drivers with the /norst switch. The only possible difference is I am loading the drivers and GUEST.EXE into upper memory (using DEVICEHIGH for the drivers and LH for GUEST.EXE). This has not caused any problems previously but I will probably experiment loading them into conventional "low" memory to see if it makes a difference.

DI1000DD.SYS definitely causes a hard lockup with ASPIEHCI.SYS (option iii), while GUEST.EXE appears to stall out indefinitely while trying to assign a drive letter after the Panasonic USB drivers are loaded (option iv).

Thanks for the info about DEVLOAD and DEVLOD. I was not aware of them and I may try using them as a last resort.

I have also verified all of the MD5 hashes. As a minor point of clarification (which also apparently confused jds), viewing ASPIEHCI.SYS in a hex editor shows the following string:

Iomega ASPI USB-EHCI 1.0 V.13 09 May 2003

Copyright © 2003 Iomega Corporation.

which implies to me that it's 1.0 version 13 (dated 09-May-2003) as opposed to "v.13 09 of 2003" as you've stated numerous times. In any case, we're all using the same file.

Thanks again for your help and I'll report back with any developments.

Edited December 16, 2010 by Prozactive

[jaclaz]

Thanks for the info about DEVLOAD and DEVLOD. I was not aware of them and I may try using them as a last resort.

Also, maybe, something worth trying:

http://johnson.tmfc.net/dos/usbdrv.html

at least to "borrow" the driver loading scheme.

jaclaz

[dencorso]

...viewing ASPIEHCI.SYS in a hex editor shows the following string:

Iomega ASPI USB-EHCI 1.0 V.13 09 May 2003

Copyright © 2003 Iomega Corporation.

which implies to me that it's 1.0 version 13 (dated 09-May-2003) as opposed to "v.13 09 of 2003" as you've stated numerous times. In any case, we're all using the same file.

Sure! You're right, of course! I misread it!

I've just fished out the version that shipped with Ghost2003, which was superseded by the one we're all using and it says:

Iomega ASPI USB-EHCI 1.0 V.02 : 12 Aug 2002

Copyright © 2002 Iomega Corporation.

The additional colon (here marked in red) present lets no doubt as to where the date begins and the version ends!

It's also remarkable that there were twelve versions from Aug 12 '02 to May 09 '03, indicating that lots of bugfixing took place in that period, before Symantec eventually gave up Iomega and started implementing its own built-in USB support in ghost and gdisk.

[jds]

I don't know whether (iv) works. (i), (ii) and (iii) I can vouch for.

Versions are important here... USBASPI.EXE (Panasonic, v. 2.28) is findable at MDGx's.

And any GUEST prior to v. 8.5 is useless (except, perhaps, v. 8.0, if it exists).

NJ32DISK.SYS is, for all I know, just a previous, older version of DI1000DD.SYS (or, at least, is derived from the same common source... the Copiright dates are somewhat confusing as to which is newer, but version number and size point to DI1000DD.SYS as the newer one (see the ASCII comparison attached).

BTW, ASPIDISK.SYS v. 4.01b Copyright 1989-1997 by Adaptec, is that it?

Never have actually used it. Now that you mention it, it opens up still more combinations, right?

In any case, this is a trial and error game, where patience pays, and getting irritated leads one nowhere.

Even my two external Seagates behave differently.

(Hmmm ... What happened to the pretty "ASCII comparison" graphic in the above quote?)

Anyway, a bit OT, but possibly of general interest anyway - which utility gives this nice comparison of two (binary) files?

I have also verified all of the MD5 hashes. As a minor point of clarification (which also apparently confused jds), viewing ASPIEHCI.SYS in a hex editor shows the following string:

Iomega ASPI USB-EHCI 1.0 V.13 09 May 2003

Copyright © 2003 Iomega Corporation.

Actually, my confusion is with the current Panasonic USBASPI.SYS driver, which is from 2008 and has a version no. 2.27, versus the modified USBASPI.EXE driver, which is from 2007, yet has a version no. 2.28 (for comparison, the only original driver I could find from 2007 had version no. 2.24).

Joe.

[Prozactive]

The latest ASPIEHCI.SYS that I have is dated 2003/05/28 and has a CRC32 of BE9DA061. It came from Ghost 2003 update file '1165278149jtun_ng2003b789_en.x86.full.zip'.

Do you have a later one dated 2003/09/13 or is it the same (per CRC32)?

@jds:

This is what led me to say you were somewhat confused about ASPIEHCI.SYS. In any case, it's a minor point but I'm glad dencorso took the time to check and clear things up. We're all using the same drivers.

Yes, I'm also somewhat confused about the versions of USBASPI.EXE. MDGx would be the source for a definitive answer, but I suspect he decided to increment the version number of his modified (possibly older) driver.

I've made the changes in CONFIG.SYS to load the drivers into conventional "low" memory and I'm about to test them shortly. We'll see if it makes any difference. I tend to think it won't but you never know. It may be my particular hardware that's causing the incompatibility.

Edited December 17, 2010 by Prozactive

[dencorso]

Along the time MDGx made available *two* different versions of USBASPI.EXE:

ASPI Manager for USB mass-storage Version 2.26

©Copyright Panasonic Communications Co., Ltd. 2000-2007

CRC32: 1C96416A MD5: 325F845251AD7F30A600E26B888F7367

21,322 bytes

ASPI Manager for USB mass-storage Version 2.28

©Copyright Panasonic Communications Co., Ltd. 2000-2007

CRC32: DE44AE4D MD5: 4434E0F5D75568742CD7AD73C313A8E9

21,323 bytes

After uncompression, both grow to exactly 31011 bytes, and differ in just 7 bytes, with some code reordering...

Both may be derived from USBASPI.SYS 2.24, by patching, but it's more than the plain vanilla isometric patch, and the whole help screen that appears on runing either from the command line was also added, prior to compressing.

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.

The ascii comparison I posted (and which remains there) was created from 2 screenshots from Beyond Compare, cropped, merged and edited to remove the hex dump (since it didn't add any new info in this particular case).