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 ... 44 45 [46] 47 48 ... 153
676
« on: February 21, 2013, 04:19:15 pm »
What's a foolproof (and preferably not exceedingly large) method to determine the first free application page on an 83+ or 84+? Importantly, such a method also needs to determine if there are no free application pages left.
677
« on: February 21, 2013, 03:58:14 pm »
Commands in Axioms can be marked to be inserted inline. Anyways there isn't really a reason why you should want to include a raw assembly program directly into an Axe program, because a proper assembly program should have things like a header and could have absolute jumps and calls and such.
678
« on: February 21, 2013, 01:48:07 pm »
Matrefeytontias, what model is your calculator? That might help me debug your app compiling issue. Now that I think of it, I probably should've put that information in the dump...
As for crashing on exit in MirageOS, the only other thing that comes to mind is that you could have problems if you're using a custom interrupt and not disabling it properly before quitting. If you are using a custom interrupt, make sure you properly disable it using LnRegr. If this doesn't fix it, let me know and I'll go ahead getting my hands dirty trying to debug it myself.
679
« on: February 21, 2013, 11:31:40 am »
You can't perform writeback to applications. You'll probably need to move whatever that data is to static RAM somewhere to be able to modify it during execution if you're going to proceed with your project as an application.
As for crashing MirageOS, does Axe give you a warning about the program being too large? If so, that's definitely the issue, and you should either convert it to an application or use Fullrene. If not, does the program crash when MirageOS launches it, randomly during execution, or when your program exits? If it's the first one, then that's definitely some weird MirageOS bug that I'm not sure would be avoidable. If it's either of the latter two, it might be due to you using L2, which MirageOS uses. If you do use L2 and it crashes during program execution, try adding LnReg to the initialization code. If you use L2 and it crashes when your program exits, try adding ClrDraw(L2) to the cleanup code.
680
« on: February 18, 2013, 01:52:27 pm »
It would be nice if you could import a binary file as inline assembly. This would allow easier use of Mimas.
Really the proper thing to do would be to make an Axiom.  But I'll look into it.
681
« on: February 15, 2013, 11:29:47 pm »
I am not sure if I had an outdated source (1.1.2) but I saw this code and a one -byte optimisation
You do have an outdated version of Axe, I already added that optimizaion in 1.2.0. I'm not so sure that would work, because there's a possible case where you could be running code from an app and finding the Nth string in a large appvar in RAM, for example (which could be more than 16KB in size).
Pfft what are the chances of that...
682
« on: February 14, 2013, 03:02:36 pm »
All four sound channels are supported. Listen closely.
683
« on: February 12, 2013, 11:06:11 am »
A sign(foo) command that returns -1 if foo is less than 0, 1 if greater, and 0 if equal. And perhaps sign(foo,bar), which would compare it to bar instead of 0. And while I'm on the topic, perhaps sign()r could be the 8bit version?
Also, I know it'd have to be named something other than sign(), because there's already a sign{}, but I don't know what to call it.
You know, you can build a pretty optimized sign routine in pure Axe. In fact... I don't think it's even think it's possible to produce a more optimized sign routine for Axe using assembly. Lbl Sign
Return!If
Return //32768*2+1
As for the other variations, the compare seems that it's a little specific and could easily just be thrown into the sign routine above like Sign(foo-bar) anyways. As for the 8-bit sign function, you should really always be working with 16-bit signed values in Axe because every signed operator expects them. There are a few operators for which you can get away with not sign-extending 8-bit signed values, such as +, -, and *. But for using other operations, it's a good idea to sign-extend any 8-bit signed numbers using sign{} when loading them from memory.
about axe being thight on space, I understand that it can give problems for some people if axe would exceed the size of about 16kb,
but it wouldn't be a problem to me and I would find it a bit sad if axe couldn't expand only for that reason,
so would it be practically possible to add 2 axe versions in the zip file, a lite and a pro version of axe,
where one has a low size and the other has all kind of possible features?
Axe has already exceeded 16kb (1 flash page); it's currently just about filling 32kb (2 pages). Right now the first page is more or less entirely code and the second page is more or less entirely data. The next step up would be 48kb (3 pages), but really the size increase itself isn't the issue. More of an issue is that there would then be code split across pages. Producing and maintaining assembly code that spans multiple pages introduces a lot more complexity over code that fits on one page. And Axe is already fairly complicated, so for now I'd like to keep it restricted to 32kb so my head doesn't explode. I think I can still add a fair amount of code/features, I just need to optimize existing code to the max as I add new code.
I wonder what's the use of Z-addressing ...
I used z-addressing with a bit of assembly in this Axe program I made for a mini competition a while ago. The screenshot demonstrates that this game quickly becomes a bit of an insane use of z-addressing, but it definitely showcases the potential power of it by "shifting" what would otherwise be a simple tunnel game at nauseating speeds with no program speed loss.
684
« on: February 11, 2013, 02:16:41 pm »
So I was looking for an official ruling by DJ_O or Juju in this thread but didn't really find one (the synthesized voice Juju posted doesn't really make it clear). What is the official pronunciation? It seems like the first syllable could be either "om" as in om nom or "ohm" like electrical resistance, and the third syllable could be either "ma" like someone might call their mom or "may."
EDIT: I guess I assumed the g belonged to the fourth syllable, that might be wrong as well.
685
« on: February 11, 2013, 01:40:18 pm »
two request :
-a Zadd() command, for change the z-adress (I know axiom can do it, but I prefer an axe command)
-an rect command who can draw in buffer and back buffer in same time (if possible )
Hmm, perhaps I'll add the z-addressing command. It certainly isn't difficult to implement. As for drawing shapes to multiple buffers... I'll think about it.
686
« on: February 08, 2013, 12:34:53 pm »
First thought that comes to mind: that is not Minecraft. It irks me quite a bit when people name their projects after well-known and well-received games that they strive to emulate, but (no offense to the author) are so incredibly far from doing. Perhaps what irks me even more is that this usually results in artificially boosted popularity and games like this become more sought after than a game that's legitimately detailed and polished and fun.
687
« on: February 05, 2013, 04:12:34 pm »
I got it!
42: 42*1+666*0
666: 42*0+666*1
688
« on: February 03, 2013, 03:06:59 pm »
I've got 3 issues:
- at some random momments axe will throw up an invalid token error when trying to compile an app from which the source is in archive. I've done some tests, and I think that it keeps throwing that error if you don't change anything, but if you unarchive it, it works perfectly, but even unarchiving and rearchiving sometimes seems to solve the problem.
- for some reason my multiplayer game (with 2 calculators) can't make connections between 2 calculaters. I check whatever the other calculator is waiting, if so, start the game, else, start a loop where you keep checking whatever the other calculator has already started this game. Now, the loops just start at both calculators, which shouldn't appear. I didn't use the port variable, since I don't really understand what it does. I've tried to make connection between a TI84+ silver edition with the latest os (2.55) and a normal ti84+ with the same os, and I use the ports to the right.
- it seems that at the latest os, the input function has a slight difference when in MATHPRINT or in CLASSIC modus: in MATHPRINT, it doesn't clear the screen before execution, while it does in the other modus. this isn't an important issue though.
- Invalid token errors: Wait a little bit.
 - Linking issues: I would suggest making a separate topic about this in the Axe Programming Help Board and posting the code you're using for linking. Linking is always a tricky topic, so I can't be sure if the issue is in your code or in Axe's code. But posting the code you're using should hopefully result in either situation being solved promptly.
- input quirks: input has always been a very strange command. Because it's more or less entirely handled by the OS, it's tricky to make sure it works how we want it to instead of how the OS wants it to. Due to this and other reasons (like the fact that it returns a string of tokens rather than characters), it's never really fit quite right into the Axe language and has just sort of had the feeling of being slapped on (which it was). So honestly I'm not too interested in fixing quirks like this. The command works for quick and dirty input, but for text input in programs that you want to distribute, I would advise writing your own input routine. You can usually make it look and function much better for your needs, anyways.
689
« on: February 03, 2013, 02:53:37 pm »
I've got another 2 requests:
- making an option so that you can easily make screenshots of your game, I can't find any other way besides using emulators.
- the syntax +→ and -→ to add/substract an expression to/from a variable or position in memmory pointed to.
For making screenshots, an emulator will always be by far the best and easiest way to go. If you really wanted to make screenshots on the calculator itself, shmibs took the words right out of my mouth. You'd then just have to transfer any picture variables to a computer and convert them from 8xi format to a standard image format, like gif; SoureCoder would be an easy way to do this. I've sort of had the idea of augmented assignment operators in the back of my head, but never put serious thought into implementing it. Partially because I'm not sure I feel comfortable trying to add operators like this, and partially because Axe is already really tight on space. However I have to say that I really like your syntax suggestion for it, so if I ever get around to figuring out how to implement it, I'll probably use that. 
690
« on: February 02, 2013, 08:08:03 pm »
Can you put a null terminator at the end of every word/string unit (like was just recently brought up here and here)? If each small piece ended in a null byte, then you could display each one just like a normal string, given the pointer to its start. If speed is not of huge importance, you would also then have the option of using stdDev() to get the pointer to individual strings given their index in the "list" of strings. Not sure if that would make it easier or harder for you, but you would have the option.
Pages: 1 ... 44 45 [46] 47 48 ... 153
|
Show Posts