34 replies to this topic

[DarkLord]

No problem, and thanks.

[Lynxpro]

guus.assmann, on Thu Feb 2, 2012 3:00 AM, said:

@Darklord,

Please don't hang me if I'm wrong on this...
There's a version of GFA Basic (Or is it assembler? I have it at home and I'm at work right now) that does support the 68881 and not the 68882.
Also some benchmarks do see the 68881 and not the 68882. But these do use the 68882 as the results are fast calculation results.
And if memory serves right, the Atari FPU card will only work with the 68881 due to the way it's accessed. Though I'm not 100% about this last one.

BR/
Guus

Mark Williams C uses the 68881. They used to emphasize that in their marketing.

[guus.assmann]

Hello Lynxpro and DarkLord,

Just now I had a look. And it's GFA Basic that uses the 68881.
The point was that some programs don't recognise the 68882 but would use the 68881.
If memory serves right, it had to do with so called Line-F of Line-A access of memory-mapped access.
But as I'm not very familiar with the 68000 software, I'm not aquainted with the details.

BR/
Guus

[DarkLord]

Hmm, okay, thanks for the update.

[lp060]

GFA-Basic had FPU options added when the TT030 came out. That should clearify which FPU GFA expects to find since the command to activate the FPU options is "TT?".

[Lynxpro]

guus.assmann, on Thu Feb 2, 2012 11:12 AM, said:

Hello Lynxpro and DarkLord,

Just now I had a look. And it's GFA Basic that uses the 68881.
The point was that some programs don't recognise the 68882 but would use the 68881.
If memory serves right, it had to do with so called Line-F of Line-A access of memory-mapped access.
But as I'm not very familiar with the 68000 software, I'm not aquainted with the details.

BR/
Guus

That's really lame that some software can support the 68881 but not the 68882. Motorola basically touted the 68882 as completely compatible with the 68881 but with much more power.

I wonder if there are any expansion cards with sockets for both the 68881 and 68882 for these very compatibility issues. I hate to say it, but there's probably a better chance of that in Amigaland than in STville.

Edited by Lynxpro, Thu Feb 2, 2012 11:13 PM.

[Ato]

DarkLord, on Wed Feb 1, 2012 12:53 PM, said:

Just out of curiosity, what programs are known for working with the 68881 but not the 68882?

I hope that you are still interested in a reply. :-)


- Most importantly: the 68881 and 68881 are pin-compatible and have identical programming models. Meaning that in user mode it does not matter which one is used, the software won't be able to tell the difference.

- An internal difference is that the 68882 has an additional conversion unit which takes care of converting data into the internal extended format. This allows for fmove instructions to be executed concurrently with transcendental or arithmetic instructions. There are strict guidelines about how to optimise code so that the execution time benefits from the conversion unit of the 68882. For best performance one should unroll loops, avoid FPU register conflicts and execute slow fmove instructions right after slow arithmetic instructions (or transcendental) in order to hide the execution time of the fmove. Cutting to the chase that means that if the software is done right, the 68882 will be much faster than the 68881 at the same clock speed since it does not spend clock cycles waiting for new data while concurrently calculating stuff.

- The frame state sizes which are stored by fsave differ: null frames are of identical size, idle frames are 28 and 60 bytes, busy frames are 184 and 216 bytes. The 68882 uses the 32 additional bytes to store the state of the aforementioned conversion unit in the frame. This is a reliable way to distinguish between the 68881 and the 68882 in software. Execute the following subroutine in supervisor mode:

; This Subroutine returns true in d0 when an MC68882 is installed,
; false otherwise.
testMc68882:
    move.l d1, -(sp)
    moveq.l #0, d0
    moveq.l #0, d1
    fsave -(sp)
    move.b 1(sp), d1
    cmp.b #$18, d1
    beq.s is68881
    moveq.l #1, d0
.is68881:
    frestore (sp)+
    move.l (sp)+, d1
    rts

Source: MC68881/68882 Floating-Point Coprocessor User's Manual, 2nd ed., 1989, Prentice Hall

Cheers,
T.

Edited by Ato, Thu Apr 19, 2012 9:44 AM.

[DarkLord]

You betcha - thanks for all that info!

[HiroProX]

BTW, if you look at the mainboard for an A1200, the traces and pinout for an FPU is present. Now if this works or is just an artifact from an earlier revision (like the label for it being a 1mb or 2mb board) is unknown as far as I know.

Edited by HiroProX, Wed May 2, 2012 12:07 AM.

[DarkLord]

HiroProX, on Wed May 2, 2012 12:06 AM, said:

BTW, if you look at the mainboard for an A1200, the traces and pinout for an FPU is present. Now if this works or is just an artifact from an earlier revision (like the label for it being a 1mb or 2mb board) is unknown as far as I know.

A couple of google searches led me to web sites that claimed that if you installed a socket, you could use
a 68881, but that it would then interfere with the trapdoor...