DOS 6.22, DESQview386, QEMM 7.5 and USB Floppy on a Dell 745
Dave R.
posts for some time now, this may be futile, but it is at least worth a
try I suppose. :-)
Anyhow. I have a new Dell Optiplex 745 that uses a USB floppy drive
instead of a "legacy" floppy port. I need to be able to use this floppy
drive in DOS (6.22) under DESQview. It appears that in some ways the
Dell folks have the USB thing pretty well figured out as I can actually
boot to DOS from the USB floppy, and can access the floppy in DOS if I
boot to DOS from the hard drive without loading QEMM386 in config.sys.
However, as soon as I load QEMM386 with the RAM parameter, I lose the
ability to access the USB floppy. The system hangs if I try to pull a
directory from the USB floppy, try to copy a file to or from the USB
floppy, etc. Depending on the other QEMM386 parameters in use, the hang
varies from hard (have to hold the power button for 4 seconds to power
down) to soft (simply pressing the power button works).
I've found that if I exclude all available memory regions that QEMM386
wants to use as High RAM, the system doesn't hang when I access the USB
floppy. For example:
DEVICE=QEMM386.SYS RAM X=B000-B7FF X=D000-DFFF
This works and allows me to access the USB floppy, but of course then I
don't have any high memory I can use.
Looking at the memory with Manifest shows that A000-AFFF and B800-BFFF
are Video, C000-CFFF and F000-FFFF are ROM and E000-EFFF is Page Frame.
If I then allow ANY section of memory to be mapped as High RAM, I'm back
to square one. For example:
DEVICE=QEMM386.SYS RAM X=B100-B7FF X=D000-DFFF
DEVICE=QEMM386.SYS RAM X=B000-B6FF X=D000-DFFF
DEVICE=QEMM386.SYS RAM X=B000-B7FF X=D100-DFFF
DEVICE=QEMM386.SYS RAM X=B000-B7FF X=D000-DEFF
All cause a system hang when I access the USB floppy. In the past, when
I've had conflicts or other problems with QEMM/DESQview, I've always
been able to identify which region of memory is causing my problem, but
this one has me stumped.
I really need to get this working if at all possible. Any help will be
much appreciated.
Regards,
Dave
buck
I rather doubt that this will help, but here's what I would do:
config.sys
DEVICE=QEMM386.SYS ON
autoexec.bat
DIR A:
Obviously,. you need a diskette with something on it in A:
Look in MFT to see if you see accesses to any high memory area after
booting that, and exclude all such areas. Reboot and run OPTIMIZE
(and pray).
You will almost certainly be better served to use a normal floppy
drive. Since QEMM was long before USB there isn't a lot of chance
that you can make this work, and the cost of the floppy drive,
controller and cable is worth a lot less than your sanity.
--
buck
BobCP
Dave R.
news:1d4ud3hr2us4grj1s...@4ax.com...
>
> I rather doubt that this will help, but here's what I would do:
>
> config.sys
> DEVICE=QEMM386.SYS ON
>
> autoexec.bat
> DIR A:
>
> Obviously,. you need a diskette with something on it in A:
>
> Look in MFT to see if you see accesses to any high memory area after
> booting that, and exclude all such areas. Reboot and run OPTIMIZE
> (and pray).
I hadn't thought of forcing OPTIMIZE to see the USB floppy access that
way, but alas it didn't work. It did manage to get OPTIMIZE stuck in a
loop though, which was somewhat entertaining...
>
> You will almost certainly be better served to use a normal floppy
> drive. Since QEMM was long before USB there isn't a lot of chance
> that you can make this work, and the cost of the floppy drive,
> controller and cable is worth a lot less than your sanity.
I agree completely. Unfortunately, I don't have many options. I'm
trying to figure this out to be able to support some legacy systems in
the field, and the next model of Dell PCs do not have a normal floppy
drive as an option, and I can't find a PCI add-in floppy controller
card. I'm not looking forward to trying to locate a replacement PC from
another vendor, especially if it ends up involving a custom build.
We've been down that road before, and it wasn't pretty.
Thanks for the response though - I was quite pleasantly surprised to see
anything, especially that quickly.
--
Regards,
Dave
Dave R.
"BobCP" <ctcb...@sbcglobal.net> wrote in message
news:_bGDi.31819$RX.2...@newssvr11.news.prodigy.net...
So far no luck with that (although there are so many different driver
combinations and BIOS configurations that I'm not yet ready to give up).
If I make any progress I'll post back, but it isn't looking very
promising.
And as with buck, thanks for the response - I was quite pleasantly
BobCP
running DV. My setup (networked) is so memory-sensitive, I'm not even
using a CD.
Although I've got a Windows box too...
Dave R.
> Hey! You and I are probably among the few and privileged to be still
> running DV. My setup (networked) is so memory-sensitive, I'm not even
> using a CD.
> Although I've got a Windows box too...
For me, it's more of a situation where I'm the last Neanderthal in the
company so I get to do the maintenance and support for a product based
on DV (although, I confess to enjoying it, perhaps a bit too much! It
must be the challenge...)
I hear you on the tight memory in a big way. Many times I've fought for
hours to free up just a few more bytes to get something working for a
customer. I must say I'm impressed though - you have enough memory to
load network drivers?! Wow, you must be special :-)
Re: Windows, same here - didja know you can run DV inside of Windows?
You can, at least in the NT/2000/XP line, never got it to work in Win9x.
--
Regards,
Dave
BobCP
> For me, it's more of a situation where I'm the last Neanderthal in the
> company so I get to do the maintenance and support for a product based
> on DV (although, I confess to enjoying it, perhaps a bit too much! It
> must be the challenge...)
>
> I hear you on the tight memory in a big way. Many times I've fought for
> hours to free up just a few more bytes to get something working for a
> customer. I must say I'm impressed though - you have enough memory to
> load network drivers?! Wow, you must be special :-)
>
> Re: Windows, same here - didja know you can run DV inside of Windows?
> You can, at least in the NT/2000/XP line, never got it to work in Win9x.
>
Thought about it but video might be a problem, since two of my programs
are run in 800x600.
I've tweeked and tweeked for memory. OS is Novell (DR) Dos, not MS. (I
use Helix for the disk cache instead of the native one.) CT mouse
driver is smaller than anything from the mouse manufacturer. The
network is Lantastic, which takes much less memory than the Novell drivers.
Here's some more information on USB:
http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/?n=Main.Download
Life is good, but complicated...
Richard Bonner
> For me, it's more of a situation where I'm the last Neanderthal in the
> company so I get to do the maintenance and support for a product based
> on DV (although, I confess to enjoying it, perhaps a bit too much! It
> must be the challenge...)
> Dave
*** Why not just run an older computer? Pentium IIs and IIIs can be had
for next to nothing.
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Dave R.
"Richard Bonner" <ak...@chebucto.ns.ca> wrote in message
news:fdhjpt$ii1$4...@Kil-nws-1.UCIS.Dal.Ca...
> Dave R. wrote:
>> For me, it's more of a situation where I'm the last Neanderthal in
>> the
>> company so I get to do the maintenance and support for a product
>> based
>> on DV (although, I confess to enjoying it, perhaps a bit too much!
>> It
>> must be the challenge...)
>> --
>> Dave
>
> *** Why not just run an older computer? Pentium IIs and IIIs can be
> had
> for next to nothing.
>
I wasn't clear in my reply - our company produced the product, and I
have to be able to provide ongoing support for our customers who
purchased it. That includes replacement hardware, which up until now
we've been able to source reasonably easily.
Before anyone states the obvious, I've been banging the drum for years
for our company to end-of-life the product and transition our customers
onto a more sustainable platform. That hasn't happened for a variety of
reasons, which is why I'm now tasked with figuring a way to handle this
latest change from Dell or finding a suitable replacement from another
source.
--
Dave
Richard Bonner
> "Richard Bonner" <ak...@chebucto.ns.ca> wrote:
> > Dave R. wrote:
> >> For me, it's more of a situation where I'm the last Neanderthal in
> >> the company so I get to do the maintenance and support for a product
> >> based on DV (although, I confess to enjoying it, perhaps a bit too
> >> much! It must be the challenge...)
> >> --
> >> Dave
> > *** Why not just run an older computer? Pentium IIs and IIIs can be
> > had for next to nothing.
> I wasn't clear in my reply - our company produced the product, and I
> have to be able to provide ongoing support for our customers who
> purchased it. That includes replacement hardware, which up until now
> we've been able to source reasonably easily.
*** So do your customers run this program on DOS machines, or under
other operating systems?
> Before anyone states the obvious, I've been banging the drum for years
> for our company to end-of-life the product and transition our customers
> onto a more sustainable platform. That hasn't happened for a variety of
> reasons, which is why I'm now tasked with figuring a way to handle this
> latest change from Dell or finding a suitable replacement from another
> source.
> --
> Dave
*** The problem is that there are no sustainable platforms under Windows
because Microsoft keeps changing the "standards" every few years. )-:
You might look into those new DELL DOS machines announced last year.
They run FreeDOS.
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
buck
wrote:
>IMHO one has to make a decision: either QEMM or USB.
>
>Tibor Mocsar
Does USB work with HIMEM and EMM? If no, then you are correct. If
yes, did you try a newer QEMM?
ftp://yesican.chsoft.biz/pub/dv/qemm97.zip
--
buck
Dave R. at dot
and a half ago and I'm just now getting everything back in order.
"Richard Bonner" <ak...@chebucto.ns.ca> wrote in message
news:fe5asa$ddt$9...@Kil-nws-1.UCIS.Dal.Ca...
> Dave R. wrote:
>
>> "Richard Bonner" <ak...@chebucto.ns.ca> wrote:
>
>> > Dave R. wrote:
>> >> For me, it's more of a situation where I'm the last Neanderthal in
>> >> the company so I get to do the maintenance and support for a
>> >> product
>> >> based on DV (although, I confess to enjoying it, perhaps a bit too
>> >> much! It must be the challenge...)
>> >> --
>> >> Dave
>
>> > *** Why not just run an older computer? Pentium IIs and IIIs can
>> > be
>> > had for next to nothing.
>
>> I wasn't clear in my reply - our company produced the product, and I
>> have to be able to provide ongoing support for our customers who
>> purchased it. That includes replacement hardware, which up until now
>> we've been able to source reasonably easily.
>
> *** So do your customers run this program on DOS machines, or under
> other operating systems?
>
Pure DOS machines. DOS 6.22, QEMM 7.5, DESQview 2.42.
>
>> Before anyone states the obvious, I've been banging the drum for
>> years
>> for our company to end-of-life the product and transition our
>> customers
>> onto a more sustainable platform. That hasn't happened for a variety
>> of
>> reasons, which is why I'm now tasked with figuring a way to handle
>> this
>> latest change from Dell or finding a suitable replacement from
>> another
>> source.
>
> *** The problem is that there are no sustainable platforms under
> Windows
> because Microsoft keeps changing the "standards" every few years. )-:
>
There is that, but at this point it seems considerably more likely that
we would be able to find replacement machines for a Windows platform. I
also wouldn't be against a Linux-based system, but I think our tech
support folks would revolt - they already have to support enough
platforms as it is, and since Linux knowledge wasn't a prerequisite when
hiring them, many (most?) of them would be lost without substantial
training. Then of course our developers aren't exactly Linux experts
either.
> You might look into those new DELL DOS machines announced last year.
> They run FreeDOS.
>
It doesn't seem to be the version of DOS as I can access the USB devices
under DOS 6.22, even after loading HIMEM and EMM386. But, as soon as I
load QEMM and allocate a portion of the UMB, it's all over. Also, I
tried getting our system running under FreeDOS a year or so ago and
wasn't able to. QEMM and DV seem to be very closely tied to MSDOS, so
anything less than 100% compatibility doesn't work (at least for me).
Anyway, I should be getting the evaluation machines in soon, so we'll
see what I have to work with. Our Dell rep indicated we weren't the
only ones raising a fuss over the switch to USB floppy drives, so
anything is possible.
--
Regards,
Dave
Dave R. at dot
I had no problems with HIMEM and EMM386 (but couldn't get DV to work
right under those memory managers). I haven't tried that version of
QEMM; I suppose it is worth a try.
--
Regards,
Dave
Klaus Meinhard
> It doesn't seem to be the version of DOS as I can access the USB
> devices under DOS 6.22, even after loading HIMEM and EMM386. But, as
> soon as I load QEMM and allocate a portion of the UMB, it's all over.
It seems that the UMB driver uses some part of upper memory that QEMM
has given to other drivers. One method to try would be to load all other
drivers into low DOS memory, loadhigh only the UMB driver under QEMM and
see if that works. You can then use OPTIMIZE (IIRC) to analyse the
memory area used. Possibly the USB driver needs a lot of upper mem at
startup, and less mem later.
If that works, you can add the other drivers one by one to upper mem
again, testing after each addition. It may be wise to see that the USB
driver is the first one loaded after QEMM.
--
* Klaus Meinhard *
4DOS Info - Info for DOS
www.4dos.info
Dave R. at dot
"Klaus Meinhard" <K_Mei...@t-online.de> wrote in message
news:ff2e6g$me7$00$1...@news.t-online.com...
I thought the same thing (in the past, it's always been a particular
memory region that needed to be excluded) but per my original post, the
only way I can get it to work is to exclude all memory regions. As soon
as I include ANY region, it stops working. Also, I'm not loading any
other drivers (yet), just trying to get this to work.
--
Regards,
Dave
Klaus Meinhard
> I thought the same thing (in the past, it's always been a particular
> memory region that needed to be excluded) but per my original post,
> the only way I can get it to work is to exclude all memory regions. As
> soon as I include ANY region, it stops working. Also, I'm not
> loading any other drivers (yet), just trying to get this to work.
I've really no clue what to do in this case. If it works with Himem /
Emm386, it _should_ work with QEMM. But QEMM is much more agressive in
adding upper mem to its store. There should be a lot of switches to get
that under control, IIRC. Try QEMM /?. Aim for the most conservative
setting, no stealthing.. Also let DOS itself and command.com in the
conventional lower 640 KB.
The desciption of the USB driver may provide some clues about its memory
requirements.
Dave R. at dot
OK, it's time to put this thread to rest (at least, for now). I
received the evaluation PCs, and contrary to the spec sheet, the floppy
drives connect to the motherboard with a standard 34-pin
cable/connector. Once again it appears we've dodged the bullet (well,
that is if I can get the rest of the system working on the new PCs of
course). And once again, I'll redouble my efforts to convince the
decision makers that we HAVE to do something, and soon.
Best regards, and thanks to all that tried to help.
Dave
Richard Bonner
> In article <fe5asa$ddt$9...@Kil-nws-1.UCIS.Dal.Ca>,
> ak...@chebucto.ns.ca (Richard Bonner) wrote:
> >You might look into those new DELL DOS machines announced last year.
> >They run FreeDOS.
> I'm afraid, it wouldn't help. The problem seems to be QEMM, not the
> underlying DOS version.
> I also tried to use USB storage devices, but the system locked up every
> time almost immediatelly. A not very practical workaround was to load
> the USB drivers after the DOS startfiles via devload.com. That way the
> system locks up somewhat later, so one has the chance to use the USB
> device for a while.
> IMHO one has to make a decision: either QEMM or USB.
> Tibor Mocsar
*** I use QEMM 8.1 with a USB flash drive and have no problems. Have you
tried loading only QEMM and the USB drivers to see if that works? Perhaps
it's a conflict with some other device or driver. Do you use QEMM's
OPTIMIZE to handle the drivers?
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Richard Bonner
> I thought the same thing (in the past, it's always been a particular
> memory region that needed to be excluded) but per my original post, the
> only way I can get it to work is to exclude all memory regions. As soon
> as I include ANY region, it stops working. Also, I'm not loading any
> other drivers (yet), just trying to get this to work.
> --
> Dave
*** You don't mention OPTIMIZE, so I suggest that you load the drivers
with the USB one first, and then let OPTIMIZE organise them for you.
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Richard Bonner
> Richard Bonner wrote:
> >I use QEMM 8.1 with a USB flash drive and have no problems.
> That's interesting. Culd you post your startfiles here?
*** Sure. This following CONFIG.sys is for my laptop. It does not load
everything I use because I am having conflict problems with my HP laptop.
It refuses to load USB or WiFi drivers for DOS. This CONFIG.sys is loaded
from a boot floppy which only loads what I need to access my USB
flashdrive and a few other things.
I won't include the AUTOEXEC.bat for this thread as I feel it's not
relevant here.
; DR-DOS CONFIG.sys (2007-04/15)
; USB Version
DEVICE=C:\UTIL\QEMM\DOSDATA.SYS
DEVICE=C:\UTIL\QEMM\QEMM386.SYS RAM BOOTENABLE:N ST:M BE:N XSTI:1A S=F900-F9FF S=FE00-FFFF R:1
DEVICE=C:\UTIL\QEMM\loadhi.sys C:\UTIL\QEMM\QDPMI.SYS swapfile=f:\dpmi.swp swapsize=2048
DOS=HIGH,UMB
DEVICE=C:\UTIL\QEMM\LOADHI.SYS /R:2 /SIZE=56016 C:\UTIL\SPEEWARE\HYPERDKX.EXE /A /C:3072 /F /OK:- /S /XM
BUFFERS=4,1
FCBS=1,1
FILES=60
LASTDRIVE=G
STACKS=0,0
DEVICE=C:\UTIL\QEMM\LOADHI.SYS /R:2 /SIZE=42016 C:\DOS\DOSPLUS\ANSIPLUS\ANSIPLUS.EXE /E
DEVICE=USBASPI.SYS /R /V /W
DEVICE=DI1000DD.SYS
SHELL=C:\DOS\COMMAND.COM C:\DOS\ /E:1920 /P
YEAR2000=OFF
> > Have you tried loading only QEMM and the USB drivers to see if that works?
> > Perhaps it's a conflict with some other device or driver.
> I loaded the USB drivers after my startfiles low, so there could be no
> memory conflicts.
*** Did that work? I can't remember what you said regarding that.
> >Do you use QEMM's OPTIMIZE to handle the drivers?
> I tried that. Optimize never completed the procedure, however, everything
> was fine when USB drivers were not involved.
> Tibor Mocsar
*** Did it issue a message as to why it did not?
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Dave R. at dot
Richard,
Optimize did nothing for me, presumably since I'm not loading any
drivers other than QEMM. And when I tried loading the various USB
drivers that are out there, I lost the ability to use my (USB) keyboard.
I hadn't tried every possible combination of drivers and parameters
before the PCs arrived. Fortunately, since the PCs actually arrived
with standard floppy drive controllers on the motherboard, we have a
(temporary) reprieve.
--
Regards,
Dave
Klaus Meinhard
I maintain that you should simplify your setup for testing. QEMM does a
lot of things automatically, which I don't remember in detail. Even
parts of plain DOS get loaded high into UMBs. Try to stop that using the
appropriate switches. Try reading the docs or the help. If it works
under himem/emm386, it should be possible to get it to work under QEMM.
You just have to even out what they do.
Klaus Meinhard
> *** Sure. This following CONFIG.sys is for my laptop. It does not
> load
> everything I use because I am having conflict problems with my HP
> laptop.
Oh ???
--
Mit freundlichem Gruß,
Klaus Meinhard
Richard Bonner
> "Richard Bonner" <ak...@chebucto.ns.ca> wrote:
> > *** You don't mention OPTIMIZE, so I suggest that you load the
> > drivers with the USB one first, and then let OPTIMIZE organise them
> > for you.
> Richard,
> Optimize did nothing for me, presumably since I'm not loading any
> drivers other than QEMM. And when I tried loading the various USB
> drivers that are out there, I lost the ability to use my (USB) keyboard.
*** What drivers are loaded for the keyboard or is it supporetd by the
cimputer itself? Perhaps there is a conflict with the USB devices and
their different drivers.
> I hadn't tried every possible combination of drivers and parameters
> before the PCs arrived. Fortunately, since the PCs actually arrived
> with standard floppy drive controllers on the motherboard, we have a
> (temporary) reprieve.
> --
> Dave
*** That will eb a help.
Richard Bonner
> Richard Bonner wrote:
> > *** Sure. This following CONFIG.sys is for my laptop. It does not
> > load everything I use because I am having conflict problems with my HP
> > laptop.
> Oh ???
> --
> Klaus Meinhard
*** The laptop came with Windows ME installed. I deleted all that and
installed DR-DOS 7.03. The laptop will not load either DOS USB or WiFi
drivers from the hard drive. It says they are missing or corrupted, but
I know better.
I wonder if somehow there is something that purposely will not allow
this in order to break operating systems other than Windoze. As an
example, when I load Knoppix Linux via a CD, it recognises the sound card
but it will not work. Nor will it under DOS. )-:
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Richard Bonner
> ak...@chebucto.ns.ca (Richard Bonner) wrote:
> >Tibor Mocsar (t...@justmail.de) wrote:
> >
> >> Richard Bonner wrote:
> >> >I use QEMM 8.1 with a USB flash drive and have no problems.
> >
> >> That's interesting. Culd you post your startfiles here?
> >
> >*** Sure. This following CONFIG.sys is for my laptop.
(Snip)
> Well, actually I do not see anything special, unless that you use
> (E)DRDOS, which has a different kernel than my MSDOS.
*** Well, if any DOS is compatible with MS-DOS, I would vote DR-DOS as
the closest. As an example, MS-DOS 6.2 will run DR-DOS 6 external
commands natively. This is not to say that there are no differences,
though.
> >> I loaded the USB drivers after my startfiles low, so there could be no
> >> memory conflicts.
> >
> >*** Did that work? I can't remember what you said regarding that.
> It works for a couple of minutes before the computer freezes.
*** Hmm, so they will load, but a conflict is confusing the system so
it halts because it does not know what to do.
> >> >Do you use QEMM's OPTIMIZE to handle the drivers?
> >> I tried that. Optimize never completed the procedure, however, everything
> >> was fine when USB drivers were not involved.
> >*** Did it issue a message as to why it did not?
> No, it simply hung.
> Telling frankly, I got tired of the troubles with USB and QEMM. I need
> QEMM because I need DV, USB would be fine but I can live without it
> if I have to. I hold it with Kant: "Only those are really free, who
> know the limits."
> Tibor Mocsar
*** Ok. My next suggestion would be to use a non-USb keyboard if a port
is available and try again.
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Dave R. at dot
> Dave R. (dwragle(at)drbsystems(dot)com) wrote:
>
>> "Richard Bonner" <ak...@chebucto.ns.ca> wrote:
>> > *** You don't mention OPTIMIZE, so I suggest that you load the
>> > drivers with the USB one first, and then let OPTIMIZE organise them
>> > for you.
>
>> Richard,
>
>> Optimize did nothing for me, presumably since I'm not loading any
>> drivers other than QEMM. And when I tried loading the various USB
>> drivers that are out there, I lost the ability to use my (USB)
>> keyboard.
>
> *** What drivers are loaded for the keyboard or is it supporetd by
> the
> cimputer itself? Perhaps there is a conflict with the USB devices and
> their different drivers.
No drivers for the keyboard, it appears to be handled by the BIOS.
Also, this is a known problem in the DOS USB community. I've seen a
number of discussions about this behavior, and at least one of the
drivers has a switch that can be set to not reset (and keep the driver
from handling) USB devices being handled by the BIOS. In my case, that
means the driver doesn't do anything with the USB floppy either since it
is also being handled by the BIOS. I can't win.
>> I hadn't tried every possible combination of drivers and parameters
>> before the PCs arrived. Fortunately, since the PCs actually arrived
>> with standard floppy drive controllers on the motherboard, we have a
>> (temporary) reprieve.
>
> *** That will eb a help.
Yep, for now anyway. This should give us 12 to 18 months to either
transition the product to another OS or find a solution for the QEMM
problem.
Dave R. at dot
I don't see how my setup can be simplified any further. I'm not loading
any drivers other than QEMM. Here's my CONFIG.SYS:
DEVICE=QEMM386.SYS RAM X=B000-B7FF X=D000-DFFF
Yes, that's the only line. The software we need to run on this platform
relies on the RAM parameter creating High RAM to allow access to the
UMB. I've got everything turned off in the BIOS other than the hard
drive, on-board video and the USB ports. Manifest shows that A000-AFFF
and B800-BFFF are Video, C000-CFFF and F000-FFFF are ROM and E000-EFFF
is Page Frame, so the X= parameters just prevent the remaining high
memory areas from being used as High RAM.
I've read the manual over and over and tried the various switches that
control QEMM's behavior until I'm sick of it. The end result is always
the same (except when I select a parameter that hangs the system on its
own, of course...) - everything is fine until I include a memory region,
at which point it stops working. I've tried Optimize and all it does
is hang and force a hard reboot, recognize that this has happened and
offer to try with less aggressive settings, and we end up in an endless
loop.
I agree, if himem/emm386 it works, it *should* be possible to get it
working with QEMM. However, it just isn't happening. As another poster
indicated, I'm not using the very latest version of QEMM, so that might
help but it will have to wait. We would have to do a more extensive
system and regression test to qualify a new version of QEMM for the
product, but if that's what it takes, so be it. However, I've
back-burnered the project for now since the PCs arrived with standard
floppy controllers, and will pick it back up (if necessary) when this
run of PCs is flagged as EOL.
Regards,
Dave
Richard Bonner
> "Klaus Meinhard" <K_Mei...@t-online.de> wrote:
> > I maintain that you should simplify your setup for testing. QEMM does
> > a lot of things automatically, which I don't remember in detail. Even
> > parts of plain DOS get loaded high into UMBs. Try to stop that using
> > the appropriate switches. Try reading the docs or the help. If it
> > works under himem/emm386, it should be possible to get it to work
> > under QEMM. You just have to even out what they do.
> I don't see how my setup can be simplified any further. I'm not loading
> any drivers other than QEMM. Here's my CONFIG.SYS:
> DEVICE=QEMM386.SYS RAM X=B000-B7FF X=D000-DFFF
*** Are you using QEMM to load the DOS USB drivers?
You could look at the eXclude parameters in QEMM, but I am suspicious
of the possible conflict between the built-in USB support and your
external drivers.
> I've read the manual over and over and tried the various switches that
> control QEMM's behavior until I'm sick of it. The end result is always
> the same (except when I select a parameter that hangs the system on its
> own, of course...) - everything is fine until I include a memory region,
> at which point it stops working. I've tried Optimize and all it does
> is hang and force a hard reboot, recognize that this has happened and
> offer to try with less aggressive settings, and we end up in an endless
> loop.
*** Are you actively including memory regions or are just letting QEMM
use whatever is not eXcluded?
> I agree, if himem/emm386 it works, it *should* be possible to get it
> working with QEMM. However, it just isn't happening. As another poster
> indicated, I'm not using the very latest version of QEMM, so that might
> help but it will have to wait. We would have to do a more extensive
> system and regression test to qualify a new version of QEMM for the
> product, but if that's what it takes, so be it. However, I've
> back-burnered the project for now since the PCs arrived with standard
> floppy controllers, and will pick it back up (if necessary) when this
> run of PCs is flagged as EOL.
> Dave
*** It might be best to try to get further before a looming deadline
puts pressure on all this. To test, get a newer version of QEMM and see if
the problem persists. At least, you will have gotten that far.
Richard
Dave R. at dot
> Dave R. (dwragle(at)drbsystems(dot)com) wrote:
>
>> "Klaus Meinhard" <K_Mei...@t-online.de> wrote:
>> > I maintain that you should simplify your setup for testing. QEMM
>> > does
>> > a lot of things automatically, which I don't remember in detail.
>> > Even
>> > parts of plain DOS get loaded high into UMBs. Try to stop that
>> > using
>> > the appropriate switches. Try reading the docs or the help. If it
>> > works under himem/emm386, it should be possible to get it to work
>> > under QEMM. You just have to even out what they do.
>
>> I don't see how my setup can be simplified any further. I'm not
>> loading
>> any drivers other than QEMM. Here's my CONFIG.SYS:
>
>> DEVICE=QEMM386.SYS RAM X=B000-B7FF X=D000-DFFF
>
> *** Are you using QEMM to load the DOS USB drivers?
>
Not at this point. I had tried loading them withotu any memory
management early on in the process and wasn't able to get the DOS USB
drivers to work at the same time as a USB keyboard.
> You could look at the eXclude parameters in QEMM, but I am
> suspicious
> of the possible conflict between the built-in USB support and your
> external drivers.
>
>
>> I've read the manual over and over and tried the various switches
>> that
>> control QEMM's behavior until I'm sick of it. The end result is
>> always
>> the same (except when I select a parameter that hangs the system on
>> its
>> own, of course...) - everything is fine until I include a memory
>> region,
>> at which point it stops working. I've tried Optimize and all it
>> does
>> is hang and force a hard reboot, recognize that this has happened and
>> offer to try with less aggressive settings, and we end up in an
>> endless
>> loop.
>
> *** Are you actively including memory regions or are just letting
> QEMM
> use whatever is not eXcluded?
Both. I get the same result either way.
>
>
>> I agree, if himem/emm386 it works, it *should* be possible to get it
>> working with QEMM. However, it just isn't happening. As another
>> poster
>> indicated, I'm not using the very latest version of QEMM, so that
>> might
>> help but it will have to wait. We would have to do a more extensive
>> system and regression test to qualify a new version of QEMM for the
>> product, but if that's what it takes, so be it. However, I've
>> back-burnered the project for now since the PCs arrived with standard
>> floppy controllers, and will pick it back up (if necessary) when this
>> run of PCs is flagged as EOL.
>
>> Dave
>
> *** It might be best to try to get further before a looming deadline
> puts pressure on all this. To test, get a newer version of QEMM and
> see if
> the problem persists. At least, you will have gotten that far.
>
I agree, and will try to devote time to finding a solution, but my
ability to do so is limited by management. "We might have a big problem
in a year or so when the next PC is released!" in their minds doesn't
justify me spending a lot of time looking for a solution now. Part of
the problem is we have a "chicken little" engineer on staff who has been
forecasting doom and gloom for the past 10 years. His mantra has been
to proclaim "Within a year from today, we won't be able to get parallel
ports / serial ports / you name it on anthing except very expensive
custom motherboards." We get this sort of thing regularly, at least once
a year, so when I raise a concern like this one, well, you get the idea.
It also didn't help that they ended up delivering PCs with standard
floppy controllers. Now *I* look like another chicken little. Sigh.
The only thing that keeps me from looking completely lame is that I have
the spec sheet from Dell that shows a USB floppy as the only option.
That said, I've downloaded a newer QEMM and plan on spending the time
necessary to try to get a working solution so that I can be the hero
when/if they drop support. Simultaneously, I'm pushing hard to start
porting the product to Windows as soon as we can so that we have both
bases covered.
Regards,
Dave
Richard Bonner
> "Richard Bonner" <ak...@chebucto.ns.ca> wrote:
> > Dave R. (dwragle(at)drbsystems(dot)com) wrote:
> >
> >> "Klaus Meinhard" <K_Mei...@t-online.de> wrote:
> > "Richard Bonner" <ak...@chebucto.ns.ca> wrote:
> > *** Are you using QEMM to load the DOS USB drivers?
> Not at this point. I had tried loading them without any memory
> management early on in the process and wasn't able to get the DOS USB
> drivers to work at the same time as a USB keyboard.
*** This must be it. I see it as two drivers competing with one
another for control of USB devices.
> > *** It might be best to try to get further before a looming deadline
> > puts pressure on all this. To test, get a newer version of QEMM and
> > see if the problem persists. At least, you will have gotten that far.
> I agree, and will try to devote time to finding a solution, but my
> ability to do so is limited by management. "We might have a big problem
> in a year or so when the next PC is released!" in their minds doesn't
> justify me spending a lot of time looking for a solution now.
*** One could say that at any time because a new one will be released
the year after that. This is a complaint of mine: Manufacturers are
artificially making things obsolete to force people to buy the same
things over and over. )-:
> Part of
> the problem is we have a "chicken little" engineer on staff who has been
> forecasting doom and gloom for the past 10 years. His mantra has been
> to proclaim "Within a year from today, we won't be able to get parallel
> ports / serial ports / you name it on anthing except very expensive
> custom motherboards."
*** Actually, at a computer club meeting earlier this year, one member
showed a new case setup. It included every port, connector, and controller
contained on PCs for about the past 20 years. *Any* hardware would work
with it.
> That said, I've downloaded a newer QEMM and plan on spending the time
> necessary to try to get a working solution so that I can be the hero
> when/if they drop support.
*** Hopefully, this will solve the problem.
> Simultaneously, I'm pushing hard to start
> porting the product to Windows as soon as we can so that we have both
> bases covered.
>
> Dave
*** Except that Microsoft will change that base as soon as they
can. )-:
Richard