Open happymimimix opened 7 months ago
List of supported VESA video modes available:
That's all there is for Insignia softpc. 1080x720 is not a known VESA mode: https://faydoc.tripod.com/structures/00/0083.htm
What graphics device shall I choose in the program to take full advantage of these modes? Is there any extra drivers I shall install in order to use higher resolutions?
By the way can I use Tame DOS with NTVDM x64 on Windows 10?
Depends on whether your program supports VESA modes or not. This is DOS-application specific, so there is no general answer to that question.
Tame can only be used with NTVDMx64 on Windows 7, as the necessary function to support mapping memory at address 0 has been removed in higher Windows versions, as I already mentioned. It would be necessary to rewrite TAME to obey NTVDM extension specification, which was not done by the author.
Sorry, saw that I provided the wrong link to the supported VESA modes. Here is the correct one: https://github.com/leecher1337/ntvdmx64/blob/cc09cbd87ea3ec61e135c34935675211601f2fda/ntvdmpatch/experimental/vesa/softpc.new/base/video/vesa_video.c#L117
Only 0x100 - 0x104 are supported due to limitations of the V7 VGA emulation of the SoftPC. Reverse Engineering and porting over the whole SoftWindows 5.0 Video engine would be a horriffic amount of work, so most likely it will never happen. If someone feels like he wants to do it, I can provide IDA databases with annotations as a starting point.
Depends on whether your program supports VESA modes or not. This is DOS-application specific, so there is no general answer to that question.
Tame can only be used with NTVDMx64 on Windows 7, as the necessary function to support mapping memory at address 0 has been removed in higher Windows versions, as I already mentioned. It would be necessary to rewrite TAME to obey NTVDM extension specification, which was not done by the author.
Can we somehow patch some system files to bring back the ability to map memory to address 0? It would be incredibly useful to make tame run on windows 10 x64.
Depends on whether your program supports VESA modes or not. This is DOS-application specific, so there is no general answer to that question. Tame can only be used with NTVDMx64 on Windows 7, as the necessary function to support mapping memory at address 0 has been removed in higher Windows versions, as I already mentioned. It would be necessary to rewrite TAME to obey NTVDM extension specification, which was not done by the author.
Can we somehow patch some system files to bring back the ability to map memory to address 0? It would be incredibly useful to make tame run on windows 10 x64.
My guess is that the only possible chance of a reply is to offer to pay for the rewrite. Tame was offered for sale, not as freeware, and my guess is that a substantial payment might be the only way to get results.
P.S. I was last in touch with the author in 2018 - a long time ago.
My guess is that removing the limitation can be done with a driver patching the system's memory mapping function (not sure if patch guard wouldn't get into my way when doing so, would need to test) or by reimplementing the memory mapper in my own driver (might get very complicated in more recent Windows versions).
But if you don't mind loading unsigned drivers in test mode, I can try to write a patch.
Anyways, I'm not quite sure about the usefulness of Tame for NTVDMx64, i.e. when using graphics mode, it just slows down the NTVDM further. But its textmode capabilities are nice for sure. Maybe you want to give it a try on a Win 7 VM to first check if it would be of any real use?
I wonder if there are still ppl. buying TAME licenses given the fact that 32bit Windows market share goes down, too bad TAME isn't open source nowadays...
My guess is that removing the limitation can be done with a driver patching the system's memory mapping function (not sure if patch guard wouldn't get into my way when doing so, would need to test) or by reimplementing the memory mapper in my own driver (might get very complicated in more recent Windows versions).
But if you don't mind loading unsigned drivers in test mode, I can try to write a patch.
Anyways, I'm not quite sure about the usefulness of Tame for NTVDMx64, i.e. when using graphics mode, it just slows down the NTVDM further. But its textmode capabilities are nice for sure. Maybe you want to give it a try on a Win 7 VM to first check if it would be of any real use?
I wonder if there are still ppl. buying TAME licenses given the fact that 32bit Windows market share goes down, too bad TAME isn't open source nowadays...
Driver signature requirement is completely gone in my mod of Windows 10 22H2, aka Lindows! Feel free to send me any unsigned drivers as much as you like!
Note to people who may see my comment and wanna know where you can get Lindows: This product is still very much work in progress and there are still large amounts of other stupid restrictions I would like to remove. I will publish the iso image on github whenever it's finished and anyone can download it for free. If anyone is interested in joining the development, contact me on discord: My username: happy_mimimix.
It may not be benificial to use the name of an already-existing product as it may lead to confusion (besides Trademark violations): https://en.wikipedia.org/wiki/Linspire
Ok, I'll try if I can patch the limit when I have some time.
Short update on this: Even though it seems to be possible to map page 0 via a kernel mode driver on Windows 8 or higher, it seems to lead to weird stability issues with the affected application. This has been verified with a patchet NtAllocateVirtualMemory
function in order to ensure that it is not related to a bug in the driver.
Therefore TAME compatbility seems to be impossible on Windows >7, as the OS seems to sometimes lookup the memory page of the GS register incorrectly which then points to page 0 and therefore read wrong data leading to crashes. Why this happens randomly is unknown, maybe some mechanism in the Kernel?
If someone knows how to find out the cause, I can upload the driver for mapping page 0 (latest loader already has support for it): https://github.com/leecher1337/ntvdmx64/blob/d9c75bdb68f2c4b42bf2b8caf5cd130c9769f3d2/ntvdmpatch/src/ldntvdm/ldntvdm/config.h#L100
A very strange discovery on the graphic mode of ntvdm x64: If I click on the icon of the command window and click edit > mark, then the whole window acts like if they were all text but each character takes up only 1 pixel. Is that what "graphic mode" in msdos actually is? Just a bunch of characters with size 1*1 and not actual graphics? Or, is that just how NTVDM handles them and that's not the case in a real dos machine?
Also is there a way to disable the new windows 8 style "this program cannot run on your device" dialog? The traditional one provides much more detail.
Just curious if it's possible to get a high resolution true color graphics mode in NTVDM x64? Perhaps copy some code from dosbox to emulate a virtual graphics card that can provide better graphics? Maybe?