[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Innovative Systems FPE...
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...
-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."