• Please review our updated Terms and Rules here

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

M

Mills32

Experienced Member
Joined
Sep 25, 2018
Messages
179
Location
Spain
This is related to my other thread about decompiling a game. I think it's better posted in a separate thread.

So, how do I create an exe which can be loaded by a 286 dos extender so that the program works in 286 protected mode?.

Open watcom has some settings to create "dos16m", "286", "dos4g" exes, but none of them work... Or I don't know how to do it properly. I tried using run286 to load the programs, but it only works with programs generated with borland bcc286 (and it was a pain to use)?.

Thanks.
 
Last edited:
in the olden days we built 286 specific applications with MSC (don't recall what version) and Pharlap 286 extender. Watcom was better known for their inclusion of freebie DOS4GW.
 
DOS extenders were commercial products and sold separately. Open Watcom can produce DOS/16M-compatible binaries, but you are still missing DOS/16M itself.
 
Svenska said:
DOS extenders were commercial products and sold separately. Open Watcom can produce DOS/16M-compatible binaries, but you are still missing DOS/16M itself.
Click to expand...
I know, I generate a DOS/16M binary, but what extender can load it?.
I mean... there is no "dos16m.exe" or is it? I could not find it.
Do I need something else in the code itself?. I just can't find any info at all, everything I find is about 32 bit protected mode.
 
Mills32 said:
I mean... there is no "dos16m.exe" or is it? I could not find it.
Click to expand...
DOS/16M is not shipped with Open Watcom. Do you have the commercial distribution?

edit: I mean the DOS/16M commercial distribution, not Watcom.
 
Last edited:
Svenska said:
DOS/16M is not shipped with Open Watcom. Do you have the commercial distribution?

edit: I mean the DOS/16M commercial distribution, not Watcom.
Click to expand...
I don't have it... it looks like it is difficult to find.

There is no point in creating a game which uses that, if it is still commercial and difficult to find, I thought it was released with open watcom.
 
Last edited:
Terry Colligan gave permission before he passed for the Professional version of dos4gw in OW. I dont believe he gave permission for the DOS/16M extender.

but you could probably pull the extender off an existing app easily enough (exospace for ca clipper v5.3).
 
I guess I can just set protected mode myself from the code. Then you just reset the PC/emulator to exit the game.
 
Plasma said:
Phar Lap 286 Extender should work with Open Watcom. There is an example in the manual.
Click to expand...
Thanks. But that's for 386, not 286. I already found the pharlap setting, and it is ment for a 32 bit version I think, because it complains about my file being 16 bit. But maybe it works :).
Code: 
Warning! W1080: file pm286.obj is a 16-bit object file
 
Well, I had to install "watcom 10.0" and run it in dosbox. It has "pharlap" setting for compiler (I think...), I hope this is the one that works.
 
Mills32 said:
Well, I had to install "watcom 10.0" and run it in dosbox. It has "pharlap286" setting for compiler, I hope this is the one that works.
Click to expand...

if it works, easy to pull that stuff into OWv2. probably just an entry in the wlink.lnk / wlsystem.lnk file that points to the extender

(i can check when I get home, I have original Watcom CD's of 9/10/11 from back in the day.)
 
BloodyCactus said:
if it works, easy to pull that stuff into OWv2. probably just an entry in the wlink.lnk / wlsystem.lnk file that points to the extender

(i can check when I get home, I have original Watcom CD's of 9/10/11 from back in the day.)
Click to expand...
It won't work... it is probably the 32 bit version:

Code: 
system begin pharlap
    libpath %WATCOM%\lib386
    libpath %WATCOM%\lib386\dos
    format phar ^
end
 
The "Phar Lap 286 DOS Extender SDK 3.0"... exists on archive.org

It works with Borland C++ 2.0/3.0/3.1/4.0.

*edit* I see it was posted above, and it is the 286 version. not the 386 version.
 
Last edited:
BloodyCactus said:
The "Phar Lap 286 DOS Extender SDK 3.0"... exists on archive.org

It works with Borland C++ 2.0/3.0/3.1/4.0.

*edit* I see it was posted above, and it is the 286 version. not the 386 version.
Click to expand...
Thanks, I think that's the only way.
 
Running games in Protected Mode on a 286 is not very beneficial. For a real example, see [here].

In Real Mode, access to XMS is not transparent and using HIMEM.SYS to copy from/to XMS is slow because of the mode switch. But most 286 machines did not have much XMS to start with (often just 384 KB), and it was used as disk cache already.

In Protected Mode, everything else is slow. Now, any system call (keyboard, mouse, disk, network drivers) require a mode switch. Any hardware interrupt requires a mode switch. And memory management is still annoying because you cannot address more than 64 KB at the same time.

For business applications, it makes sense. It also makes sense for operating systems (and all applications run within). But for games on a DOS substrate, it isn't that useful.
 
Svenska said:
Running games in Protected Mode on a 286 is not very beneficial. For a real example, see [here].

In Real Mode, access to XMS is not transparent and using HIMEM.SYS to copy from/to XMS is slow because of the mode switch. But most 286 machines did not have much XMS to start with (often just 384 KB), and it was used as disk cache already.

In Protected Mode, everything else is slow. Now, any system call (keyboard, mouse, disk, network drivers) require a mode switch. Any hardware interrupt requires a mode switch. And memory management is still annoying because you cannot address more than 64 KB at the same time.

For business applications, it makes sense. It also makes sense for operating systems (and all applications run within). But for games on a DOS substrate, it isn't that useful.
Click to expand...
In my case, once the game is running, it will only call mouse functions at around 17 fps. The rest of the code is just copying image data from ram to vram, and computing some math. Well i'll have to add the music player which is a software interrupt, so nothing bad there?.

About using 64k chunks, it's ok, the game data fits fine in that, (for example animation frames). Anyway I'll test it and post in the other thread, and use real 286 and 86box to test if it is slower.


[SOLVED]
To use protected mode on 286:
- use "Phar Lap 286 DOS Extender SDK 3.0" (archive.org for example).
- Also install Borland C++ (I tested 3.0).
- Then go to phar lap folder "RUN286\EXAMPLES\USEGUIDE\CHAP1".
- Write this or create a make.bat:

Code: 
set LIB=C:\RUN286\bc3\lib;C:\borlandc\lib
set PATH=C:\dos;C:\RUN286\bin;C:\borlandc\bin
rem compile any sample, like memtest. "-mh" is not needed, I was just testing
bcc286 -mh memtest.c

If it complains about not finding BCH286.LIB or BCL286.LIB, look for then in any other phar lap version (3.12) and paste the libs in "RUN286\BC3\LIB". (maybe I installed it wrong?).

Generated EXE file needs "RUN286.EXE" and "DOSCALLS.DLL" in the same folder to create a standalone program.

For the moment I can only use 1 Mb ( 2Mb total RAM), but I think that's enough for me.
 
Last edited:
Svenska said:
Running games in Protected Mode on a 286 is not very beneficial. For a real example, see [here].

In Real Mode, access to XMS is not transparent and using HIMEM.SYS to copy from/to XMS is slow because of the mode switch. But most 286 machines did not have much XMS to start with (often just 384 KB), and it was used as disk cache already.

In Protected Mode, everything else is slow. Now, any system call (keyboard, mouse, disk, network drivers) require a mode switch. Any hardware interrupt requires a mode switch. And memory management is still annoying because you cannot address more than 64 KB at the same time.

For business applications, it makes sense. It also makes sense for operating systems (and all applications run within). But for games on a DOS substrate, it isn't that useful.
Click to expand...
disk and network access would be magnitudes slower than the real/protected mode switch anyways, except of course whatever is read from cache. I.E. if you read large enough chunks and don't re-read the same data again then for disk and network I/O the performance penalty should be negligible.
Possibly any multiplayer style network use might hurt performance somewhat. However in an action game you can't have the game react faster than the screen refresh rate anyways, and thus you can to an extent do all real mode API calls in one go once for every screen redraw/refresh cycle. Network drivers probably needs interrupts to be able to transmit/receive data without buffer over/under runs.

There are afaik only really four mouse protocols that you need to support on a PC. Microsoft bus mouse Microsoft and Mouse systems serial port mice, and PS/2 mouse. Also protected mode requires a 286 and thus the keyboard controller is always AT for a fully compatible machine.
In particular for 286 class machines the same caveats as for for example Windows in protected mode applies, where well known brands seems to still not had dared to do 100% IBM compatible hardware. But for a hobbyist writing a game you can kind of decide to not give a s**t about people who happen to have a HP 286, or you can release your code as open source and let others add support for less common machines.

If you want to you could also add your own drivers for network cards and even disk I/O. Kind of like how Windows evolved from always calling real mode APIs for everything except video and possibly keyboard/mouse I/O, to in the latest WfW3.11 have it's own protected mode code for disk I/O, filesystem implementation (including a better cache than smartdrv), network card driver, protocol stack and whatnot.
And sure, it would be a gigantic feature creep to add all this to a game, and in particular for disk I/O it would be a huge risk of damaged reputation if the game writes data to disk rather than just read it and has a bug that corrupts your disk. If the code can return to the DOS prompt safely it seems easier to just save any high score / game save data at the end using the DOS APIs while at the start of the game maybe call any API to flush disk caches and then run your own MFM/IDE disk I/O code for reading from disk. I'm not 100% sure but I think that the BIOS of a PC never assumes that the MFM/IDE hard disk controller is in a particular state when doing reads/writes, but I may be wrong. Since a lot of different BIOSes seems to be dumped and can be ran in 86box it would likely not be hard to test what happens if you set the hard disk controller to various states and then return to DOS. Thinking about it I've never heard of problems using various "disk maintenance" programs (in that that I've never heard of them causing trouble for continuing running the computer after exiting the program, without needing to reboot).
 
You must log in or register to reply here.
Back
Top