Yeah, probably will "do it" on my 386 DX-40 build. That's a tad too choppy for my taste especially when the enemies and smoke effects start to move on screen. Also, my 286 is only a 12MHz model.

liqmat wrote:

Yeah, probably will "do it" on my 386 DX-40 build. That's a tad too choppy for my taste especially when the enemies and smoke effects start to move on screen. Also, my 286 is only a 12MHz model.

DX40 will be perfect. I remind playing Darker Demo on DX40s at school. Oh, and smoke effects are kinda special in this game 😉

Jo22 wrote:

It's not that bad, IMHO. That "it has to switch to protected-mode and then do a reset to get back to real-mode" thing is outdated information.
Himem.sys (~MS-DOS 6.x) has two code paths. One that uses LOADALL (286), one for the 386 and later CPUs.

isn't xms usage limited to manually copying data between it and conventional ram like swapfile? doing that alone is much slower than normal conventional ram.

noshutdown wrote:

Jo22 wrote:

It's not that bad, IMHO. That "it has to switch to protected-mode and then do a reset to get back to real-mode" thing is outdated information.
Himem.sys (~MS-DOS 6.x) has two code paths. One that uses LOADALL (286), one for the 386 and later CPUs.

isn't xms usage limited to manually copying data between it and conventional ram like swapfile? doing that alone is much slower than normal conventional ram.

Himem.sys/XMS sure has bottlenecks, but has them on all processors in some way, it's not so much an issue with the 80286 per se (ancient Himem.sys used the reset method).
EMS is more complex, but better documented and quicker sometimes (especially if hardware based EMS is used or via VME instead of V86).
One thing that also affects XMS performance is the way the A20 line is handled.

There are lots of ways, from the classic one via KBC to Fast A20.
To complicate matters, there's no official way in which order the different methods should be detected
and how they should be accessed afterwards (directly or BIOS; if BIOS, then what BIOS function ?)
Himem.sys of DOS 6.x has 17 methods of handling the A20 gate.

Fast A20 has to be supported by both chipset/BIOS and the memory manager(s).
Himem.sys (or EMM386) of MS-DOS 6.x/7.0 doesn't support it yet, but maybe later versions of PC-DOS
or third party memory managers did. If something like QEMM is used, which may support Fast A20,
then it also is important that the processor (486+) can do VME, since normal V86 is slower than Real-Mode.

Edit: Himem.sys apparently does support the PS/2's quicker A20 method that's available via port 0x92h.
Not sure if this is related to Fast A20, though. At least the PS/2 method is not using the comparably slow KBC.

I recommend reading thse links, since I'm not so good at explaining things. 😅

https://retrocomputing.stackexchange.com/ques … -the-80286-work
https://en.wikipedia.org/wiki/LOADALL

http://www.os2museum.com/wp/himem-sys-unreal- … de-and-loadall/
http://www.os2museum.com/wp/forward-compatibility-landmines/

https://en.wikipedia.org/wiki/A20_line
http://www.os2museum.com/wp/the-a20-gate-fallout/

AlaricD wrote:

I don't think it would for fractint, either, since the "int" in "fractint" means "integer".

The name does originate from fractal + integer and it's also true that in the first versions only integer arithmetic was used. But in later versions it uses the FPU if present.

Jo22 wrote:

Himem.sys/XMS sure has bottlenecks, but has them on all processors in some way, it's not so much an issue with the 80286 per se (ancient Himem.sys used the reset method).
EMS is more complex, but better documented and quicker sometimes (especially if hardware based EMS is used or via VME instead of V86).
One thing that also affects XMS performance is the way the A20 line is handled.

after all, is there any way to make accessing xms as fast as conventional ram, on a 286?

noshutdown wrote:

after all, is there any way to make accessing xms as fast as conventional ram, on a 286?

Only if you use its quirky protected mode.

konc wrote:

AlaricD wrote:

I don't think it would for fractint, either, since the "int" in "fractint" means "integer".

The name does originate from fractal + integer and it's also true that in the first versions only integer arithmetic was used. But in later versions it uses the FPU if present.

I did a little bit of benchmarking last year. And the Mandelbrot set for example runs way faster on a 286 than on the 287 (you have to force FPU usage). But Fractint contains other fractals that require floating point and those will be 5-10x faster with an FPU. Same goes for stuff like Autosketch, which will also be 5-10x faster using a 287.

Scali wrote:

noshutdown wrote:

after all, is there any way to make accessing xms as fast as conventional ram, on a 286?

Only if you use its quirky protected mode.

wiki says that there is no way for 286 protected mode to switch back to real mode and no access to dos interrupts.
and if you want to use more than just four 64kb segments, you need to modify those segment registers frequently, which is extremely slow in 286 protected mode.

Some chipset had a workaround for this iirc so you can reset the CPU without rebooting (but that mustn't be standard, and that is probably slow)

This is a nice writeup on the technique of leaving protected mode on the 286:

http://rcollins.org/articles/pmbasics/tspec_a1_doc.html

Later versions of HIMEM.SYS and other software will use triple faulting to leave protected mode, which is faster than the above method of using the BIOS:

http://www.rcollins.org/Productivity/TripleFault.html

root42 wrote:

This is a nice writeup on the technique of leaving protected mode on the 286: http://rcollins.org/articles/pmbasics/tspec_a1_doc […]
Show full quote

This is a nice writeup on the technique of leaving protected mode on the 286:
http://rcollins.org/articles/pmbasics/tspec_a1_doc.html
Later versions of HIMEM.SYS and other software will use triple faulting to leave protected mode, which is faster than the above method of using the BIOS:
http://www.rcollins.org/Productivity/TripleFault.html

i read it, it seems possible but still pretty slow, as it said "may take up to a few tenths of a second", and i am not sure if they are bios-dependent.

still i want a brief comparision table of:
relative speed to conventional ram
programming complexity(how much additional inline assembly needed for each access)
compiler native support
limitations and drawbacks

between:
real+ems
real+xms driver
real+xms manual loadall management
protected mode
on a 286 machine.

Thing is with the loadall opcode you don’t need protected mode to access XMS. Only when setting it up. In Windows you also need rarely to switch back to real mode.

(Btw, also loosely related to this thread: Anything else besides games on your retro PC? How old are You?)

Edit: Also intersting in respect to A20 and the adress wrap-around issuje is the Call 5 interface, a leftover from the CP/M era. 😉
Some DOSes can even handle old programs that use it wihout having to limit the adress space by using A20.
http://www.os2museum.com/wp/who-needs-the-add … paround-anyway/

So LOADALL takes 195 cycles. That's a bit slower than just loading a segment register. Probably slower than changing EMS pages (assuming hardware EMS, no doubt emulating EMS would be slow on a 286). Definitely faster than calling an XMS driver to have a large memory block copied.

Haven't read too much on 286 protected mode yet. But I assume that if you go to PM, once you've setup your descriptor table then you can access any memory you want to just by loading a segment register if you're running at the right privledge level. There is a bit of overhead for this operation (and other ones like far calls, etc.) in PM, my reference says it takes 17 cycles instead of 2. Much better than 195 at least. The downside is that you have to go back to real mode to call BIOS/DOS. I guess you need your own interrupt handlers too?

bakemono wrote:

So LOADALL takes 195 cycles. That's a bit slower than just loading a segment register. Probably slower than changing EMS pages (assuming hardware EMS, no doubt emulating EMS would be slow on a 286). Definitely faster than calling an XMS driver to have a large memory block copied.

Haven't read too much on 286 protected mode yet. But I assume that if you go to PM, once you've setup your descriptor table then you can access any memory you want to just by loading a segment register if you're running at the right privledge level. There is a bit of overhead for this operation (and other ones like far calls, etc.) in PM, my reference says it takes 17 cycles instead of 2. Much better than 195 at least. The downside is that you have to go back to real mode to call BIOS/DOS. I guess you need your own interrupt handlers too?

how frequent do you need to perform loadall in real mode? for each time you want to address somewhere above 1mb? and what about compiler support?

Compiler support isn't an issue since you access XMS via an API implemented as INT 2Fh:

http://www.phatcode.net/res/219/files/xms20.txt

noshutdown wrote:

how frequent do you need to perform loadall in real mode? for each time you want to address somewhere above 1mb? and what about compiler support?

LOADALL would be needed when changing segments. For instance, if you want ES to point to 4MB, you setup the data structure and execute LOADALL. Now you can access anything inside the 64KB area at 4MB, ie. $400000-$40FFFF by using an ES segment override. If you want to access a different area, like the next block after that at $410000, then you'd have to do LOADALL again.

I don't know much about compilers and have no idea if this technique would mesh with how they handle segments.

I also recommend to read the articles at rcollins.org. They are very interesting an well written, so even a complete layman has a chance to get the basic idea of complicated stuff.
Here's one entitled "The LOADALL Instruction" - http://www.rcollins.org/articles/loadall/tspec_a3_doc.html

I toyed with an idea of building a 286, but then.. PC really came to shine as gaming platform from around 1992 when 286 was obsolete. And pre 90s games were almost always developed for other platforms (with better graphics/sound) and then ported to DOS. An AMIGA 500 or 1200 will be a much better system for such games.