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.
http://classictechnology.herokuapp.com
Main desktop: Pentium MMX/200 (Socket 7), SB16, 64MB RAM, S3 Trio64V2/DX, Windows 95 OSR2
Laptops: IBM Thinkpad A20m (PIII 700MHz, 512MB RAM), Toshiba Satellite Pro 460CDT (Pentium MMX/166, 64MB RAM)
User avatar
keenmaster486
Oldbie
 
Posts: 1474
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: 798
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: 3856
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: No registered users and 2 guests