kmcvay@oneb (Ken McVay) (06/29/90)
I recently installed DV386 (2.26) on a 386/25MHz machine with a Quadtel BIOS and 2048k of RAM - the top meg's extended in BIOS. DV's install seemed to work - ie DV's setup ran, and I configured it as I wanted it - but when I added QEMM to the mix, DV locked up tighter'n a witch's....aw, you know.... I eliminated everything that I didn't need - no ansi.sys, etc. and moved the video and system from shadow RAM to ROM, in an attempt to eliminate sources of address conflict - I loaded QEMM.SYS in a variety of ways: device=qemm.sys device=qemm.sys RAM etc... QEMM loads, but no matter how I set things up, DV won't run without locking up - what would seem to be a clear sign of conflict. Before I spend more time twiddling with things, I thought I'd see if there's anything the doc's have left out, or anything I might have overlooked in my enthusiam to get the beastie working....I have Manifest, and can get detailed information using it and QEMM's various reports, but nothing that suggests where the conflict may be.... The O/S is PC-DOS 3.3..... Any suggestions?
reisert@ricks.enet.dec.com (Jim Reisert) (06/29/90)
In article <268acbc5-65comp.sys.ibm.pc@oneb>, kmcvay@oneb (Ken McVay) writes... >I recently installed DV386 (2.26) on a 386/25MHz machine with a Quadtel BIOS >and 2048k of RAM - the top meg's extended in BIOS. > >DV's install seemed to work - ie DV's setup ran, and I configured it as I >wanted it - but when I added QEMM to the mix, DV locked up tighter'n a >witch's....aw, you know.... I had a similar problem. It turned out that QEMM was mapping already-mapped video ROM to RAM. What I believe happened was that video ROM at address C000-C7FF was mapped to RAM at E000-E7FF by the system. QEMM thought that E000-E7FF was free (it didn't know about the mapping), so it loaded DESQview there. And the system hung. The solution was to EXCLUDE E000-E7FF in the QEMM.SYS line and everything was fine after that. How to find out? Reboot w/o running QEMM. Run Manifest (which I hope you got with DESQview) and take note of the memory map between 640K and 1M. Then reboot with QEMM loaded (no DESQview) and run Manifest again, to see what QEMM thinks is free RAM. What you may find is that Manifest w/o QEMM reported a ROM (or mapped ROM) somewhere that Manifest w/ QEMM now thinks is free memory. You will therefore have to EXCLUDE this memory when you start up QEMM.SYS. Finally, I believe part of the installation process is to copy XDV.COM to DV.COM. XDV is a version of DESQview that can load itself into high RAM. Try deleting DV.COM (you should still have DV.EXE, and XDV.COM) there and run DV again. I found that when I had the problem above, DV.EXE would run but XDV.COM would crash the system. Hope this helps. jim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "The opinions expressed here in no way represent the views of Digital Equipment Corporation." James J. Reisert Internet: reisert@ricks.enet.dec.com Digital Equipment Corp. UUCP: ...decwrl!ricks.enet!reisert 77 Reed Road Hudson, MA 01749-2895
simon@hpspwr.enet.dec.com (Curiosier and curiosier...) (06/29/90)
In article <12971@shlump.nac.dec.com>, reisert@ricks.enet.dec.com (Jim Reisert) writes... >In article <268acbc5-65comp.sys.ibm.pc@oneb>, kmcvay@oneb (Ken McVay) writes... > >>DV's install seemed to work - ie DV's setup ran, and I configured it as I >>wanted it - but when I added QEMM to the mix, DV locked up tighter'n a >>witch's....aw, you know.... > >I had a similar problem. It turned out that QEMM was mapping already-mapped >video ROM to RAM. What I believe happened was that video ROM at address >C000-C7FF was mapped to RAM at E000-E7FF by the system. QEMM thought that >E000-E7FF was free (it didn't know about the mapping), so it loaded DESQview >there. And the system hung. The solution was to EXCLUDE E000-E7FF in the >QEMM.SYS line and everything was fine after that. > You should also check if your system does ROM (both system and video) shadowing. If it does, you should disable it and let QEMM do this task. You may have a conflict between the system and QEMM trying to use the same segments. --------- Leo Simon simon@pwrvax.enet.dec.com Who is not liberal when young, does not have a heart. Who is not conservative when old, does not have a brain. -- W. Churchill
dmurdoch@watstat.uwaterloo.ca (Duncan Murdoch) (06/30/90)
In article <12972@shlump.nac.dec.com> simon@hpspwr.enet.dec.com (Curiosier and curiosier...) writes: > >You should also check if your system does ROM (both system and video) >shadowing. If it does, you should disable it and let QEMM do this task. >You may have a conflict between the system and QEMM trying to use the >same segments. Actually, if you've got a Chips & Technologies chipset, you lose some memory by doing this. The chipset always saves about 200K for shadowing, whether you use it or not; telling QEMM to do the shadowing costs you memory outside this 200K. At least that's the way it works in my machine... Duncan Murdoch
david@csource.OZ.AU (david nugent) (07/01/90)
In <268acbc5-65comp.sys.ibm.pc@oneb> kmcvay@oneb (Ken McVay) writes: >I recently installed DV386 (2.26) on a 386/25MHz machine with a Quadtel >BIOS and 2048k of RAM - the top meg's extended in BIOS. > >DV's install seemed to work - ie DV's setup ran, and I configured it as I >wanted it - but when I added QEMM to the mix, DV locked up tighter'n a >witch's....aw, you know.... > >I eliminated everything that I didn't need - no ansi.sys, etc. and moved the >video and system from shadow RAM to ROM, in an attempt to eliminate sources >of address conflict - I loaded QEMM.SYS in a variety of ways: > >device=qemm.sys >device=qemm.sys RAM >etc... > >QEMM loads, but no matter how I set things up, DV won't run without locking >up - what would seem to be a clear sign of conflict. There's unfortunately no real short-cut; it takes a *lot* of trial and error on some machines. Your best bet is trying to contact QuaterDeck to see if they know of anyone who's been there before. I'm surprised it didn't work without the RAM statement in there though; I've only ever come across one machine where QEMM just plain refused to run. It had a 1989 AMI BIOS, though I don't recall which revision off- hand. Never found out why, though 386^MAX from Qualitas worked fine. BTW, if you run a VGA, try it with a CGA or EGA card. If it works, then it's pretty obvious where the conflict is. QEMM seems to have problems with some, particularly some Genoa cards. david -- _______________________________________________________________________________ Unique Computing Pty Ltd Melbourne Australia - Communications Specialists david@csource.oz.au 3:632/348@fidonet 28:4100/1@signet
ppa@hpldola.HP.COM (Paul Austgen) (07/03/90)
Rather than using the RAM statement raw, you have to decide where the memory conflicts are. I used Manifest, and it even missed a conflict. Get rid of the RAM statement, and use RAM= with trial and error. (Or use EXCLUDE=). I have shadow ram, and I let the machine allocate it, rather than shutting it off.
djb@bbt.UUCP (beauvais) (07/03/90)
In article <268acbc5-65comp.sys.ibm.pc@oneb> kmcvay@oneb (Ken McVay) writes: >I recently installed DV386 (2.26) >DV's install seemed to work - ie DV's setup ran, and I configured it as I >wanted it - but when I added QEMM to the mix, DV locked up tighter'n a It appears that you installed DV then QEMM... It's supposed to be the other way around. QEMM then DV. Hope that does the trick for you. -- Dan Beauvais ...!mcnc!rti!bbt!djb BroadBand Technologies, Inc. +1(919)-544-6850 x 295 Box 13737 Research Triangle Park, NC 27709-3737
mlord@bwdls58.bnr.ca (Mark Lord) (07/06/90)
In article <11250142@hpldola.HP.COM> ppa@hpldola.HP.COM (Paul Austgen) writes: >Rather than using the RAM statement raw, you have to decide where >the memory conflicts are. I used Manifest, and it even missed a >conflict. Get rid of the RAM statement, and use RAM= with trial >and error. (Or use EXCLUDE=). I have shadow ram, and I let the >machine allocate it, rather than shutting it off. Beware of using multiple RAM= statements when using the OPTIMIZE thingie. It has trouble with this, but fails to tell you about it! Instead, use RAM by itself, along with INCLUDE= and EXCLUDE= as appropriate. ___Mark S. Lord______________________________________________ | ..uunet!bnrgate!bmerh614!mlord | These are my opinions only.| |________________________________|____________________________|
ppa@hpldola.HP.COM (Paul Austgen) (07/10/90)
> / hpldola:comp.sys.ibm.pc / mlord@bwdls58.bnr.ca (Mark Lord) / 1:48 pm Jul 5, 1990 / > In article <11250142@hpldola.HP.COM> ppa@hpldola.HP.COM (Paul Austgen) writes: > > Beware of using multiple RAM= statements when using the OPTIMIZE thingie. > It has trouble with this, but fails to tell you about it! > > Instead, use RAM by itself, along with INCLUDE= and EXCLUDE= as appropriate. > My point was, which I didn't get across very well, that OPTIMIZE isn't a very good thing to use at all. I recommend running it once to give one an idea what it is trying to do, and to get the syntax examples. Then, start with a clean file, and add your own so you have things under control. Just jamming in a RAM statement as OPTIMIZE does is just not elegant enough. Also, it messed up my Prompt declaration. The deal is that the program is trying to edit an ascii file without human intervention. Just too many factors to be likely to work correctly.