From: jj4public@nospicedham.vfemail.net   
      
   On Sun, 23 Dec 2018 19:03:56 -0500, Rod Pemberton wrote:   
   >   
   > Did that answer your question? ...   
      
   I know some of the information, but not enough to answer my own question.   
      
   > AISI, there are two ways to answer the question from the chart:   
   >   
   > 1) there is only one mode with '64' in it's name, meaning 64-bits,   
   > i.e., PM64, which is a protected mode since CR0.PE=1, hence it's not a   
   > real mode, therefore there is no 64-bit 'unreal' real mode, e.g., no   
   > RM64 mode   
   >   
   > 2) 'unreal mode' is a real mode, i.e., RM32, but the chart shows that   
   > there are only two real modes, i.e., those which have CR0.PE=0, known as   
   > RM16 and RM32, for 16-bit and 32-bit respectively, hence there is no   
   > 64-bit 'unreal' real mode, e.g., no RM64 mode   
      
   OK. Perhaps it dues to the Long Mode which bind the operating environment to   
   protected mode, and support for CS.ar.D=1 is removed. What would happed if   
   CS.ar.D is set to 1? Is there any article which describe that attempt? i.e.   
   a research article about the failed attempt to get 64-bit Unreal Mode. I   
   simply want to know how and why it fails.   
      
   > Of course, the chart only shows known modes, not intermediate states.   
   > Personally, I'm still not sure where RM32 comes from, as I've not   
   > noticed it documented anywhere.  ...  Of course, much the same can be   
   > said of PM16, unless you have some old manuals around.  Can anyone   
   > clarify?   
      
   RM32 is obviously undocumented. Same thing as Unreal Mode. Things which   
   aren't thought of by the designer. It's similar to the old Mode-X VGA mode.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)