This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Michael.3545
61
« on: June 25, 2010, 08:07:21 pm »
While I was drawing out my ideas, much to my surprise I found that squaring a complex number (integers only  ) is relatively easy to do with a four-column array. @Quigibo Is this 10 minute grapher available for download anywhere?
62
« on: June 25, 2010, 07:28:05 pm »
very large numbers? if you have a complex number c = a + bi, as soon as sqrt(a^2 + b^2) > 2, you know its unbounded. it's a very nice property about the mandelbrot set that makes computing a lot faster. if the magnitude of the complex number has not exceeded 2 after your max_iters, then you assume it's a part of the set.
Well, that takes care of the large numbers, but I am still at a loss of how to implement sub-integer numbers with the current version. Can anyone think of a way of doing this with expanded values?
63
« on: June 25, 2010, 06:48:55 pm »
55) The key that causes the most loss of data is located directly adjacent to the arrow keys keys. (see 34)
56) A maximum of 10 saved image files would be supported, without 3rd party software modification.
57) The only internet connection possible would be via telnet.
58) The Login Dialog can be permanently disabled by temporarily removing the power source.
59) Cleaning the keyboard requires removal of the computer's power supply and motherboard.
64
« on: June 25, 2010, 06:19:02 pm »
Last year, I made a program in TI BASIC to graph the Mandelbrot set. There was already one out there, but I wanted to make my own as a kind of educational challenge to myself. (Woah, that sounds so nerdy, but you guys can probably relate)
Well, it worked. But it takes 30 minutes to graph. I'm not ready to learn assembly at this point, so until Axe came out I resigned myself to half-hour waits. But now, my new project is to make a fast, axe Mandelbrot set grapher. The plan is the have it display the time a BASIC program would take, and then the (hopefully significantly shorter) time the axe program will take. It would be a great way of showing the difference between the speeds of Axe and BASIC. If it is fast enough, I could even throw in a grayscale layer at a higher iteration for visual effect.
The problem, is that the Mandelbrot set is tiny. It only reaches from -2 to about .6 on the real axis, and -.8 to .8 on the imaginary axis. Checking the points would require numbers with decimals, and a method of multiplying them together.
To check a complex number c to see if it lies in the Mandelbrot set, you follow this pattern.
c , c^2 + c , (c^2 + c)^2 +c , [(c^2 + c)^2 +c]^2 + c ... and so on. If c is unbounded, it is not in the Mandelbrot set. The easiest way to check this is to see if c's real and imaginary parts are less than a very large number. Now the program requires support for very small numbers and very large numbers!
Is devising a system for handling decimals even possible? TI did it, but does anyone know how? (their method may not be plausible for an assembly program anyway) If only axe's variables could store decimals... *sigh*
65
« on: June 25, 2010, 05:18:29 pm »
As all of you stated above, the C9 on the end was the issue. I figured this out myself last night before I went to bed. Actually, it was keeping me up. I thought to myself, "What if ret is the same as Return?" I took off the C9, and bazinga! After turning back on, the code resumed where it had left off. After a slight modification of my program, (eliminated the appvar and added a big ol' loop) it worked beautifully. So all of the people who were talking about the C9 above were right. In conclusion, C9's are bad to have at the end of your Asm( tags in Axe. Quigibo, perhaps this would be a worthy addition to the Asm( portion of the commands list? And if anyone wants the working source code, I will post that here as soon as I unlock uploads at 20 posts. The 8 digit password can be easily changed in the source code if you use the keycodes.png file included with axe.
66
« on: June 24, 2010, 06:58:16 pm »
It would remain an 8xp file, it is the contents of the file that changes.
67
« on: June 24, 2010, 06:00:09 pm »
Well, when you turn back on again from the new asm code, the startup application doesn't launch. Any suggestions? Perhaps there is a way to make the program start itself without the app?
(self-starting programs *shudder* what's next, a calculator virus? skynet8x?)
68
« on: June 24, 2010, 03:06:08 pm »
That new code (the long one) doesn't resume where I left off, but it also seems to not eat RAM, so I will test it out.
EDIT: The new code now works just like the old one (returns to home screen on power-on) , only without the RAM-eating side effect. Thanks everyone, it seems that this case is closed.
69
« on: June 24, 2010, 02:46:30 pm »
Ah, so is there one that pauses processing and turns off the LCD screen? Like a standby mode in windows?
70
« on: June 24, 2010, 02:37:20 pm »
@ACagliano ...when the calc is turned off using asm within a program, when the calc is turned back on, it resumes from the line it left off...
My code doesn't do this. I tried: Disp "HI"
Asm(EF0850C9)
Pause 1000
Disp "HI2"
And I received the output of HI on the home screen after turning the calculator back on. @Runner112 | EF0850 | = | bcall 5008 | | C9 | = | ret |
Why is the longer one so much longer?
71
« on: June 24, 2010, 02:18:59 pm »
@souvik1997
It doesn't seem to mind, and it works as it should.
@ACagliano
prgmPWD is 584 bytes, so subtract out whatever header stuff and your probably do get 572. Now it all makes sense. Is there any way to work around this problem? If only I could exit the program and then do the bcall.
EDIT: Now that I think of it, there MUST be some way of doing this, as other password protection Apps and Programs don't have this problem. Oh, and where in memory do the copied programs go? I can't seem to find them with calcsys.
72
« on: June 24, 2010, 01:40:31 pm »
Sorry, I guess I assumed you had clicked on my link and somehow come to the conclusion that it wasn't the source. Next time I will just use http://sc.cemetech.net to avoid all this confusion and get all of the information in one place.
73
« on: June 24, 2010, 01:37:22 pm »
@_player1537 Ah, so THAT is what that link was for. @LordConiupiter Here is a description of what the program does. It is safe to run, it doesn't clear your ram. It just eats it.  It is meant to be ran using the startup app. .SET UP APPVAR checks to see if the appvar already exists, if not, it creates a new one. The apvar stores how many tries you have left before the program locks down. .LOCKDOWN MODE if you get the password (which is 1 2 3 4 5 6 7 8 currently) wrong three times, the next time the program is ran you must press [2ND] [MODE] and [DEL] simultaneously within 3 seconds to reset your remaining tries to 3. .SET PASSWORD is where I store the correct password into GDB1 .GET INPUT Gets input and stores it to L1 .CHECK INPUT compares L1 to GDB1 .CORRECT exits the program normally, giving you acess to the home screen .INCORRECT Turns the program off, causing it to be started again next time you turn the calculator. (remember the startup app)
74
« on: June 24, 2010, 01:25:25 pm »
I did post the source. That 8xp file is the source code. It has not been axed yet.
And why would I put ...SRC in an assembled program?
75
« on: June 24, 2010, 01:17:23 pm »
Ah, I see. 5 posts. And I lied, it is an 8xp file, but I edited it so it is right now. And there isn't any output from the compiler, it compiles fine. Running the program itself eats the RAM somehow.
|
Show Posts