Re: Innovative Systems FPE...

[alawther@spammenot.mac.com (Anthony Lawther)]

Michael J. Mahon <mjmahon@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.
> 
> >> 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?
> 
> >> 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...

If the intent is to replicate the function of this card rather than
slavishly cloning it, would it not make sense to use a larger glue chip
(if necessary) and perform the transformations in hardware? Then it
would reduce to copying the FAC and ARG from RAM to the registers in the
glue chip on the card and triggering the required function then copying
the result back from the registers. This could even allow further
optimisation when cascading operations.

Regards,
Anthony.
> 
> -michael
> 
> NadaNet 3.1 for Apple II parallel computing!
> Home page:  http://home.comcast.net/~mjmahon/
> 
> "The wastebasket is our most important design
> tool--and it's seriously underused."