8BIT wrote:
The code took 7 minutes and 46.4 seconds to run (65816 clocked at 7.1MHz generating a 320x200 color display).
The code in the article can be sped up in a number of ways, such as using a smaller timeout value than 256 (e.g. 32 as in CC65). 7.1 MHz compared to 1 Mhz Apple II (or 2.5 MHz Apple IIgs) helps too, of course, as would using 16-bit native mode on the 65C816. (I thought about replacing the multiply routine with a faster table-driven technique, like 4AB = (A+B)^2 - (A-B)^2, but I never got around to doing much about that.) The BASIC loop in lines 300-550 would be much faster in assembly, since the all the necessary values already pre-computed; the FP math would be replaced with fixed point math (and the FP to one's complement fixed point conversion wouldn't happen inside the loop any more, nor would saving/restoring the ZP each time), and so on.
One modification I made was to separate the calculation from rendering. I just stored the data in RAM, then I could apply coarse value coloring or fine value coloring to the same data without having to recalculate the data (which was the slow part). (The built-in BASIC graphics routines were ROM-space-optimzed, and thus slow; redisplaying the image was fairly quick using speed-optimized routines.)
The next month's article (Bob doesn't have a scan of it on his website for whatever reason) has a modified BASIC program that uses (if memory serves) the neighboring value technique described in the article. I still have both issues somewhere in the bat cave. It was an interesting, but slow, program. I'd let it run overnight, and I can remember my father making me get out of bed at some ungodly hour of the morning one day because "the computer is beeping". Of course, back then I considered anything before 11:45 A.M. to be some ungodly hour of the morning.
Login
Register
FAQ
Search
