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 Rugxulo Homepage, Usono, 19.01.2024, 01:25

> > 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
V86 mode (a special real-mode friendly form of protected mode), but yeah, since it's (always?) ring 3, it's more "protected" and thus prevents some things (for stability). The original Pentium (only), for instance, would not allow RDTSC under V86 mode. Others won't even let you write (or read!) a control register (unless they emulate that, I think JEMM does).

> 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.
Most DOS versions of EMM386 (except DR-DOS) required HIMEM.SYS to also be loaded first. And it was weird whether some would share XMS and EMS or not or how much.

> 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.
VME came with the Pentium (aka 586) in 1993.

> More modern DOS games can even coexist with Windows through DPMI.
Not with x64-only Windows 11. But yes, DPMI was invented by Windows 3.0 in 1990. Even XP had bugs that DJGPP 2.03p2 had to workaround, but it was most okay. With Vista, things went way downhill for DPMI support.

> 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.
I believe Quarterdeck (Desqview) was one of the main companies behind VCPI.

> 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.
The so-called GEMMIS interface, right?

> 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.
CWSDPMI is not a "DOS extender" in that it doesn't support unofficial int 21h extensions (which were never standardized). It's a "strict" 32-bit DPMI server only (no 16-bit DPMI). DJGPP v1 had various workarounds and extensions and a separate GO32.EXE "extender", but DJGPP v2 (circa 1996) is "DPMI only". CWSDPMI is just one of many ("standard") DPMI 0.9 hosts potentially supported. GO32.EXE is no longer needed at all.

> 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.
Any 32-bit cpu (e.g. 386) can use 32-bit computations (e.g. registers EAX etc.) even in real mode, assuming your BIOS isn't buggy and doesn't clobber the registers (which most don't).

> 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.
So-called DOS-extended apps still have to switch back to DOS for the disk access. In theory, it's offset by an improvement in other speedups. Actually, switching to V86 mode from pmode (e.g. EMM386) should be faster than switching from pmode to real mode. Although the Pentium added "4 MB pages" for better speed, which CWSDPMI r7 optionally supports (by default), which is noticeably faster, but that's not supported under EMM386 because it's always 4 kb pages there (legacy requirement).

Post reply
 

Complete thread:

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