Organization: Computing Technology Services, Michigan Technological Univ.
Date: Wednesday, 22 Jul 1992 18:54:17 EST
From: Jeff McWilliams <JJMCWILL@MTUS5.BITNET>
Newsgroups: comp.sys.atari.8bit
Subject: 6502<-> 68881 Math Cop.


Well I got some Motorola databooks today.  One was for the
68000 family.  Included in there was some specs on the 68881
math coprocessor.  Very interesting.  The 68881 can act in either of
two ways, as a coprocessor, or as a peripheral processor.
The first way would apply to the 68881 being wired up with a 68020,
where the integration of the two is almost seamless, and the pair
can be thought of as one CPU, with floating point operands and
registers.

The second method, called peripheral processor, is so that the
68881 can interface to earlier 68xxx models, like the 68000 or 68008.
In this mode, communication between the 68881 and CPU takes place
by reading and writing to the 68881's registers, called Coprocessor
Interface Registers (CIRS)  These are basically registers that you map
into the CPU's address space, much like you map a PIA (6520) registers
into the 6502's address space.

Another interesting feature of the 68881 is that it can be configured
to work with an 8 bit data bus, with some decrease in performance
as compared to its default 32 bit data bus configuration-- of course.

Additionally, the 68881 can have a separate clock attached to it,
running at either a faster or slower speed than the rest of the
system, due to the asynchronous nature of the chip.

The 68881 can also handle floating point numbers in either IEEE format
or a BCD format, much like the format used in the Atari 8 bit FP
OS routines.

What does this mean for us Atari classic users?  That it is probably
technically quite possible to interface a math coprocessor such as
the 68881 to the 6502, even directly, without too much hassle.
The 68881 could be running at anywhere from 16.6 to 50 mHz and not
interfere with the 6502's required clock speed of 1.79mHz in the
Atari.

All that would need to be done is wire it in, and rewrite the OS
routines to communicate with the 68881 instead of doing all the
math at slooowww 1.79mHz through software approximations.

I don't have all the specifics on the 68881. The exact method of
using the CIR locations on the 68881 to get the job done wasn't
described in this manual, only 68020 floating point opcodes were
mentioned.

If a coprocessor card were designed on the Parallel Bus, as was
mentioned earlier, comprised of a 8mHz 65802 or 65816, then
the 68881 could be implemented in there as well.  In fact, the
65802 and 65881 have a new OPCODE, called COP, for doing this.
COP causes the CPU to look to an interrupt called the coprocessor
interrupt, which is handled much like a IRQ interrupt, or NMI interrupt.
An operand  byte following the COP instruction would indicate
what type of operation were to be executed.  The COP interrupt handler
would look at the operand byte and then call the appropriate
function.  The 68881 has a pin called SENSE' on it.  Basically
it is attached to ground.  By using a pull-up resistor on the
PC board, the sense line would be high if the 68881 were not present,
and low if it were.  The COP interrupt handler could examine this
line, and either call the standard Atari OS floating point routines
and execute them at the CPU's speed of 8mHz, or it could
talk to the 68881 and have it do the high speed, accurate floating
point operation.  Either way, the COP interrupt routine would
return with the result.

This would make for, in my opinion, an elegant and flexible design.
For those not wanting to churn out the bucks for the 68881, they
could have a coprocessor card that does floating point, and whatever
else, out there on the parallel bus, doing instructions at 8mHz instead
of 1.79mHz.  If they choose to, they could later purchase and plug
in the 68881, and realize an additional increase in floating point
speed, making maybe even programs like ChromaCAD really fly.


Of course, there is no reason why the 68881 can't be hooked up to
the parallel bus directly, and then redo the OS ROM with the OS FP.
routines calling the 68881.  The 68881 can still run at whatever speed
desirable, as mentioned above, due to its asynchronous nature.


I will be attempting to get further databooks on the 68881, to further
research this far-out idea.  I don't have the capital to
actually start building one of these babies tomorrow, but at least
I can study the feasibility of such a grand project, and perhaps
see others further develop and implement the idea.


Comments and ideas encouraged.

Jeff McWilliams