VOGONS


NTVDM on windows 10 x64

Topic actions

Reply 40 of 89, by truemaster

User metadata
Rank Member
Rank
Member

this is an amazing work no doubt about it. too bad the inerest is so low didnt expect that. i will be good also some improvements to sb emulation it was hellish back then before dosbox release and vdmsound is only on xp. if an improvment is made it will be a good patch on even x86 osses

Reply 41 of 89, by leecher

User metadata
Rank Newbie
Rank
Newbie

Why not use SoundFX 2000?
http://www.softsystem.co.uk/products/soundfx.htm

Works fine for me in NTVDMx64. There was a bug in the NTVDMx64 loader that prevented it from loading, but I already fixed it.

Reply 42 of 89, by KST_17

User metadata
Rank Newbie
Rank
Newbie

Thanks a lot, leecher, for your proof-of-concept. This also proves that it is possible to implement anything, bypassing the limitations of windows x64.
But in my laptop (spec: intel i7-2630qm w/ intel hd3000 integrated videocard, win7x64) NTVDMx64 lags, although the display of console applications is great. Low framerate and increase loading CPU. I do not think that my processor is rather weak for CCPU emulation because VMWare works perfect without a large load. Give advice or help something.

Reply 43 of 89, by leecher

User metadata
Rank Newbie
Rank
Newbie

Hi,

As you are speaking of it, I signifially improved to SAS memory-interface to the CCPU yesterday, because scrolling was really slow on the console as soon as the emulated EGA/VGA kicked in.

There is a smart logic for console mode in NTVDM: If you just do normal text I/O via the INT 21h DOS-functions or do just teletype write, the NTVDM doesn't do any video adapter emulation and just flushes out anything to console. So you have the advantage of fast output and console redirection. As soon as your application does any cursor positioning and such (i.e. via INT 10h), it switches the console over to video adapter emuation (which is slow) and stays that way until you close the console.
The video adapter emulation does a lot of I/O on the virtual video buffer and therefore slows down everything.

Now my impovement to the SAS-routines at least allows block-wise memory moving which significally improves video output performance ov the 1-byte based read/write loops it originally uses.
I will provide a patch the next days on github that patches in the improved SAS-interface, stay tuned.

However don't expect too much from the C_VIDC emulation of NTVDM. Remember that the original NTVDM doesn't do any console graphics but instead always switches to fullscreen (X86GFX) as soon as there is graphic output, because it can take advantage of the fact that it can directly write to the VGA video card (via the miniport driver) which is blazing fast.
But Microsoft introduced a new display driver model with Windows 7 (WDDM as opposed to the old XPDM), which lacks the possibility to use the VGA card directly (but is better for fast output rendering). This causes the problem when you get an error message when you try to switch a console window to fullscreen with ALT+RETURN.
In Windows 7, the kernel supported both display driver models, so you were able to switch between them. By simply disabling the WDDM display driver, you were switched back to Standard VGA XPDM driver semalessly and were able to use NTVDM like you were used to from XP. There are even patches out there, that automated this for you.
Unfortunately, with Windows 8, the support for XPDDM was gone for good and so was NTVDM's ability to use fast, direct video output.
However the Windows console has always featured a console graphics buffer, as it was also needed for non-X86 builds of NTVDM. It has a bug that must be fixed (which the NTVDMx64 loader does for you). So in Alpha/MIPS/PPC builds, an emulated video card was used and fortunately the sourcecode contained the C_VIDC c-implementation of it. Insignia emulated a full Video controller, but not in neat C-code, as one would expect, but they used something called J-code, which seems to be some intermediate code that was then compiled to unreadable, ugly C-code. It seems to work, but it's not very fast.
There also is the flavor of A_VIDC, which would specify an interface to an Assembler-based video card emulation. As far as my analysis has shown, for non-X86 builds, the didnt use the C_VIDC but maybe the A_VIDC. However, we don't have any sources for it, so our only option to get rid of the slow C_VIDC would be to write our own, faster implementation, if possible with the given architecture.

So, long story short: NTVDM's video card emulation sucks... Maybe someone wants to have a look at it?

Regarding the CPU load, there already is a nice trick on the original NTVDM to keep CPU load low, I think most of the people here know it: https://forum.qbasic.at/viewtopic.php?t=2172
Basically, these are TSRs that hook the timer interrupt and release the timeslice to the host CPU on idling. They also work on NTVDMx64. The original download seems to be unavailable, here is a mirror: http://dose.0wnz.at/auslast.zip

Have a nice DOS...

Reply 44 of 89, by truemaster

User metadata
Rank Member
Rank
Member

yes its slow because v86mode is not avaible on long mode, when a x64 os is working the cpu switches to long mode. your cpu is fine. that is a big if not the main issue why ntvdmx64 works slower than the one on x86 machines. maybe a rework in the cpu emulated area make things better. porting cpu emulation from dosbox a way through?

Reply 45 of 89, by leecher

User metadata
Rank Newbie
Rank
Newbie

I'm currently working on HAXM integration, not sure if I will get it working, the new SAS implementation is also a result of the preparation work being done for HAXM-based monitor. However, remember that also in V86 mode/HAXM, when emulating the graphics card, the CPU has to call back to the supervisor to talk with the emulated VGA card, so as long as the video adapter emulation isn't very fast, I don't know if there will be significant performance gains. Original NTVDM didn't rely on a slow emulated video adapter.

Reply 46 of 89, by truemaster

User metadata
Rank Member
Rank
Member

mmm got it. another question in x86 machines we can create a shortcut of a 16bit exe the so called pif in x64 even with this patched ntvdm the shortcut creation gives error about space why is that?

Reply 47 of 89, by leecher

User metadata
Rank Newbie
Rank
Newbie

How did you create the .pif file on x64? iirc pifedit.exe only existed on Win 3x, and on 32 bit windows, functionality was incorporated into the shell. I haven't tried them yet.

Reply 48 of 89, by truemaster

User metadata
Rank Member
Rank
Member

oh sorry you didnt undreastand well in x86 windows we can create a pif shortcut. but why in x64 even after install of the ntvdmx64 any attempt to create a pif gives an error about not enough space and pif cant created

Reply 49 of 89, by leecher

User metadata
Rank Newbie
Rank
Newbie

Ah, you mean just creating a shortcut to a 16bit application. Well, the shell doesn't support it, because there never existed any 16bit support on 64bit Windows. We may be able to patch the shell and write some extension that re-adds this funtionality, but it wasn't a real top priority, as one can easily create a .bat or .cmd file as a launcher and just do a shortcut to it for instance.
Microsoft also removed the 16bit resource-parser in Windows 7 which makes it impossible for you to use an icon of a 16bit application in a shortcut even on 32bit versions.
But as we currently only support DOS with NTVDMx64 (as there already is the excellent WineVDM for Win16), the missing icon parser will be the least problem. 😉

Reply 50 of 89, by crazyc

User metadata
Rank Member
Rank
Member
leecher wrote:

Microsoft also removed the 16bit resource-parser in Windows 7 which makes it impossible for you to use an icon of a 16bit application in a shortcut even on 32bit versions.

FWIW, I added a workaround in winevdm for this at https://github.com/otya128/winevdm/commit/4ed … 0f8bf914605dbc2.

leecher wrote:

I'm currently working on HAXM integration, not sure if I will get it working, the new SAS implementation is also a result of the preparation work being done for HAXM-based monitor. However, remember that also in V86 mode/HAXM, when emulating the graphics card, the CPU has to call back to the supervisor to talk with the emulated VGA card, so as long as the video adapter emulation isn't very fast, I don't know if there will be significant performance gains.

I put an issue for this at https://github.com/intel/haxm/issues/164. I haven't been able do anything with the suggested solution though.

Reply 51 of 89, by truemaster

User metadata
Rank Member
Rank
Member

ah ok got it. i thought the pif shortcuts made from ntvdm or dos but is not. i total agree with you patching ntvdm for better fuctionality is higher priority than patching the shell for pif creation. about the .bat and cmd creation they are are ok but .pif have also memory adjustments not found on .cmd and .bat and that propably will make shell patching a thing sometime.

Reply 52 of 89, by leecher

User metadata
Rank Newbie
Rank
Newbie
crazyc wrote:

I put an issue for this at https://github.com/intel/haxm/issues/164. I haven't been able do anything with the suggested solution though.

I added functionality for BOPping to haxm, may issue a Pull-Request for it, as it may also be benificial for other users as well. This patch was easy.
But do you know by any chance if there is a shortcut for translating a linear to a physical address from usermode side? I think about adding another IOCTL for it, but maybe I missed something? Manual pagetable parsing also doesn't sound very appealing.

Reply 53 of 89, by KST_17

User metadata
Rank Newbie
Rank
Newbie
leecher wrote:

Regarding the CPU load, there already is a nice trick on the original NTVDM to keep CPU load low, I think most of the people here know it: https://forum.qbasic.at/viewtopic.php?t=2172
Basically, these are TSRs that hook the timer interrupt and release the timeslice to the host CPU on idling. They also work on NTVDMx64. The original download seems to be unavailable, here is a mirror: http://dose.0wnz.at/auslast.zip
Have a nice DOS...

Danke, leecher) This patch realy decrease CPU loading in some console application like edit, turbo pascal 7, etc.
But low framerate is remained. For console editors it doesn't matter. Only for game maybe.

leecher wrote:

But Microsoft introduced a new display driver model with Windows 7 (WDDM as opposed to the old XPDM), which lacks the possibility to use the VGA card directly (but is better for fast output rendering). This causes the problem when you get an error message when you try to switch a console window to fullscreen with ALT+RETURN.
In Windows 7, the kernel supported both display driver models, so you were able to switch between them. By simply disabling the WDDM display driver, you were switched back to Standard VGA XPDM driver semalessly and were able to use NTVDM like you were used to from XP. There are even patches out there, that automated this for you.

I don't know about that. And I think my "new" integrated videoadapter doesn't support XPDM( Maybe it works on VGAsafe or standart VGA adapter.
From here: https://www.betaarchive.com/forum/viewtopic.p … 6830&hilit=xpdm

Reply 54 of 89, by leecher

User metadata
Rank Newbie
Rank
Newbie

Just wanted to let you know that I committed the faster SAS-interface, maybe it helps a bit performance-wise. Maybe someone can test it if it introduces some new problems, as I didn't test it so thoroughly.
It won't help much with the video output (i.e. games), but scrolling in textmode when doing video emulation should perform much better now.

Reply 55 of 89, by leecher

User metadata
Rank Newbie
Rank
Newbie

I now tried to implement HAXM VT-x support into NTVDM.
I didn't find a way yet, how to properly hook INT-calls in order to get DPMI working somehow, but even in realmode, it's dreadfully slow, because of the lack of XPDDM drivers and the associated problem that the video card needs to be emulated.
This results in thousands of HAX_EXIT_FASTMMIO calls for updating the screen which all cause the VM to exit, then EGA/VGA emulation in NTVDM has to do handling of the read/write command and then it has to resume VM which causes a very, very big overhead. Thus, the emulated C-CPU still performs far better, as it doesn't have to do all these context switches all the time. So basically the same problem that crazyc wrote about.
Setting up a usermode emulator for these instructions sounds like a horrible amount of work to me as it would also require to check when emulation can switch back to VT-x again.

I made a special build of HAXM which allows me to do BOPping like required by the NTVDM.

Is anybody interested in the HAXM-support sourcecode anyway? Given these limitations, I think it's not really worth to work on it any further.

Reply 56 of 89, by crazyc

User metadata
Rank Member
Rank
Member

For a workaround you can do what DOSEMU does and run the vm in v86 mode. If you don't map the vram then you and use the page fault handler to force a vmexit then emulate until the vram access appears to be complete then return to the vm.

Reply 59 of 89, by robertmo

User metadata
Rank l33t++
Rank
l33t++

what i ment was why do you bother with improving ntvdm while we already have dosbox that is perfect (has even d3d in win9x) just missing the cpu speed. (it already has gfx speed)
trying to make ntvdm as good as dosbox will require a lot of unnecessary work.
why making a whole new emulator for just few win9x games with 16-bit installers while dosbox can run win9x games even with 32-bit installers.