!pr2
Rod's Color Pattern in 6502 Code.............Charles H. Putney

When I read the January AAL with Bob Urschel's article about running Rod's Color Pattern on the QWERTY 68000 board, it sounded like a challenge.  You may remember I like speed challenges, at least inside computers.

Fifty times faster than Basic didn't sound too fast, so I checked a simple loop to see if it might be possible to save the dignity of the 6502.  It did look possible, at least by using tricky table-driven code.

So, I wrote some more code and it looked like 8.0 seconds per loop.  This clocks out at 55 times faster than Integer BASIC, but I didn't have the internal calculation for the color value exactly like the original.

I finally decided to use a table lookup for the color calculation.  Now the problem was how to create all those data statements.  I thought about using some macros, but the calculations are too involved.  I wrote an Applesoft program to generate the lines of code for the assembler, and then EXECed them into my source code.  I finally got all the bugs out and timed it.

The table-driven version performs a main loop every 6.2 seconds, compared to 446 seconds per loop for the Integer BASIC version.  That is nearly 72 times faster.

Well, my only worry now is that Bob Urschel made an error in his timing, and his really runs 200 times faster.  If not, we have saved face for the venerable 6502.

Of course, we did use a little more memory.  But that is frequently a trade-off worth making in important programs.

For comparison purposes, here is the Integer BASIC program again:

!lm+5
10 GR
20 FOR W = 3 TO 50
30 FOR I = 1 TO 19
40 FOR J = 0 TO 19
50 K = I+J
60 COLOR = J*3 / (I+3) + I*W/12
70 PLOT I,K: PLOT K,I: PLOT 40-I,40-K:PLOT40-K,40-I
80 PLOT K,40-I: PLOT 40-I,K: PLOT I,40-K: PLOT 40-K,I
90 NEXT J: NEXT I: NEXT 2
100 GO TO 20
!lm-5

My program to generate the data tables includes similar logic.  I broke the tables into two planes, rather than storing one data table 48*19*20 = 18,240 bytes long.  One plane computes J*3/(I+3), and includes 380 bytes.  The other computes I*W/12 and includes 48*19=912 bytes.  My table lookup routine uses I and J to index into the first plane, and I and W into the second.  Then the two values are added together.  Pretty tricky!
!np























I believe in letting computers work for me, so I had to use some macros to simplify typing in all the code for those eight plot statements.  I wrote a PLOT macro, but then I noticed that there was some redundant code that way.  By rearranging the order of the PLOT statements, I can separate the y-setup from the x-setup and plot.  That way the base address does not get re-calculated as often, saving more time.  Here is my program:
