Speed-coding for the 6502 – a simple example (colino.net)

What a delightful short read.

They could go one step further and calculate the table as needed and use it as a cache.

For an single image scaling it might get a little bit better.

I wonder if building this table can be sped up by noticing a recurring pattern?

    x    0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 ... 254 255
    f(x) 0  0  1  2  3  3  4  5  6  6  7  8  9  9 10 11 12 12 ... 190 191

So something like

    sta table,y
    iny
    sta table,y
    adc $0
    iny    
    sta table,y
    adc $0
    iny    
    sta table,y
    adc $0
    iny    

used as the loop body that should be repeated 64 times, should work. Will it take less than 6000 cycles total?

Very neat. Breaking up multiplications and divisions into bit shifts, and lookup table to trade off memory for runtime, are indeed nothing new to engineers working on the low level, but this paints a very pretty picture of how this looks in practice.

Games that needed trig in the 90's often used SIN/COS lookup-tables. To keep memory down:

1) you only need the first 1/4 of the Sine table since the remaining 3/4 are either the first 1/4 in reverse and/or with the sign flipped.

2) and of course Sine can also be used as a Cosine lookup if you add pi/2 radians to the cosine angle (wrapping around of course).

3) to avoid the size needed for a table of floats you can of course use integers (scaled by some factor) or fixed-point values.

4) and simple interpolation would get you seemingly more precision.

(Combining all the above was a bit gross so documentation and a good SPI helped.)

I wrote a token ring networking simulator with error simulation (token dropping etc) on a 6502. 128 bytes of RAM. It was a squeeze.

I used a Hewlett Packard development system with a 12" hard disk.

Good times.