Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Is there a DOS memory documentation available? (Users)

posted by mceric, Germany, 18.01.2024, 10:47

> I'm not sure about the validity of this but I've read about EMM386 being
> shunned because it puts the processor in Protected mode and thus the system
> runs slower and some incompatibilities may be introduced too.
That is correct. EMM386 uses protected mode because this allows it to put DOS into a special task which simulates a normal DOS environment, but allows it to juggle with memory in software to provide EMS and UMB. There also was EMS hardware, sometimes as add-on card, sometimes as a chipset feature of the mainboard, but neither were widespread.

You also have UMB chipset drivers such as UMBPCI. Not all mainboards are supported by those and sometimes the UMB have limitations, such as not supporting DMA access for example related to disk/floppy/network/sound controllers. DMA can also be an issue with UMB and EMM386 if BIOS and drivers do not properly implement negotiations and preparations for them.

But back to EMM386: Because it simulates normality, there can be gaps in the simulation and somethings can be slower to simulate than others, such as the DOS style of handling hardware interrupts. Newer CPU had VME, virtual mode extensions, to speed up those again. The main compatibility issue with EMM386 is that by design, it cannot coexist with early protected mode DOS games which want to use protected mode themselves, but do not yet support various interfaces allowing EMM386 and the game to share it. More modern DOS games can even coexist with Windows through DPMI. Others cannot even coexist with HIMEM, but those are rare. Games with DOS extenders which cannot coexist with EMM386 (and Windows) were actually a thing for a while. Those would usually tell you that you have to reboot and not load EMM386 before playing them if they detected a loaded EMM386.

Which is one of the reasons why a default FreeDOS install will ask you at boot which standard set of drivers you want to load. Including choices where EMM386 is omitted.

Regarding VCPI: That is a very low level coexistence interface. It is used for example by Windows to replace the entire EMM386 by a Windows built-in implementation when it starts. Games may support it, but DPMI is far more app-oriented and smooth to use. Things compiled with DJGPP and related compilers often use CWSDPMI as DOS extender, so if CWSDPMI can use VCPI to load its own DPMI layer and then load your DJGPP-based app, it can use that route for running while EMM386 is loaded.

Games which do not care about protected mode will not usually have compatibility problems with EMM386, because EMM386 will only have to make things look like normal DOS processor mode, which is why the special task style used here is called virtual 8086 mode. In practice, EMM386 can let you use 32-bit computations as well, but it cannot let you mess with protected mode yourself. Your apps will have to use VCPI and play nice if they want that while EMM386 is loaded.

I would say the speed issue affects mostly interrupt-heavy apps, such as games which use soundcard IRQ many times per second. If your CPU and EMM386 support VME as mentioned above, the speed impact will be much less.

> On Windows 98 EMM386 doesn't need to be loaded as a DEVICE in CONFIG.SYS,
> but nevertheless Windows creates an EMM Page Frame for EMS compatibility
See above. Windows, even Windows 3, takes control of protected mode. While doing so, it is polite enough to also provide services normally offered by EMM386. If EMM386 is already loaded before Windows 3, then Windows needs to use VCPI to replace EMM386 with its built-in implementation on the fly.

The CPU does not unload EMM386 if you restart in DOS mode. You just actually restart and do not load it again that time, so you stay in real mode ;-)

In real mode, everybody is free to switch to protected mode any way they like. But if EMM386 is loaded, protected mode already is active, so it cannot allow you to do uncontrolled changes to protected mode.

Completely unloading EMM386 would involve rolling back all protected mode configuration. You would no longer have EMS and UMB, so it would only be possible if neither are used at that moment. Because it is far easier to just reboot and not load EMM386 again after that reboot, there would not be much use in EMM386 implementing a method to remove itself on the fly.

With JEMM386 and JEMMEX, you do have LOAD and UNLOAD command line options. Check whether they are sufficient for what you need, but note that you can only use them if you loaded JEMM... from autoexec or command line, not if you loaded it from config sys.

---
FreeDOS / DOSEMU2 / ...

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 93 users online (0 registered, 93 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum