Development on a 286, for a 286

Getting old software/games running on older hardware.

Re: Development on a 286, for a 286

Postby keenmaster486 » 2019-3-12 @ 14:43

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.
I flermmed the plootash just like you asked.

http://classictechnology.herokuapp.com
http://keenmaster486.github.io
Vintage desktops: Pentium/MMX 233 (Win95), 286-12 (MS-DOS 5.0)
Vintage laptops: IBM Thinkpad 600E, 560X, 365CD
User avatar
keenmaster486
Oldbie
 
Posts: 1662
Joined: 2016-2-16 @ 02:04
Location: Atroxus

Re: Development on a 286, for a 286

Postby BloodyCactus » 2019-3-12 @ 15:26

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.

Code: Select all
uint32_t q;

// will not give you result you expect because bug in integer promotion
// despite result being able to handle it.
q = 256 * 1024;

// may give expectant result but I've had issues in past
q = (uint32_t)256  * (uint32_t)1024;

// will give expectant result
q = 256;
q *= 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
--/\-[ Stu : Bloody Cactus :: http://kråketær.com :: http://mega-tokyo.com ]-/\--
User avatar
BloodyCactus
Oldbie
 
Posts: 842
Joined: 2016-2-03 @ 13:34
Location: Lexington VA

Re: Development on a 286, for a 286

Postby Scali » 2019-3-12 @ 15:56

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: viewtopic.php?t=42518
Scali
l33t
 
Posts: 4108
Joined: 2014-12-13 @ 14:24

Re: Development on a 286, for a 286

Postby Damaniel » 2019-3-12 @ 19:49

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).
Damaniel
Newbie
 
Posts: 26
Joined: 2014-10-10 @ 22:16

Previous

Return to Software

Who is online

Users browsing this forum: xjas and 1 guest

cron