VOGONS

Common searches


First post, by Kurasiu

User metadata
Rank Newbie
Rank
Newbie

Well, dang. First the sound card problems, and now this. I didn't know about this issue, as my low memory had only ~550 KB of free space (strangely even with a "clean" autoexec/config, with DOS=HIGH,UMB and devicehigh's used), which wasn't enough for several DOS games (as a reminder - using Windows 98 ).

So I installed QEMM 97, let it handle things with Optimize command and after several reboots eveything seemed to work like a charm - 614 KB of conventional memory free, looked fine and dandy. Well, expect not.

I tried to run several DOS games (Ultima Underworld, Monster Bash, Bolz etc.). I was happy at first, as every single one of them ran without any problems. However also evey one of them hard crashed the computer, mostly during loading sequences. (UU during dungeon entering, Monster Bash and Bolz during level load, Construction Bob during next batch of levels etc.) Same thing occurs when running the game in both MS-DOS mode reboot and Windows 98.

Could it be the QEMM's doing?

Reply 1 of 15, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

Quite possibly. Many DOS games came with warnings about running with QEMM in "stealth" mode. The Windows components of QEMM97 are of rather dubious value as well.

If you really want answers, posting your current autoexec.bat and config.sys would be a good start.

Reply 2 of 15, by Kurasiu

User metadata
Rank Newbie
Rank
Newbie

Yes, of course. Here they are, in the meantime I uninstalled QEMM and cleaned the config and autoexec. And well, the games are still crashing (at least those which I can run). I seriously have no idea what to do. System issue or what?

//autoexec mode con codepage prepare=((852) C:\WINDOWS\COMMAND\EGA.CPI) mode con codepage select=852 keyb pl,,C:\WINDOWS\COMMAND […]
Show full quote

//autoexec
mode con codepage prepare=((852) C:\WINDOWS\COMMAND\EGA.CPI)
mode con codepage select=852
keyb pl,,C:\WINDOWS\COMMAND\keybrd4.sys
LOADHIGH C:\DOSDRV\CTMOUSE.EXE

//config files=40 buffers=40 lastdrive=f DEVICE=C:\WINDOWS\HIMEM.SYS DEVICE=C:\WINDOWS\EMM386.EXE DOS=HIGH,UMB DEVICEHIGH=C:\WIN […]
Show full quote

//config
files=40
buffers=40
lastdrive=f
DEVICE=C:\WINDOWS\HIMEM.SYS
DEVICE=C:\WINDOWS\EMM386.EXE
DOS=HIGH,UMB
DEVICEHIGH=C:\WINDOWS\COMMAND\display.sys con=(ega,,1)
Country=048,852,C:\WINDOWS\COMMAND\country.sys

mem /c /p returns that MSDOS, HIMEM, EMM386, DBLUBFF, DISPLAY, IFSHLP, WIN, KEYB, CTMOUSE and COMMAND are loaded into conventional memory (despite loadhigh/devicehigh), leaving me with 555 KB of free space.

Reply 3 of 15, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

As per the other thread, DOS=HIGH,UMB should be before EMM386 but after HIMEM. I'm not sure if it makes a difference having the files=,buffers=,and lastdrive= lines at the top, but you might want to move them to the bottom to see if that changes anything.

If you have fiddled too much with your BIOS settings, that might also be causing a colorful variety of problems, of course.

Reply 4 of 15, by Davros

User metadata
Rank l33t
Rank
l33t

Try this

DEVICE=C:\WINDOWS\HIMEM.SYS
DOS=HIGH,UMB (also try DOS=HIGH)
DEVICE=C:\WINDOWS\EMM386.EXE NOEMS
DEVICEHIGH=C:\WINDOWS\COMMAND\display.sys con=(ega,,1)
Country=048,852,C:\WINDOWS\COMMAND\country.sys
lastdrivehigh=f

ps: this is restart in msdos mode, yes ?

Guardian of the Sacred Five Terabyte's of Gaming Goodness

Reply 5 of 15, by Kurasiu

User metadata
Rank Newbie
Rank
Newbie
Jorpho wrote:

If you have fiddled too much with your BIOS settings, that might also be causing a colorful variety of problems, of course.

Didn't really change this much in BIOS (to tell the truth I only turned on USB support, other than that I only looked for those NMI settings), but nevertheless I loaded fail-safe settings. Changed the DOS line/proposed settings by Davros in config as well.

But I still have no way to test the new settings, as my conventional memory is cluttered with all those drivers. Yeah, still, even with HIGH's everything is loaded into low memory.

Reply 6 of 15, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

Well, you're using Polish Windows, right? There's the famous bug in international versions of HIMEM.SYS, but I keep forgetting whether it was fixed in Windows 98.
http://madsenworld.dk/con_auto/index-uk.htm#io2patch
(See also OSR2FIX at http://www.mdgx.com/dos.htm .)

Rather than muck around with patches, it might be best to just try using HIMEMX in place of HIMEM.SYS and see if that solves the problem.
http://www.japheth.de/Jemm.html

HIMEMX is by all accounts quite harmless (and apparently works much better than HIMEM.SYS in some ways).

Reply 7 of 15, by Kurasiu

User metadata
Rank Newbie
Rank
Newbie

You're a wizard, Jorpho! Everything in DOS runs nice and smooth now. 😁 Yes, I guess my polish copy of Windows 98 was affected by the bug, as using Himemx and Jemm did the trick, now I have a whooping 614 KB of free space. Tried to run the most crashing game several times (Monster Bash) with different fiddling (saving, finishing levels etc.) and it didn't crash even once, so I guess other games will work just fine too.

However I'm getting a strange error during Windows booting up. While I can use the DOS mode, loading Windows results in (pardon my shabby translation) "Can't start Windows, when a, currently used, protected mode program is running. Close this protected mode program and try running Windows again." Any special options needed for the Himemx and Jemm? I'm loading them via DEVICE=, like the older himem and emm386. I guess the solution lies somewhere in the manual, though I'd like to ask the pro here. 😜

Reply 8 of 15, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Don't load anything in config.sys or autoexec.bat when booting Windows:

  • Turn off Windows auto-boot by setting BootGUI=0 in C:\MSDOS.SYS (random article: http://www.techrepublic.com/article/customize … ys-file/1056250 )
  • Make boot menus in config.sys that let you choose different paths to take through your config.sys and autoexec.bat files (random article: http://technet.microsoft.com/en-us/library/cc749871.aspx )
  • For the Windows path, don't load anything except for Windows itself (via C:\Windows\win.com in autoexec.bat)
  • For the DOS path load all your DOS stuff (memory managers, etc.).
  • After you've done all this, reboot the computer to switch between pure DOS and "pure" Windows.

This is exactly what I did on my 486DX4-120 with Win95 back in the day, and it worked great.

Edit: If you need help with the menus, post your latest config.sys and autoexec.bat.

Reply 9 of 15, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
Kurasiu wrote:

However I'm getting a strange error during Windows booting up. While I can use the DOS mode, loading Windows results in (pardon my shabby translation) "Can't start Windows, when a, currently used, protected mode program is running. Close this protected mode program and try running Windows again." Any special options needed for the Himemx and Jemm? I'm loading them via DEVICE=, like the older himem and emm386. I guess the solution lies somewhere in the manual, though I'd like to ask the pro here. 😜

Oh, I haven't been able to get Jemm to work with Windows either on my Pentium 4. (You would think the programmer could have found a more elegant solution that doesn't bring Windows crashing down, and I do find it a little odd that he doesn't mention it in the readme at all.)

HIMEMX is the important thing here. You can keep on using EMM386 with it if you want; if you find Jemm works better for one reason or another, you will have to set up a boot menu, as Mr. HunterZ suggests.

Reply 10 of 15, by Kurasiu

User metadata
Rank Newbie
Rank
Newbie

Haha, oh man, let me know, when you'll be around Poland, guys - I'll definitely buy you a beer. 😁 Everything works like a charm, installed and played BioForge and Ultima VIII this morning (from the original CDs), and played'em for like a good hour or so, without any problems. Topic aside, one question - any better way to use CD Rom under DOS? MSCDEX is fine, but it's gobbling up a whipping 24 KBs of memory.

Yeah, such custom boot menu would be a great choice, as I actually need a quick access to Windows, DOS and DOS without any EMM (for certain games, like Ultima VII). However I'll do this, when I return home from spring break, I'll keep you mates informed, when there shall be any trouble. 😉

Reply 11 of 15, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
Kurasiu wrote:

Topic aside, one question - any better way to use CD Rom under DOS? MSCDEX is fine, but it's gobbling up a whipping 24 KBs of memory.

SHSUCDX, definitely.
http://johnson.tmfc.net/dos/shsucdx.html

I think the Jemm documentation talks about some special Jemm-loadable module for CD-ROM access, but I've never messed with that.

If you're still using the Oak device driver in your config.sys, there may be some better alternatives; http://www.mdgx.com/newtip1.htm#CDROM4 suggests XGCDROM.

Last edited by Jorpho on 2013-03-22, 14:52. Edited 1 time in total.

Reply 12 of 15, by jwt27

User metadata
Rank Oldbie
Rank
Oldbie
Kurasiu wrote:

However I'm getting a strange error during Windows booting up. While I can use the DOS mode, loading Windows results in (pardon my shabby translation) "Can't start Windows, when a, currently used, protected mode program is running. Close this protected mode program and try running Windows again." Any special options needed for the Himemx and Jemm? I'm loading them via DEVICE=, like the older himem and emm386. I guess the solution lies somewhere in the manual, though I'd like to ask the pro here. 😜

Loading Jemm puts the CPU in protected mode (virtual x86 mode), that's probably what windows is complaining about. If you don't use EMS memory then I would recommend to use XMGR and UMBPCI, that will give you UMBs and XMS without EMS, and will leave the cpu in real mode.

Reply 13 of 15, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
jwt27 wrote:

Loading Jemm puts the CPU in protected mode (virtual x86 mode), that's probably what windows is complaining about.

Well, the thing is that EMM386 also puts the CPU in protected mode. Apparently Windows knows how to gracefully take over from EMM386, though.

Reply 14 of 15, by jwt27

User metadata
Rank Oldbie
Rank
Oldbie
Jorpho wrote:
jwt27 wrote:

Loading Jemm puts the CPU in protected mode (virtual x86 mode), that's probably what windows is complaining about.

Well, the thing is that EMM386 also puts the CPU in protected mode. Apparently Windows knows how to gracefully take over from EMM386, though.

Probably because EMM386 is also made by MS, so they know how it works and how to unload it, but they don't have a clue what Jemm is. OR they just pretend they don't know and throw error messages just to force you to use their inferior EMM 🤣

Reply 15 of 15, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
jwt27 wrote:
Jorpho wrote:
jwt27 wrote:

Loading Jemm puts the CPU in protected mode (virtual x86 mode), that's probably what windows is complaining about.

Well, the thing is that EMM386 also puts the CPU in protected mode. Apparently Windows knows how to gracefully take over from EMM386, though.

Probably because EMM386 is also made by MS, so they know how it works and how to unload it, but they don't have a clue what Jemm is. OR they just pretend they don't know and throw error messages just to force you to use their inferior EMM 🤣

QEMM manages it too, though (at least in theory).

I think I came across a post stating that the author of Jemm simply didn't want to bother throwing in a whole bunch of kludges just to please Windows.