DOS Problem

Many old programs for DOS use software delays implemented as dummy loops. When the program is started, the startup code calibrates the delay constant. The newer computers are way too fast, so the calibration fails and the program crashes because of division by zero or some other error. The DosBox software may help you.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

On 03/23/2009 04:47 PM, snipped-for-privacy@gmail.com sent:

If the OLD system *really* has a *true* DOS OS, then the application program /may/ not work under Win98's DOS emulation.

Pete

It's possible the program could be emulating a floating point processor in code or auto detecting one instead of using a software version. THe version and behavior of your current machine may not be compatible in expected results.. It's been a while but I seem to remember that you could create a short cut to the DOS program which creates a PIF file that allows you to edit special conditions needed for the program. One could be the configuration of the FPU, in the Misc. section... You could be facing a precision issue or rounding issues..

Also, I don't know how you're attempting to start this DOS app up how ever, there is a difference between a DOS box and booting into DOS>

F8 key I think allowed you to boot straight to DOS>

I had the same thought. There was a software emulator called EM87 or something for FP routines with out a coprocessor. But that was windows 3.1 days, around the time of win95 just about every machine had a coprocessor.

Cheers

Problems usually happen with DOS programs that do a direct write to the screen (one of the speed-up tricks); direct read or write to I/O is another area. Believe it or not, a direct write to a printer seems to be OK, but be warned concerning the use of PRN2FILE...and then trying to re-direct...

To me it suggests that your new computer is too fast, and the speed is causing a divide overflow in timing loop initialisation. do you have source?

Did you clear off the Win98, partition the drive with FDISK, and set up and install a clean DOS on the machine? How old is the "old used Win 98 machine?" Is it actually older than the one where you had the software working? (It's not clear from your words if you _ever_ had the software working elsewhere, so it's important to know both whether or not you did run it elsewhere successfully and also what the relative ages of the two machines are, if so.)

One detail I remember that others didn't mention yet is that the older floating point units (when present) needed an FWAIT instruction to delay until results were ready. Newer CPUs don't need them and many of the compilers omit the FWAIT if compiled with certain switches enabled. It could be the case that the DOS software was compiled for newer machines and that if you ever had success with it, it was on a cpu that didn't need FWAIT; and that only now are you trying to run this on a truly "older" machine that actually _does_ need FWAIT instructions. (Assuming a coprocessor exists ib it, of course.)

An option on many compilers allowed a library arrangement that was included in the code as a CALL instruction for the first time execution and that, after the library tested to see if there was a coprocessor present and working, would modify the call itself and stuff in the direct floating point instruction, instead, so that the

I don't remember seeing self-calibrating timing delay code used for floating point code, though. So I don't think that is the problem. The FWAIT instruction was created exactly for the purpose of waiting for completion results, because the earliest cases of coprocessors were actually separate parts that ran in parallel with the CPU and had access to the bus. They would monitor the instruction stream and interact and the main cpu needed some way of testing to see if a result was available before initiating an exchange over the bus to hand off the results to the main cpu. A self-calibrating time delay just wasn't needed for floating point operations and, in any case, I never saw one being used and I looked at a lot of floating point code (through debuggers, since many of the compiler manufacturers at the time were getting their code from a 3rd party who didn't want them disclosing the source to anyone) because I was writing operating system code and needed to ensure that pre-empted floating point code had its complete state preserved. So I was looking around, back then. Can't recall seeing that trick for floating point code, though I certainly saw it in plenty of places for other reasons.

There is another possibility that comes to mind. It's possible that the chipset isn't being configured correctly (some of them have options that relate to floating point error trapping and it requires no more than a small program in your config.sys file or in the autoexec.bat to re-configure the chipset and interrupt handling) and that you need to replace a small bit of interrupt code. I've had to do this a few years back in order to make VC++ 1.52c generated code (Microsoft) operate on an embedded PC. I can't remember the exact error I kept getting, but it might have been the one you mentioned above. So in terms of correcting yuor problem without having access to the source code, it may be possible to construct a boot-up and/or TSR program that runs in the background. That is, if that's the issue.

A useful answer likely will require research.

Jon

Ah, but the only processor that needed FWAIT was the 8087 (as I recall, the 80286/7 pair already did away with it), and if that machine has an 8086 inside it AND can run Windows 98, I would be supremely amazed. :-D

What kind of a program is it? No clue? DOS4/GW? Whatever the error is, it sounds cryptic enough to be compiler-specific, in which case you might hope to find out what it comes from.

Tim

Why not just intall Open DOS or FreeDOS. Even if you have a timing loop as the other posters believe, your program will be using the serial or parallel port I presume since it is a controller. Port response timing is terrible under windows since the OS wants to own the ports.

If you are unable to get a solution by asking for help in newsgroups and this is a machine that is needed by your business, I fix this sort of problem as a consultant, and I don't charge anything if I cannot fix the problem.

I cannot diagnose your problem remotely, but in general a domain error occurs when a math library (possibly turbo C, given the age of the program) is passed an out of range number by the calling function. If the source code is still available, adding a range check would show exactly where the error comes from. If you only have the .com or .exe, fixing it would involve some trial and error with different configuration options, followed by trial and error with different versions of DOS, followed by trial and error with different computer hardware. One way or the other, if I was hired to fix it I would try to end up leaving you with two or three spare PCs wrapped in plastic, preloaded and ready to go.

Agreed. I'd forgotten just how quickly FWAIT was retired. Your point taken.

I assume you are asking the OP, on that.

Jon

Every machine had a coprocessor starting with the '486, before that you needed an 8087, an 80287 or an 80387. If your '98 system is a 386, look for an empty socket where the '387 would go.

Guy Mac>[...]If the source code is still available, adding a range check

The moral of this story, boys and girls, is: Embrace Free Software.

Get the source code for your apps:

What is the CPU in the machine and how much ram is there ? A lot of DOS programs won't run if there is too much ram !

The 486DX had an FPU; the 486SX didn't.

Note that Win95/98/ME include MS-DOS 7, which can be run natively (in real mode, not virtual 8086 mode) by selecting "Restart in MS-DOS mode" from Windows, or pressing F8 (IIRC) at startup.

But it seems that the OP's problem is a hardware issue.

DOS software was often written "to the metal". Once Windows took over, the term "PC compatible" stopped referring to hardware compatibility, instead meaning "Windows drivers provided". E.g. expensive 16550 UARTs were eliminated in favour of including equivalent functionality in all-purpose I/O chips. While this works fine in Windows, inb/outb on 03Fh/02Fh may not work.

Nobody wrote:

Wasn't a 486SX a 486DX whose 80-bit co-processor failed at Test and a 487 a 486DX whose 32-bit processor failed at Test?

Mmm I recollect something like that ! But I put it down to an urban legend.

If the OP is in the UK, I've still got some 386 / 486 kit kicking around. In fact I have a brand new IBM 4Mhz 286 M/B around somewhere !

The Intel i486SX was a Intel 486DX microprocessor with the power and address/data bus connections to the floating-point unit destroyed with a laser. Many of these floating-point units were defective, but if there weren't enough bad chips they would kill the FPU is some good ones rather than face a 486SX shortage.

The Intel i487 was a normal i486DX microprocessor with an extra pin. When installed in what was called a "math coprocessor" socket. this extra pin disabled the i486SX. This gave the users who were used to the i386 and i387 a cheaper non-FPU chip with a familiar- seeming upgrade path.