Restore or drop the i286 protected mode ?

[mfld-fr]

Issues #207 and #233 raise a somewhat 'strategic' question about the support of the 16-bit protected mode. My proposal is to merely drop it, after considering the following pros & cons:

Pros:

• existing code base in the repository
• allow memory 1...16 MB
• intrinsic robustness

Cons:

• inconsistent code with current features
• strong architectural constraints in addition to the current i86 segmentation
• very specific to i286 processor model
• never being a success on PC market
• not suited for embedded market
• and last but not least, nobody to work on it

[jbruchon]

I don't think it makes sense to support it, especially with few people working on the project. The scope needs to be restrained. 286 chips are 8086-compatible. If the access to more memory is desired, perhaps a little trickery would be suitable instead:

https://en.wikipedia.org/wiki/LOADALL

[tkchia]

Hello @mfld-fr, hello @jbruchon,

Maybe, in that case, instead of direct support for 286 protected mode, it might be useful to think about allowing for some sort of API or device driver (?) to let ELKS programs use extended memory in a managed way --- similar to MS-DOS's XMS or its earlier vdisk.sys protocol.

Thank you!

[mfld-fr]

Outcome of the discussion (both here and on the mailing list) is that the unreal mode would be an easier way to use the memory > 1 MB than the protected mode. Thanks to all, I feel now comfortable to drop it.

[mfld-fr]

Dropped in #235.