How did the Apple II do floating point?
Jake Wildstrom
the Apple II (in particular Applesoft Basic) handled floating point --
I'm going to be using software FP, and I'm trying to make it mimic
Apple II behavior as much as possible. Any pointers to
algorithms/specifications would be muchly appreciated.
+--First Church of Briantology--Order of the Holy Quaternion--+
| A mathematician is a device for turning coffee into |
| theorems. -Paul Erdos |
+-------------------------------------------------------------+
| Jake Wildstrom |
+-------------------------------------------------------------+
Paul Schlyter
Jake Wildstrom <wil...@mit.edu> wrote:
> For a retrocomputing project I'm doing, I'd really like to know how
> the Apple II (in particular Applesoft Basic) handled floating point --
> I'm going to be using software FP, and I'm trying to make it mimic
> Apple II behavior as much as possible. Any pointers to
> algorithms/specifications would be muchly appreciated.
http://hotel04.ausys.se/pausch/Apple2
where you can find a complete disassembly, with comments, of the
Applesoft interpreter.
Of course Applesoft performed its f.p. arithmetic in software, since
the Apple II had no hardware support for f.p. arithmetic. Applesoft
stored its f.p. values in a variety of the "Microsoft f.p. format":
Exponent byte: hi bit = sign (1=negative, 0=positive)
next seven bits = binary exponent (bias 127 or 128)
Mantissa bytes: Mantissa, with the most significant bit omitted
(it's always 1 for a noarmalized f.p. number anyway).
The Most Significant Mantissa Byte is stored closest
to the Exponent Byte.
The f.p. number zero was represented by setting all bytes of the f.p.
value to zero. There was no representation for over/underflow,
indefinite, infinite, NaN's etc. Underflows were handled by setting
the result to zero (= all bits 0), overflows/infinites by setting all
bits to 1. Indefinites and NaN's were'nt even considered.... :-)
Applesoft used four mantissa bytes = 5 bytes for the entire f.p.
number. The Exponent Byte appeared at the lowest memory address, and
the Most Significant Mantissa Byte followed; thus in the Apple II,
f.p. numbers were "big endian" as opposed to integers which were
"little endian".
MBASIC (in CP/M) used 3 (single precision) or 7 (double precision)
mantissa bytes, for a total of 4 (single precision) or 8 (double
precision). The Exponent Byte appeared at the highest memory
address, thus MBASIC in CP/M consistently stored its binary numbers
in "little endian" format. Note that unlike the IEEE f.p. format,
the Microsoft f.p. format did not use more exponent bits in
double precision compared to single precision.
GWBASIC/BASICA used the same f.p. number format as MBASIC.
Turbo Pascal used a variety of the MS f.p. format, using one
sign+exponent byte plus 5 mantissa bytes, for a total of 6 bytes.
Although the Apple II Integer Basic lacked floating point, the
Integer Basic ROM's contained "floating point routines", written by
Steve Wozniak, and callable from assembly language. These
floating-point numbers were 4 bytes large, but I don't remember their
precise format - the format differed a little from the MS f.p.
format though.
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
David Empson
> For a retrocomputing project I'm doing, I'd really like to know how
> the Apple II (in particular Applesoft Basic) handled floating point --
> I'm going to be using software FP, and I'm trying to make it mimic
> Apple II behavior as much as possible. Any pointers to
> algorithms/specifications would be muchly appreciated.
I'm aware of three relatively common floating point implementations on
the Apple II:
- Applesoft BASIC
- Apple II Pascal
- Standard Apple Numerics Library (SANE)
Applesoft's implementation came from Microsoft. It uses five bytes to
store the floating point number, with a similar range of magnitudes to
IEEE-754 single precision floating point (i.e. 7 bit exponent), but with
a larger mantissa hence greater precision. I don't have time to check
right now, but there is probably more information available in the
reference manuals. An interesting point about the Applesoft floating
point engine is that it had some well known bugs which you may want to
emulate.
I don't know what Apple II Pascal used. It is probably documented in
the manual, which is rather deeply buried at the moment. I think it had
four bytes for floating point variables, so it is probably similar to
IEEE-754 single precision.
SANE _is_ IEEE-754/854, using single, double and extended precision (4,
8 and 10 bytes respectively). The SANE library was available for 8-bit
Apple II models (used by AppleWorks, for example), and is part of the
toolbox for the Apple IIgs and Macintosh.
Paul R. Santa-Maria
> For a retrocomputing project I'm doing, I'd really like to know how
> the Apple II (in particular Applesoft Basic) handled floating point --
> I'm going to be using software FP, and I'm trying to make it mimic
> Apple II behavior as much as possible. Any pointers to
> algorithms/specifications would be muchly appreciated.
Please see:
http://til.info.apple.com/tilarchive.nsf/artnum/n74
http://til.info.apple.com/tilarchive.nsf/artnum/n75
http://www.6502.org/source/source.htm
Paul R. Santa-Maria
Monroe, Michigan USA
Paul R. Santa-Maria
> Please visit my Apple II web page at:
> http://hotel04.ausys.se/pausch/Apple2
> where you can find a complete disassembly, with comments, of the
> Applesoft interpreter.
Paul, I have tried to use the source files you have posted but they are in a
difficult format to use. It would be much more handy if you were to
assemble them and post the listing file instead. Creating new source from
the listing file is much simpler than trying to create them from the
original tokenized source file.
Dr A.P. Whichello
> Jake Wildstrom <wil...@mit.edu> wrote:
>
> > For a retrocomputing project I'm doing, I'd really like to know how
> > the Apple II (in particular Applesoft Basic) handled floating point --
> > I'm going to be using software FP, and I'm trying to make it mimic
> > Apple II behavior as much as possible. Any pointers to
> > algorithms/specifications would be muchly appreciated.
>
> I'm aware of three relatively common floating point implementations on
> the Apple II:
>
> - Applesoft BASIC
> - Apple II Pascal
> - Standard Apple Numerics Library (SANE)
>
> Applesoft's implementation came from Microsoft. It uses five bytes to
> store the floating point number, with a similar range of magnitudes to
> IEEE-754 single precision floating point (i.e. 7 bit exponent), but with
> a larger mantissa hence greater precision. I don't have time to check
> right now, but there is probably more information available in the
> reference manuals. An interesting point about the Applesoft floating
> point engine is that it had some well known bugs which you may want to
> emulate.
Somewhere I have an article describing the bugs.
>
> I don't know what Apple II Pascal used. It is probably documented in
> the manual, which is rather deeply buried at the moment. I think it had
> four bytes for floating point variables, so it is probably similar to
> IEEE-754 single precision.
It was similar, but not identical. I recall it had an 8 bit exponent
(excess 128?) and 23 bit normalised mantissa. The SANE package had
conversion routines to/from for it. If you hunt around my Sydney Uni web
page (assuming it's still there) for my MATHPACK.TEXT unit, some
functions using trix records show how the Pascal floating point could be
used and manipulated.
>
> SANE _is_ IEEE-754/854, using single, double and extended precision (4,
> 8 and 10 bytes respectively). The SANE library was available for 8-bit
> Apple II models (used by AppleWorks, for example), and is part of the
> toolbox for the Apple IIgs and Macintosh.
I have the complete 8 bit version for Pascal, Prodos and Apple 3
somewhere, assuming the disks still work...
Adrian.
--
Dr A.P. Whichello Phone: +61 2 6201 2431
Electronics & Telecommunications Engineering Fax: +61 2 6201 5041
University of Canberra Email: adr...@ise.canberra.edu.au
Australia WWW: http://www.ee.usyd.edu.au/~adrianw
"I wish to God these calculations had been executed by Steam!" C.Babbage
Paul Schlyter
you'll find an executalbe for MS-DOS, runnable on Windows too as a
console application. On other systems you must download the C
source, FID.C, and compile it yourself. It's written in portable
C and compiles cleanly on 16-bit MS-DOS, on 32-bit Win-32, and on
several flavors of UNIX.
FID is able to de-tokenize Applesoft Basic, Integer Basic and S-C
Assembler tokenized files to plain ASCII files. Note that Integer
Basic and S-C Assembler tokenized files are both stored as type 'I'
files on Apple DOS disks; however FID is able to automatically
determine which is which (not that difficult really; a tokenized
Integer Basic program line always ends with a $01 while a tokenized
S-C Assembler line always ends with a $00.
Compiling the source files for Applesoft and storing the listing file
on disk has one substantial problem: that listing file is too large
to fit within those 140K (really 128K data area) of an Apple DOS 3.3
disk....
Stephen Shaw
remember correctly. A lot of money in those days!
--
*(C)ontinue (A)bort (F)all Asleep*
Ralf Quint
<snip>
>
>MBASIC (in CP/M) used 3 (single precision) or 7 (double precision)
>mantissa bytes, for a total of 4 (single precision) or 8 (double
>precision). The Exponent Byte appeared at the highest memory
>address, thus MBASIC in CP/M consistently stored its binary numbers
>in "little endian" format. Note that unlike the IEEE f.p. format,
>the Microsoft f.p. format did not use more exponent bits in
>double precision compared to single precision.
>
>GWBASIC/BASICA used the same f.p. number format as MBASIC.
>
the [M,GW]BASIA[A] fp formats? For a software reconstruction project,
i would need any available information about this i could get...
thanks,
Ralf
Douglas A. Gwyn
> There was an FP chip for the Apple. About US$300 in the late 1970's if I
> remember correctly. A lot of money in those days!
Not exactly a "chip", since the Apple II didn't have any FPP socket.
There was a *card* using the MC68881 that was supported by ORCA/C.
Paul R. Santa-Maria
> Paul R. Santa-Maria <pa...@wccnet.org> wrote:
> > Paul Schlyter <pau...@saaf.se> wrote:
> >> Please visit my Apple II web page at:
http://hotel04.ausys.se/pausch/Apple2
> >> where you can find a complete disassembly, with comments, of the
> >> Applesoft interpreter.
> > Paul, I have tried to use the source files you have posted but they are
in a
> > difficult format to use.
> Assembler tokenized files to plain ASCII files.
I don't understand how to make it work. APPLESOFT.sit contains individual
tokenized S-C assembler source files, not a DSK image. FID appears to only
work with DSK images, not individual files. What am I doing wrong?
Paul Schlyter
Paul R. Santa-Maria <pa...@wccnet.org> wrote:
> Paul Schlyter <pau...@saaf.se> wrote:
>> Paul R. Santa-Maria <pa...@wccnet.org> wrote:
>>> Paul Schlyter <pau...@saaf.se> wrote:
>>>> Please visit my Apple II web page at:
>http://hotel04.ausys.se/pausch/Apple2
>>>> where you can find a complete disassembly, with comments, of the
>>>> Applesoft interpreter.
>>> Paul, I have tried to use the source files you have posted but they are
>>> in a difficult format to use.
>> FID is able to de-tokenize Applesoft Basic, Integer Basic and S-C
>> Assembler tokenized files to plain ASCII files.
>
> I don't understand how to make it work. APPLESOFT.sit contains individual
> tokenized S-C assembler source files, not a DSK image. FID appears to only
> work with DSK images, not individual files. What am I doing wrong?
did put on my Apple II web page.
So now you have four options:
1. Use that other DSK image utility (there's a link to it on my Apple II
web page) to put those S-C Asm source file on .DSK images, then use my
FID utility to detokenize it.
2. Grab the C source of my FID utility and modify it so it can detokenize
individual files too. Or...
3. Wait until I do 2. for you - it may take a few weeks.
4. Wait until I upload the Applesoft source as .DSK images to my Apple II
web page - it may take a week or so.
I'll get back here and tell what I've done.