Tom's Guide | Tom's Hardware | Tom's Games
![]() |
![]() |
![]() |
EHDD is IOMEGA 80GB identified (both by Windows/SysInfo and DOS/DI1000DD.SYS) as WDC WD80 0BB-JHA0
Three weeks ago I installed the above EHDD to use with two older systems:
1 Acer Travelmate 200 NB BIOS 4.234T v3.3 WIN98SE Installed a DUB-C2 USB cardbus adapter (NEC chips) to provide EHCI support.
2 NEC SPB400 desktop Phoenix BIOS v4 rev6 WIN98 Installed a DUB-A2 PCI card (VIA chips) to provide EHCI support.EHDD functions under Windows (and protected mode DOS) with EHCI support on both systems.
In real mode DOS used the USB driver pair USBASPI.SYS (v2.15 aka usbaspi4.sys) and DI1000DD.SYS in an emergency boot floppy to obtain EHCI functionality on the Acer. On the NEC was forced to use onboard UHCI ports (Intel chip) to obtain functionality - but IT WORKED.
Was pleased and made Ghost image backups of both C:\ drives. Then experimented on making an emergency boot CD (NEC has CDRW) with USB support. USBASPI.SYS in config.sys hangs (because of read only?) so experimented with other drivers (ASPIUHCI.SYS and ASPIDISK.SYS pair or DUSE.EXE) and CTLOAD from RamDrive. NoGo!
Went back to emergency boot floppy and discovered I had lost DOS access to the EHDD. USBASPI.SYS /u /v loads, scans UHCI, detects and initializes the USB device and DI1000DD.SYS assigns drive E: DIR E: reports Volume 3952-6AA6 containing one file RRaA 0 byte no directory structure but does report 72GB. Tried alternate UHCI port, different cable and finally emergency boot floppy with EHCI support on the ACER. Same NO FUNCTIONAL ACCESS result.
Windows (and protected mode MSDOS) functionality continues to work fine.
Used ScanDisk and Fdisk in protected MSDOS to verify EHDD shows:
Paritions E:1 Status A Type PRI DOS Vol. Label Iomegs_HDD Serial # 3952-6AA6 Mbytes 76317 System FAT32 Usage 100%. The Type and ID is also reported in DOS by DI1000DD.SYS.DOS functionality is obviously important for emergency backup purposes. Because the problem is identical in all settings, it seems the difficulty is in reading the FAT. Is it possible some unsuccessful initialization attempt during experimentation with the CD boot disk made a write change to the DOS initialization sector (Is there such a beast)? Any help is appreciated.

![]() |
![]() |
![]() |

This post is quite old and has been locked from receiving new replies. Please create a new posting instead.
| Ads by Google |