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.