68881 FPU and other FPU

[RalfK]

Chromatix wrote:

I think a 1-chip interface solution - of which only half the chip is even used - is definitely simpler than the Z80 board linked earlier.

This solution interfaced to the AppleBus uses some chips more:
http://mirrors.apple2.org.za/Apple%20II ... %20Engine/

[Chromatix]

It appears that an Apple II slot only provides 16 bytes of address space, so there is some remapping to squeeze the most useful parts of the 32-byte register space into that. Don't ask me why they use a big chip like that to do the job.

[RalfK]

Chromatix wrote:

It appears that an Apple II slot only provides 16 bytes of address space, [...]

There is another address space of 256bytes which is normally used for code. But you can use it also for I/O.

Additional document, Motorola's AN947 (MC68881 Floating-Point Coprocessor as a Peripheral in an 68000 System):
http://bitsavers.trailing-edge.com/comp ... 7_37p].pdf

[BigDumbDinosaur]

RalfK wrote:

Chromatix wrote:

It appears that an Apple II slot only provides 16 bytes of address space, [...]

There is another address space of 256bytes which is normally used for code. But you can use it also for I/O.

Additional document, Motorola's AN947 (MC68881 Floating-Point Coprocessor as a Peripheral in an 68000 System):
http://bitsavers.trailing-edge.com/comp ... 7_37p].pdf

That appears to be a dead link.

[Chromatix]

The forum is confused by the presence of square brackets in the URL. Try this: linkie

[Chromatix]

So, while interfacing the 68882 to the 65xx bus is pretty simple at the hardware level, the software side is… not.

It's definitely a system designed to interface with a non-trivial state machine built into the 68020/030 CPU, and which has to be emulated when using the FPU as a memory-mapped peripheral. It's doable, but expect to write a bunch of support routines which take a noticeable time to transfer operands around. On the upside, you get to choose how to locate the operands to supply and retrieve; you're not expected to implement every addressing mode that the 68K does, or even do things according to a similar software model to the 68K. You can even store the operands little-endian, as long as your interface routines fix that during the transfer.

On top of that, the 68882 implements what can only be described as a sophisticated floating-point exception model, which requires equally "sophisticated" handling when such an exception occurs. My advice here would be to strictly avoid setting any of the exception trap flags, and instead rely on the IEEE-754 "default value" and rounding behaviours. This will allow simplifying the exception handler to one which simply gets the FPU back into a usable state; with the trap flags disabled, the only triggerable exceptions are transfer protocol violations and invalid command words. You might never need to execute FSAVE, which by itself is a massive simplification to the protocol.

To accomplish that, writing $0001 to the "control" register resets the transfer protocol to the idle state, and executing FRESTORE to load the null state word of $00000000 performs a full reset and initialisation (including loading all registers with NaN).

[RalfK]

Chromatix wrote:

So, while interfacing the 68882 to the 65xx bus is pretty simple at the hardware level, the software side is… not.

At mirrors.apple2.org.za (my first link) there is a disk image called Floating Point Engine Tools. The manual describes the interface to the hardware and the library. I would disassemble the software from this disk if I'm interested in adding this FPU to my 6502

[Chromatix]

As a further simplification, you could adopt the load-store programming model for the FPU, and perform all actual operations register-to-register. The 68882 has enough internal registers to make that practical. This avoids the need to combine operation commands with supplying operand values.

Likewise, if you implement context switching in your SBC, the manual for the 68882 suggests using FSAVE and FRESTORE for that purpose. It's probably better just to save the value and status registers, though this does require waiting for the FPU to complete its current operation. But that is also why "lazy context switching" was invented; have a flag checked in your support routines to indicate whether to perform a context switch before the next FPU operation, and another flag indicating whether that occurred.

[Jmstein7]

Chromatix wrote:

Indeed, I just read the MC68882 datasheet, and the hardware connections to a 65xx bus look reasonably simple. I don't see any reason why you couldn't attach it to either a 6502 or a 65816.

Screenshot 2020-06-01 01.10.00.png

As shown above, the data bus can be configured to operate in 8-bit chunks, originally for compatibility with the 68008. Just tie /SIZE low, gang all four bytes of the 68882's databus together, and connect all five address lines. The /CS line should be produced conventionally for a 32-byte address range, R/W should be brought directly from the CPU, /DS is just /WE, and /AS is just Phi1.

The only real wrinkle is /DSACK0, which in the 68K bus protocol is used to implement wait states; it is also a line that should be pulled up (gently). Since the 68882 has complex internal processing and operates on an independent clock from the CPU bus (in general, though you can use the same clock for both if requirements permit), the number of wait-states is not predictable in advance. So you'll need to pull RDY low (or stretch the 65xx clock, if you prefer) when accessing the 68882, until /DSACK0 also goes low. I think you can do that by cascading two NAND gates:

Code: Select all

  RDY = !(/DSACK0 & !(/CS & /CS))

So, if either the 68882 is deselected or it has signalled completion, RDY goes high.

I think a 1-chip interface solution - of which only half the chip is even used - is definitely simpler than the Z80 board linked earlier.

One final wrinkle: the 68882 only guarantees TTL signal levels. This is probably fine for a basic system, just something to be aware of.

Chromatix,

Have you tested this setup? I just got some 68882s that I wanted to interface to a 65C816 board I'm working on, but I'm going to go through the rigor of soldering it all together. So, in, the back of my mind, I'd like some form of reassurance before I go through all that effort, if someone has done this before, or someone reliable just reasonably believes that this schematic is sound.

Jonathan

[barrym95838]

Chromatix got off to an aggressive and productive start on this forum, but has been invisible here for about a year. Similarly, chitselb (Charlie H.) has stopped posting. He appears to have suffered a personal tragedy with a bus fire, but I'm unable to confirm any of that, because neither have replied to my private messages.

[handyandy]

There’s also a redesign of the FPE and Number Cruncher coprocessor cards for the Apple IIe and IIGS here:
https://www.geekdot.com/numbercruncher-reloaded/

Cheers,
Andy

[Jmstein7]

barrym95838 wrote:

Chromatix got off to an aggressive and productive start on this forum, but has been invisible here for about a year. Similarly, chitselb (Charlie H.) has stopped posting. He appears to have suffered a personal tragedy with a bus fire, but I'm unable to confirm any of that, because neither have replied to my private messages.

Holy moly - I'm sorry to hear it!

[Jmstein7]

handyandy wrote:

There’s also a redesign of the FPE and Number Cruncher coprocessor cards for the Apple IIe and IIGS here:
https://www.geekdot.com/numbercruncher-reloaded/

Cheers,
Andy

Thanks, Andy.

I know Axel Muhr, we've had a bunch of correspondence - great stuff, particularly with respect to transputers. He taught me all I know about them

J

[Sean]

Jmstein7 wrote:

handyandy wrote:

There’s also a redesign of the FPE and Number Cruncher coprocessor cards for the Apple IIe and IIGS here:
https://www.geekdot.com/numbercruncher-reloaded/

Cheers,
Andy

Thanks, Andy.

I know Axel Muhr, we've had a bunch of correspondence - great stuff, particularly with respect to transputers. He taught me all I know about them

J

Last night I discovered bitsavers.org has archived copies of the "MC68881/MC68882 Floating-Point Coprocessor User's Manual" and "AN947 - MC68881 Floating-Point Coprocessor as a Peripheral in an M68000 System" which go into much greater depth than the datasheet does. I read over enough to see it looks viable, and not as hard as some have suggested, so long as you have these documents.

The wiring side looks to be as simple as the datasheet suggests, and nothing different appears in those two files to suggest otherwise. What they clarify is how communications between the processor and the coprocessor occur. The FPU exposes a 32-byte address space of registers for communicating between the two. There tends to be a series of reads and writes needed to accomplish anything, which the manual refers to as "dialogs."

Chapter 7 of the user's manual describes these "dialogs" in great details. The basic pattern is CPU writes to a command register indicating what it wants the FPU to do, then reads a response register to see if the FPU needs anything from the CPU. The FPU response may request resolution of an operand address and being provided with the operand data, for example. If so, the FPU needs to resolve the address, load the data from register or memory, and write it to the operand register of the FPU.

The manual covers how to hand transfers using 8, 16, and 32 bit data bus sizes. AN947 includes 68K assembly macros for using the FPU as a peripheral instead of a coprocessor.

Perhaps this will help you or others in the future.