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 - Runer112
Pages: 1 ... 122 123 [124] 125 126 ... 153
1846
« on: October 25, 2010, 11:47:48 pm »
I don't know if this has been requested, but 32 bit math would be awesome.
It would. It would also require Quigibo to completely rewrite every math routine and auto-optimization for a 32-bit mode, as well as needing to create ways to interweave it with the normal 16-bit mode, both on the compiled program side and the parser side. It would be a long and difficult undertaking, and although it would be awesome, I think its sheer difficulty makes it a low priority. An 8-bit mode has been requested too, and even though that would undoubtedly be a good deal simpler and easier to code, that's still the kind of thing Quigibo doesn't imagine implementing until the far future, like Axe 2.0.
1847
« on: October 25, 2010, 10:51:55 pm »
You, getting caught using an older version of Axe?  Lol Anyways you should check out my approximately over 9000 feature requests. 
1848
« on: October 25, 2010, 09:50:25 pm »
Runer, I can't replicate that effect, it just throws a BAD SYMBOL at the 'o' for me as I would expect. What version are you using?
0.4.5 Hold on, let me try to get a screenshot. EDIT: Made a screenshot illustrating the problem. The compiled size of 19 bytes indicates 16 bytes of header/VAT data and 3 bytes for "C".
1849
« on: October 25, 2010, 09:46:21 pm »
Ahh, Quigibo! Did you read my epic on the last page? Also, a new request for TI Program Editor users like me (although I'm probably the only one lol). When saving 8xp files, if a lowercase letter represents something special (u, v, w are equation variables and a, b, c, d, e, n, p, r, s, t, z are statistics variables), TI Program Editor parses these as these special tokens and not lowercase letters. Due to this, they turn into garbage when parsed inside strings by Axe. Could you make these tokens be parsed as the lowercase letters they actually represent?
1850
« on: October 25, 2010, 09:17:42 pm »
In SourceCoder, I believe that if you type Copy, it recognize it as conj, so such thing may not happen in SourceCoder.
The test I just did with SourceCoder disagrees with this. That would prevent you from typing the literal string "Copy" and SourceCoder isn't designed to be an Axe source editor anyways.
1851
« on: October 25, 2010, 09:04:22 pm »
I'm not sure if this is a bug, intentional, or what, but something interesting I just discovered: lowercase letters not in a string act like a period and turn the rest of the line into a comment. I don't see much of a use to this, but I found out when I was trying to optimize a program by changing a Fill() command to Copy(). The size savings when I did were much larger than I expected, so I was questioning how that was possible with the change I just made. I was using the TI Program Editor bundled with older versions of TI Connect to write the program, and I realized that I had literally written "Copy(" when the actual command was "conj(" which would explain some things. But I found it odd that it actually parsed successfully, treating the first "C" as the variable C and ignoring the rest of the line.
That's TI-Connect-side, right?
What would be TI-Conncect-side? It doesn't matter where the source came from, lowercase letters are parsed like periods.
1852
« on: October 25, 2010, 06:45:51 pm »
I'm not sure if this is a bug, intentional, or what, but something interesting I just discovered: lowercase letters not in a string act like a period and turn the rest of the line into a comment. I don't see much of a use to this, but I found out when I was trying to optimize a program by changing a Fill() command to Copy(). The size savings when I did were much larger than I expected, so I was questioning how that was possible with the change I just made. I was using the TI Program Editor bundled with older versions of TI Connect to write the program, and I realized that I had literally written "Copy(" when the actual command was "conj(" which would explain some things. But I found it odd that it actually parsed successfully, treating the first "C" as the variable C and ignoring the rest of the line.
1853
« on: October 24, 2010, 10:04:37 pm »
This is designed to combine multiple non-assembly programs into one. The reason I say non-assembly is because it should work for any programs that can be edited in the program editor, such as BASIC programs or Axe source code. It copies all the lines in the specified programs into one large program, adding new lines between the end and start of programs as necessary.
1854
« on: October 24, 2010, 12:13:23 pm »
Hex display, definitely  Either ▸Rect or ▸Polar would work.
And this:
Not that important, but a length()r would come in handy for me.
Would that search backwards from a pointer? I think that could be useful. 
If you urgently need a routine for that, you could do it with the following assembly: Asm(AF474FEDB921FFFFED42)Just put the pointer value right before that.
1855
« on: October 24, 2010, 12:00:22 pm »
No, they are the pointers to the operating stack and the floating point stack. All free RAM is located between these two structures, so subtracting the pointers to them makes sense that it would give you the amount of free RAM.
1856
« on: October 24, 2010, 07:59:03 am »
oooh, transformer un numero pour une chaine:
:{0,1→L₁
:{0,N→L₂
:LinReg(ax+b) Y₁
:Equ►String(Y₁,Str1
:sub(Str1,1,length(Str1)-3→Str1 This is indeed the way to convert a number into a string, and this code should work. Are you sure you entered it correctly?
1857
« on: October 24, 2010, 06:54:54 am »
Enjoy. All the information should be in the source file. I slaved over this for many an hour. Tell me if it works fine for you. I tested it and it seems to work. If you need the input style changed I can change it for you. ..AXE LIBRARY: MERGE
.<DESCRIPTION>
.This routine will merge multiple BASIC programs listed in an OS string into one program
.Author: Runer112
.Date: 10/24/10
.Insert style: Inline
.Parser version designed for: 0.4.5
.Size as of version 0.4.5: 342 bytes
.<INPUTS>
.Str0M1: Name of OS string containing program names
.Example format of data in OS string: "prgmPRGMNAMEprgmAprgmTEST"
.Str0M2: Output program name
.<OUTPUTS>
.Returns: 0 if failed, non-0 otherwise
.A program, the name of which is determined by Str0M2
.<DESTROYS>
.Last 24 bytes of saveSScreen (last 24 bytes of L₁ as of 10/24/10)
.<ROUTINE>
.Temporary program name storage (last 10 bytes of saveSScreen)
ᴇ05→{ᴇ89EC-10}r
Fill(ᴇ89EC-9,8)
.{ᴇ89EC-12}r = merge loop iteration/pointer to merged program, {ᴇ89EC-14}r = total length of merged program in first iteration, current position in merged program in second iteration
0→{ᴇ89EC-12}r→{ᴇ89EC-14}r
.Merge loop
Lbl 0ML
.Check that OS string exists, {ᴇ89EC-16}r = pointer to string, {ᴇ89EC-18}r = current position in string
If GetCalc(Str0M1)→{ᴇ89EC-16}r→{ᴇ89EC-18}r
.Repeat while position is not outside of string
While sub(0MC)
.{ᴇ89EC-20}r = current offset in temporary program name
0→{ᴇ89EC-20}r
.Repeat until current token = prgm (0x5F)
While {{{ᴇ89EC-18}r+1→{ᴇ89EC-18}r}→{{ᴇ89EC-20}r+1→{ᴇ89EC-20}r+ᴇ89EC-10}}-ᴇ5F
.If position is outside of string
!If sub(0MC)
.Break
Goto 0MD
End
End
.Done copying name
Lbl 0MD
.Replace last byte with 0
0→{{ᴇ89EC-20}r+ᴇ89EC-10}r
.Check that program to copy exists, {ᴇ89EC-20}r = pointer to program, {ᴇ89EC-22}r = length of program
If {GetCalc(ᴇ89EC-10)→{ᴇ89EC-20}r-2}r→{ᴇ89EC-22}r
.If second iteration
If {ᴇ89EC-12}r
.Copy program to merged program
conj({ᴇ89EC-20}r,{ᴇ89EC-14}r,{ᴇ89EC-22}r)
.If not last program to copy, {ᴇ89EC-24}r = backup of length of merged program
If {ᴇ89EC-12}r+{ᴇ89EC-24}r-sub(0MM)
.Append new line token
ᴇ3F→{sub(0MM)-1}
End
End
.Add length of current program (plus 1 for a new line token) to length of merged program
sub(0MM)→{ᴇ89EC-14}r
End
End
.If first iteration
!If {ᴇ89EC-12}r
.Attempt to create merged program and increase iteration count
!If GetCalc(Str0M2,{ᴇ89EC-14}r→{ᴇ89EC-24}r-1)→{ᴇ89EC-12}r→{ᴇ89EC-14}r→{ᴇ89EC-12}r
.Program creation failed, go to end
Goto 0ME
End
Goto 0ML
End
End
.Go to end
Goto 0ME
.Merge position check
Lbl 0MC
{{ᴇ89EC-16}r-2}r+{ᴇ89EC-16}r-{ᴇ89EC-18}r
Return
.Merge math
Lbl 0MM
{ᴇ89EC-14}r+{ᴇ89EC-22}r+1
Return
.Merge end
Lbl 0ME
1858
« on: October 24, 2010, 01:56:18 am »
This. EDIT: Wow, really? Thumbing me down for jokingly pointing out a bug in Chrome? Maybe the omnimaga community is worse than I had thought...EDIT 2: Well it seems that my comment was poorly worded and off-topic, so it wasn't taken well. Which I guess is my fault. I won't delete my previous edit so others can see it if they like, but it's my rash overreaction to my poor attempt at humor being negatively received. I don't hate the omnimaga community... I'm not neutral towards the omnimaga community... I don't like the omnimaga community... I love the omnimaga community. It's the site I spend the majority of my time online at, it's the site I spend the majority of my time reading, and it's the site I spend the majority of my time producing content for. If omnimaga disappeared I don't know what I would ever do, because it has become a core facet of my life. And I'm sorry for ever having said otherwise. I'm not sure what else to write, I think that's about it. Sorry.
1859
« on: October 24, 2010, 12:14:27 am »
I knew there was a way of finding it, and looking at that post I actually remember seeing it before. Thanks for finding it for me.
1860
« on: October 23, 2010, 10:49:33 pm »
I may be mistaken, but is there not a byte pair in RAM in which the OS keeps the amount of free RAM? If there is, where in RAM is this located, and how often is this value updated? If not, I'll just use MemChk, but this seems easier.
Pages: 1 ... 122 123 [124] 125 126 ... 153
|
Show Posts