Welcome, Guest. Please Login
 
  HomeHelpSearchLogin FAQ Radified Ghost.Classic Ghost.New Bootable CD Blog  
 
Pages: 1 ... 18 19 20 
Send Topic Print
A Better USB 2.0 DOS Driver for Ghost + More! (Read 385409 times)
Prozactive
Gnarly
*
Offline



Posts: 31


Back to top
Re: A Better USB 2.0 DOS Driver for Ghost + More!
Reply #285 - Dec 13th, 2010 at 10:22am
 
Chill NightOwl.  Wink I didn't have the link handy as I was composing my reply in the edit window.

Here's a link to the referenced forum thread. That post and the subsequent post discuss where to get the file. You'll note that they also don't provide a specific link. I absolutely have no idea specifically where I got the file as it was many months ago and I DL'ed so many files from so many places developing my Ghost boot disk. However, the link that dencorso references does not sound familiar at all.

http://www.msfn.org/board/topic/146397-ext-hdds-greater-than-137gb-under-win-me/...

And I was speaking of lack of time and energy posting my detailed technical experiences with Ghost boot disks and drivers, not this particular ASPI disk redirector driver. HTH
 
 
IP Logged
 

NightOwl
Radministrator
*****
Offline


"I tought I saw a puddy
tat..."

Posts: 5801
Olympia, WA--Puget Sound--USA


Back to top
Re: A Better USB 2.0 DOS Driver for Ghost + More!
Reply #286 - Dec 13th, 2010 at 10:35am
 
@
Prozactive

Saw your edit after I posted--

Quote:
Unfortunately I don't have the specific link to get the file

How about a link that talks about using that file?

I found this link that mentions the *aspidisk.sys* driver:  http://www.adaptec.com/en-us/support/_eol/scsi_sw/ez-scsi_3.1/

Don't know if you can extract that driver from that file--I would look at the downloaded file with WinRAR if it's possible--often files are insided a *.exe* file that otherwise run an update program--and separate files can be extracted without running the *.exe* file!

Here's another link:  http://www.adaptec.com/en-us/speed/scsi/dos/dosdrvr_exe.htm

Came from here:  http://fixunix.com/ms-dos/531113-where-i-can-find-aspidisk-sys-und-aspiusb-sys.h...
 

____________________________________________________________________________________________

No question is stupid ... but, possibly the answers are Wink !
 
IP Logged
 
Prozactive
Gnarly
*
Offline



Posts: 31


Back to top
Re: A Better USB 2.0 DOS Driver for Ghost + More!
Reply #287 - Dec 13th, 2010 at 10:42am
 
You jostled my memory. I believe it was EZ-SCSI. I now recall looking at the various versions and trying to figure out which to use. I believe I finally used 4.01. And yes I think I may have extracted them from some install file. The dosdrvr term looks very familiar too. But like I said, it's very blurry and I can't recall specifically what I finally did and where I got the file. I'm sure you're on the right track though.
 
 
IP Logged
 
piikea
Gnarly
*
Offline


I love YaBB 1G - SP1!

Posts: 35


Back to top
Re: A Better USB 2.0 DOS Driver for Ghost + More!
Reply #288 - Dec 13th, 2010 at 5:16pm
 
OK, you both beat me to it. Prozactive provides the initial info & now link to discussion as I was about to. And Nightowl the link to the actual file which I have in the interim found & tried but got the same "overload" error.

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.

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.

2nd EDIT:
I'm also leery of messing up the Panasonic Drivers floppy's I have that do work!
 
 
IP Logged
 
NightOwl
Radministrator
*****
Offline


"I tought I saw a puddy
tat..."

Posts: 5801
Olympia, WA--Puget Sound--USA


Back to top
Re: A Better USB 2.0 DOS Driver for Ghost + More!
Reply #289 - Dec 16th, 2010 at 1:42am
 
@
Prozactive and
@
piikea

I looked at that thread--there's no discussion as to when or how to use *aspidisk.sys* for accessing external USB HDDs in DOS--any other links that might explain how to use that driver and why?

Quote:
Or better yet stick w/ my current back-up "protocol" which uses the Panasonic USB Drivers disks & an 80GB ext HDD

Well, I'm using the Panasonic DOS USB driver on HDDs up to 160 GB so far.  I may be able to test it on a 650 GB HDD soon.
 

____________________________________________________________________________________________

No question is stupid ... but, possibly the answers are Wink !
 
IP Logged
 
Prozactive
Gnarly
*
Offline



Posts: 31


Back to top
Re: A Better USB 2.0 DOS Driver for Ghost + More!
Reply #290 - Dec 16th, 2010 at 12:05pm
 
ASPIDISK.SYS directly replaces DI1000DD.SYS. Load it the same way. I spent a good deal of time yesterday testing the various combinations of drivers and found that it and NJ32DISK.SYS do not work, at least for the USB devices I tested in my system. They generally detected the USB devices after loading the USB driver but could not assign a drive letter to them for some reason. Thus, after Ghost 2003 loaded, those USB devices did not show up in the list of mounted disks within Ghost.

The only time ASPIDISK.SYS proved useful was with a friend's Verbatim NTFS-formatted 1TB external USB HDD. It was the only driver that allowed access to the HDD without "divide overflow" and other errors. We were able to successfully write a Ghost image to the HDD afterwards.

@piikea:
That reminds me... I didn't read the 10+ confusing pages in the MSFN forums thread but how did you end up partitioning and formatting your 1TB HDD? My friend's 1TB HDD was formatted in NTFS as one large partition as I recall. Perhaps that makes a difference in why ASPIDISK.SYS worked for him but not you.
 
 
IP Logged
 

Ghost2003-Wonder
N00b
Offline


I Love Radified!

Posts: 6


Back to top
Re: A Better USB 2.0 DOS Driver for Ghost + More!
Reply #291 - Aug 6th, 2011 at 1:37am
 
NightOwl- wrote on May 24th, 2005 at 11:02am:
Valts

Quote:

"The following file is missing or corrupted: Di1000dd.sys
There is an error in your CONFIG.SYS on line 3


Chicken vs Egg Problem?

I've seen reference to computer systems that can boot from USB memory cards--but I have no experience as to whether this is true or not.

Does your system have such ability?Does it create a 'virtual A:\ drive' like the bootable CD sector on optical media?Or, how exactly do you set it up so it's supposed to work?

The problem is--you are trying to load a USB driver that mounts a USB card reader (Device=usbaspi.sys /e /v ), and then a driver that assigns a drive letter to that mounted USB card reader (Device=di1000dd.sys ).But you need those drivers loaded before you can access the memory card.


NightOwl



I have gone thru the procedures I learned from this post (Jason Baker’s post at 2004-10-15) to make my HP USB2.0 2GB Flash/Thumb Drive boot up my computer to Win98-DOS and then install all the USB 2.0 device driver for DOS. This message is to explain not only how but also why you need to go thru the complicated steps in order to get the Ghost 2003 work if you must boot up the machine via the USB 2.0 port.

As NightOwl had once said, the main problem to boot up a computer from an USB device is how to handle the Chicken And Egg problem (CAE).

The USB media, via which the machine is being booted up, will also be scanned and then assigned (by the device driver saved on this very media) with a new Drive Letter which is more likely than not to be a different one as the old Drive Letter of the USB media when it was in charge of the booting procedure in the very beginning.

This Drive Letter ReNaming issue pops up in the middle of the booting up procedure. The result is that the computer has no idea from where can it fetch the next instruction/command to finish the boot up job after that ReNaming point, since the Drive Letter of the USB media on which the boot up CONFIG.SYS file is saved has suddenly been changed.

--- Gazing at this scenario, it does not look like a Chicken And Egg problem to me though. It looks more like the video clip depicts that Bugs Bunny is sitting on a high tree branch and working very efficiently to cut off the very same branch from the tree end. ---

“I won’t fall, Doc. I can totally ignore the gravitational force so long I don’t look down at the earth…” so said the Bugs.

I skip the step(s) of preparing the bootable Win98-DOS USB2.0 Flash Drive & how to set your computer’s BIOS to make the PC boot from the USB device attaced to its USB port. NightOwl had covered those topics in very detailed before. I’ll focus on explaining Jason’s idea in loading the USB2.0 device drivers for DOS from that very same USB2.0 Flash Drive

(1)      Put only very fundamental stuff in the CONFIG.SYS file. The USB device driver must not be saved in this file for the reasons that Bugs Bunny had since very long time declined to accept. Meanwhile the fundamental stuff should be enough for the autoexec batch file to create, later, a virtual RAM DRIVE of capacity no less than 2MB (I’ll make it 4 MB). Jason put these stuff on his CONFIG.SYS

switches=/f
break=off
dos=high,umb
files=20
buffers=30
lastdrive=z
device=c:\dos\himem.sys /testmem:off /v
device=c:\dos\emm386.exe /v h=128 noems

You don’t see the CONFIG.SYS called by any program and yet if you made any wrongful change to it, or just change its file name, your computer can’t boot up. Will this make you feel curious?

After power on and finishing the Power On Self Test step, the BIOS will tickle the 1st of the DOS System Trio files, the IO.SYS; not by name, not by age not by gender, but by the exact address/spot where this IO.SYS must be saved on the selected device (device selection is decided by adjusting the Boot Device Sequence of the BIOS); which then leads to execute the 2nd one, MSDOS.SYS. The MSDOS.SYS will call the CONFIG.SYS to execute each of its instructions 1 by 1. Up to this point, there is neither File System nor Memory Management service yet. The calling of CONFIG.SYS by the MSDOS to get some .sys instructions to run is Hard-Coded in the MSDOS.SYS. No File System service means there is no way you can request “Hey guy, I don’t have a CONFIG.SYS file, would you accept a KONFOG.CYC saved in the iJunky sub-directory?” MSDOS would not even bother to “Huh?” if you do so.

The automatic and implicit execution of the CONFIG.SYS is something we don’t like as we want to Boot Up and Install Device Driver from USB device. The execution of CONFIG.SYS is totally automatical; you have no control at all. If you save the Panasonic or the Iomega drivers to the CONFIG.SYS file, you are doomed.

(2)      From now on, all the jobs are to be done by the AUTOEXEC.BAT file
In the AUTOEXEC.BAT, the first job is to create the RAM drive of 4MB. For individual application of very simple environments, just hard-code the virtual RAM Drive to M: drive (don’t pick up one that’s either too near the Z: or too close to the C:) should be fine. This can be done by the instruction of:
c:\dos\xmsdsk.exe 4096 m: /y

Don’t be too conservative in allocating the size of RAM Drive. 1G DDR is so common inside a computer these days. 4MB budget for a virtual RAM Drive is no big deal. As the matter of fact, after booting up, DOS by itself won’t take any RAM beyond 1 MB. Most of the 1GB except the 1MB occupied by DOS will be idle if you don’t use them. I don’t know what’s the maximum virtual RAM Drive can be created by DOS, I will never feel shy in fully making use of the available RAM as my RAM drive. RAM drive is so much faster than a Floppy or CD.

 
 
IP Logged
 
Ghost2003-Wonder
N00b
Offline


I Love Radified!

Posts: 6


Back to top
Re: A Better USB 2.0 DOS Driver for Ghost + More!
Reply #292 - Aug 6th, 2011 at 2:09am
 
NightOwl- wrote on May 24th, 2005 at 11:02am:
Valts

Quote:

"The following file is missing or corrupted: Di1000dd.sys
There is an error in your CONFIG.SYS on line 3


Chicken vs Egg Problem?

I've seen reference to computer systems that can boot from USB memory cards--but I have no experience as to whether this is true or not.


/Continued

The granularity of the RAM Drive size is K (1024), the number 4096 at the end of the above command means 4096K, which is equal to 4 Million. The ‘m’ after that is the designated Drive Letter for this RAM Drive I chose. You might take the N, R or S or whichever letter not being used as you like.


(3)      Copy all the files, sub-directories from you USB booting up drive to the M: Drive.
Note: If the COMMAND.COM file on you USB booting drive root directory is not visible then it won’t be copied to M: Drive at all. That’s an error will fail the booting job. Using the DOS command, ATTRIB, to change the COMMAND.COM’s attributes to make it visible in you booting Drive root directory, so it can be copied to the M: Drive.
c:\dos\attrib –h –s c:\command.com  ==  to make command.com visible
copy c:\*.* M:\*.*
mkdir M:\dos
copy c:\dos\*.* M:\dos\*.*
mkdir M:\ghost
copy c:\ghost\*.* M:\ghost\*.*


(4)      Launch another DOS shell which is resident in M: Drive by this instruction
M:\COMMAND.COM /P
set COMSPEC=M:\command.com > nul

The /P option in the above instruction is to get another Shell (that’s, the COMMAND.COM , the one saved on the M: Drive root directory in our case here)to be in charge of the system Permanently.

The reason to issue this instruction:: You will sooner call another BATCH file (let’s name it LOAD-DRV.BAT) to “LOAD” the USB 2.0 device driver(s). When that LOAD-DRV.BAT file finish its job (and hence, the booting Drive will be ReNamed with new Drive Letter --- by then), it must return the control of the computer back to the currently Working Shell. If you don’t run the above instruction to make the Shell saved on the M: Drive to be the permanent boss of the system, then the LOAD-DRV.BAT will get nowhere to return the control power since his current boss’ home Name has just been ReNamed by the LOAD-DRV.BAT itself.

Nobody can blame you if you feel dizzy now, because a key question has not been answered yet:

If the COMMAND.COM residing on the C: Drive need to worry about the Drive Letter of his physical drive being changed by device driver scanning and designating, then why the COMMAND.COM residing on the RAM Drive M: does NOT have the similar concern?

Well for whatever reason, the engineers who did the USB2.0 Device Driver for DOS do make their codes to scan the virtual RAM Drive and recognize its existence, but they do NOT rename the Drive Letter of the RAM Drive. My speculation (kinds of like to Read those engineer’s minds) is that what they were doing was the device driver for the USB 2.0 devices; since the virtual RAM Drive is a totally different animal as a physically existing USB device, the Drive Letter of the virtual RAM Drive is none of the USB 2.0 device driver’s business at all. Just let it be what it is.

BTW, calling the drives loading program directly within the AUTOEXEC.BAT file in stead of indirectly calling another BATCH FILE to execute the loading jobs will not fix the Bugs Bunny problem. The booting USB device will still be ReNamed, and the currently working Shell will still be missing for the same reason, and following instruction still can not be fetched by the computer.

Make the COMMAND.COM of the virtual RAM Drive be the boss (the Shell) is the only solution so far I know.

(5)      Calling the LOAD-DRV.BAT file by this instruction
call M:\ LOAD-DRV.BAT

(6)      Here, we standing inside of the LOAD-DRV.BAT file now
Mainly there are only 2 jobs inside the LOAD-DRV.BAT,. They are either the Panasonic school’s Pairs or the Iomega camp’s Doubles, as we’ll see sooner.

To me, conceptually this is the most difficult step:

Under normal situation, CONFIG.SYS is a file implicitly and automatically called by the MSDOS.SYS to get the Device Driver installed even before the computer finishes the booting procedure. Those invisible trio: the IO.SYS, the MSDOS.SYS and the COMMAND.COM are always existing but never be the visible programs. To most of the human being of this world, how is anything inside of the CONFIG.SYS is done, and by whom, is a pure black box. And now, we are talking about EXPLICITLY Loading those XXX.SYS files and activate it, how could that be possible?

Luckily there are software tools to do that job. One of these kinds of tools named DEVLOAD.COM can take care of that.

For Panasonic school, the device driver Pairs will be loaded by these instructions.

M:\dos\devload /v M:\panason\usbaspi.sys
M:\dos\devload.com /v M:\panason\DI1000DD.sys

Option /v makes both the loader and the driver themselves more or less verbose.

There are rooms to improve and make this batch file more friendly. Echo the following messages, for example, will make the booting procedure more smooth.

@echo Kindly reminding, Dude
@echo This is the best time and the last chance for you to plug in all the USB device(s)
@echo into your computer’s USB ports if you want to use them in DOS environment @echo later…
pause

M:\dos\devload.com /v M:\panason\usbaspi.sys

@echo Dude, if you have finished reading the report message displayed by the
@echo Panasonic USBASPI.SYS driver, please get ready to let the DI1000DD.SYS to
@echo designate each USB device detected by the USBASPI.SYS for you…
pause

M:\dos\devload.com /v M:\panason\DI1000DD.sys

/to be continued
 
 
IP Logged
 
Ghost2003-Wonder
N00b
Offline


I Love Radified!

Posts: 6


Back to top
Re: A Better USB 2.0 DOS Driver for Ghost + More!
Reply #293 - Aug 6th, 2011 at 2:40am
 
[quote author=20243B322127263D34530 link=1095438251/25#25 date=1116950533]Valts

Quote:

"The following file is missing or corrupted: Di1000dd.sys
There is an error in your CONFIG.SYS on line 3

/continued

Don’t laugh so breathlessly as that could hurt you--- at least don’t do that before you finish reading the two very good reasons for doing those Message Echos:

1.      Before you Power On the computer, you should not plug in any USB device other than the one you using to boot up the computer. Otherwise your computer can not decide which USB device, among the many ones, is in charge of the booting up procedure. You can bet the PC will hang in no time.

2.      You must not plug in any USB devices later than the Device Drivers starting to be loaded. Otherwise the to-be-loaded Device Driver won’t be able to detect the existence of your USB device(s) and thus it can’t load/configure appropriately for your devices.

Now you see, sometimes even the Echo Message could be very critical. You may continue laughing now if you want.

Finally, put this instruction to express you are to return to AUTOEXEC.BAT file

exit.

(7)      Ha, we are back to the AUTOEXEC.BAT again
Mind you, the main reason we can come back to AUTOEXEC.BAT is owing to the LOAD-DRV.BAT, after finishing its job, can successfully report to his boss, the COMMAND.COM, located on the virtual Ram Drive M:\

The remaining jobs is quite self-explaining:

@echo Just come back from LOAD-DRV.BAT to AUTOEXEC.BAT

rem: Load the MS Mouse driver. Ghost 2003 is so easy to use when Mouse pointer is
rem: available.

M:\dos\mouse

@echo Your booting up USB Flash Drive should now be assigned with the Drive Letter of N:
@echo now --- A Letter next to your RAM Drive Letter, which remains unchanged, the M:

path=%path%;N:\;N:\DOS;N:\GHOST

rem: The speed difference between the USB Flash Drive and the DDR RAM Drive is not that
rem: significant. So, there is no substantial gain/loss in choosing either of these 2 devices
rem: as your searching target to find the program(s) to run.
rem: If your booting up USB device is the obviously slower media like an USB Floppy or an rem: USB CD device, then you'd better choose the RAM Drive to be searched on
rem: your PATH environment variable. In our case it would be something like this then.

path= M:\;M:\DOS;M:\GHOST

@echo To confirm your USB Flash Drive is assigned as N: Drive now, a DIR command will be
@echo issued to display files saved in the N: root directory
rem: This is really something laughable, since you will be able to verified that later in the
rem: GHOST devices listing window…
pause

dir m:\

@echo Tip:: Type GHOST/? and press Enter key to list all the possible options in using
@echo        GHOST program.
@echo Tip:: Type GHOST and press Enter key to start GHOST…
@echo Smiley
@echo Smiley
@echo Smiley

And that's all, folks...


P.S.

In my 2nd post of this topic, step (3), I said that you need to use the DOS command, ATTRIB to change the attribute of the COMMAND.COM as to make it visible and hence be copy-able.

That attributes changing job must be done OFF-LINE. That is, the COMMAND.COM attributes changing instruction should not be included as one instruction line of your AUTOEXEC.BAT file. That job should be done before the AUTOEXEC.BAT is executed.

You see, you can change/replace the working BOSS/Shell by issuing the command.com /p when the computer is working. But you should never try to REPAIR/MODIFY the working BOSS/Shell while the compuer is running. That's very bad practice. --- Now that looks like a very good Chicken-And-Egg example.
 
 
IP Logged
 
Ghost2003-Wonder
N00b
Offline


I Love Radified!

Posts: 6


Back to top
Re: A Better USB 2.0 DOS Driver for Ghost + More!
Reply #294 - Aug 6th, 2011 at 4:11am
 
There are always some typos, missings, errors detected only after you had posted your messages.

(1) Jason Baker's post link is:
http://www.computing.net/answers/dos/ghosting-from-booted-usb-key-drive/15205.ht...

I miss the hyperlink in the very beginning of my first post.

(2) DOS has three very baisc System Files: IO.SYS, MSDOS.SYS, COMMAND.COM. None of them are either visible or writable. Missing any one of them will make it impossible to boot up the PC. Among them the IO.SYS is even more picky: relocate its location on the storage media even by 1 byte offset will make the IO.SYS file invalid and hence the PC can not boot up any more.

Therefore, in step (3) of my 2nd post, without changing the attributes, none of these 3 System Files will be copied from the Booting USB Flash Drive to the virtul RAM Drive. But we only care if the COMMAND.COM has been copied or not.

Why?

The IO.SYS and the MSDOS.SYS are the 100% permanently Stay Resident style codes. They are loaded onto the RAM space only once every time the computer is Power ON. They squat in the same specific RAM address space no matter what until the computer is Power Off . After Power Off, these 2 files just vaporize from the RAM, they don't even need to be closed --- as all the regular files must do.

When the computer is firstly booted up by the USB Flash Drive, the IO.SYS and the MSDOS.SYS are the first 2 files loaded into the RAM space (note: Not the virtual RAM Drive --- the virtual RAM Drive has not been created until later. Rather, it is the RAM space somewhere inside the 1MB memory boundary which is allocated for the DOS kingdom). As I just mentioned above, these 2 files will squat on that loaded RAM locations and remain effective no matter what until the Power OFF. They just can't care less if the Drive Letter of the USB Flash Drive (on which their original images are saved) has been changed millions times or not.

COMMAND.COM is different animal in this regard. When the RAM memory available space is getting lower, the COMMAND.COM program can either partially or highly let go itself from the RAM to give room for the loaded application program. After the application program has finished its job and quits, the current working Shell, namely, the speicific copy of COMMAND.COM saved at specific folder of specific device will then be loaded into the memory again.

That should be clear why we don't care if the IO.SYS and the MSDOS.SYS have been successfully copied to the RAM Drive or not, and why we must make sure the COMMAND.COM has been successfully copied to the RAM Drive.
 
 
IP Logged
 
Pages: 1 ... 18 19 20 
Send Topic Print