From: nowhere@nevernet.at   
      
   On 14/02/2022 17:10, James Harris wrote:   
      
   >>>>> Why could it not be in PM running a 16-bit code segment?   
      
   >> at which address would you see such PM16 code?   
      
   > Within range 0 to 64k. See below.   
      
   this would mean starting from 0000:0000   
   but what value will the CS descriptor have then ?   
      
   >> while trueRM is limited to FFFF:FFFF (aka HMA minus 16),   
   >> PM16 blocks can reside anywhere within 4GB.   
      
   > I don't think so: PM16 is limited to 64k code segments. The following is   
   > from the 80286 documentation.   
      
   > The programmer views the virtual address space on the 80286 as a   
   > collection of up to sixteen thousand linear subspaces, each with a   
   > specified size or length. Each of these linear address spaces is called   
   > a segment. A segment is a logical unit of contiguous memory. Segment   
   > sizes may range from one byte up to 64K (65,536) bytes.   
      
   me too owe ye olde 286 manuals.   
   but later stuff said:   
      
   Protected Mode.   
   In this mode, the processor supports virtual-memory and physical-memory   
   spaces of 4 Gbytes and operand sizes of 16 or 32 bits. All segment   
   translation, segment protection, and hardware multitasking functions are   
   available. System software can use segmentation to relocate effective   
   addresses in virtual-address space. If paging is not enabled, virtual   
   addresses are equal to physical addresses. Paging can be optionally   
   enabled to allow translation of virtual addresses to physical addresses   
   and to use the page-based memory-protection mechanisms.   
      
   I once tested and set the base of an PM16 code descriptor to 3rd GB.   
   it worked but there was no much sense in doing that.   
      
      
   >>> Further, loading CS with a selector for a 32-bit ('big') descriptor   
   >>> will only affect the code segment. One or more data segments could   
   >>> still be 16-bit.   
      
   >> been there :) it crashed if you leave data selectors RM styled.   
      
   > It should work, AFAICS.   
      
   this BIG REAL mode (had been tried by a few brave enough) suffers a lot.   
   it can't use INT, IRQ and EXC by normal means. the workaround is a PITA.   
      
   >>> All this would make Real mode little more than a subset of Protected   
   >>> mode. Or, put another way, one could say that Real mode *is*   
   >>> Protected mode with:   
      
   >>> 1. certain values in the segment descriptors   
   >>> 2. different rules as to what it means to load a segment register   
      
   >> just a point of view matter ?   
      
   I see it the other way: PM came a long while after RM.   
      
   > To me this is more about gaining an insight into what is likely   
   > happening inside the processor, and thereby making it easier to understand.   
      
   But not much to learn if you're stuck with 286 ...:)   
      
   >>>>> Furthermore, you could consider that accesses off DS would also   
   >>>>> include checks but that the internal descriptor would have the   
   >>>>> limit set to 0xffff so nothing would be out of range.   
      
   >>>> You could setup smaller than 64K limits on Unreal Data segments.   
   >>>> this might raise a real mode exception because still in RM  :)   
      
   >>> Or PM16. :-)   
      
   >> :) look at the AMD pages which lists RM<>PM instruction differences,   
   >> and then check on a few to see if it is in RM or PM16.   
   >> hint: some instructions are privileged and a few aren't allowed.   
      
   > What about RM code? ISTM that a lot of RM code could work unchanged in   
   > PM16.   
   again: look at privileged instructions, work in RM but may fail in PM.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)