>> All,
>>
>> While I'm at it, figured I might as well add the beginning to
>> running guest real-mode (RM) code in the monitor using
>> v86 mode. That brings up some issues on that front to discuss.
It's a nice initiative Kevin, but it seems to me there are more urgent
things that need to be coded right now!! I'm not sure, but it would
probably be better to save realmode until PM is actually working well
(ie when you can run linux). After all, realmode support requires a
substantially different approach than the PM code. What do you think ?
>> The first is whether to pre-scan RM code pages. Ideally it
>> would be nice not to bother. But of course, the good people
>> at Intel created some less-than-perfect virtualization, even
>> of real-mode via v86 mode. For instance, the classic
>> v86 mode detection code:
>>
>> SMSW some_word
>> if (some_word & 0x0001) // CR0.PE==1
>> in_v86_mode = 1;
>> else
>> in_v86_mode = 0;
Can't we catch SMSW ? If not, we'll need to prescan...
I guess the solution you give, to have an option to turn prescan on/off,
would be best (this is the same as we were planning to do with PM ring3
code..)
>When you are running in real mode sometimes it's nice to know whether you
>could have precise timing and access the hardware directly or not (last
>case is true for advanced VM86 not like emm386). There could be some int
>service used by OS for these purposes though but it's different for every
>OS and it's not guaranteed that every OS has it. So maybe this feature is
>not so useless.
I don't agree. I think that plex86 should, if possible, catch this.
It would be a bug if it didn't. You associate VM86 checking with timing,
but I associate it with something different: in my experience, VM86 checking
is done in DOS programs only (1) inside DOS extenders, before switching to
PM, and (2) inside programs in order to check whether a DOS extender has been
loaded. In both cases, the program will crash/exit if it detects VM86 mode,
while in the VM we don't want it to detect but we want it to switch to PM!!
(which will cause an exception, which will make the monitor switch its logic.)
Thus, probably if we don't catch this, programs such as emm386, QEMM,
DOS4GW-based and DJGPP-compiled programs wouldn't work.
>> Perhaps it makes sense to ultimate have an option to run
>> without prescanning (SBE) for code which doesn't encounter
>> stuff like this.
>>
>I think that making the realmode task to think that there's no VM86 could
>only cause more troubles (it might think that it's true rm and go to
>access non-standard hardware directly) and perhaps a downgrade of
>performance. Performance is very critical for realmode, precision of timer
>and the most important - good SB-clone emulation (sound).
This is no different in PM. Timing is an issue that needs to be solved
in general, not specifically in RM.
-- Ramon
