tom9876543 wrote:You should test for a 80286 only.
You have a point. However, it is done already and I do not find too important reasons to change it. My first stage boot code simply tests that the CPU is not 8086. That should mean that the CPU is
at least 80186 but is probably at least 80286 or newer. I want to use 80186 instructions after the first stage and it does not matter whether the CPU is 80186 or 80286 at that point. The second stage boot code just loads the third boot code that is in a file. The third stage boot code does the complete CPU test (e.g. 80286, "32-bit", "64-bit"), prepares the environment (also: load settings from a boot configure file, interactive menu for video modes, memory detection, etc.) and starts the correct kernel.
tom9876543 wrote:I won't ask why you are spending a significant amount of time to support an obsolete CPU (80286).
I will not spend a significant amount of time. It would be fun to take an ancient computer and run the system on it. If I can make that ancient computer to communicate with another computer with my modern system (e.g. serial cable) and do some fun things, it would be worth it. Also, the applications written for it can basically run everywhere (like I pointed out in my previous post). Also, I will guarantee that all the applications written for my 80286 system will run on my every newer system (natively or emulated). I take the backward compatibility very seriously.
I will first finish the 80286 kernel and I think my plan is quite good. I am not an experienced OS developer but I feel that I am competent enough to create this simple kernel so that it will really be finished, documented, tested and published. I have a reasonable goal and it will not take years to reach that. The modern kernels (32-bit/64-bit) will be done differently and I have to do more research first.