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 ... 88 89 [90] 91 92 ... 153
1336
« on: April 19, 2011, 10:28:10 pm »
Welcome! May I suggest introducing yourself so we can learn a little bit about you and all say hi? To answer your question, I believe you want the getKey(0) command. Normally, getKey(number) is used to check if a specific key corresponding to that key code is pressed. But if you enter a zero, it will instead check if any key is pressed. To create a loop that repeats as long as no key is pressed, I would suggest the following: While 1 .Endless loop...
EndIf getKey(0) .Until a key is pressed
1337
« on: April 19, 2011, 09:58:58 pm »
Although a ++ command could definitely be useful to intense optimizers like myself, I don't think the command should be added due to confusion it may cause. These are the two major sources of confusion I would foresee: - It's only an 8-bit math command, whereas every other math command is 16-bit. And unless the user knows the underlying machine code, I would imagine that they would think something as simple as addition of 1 could easily be performed on a 16-bit value.
- The result of the addition isn't returned in hl. {B+L1}+1 and {B+L1}++ would return an entirely different value, despite only having one slight difference in the mathematical operator that comes after what would appear to be a value fetch. In my mind, this is by far the stronger reason of the two as to why this operator could cause confusion.
1338
« on: April 19, 2011, 07:55:05 pm »
After some testing, it appears to me that application sending issues might have something to do with USB linking. Sending Pokemon to both 2.43 and 2.53MP over USB failed, while sending it over a silver link cable succeeded. It's strange that this problem doesn't happen with any of the apps produced by the old version of TI-Boy, but hopefully someone who knows more about USB linking can look into this.
If you get an error like the one below, try sending the application over a serial link cable instead if you have one.
And can people who have received errors like this when sending confirm that their errors happened over USB protocol so I know I'm not just making this USB thing up? And if you have a serial cable, can you confirm that sending the same application over that works?
1339
« on: April 19, 2011, 05:18:23 pm »
I have a bug for 0.5.1: I made a sprite routine and sometimes there are random lines appearing. I'll post the thing where it happens later.
Hmm... I'm going to call this 50% my fault, 50% Quigibo's fault.  I provided Quigibo with an optimized portion for the Pt-Mask() routine for Axe 0.5.1. But because I was only providing a small portion of it, I didn't worry about its context. But it just so happens that the portion I provided for him was the very last part of the routine, so we managed to lose the final return for the routine somewhere along the way. So here's why you're seeing the artifacts in your program. When aligned masked sprites are drawn (x mod 8 = 0), instead of the masked sprite routine returning at the end, code execution proceeds to whatever happens to be after it. And in the case of your program, the next routine is the Pt-On() routine. But because it just has garbage inputs that are whatever carried over from the end of the Pt-Mask(), you get garbage sprites drawn to the screen. As for a fix, you have two options. The first is to downgrade to Axe 0.5.0, but I have a better idea. The second option is to add the final return onto the end of the masked sprite routine yourself! What you'll want to do is open RPGSPRIT and add the return manually like this: Pt-Mask((A*8)+r₁,(B*8)+r₂,Pic1MB+(32*A)+(16*B)+(64*r₃)+(256*r₄)
[C9]
Pt-On((A*8)+r₁,(B*8)+r₂,Pic1SG+(16*A)+(8*B)+(32*r₃)+(128*r₄))ʳ
1340
« on: April 18, 2011, 11:02:08 am »
If you want to examine the source code for Axe routines, I suggest looking at the Commands.inc file found in the Developers folder of Axe releases. That file lists the source for every Axe command available. However, it may be difficult to determine which commands correspond to which routines, as they aren't named according to their Axe tokens. To determine which routines correspond to which Axe tokens, you may want to look at this. It lists technical details about every routine in Commands.inc, including which Axe tokens they correspond to. So to find the ClrDraw routine, you would search my file for "ClrDraw" to find the routine it corresponds to, and then search Commands.inc for the routine name you just found to find the code for the routine. EDIT: Oops, forgot to actually answer your questions: - ClrDraw: B_CALL(_GrBufClr)
- Fix 5: set 7,(iy+20)
- Fix 4: res 7,(iy+20)
1341
« on: April 18, 2011, 02:55:38 am »
Good news: After some testing with Zelda: Link's Awakening, the new TI-Boy runs anywhere from 20-60 percent faster than the old TI-Boy!  Bad news: I can't successfully send Pokemon Blue to my calculator.  The old TI-Boy Pokemon sends fine, so it isn't a size issue. And leafiness0 is experiencing the same problem, so it isn't just me. I have OS 2.53MP and he has OS 2.55MP.
1342
« on: April 17, 2011, 09:56:06 pm »
A note: the in f,(c) opcode is undocumented. If you use it, you don't have to worry about the grayscale looking bad on the Nspire's screen, because this opcode will straight-up fail on it.
1343
« on: April 16, 2011, 05:46:06 pm »
If you look at $0028, and follow the code from there, you'll see that the OS swaps out the Flash page that your application is on with a page that has the OS routines. Then, when the routines are finished executing, it swaps the page back.
'Fraid it's not that easy. Remember that you can create your own B_CALL routines for Multi-page applications
I'm pretty sure it is that easy.  And what do you mean by creating your own B_CALL routines? The B_CALLs are the OS routines, so anything you have in your app isn't a B_CALL, and you can't use the B_CALL macro to call a routine in the app of your choice.
1344
« on: April 14, 2011, 08:23:25 pm »
1345
« on: April 14, 2011, 04:21:55 pm »
The capacitors that hold the bits of data in RAM don't perfectly hold a charge, so they must periodically be "refreshed." During each refresh, any capacitors that are holding charge are topped up and any capacitors that are not are left empty.
1346
« on: April 11, 2011, 06:10:04 pm »
The percent symbol's character value is 25 in hexadecimal, but you're inputting it as a decimal value. So instead of displaying character 25h, it's really displaying character 17h, which is the less than or equal to symbol on the calculator. You want to use Disp ᴇ25►Dec. The ᴇ before the number signifies that it's a hexadecimal value.
1347
« on: April 11, 2011, 06:00:34 pm »
Optimized. Sorry, I just had to. It's a pretty epic optimization, though.
1348
« on: April 11, 2011, 04:30:01 pm »
You can define a token to be an immediate value load by making the full code ld hl,constant, but that's about as close as you're going to get to constants. When used in an expression it won't have any special constant optimizations, it will just be treated like a value in parentheses.
1349
« on: April 10, 2011, 07:28:55 pm »
I just want to sort of bump up this post from a short while back. A bunch of people have been debating how to get a "hard return" function working and I don't know if they missed this post I made 2 pages ago. It details both how a programmer could manually add this functionality and how the command could be built-in to Axe. Because the OS return location is dug into the stack at an unknown depth, you cannot access it. The solution to this is to backup the OS return location at the start of your program when you know that it is the topmost stack entry. I would suggest using code like the following:
.MYPROG
Asm(ED73E383) .Back up the OS return location
.YOUR PROGRAM GOES HERE
Asm(ED7BE383ED56C9) .Exit program from anywhere, put this wherever you want it
EDIT: Quigibo, perhaps you could add a Returnr function for this? I could be wrong, but I believe I see a very easy way to handle this. If a Returnr is detected in the first pass, set a flag to say so, but otherwise parse the Returnr command and the rest of the pass as normal. Before starting the second pass but after the header has been added, check this flag. If it isn't set, resume as normal. If it is set, add the 4-byte stack pointer backup code to the beginning of the program and then step through every static pointer, increasing them by 4. The rest of the program should then be able to be parsed normally.
1350
« on: April 10, 2011, 01:30:15 pm »
Scout, that would not work. The problem has to do with the state of the stack when hitting a Return. If you're in a subroutine, the return address to actually exit the program, and not just return from the subroutine, is somewhere hidden in the stack. When your program is just starting up, the stack will look something like this:
OS return location
Stuff
...
But when you're in a subroutine, the stack will look something like this:
Subroutine return location
Possibly more subroutine return locations
...
OS return location
Stuff
...
Because the OS return location is dug into the stack at an unknown depth, you cannot access it. The solution to this is to backup the OS return location at the start of your program when you know that it is the topmost stack entry. I would suggest using code like the following:
.MYPROG
Asm(ED73E383) .Back up the OS return location
.YOUR PROGRAM GOES HERE
Asm(ED7BE383ED56C9) .Exit program from anywhere, put this wherever you want it
EDIT: Quigibo, perhaps you could add a Returnr function for this? I could be wrong, but I believe I see a very easy way to handle this. If a Returnr is detected in the first pass, set a flag to say so, but otherwise parse the Returnr command and the rest of the pass as normal. Before starting the second pass but after the header has been added, check this flag. If it isn't set, resume as normal. If it is set, add the 4-byte stack pointer backup code to the beginning of the program and then step through every static pointer, increasing them by 4. The rest of the program should then be able to be parsed normally.
Pages: 1 ... 88 89 [90] 91 92 ... 153
|
Show Posts