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@xxxxxxxx> 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
