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.
Topics - Michael.3545
Pages: [1]
1
« on: August 18, 2014, 07:29:09 pm »
I'm looking to buy an Nspire, and of course I want to be able to run Ndless on it. If I get an Nspire with 3.9 but a pre-J hardware revision, will I still be able to downgrade it via the RS232 boot2 flashing method? I know this method used to work, but I haven't been able to find any information about if 3.9 has done anything further to block this. From what I know, I'd guess it'll still work, but I want to get a second opinion before I make a purchase. Thanks all!
2
« on: May 05, 2012, 10:19:39 pm »
When an axe program ends, it leaves anything you drew on the home screen. (Unless you clear it first, of course) I'd like to get this effect, only on the graph screen instead. For example, PrettyPrint leaves its output on the graph screen, and you can refer back to it later, or store it to a picture if you wish. Is this possible in Axe?
3
« on: October 30, 2010, 12:33:46 am »
On IRC today, we ended up talking about making games in PowerPoint. I just happened to have a really cool old math project on my Google docs, and DJ figured that the rest of you may be interested. It has a super secret surprise theme, don't spoil it!
Freakishly long link: https://docs.google.com/leaf?id=0B1AfyYYD6YT9MmI1OTljMTgtYWI0NC00ZWRiLTg5NGItNWRiNzNlN2JiNmEw&hl=en&authkey=CMj22fwE*Note that this is a PowerPoint file, I just stuck it inside a .exe file, because I am cool like that. I also have a couple of mazes I made, one with moving parts. If the above file goes down well I'll take the time to upload those too. If anyone else has a cool PowerPoint thing, please share it with us!
4
« on: October 28, 2010, 12:44:22 pm »
Yesterday, the adapter cable for USB8x came in the mail, and i was euphoric. I was able to use a mouse and keyboard to get input, but for some reason my flash drive would work with MSD8x. It simply says "Drive not responding to commands". This leads me to think that either the drive is not supported, or that I don't have enough power. If I run MSD8x a second time, it does the odd glitch where the app menu ends up with a cursor. I tested it with both a 2G and a 256M flash drives. I know the 2G one to be FAT16.
On a scale from 0 to 4, with 4 being new and 0 being poor, my batteries return a 4. (according to my battery checking program)
3 are Energizer and one are Duracell.
Testing with a voltmeter, all of the batteries are in the "good" zone, but one is bordering "good" and "?".
Any ideas?
5
« on: October 26, 2010, 06:49:08 pm »
Hello Omnimagicians, I seem to be having a bit of an issue. I am working on a pacman clone. The ghosts used to behave like this:  I finally added a method of controlling the ghost's movements, and instead of moving as expected, I got this:  This is the code I added: : .G-BRAIN
:..............
:
: .On tile
: !If {A}^7 or ({B}^7)
: L4+2?P
: 0?{L4}r
: 0?{P}
: If J
: J*?1?{L4}
: Else
: K*?1?{L4+1}
: End
:
:.stop indent
:
:.1 UP
:!If pxl-Test({A},{B}-1)r
:If {L4+1}??1
: 0?{{P}*2+L4+3}
: ?1?{{P}*2+L4+4}
: {P}+1?{P}
:End
:End
:
:.2 RIGHT
:!If pxl-Test({A}+7,{B})r
:If {L4}?1
: 1?{{P}*2+L4+3}
: 0?{{P}*2+L4+4)
: {P}+1?{P}
:End
:End
:
:.3 DOWN
:!If pxl-Test({A},{B}+7)r
:If {L4+1}?1
: 0?{{P}*2+L4+3}
: 1?{{P}*2+L4+4}
: {P}+1?{P}
:End
:End
:
:.4 LEFT
:!If pxl-Test({A}-1,{B})r
:If {L4}??1
: ?1?{{P}*2+L4+3}
: 0?{{P}*2+L4+4}
: {P}+1?{P}
:End
:End
:
:.resume indent
:
: {rand^{L4+2}*2+L4+3}?P
: {P}?iPart(U}
: {P+1}?iPart(V}
: sub(GGD)
: End
:
:..............I am using L4 as super temporary storage. It is used in one routine during my loop, and I write completely new data to it each time I use it, so volatility isn't an issue. I tested all of the things I wasn't sure about (such as using pxl-test() on an off-screen locaiton) and all of that sort of stuff works as expected. Here is what my variables do: - A,B: Pointers to where the ghosts x and y positions are saved. (1 byte each)
- J,K: Temporary variables, they store the ghost's x and y velocity.*
- U,V: Pointers to where the ghost's x an y velocity are stored. (1 nibble each)*
- P: A temporary variable I use to avoid repeating math I've already done.
Here is the structure of L4: - {L4},{L4+1}: the x and y velocity opposite to which a ghost is currently moving at.*
- {L4+3}: The number of x and y velocities stored in the next 6 bytes of ram
- {L4+4},{L4+5}: A possible x,y velocity*
- {L4+6},{L4+7}: same as above
- {L4+8},{L4+9}: same as above
* These values are either 1, 0, or -1.Thanks for your help! It is depressing that I couldn't figure it out myself. :'(
6
« on: October 18, 2010, 06:39:14 pm »
So, a while ago I was on ticalc.org, and I downloaded this file. I was impressed by the game, but there were some parts of it that I didn't like. I said to myself, "you should use Axe to make an awesome version of this." So I got started. The only thing left to do is add a control system for the ghosts. I have to say my favorite part is wrapping from one side to the other.  Well, that's what I have been up to recently. The source and executable can be found here: http://www.box.net/shared/q7n2g5avh1If anyone is interested in making levels, I can edit in some more information on that.
7
« on: July 02, 2010, 05:23:33 pm »
So. I suppose I need to introduce myself, as it isn't really official until I get my peanuts. I got my graphing calculator (an 84+) the summer before 9th grade, (2 years ago) as it was suggested to have one for Algebra 2. I remember thinking to myself, "d***, that's a lot of buttons." About halfway through the first semester, I read Appendix A in the manual, and made a Quadratic Formula program. Ever since then, I have been making programs to make my calculator do math for me. I tried learning assembly, but that is currently way too hard for me. When Axe came out, I finally had the chance to make more powerful programs without assembly. Invariably, I got stuck, and signed up here for help. Now I figure that Omnimaga is pretty cool, so I have added it to my spellcheck dictionary and decided to stay. The only thing I need to do now to achieve perfect happiness is get a working adapter so I can use MSD8x. And I just lost the game. 
8
« 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*
9
« on: June 24, 2010, 12:41:31 pm »
Axe is amazing. In fact, it is so amazing, that it made me sign up for a forum, an act which I am rarely caught doing. But to get down to the meat of the problem I am having, a password program I am working on has developed the uncanny ability to eat RAM. In fact, each time i get the password wrong, then right, it eats 572 bytes of RAM. I believe that this may have something to do with the assembly code I am using to give the program the ability to turn off the calculator.
This code is EF0850C9
which via the use of calcsys' hex editor and decompiler, I have discovered translates to:
bcall 5008
ret
After testing the code to see if it was the culprit, I learned that every time this code is ran, it eats 6 bytes of ram.
If you factor 572, you get 2, 2, 11 and 13. So no matter how many times you loop that code, you can't lose 572 bytes.
Oh, and I looked through all of the symbols and the VAT section of calcsys, and couldn't find anything that matched the size of my missing bytes. The have been eaten, I tell you!
Does anyone have any idea what could be causing this?
If you want, I could post the source, but it is 516 bytes large and I have no idea exactly what portions are related to the problem.
Pages: [1]
|
Show Posts