#126517 - jdogalt - Tue Apr 24, 2007 1:06 am
I may just be misreading code, but can someone (wintermute?) tell me why in
libnds/source/common/biosCalls.s
that swiSleep is defined using swi 0x07?
It seems to me from reading the specs at neimod.com/dstek that swiSleep should be implemented as a cut and paste of how swiSwitchToGBAMode is implemented, but replacing the #0x40 with #0xC0. (i.e. using swi 0x1F).
What confuses me even more, is the comments which read-
// swiSleep (swi 0x07)
// Same as swiSetHaltCR(0xC0)
// swiSwitchToGBAMode (not a SWI)
// Same as swiSetHaltCR(0x40)
// swiSetHaltCR (swi 0x1F)
// Writes a byte of the data to 0x04000301:8
I don't know where to begin. Lets start with the "not a SWI" on swiSwitchToGBAMode, which from my reading of the code, absolutely is an swi 0x1F. And then from there and the various reading of the code I can't see how swiSleep is different from swiSwitchToGBAMode. And given the neimod.com/dstek specs, they would appear to me to be very similar sorts of things.
Now then, just to give some context and hope that I can get some help with my real problems... What I'm trying to accomplish is to write a pager application for the NDS that is as efficient as possible. So far, without using the above sleep (regardless of whether or not it is already implemented correctly), I can achieve 16 hours of battery life, doing an intrWait(arm9) for 10 seconds on the timers, and waking up and doing maybe 0.1 seconds of grabbing wifi packets.
However, given my testing of the Nintendogs pictochat search mode, I believe it should be possible to nearly double that. I.e. I saw at least 28 hours of battery life in that mode. (where it is doing more or less what I want- polling wifi while in as deep a sleep as possible, and alerting the user if an interesting network condition occurs)
Now, if someone wants to actually reverse engineer the nintendogs code to find out what its actually doing- well, I'd be seriously grateful. But thats a bit more involved than I am currently skilled and wanting to go to.
Basically my plan now is to replace my intrWait, with swiSleep (as is, or I'll try reimplementing myself as a copy of the switchtogbamode_with_0xC0 since that seems like what it should be). Does anybody happen to know if there is something wrong with that strategy? Also, the neimod.com/dstek spec was vague about the arm9 going into low power mode, sort of suggesting it would happen automatically when the arm7 goes to deep sleep.
One other thought is- is it possible to run just on the arm7, and effectively leave the arm9 off? At one point I thought I ran across something suggesting that the arm9 was what needed to control the vibration motor in my supercard-lite-microsd-rumble. So I'm thinking that may not be really possible.
Anyway, if anyone has actually bothered to read this far, I bet you have some insight that will help me. Please reply :)
Thanks,
(I did search the forum for swiSleep and found one interesting thread with code. I'm certainly not at the point that I'm stuck and have nothing to try, but I'm hoping some guru out there might save me the trouble of going down a few more non-optimal or outright wrong paths).
-dmc/jdog
libnds/source/common/biosCalls.s
that swiSleep is defined using swi 0x07?
It seems to me from reading the specs at neimod.com/dstek that swiSleep should be implemented as a cut and paste of how swiSwitchToGBAMode is implemented, but replacing the #0x40 with #0xC0. (i.e. using swi 0x1F).
What confuses me even more, is the comments which read-
// swiSleep (swi 0x07)
// Same as swiSetHaltCR(0xC0)
// swiSwitchToGBAMode (not a SWI)
// Same as swiSetHaltCR(0x40)
// swiSetHaltCR (swi 0x1F)
// Writes a byte of the data to 0x04000301:8
I don't know where to begin. Lets start with the "not a SWI" on swiSwitchToGBAMode, which from my reading of the code, absolutely is an swi 0x1F. And then from there and the various reading of the code I can't see how swiSleep is different from swiSwitchToGBAMode. And given the neimod.com/dstek specs, they would appear to me to be very similar sorts of things.
Now then, just to give some context and hope that I can get some help with my real problems... What I'm trying to accomplish is to write a pager application for the NDS that is as efficient as possible. So far, without using the above sleep (regardless of whether or not it is already implemented correctly), I can achieve 16 hours of battery life, doing an intrWait(arm9) for 10 seconds on the timers, and waking up and doing maybe 0.1 seconds of grabbing wifi packets.
However, given my testing of the Nintendogs pictochat search mode, I believe it should be possible to nearly double that. I.e. I saw at least 28 hours of battery life in that mode. (where it is doing more or less what I want- polling wifi while in as deep a sleep as possible, and alerting the user if an interesting network condition occurs)
Now, if someone wants to actually reverse engineer the nintendogs code to find out what its actually doing- well, I'd be seriously grateful. But thats a bit more involved than I am currently skilled and wanting to go to.
Basically my plan now is to replace my intrWait, with swiSleep (as is, or I'll try reimplementing myself as a copy of the switchtogbamode_with_0xC0 since that seems like what it should be). Does anybody happen to know if there is something wrong with that strategy? Also, the neimod.com/dstek spec was vague about the arm9 going into low power mode, sort of suggesting it would happen automatically when the arm7 goes to deep sleep.
One other thought is- is it possible to run just on the arm7, and effectively leave the arm9 off? At one point I thought I ran across something suggesting that the arm9 was what needed to control the vibration motor in my supercard-lite-microsd-rumble. So I'm thinking that may not be really possible.
Anyway, if anyone has actually bothered to read this far, I bet you have some insight that will help me. Please reply :)
Thanks,
(I did search the forum for swiSleep and found one interesting thread with code. I'm certainly not at the point that I'm stuck and have nothing to try, but I'm hoping some guru out there might save me the trouble of going down a few more non-optimal or outright wrong paths).
-dmc/jdog