#43 Bunch of problems
I just switched from MS-DOS 7.10 to FreeDOS. However, I experienced a lot of problems these days.
First, the installation. The RTL8168 (PCI-E) onboard network card on my new motherboard, GA-M720-US3, has no packet drivers, and I found that the post-installation of FreeDOS involves WATTCP very often that if I don't install a proper packet driver, and I set the WATTCP options manually instead of DHCP, it will end up with "No Nameserver Detected" and the post-installation hangs even if I try to CTRL-BREAK. If I let it use DHCP, it will keep saying "Configuring through DHCP... failed" until I CTRL-BREAK it. Is there anyway to deal with it if I cannot get a packet driver for the network card in the first place? Also, will there be a proper packet driver for PCI-E onboard network cards like RTL8168 in the future? There were workarounds for making NDIS2 DOS drivers into packet drivers, but I haven't tested it yet.
Second, the compatibility. I installed FreeDOS using the unstable Kernel 2037 since there are things not supported by stable Kernel 2036. I have XMGR as XMS memory manager, and along with it I use UMBPCI for real mode without EMS, and JEMM386 for protected mode with EMS. However, it somehow seems to be unable to provide as much UMB as in MS-DOS. (I remembered I could make up to 60-80K using JEMM386, while in FreeDOS both JEMM386 and UMBPCI only offer me 36K) Also, FreeDOS doesn't seem to take care of the UMB region of B000-B7FF even if I included, as monochrome is never used in this system and I haven't involved in any problems from programs using this region so far when using MS-DOS. Besides, the JEMM386 tends to crash when loading CTMOUSE driver (and some games may end up a crash if I use mouse, and many programs don't even seem to work properly in FreeDOS now) using this kernel. Since the kernel is unstable I even replaced the KERNEL.SYS and COUNTRY.SYS with version 2039, the problems are still there.
Once I told you about the crash-after-loading problem caused by QEMM in FreeDOS using Kernel 2037 (and the problem that QEMM doesn't load in Kernel 2036)... however, I'm not going to use it since I'm using Jack's UIDE driver, which involves all the RAM I have instead of the first 256M (while QEMM386 locks up the rest of the RAM after 256M), but I still hope if there are replacements that's more compatible with the modern environment. The QEMM's Stealth function helped me a lot before I updated my motherboard, as it provides loads more UMB (even now it can still provide me with 91K UMB in MS-DOS with EMS enabled).
I don't know if it's possible to make new DOS audio drivers for SB-compatible PCI cards to make them work fine on modern motherboards... as I found that nVidia nForce chipsets manage IRQs in a different way than Intel and VIA that devices (including onboard devices) are all to be occupying IRQ 5 first, and occupy other IRQs when IRQ 5 is used, while the original PCI audio drivers requires the IRQ 5 being free. It seems modern boards retain D-DMA, including my motherboard which uses nForce 720D. Original DOS audio drivers are designed to work with old Intel chipsets like 440BX and suffer a lot of issues on non-Intel chipsets at that time like VIA Apollo 1 (And that seems to be why these drivers ship with documentations mentioning about the compatibilities about non-Intel boards), and they don't seem to work properly with some later ISA-available Intel P3/P4 and AMD K7 motherboards around 2002-2003 as these drivers' latest versions are in 1999. Now that all PCI-cards are suffering problems with digitized audio (either it won't produce digitized audio, or will crash the game) on my new motherboard, while FM music still works perfectly, just depending on the card's FM chip's quality. YAMAHA YMF7x4's genuine OPL3 sounds best, and ESS Solo-1 ES1938 only has minor defects. The other cards, like Aureal and ESS cards after Solo-1 like ES1968/ES1989, and Creative Sound Blaster PCI, has bad FM quality. SBLive! has excellent FM quality through emulation, but it seems to suffer a lot of compatibility issues and requires a lot of memory so I don't use it anymore. Also, it's unknown whether non-Creative cards can be modded to be SB16-compatible instead of just being SBPro-compatible...
Hope you can solve all these problems in the future.
Larry
EDIT: Actually the first problem should be "No Nameserver Defined" or something... the installation simply hangs at that place and then nothing else will be done.
Also, I found that when I try to load JEMM386, it says "No page frame found, EMS function limited", as the UMB area reserved for EMS was also completely used by something, probably the system itself, and the system can only provide 36K UMB with or without EMS.
BTW, which kernel so far is the most stable, and can provide the most stable UMB?
> I just switched from MS-DOS 7.10 to FreeDOS.
Good.
> However, I experienced a lot of problems these days.
> First, the installation.
Please reveal what you downloaded and from where.
The distro's are obsolete and de facto unusable, you will have to download
separate files (as you apparently partially did).
> Also, will there be a proper packet driver for PCI-E onboard
> network cards like RTL8168 in the future?
Nobody knows, but this is NOT a BUG of FreeDOS.
> Second, the compatibility. I installed FreeDOS using the unstable Kernel
> 2037 since there are things not supported by stable Kernel 2036.
Get 2039.
> I have XMGR as XMS memory manager
Try also HIMEMX 3.32.
> Besides, the JEMM386 tends to crash when loading CTMOUSE driver
Version ? Get 2.1b4.
> and many programs don't even seem to work properly in FreeDOS now
examples ???
> using this kernel. Since the kernel is unstable I even replaced the
> KERNEL.SYS and COUNTRY.SYS with version 2039, the
> problems are still there.
What problems are left ? KERNEL.SYS is critical, COUNRY.SYS isn't (I don't use the latter at all).
> I don't know if it's possible to make new DOS audio drivers for SB-compatible PCI cards
You mean SB-incompatible PCI cards maybe ??? This is a hardware problem, not FreeDOS kernel problem.
> BTW, which kernel so far is the most stable, and can provide the most
stable UMB?
Try 2039, then 2038. There are many fixes. I don't use UMB, though.
I don't know whether FreeDOS 1.0 distributions are still being updated... I can't remember when I downloaded and burned my FreeDOS 1.0 CD... it was several months ago...
As for the RTL8168 network card problem... it's sure that it's not a bug of FreeDOS but what I want to ask is that is there a way to prevent WATTCP from being involved during the installation? Actually I didn't complete my last FreeDOS installation just because of the WATTCP. I'm unable to reinstall since I fear that it may take over my LILO bootloader used by my Mandriva Linux installed on the hard disk with FreeDOS, and it may compromise my Windows 7 installation on my second hard disk.
I've already gotten the kernel 2039 and replaced the original SYS files. Things are still unsettled. The CTMOUSE driver I'm currently using IS 2.1b4 (Actually any version of CTMOUSE would cause problems with FreeDOS and Japheth's JEMM386 and it prevents CTMOUSE from running, if I use UMBPCI, the system would crash when trying to move the mouse). If XMGR does have problems with FreeDOS (since there was a time that Jack made drivers prohibited to use on FreeDOS), then I'll try HimemX...
Actually, CWSDPMI seems to be no longer working properly... this prevents a lot of programs including my programming environments such as FreePascal, from running in FreeDOS.
Besides, as for sound cards, what I'm saying is about some early PCI sound cards that's SB-compatible (Like ES1938, YMF744, SBLive!, etc.). SB-Incompatible cards, however, as they're hardware-related problems I'll not describe more here. I'll have a look, or maybe someone can be interested about restoring the old PCI sound cards' DOS compatibility back to the fullest, and thus to make FreeDOS something really worth using on a modern system.
> I don't know whether FreeDOS 1.0 distributions are still being updated
NO. 1.1 distro is awaited.
> what I want to ask is that is there a way to prevent WATTCP
> from being involved during the installation? Actually I didn't complete
> my last FreeDOS installation just because of the WATTCP.
I don't know as the distros are obsolete and I don't use them.
> I'm unable to reinstall since I fear that it may take over my LILO
But you can update any files manually as you apparently already did, so no real problem ;-)
> The CTMOUSE driver I'm currently using IS 2.1b4 (Actually any version
> of CTMOUSE would cause problems with FreeDOS and Japheth's JEMM386
But this bug got fixed for 2.1 - for you still JEMM386 + CTMOUSE -> crash (no SBEMU, UMBPCI, ...) ??? Supply crashshot then.
> Actually, CWSDPMI seems to be no longer working properly...
since what happened ???
> this prevents a lot of programs including my programming environments
> such as FreePascal, from running in FreeDOS.
NO. Get HDPMI32 and make it resident: HDPMI32 -r
> maybe someone can be interested about restoring the old PCI sound
> cards' DOS compatibility back
Did such a compatibility exist in the past ???
> to make FreeDOS something really worth using on a modern system.
Again, I'm not aware of any sound support in FreeDOS project. Nevertheless,
JEMM386 has a SBEMU-HACK that reportedly "works" for a few people.
Sorry for keeping too long, anyway...
> NO. 1.1 distro is awaited.
I hope it will come out soon...
> But this bug got fixed for 2.1 - for you still JEMM386 + CTMOUSE -> crash
> (no SBEMU, UMBPCI, ...) ??? Supply crashshot then.
Actually I cannot make proper crackshots... but JEMM386 would say it has encountered an exception (sometimes it would load while mostly it won't, and CTMOUSE may end up killing itself when things go wrong). By the way, it seems the UMB region used by EMS is consumed by FreeDOS so when I load JEMM386 it says "No page frame found. EMS function limited." (Actually both RAM and NOEMS at this case provide the same amount of UMB).
UMBPCI won't report the error caused by CTMOUSE, but some applications may crash when trying to move the mouse (It happened when I ran an SVGA game called Tetris Pro)... Fortunately, Jack's UIDE works with UMBPCI.
I don't have any kind of SBEMU at present... I just use their original and obsolete drivers for DOS music...
> since what happened ???
Nothing. When I run FreePascal IDE it just gives me some error messages. The CWSDPMI would load, however... If Japheth's HDPMI can work better I'll use that instead.
> Did such a compatibility exist in the past ???
Yes, there is. There were two main kinds of DOS support for PCI sound cards - PC-PCI (aka SB-Link) and Distributed DMA (DDMA).
It seems SB-Link is now obsolete after Intel 440BX chipset... However, DDMA seems to have been kept on most boards including modern ones, but they may have some differences that it may not be as compatible as Intel's chipsets, since the drivers are designed mainly for 430TX/440BX, and for this reason most manufacturers ship chipset compatibility lists for chipsets at that time such as VIA Apollo-1. So far only YMF7x4's SETUPDS could detect any possible DDMA, and is able to produce at least genuine FM music.
Other than these two kinds, ESS audio cards use their Transparent DMA (TDMA), which is chipset-independent and only consumes a little base memory (about 1K-2K). Aureal Vortex uses a decent emulation that consumes about 25K base memory, and ESS' TDMA seems to be an enhanced way of Aureal's.
Creative's Sound Blaster PCI and Sound Blaster Live! use pure SB16 emulation, which requires both EMS (and it dislikes Quarterdeck's QEMM386 and will reboot if loaded) and a lot of base memory (about 30K). Sound Blaster Live! was once known for having the best SB16 compatibility in DOS.
AFAIK the best SBPro-compatible PCI cards are YAMAHA's YMF7x4 series, and ESS' Solo-1 (ES1938), for it has the best music quality and compatibility since they have native FM chips onboard, and they consume little base memory and they don't need EMS. Other cards, like Aureal Vortex and later ESS models (ES1968, ES1989, etc.), have less authentic music quality.
> JEMM386 has a SBEMU-HACK that reportedly "works" for a few people.
I have never heard of such a thing. Plans for supporting audio was written in the documents of Japheth's HX DOS Extender, but it's still uncertain about how it will work.
I wrote:
> Get 2039
Wrong, get 2038 and use it __OR__ get 2039 and help to test the BUG.
Larry wrote:
> I hope it will come out soon...
Kernel must get fixed first.
> Actually I cannot make proper crackshots
why ?
> > JEMM386 has a SBEMU-HACK that reportedly "works" for a few people.
> I have never heard of such a thing
RTFS, it's in ;-)
I think this bug is outdated since the release of FreeDOS 1.2 RC1, which uses updated versions (for example, Kernel 2042, which should fix problem mentioned above).
Can you reconfirm if this problem still exists in FreeDOS 1.2 RC1? Otherwise, I think we can close and assume fixed.