Re: Innovative Systems FPE...

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

mdj wrote:
> 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 ...

Since the card cannot directly access memory, it depends on 6502
instructions to move data, so endianness is intrinsically a decision
of the 6502 load/unload code.

> > > > 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'

Actually, I doubt it.

The only data endianness "enforced" by the 6502 is that involved in
indirect addressing, which has nothing to do with FP.

Many FP implementations choose big-endian just because it's a lot
easier to visualize the shifts, etc., than in little-endian mode.  ;-)

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

Since the 68881 and all contemporary FP coprocessors directly
implemented IEEE FP, which SANE is a software implementation of,
it was natural to use IEEE formats.

I don't know of any coprocessor that implemented Applesoft-format
FP numbers, except possibly by a software patch.  Certainly no
hardware ever did!

It would be possible to load/unload memory values to/from a buffer
register in the "glue" logic, which would then transform them on
their way to the coprocessor, but that would be much more complex
logic for the time, and would specialize the interface.

Maybe FP coprocessor card makers figured that if you were using
Applesoft, you weren't too interested in speed.  ;-)  But that could
certainly be said for those using SANE--it's slow as molasses!

I'm going to be looking at conversion of IEEE to/from Applesoft format,
and I expect it to involve a shift and a little bit fiddling, but not
too much to do on-the-fly.

-michael

NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon

"The wastebasket is our most important design
tool--and it's seriously underused."