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 ... 39 40 [41] 42 43 ... 153
601
« on: May 18, 2013, 06:38:42 pm »
The line after For(VAR,START,END) will hold the value of END-VAR for the current iteration. You can use this to optimize if you'd like, just keep in mind that this could potentially change in the future.
I can't say I've seen optimizations involving the use of this value... I have, however, made many optimizations using For(CONST), as this doesn't even affect HL. But be wary that For(VAR/EXPR) will load VAR/EXPR into HL at the start of the first iteration, but not after that.
602
« on: May 13, 2013, 04:02:41 pm »
I assume the swap sector was originally used to retain compatibility with 83+ and 48KB RAM 84+ calculators. It's possible that the extra RAM, if available, could be used instead of the swap sector. But coding that capability would consume code space that I don't really have to give right now to address this relatively niche compatibility problem. I'll keep it in mind down the road, though.
603
« on: May 13, 2013, 03:53:38 pm »
No, it's always needed. Axe uses the swap sector to store data while compiling.
604
« on: May 13, 2013, 03:27:34 pm »
Axe uses neither of those. My money's on the flash unlock as the issue. And there isn't really any way around a hacky flash unlock as far as I can tell; the OS tries to stop you from unlocking flash, so you have to abuse things.
605
« on: May 13, 2013, 03:23:17 pm »
Chances are the emulator doesn't properly emulate the flash unlock or some other fancy stuff Axe needs. TI's 84+ emulator for the Nspire isn't very good. You would have to ask Runer112. Quigibo intended to keep Axe Nspire compatible before but I am unsure if Runer112 continued that route.
The compiled programs themselves are compatible. But with how complicated the compiling process has become, I'm not sure that compatibility can be retained for the application itself. But I'll keep it in mind.
606
« on: May 13, 2013, 01:15:33 pm »
A strong suggestion: only use Axe fusion for testing your own programs, and not for programs you distribute to others. It's really underbaked and I've just barely been keeping it working in the latest Axe releases. I will likely remove it entirely eventually in favor of replacing it with a better, more robust system.
EDIT: And to clarify, the purpose of Axe Fusion was to result in smaller compiled programs. It was not intended to increase either compiling or execution speed.
607
« on: May 11, 2013, 04:27:52 pm »
You are correct; the bug does indeed exist, and it's because I made a stupid! It appears that I optimized string data parsing a little too aggressively in 1.2.0, but I've fixed it now and the fix will be in the next release of Axe. If you would like a workaround in the meantime, you can replace "Pic2" with [07600100].
608
« on: May 11, 2013, 12:14:01 pm »
I have no idea what that would be happening... If the source file is archived, I would first suggest unarchiving and rearchiving it; Axe occasionally has issues with archived source files, but this usually fixes it. If compiling it still results in the same error, can you post the full source code (in its original 8xp form in case there's some weird token data issues)? And/or if you're using Axe 1.2.1 (which I hope you are!), can you press STAT when the error occurs and relay that hexadecimal error dump info?
609
« on: May 11, 2013, 01:33:59 am »
It seems to work fine for me. Could you provide the code context for which this doesn't work for you? Ideally this would be the source code, but if that cannot be shared, the compiled code would likely suffice. Or if you can recreate the problem in a small program designed to trigger this issue, sharing that would work as well.
610
« on: May 10, 2013, 03:54:40 pm »
I can't turn my calculator into a Gameboy by making Pokémon run on startup?  So why couldn't you just scrap the old methods and appvars for the new? I don't think any really important data would be lost if you had to delete the existing settings appvar, the user would just have to take a minute or two to review their settings. Possibly a good idea anyways to have users review it all, with new features.
611
« on: May 09, 2013, 05:59:11 pm »
Oh yeah, I guess applications could explain his support of lowercase letters, which completely didn't register with me when I read his post originally. But applications can actually have all sorts of characters in their names; I think just about any defined character is fair game. I know most applications only use the characters he listed, but certainly not all of them. If he wants to support applications, he should really toss out the bit-packing altogether.
612
« on: May 09, 2013, 05:16:11 pm »
I don't actually need this feature myself, but a user asked in a topic on Cemetech how to disable APD. Perhaps disabling APD is a feature that would fit well into zStart?
That should be pretty easy. I can do that at the same time I do lowercase.
And hopefully it'll be an option? I found a bug today. You can't set a program with theta in it's name to run on RAM clear/turn on/zStart quit/on + num. In the zStart GUI, the theta shows up as U and this prevents the program from being found and run.
I forgot about theta, I have to admit though that I don't think this is a fixable problem. When I store the names of programs, I compress them to 6 bits per character. If you account for lower case, upper case, and numbers, that leaves me with 2 extra characters. I gave one of those to space and the other to zero (actual zero, not ascii 0). So, I hate to say it, but you'll probably just have to rename whatever you want to use.
What's space for?
613
« on: May 09, 2013, 03:23:25 pm »
I don't actually need this feature myself, but a user asked in a topic on Cemetech how to disable APD. Perhaps disabling APD is a feature that would fit well into zStart?
614
« on: May 06, 2013, 03:15:28 pm »
As far as I can understand, you want to create a program with the name stored in the OS variable Str4 and the contents stored in the OS variable Str1? If so, here's what I've come up with. I made two different versions: one is larger and allows you to handle each error that could occur individually, while the other is smaller and doesn't support error handling (errors are still caught and avoided, they just cannot be acted upon). The source for both versions is included as text below and as programs attached at the bottom of this post.
With error handling:
!If GetCalc("Str1")→S
.Str1 not found
Else
!If GetCalc("Str4")→N
.Str4 not found
Else
.L₁ can be replaced with any section of safe RAM at least 9 bytes large
'prgm'→{L₁}ʳ
Fill(L₁+1,8)
Copy(N,L₁+1,{N-2}ʳ)
!If GetCalc(L₁,{S-2}ʳ→L)→P
.Creation error
Else
Copy(S,P,L)
End
End
End
Without error handling:
If GetCalc("Str4")→N
.L₁ can be replaced with any section of safe RAM at least 9 bytes large
'prgm'→{L₁}ʳ
Fill(L₁+1,8)
Copy(N,L₁+1,{N-2}ʳ)
If GetCalc("Str1")→S
Copy(S,GetCalc(L₁,{S-2}ʳ→L),L)
End
End
615
« on: May 01, 2013, 05:21:44 pm »
I would advise fully reading through the Documentation.pdf file included in Axe releases, for starters. It's far from a total guidebook, but it covers a lot of the basics and walks through code examples for common tasks.
Pages: 1 ... 39 40 [41] 42 43 ... 153
|
Show Posts