Cellular automata on Rayman's PTP w/3.5" LCD?

avsa242

Hi ladies & gents,

I'm wondering if someone can just give me a push in the right direction here. I have this source: http://forums.parallax.com/attachment.php?attachmentid=54843&d=1217417073 for the "Cellular automata 256 Rules" demo. To see what it looks like running rule #150 (using the tv driver) go here: http://www.youtube.com/watch?v=Dh9EglZJvZs

What I am trying to do, in an effort to learn spin, is port this to Rayman's PTP (propeller touchscreen platform), using his 3.5" LCD. So far I've gotten it to draw something, just not what it's supposed to. Please note I'm not looking for someone to just fix the program and give me the solution ; what I'm hoping is that someone else with this device can run the attached code and get it working as in the YouTube video, give me a hint/direction as to where the problems are in the code (e.g., is it a problem with memory offsets, a math problem, or is the hardware/drivers fundamentally different enough that it would require drastic changes, etc).

Thanks for any help you can give me!

Cheers,
Jesse

Rayman

What's not working?

I'm thinking that that longmove instruction for scrolling will have to be adjusted for the different screen size.

But, honestly, I first glance I don't see how that longmove instruction scrolls the screen a whole line... I looks to me like in only shifts two longs of memory...

avsa242

Rayman,

I do get a scrolling result, but all that is drawn is the one (seed) pixel at the center of the screen, plus about a 10 pixel long segment starting at 319,239 extending left. Occasionally it will also draw one or two pixels somewhere right of the center, as it is scrolling up. I played around a little with that longmove instruction, which btw I think is longmove destination, source, count so I think that is saying move 0x5FFF/4 (0x17FF, or just shy of 6K) of data at once no? I could be mistaken...I'm only just learning this so I wouldn't be surprised

Cheers,
Jesse

Rayman

Well, I must admit that I don't understand what that code is doing...

Apparently, it's not scrolling a whole horizontal line, just a portion of it...

Anyway, I'd think that 0x5FFF/4 will probably need to be changed as the size of the graphics buffer is smaller with the PTP...

avsa242

Rayman,

Thanks! That ended up being part of the problem...changed to move only 0x12BF at a time. The other half was simply the calculation in cpixel() for the offset from display_base. I had to try to "reverse engineer" that line to figure out that one parameter was the number of lines in the display - 1, and another was the number of y_tiles x 4. Once those were changed it came to life! Thanks again for the hint and the PTP of course! Thanks also to William Como for writing the original demo!

Cheers,
Jesse

Rayman

Nice work. Glad you didn't need too much help from me

You got me curious, so I loaded it up on my test rig and took this little video (zipped mov file).

It appears to be some kind of fractal generated on the fly... The sound appears to be generated by the video.

avsa242

Rayman,

Thanks! Yup...that particular one is commonly referred to as a Sierpinski Triangle. It's pretty simple as far as fractals go but it's one that I've been interested in since a computer programming/math teacher taught me how to render a static one in BASIC in highschool (I'll be damned if I could have remembered the code or the math on my own ). Also glad to see it works the same on your PTP as well so I know I didn't hit a fluke or something heheh. The "rule" number in the last DAT section changes the exact variation of the triangle drawn. Some look and/or sound interesting, most don't.

Cheers,
Jesse

Edit: Actually, I think I'm mistaken...rule 90 is the Sierpinski triangle...the default 150 resembles it but isn't quite the same thing. 150 sounds cooler though