• Please review our updated Terms and Rules here

Testing the math co-processor...

Chris_in_Japan

Experienced Member
Joined
Nov 4, 2012
Messages
68
Location
Liechtenstein, Europe
Hi everybody!

I bought and installed a math co-processor in my 5160 and have no diagnose software.

How can i test if the co-processor is working (well)? Some command in dos (3.30) to check it? Some simple for/next routine in basic with some execution time with and without co-processor to judge if working?

Many thanks!
 
Don't forget to move switch 2 from ON to OFF.

I like to use Checkit v3.0 since I don't know any DOS commands for that.

If you have a spreadsheet that might check for a co-processor.
 
Don't forget to move switch 2 from ON to OFF.

I like to use Checkit v3.0 since I don't know any DOS commands for that.

If you have a spreadsheet that might check for a co-processor.

Certainly - the dip switch is already in position...

I guess CheckIt is a diagnose software. Unfortunatelly i do not have one, neither a spreadsheet, therefore i was hoping for some simple routine in basic with mathematical operators where somebody did time measurements with and without the co-processor...
 
When did MS create msd.exe? That showed you if you had a coprocessor installed. Other than that I'm not immediately sure how to detect the presence.. google might show you some basic (assembly) code to poll for one though. Surely there must be some bios interrupt that would return some processor value.
 
When did MS create msd.exe? That showed you if you had a coprocessor installed. Other than that I'm not immediately sure how to detect the presence.. google might show you some basic (assembly) code to poll for one though. Surely there must be some bios interrupt that would return some processor value.

Nope... Unfortunatelly not in my early 3.30...
 
Here is the code I use in my BIOS to detect the coprocessor presence:
fninit ; initialize coprocessor
mov cx,3
.wait:
loop .wait
mov word [test_word],0000h ; clear space for control word
fnstcw word [test_word] ; store control word
cmp word [test_word],03FFh ; 8087 sets control word to 03FFh
jne .no_fpu

If coprocessor is present it will store 3FFh at the test_word address, if not, it will remain unchanged (0h). You cat try running similar code from DEBUG. This code will work regardless of jumper setting and I never understood why IBM actually implemented that jumper (the only explanation
I have is that 8087 was released after IBM PC was designed, and IBM guys didn't really had a way to test it :))

Update:
This site has a few simple examples of coprocessor programming: http://www.ee.unb.ca/tervo/ee6373/dos8087.htm
For example you can get the PI value (runs in DEBUG): http://www.ee.unb.ca/tervo/ee6373/8087ex2.htm

If you want a more thorough test you should use a diagnostics software.

I am afraid that MSD won't really test the coprocessor. I think it merely prints the value from BIOS's data area equipment list word.
As far as I know BIOS also doesn't check coprocessor, the INT 11h (equipment check) just returns the equipment list as defined by jumpers.
 
Last edited:
Here is the code I use in my BIOS to detect the coprocessor presence:
fninit ; initialize coprocessor
mov cx,3
.wait:
loop .wait
mov word [test_word],0000h ; clear space for control word
fnstcw word [test_word] ; store control word
cmp word [test_word],03FFh ; 8087 sets control word to 03FFh
jne .no_fpu

.

Hey sergey - many thanks!

I am not acquainted with debug...

It is each instruction line ending in the semicolon?

I mean when you write
"mov word [test_word],0000h ; clear space for control word",

I should type:
mov word [test_word],0000h [ENTER]

Right?

Sorry for the stupid question!
 
If coprocessor is present it will store 3FFh at the test_word address, if not, it will remain unchanged (0h).

Ah! And the second stupid question: at the end of typing your routine into DEBUG, how do I check the value stored in test_word address? Which instruction is to be typed in for it? Or the routine itselfs shows the value (3FFh or 0h) anyway at the end?
 
Ah! And the second stupid question: at the end of typing your routine into DEBUG, how do I check the value stored in test_word address? Which instruction is to be typed in for it? Or the routine itselfs shows the value (3FFh or 0h) anyway at the end?

Actually the example above is using NASM syntax and it needs some changes to work in DEBUG. Please refer to the second link in my previous post (PI calculation), it basically shows how to calculate the PI value using DEBUG. If it works on your computer - your 8087 is OK.

Technical note: DEBUG is pretty dumb :) It doesn't support labels or other more advanced features of a normal assembler. Basically it just translates mnemonics to the machine code. The first link has a list of most useful DEBUG commands. Google for more :)
 
fninit ; initialize coprocessor
mov cx,3
.wait:
loop .wait
mov word [test_word],0000h ; clear space for control word
fnstcw word [test_word] ; store control word
cmp word [test_word],03FFh ; 8087 sets control word to 03FFh
jne .no_fpu

Sergey, you can save a couple of bytes by changing this:

Code:
        mov     word [test_word],0000h  ; clear space for control word

into this:

Code:
        mov     [test_word],cx  ; clear space for control word

@Chris_in_Japan: Instead of fiddling with debug, I'd just use a diagnostic tool such as CheckIt or programs specificly made for testing FPU:s. In this thread there's a download link to software for IIT coprocessors which might work for you even if your FPU isn't made by IIT (the IIT specific functions won't work of course). Intel has a similar tool but I can't remember it's name. I suggest that you search the forum or just google on the subject.

Also, this document might be of interest as well.
 
Per, this looks like it will only detect an i387 chip. Have you used it to detect any others?

I have used it to test both an 8087 and a 287, so it will certainly detect others. The promotinal parts does highlight the 387 a lot, but when it comes to the actual testing then it does all of them.

The text-only version of the test program (MCPDiag.exe) can be run standalone, and goes right to the testing. RunMCP.exe on the other hand is a fully featured graphical slideshow with promotinal material in addition to the test program.
 
Last edited:
Sergey, you can save a couple of bytes by changing this:

Code:
        mov     word [test_word],0000h  ; clear space for control word

into this:

Code:
        mov     [test_word],cx  ; clear space for control word

Yes it will save 2 bytes, but it makes code less readable, and there is a concern that in case some another code is added after the loop it will break that MOV.
 
Yes it will save 2 bytes, but it makes code less readable, and there is a concern that in case some another code is added after the loop it will break that MOV.

Readability? That's what comments are for. :) Oh well, just trying to help...
 
Being too stupid for this debug stuff and reading that fractal calculations is something were the co-processors are appreciated, i ran the basic routine below and took to the 5160 five hours to finish the mandelbrot.

This was performed in screen 1 (320 x 200) and please remark the relatively low number of iterations (20 loops) per pixel...

What do you think? Was the co-processor working or rather not? I understood that the time difference with and without is dramatic for fractals but I am unable to judge the time above.


1030 CLS
1031 SCREEN 1
1032 COLOR 0,0
2020 REM L is the maximum iterations to try
2030 L = 20
2040 FOR I = 0 TO 319
2050 FOR J = 0 TO 199
2060 REM Pixel coordinates (I,J) to math (U,V)
2060 U = I / 160 - 1.5
2070 V = J / 100 - 1
2080 X = U
2090 Y = V
2100 N = 0
2110 REM Inner iteration loop
2120 R = X * X
2130 Q = Y * Y
2140 IF R + Q > 4 OR N >= L THEN GOTO 2190
2150 Y = 2 * X * Y + V
2160 X = R - Q + U
2170 N = N + 1
2180 GOTO 2120
2190 REM Compute the color to plot
2200 IF N < 10 THEN C = 0 ELSE C = FIX(4 * (N-10) / (L-10))
2210 PSET (I, J), C
2220 NEXT J
2230 NEXT I
2240 END
 
Back
Top