This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's Your Projects subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.

This forum is locked: you cannot post, reply to, or edit topics. Project Releases => Your Projects
Author Message

Advanced Member

Joined: 13 Mar 2004
Posts: 423

Posted: 16 Jun 2007 10:11:10 am    Post subject:

File Name :: Cellular Automata
Author :: Iambian
Category :: Ti-83plus Asm Math/Science
Screenshot ::
Description ::
This program is a more generalized version of my previous submission of a program of this type. By default, it runs the rule set for two-dimensional cellular automata known as "Conway's Game of Life", or just "Life". You can also change the rules, describes some of the named rules.

I'm open to comments about the program, especially about bug reports. It *is* open-source, after all.

View File
Back to top


Joined: 04 Apr 2007
Posts: 756

Posted: 16 Jun 2007 02:46:03 pm    Post subject:

Oh, looks better than before. I wanna try...
Back to top


Joined: 27 Aug 2005
Posts: 956

Posted: 16 Jun 2007 10:40:05 pm    Post subject:

That is pretty fun, even though I don't understand the concept behind the whole thing XD

And I am not looking for an explanation, I have plenty of other useless information in my head... Razz
Back to top

Advanced Member

Joined: 13 Mar 2004
Posts: 423

Posted: 20 Jun 2007 10:56:01 am    Post subject:

I've identified a non-critical bug with regards to the "save a pattern" option. Well, I'm pretty sure it's a bug, but I'm not entirely sure if it's rather a problem relating to the step-by-step feature. What happens is that when you generate a pattern that you happen to like, the feature will either save from the incorrect buffer, or one more iteration of the cellular automaton will take place before the program actually exits. Whatever the problem is, I'm going to see about fixing it soon.

Also, I'm implementing an update to the menu system (essentially a copy and paste operation from a more recent yet incomplete project), which will invariably cause the program to bloat a wee bit more. The planned update will change the form of the "change rules" menu a small bit and will introduce a small box indicating the current rule in effect. This may slow down scrolling a small bit due to the redisplay overhead (note: ineffective method), but it should not be entirely noticable.

I also plan on introducing a thumbnailing feature for the "load a pattern / save a pattern" menus that will allow the user to have a general idea of what it is that he or she will be loading to the graphscreen. I haven't figured out how I'm actually going to do it, but rest assured that it will be done eventually.

In place of providing an in-program rule editor, I might just take the cheap way out and either allow the program to be more easily "hackable" or I'll ask the user to provide a ruleset through a variable, like Str0 or something. Help would be appreciated for programming an in-program rule editor. I would also be grateful if it were programmed to work with the pre-existing dialog box routines (found in _UTILITY.Z80).

Any other thoughts as to how the program may be improved?

Last edited by Guest on 20 Jun 2007 10:56:43 am; edited 1 time in total
Back to top

Advanced Member

Joined: 13 Mar 2004
Posts: 423

Posted: 25 Jun 2007 02:58:29 pm    Post subject:

Sorry for the double-post, but I think it really needs it.

I'm having problems with the update. The menu system's been changed and the source that handles the menu system's become even more unreadable than ever, not to mention the "stack abuse" that's now become rampant in the code.

For some reason, between the running of the cellular automaton and handling the menu system, random bytes are being written all over the place, and I don't know exactly how to deal with that kind of problem. Are there any suggestions on how to identify where these random changes are being made or how it's affecting the RAM? Or if it's an error with how I'm handling the stack or whatnot?

Previously, the program's been crashing upon exit to the TI-OS but only when the cellular automaton is actually run ("start program"), but now it's somewhat stabilized on PTI, but the random crashes are still worrying me. I hate to knowingly (officially) release an unstable program, so...

The attached file is what I have so far. The difference in the menu system is the addition of functionality to the left/right keys in certain menus, and a slightly altered system of how the vectors are loaded (see _utility.z80). The run of code that handles the menu for the "change rules" section are especially ... obfuscated. I certainly need to make a macro of it, but haven't really bothered myself to do it. For the main routine, I have the program save an additional twelve bytes (total 24) from the area above and below both screen-sized buffers used for the cellular automaton. I believed that this was the problem, and I certainly had the additional space in StatVars to do it. Some of the crashing problems cleared up a bit, but when I noted that some of the text was overwritten when I tried to go back to a menu, I then believe it was a problem bigger than just writing too far outside the buffers.

Last edited by Guest on 25 Jun 2007 03:00:59 pm; edited 1 time in total
Back to top
DJ Omnimaga

Calc Guru

Joined: 14 Nov 2003
Posts: 1196

Posted: 24 Jul 2007 12:06:36 pm    Post subject:

wow look nice!
Back to top

Advanced Member

Joined: 13 Mar 2004
Posts: 423

Posted: 26 Jul 2007 02:51:11 pm    Post subject:

DJ Omnimaga wrote:
wow look nice!

Thanks for the compliment :)

On another topic, I've just found out (since I've just been using this on the homescreen), that this program does not seem to like MirageOS. That is, upon successful execution (if it gets that far), the calc will crash. For some reason, this does not happen when I run the program from the homescreen.

Perhaps this has to do something with the interrupt table vector or something, since this program uses the memory area between $8000 and $81FF. Or do you think it's a problem with something happening with the FlashAPP?
Back to top


Joined: 04 Dec 2008
Posts: 32

Posted: 04 Dec 2008 02:55:19 pm    Post subject:

I dont understand this source code can somebvody walk me through this by commenting a source code too .either in the forum or by mail will work
Back to top
darkstone knight

Advanced Member

Joined: 07 Sep 2008
Posts: 438

Posted: 04 Dec 2008 05:15:50 pm    Post subject:

this is an assembly game, if you want to read it, you need to get the origion Source (wich, for this game, is public)

if you enter this game in the SourceCoder thing, you will see the instructions as they apear to your calucation (short story: binairy junk)

if you want to learn assembly, check this: (the beginning is hard, dont give up lol, its worth it)
Back to top

Advanced Member

Joined: 13 Mar 2004
Posts: 423

Posted: 09 Dec 2008 03:04:42 pm    Post subject:

Truthfully, this code is not really meant to be understood by anyone. If you just want to pull the main "engine" of the program out, copy and paste the stuff between the label "begincellular2" and the comment "Subroutine code end" (these are lines 328 through 858 of the file "Cellauto.asm"). Define the following labels:

iterations equ tempswaparea+00;Current number of iterations performed. (4b)
buf1       equ tempswaparea+02;(2b) Buffer 1 to read cell data from
buf2       equ tempswaparea+04;(2b) Buffer 2 to write new cell data to.
done       equ tempswaparea+06;(1b) 0=iterations not done. 1=iterations match "setloops"
halted     equ tempswaparea+07;(1b) 0=continuealgorithm 1=haltprogram
rules      equ tempswaparea+08;(2b) address of ruleset
iterations equ tempswaparea+10;Current number of iterations performed. (4b)

The only thing that needs to be initialized before calling "begincellular2" is "rules", which takes an address to the data that defines the rule. An example of this:

.db 1  ;return to life, one entry
.db 3  ;return to life, these # of neighbors
.db 2  ;keep alive, two entries
.db 2,3;keep alive, these # of neighbors

Ensure that nothing is being kept in the appbackupscreen and the savesscreen buffers, as they will be trashed. Also, statvars will be trashed, so after you're done using the routine in your program, do a "bcall(_DelRes)".

Just about everything else in the program other than the mentioned material just puts a pretty face on the program. The material that is mentioned should be treated as a black box : You do not need to know how it works, just that it works.

EDIT: How do I get the post to preserve spaces in the codebox?
EDIT2: The source that was mentioned requires one dependency: The contents of the "_getkbd.z80" file.

Last edited by Guest on 09 Dec 2008 03:11:48 pm; edited 1 time in total
Back to top
The Raptor of Calcs

Super Elite (Last Title)

Joined: 25 Oct 2006
Posts: 2535

Posted: 09 Dec 2008 05:34:03 pm    Post subject:

I think your only option to have spaces in a codebox is to type some random characters, some underscores maybe, and make them white...

EDIT: And ASM is one of the hardest languages (IMHO) to reverse-engineer (as in to understand how it works as though it were your own program).

Last edited by Guest on 09 Dec 2008 05:34:59 pm; edited 1 time in total
Back to top

Advanced Member

Joined: 13 Mar 2004
Posts: 423

Posted: 09 Dec 2008 07:05:56 pm    Post subject:

Harrierfalcon wrote:
EDIT: And ASM is one of the hardest languages (IMHO) to reverse-engineer (as in to understand how it works as though it were your own program).

That's part of the reason why I attempted to provide a solution that requires no knowledge of how or why it works. Just copy, paste, and make the changes needed to get it to work.

Now... I'm unsure of how well it would work given those instructions, but it seems right to me. One thing I forgot to mention is that it might be a good idea to initialize "iterations" to zero. Or at least the first bit.

EDIT: "bit", referring to "binary digit". It influences which buffer the material is going to be written to or from. Also, I neglected the whole buffer thing. Best to initialize *one* of them to whatever pattern you want. Guess and test, I guess.

Last edited by Guest on 09 Dec 2008 07:07:23 pm; edited 1 time in total
Back to top
Display posts from previous:   
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» View previous topic :: View next topic  
Page 1 of 1 » All times are UTC - 5 Hours