Confirmed ... As clarified in Volume 2 on page 14 (9/07 revision): http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf "Virtual-8086 mode is not supported when the processor is operating in long mode. When long mode is enabled, any attempt to enable virtual-8086 mode is silently ignored." If you read through Section 1.3, it explains much of this. Starting with Table 1-1 on page 11, it breaks down how there is A) Long Mode and B) Legacy Mode, and how the former has A1) 64-bit Mode and A2) Compatibility Mode, whereas the latter has B1) Protected Mode, B2) Virtual 86 mode and B3) Real Mode. Now it seems that A2 (Compatibility Mode) supports 16-bit/16-bit and might be a bit confusing. But if you look at B1 (Protected Mode), you'll note 16-bit/16-bit is also supported. Here's the key. A2 (Compatibility Mode) _requires_ Protected Mode. The processor can_not_ exit Protected mode. Although Virtual 8086 is a form of it, it is not the same thing, and does not work in A2. Again, I regularly invite people to read Chapter 1 in Volume 2 because it explains a lot about the x86-64 architecture, including how register addresses v. page addresses v. physical addresses are also at work. The whole idea behind "Long Mode" is maximum compatibility with i386+MMU (basically the i486 TLB, as well as i686 PAE). That means there are constraints on 16-bit/32-bit compatibility, as well as "hard" limits at 48-bit flat and 52-bit paging as well. ----- Original Message ---- From: Bryan J Smith <b.j.smith@xxxxxxxx> Virtual86 != Protected386 Long Mode supports Protected386, but not Virtual86. At least that's what I remember from first reading the AMD x86-64 Programmer's docs over 5 years ago. I'll check when I'm in front of a computer again. Protected386 can still provide DPMI, but it's not the same as Virtual86. Long Mode is designed for 4-byte flat and 6-byte segmented/normalized pointer compatibility, not 4-byte segmented/normalized pointer compatiblity. Again, it's still quite possible to run DPMI programs, but the processor won't be using Virtual86 IIRC. If you study how Long Mode works (which is _not_ 64-bit), it starts to make sense how it has its limitations (which allows for i486 TLB compatibility). -- Bryan J Smith - mailto:b.j.smith@xxxxxxxx http://www.linkedin.com/in/bjsmith Sent via BlackBerry from T-Mobile -----Original Message----- From: "Andrew Bird (Sphere Systems)" <ajb@xxxxxxxxxxxxxxxxxxx> Date: Sun, 25 Oct 2009 19:57:37 To: <b.j.smith@xxxxxxxx> Cc: <linux-msdos-owner@xxxxxxxxxxxxxxx>; <linux-msdos@xxxxxxxxxxxxxxx> Subject: Re: Crash on app startup with cpuemu=vm86(corrected) Hi Bryan, Mmm I wondered about that, but thought that DPMI support meant that the executable had to be running in protected mode. The fly in the ointment of course in that argument is whether a TSR(btrieve) could be run in. So am I better off to rebuild the host machine to i386 arch (32bit) and run with _cpu_emu=off, will that give me near native speed? Thanks, Andrew On Sunday 25 October 2009, Bryan J Smith wrote: > I'm fairly certain thay when the processor is in "Long Mode" > (48-bit flat, 52-bit PAE) that Virtual86 is not supported. > "Long Mode" is only compatible with 32-bit flat, 36-bit PAE > addressing, and not 20-bit. > > ------Original Message------ > From: Andrew Bird (Sphere Systems) > Sender: linux-msdos-owner@xxxxxxxxxxxxxxx > To: linux-msdos@xxxxxxxxxxxxxxx > Sent: Oct 25, 2009 12:20 > Subject: Crash on app startup with cpuemu=vm86(corrected) > > Hi guys, > I wonder if anyone can help me? I have a bespoke app(DPMI), which uses the > btrieve TSR, it is misbehaving on startup. The test hardware is x86_64 > Athlon X2 , Fedora 11(64 bit install). > > The app is working fine with _cpu_emu=vm86sim and as far back as dosemu > 1.2.2. > > I'd like to get this running with _cpu_emu=vm86 and dosemu 1.4.0 for extra > speed. Here's the relevant log at crash time, it was generated by SVN 1988 > > Thanks > > > Andrew > > EMU86: directly calling int 0x10 ax=0x20e at 0xf800:0x6330 > SetSeg REAL CS:f800 > SetSeg REAL SS:2390 > SetSeg REAL DS:2390 > SetSeg REAL ES:b800 > SetSeg REAL FS:0000 > SetSeg REAL GS:0000 > INTERP: enter=000fe330 > SetSeg REAL CS:f000 > INTERP: exit=000fc010 err=13 > EMU86: retval=VM86_UNKNOWN > Sys timers d=0 > Do INT0x10: Using caller_function() > 3d4 { 40e > 3d4 { 820f > SetSeg REAL CS:1091 > SetSeg REAL SS:2390 > SetSeg REAL DS:2390 > SetSeg REAL ES:b800 > SetSeg REAL FS:0000 > SetSeg REAL GS:0000 > INTERP: enter=000109a6 > SetSeg REAL CS:0d69 > ** JMP: ignored > SetSeg REAL CS:901f > SetSeg REAL CS:1be6 > ** JMP: ignored > SetSeg REAL CS:958f > SetSeg REAL CS:10f6 > SetSeg REAL CS:958f > leavedos(47810|0xbac2) called - shutting down > > killed while in vm86(), trying to dump DOS-registers: > Program=emu.c, Line=492 > EIP: 1091:00000096 ESP: 2390:0000e9a2 VFLAGS(b): 00000 00110010 01000110 > EAX: 0104020e EBX: 00000000 ECX: 00000050 EDX: 00000e22 VFLAGS(h): 00003246 > ESI: 0000ebe4 EDI: 00000904 EBP: 0000e9a8 DS: 2390 ES: b800 FS: 0000 GS: > 0000 FLAGS: PF ZF IF RF VM VIF IOPL: 3 > STACK: 1c 00 00 00 96 00 91 10 46 32 -> 97 32 90 23 90 23 d4 ec 5c 08 > OPS : 03 90 8a f0 33 db b4 02 cd 10 -> 9d 07 1f 5d ca 0a 00 00 00 00 > 9d 1091:0096 popf > closing debugger pipes > -- > To unsubscribe from this list: send the line "unsubscribe linux-msdos" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- > Bryan J Smith - mailto:b.j.smith@xxxxxxxx > http://www.linkedin.com/in/bjsmith > Sent via BlackBerry from T-Mobile > -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±šÇh²)í…æèw*jg¬±¨¶‰šŽŠÝ¢j/�êäz¹Þ–Šà2ŠÞ™¨èÚ&¢)ß¡«a¶Úþø®G«�éh®æj:+v‰¨Šwè†Ù¥ -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
