How to create dos/16m 286 protected mode programs with OpenWatcom

[Mills32]

Just tested on 86Box, (no real 286 for the moment, I think I can trust 86Box). Phar lap's protected mode was as fast as real mode in my particular case. That video showing the game running slower in protected mode, https://virtuallyfun.com/2024/01/29/phar-laps-286-dos-extender-why-nobody-used-it-for-games/... It is probably using some phar lap's library (I think) which makes the game go slow.

 

[BloodyCactus]

in the pharlap sdk install is a \swtest\swtest.exe that runs tests on the different switching in/out of pmode methods (you need to read swtest.txt for the details).

 

[MiaM]

I've linked to a case study. If you don't trust it, don't trust it.

The study you linked to only shows the cost of calling real mode APIs from protected mode. It says nothing about how many such calls Mills32 would need to do per time unit in his particular case.

 

[BloodyCactus]

Just tested on 86Box, (no real 286 for the moment, I think I can trust 86Box). Phar lap's protected mode was as fast as real mode in my particular case. That video showing the game running slower in protected mode, https://virtuallyfun.com/2024/01/29/phar-laps-286-dos-extender-why-nobody-used-it-for-games/... It is probably using some phar lap's library (I think) which makes the game go slow.

oh wow, I just read the article. thats my source code lol! Sarien. We did test pharlap back in the day, there was several dos ports (allegro/djgpp/watcom/etc).
if the engine is just pumping frames via memcpy to a mapped segment, theres a hit to loading the segment register but I wouldnt think it would impact it that much... I wonder if something else is going on.

 

[Mills32]

To finish this thread, I tested on a real 286 6-12MHz, + oak oti VGA. The game (it is just decoding the animations, not a real game right now) was as fast in protected mode as in real mode. (well, it does no run particularly "fast" ). It will only call a mouse function at 70/4 Hz, and that's all.