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 - Jerros
Pages: 1 2 3 [4] 5 6 ... 10
46
« on: October 11, 2010, 01:34:13 pm »
I'll look through it. Basically what I would do is run it in wabbitemu and place a breakpoint at $0038. $0038 is where the calculator goes when an interrupt happens, so if you follow the interrupt through, it will point you back to the location of the hidden EI.
I'll send you a PM tomorrow then, if it's not too much trouble for you. Thank you.
47
« on: October 11, 2010, 07:03:50 am »
Perhaps you could post the source, that way we could see what is really happening.
The loop is over 600 lines, and that's without the calls and jumps outside of the loop, so I don't think I can bother anyone with that. :O If you REALLY wan't me to post it, I will, but it would take way to long for someone to look through it, only to find that I'm making some nooby mistake that could've easely been fixed without all that efford... So basically, as long as I don't know that turns interrupts back on, I'd have to put di's everywhere at random? (hehe...) Rather than doing that, is there a concrete list with command that turn interrupts back on? That way I can go over things myself without bothering anyone. Thanks for the replies all!
48
« on: October 11, 2010, 06:58:03 am »
Actually, a call Label2 equivalent would look like this:
Label1:
ld hl,ReturnLabel
push hl
jp Label2
ReturnLabel:
It won't be returning to Label1, it will return to the point after the call.
Thanks thanks thanks!  I'll try this as soon as possible. ^_^
49
« on: October 10, 2010, 01:27:29 pm »
I unfortunately cannot help due to lack of ASM knowledge but one thing to be careful with when using direct input is to make sure to either add a delay between key detections or get rid of key repeat by checking if the user has released the key you pressed before continuing further in the program. Also make sure there's a small delay before checking if people released the key, so it gets detected at all. Not sure how long the delay would be in ASM, though. Otherwise, what happens is that in your game menus, options will be chosen way too fast and it will be impossible to accurately navigate through menus due to key detection being too sensitive. In-game it can also pose problem if your game has everything moving tile-by-tile. An example of this problem would be the first version of Splut, which was submitted to the contest.
I had that problem before already, but luckely Quigibo had a perfect solution for that: http://ourl.ca/6459/105146So direct input would defenitely be an option. Although I'm still unsure of how to completely disable the ON button. Like other here have said - completely disabeling it would force the use of direct input, which I'm fine with. So, how to disable it? I'm not good enough (yet) to understand what the kind people post here. ;P
50
« on: October 10, 2010, 12:32:38 pm »
POP HL \ ret should work, Jerros. Maybe the fault is elsewhere? Do you mind posting the code fragment involved?
I'll just try again. The code fragment considered is BIG (over 600 lines + lots of calls and stuff) so I dont want to bother you with that ^_^. To give more detail of what I'm trying: Label1:
(...)
CALL Label2
(...) ; <-- must get executed after the RET*
Label2:
(...)
CALL label3
(...) ; <-- A normal Ret in Label 3 will cause this to be executed. I don't want that :P.
ret
Label3:
b_call _GetCSC
CP skDel
JP Z, Quit
JR Label3
Quit:
ret ; and I want this RET* to go to Label1, NOT 2.
It's obvious that I should use a JP under "Quit" to go to where I want in Label1, though I have my reasons for it to MUST be a "ret"... Err...
ret \ ret would pop pc twice, but the first time you pop pc, the next line will not execute, because PC will be elsewhere. Pop is not exclusive to variables, they are all on the stack together. For instance:
push hl
push bc
pop hl
pop bcThis will swap the values of hl and bc. Therefore, if (9D95:) call xxxx pushes PC to the stack and loads xxxx into pc, the stack looks like this:
9D95
Then, if you pop hl, you can no longer return to that location unless you push it back. Look at this:
Label1:
push Label1
jr Label2This is the equivalent of call Label2, just with more bytes.
Wow! Thanks, I get it now Though I can't experiment anymore today, I'll post as soon as I know more.
51
« on: October 10, 2010, 11:48:41 am »
ret IS pop pc.
pop hl pops hl.
But... I want to pop PC twice with one Ret command... Or at least do 2 pops and THEN peform the next line of code. I suck at making myself clear. Q_Q
52
« on: October 10, 2010, 10:27:05 am »
That looks like it will work at first glance, but I don't konw why it isn't. This is how calls work:
I don't know why it isn't either, haha. Try this as a completely new program:
Code:
Label1:
push Label2
ret
Label2:
ret
This should exit the program because you are pushing the location of Label2 onto the stack, and then returning to it. Not sure, though. If that doesn't work, just push two zeros onto the stack, and run it with a ret. That should reset your calc, so beware.
But does label 2 get executed now? Doesn't look like it... ret // 4. This does the equivalent of POP PC (PC now equals 9D97)
So... isn't it possible to do POP PC then? Because POP HL just pops... HL, not PC right? It doesn't seem to work though...
53
« on: October 10, 2010, 08:40:41 am »
Yeah, iirc, the last address is stored on the stack. Try a pop into hl and then go to that address.
Ehrm, as in: Label1:
Call Label2
(...)
Label2:
Call Label3
ret ; <-- isn't neccarery, since it will nver get executed, right?
Label3:
POP HL
ret ;<-- will go to label 1?
^That? EDIT: Doesn't work. I'm more braindead than you can imagine - could you elaborate what you meant with: Try a pop into hl and then go to that address.
Thanks for the reply!
54
« on: October 10, 2010, 07:55:06 am »
I've stumbled across another problem - how would I do a "double" ret command? Let me explain: Label1:
call label2
ret ; Let's call this one "ret%" This will go to where I want!
Label2
ret ; I want this "ret" to go to the same 'place' as "ret%".
Or, to make things more general: Label1:
Call Label2
(......) ;[1]
Label2:
Call Label3
ret ;[2] Will take it back to [1].
Label3:
Call Label4
ret ;[3] Will take it back to [2].
Label4:
Call Label5
ret ;[4] Will take it back to [3].
Label5:
ret ;[5] Will take it back to [4].
In the latter example, I want the ret from [5] not to go back to [4], but, lets say, to [1]. Is it possible to set things up in such way that a "ret" command will do that? I don't know the specifics, but the addres from which you use "Call" from gets stored in a stack, right? So would it be possible to "Pop" that stack, so that a "ret" will take it back more than one 'step'? From what I've read, "POP PC" would do that. Though I've tried that and then my assembles gives an error, so I guess things aren't that simple. Thank you!
55
« on: October 10, 2010, 02:36:05 am »
if you just put a DI after each bcall, your problem would go away and GetCSC should still work.
Thanks, I'll try that. It isn't sacret though that GetCSC must work, it's always possible to use the direct-output thing (I got a script for that already somewhere, I believe ). EDIT: Nope, this didn't work. Spamming on will still result in a slowdown. I'll be trying some of the other suggestions. EDITEDIT: Nothing I've tried with DI worked so far, spamming on will still slow the lot down. It's a BIG loop, with loads of calls, jumps, sprites checking and drawing and moving and other stuff (but just 1 b_call iirc). Putting the DI as the first line of the loop does nothing, and I've put it before and after the B_call and at some random places just to be sure, but ON will still blow the lot. Also, you're all saying that GetCSC will stop working, but even this still works: DI
b_call _GetCSC
DI
CP skButton
JP Z, Label
Which proves that I have no idea what I'm talking about...
56
« on: October 09, 2010, 01:43:57 pm »
You could send that byte every pass of the loop, I guess.
The problem with disabling only the ON interrupts through port (3) is that the ON key is only disabled for .01 second. This is because as soon as the next Ti interrupt fires, it will turn them right back on.
Is this info contradictive, or don't I understand it? If it will only turn ON off for .01 sec, then just sending that once per loop won't be enough, right? As for the DI instriction, that seems like a good way, though all I have to do is replace GetCSC with a directly-into-port routine? Or would it be nesaccery to do DI after every B_Call, since: typically routines like bcall(_clrLCDFull) have an ei at the end of them.
Or perhaps do this? : EI
B_Call(_GetCSC)
cp SKwhatever
JP Z, Randomness
DI
But thanks, I'll mess around a bit tomorrow and see what works and what not. (though I've gotten a very scary error message on my calc last week - never seen that one before... Maybe the trail-and-error way of working might have it's downsides after all. ^_^).
57
« on: October 09, 2010, 06:39:00 am »
Perhaps a simpler solution might be to just disable the ON key interrupt, which is controlled by bit 0 of port 3. Outputting 00001010 to port 3 should disable the NEXT ACTIVATION of the ON key interrupt while keeping other interrupts enabled. You'd need to find some way to constantly deactivate it though, I believe.
Which would be that di instruction, okay thank you. Now I've just got to figure out how "di" exactly works and what it does, but that's what the interwebs is for. ^_^
58
« on: October 09, 2010, 02:51:40 am »
The obvious way to fix this problem is to just disable interrupts. A simple di somewhere in your loop should take care of this. But now you have to watch out because TI likes to use interrupts. Bcalls that draw to the screen tend to turn the interrupts back on, so just be careful there. Also, bcall(_GetCSC) relies on interrupts to function, so you are going to have to use direct key input with port (01).
What's a "di" somewhere in the loop? And replacing the GetCSC with direct key output.... That'd invlove making a piece of script that would only let it react ONCE when a button is pressed down, right? Else the calc would react as if you were spamming the buttons, but I guess I can do that. Could you elaborate on that "di" thing please?
59
« on: October 08, 2010, 01:08:54 pm »
I'm making a game in which timing is cricial. You need to press a certain button when a sprite is in a specific area. However, I have found that spamming the "ON" button significantly slows the programm down, and thus makes things much easier. I don't exactly know why spamming the "ON" button results in a slowdown (has to do something with interupts?), but I want it to go away.  How'd I do this? And how would that affect the programm, since from what I've read the "ON" button is pretty special, and I have no idea how this will affect things. Thanks in advance!
60
« on: October 03, 2010, 04:29:33 am »
Or World of Warcraft, the previous version was: V3.3.5.12340
And thank you for the link, ExtendeD.
Although it still seems that the significance of the change is just something one randomly decides, it's not set in stone.
Thanks!
Pages: 1 2 3 [4] 5 6 ... 10
|
Show Posts