Motorola 68881 & 68882 math co-processors...

[+DarkLord]

No problem, and thanks.

[Lynxpro]

@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]

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 February 3, 2012 by Lynxpro

[Ato]

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 April 19, 2012 by Ato

[+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 May 2, 2012 by HiroProX

[+DarkLord]

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...

[Michal Tersl]

The name of the extension card is Atari SFP004. Installation manual: http://www.atarimani...o-processor.pdf and some pictures: http://www.maedicke....ware/sfp004.htm

 

And I have to apalogise because I was wrong. It was not a ROM-port card but one for the Mega-ST internal 68000 expansion bus. Sorry again for the wrong information.

 

 

 

 

Whoopsy Daisy! Quite some improvement. Would be really nice if you could add support for the FPU-on-a-card for later comparison if we find somebody who has got one. :-)

 

Cheers,

T.

 

Hi, I have myself the Atari SFP004, but I am unable to find any SW that would be able to use it. I am particularly looking at Fortran compiler that I used to have back in 80' when I used it for numerical calculations. It all went by when I sold my Atari stuff... Now back I was able to get the SFP004 but not single SW package. I know that there should exist GFA Basic that can utilize the 68881, but I prefer Omikron Basic (this is much faster then GFA even without the 68881) but I not sure if there was ever a version supporting the 68881 co-processor.

 

Can anyone please help locating at least some of the SW?

 

Many thanks.

[dml]

The 68881 and 68882 only differ by performance/timings. There are no compatibility issues between them, or 'extras' in the 68882, or stuff that works with one but not the other.

 

There is however a different way of 'wiring' an FPU to a 68000 which makes it incompatible with code made for 68020+ with FPU. This has to do with the way instructions are encoded for comms between the older 68k CPU and the FPU. This doesn't affect Falcons or TTs at all since they are 030 based. The 881 or 882 will work equally well but 882 will be quicker.

 

And double precision values are not mandatory when using the FPU. The chip can handle single (32bit) or double (64bit) precision values in memory, and internal operations are always slightly greater than both (80bits) without incurring extra cost. i.e. arithmetic is always 80-bits internally but the extra bits do not have to be moved to/from memory (which is where extra cost would show). Whether singles or doubles are used is up to the software using it. The chip handles both types nicely just like the FPU in modern PCs (the 881 was very advanced for its time).

 

The 881/2 also has hardware versions of more advanced functions which the later 68040/68060 chips don't have (those need emulation). So the 881/2 chip is technically more 'capable' than the later CPUs with builtin FPUs. However the subset of functions implemented by the 040/060 chips are much much faster than the old FPUs.

 

Not much 'old' software uses the FPU, but any more recent stuff ported from other systems will benefit from having one. It's hard to find projects these days that don't use floats for something as it's now almost assumed as a standard hardware capability...

 

As for comparisons... software floating point libraries are *awful*. I have studied them in detail. The simplest arithmetic must involve calls out to libraries and redundant packing/unpacking of data types for every single add, subtract, multiply etc. This overhead costs nearly as much as the arithmetic does. A hardware FPU has none of that - single instructions, no calls to libraries, no copying stuff around in memory. Can be orders of magnitude faster. If you have a program that wants to use floats, it's worth having one.

 

Speeds - the 882 can typically be clocked 2x and sometimes 3x it's rated value. Many chip MFRs had a habit of making good chips and then stamping different numbers on them to suit different markets. You could have 3 chips all with the same tolerances but marked 16mhz, 33mhz, 40mhz and nobody could tell the difference. Only way to find out is to overclock and see. If one doesn't clock well, try another. They don't cost very much now.

[lp060]

Hi, I have myself the Atari SFP004, but I am unable to find any SW that would be able to use it. I am particularly looking at Fortran compiler that I used to have back in 80' when I used it for numerical calculations. It all went by when I sold my Atari stuff... Now back I was able to get the SFP004 but not single SW package. I know that there should exist GFA Basic that can utilize the 68881, but I prefer Omikron Basic (this is much faster then GFA even without the 68881) but I not sure if there was ever a version supporting the 68881 co-processor.

 

GFA v3.6 or omikron v4

[+DarkLord]

This doesn't affect Falcons or TTs at all since they are 030 based.

 

So can we safely assume that it wouldn't affect accelerated machines with '030 CPU's

as well?

 

(and thanks for the detailed explanation - very nice!)

[dml]

So can we safely assume that it wouldn't affect accelerated machines with '030 CPU's

as well?

 

If the machine has a 020 or 030 CPU, it will either be coupled to an FPU 'properly' - most likely on the same board (and therefore be compatible with any other programs that expect 0x0+88x), or it won't have any FPU coupling at all. I don't think there is an in-between scenario.

 

I really doubt an 020/030 can couple to an 88x chip using the '68000 hack' method (e.g. an 030 board trying to talk to an 881 somewhere else in the system, intended for a 68000) and even if that is possible, I don't expect such a machine would benefit much from that arrangement (the 68000 kind of coupling is necessarily slow).

 

So if you have an 030 and 88x on the same board (be that a mainboard or accelerator board), you don't need to worry about unusual/incompatible coupling. It will just work. If you have an 030 on an accelerator board and an 88x on the mainboard - that's a bit suspect but assuming the 'original' mainboard CPU was also 020+ class, it will likely still 'just work'. If the original CPU was a 68000, the coupling to the 88x probably won't work.

 

I'm probably making that look more complicated than it is

[+DarkLord]

Not too much, I think even I got it. Thanks again for your detailed explanations Doug. I always

look forward to your posts.

[jens]

Afaik a Falcon expansion board based speeder will use the motherboard FPU without problems.

And btw.:

There are megabus graphics cards which have an FPU slot to upgrade the 68000 in the Mega ST.

I had two of them, but I gave them away, not remembering the names anymore. I do believe both to have been Matrix cards. (Darklord, listen to this! Upgrade your STacy with a Matrix megabus graphics card!)

[dml]

There are megabus graphics cards which have an FPU slot to upgrade the 68000 in the Mega ST.

I had two of them, but I gave them away, not remembering the names anymore. I do believe both to have been Matrix cards. (Darklord, listen to this! Upgrade your STacy with a Matrix megabus graphics card!)

 

I wouldn't mind finding a card for my old Mega 4! I think they are nearly impossible to find these days though? :-z

[jens]

I think so.

A C32 I had used a VME adapter and sat in a case as big as a Mega/STe or TT casing so you could put the computer on it.

Another card had a similar adapter and resided in a bigtower together with a TT.

So maybe it would be interesting to search for a TT if you want to upgrade your Mega ST.

[+DarkLord]

(Darklord, listen to this! Upgrade your STacy with a Matrix megabus graphics card!)

 

Hmm, I'm a little bit confused here. It might just be I'm not understanding the terminology?

 

I can't find a "megabus" in my STacy. There is a place that looks like its there for a VME

header, but that's all I can find.

 

What am I missing?

 

Thanks!

 

Here is that odd port on the STacy:

 

 

and here is the VME standard:

 

[jens]

I don't have any Mega STs atm, so I can't look that up, but the Mega STs do have the Megabus, not the VME, and in short the STacy is a Mega ST with a different layout and casing, so I assume this should be a Megabus, not a VME.

 

Ok, I do have to correct myself.

Just found someone who was able to tell me it's a STacy expansion slot which is neither the megabus nor the VME, but as it's the full 68000 which is accessible there it would be possible to make adapters for either of them.

Edited January 11, 2013 by jens

[+DarkLord]

No problem, I correct myself, and get corrected (hard!) by others all the time.

 

That makes more sense I think - that picture I posted is the only thing close to

an expansion port I can find on my STacy.

 

Thanks.

[Bumzyman]

I was thinking about getting some 68882's for my Falcons that don't have CT60's and found a few on eBay that seem to be newly made but not by Motorola.

 

Here's two 40Mhz examples:

http://rover.ebay.com/rover/1/711-53200-19255-0/1?ff3=4&pub=5574883395&toolid=10001&campid=5336500554&customid=&mpre=http%3A%2F%2Fwww.ebay.com%2Fitm%2F251245225321

http://rover.ebay.com/rover/1/711-53200-19255-0/1?ff3=4&pub=5574883395&toolid=10001&campid=5336500554&customid=&mpre=http%3A%2F%2Fwww.ebay.com%2Fitm%2F251298563729

 

Are these chips legit?

Can anyone confirm that they would or should work?

[Bumzyman]

Well after searching around for the chip mfg logos I figured out that the previous post I made was linking to chips made by Freescale and ON Semiconductor. I assume they are the same as the Motorola mfg parts.

[Ato]

Well after searching around for the chip mfg logos I figured out that the previous post I made was linking to chips made by Freescale and ON Semiconductor. I assume they are the same as the Motorola mfg parts.

 

ON Semiconductor was part of Motorola and Freescale is what has become of Motorola. So it should be OK.

 

Cheers,

T.