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

elksfs removed from ELKS kernel; EMS memory needed

[Jody Bruchon]

Upon close examination of a "diff" between the filesystems "minix" and 
"elksfs" I have concluded that elksfs is merely a clone of minix, with 
changes for the new name but nothing of real value. This effectively 
means that the minix filesystem was included in entirety in the ELKS 
kernel source TWICE. There seems to be zero documentation specifying the 
layout of elksfs, and zero tools that create one, thus to me it is quite 
clear that elksfs never came to actually exist. I have removed it and 
pushed the removal to Git, reducing the total ELKS kernel code by 75 KiB 
and removing some unnecessary configuration options.

Next on the chopping block: everything that depends on CONFIG_NOT_NOW is 
potentially vaporware and/or bloat, though some of it looks potentially 
useful. I've acquired the LIM EMS 4.0 specification from:
http://www.arl.wustl.edu/~lockwood/class/cs306/class-resources/gpe/limems41.doc.html
And I would like to develop support for expanded memory, possibly tying 
into the swap subsystem. Does anyone on the list have some hardware with 
EMS memory for testing?

Jody Bruchon

Re: elksfs removed from ELKS kernel; EMS memory needed

[Kirn Gill]

Reading over the document shows that it's not much use to us. It's an
developer's doc on the EMM APIs provided by EMM386.EXE on
DOS-compatible OSes. It contains developer examples in C, Turbo
Pascal, and Microsoft's 386 assembler, all expecting to use MS-DOS and
EMM386 to actually perform the work for them.

It doesn't tell you much about how EMM works from an actual hardware
perspective, sadly, and absolutely nothing on how it works.

On the other hand, I did get an idea - why not look at FreeDOS's EMM386 source?

On Fri, Feb 17, 2012 at 00:39, Jody Bruchon <jody@jodybruchon.com> wrote:
> Upon close examination of a "diff" between the filesystems "minix" and
> "elksfs" I have concluded that elksfs is merely a clone of minix, with
> changes for the new name but nothing of real value. This effectively means
> that the minix filesystem was included in entirety in the ELKS kernel source
> TWICE. There seems to be zero documentation specifying the layout of elksfs,
> and zero tools that create one, thus to me it is quite clear that elksfs
> never came to actually exist. I have removed it and pushed the removal to
> Git, reducing the total ELKS kernel code by 75 KiB and removing some
> unnecessary configuration options.
>
> Next on the chopping block: everything that depends on CONFIG_NOT_NOW is
> potentially vaporware and/or bloat, though some of it looks potentially
> useful. I've acquired the LIM EMS 4.0 specification from:
> http://www.arl.wustl.edu/~lockwood/class/cs306/class-resources/gpe/limems41.doc.html
> And I would like to develop support for expanded memory, possibly tying into
> the swap subsystem. Does anyone on the list have some hardware with EMS
> memory for testing?
>
> Jody Bruchon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html