In article <3b552483$0$1915$b45e6eb0@senator-bedfellow.mit.edu>,
Jake Wildstrom 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.
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.
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
Jake Wildstrom 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.
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.