Re: elksfs removed from ELKS kernel; EMS memory needed

[David Given <dg@cowlark.com>]

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

Kirn Gill wrote:
[...]
> Either way, it's an "high" level API doc for DOS-based EMM managers.
> We're looking to actually implement an EMM, which, if they're as you
> say hardware-specific, gives me the impression that a separate driver
> will be required for each addon board.

Minix 1.5 had support for some EMS hardware; it may be worth trawling
through the VCS looking for the code. Actually finding the hardware
might be tricky.

> There's also the issue of how bcc generates code. Notably it doesn't
> support far access or far calls, making usage of EMS quite difficult,
[...]

My understanding is that EMS hardware typically maps pages into a window
somewhere above 640kB.

Given that ELKS binaries are all tiny or small mode, and therefore don't
care what segment they're running in, it should be possible to run code
directly out of the EMS window --- just map the process in and set the
segment registers accordingly. Naturally there would be problems if the
process used split I/D segments and *both* segments were in EMS, because
(depending on the hardware) you may not be able to map both of them in
at once. But combined mode executables and split I/D where one segment
was in main memory ought to work fine.

The simplest solution, of course, is to just build a block device
interface and use it for swap. It'll be slow, but it's an 8086 --- it's
*always* going to be slow...

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]