Difficulties in DOS on real hardware

DOS specific questions.
keenmaster486
Posts: 4
Joined: Feb 20, 2019 21:28

Difficulties in DOS on real hardware

Postby keenmaster486 » Feb 20, 2019 21:47

Hello,

I've been developing a game engine in FB DOS for several months, using FBGFX. I have found that, while the program always works perfectly in DOSBox, it's a pain in the rear end to get it to run on real hardware, and oftentimes it's a total crapshoot whether or not it will run, even on machines with identical processors, RAM, and software, but different motherboards, etc.

Same thing with emulators such as 86Box, PCem, etc. On some configurations I can get it to run on the target machines (386, 486), but most of the time the engine will throw a GPF or some other such error.

One of the most egregious problems for a long time had been that any code produced with FBC, no matter what the compiler flags, would fail to be able to set the screen resolution on a plain Pentium. Not Pentium-MMX, or 486, or even 386, just a plain Pentium. It would throw an invalid opcode whenever a SCREEN or ScreenRes call was made, no matter what the requested screen resolution. The issue could be reproduced by simply creating a blank .bas file that does nothing but a SCREEN 13, or ScreenRes 320,200,8, or SCREEN 7, or whatever, call. This issue was only just fixed in the latest version (1.06), so there's that. I'm glad it was fixed; now my engine runs on plain Pentiums.

But it still has some issues. I think it may have something to do with how FBGFX is initializing things. I have heard something about an IRQ0 timer that may be causing issues.

After extensive testing I have also determined that software configuration DOES NOT MATTER. If it works at all, it will work great with whatever you throw at it - no XMS manager at all, HIMEM, JEMMEX, EMM386, etc, etc. If it doesn't work, it doesn't work, period, and no amount of changing your memory management configuration or even booting straight to command prompt will make it work.

How are you guys developing the FreeBasic DOS version? Are you using real hardware to develop it, or emulators?

Now, I am aware that FB code requires a 386 with an FPU. I have tried WMEMU, however, with no success. So I'm only trying to run the engine on DX processors so far.

Something that may be of interest to you is this: https://www.vogons.org/viewtopic.php?f=9&t=65223
Superfury over at the VOGONS forums is testing his UniPCEmu emulator, and has posted a great deal of debug information of what seems to happen when he attempts to run my engine. This may give some insight into what is happening behind the scenes when it fails to run on an actual machine.

Most of the GPFs will occur even before the engine has attempted to load any large things into memory, and even before any graphics pages have been created. If it manages to make it to the graphics page creation stage of the initialization process, then 99% of the time it will work smoothly from there on out with no issues. On many machines the program crashes as it attempts to start the initialization process with some basic file I/O operations, after having already successfully allocated memory for various arrays and pointers.

I have tried both CWSDPMI and HDPMI32 (latest versions) with no change in behavior between them.

Here you can find the thread on VOGONS where I have posted various iterations of the engine at various stages of development, and people have posted results of testing it on various machines: https://www.vogons.org/viewtopic.php?f=5&t=58905

I wonder whether this is a known issue, or if people just don't develop for DOS any more and the DOS version is just no longer tested at all. Is this something that could be looked into?
rugxulo
Posts: 216
Joined: Jun 30, 2006 5:31
Location: Usono (aka, USA)
Contact:

Re: Difficulties in DOS on real hardware

Postby rugxulo » Feb 27, 2019 1:37

keenmaster486 wrote:Now, I am aware that FB code requires a 386 with an FPU. I have tried WMEMU, however, with no success. So I'm only trying to run the engine on DX processors so far.


The only little bit I know about that was shown in the old thread titled "MD5 Calculator" (circa 2009). Apparently, even if you explicitly avoid using floating point types in your code, the runtime will still always assume FPU is present. I got lucky, at that time, to nop out the two offending instructions, and it still worked, but that was a fluke. Nowadays I don't even have my 486 hooked up (and it's probably rotted by now). Also haven't seen DOS386 in a few years, so I'm a bit worried for him.

keenmaster486 wrote:I wonder whether this is a known issue, or if people just don't develop for DOS any more and the DOS version is just no longer tested at all. Is this something that could be looked into?


Get on the FreeDOS mailing lists. Granted, it's barely a dozen or so active developers, but there are still some (very few) people in the world interested. Or try asking on news://comp.os.msdos.programmer or BTTR's forum or similar. Yes, DOS aficionados are very meager, but you have to know where to look.
coderJeff
Site Admin
Posts: 2841
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Difficulties in DOS on real hardware

Postby coderJeff » Mar 09, 2019 18:10

keenmaster486 wrote:How are you guys developing the FreeBasic DOS version? Are you using real hardware to develop it, or emulators?

I'm mostly developing on Win 7 64-bit. Sometimes I will test some code in DosBox, win98 VM, WinXP VM, but honestly that's rare. I haven't tested fbc-dos on real hardware in more than 10 years. I've only briefly played around with FreeDOS. DOS was my preferred choice maybe 15 years ago. Sorry.

> Now, I am aware that FB code requires a 386 with an FPU. I have tried WMEMU, however, with no success. So I'm only trying to run the engine on DX processors so far.

In theory, fbc should be able to generate 386/486/586 code, even if fbc itself will only run on 586. I am targeting i586 as the target platform, but that's not to say I didn't screw something up. Or possibly, the DJGPP binaries used with fbc are not correct for 386 targets. I don't remember if we ever supported math emulation only.

> I wonder whether this is a known issue, or if people just don't develop for DOS any more and the DOS version is just no longer tested at all. Is this something that could be looked into?

The DOS package for 1.06.0 was built and tested in a CMD prompt on WinXP running in a virtual machine (emulator). That is what is available to me. At one time in the past, fbc was being developed on DOS machines, but now, it's really only a target.
marcov
Posts: 2747
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Difficulties in DOS on real hardware

Postby marcov » Mar 09, 2019 20:26

coderJeff wrote:
keenmaster486 wrote:How are you guys developing the FreeBasic DOS version? Are you using real hardware to develop it, or emulators?

I'm mostly developing on Win 7 64-bit. Sometimes I will test some code in DosBox, win98 VM, WinXP VM, but honestly that's rare. I haven't tested fbc-dos on real hardware in more than 10 years. I've only briefly played around with FreeDOS. DOS was my preferred choice maybe 15 years ago. Sorry.


As a release manager for a not to be mentioned product, I hear you :-)

p.s. make it twenty years, just to be sure.
MrSwiss
Posts: 3025
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Difficulties in DOS on real hardware

Postby MrSwiss » Mar 09, 2019 20:42

marcov wrote:p.s. make it twenty years, just to be sure.
Not shure thats long enough, beginning 1998 was rollout of:

Windows_NT Server/Client version 4.0, commercially in the company I've worked
for at the time, replacing existing Novell-Servers, as well as Win 95/98 Clients.
(Which means to state: DOS days where earlier than that finished ...)
marcov
Posts: 2747
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Difficulties in DOS on real hardware

Postby marcov » Mar 09, 2019 20:44

MrSwiss wrote:
marcov wrote:p.s. make it twenty years, just to be sure.
Not shure thats long enough, beginning 1998 was rollout of:

Windows_NT Server/Client version 4.0, commercially in the company I've worked for,
at the time, replacing existing Novell-Servers, as well as Win 95/98 Clients.
(Which means to state: DOS days where earlier than that finished ...)


NT4 didn't support LFN, in that respect it was a step back from win98, it was not deployed as wide as win9x was. Mostly NT4 was server only and a few IT related workstation

In early 2000 I joined a team that prepared a wide rollout of windows 2000 (then, not released) to all desktops (+/- 20000 seats) of the organization. Most of our organization already ran win2000 prior to XP.

As a result, as a trainee, I quickly ported my own software from win9x to NT based systems in that period. Simply because dos based compiling took twice as long as win32 based compiling (+results)

P.s. running win2000 beta on 96MB Pentium-I is NOT fun.
MrSwiss
Posts: 3025
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Difficulties in DOS on real hardware

Postby MrSwiss » Mar 09, 2019 20:51

marcov wrote:P.s. running win2000 beta on 96MB Pentium-I is NOT fun.

Nobody had such *lame* PC's ... min.RAM was: 192 MB (max. on Laptops), average RAM 256 MB.
Pentium II CPU's.

P.S. Nothing to do with Y2K, 2000 (which is NT 5.0)
marcov
Posts: 2747
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Difficulties in DOS on real hardware

Postby marcov » Mar 09, 2019 20:59

MrSwiss wrote:
marcov wrote:P.s. running win2000 beta on 96MB Pentium-I is NOT fun.

Nobody had such *lame* PC's


Trust me.

... min.RAM was: 192 MB (max. on Laptops), average RAM 256 MB.


Strange for a person advocating NT4. Afaik requirement for NT4 was 16MB, though 32MB was "recommended".

Maybe you are mixing periods.

P.S. Nothing to do with Y2K, 2000 (which is NT 5.0)


Since windows 2000 (aka NT5) emerged AFTER the year 2000, that is pretty obvious. Though at the time we had our hands full with REAL problems, like Win98 only loading 64k worth of shares info. IOW too many shares (read home dirs), and Windows 9x wouldn't show them.

Fun fact, on that 96MB P-I, I read my outlook corporate mail using cygwin MUTT , because outlook express was too memory hungry
MrSwiss
Posts: 3025
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Difficulties in DOS on real hardware

Postby MrSwiss » Mar 09, 2019 21:11

marcov wrote:Trust me. -- Maybe you are mixing periods.
I was only stating the HW we've had in the company, of course "loaded up" during rollout.
(What could not be upgraded, was simply replaced.)

marcov wrote:... we had REAL problems ...
We've just solved those (with the rollout). ;-)

marcov wrote:Strange for a person advocating NT4.
I'm not ever *advocating* anything, just stating facts.
marcov
Posts: 2747
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Difficulties in DOS on real hardware

Postby marcov » Mar 09, 2019 22:54

MrSwiss wrote:
marcov wrote:Trust me. -- Maybe you are mixing periods.
I was only stating the HW we've had in the company, of course "loaded up" during rollout.
(What could not be upgraded, was simply replaced.)


Date?

I'm not ever *advocating* anything, just stating facts.


I'm just wondering about the link between the facts. So when was this NT4 rollout with average 256 MB?
MrSwiss
Posts: 3025
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Difficulties in DOS on real hardware

Postby MrSwiss » Mar 10, 2019 0:06

marcov wrote:Date?

Are you sleeping? Clearly stated in my first reply: beginning 1998 (actually February).
marcov
Posts: 2747
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Difficulties in DOS on real hardware

Postby marcov » Mar 10, 2019 0:20

MrSwiss wrote:
marcov wrote:Date?

Are you sleeping? Clearly stated in my first reply: beginning 1998 (actually February).


No, just double checking. Seemed to be an awful lot for the time. https://www.reddit.com/r/hardware/comme ... _timeline/
MrSwiss
Posts: 3025
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Difficulties in DOS on real hardware

Postby MrSwiss » Mar 10, 2019 0:34

Company IT differs from Home PC's in that way, that before a new OS is deployed,
many, many tests are performed (e.g. HW as well as SW compatibility tests) and,
only if the Standards have been redefined/rewritten and approved by management,
HW as well as SW procured then ... deployment is planned, then executed.

(all along the above way, IT has to keep everybody affected, informed of progress,
if a "Project" is supposed to succeed [aka: soft targets])
coderJeff
Site Admin
Posts: 2841
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Difficulties in DOS on real hardware

Postby coderJeff » Mar 10, 2019 20:45

I don't remember what my PC specs were back then, but it always seemed laptop memory was so expensive that I suffered with never having enough of it. In the 90's I was writing custom software to talk all kinds of interesting peripherals in manufacturing, where device drivers didn't exist for windows yet. And I do remember in 1999 being contracted to modify DOS based programs for the Y2K bug, since they were still using 8 digit year format, and converting their databases. But that couldn't have lasted long because I think I rewrote all their DOS apps for Windows probably by about 2005. When I got interested in FB around that same time was probably also the tail end of my interest in DOS applications, though I was still playing around programming soundblaster and adlib cards and video just for fun (I didn't make any money doing fun stuff).

Continuing on an earlier thought...all my old hardware is broken, or rotted, or gone by now. So I just don't find any need to write something specific to DOS. Is any manufacturer specifically still making a 386(DX) micro where DOS is the preferred "OS"? I have trouble imagining that such a thing is happening.
keenmaster486
Posts: 4
Joined: Feb 20, 2019 21:28

Re: Difficulties in DOS on real hardware

Postby keenmaster486 » Mar 12, 2019 20:45

If you want a good emulator to test on, use 86Box or PCem, and emulate a 386DX with MS-DOS 6.22 or the like. Easy to copy files back and forth using ISO images and mounting them as CDs.

I have a feeling that if I was developing directly on such a machine instead of using DOSBox for primary testing, I might be able to get it to work, as DOSBox tries to provide an optimal environment for DOS programs to run in (i.e. lots of available memory, most compatible video card, etc.). You won't usually get this environment on a real machine. So maybe some things that I am doing are working in DOSBox because the emulation isn't perfect. But on the other hand, a lot of the problems will occur even before my program has done anything useful, which to me indicates that it is an issue with FBGFX.

There are a lot of old Pentium-class systems still out there on the market for cheap. Less 486 and 386 but they can be found. I got myself a 286 the other day - obviously useless for FB stuff but it will be fun to play around developing in OpenWatcom.

Just for your reference, the Windows XP NTVDM is not great for testing DOS stuff. It was always horrible for compatibility back in the day; I remember pulling my hair out trying to get things to work right in it. If you do have a Windows 98 VDM, that is much better. I do notice that a lot of the time running my game engine in Windows 95/98 will work better than in pure DOS... same problem as running it in DOSBox; Win9x will provide as good an environment as it can for DOS programs.

(re: the NT4/2000 debate; remember the Pentium MMX and Pentium II came out in 1997. 64 MB of RAM was a lot for that year, and for many motherboards that was the maximum cacheable amount. By the year 2000, right before the Pentium 4 came out, a dual Pentium III 1.4 GHz with 512 MB or even 1 GB of RAM, maybe a high-end Nvidia card and Windows 2000 was about as high-end as it got for consumer-grade stuff. I think probably most people would have a Pentium II or III with 128 or 256 MB)

Return to “DOS”

Who is online

Users browsing this forum: No registered users and 1 guest