Re: [Freedos-user] devload and UMB problem
with the new release of devload http://www.coli.uni-saarland.de/~eric/stuff/soft/by-others/devload-3.21.zip the problems appears solved.. Now more usb drivers can be loaded in UMB's. Roberto iw2evk iw2evk wrote: I've the same problem with usb drivers Devload \h C:\usb\usbaspi.sys devload \h C:\usb\usbcd.sys All the drivers remain in low memory. as702 SHA-1 wrote: just wondering if you could shed some light on a problem i'm having with FreeDOS (this work is based off of Modboot/NwDsk 3.42 FreeDos) i cannot for the life of me get devload to function using the /H switch. whenever i try to load a device into UMB, it always dumps the device into conventional ram. for instance: :config.sys devicehigh=\bin\ifshlp.sys works fine, whilst :autoexec.bat/some.bat devload /h %ramdrv%\bin\ifshlp.sys will load the driver into conventional ram only. am i doing something wrong? i also can't seem to get the shell to load into UMB :config.sys shellhigh=\command.com /e:2048 /p again, goes straight into conventional memory. i must be missing something :( _ http://clk.atdmt.com/UKM/go/msnnkmgl001007ukm/direct/01/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- View this message in context: http://www.nabble.com/devload-and-UMB-problem-tp17936897p18148779.html Sent from the FreeDOS - User mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] devload and UMB problem
with the new release of devload http://www.coli.uni-saarland.de/~eric/stuff/soft/by-others/devload-3.21.zip the problems appears solved.. Now more usb drivers can be loaded in UMB's. Roberto iw2evk Eric Auer wrote: Hi again, well if you can compile devload at all (you need tasm or the free arrowasm asm, www.dunfield.com/downloads.htm ) then you can help yourself with a patch / workaround: mov bx,0fffh; never desire 64k of UMBs Change this line to use 3ffh instead of 0fffh, then your devload will give drivers only 16k instead of 64k in /H UMB mode. Might be too small for other drivers, though. Maybe a nicer workaround would be: mov bx,80h ; first fit, try UMB first, low 2nd ; (4xh is only UMB, 00h iss low only) Change the 80h to 40h, then your devload will never fall back from UMB to low RAM in /H UMB mode. It will just fail to load a driver if not enough UMB is free instead. I think those workarounds should make devload do what you want in YOUR computer, they are just not universal enough to be put into an official version :-) Eric PS: SHELLHIGH would work, but FreeCOM command.com does need more than 100 kB of RAM during startup and your UMB is way too small for that. It only needs 3 kB later, so it is no problem that those 3 kB will be in low RAM :-). - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- View this message in context: http://www.nabble.com/devload-and-UMB-problem-tp17936897p18148790.html Sent from the FreeDOS - User mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] devload and UMB problem
Hi Roberto iw2evk, actually devload-3.21 is not officially released yet, I am still waiting for the okay from David (original author) but I guess he will like this version ;-). So as everybody now knows there will be an update anyway, feel free to test it already: Does it work with and without /H (load high) option for all the drivers for which it worked before? Does it also work for drivers for which 3.19 and 3.20 did not yet succeed in loading them high? Thanks :-) Eric PS: I notice that di1000dd requires for the INIT call that sub-unit number is 0 or 1, yet another weirdness found after Tom's needs r_bpfat=buffer in di1000dd and usbaspi for C_BLDBPB :-p PPS: Which drivers still cannot be loaded in UMBs? with the new release of devload http://www.coli.uni-saarland.de/~eric/stuff/soft/by-others/devload-3.21.zip the problems appears solved... Now more usb drivers can be loaded in UMB's. Roberto iw2evk - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] devload and UMB problem
I've the same problem with usb drivers Devload \h C:\usb\usbaspi.sys devload \h C:\usb\usbcd.sys All the drivers remain in low memory. as702 SHA-1 wrote: just wondering if you could shed some light on a problem i'm having with FreeDOS (this work is based off of Modboot/NwDsk 3.42 FreeDos) i cannot for the life of me get devload to function using the /H switch. whenever i try to load a device into UMB, it always dumps the device into conventional ram. for instance: :config.sys devicehigh=\bin\ifshlp.sys works fine, whilst :autoexec.bat/some.bat devload /h %ramdrv%\bin\ifshlp.sys will load the driver into conventional ram only. am i doing something wrong? i also can't seem to get the shell to load into UMB :config.sys shellhigh=\command.com /e:2048 /p again, goes straight into conventional memory. i must be missing something :( _ http://clk.atdmt.com/UKM/go/msnnkmgl001007ukm/direct/01/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- View this message in context: http://www.nabble.com/devload-and-UMB-problem-tp17936897p17960502.html Sent from the FreeDOS - User mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] devload and UMB problem
Eric Auer schrieb: ... I said some weeks ago that devload can not load into umb every time (Thread [Freedos-user] loading other config.sys?) but if I remember right you didn't believe me that devicehigh and devload /h are not completely the same or better said that devload can not be a full replacement for devicehigh. Great. Now you figured out yourself on source level. For some reason devload can never become perfect? I mean, if it would be possible to call exactly the same method as devicehigh is using then devload would already simply use this. Also if the whole devicehigh stuff wouldn't be necessary then we would also not use device commands, but only loadhigh. -mr - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] devload and UMB problem
Hi Michael, you were right, I was not aware that devload fails to figure out an appropriate UMB size and therefore fails more often than devicehigh to load devices to UMB space. Reading the sources made me realize that this feature is missing. Of course it can be added. However, devload will still not be perfect: Some drivers only have full performance if you load them before you load any command.com for the first time, which means you must load them before any bat file or prompt which would let you run devload... ;-). For the same reason, DEVICE is still needed even if DEVLOAD works as good as it can get for low RAM... Eric - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] devload and UMB problem
Eric Auer schrieb: However, devload will still not be perfect: Some drivers only have full performance if you load them before you load any command.com for the first time, which means you must load them before any bat file or prompt which would let you run devload... ;-). Could you reach the same state 'not loaded any command.com' by unloading command.com before and then it could become perfect? By the way, what about devload /unload ..? -mr - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] devload and UMB problem
Hi again, However, devload will still not be perfect: Some drivers only have full performance if you load them before you load any command.com for the first time Could you reach the same state 'not loaded any command.com' by unloading command.com before and then it could become perfect? You cannot unload command.com and I meant performance things such as you better load himem and emm386 before the rest - because they give you HMA (for kernel and buffers) and UMB (for loading stuff high). The kernel will not even try to move itself and buffers from the DOS RAM into HMA after you load command.com and it is quite okay that it works like that. I think you somehow want to tell that config sys is not user friendly enough and that you want to use a batch file instead - maybe we should just make config sys a bit more flexible instead of doing complex stuff like semi-reboot command.com and kernel during devload ;-) By the way, what about devload /unload ..? There are separate tools for that. Device drivers are not made to be unloaded, so you can only unload them if you have a mark / relase style tool which records some system state before you load a driver and lets you restore hopefully the right part of the state at the moment when you wipe / unload that driver later. If you want to unload something, it should better not be a device driver... A normal TSR might even already have some option to unload itself :-). Then you need no extra ram for record/restore state and have no risk that a mark-release tool might restore wrong style. Eric - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] devload and UMB problem
just wondering if you could shed some light on a problem i'm having with FreeDOS (this work is based off of Modboot/NwDsk 3.42 FreeDos) i cannot for the life of me get devload to function using the /H switch. whenever i try to load a device into UMB, it always dumps the device into conventional ram. for instance: :config.sys devicehigh=\bin\ifshlp.sys works fine, whilst :autoexec.bat/some.bat devload /h %ramdrv%\bin\ifshlp.sys will load the driver into conventional ram only. am i doing something wrong? i also can't seem to get the shell to load into UMB :config.sys shellhigh=\command.com /e:2048 /p again, goes straight into conventional memory. i must be missing something :( _ http://clk.atdmt.com/UKM/go/msnnkmgl001007ukm/direct/01/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] devload and UMB problem
Hi again, well if you can compile devload at all (you need tasm or the free arrowasm asm, www.dunfield.com/downloads.htm ) then you can help yourself with a patch / workaround: mov bx,0fffh; never desire 64k of UMBs Change this line to use 3ffh instead of 0fffh, then your devload will give drivers only 16k instead of 64k in /H UMB mode. Might be too small for other drivers, though. Maybe a nicer workaround would be: mov bx,80h ; first fit, try UMB first, low 2nd ; (4xh is only UMB, 00h iss low only) Change the 80h to 40h, then your devload will never fall back from UMB to low RAM in /H UMB mode. It will just fail to load a driver if not enough UMB is free instead. I think those workarounds should make devload do what you want in YOUR computer, they are just not universal enough to be put into an official version :-) Eric PS: SHELLHIGH would work, but FreeCOM command.com does need more than 100 kB of RAM during startup and your UMB is way too small for that. It only needs 3 kB later, so it is no problem that those 3 kB will be in low RAM :-). - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
