Games that run on a 286 are most likely expecting XMS or don't use additional memory at all. EMS was slow and rarely required by games.

Hm, I thought XMS was slow, because it needed protected mode switches? While EMS was supported by bankswitching in hardware, or via virtual86 mode on the 386...? But someone with more technological prowess than me might correct me here.

On a 286, you are actually right. XMS is slow there due to mode switching. However, EMS back then was provided by ISA memory cards and the ISA bus makes it even slower than (local) XMS memory. EMS was also expensive and that's why it was rarely required by games at that time. Productivity software on the other hand often required or utilized it, like compilers for example.

ps: EMS is emulated using XMS on a 386 and up. So to the slowness of XMS it adds the overhead of emulating EMS. So in reality, EMS is always the slower memory. This can be proven easily by running a game benchmark with "EMM386.EXE RAM" and again with no EMM386 at all. This is true for 386 and up only, however. I've never tested the difference on a 286.

Yes, that's true for the original Himem.sys releases.
But actually, with modern Himem.sys (v2.06 and later), the 286 never has to leave real-mode.
Or more precisely, the modern Himem.sys doesn't call a BIOS sub routine anymore that did in turn use protected-mode..
Rather, it uses LOADALL to -in simple words- save/restore/modify the CPU state.
And on 386 and later processor types, it uses unreal-mode.

"The above method was obviously not usable on 286 systems. However, HIMEM.SYS version 2.06 added a new code path which
avoided the BIOS thanks to the well-undocumented LOADALL instruction. LOADALL can be used to load the entire
internal CPU state, including hidden registers. HIMEM.SYS modified the hidden segment base registers to point
to the source or target memory location above 1MB. The processor was never switched out of real mode.
The block move was done with interrupts enabled, although if an interrupt actually occurred, the selector bases
had to be reprogrammed and the move restarted. The LOADALL method was then the only 286 code path,
because V86 mode was not applicable (in other words, the CPU was always in real mode when executing HIMEM.SYS
and LOADALL could be used)."
Source: http://www.os2museum.com/wp/himem-sys-unreal- … de-and-loadall/

Anyway, it's still true that XMS is slower on a 286, because memory has to be copied.
EMS -in hardware-, can do make use of pointers and such. So it could be quicker here.
EMM386 and other LIMulators can be slow on 386/486 machine on the other hand,
because it runs in V86 and the CPU's MMU has a lot of work to do.

And on ATs, it's also the A20 gate that can be related to performance.
Some systems used the keyboard controller, some the chipset, some a CPU pin.
Not sure how MS-DOS' Himem.sys fits into this. It doesn't support FAST A20 yet, I think.

In the ends, it depends on the machine, I think.

Some Sierra games (SCI) did support both types of memory.
And some early apps also used Extended Memory directly via Int15h.

PS: I hope I don't sound too much of a smartass here. 😅
It's just that this matter is quite interesting to me. 😀

Interesting, maybe I need to make the default mode of my HT12/A 286 pc to use the Headland EMS memory driver rather than DOS6.22 himem.sys
Also in this machine I have installed a Kingston 386sx33 upgrade, in that case what is better? emm386 , headland ems or himem.sys ?
I never thought of that aspect about memory tbh!

Regarding Himem.sys 2.06: that is very interesting. When was that introduced? E.g. I am currently running DOS 5.0.

root42 wrote:

Regarding Himem.sys 2.06: that is very interesting. When was that introduced? E.g. I am currently running DOS 5.0.

Hmm.. I'll have to check. But DOS 5 is safe, I think. My copy of DOS 5 (Release A) comes with Himem.sys 2.77.

Edit: Just checked what I believe is a MS-DOS5 non-A floppy (English): It also ships with Himem.sys v2.77.
Himem.sys version 2.06 is dated 03/21/89. Maybe it came with OEM releases of DOS 4.0 at some point ?
My copy of MS-DOS 4.01 (German) comes with a slightly older version - Himem.sys v2.04, dated 08/17/88.

Anyway, version 2.06 can also be found on the net.
Seems back in the day it was also distributed via shareware and public domain discs.

http://cd.textfiles.com/nightowl/carrs/026C/HIMEM206.ZIP
http://cd.textfiles.com/1stcanadian/utils/xms … ec/himem206.doc

keropi wrote:

Interesting, maybe I need to make the default mode of my HT12/A 286 pc to use the Headland EMS memory driver rather than DOS6.22 himem.sys
Also in this machine I have installed a Kingston 386sx33 upgrade, in that case what is better? emm386 , headland ems or himem.sys ?
I never thought of that aspect about memory tbh!

Hi Keropi, you're welcome. Also, I have to thank you for an older thread of yours.
It inspired me to tweak one of my beloved 286 boxes. It's the smallest and cutest machine I got.
It has a Headland chipset and an integrated Hercules graphics chip, which made me using my old TTL monitors more often.
A few months ago, I had a lot of fun taking various screen captures of the HGC/MGA monitors I collected in the past.
This was really fun and made me valuing these much more. Hercules looks much friendlier on real CRT, especially when the image is non-shquashed. ^^
Anyway, I made a video of installing/configuring EMS via chipset: https://youtu.be/DSQCKlhmEq8
This video was directly inspired by your thread. I also kept Himem.sys (DOS 6.2), btw. It played nice with EMS.

Nice video. You have a very easy setup there, with everything in the CMOS setup program. I have to twiddle little DIP switches. I am not even sure that I can use XMS and EMS at the same time. I actually doubt it, since the memory must not overlap, I think. And the Suntac chipset only supports a fixed EMS size. I have not many games that would utilize EMS anyway. DoTT would be one of those I think.

Hi, thanks! Yeah, I guess I'm kind of lucky that my board is one of the more comfortable models.. 😊
Depending on how your chipset works and how it allocated memory, it *could* be possible that Himem could access Extended Memory still.
Things is, you have to load the EMS driver first and Himem.sys afterwards (provided it supports both types simultanously).
This is in reverse to the usual setup with EMM386 on more modern computers.

Alternatively, you could try to replace your BIOS with another version.
All that's inmportant is that both BIOSes are written for the same chipset.
Provided that no extra features are built into the board..:

I did something similar with a Schneider Tower AT (original EGA series), also Headland based.
Though not HT12/A; G2 I think. The other BIOS (Phoenix or AMI ?) worked fine and had some nifty extra features, but..
It had neither control over the built-in EGA graphics chip, nor the mouse port.
During boot-up, this caused a lot of trouble so I reverted to the original firmware.

Well, kinda "original". The one that came with my model was too old and did not support additional VGA cards yet.
Which means I got no video. In a similar fashion, another version also caused trouble.
They were made for the VGA models, thus lacked the ability to disable on-board stuff and the mouse port.
The result were some beeps and error message during post. I fixed the issue by using a another version again.

Edit: Some fixes.
Edit: Looking for Schneider Tower AT BIOS
Edit: Text cleaned up. My memory is lacking a bit, sorry.

Jo22 wrote:

Hi Keropi, you're welcome. Also, I have to thank you for an older thread of yours.
It inspired me to tweak one of my beloved 286 boxes. It's the smallest and cutest machine I got.[...]

haha the circle is complete now 😊 I will watch the video later when there is quiet in the house 😒