Re: Innovative Systems FPE...

[mdj <mdj.mdj@gmail.com>]

On Aug 12, 6:15 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> On 8/11/2010 11:44 PM, mdj wrote:
>
> > On Aug 12, 7:20 am, "Michael J. Mahon"<mjma...@aol.com>  wrote:
> >> I recently acquired an Innovative Systems (iS) 68881 FPE.
>
> >> It was clearly designed to accelerate SANE on the IIgs, but it
> >> also came with Appleworks 2.0 patches (for it's SANE routines)
> >> and with a set of macros for direct use with 8-bit Apple II's.
>
> > Are they SANE compatible macros? It seems wierd that they'd patch the
> > SANE runtime and use broken macros when SANE itself already supplies
> > them (albiet only for EDASM).
>
> The macros were originally designed for APW and the 65816, then
> translated automatically (then how account for the non-systematic
> errors?) for Merlin 8.
>
> I really haven't compared them to Apple's SANE macros--that's an
> interesting thing to do.  They seem quite heavily influenced by
> Motorola's 68000 assembler in concept--sort of.
>
> It's about 600 lines of macros that could easily be reduced to
> 200 or less with a suitable use of macros!  ;-)
>
> For example, specifying a command and transferring data are done
> as separate "phases" involving handshakes with the 68881.  And
> each different data format (Single, Double, Packed BCD, etc.) has
> its own macro, rather than passing the storage format as another
> parameter.
>
> They also decided to store the FPE's slot-based /DEVSEL base in
> page zero, and always refer to FPE registers indirect,Y.  This
> would permit dynamically adapting code to whatever slot the FPE
> is in, but their code patches for Appleworks, for example, are
> replicated for each slot--statically compiled into the code!
>
> If one is willing to assemble for a particular slot, then much
> more compact and faster code can be written to access the FPE.
> In fact, one could even use "loops" and other advanced programming
> concepts.  ;-)
>
> They agonized over flipping little-endian 6502 data to big-endian
> 68881 data, even for data types that have no native use on the 6502.
>
> All things considered, I think I can make this much simpler, faster,
> and smaller, all at once.

It sounds like it! Strange, with that much glue logic you'd think
you'd handle endianness translation in hardware ...

> >> Upon reviewing the macros converted for Merlin, it's apparent
> >> that they were never used or tested, since they have numerous
> >> errors.  They also suffer from the delusion that floating-point
> >> numbers should be represented in little-endian form on the 6502,
> >> which Applesoft contradicts.
>
> > Curious, since the 68k is big-endian, but I suppose you can load the
> > registers more quickly on an 816 that way...
>
> Since the 65816 has no notion of the meaning of floating point data,
> that choice is arbitrary.  Did Apple choose little-endian representation
> for SANE FP numbers?

It's little, and the call interface is essentially push two addresses
onto the stack plus an operand code and call the entry point.

I suspect that this allows some slight optimisations since in little
endian the floating point mantissa has the same address as an integer
type does, though I admit this is 'gut feel'

> >> Does anyone know how many of these things were made, and if
> >> anyone ever used one successfully with a //e?  My serial number
> >> is 890005, so I'm guessing they weren't very popular.  ;-)
>
> >> I'm making progress, but feel like completely redesigning
> >> the macros to use a small runtime FPE package.  A further
> >> out possibility is making an interface to Applesoft, since
> >> the 12MHz 68881 clock compensates for the relatively weird
> >> dance one must do with the 6502 to load operands, perform
> >> instructions, and store results.
>
> >> This might be a more interesting thing to do if there were
> >> more of them in use...
>
> > Well, if you managed to make a patchset for Applesoft and somebody
> > wanted to produce some , it'd be a mighty fine accelerator
> > companion... How complex is the board ?
>
> Simply complex.  ;-)  It's basically a 68881 and a Xylinx XC2064
> glue chip (plus a TTL transceiver).
>
> Looking over the Applesoft listing, I see a lot of "fiddling" with
> the floating-point accumulator, so it would be difficult to simply
> map FAC and ARG to 68881 registers.
>
> The easy way (?) would be to convert Applesoft's FAC and ARG into
> and out of the 68881 on pretty much every operation worth speeding
> up (multiply, divide, math functions, BCD conversions), which would
> require a lot of annoying movement of data...

Right. A 'good' card would have a mode that presented Applesoft
compatible registers (didn't the older ones do that ?) but I suspect
optimising for SANE was the first order of business.

Matt