Name: NateC Date: August 21, 2007 at 11:11:18 Pacific Subject: DOS gaming OS: Windows 98 DOS CPU/Ram: PMMX 233/64MB Model/Manufacturer: clone
Comment:
Okay, I have a couple problems.
One, I have a couple CD's which my CD-ROM refuses to recognise in DOS - but it will recognise them in Windows.
It's the Redneck Rampage Family Reunion pack; to an extent, it's ot of super-great concern in that the game doesn't need the CD's to play. However, the game's soundtrack is CD-only. I know that the CD-ROM in this machine has had problems with games that have very specific security devices on the CD's themselves (such as a lot of recent Blizzard titles), and if that's the case...well, I have extra CD-ROM's. However, this is a DOS game.
The other thing is, I need to free up memory from the 640k barrier; I only have access to 570 KB, which is causing problems with two games - The Elder Scrolls: Arena, which I can't play in DOSBox on my main machine because my Celeron just can't handle it, and the other is Syndicate, which I can DOSBox.
Now, I was thinking of loading my CD-ROM into upper memory, but I'm wondering what the consequences of that are.
Also, is it possible to load sound drivers into upper memory?
If you guys need to see my autoexec and config files, no problem. However, I'll have to switch machines, which I'd rather not do (they aren't networked because the 233 doesn't have a NIC), but if I have to, I will.
One, I have a couple CD's which my CD-ROM refuses to recognise in DOS - but it will recognise them in Windows.
What driver are you using (XCDROM, etc.) ? Also, are you using SHSUCDX or MSCDEX?
Now, I was thinking of loading my CD-ROM into upper memory, but I'm wondering what the consequences of that are.
Unless your specific driver has an issue with that, it should be OK.
Also, is it possible to load sound drivers into upper memory?
Depends on the sound card. Btw, you have an old 233 MMX, maybe you would be better off getting an ISA soundcard that doesn't need drivers, like an SB16, AWE 64, etc.
If you guys need to see my autoexec and config files, no problem.
I've regularly gotten 600+ K using memmaker on new setups. Besides the necessary drivers--himem.sys and emm386.exe--I have the cdrom driver. Then in autoexec.bat, mscdex (or equivalent), a mouse exe file and any necessary dos sound files.
After running memmaker I copy autoexec.bat to dosstart.bat in the windows folder and REM out the lines in autoexec.bat since windows doesn't need them. When you do a 'restart in msdos mode' dosstart.bat will run and load those files.
If you boot straight to dos using the F8 options you'd then need to run dosstart.bat manually to load mscdex and the mouse driver.
I've regularly gotten 600+ K using memmaker on new setups. Besides the necessary drivers--himem.sys and emm386.exe--I have the cdrom driver. Then in autoexec.bat, mscdex (or equivalent), a mouse exe file and any necessary dos sound files.
Still, it depends on the sound card. I've owned a computer with an onboard sound card whose needed a 30+ K of conventional mem and I had a hard time loading it high.
Another detail that need to be taken in account is whether he needs stack frames or not. If he does then he'll have less free upper memory.
NateC You have said you are using MSCDEX, but you didn't tell me what driver are you using (MSCDEX and SHSUCDX need a driver to comunicate with the drive, they do not do it by themselves). I think that replacing this driver with UDVD (http://johnson.tmfc.net/dos/, in Jack R. Elis Drivers) could help you with your problem.
Yep, a "true" MS-DOS system is the best way to play "true" DOS games. I use a dual-boot DOS6.22/Win95A P-133 for most of the older games I favor...
Honestly I never had any trouble with MS-DOS 7.10 (from Win98). I mean, its kernel does support just about everything the MS-DOS 6.22 one does, and supports FAT32 and LBA. Of course it is better to have a dedicaded setup, with DOS-only drivers and tools borrowed from an MS-DOS 6.x setup, but you can achieve that using a startup menu with distinct configurations.
Also, he is using Windows 98, so his machine might be partitioned as FAT32, unallowing him to dual-boot with DOS 6.22 without messing with boot managers and partitioning.
>>>Also, he is using Windows 98, so his machine might be partitioned as FAT32, unallowing him to dual-boot with DOS 6.22 without messing with boot managers and partitioning.<<<
Which is precisely why I suggested a "pure DOS" machine. Some of the games may have problems with FAT32. If there's something he couldn't do without on his current setup, then best move the games to a separate system than risk a reformat/reinstall, and not be able to find something lost in the process.
memmaker worked, the problem with Syndicate is EMM386, but I can DOSBox it.
Also, I found an ISA SB16 (and an ESS, but we'll forget it exists for now :P). If i don't need drivers for an ISA soundcard, how exactly...does it work?
I'm not sure you can do without the SB files. I don't think I've ever tried it. That fellow never posted back so I don't know if he got it going and if so, what exactly he did.
But you do need the SET BLASTER line to be correct. Verify any jumpers on the card are correct also.
If i don't need drivers for an ISA soundcard, how exactly...does it work?
DOS doesn't have a sound API, the applications have to use the card directly (which isn't very difficult, since in DOS there is no hardware protection). SoundBlaster was the standard back in DOS days, so every decent game should support it (or something like ADLIB, which is supported by SB). In fact, these DOS "drivers" you mention aim to emulate a SoundBlaster PRO/16 (16 is better).
If your SB16 isn't Plug'n Play, you would only need to set the BLASTER environment variable with the proper values. If it is PnP, on the other hand, besides the BLASTER variable you would need something to initializa it, although you can set "PnP OS" to no in your bios setup instead and let the bios do the job.
As regards Sound Cards PCI Cards sit on IRQ10, ISA Cards, even P'n'P will usually sit on IRQ5. Therefore with PCI Cards you need an Enulation "driver".
Games written for MS-DOS look for IRQ5 and therefore using the SET BLASTER ensures IRQ5 is reserved. With MS-DOS 6.22 I always use non-P'n'P, which is also what I do for W9x if I have an ISA Sound Card.
Okay, well if it's neither here nor there, I won't worry about it. One final question.
My general midi will not work properly. Windows is doing it's damndest to block it. I know for a fact that this card has it, and it was on IRQ 300. Now the IRQ is bouncing around and it won't initialise, and I have a feeling I should have installed my DOS drivers before the Windows drivers.
I'm using a C-Media 8330 (aka CMI8330), so anyone who has this card might know what I'm talking about. I have feeling that the latest Windows drivers are in fact those for the 8738, and the DOS drivers might be also, and I'm very certain that both cards, while using the same SB emulation, have different port values for the general midi.
but it could also be that GM has not been inserted into the "SET BLASTER" line in my autoexec.
Dammit, sorry, I'm bouncing between two computers, and I don't have any working floppies that a) don't have anything important on them and b) have any usable space on them.
The 300 for midi is the I/O port address and not the IRQ. It's default is P330 in the SET BLASTER line. If you're running the game within windows, SET BLASTER should reflect the windows setting for the card--check device manager. Of course that may not be where the game is looking.
In pure dos makes sure PnP OS is disabled in cmos/bios setup.
You probably need a SET MIDI line something like:
SET MIDI=SYNTH:X MAP:Y
where X = 1 for an FM chip or 2 for MPU-401 and Y is G for general midi, E for extended midi and B for basic midi.
Generally the dos installation program should edit config.sys and autoexec.bat with the correct settings.
From C-Media, the only place to get the drivers, but their driver package is a generic package, which doesn't make sense because the CMI8738 is a 32-bit sound card, not a 16-bit card, iirc. It's basically an AWE-32, and is compatible with the Yamaha G drivers, which the 8330 is not; the 8338 is, though. I know, I have an 8338 and 8738 (I use the 8338 out of pure convenience) in this machine (the higher end one that I'm posting from).
I'll try the set midi trick, and see if that works, but no, it's idabled by default because you can't configure that aspect of the install in WIndows; that has to be done in DOS. And it doesn't work right.
(Click on the SOUNDB.zip link to get to the driverguide page.) Extract the download to a folder. Reboot in pure dos and run INSTALL. There's a readme.txt file there too. You should be able to choose to only install for dos.
After installation, running CMINIT from the dos directory in the extracted folder will give the card settings and CMTEST will test its various functions.
clicked on PCI AUDIO--CMI8330--DOS and downloaded the file. The dos files look the same as the driverguide download. Is that the one you've already tried?
Actually though the CMedia Emulation "Drivers" self-install, it will quite often need settings tweaked. Also using a PCI card is wasting conventional memory unneccessary, especially sice you have ISA Cards.
Conventional memory is no long an issue, thankfully, although I wish I could have kept emm386 out of the deal.
Anyway, I'll try the SET MIDI line later today and see how it goes. I'll probably have to edit the Set Blaster line in my autoexec because I'm 99% sure that the MPU401 i/o address is 300, not 330.
Ehn, I have to bounce between the two computers anyway. Keeping Syndicate on this one is the least of my concerns.
Anyway, from what I can gather, the driver package that I downloaded from C-Media either doesn't have a General Midi driver built in, or because I'm using Windows 98 it's creating a conflict with the WIndows 98 drivers. Anyway, I'll just play the games in a Windows 98 DOS window unless otherwise specified.
The information on Computing.Net is the opinions of its users. Such
opinions may not be accurate and they are to be used at your own risk.
Computing.Net cannot verify the validity of the statements made on this site. Computing.Net and Computing.Net, LLC hereby disclaim all responsibility and liability for the content of Computing.Net and its accuracy.
PLEASE READ THE FULL DISCLAIMER AND LEGAL TERMS BY CLICKING HERE