Noticed a slight difference between the code I had uploaded, and the code in my workspace.
I was able to get the Arduino Mega 2560 to calculate and draw a next nearest neighbor fractal using uLisp-TFT. However, I had to use some rather aggressive GC to keep from running out of memory, which slowed the calculation down very much (about 8 or 9 hours for this image). I only need to store two lines of pixels at a time, but I think data extraction and rule-related calculation creates a lot of intermediate lisp objects. To make this practical I think I need to re-implement the core NNN functions in C, leaving the Lisp rule selection and drawing interface on top.
uLisp code is available here: http://download.savannah.nongnu.org/releases/ulisp-tft/nnn-slow.tar.gz
This call should get you a similar image:
(lcdinit) (drawnnn (buildf32 187 71 254 245) (randomline 30))
30 is for 30 blocks of 16 pixels, i.e., start with 480 pixel line.
I have a new project, adding TFT extensions to Arduino’s uLisp interpreter. In other words, I’m adding uLisp TFT commands so I can control a TFT Shield using lisp commands rather that direct C functions. The new Lisp functions are basically wrappers around the C function, which is a lot easier than re-writing them all in lisp, on the pin level. This allows to write TFT based programs in lisp, of course, and also command the shield at an interpreter prompt through the serial connection, rather than having to recompile a program.
1215> (setcolor 0 0 255) nil 1215> (dotimes (x 119) (drawline 100 200 (* x 4) 319)) nil
The project is hosted at Savannah.
I am using the KUMAN 3.5″ TFT LCD Shield. The shield does both screen drawing and touchscreen, but at present I have only implement some of the screen drawing functions. I initially wanted to use a UNO instead of a MEGA2560, but I wanted something with more memory if I was going to try combining uLisp and the TFT related libraries.
Shortly after getting enough functions to draw on the screen, I wrote a lisp program to draw Next Nearest Neighbor fractals. Having less that 1600 bytes of spare memory to work with I had to be extra careful even buffering a single line of pixel data, packing sixteen pixels into each sixteen bit integer. I wanted to post a cool photo of that, but for some reason the program keeps running out of memory, even when I’m using aggressive garbage collection. It seems like the procedures I wrote shouldn’t be using that many bytes, but apparently I’ll have to review that some more.