Re: Innovative Systems FPE...

[Michael J. Mahon <mjmahon@aol.com>]

Anthony Lawther <alawther@spammenot.mac.com> wrote:
> 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.

That would require the card to make DMA accesses to memory. 

-michael  -  NadaNet 3.1:  http://home.comcast.net/~mjmahon