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

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.

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 ... 00_System_[Motorola_1987_37p].pdf

That appears to be a dead link.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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

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

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

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.

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

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.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

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

Holy moly - I'm sorry to hear it!

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.