[CSDb] - User Forums - How easy is it to calculate sine tables from the bare bones in ML?

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > How easy is it to calculate sine tables from the bare bones in ML?

2008-08-05 09:52

Conrad

Registered: Nov 2006
Posts: 849

How easy is it to calculate sine tables from the bare bones in ML?

Hi!

I'd like to have a go at coding my own routine of calculating sine/cosine tables without use of the BASIC interpreters (pi, sin(), etc) and just use pure ML instead.

Can I ask, how easy (or how SMALL) is this to do? Do I need to do additional algorithms like factorial or are there KERNAL routines for that (if any)? Multiplication code is no problem as I've seen articles on those, I'm just thinking about the rest of math involved with sine calculation.

Thanx in advance.

... 30 posts hidden. Click here to view all posts....

2013-12-20 23:47

doynax
Account closed

Registered: Oct 2004
Posts: 212

Quoting ChristopherJam

An alternate approach is to fill a table with a square wave, then filter it with a few smoothing passes to eliminate the harmonics. The following hasn't been optimised for size, but it's only 38 bytes, and only takes about 170,000 cycles to create a table of 127.5+63*cosine(i*pi/128) with an RMS error of under 1%

Well done, that is exceedingly clever. I never would have considered that approach.

Any chance of a 16-bit version or one with (closer to) full 8-bit range?

2013-12-22 08:39

ChristopherJam

Registered: Aug 2004
Posts: 1409

Thanks doynax. I was probably somewhat influenced by having spent a couple of weeks playing with KarplusStrong string synthesis earlier this year (looking for fresh samples to try to play back on the c64 ;) - most of the sounds tended towards a sine wave eventually.

16 bit should be reasonably sane; I've just finished tuning a simulation of one that gives 16 bit results with a range from $0000 to $ffff, RMS error of around 31, or 0.04% of the full range.

It's all getting a little far from practical at this point, as it likely wouldn't save that much space over a table, which in turn you could probably LZ compress the deltas for reasonably well.

Here's the Python in any case - I leave translation to 6502 as an exercise for the reader, or my future self if I get really really bored. The N.sum(v)/256 terms could, of course, be pre-calculated.

import numpy as N

def sim(si,jo,dco,lv,hv,pw):
	v=N.zeros((256,),N.int)+lv
	v[dco:][:pw]*=0
	v[dco:][:pw]+=hv

	nv=1

	i=si
	j=(i+jo)&255
	while 1:
		nv=(v[i]+v[j])+(nv&1)
		v[i]=nv/2
		i=(i+1)&255
		j=(j+1)&255
		if(i&255==0):
			j=(j-1)&255
			if j==0:
				break

	v=(v+N.take(v,(N.arange(256)+64)%256))*256
	v-=N.sum(v)/256
	v=N.cumsum(v)/256
	v-=N.sum(v)/256
	v[0]+=0xfffe00
	v=N.cumsum(v)/256
	return v

v=sim(255, 31, 81, 0, 13097, 131)

Previous - 1 | 2 | 3 | 4 - Next

Refresh

Subscribe to this thread: