I think perhaps my best bet here is to develop on a 486 or Pentium-class machine with OpenWatcom, and set it to produce 8086-compatible executables. Primary testing can be done on the development system, and more thorough testing can be done on the target system.

My instinct is to not use DOSBox, the reason being it tries to provide a "perfect" environment for DOS programs (i.e. lots of available memory, high stability, the most compatible hardware, etc), which you will not get most of the time on real hardware, especially an XT class machine.

However, @Jo22 I am looking into PowerC.

Edit: Holy cow, I didn't see this before: https://github.com/open-watcom
I was using the original Open Watcom, version 1.90.

keenmaster486 wrote:

I think perhaps my best bet here is to develop on a 486 or Pentium-class machine with OpenWatcom, and set it to produce 8086-compatible executables. Primary testing can be done on the development system, and more thorough testing can be done on the target system.

if targeting real mode code, be aware that using say 32bit ints will not give you the results you expect. its a bug in OpenWatcom

eg: below is issue for xt/286 if using uint32_t but fine in 386+ real mode or pmode.

1uint32_t q;
2
3// will not give you result you expect because bug in integer promotion
4// despite result being able to handle it.
5q = 256 * 1024;
6
7// may give expectant result but I've had issues in past
8q = (uint32_t)256  * (uint32_t)1024;
9
10// will give expectant result
11q = 256;
12q *= 1024;

keenmaster486 wrote:

My instinct is to not use DOSBox, the reason being it tries to provide a "perfect" environment for DOS programs (i.e. lots of available memory, high stability, the most compatible hardware, etc), which you will not get most of the time on real hardware, especially an XT class machine.

Well dosbox does not try to be perfect it tries to be fast. I ran into something a while back, that is quite simple. Dosbox lets you write to CS: in protected mode that is marked execute only, on real hardware it causes a fault, on dosbox, it works perfectly fine.

dosbox is good for development, but it must be supplimented with real hardware testing. Another thing I ran into, dosbox would return immediately on a non-existant floppy drive with no error, real hardware with real dos would hang for 20+ seconds looking for the floppy drive and throw an abort message on screen.

keenmaster486 wrote:

Edit: Holy cow, I didn't see this before: https://github.com/open-watcom
I was using the original Open Watcom, version 1.90.

OpenWatcom 2.0 is much nicer than the 1.90

The original 1.90 has a bug that locks up on a real 8088 with no FPU installed. The runtime lib has a bug that executes an fwait in its FPU detection routine. When there is no FPU, the instruction will wait forever.
I made some patched libraries for Watcom 1.90 myself, and also reported the bug to OpenWatcom 2.0. So recent builds of 2.0 should not have the issue.
See here for more info: OpenWatcom 1.9-built binaries lock up on 8088 without FPU

keenmaster486 wrote:

I think perhaps my best bet here is to develop on a 486 or Pentium-class machine with OpenWatcom, and set it to produce 8086-compatible executables. Primary testing can be done on the development system, and more thorough testing can be done on the target system.

My instinct is to not use DOSBox, the reason being it tries to provide a "perfect" environment for DOS programs (i.e. lots of available memory, high stability, the most compatible hardware, etc), which you will not get most of the time on real hardware, especially an XT class machine.

Building the code in DOSBox (or 86box/PCem in my case) is perfectly fine, and way more convenient than using real hardware. That being said, there's no substitute for testing your code on real hardware, which you should do as often as is convenient (which in my case is every few days or after I add a large new feature).