Re: elksfs removed from ELKS kernel; EMS memory needed

Re: elksfs removed from ELKS kernel; EMS memory needed

[Kirn Gill]

Aha, I did not know that. Then I guess what we have here is an
vendor-neutral and EMM-neutral API doc.

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.

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,
to say the very least, although this doc gives the impression that EMS
can be mapped (by the EMM) into the 640k area, of course, that leads
to us having to use/implement a weird API for apps to use EMS under
ELKS. Which wouldn't be portable at all, to say the least.

I think looking to "newer" CPUs might actually be better off, while
maintaining compatibility with older ones. an 286 can address 16MB of
memory, of which a max of 15MB can be RAM. 386s would be nice as well
- there's plenty of them used in the embedded space.

On Fri, Feb 17, 2012 at 04:19, Urja Rannikko <0451383440@netti.fi> wrote:
> Sorry for replying like this (blame nokia 6630 mail app);
> EMM386 only works on 386s (or better) and uses protected mode and VM86 mode to virtually provide EMS for the app running inside the VM86 box. EMS systems on pre-386s were hardware specific and had a hardware specific EMM.
> Sure you can use pm+vm86 to expand elks memory but that sounds a bit weird.
>

Re: elksfs removed from ELKS kernel; EMS memory needed

[David Given]

[-- 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 --]

EMS support will probably never happen

[Jody Bruchon]

Unfortunately, the LIM EMS specification seems to be an API spec for 
programs and drivers, not a hardware interface standardization. IBM, 
Intel, AST, and others apparently all use a totally different driver 
with different interfaces. Also, based on the extreme price of EMS cards 
on eBay and the very small number of them I am finding, EMS support is 
probably a waste of time to even think about. There is no standard 
hardware interface, and if the hardware is so hard to find that I can't 
get it to test with anyway, there's little point in planning to add 
support for it. Unless someone has a valid objection, tonight I will 
remove the placeholder code for EMS support and the EMS support option 
which does nothing anyway.

Just to be clear about what I'm doing, I'm trying to shrink the ELKS 
code base by stripping out vaporware and useless code, particularly 
since one direction we are interested in taking is porting to a 
different compiler, and every single line of code that's not necessary 
when such work begins will only be an additional burden at that time. 
Plus, novices who look at ELKS and happen to enable those options will 
see options for drivers that simply don't exist or aren't functional, 
and then be confused when it doesn't work.

Jody Bruchon