It seems that some coprocessors manage BCD natively:

http://en.wikipedia.org/wiki/Intel_8087

You are right, seems that a 8087  only acts as an extension of the 8086 or 8088 assembler set .

Maybe, but Am9511 is known at least to expand the Enterprise, I don't know about other existing solutions (hey, is there a real Am9511 for EP, or is it only a newspaper arcticle I've also read?). I guess FPUs for intel x86 family are too deeply bound to the x86 CPUs and can't be easily used with other CPUs like Z80 (but I can be wrong). I am also curious if there is some more modern solution for having an FPU other than the Am9511. uM-FPU is not so bad, but it's SPI based stuff.

I've find a small  article about comparison of Amd and uM FPU-s, and it seems, on the same frequency the uM has similar speed as Amd.
http://www.cpushack.com/2010/09/23/arithmetic-processors-then-and-now/
OK, big advance of uM, it has IEEE 754 format (like the Am9512).
On the datasheet of Am9511 there is a speed comparison to software routines. A BASIC has the some floating point number format, like the Am9511, so it can be compare, and in average, the FPU is 50 times faster than software routines.

Találtam egy rövidke cikket, ami összehasonlítja (vagy inkább csak megemlíti) az AMD és a uM koprocit, és ez alapján úgy tűnik, azonos órajelen nagyjából azonos sebességűek.
http://www.cpushack.com/2010/09/23/arithmetic-processors-then-and-now/
OK, tudom, nagy előnye a uM-nak, hogy tudja az IEEE 754 formátumot, míg az Am9511 nem (csak az Am9512).
Az Am9511 adatlapján van egy teszt, ahol összehasonlítják a sebességét szoftveres rutinokkal (nagy szerencsére az egyik BASIC pont ugyanazt a lebegőpontos számformátumot használja, mint az AMD), és átlagban 50x gyorsabb a koproci. (2 perc helyett 2,5 mp alatt megrajzol egy Mandelbrot ábrát! )

A Pascal RTL rutinjait valahogy így kéne lecserélni:
;--------------------------
; X / Y Real
; input:
;   X in stack
;   Y in HLDE
; output:
;   X / Y in HLDE
;--------------------------
l0acd:  call convert2AMD        ; convert Y to AMD format and send it to AMD
        pop  bc                 ; get return address from top of the stack
        pop  de
        pop  hl                 ; HLDE = X
        push bc                 ; push return address
        call convert2AMD        ; convert X to AMD format and send it to AMD
        ld   a,019h             ; code for XCHF (exchange 32 bit operands)
        out  (CMDPORT),a
        ld   a,013h             ; code for FDIV
        out  (CMDPORT),a
        call error_handling
        jp   GetResult
Igen, tudom, hogy a rutinok igy csak a CMDPORT-ra kiküldött bájtban különböznek, az első hat sor minden kétoperandusos rutin elején azonos lenne, de mivel annyi hely van (jóval hosszabbak a szoftveres lebegőpontos rutinok), hogy a gyorsaság miatt maradhat igy (egy CALL / RET -tel kevesebb). XCHF is csak az osztásnál kell.

Some other things than BASIC work too on BCD, for example the internal clock.

Azon gondolkodok, vajon az SADD (16 bites előjeles egész összeadás) utasítás vajon miért került bele a koprociba? Az adatlap szerint 16-18 órajel ciklus alatt fut le, miközben egy sima ADD HL,DE pedig csak 11 ciklus. És akkor még nem számoltam az adatok és a parancs kiküldésének az idejét...

Nem lehet, hogy olyan proci mellé szánták ami nem ismert ilyet?
Az adatokat mindig újra kell küldeni? Nem lehet előző számítás eredményével újabb műveletet végezni?

Nem tudom, milyen más proci lehetett a 70-es évek legvégén, ami nem tud összeadást... (persze lehet, hogy én vagyok tudatlan).
De, lehet, az eredmény a verem tetején lesz. Aztán beküldök még egy operandust, aztán egy szorzást, és csak utána olvasom ki az eredményt. Azt is lehet, hogy előre betöltök a verembe 8 db integer-t, majd kiadok egymás után 7 darab összeadást, és utána olvasom csak ki az végeredményt. Igazából RPN módszerrel működik, ahogy nézem.

http://ep128.hu/Ep_Hardware/Pic/Rajz_Koopproci.gif
Az U5A és U5B invertereknek mi a célja?
Miért nem lehet közvetlenül összekötni a READY (PAUSE) kimenetet a Z80 WAIT bemenetével?