| Author |
Message |
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
|
| Back to top |
|
|
Xphoenix
Elite
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 |
|
|
tifreak8x
Elite
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...  |
|
| Back to top |
|
|
Iambian
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 |
|
|
Iambian
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
http://i-lost-the-ga.me
Calc Guru
Joined: 14 Nov 2003
Posts: 1196
|
| Posted: 24 Jul 2007 12:06:36 pm Post subject: |
|
|
| wow look nice! |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 26 Jul 2007 02:51:11 pm Post subject: |
|
|
DJ Omnimaga wrote: wow look nice!
[post="110486"]<{POST_SNAPBACK}>[/post]
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 |
|
|
Steelersfan1693
Newbie
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)
http://dragonfire.unitedti.org/asmin28/lesson/toc.html |
|
| Back to top |
|
|
Iambian
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:
Code:
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:
Code:
c.Life:
.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 |
|
|
Harrierfalcon
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 |
|
|
Iambian
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).
[post="130117"]<{POST_SNAPBACK}>[/post]
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 |
|
|
|
Project Releases => Your Projects
