Around 768 bytes. The golden days of tight code and amazing minds pulling together cool code that set the framework for floating point on 'home' computers. A great reference point and piece of history.
Well, $1fee-$1d00=750 bytes of code, + the 14 zero page locations. Its really the zero page that makes the processor function at all. When I go back to 6502 assembly, it amazes me what was possible with a processor that basically had 3 independent (because they could not be combined) 8 bit registers and a 256 byte stack.
There are some C compilers (http://www.6502.org/tools/lang/) for the processor, but it quickly becomes obvious just how poorly C fits. The 6502 is basically a processor that forces one to code with a bytecode + interpreter or in native assembly.
Which brings me back to the zero page. It is is both the solution to getting anything complex done. And simultaneously the problem because there isn't a good way to allocate space there (because the zero page locations are encoded directly in the instructions).
You need to allocate zero page as you do registers - but fortunately it's large enough (compared to the complexity of 6502 programs) that you'll probably never need to deal with spilling. So what I've always done is use the assembler to allocate bytes in zero page as required. Your code will seem to eat through the space available very quickly... and then, at some point before you run out, you'll stop needing any more.
(Trying to allocate space there dynamically is certainly a fool's errand, of course.)
Yes, but it precludes easily sharing routines from different projects. I remember being frustrated a number of times because I didn't have source for something that conflicted with another library I wanted to use.
(Just to add to this, that hundred or so free bytes in the $0300 page IIRC was also a problem. Lots of utilities used it, so I remember there being a lot of conflicts there too).
Takes me back a bit. In 1980 I was writing an APL interpreter for the Apple ][ (alas, not half completed) and purchased a copy of "Software Manual for the Elementary Functions" by Cody and Waite. It still sits on my bookshelf 35 years later, awaiting full translation of its algorithms into 6502 code. SQRT, ALOG/ALOG10, EXP, POWER, SIN/COS, TAN/COT, ASIN/ACOS, ATAN/ATAN2, SINH, COSH, TANH, and random number generation. Also useful and comprehensive testing notes for your nascent implementation, with tests written in Fortran.
Alternative code, this time from the 1980s, and targeting the CMOS variants, from another W (Acorn's Sophie Wilson): http://8bs.com/basic/basic4-bycategory.htm#Menu - scroll down a bit to find the floating-point operations.
I think the format was: 1 bit sign, 7 bit exponent, 32 bit mantissa.
(This code is for the version of BBC BASIC that shipped with Acorn's Master 128.)
Tons of great little tricks in there. 6502 math coding is kind of fun in this way.
A look at old games, such as "Elite" ( http://www.iancgbell.clara.net/elite/) show many trade offs being used to make simple wireframe 3D plausible at some few frames per second.
One thing to keep in mind is how primitive microprocessors like the 6502 were. The IBM 704 (introduced in 1954) had floating point in hardware (i.e. lots of vacuum tubes). The 6502, more than 20 years later, didn't have any math beyond 8-bit integer adds, subtracts, and shifts. Even integer multiplication required software. The 6502 floating point routines are an accomplishment, but implementing floating point circuitry with vacuum tubes is also pretty impressive.
The 6502 was special because it was so, so much cheaper than its competitors, at least initially, making home computers practical. And that's probably why it was so limited.
Curious. So Woz had already written these routines and didn't incorporate them into Integer BASIC because "he was primarily interested in writing games, a task for which integers alone were sufficient."
Yet there was customer demand for floating-point and Apple ended up contracting Microsoft's BASIC (which included FP) as Applesoft. Supposedly this was because "Wozniak—the only person who understood Integer BASIC well enough to add floating point features—was busy with the Disk II drive and controller and with Apple DOS, Apple turned to Microsoft."
It's hard for me to imagine that Apple didn't have a single engineer that could incorporate these already-written-by-Woz routines into Woz's Integer BASIC.
Woz was a beast. I often wonder how he got so good without a community, but I imagine having a father who graduated from Caltech and worked as an EE at lockheed helped a lot.
There was quite a big community for that area - notably the home brew computer club, not to mention a bunch of early computer fan zines that morphed into magazines. Not to mention a lot of heavy thinkers designing mainframes and minis (also probably attending the HBCC).
edit: I see from the link in the comment posted by ddingus that there is also an errata with a fix for the bug in the original code. http://codebase64.org/doku.php?id=base:errata_for_rankin_s_6...