From: branimir.maksimovic@gmail.com   
      
   On 2021-07-01, Rod Pemberton  wrote:   
   > On Thu, 01 Jul 2021 00:51:39 GMT   
   > Branimir Maksimovic  wrote:   
   >   
   >> On 2021-06-30, Rod Pemberton  wrote:   
   >> > On Tue, 29 Jun 2021 23:05:49 GMT   
   >> > Branimir Maksimovic  wrote:   
   >> >> On 2021-06-28, Rod Pemberton  wrote:   
   >> >> > On Sun, 27 Jun 2021 15:17:43 GMT   
   >> >> > Branimir Maksimovic  wrote:   
   >> >> >> On 2021-06-27, Rod Pemberton  wrote:   
   >   
   >> >> >> > IIRC, memtest86+ loads from DOS.  So, it's likely 16-bit code   
   >> >> >> > too, or possibly 32-bit if was compiled for DPMI.  32-bit   
   >> >> >> > might not be too bad.   
   >> >> >>   
   >> >> >> memtest86 can test more then megabyte so I guess it is not 16   
   >> >> >> bit...   
   >> >> >   
   >> >> > Aren't you familiar with "unreal" mode? ...   
   >> >>   
   >> >> Yes, but that is 32 bit, not 16 bit programs...   
   >> >   
   >> > No, unreal mode is generally 16-bit real-mode code.  It's called   
   >> > unreal mode because you have access to the entire memory range in   
   >> > real-mode.   
   >> >   
   >> > As I understand it, 32-bit unreal mode is exceptionally difficult to   
   >> > use due to an issue with interrupts.  The only 32-bit unreal mode   
   >> > example that I'm aware of is/was FASM.   
   >>   
   >> Look, you cannot reach more than megabyte with 16 bit program, you   
   >> need 32 bit instrucion...   
   >   
   > Sure you can.  You'd only need a 16-bit mixed-mode x86 instructions   
   > (386 or later).  You can do that without use of unreal mode.  I.e.   
   > address-size (67h) override used within 16-bit code in a 16-bit code   
   > segment, to allow for 32-bit addresses.   
      
   Look I programmed DOS like that in early 90es.   
      
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)