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