There's room for cpu gain :
cos(t) and sin(t) could be computed just once per frame.
x = (i-64)/128 could be moved outside the inner loop.
lots of array creation could use globals instead.
you are calling 4 pset per i/j pair for 3/4 of the pairs, so 3 pset calls per pixel instead of one on average.

All the length computations and comparisons to compute the pixel color could be manipulating square distances to avoid computing lots of square roots.

Of course, all of that would uglify the code significantly.

Other subject :
There's something I don't understand about the usage of flip in _init and _draw :
My assumption was that flip() was copying the current state of the video memory to the screen and wait for the end of the current 1/30s slice, and that that copy also happened automatically if still working when the time slice ended.

Things are not that simple : when I commented out the 1st flip in _draw to see if this would gain some time, the progressive display previously happening while inside the nested loops in _draw stopped. I don't understand why. Could you please explain that to me ? I've not tried to mix flip() and _draw except to add pauses so far.