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 - calcdude84se
Pages: 1 ... 79 80 [81] 82 83 ... 161
1201
« on: September 25, 2010, 12:43:34 pm »
*BUMP* For future reference, maybe someone could write the interrupt code? (Not me, as I seem to be confused by Axe interrupts )
1202
« on: September 25, 2010, 11:18:14 am »
Nice! Far from complete, definitely, but keep up the good work!
1203
« on: September 25, 2010, 11:04:47 am »
Do you use TI-Connect? I got an insufficient memory error before, when sending a 49 KB APP, even thought I had 95 KB free.
Because of how the OS uses flash memory, this isn't abnormal, though it is annoying. (Apps and programs/appvars/etc. cannot share a sector) And somewhere around here is a program to test if you have 128KB or 48KB of RAM... * calcdude goes and findsEdit: Found it. http://www.omnimaga.org/index.php?action=dlattach;topic=1129.0;attach=2134Directions: I made another one It's designed to be run from the homescreen with Asm( If you have XRAM, the program will return, saying nothing. If you don't, it'll say FAILED, and then return.
1204
« on: September 20, 2010, 10:37:37 pm »
Cool! Pass by reference will be less useful than say, in C, because our largest data structures are two bytes Keep up the good work, can't wait to try it!
1205
« on: September 20, 2010, 09:16:18 pm »
Maybe we could have a getKey(#) r that uses the delay appropriate for 15MHz mode? And yeah, it is annoying
1206
« on: September 20, 2010, 09:13:18 pm »
Well apparently the buffer where the input string is stored is not a temporary variable so a bcall to _CleanAll doesn't clear it. I will have to find the name of that string. The buffer for the input is named "-" and I've seen a "#" and "$" so I'm guessing it's something similar to that.
There isn't a way to fix the memory leaks since this is an OS call.
As you are probably aware, there is a leak-free (or less so) version of _GetKey, undocumented and called _GetKeyRetOff I wonder if something similar exists for the input bcall... Good luck making it work!
1207
« on: September 20, 2010, 09:07:16 pm »
That would be very confusing. _player1357: Sadly, no. It's mainly ideas, though those are very close to being finalized and the fun stuff should start happening soon Edit: Oh, and thank you for the multitude of peanuts
1208
« on: September 19, 2010, 03:48:26 pm »
So it is. My bad, I had misread something earlier. But my main point is still valid
1209
« on: September 19, 2010, 03:35:35 pm »
I'm not sure, it might have been. At any rate I'm bumping it
1210
« on: September 19, 2010, 03:01:54 pm »
Looks cool! I've even played that game before.
1211
« on: September 19, 2010, 02:52:42 pm »
Not to mention apps are signed differently (not with RSA but with some other method) In the end, though, it's still slow.
1212
« on: September 19, 2010, 02:46:32 pm »
input acts funnily... prgmBASIC [code=BASIC]Input "THE GAME: ",A prgmAXE when compiled
input Running these two programs in the order given, My screen will look like this: prgmBASIC THE GAME: 1337 Done Asm(prgmAXE THE GAME: In addition, pressing 2nd+Quit will quit the program, causing memory leaks, and it may be the same for 2nd+Off (haven't tried yet)[/code] Edit: Weird formatting errors. Can't fix.
1213
« on: September 19, 2010, 02:42:52 pm »
1214
« on: September 19, 2010, 02:37:54 pm »
No, apps are signed with the 0104 key, OS's with 05 and 0A (for 83+(SE) and 84+(SE), respectively)
1215
« on: September 19, 2010, 02:35:50 pm »
Supposing the appvar is called "appvCHECKSUM"
Return!If GetCalc("appvCHECKSUM",2)->X sub(C)->{X}r Note that this example doesn't check if the appvar already exists, and assumes subroutine C as above. And again, the process takes a couple seconds.
Pages: 1 ... 79 80 [81] 82 83 ... 161
|