#154621 - Lazy1 - Sat Apr 19, 2008 9:11 am
While I've been re-porting sdl-sopwith I have noticed that exit() is used almost everywhere.
Since the DS has no OS to exit to this is a big problem.
Ideally I would like to keep the original source base in tact and only modify code specific to the DS.
Aside from the exit() issue the port is almost ready and even has working (slightly buggy) PSG sound and TCP/IP netplay :D
The sound is also tricky since the SDL port just emulated the PC speaker where I just send the current frequency to the PSG.
This causes problems when the program turns off and on the speaker causing clicks and delays.
Not sure how to handle that one without modifying the main sources though.
#154623 - simonjhall - Sat Apr 19, 2008 11:50 am
You could always use the atexit (?) function to define a callback when exit gets called? You could either while(1) it in there, or use one of the reboot libraries to do something more flash.
No idea about the sound thing though - I've never used the psg!
_________________
Big thanks to everyone who donated for Quake2
#154628 - silent_code - Sat Apr 19, 2008 2:04 pm
this may be obsolete to you, but do you wait the required amount of milliseconds after enabling sound? i can't think of anything else right now.
good luck and happy coding! :^D
#154643 - Lazy1 - Sat Apr 19, 2008 7:28 pm
| silent_code wrote: |
this may be obsolete to you, but do you wait the required amount of milliseconds after enabling sound? i can't think of anything else right now.
good luck and happy coding! :^D |
I guess I don't but would that really cause the problem?
| simonjhall wrote: |
You could always use the atexit (?) function to define a callback when exit gets called? You could either while(1) it in there, or use one of the reboot libraries to do something more flash.
|
But isn't there a way to restart the application without having to reload it?
Also, is atexit() called before or after the crt shutdown code (if there is any)?
#154646 - silent_code - Sat Apr 19, 2008 8:08 pm
gbatek:
Power control
When restoring power supply to the sound circuit, do not output any sound during the first 15 milliseconds.
i say: who knows? probably not all of them, altough it might be - i don't know. depends on what "turns off and on the speaker" means in terms of how it's done. ;^)
good luck!
#154655 - Cydrak - Sat Apr 19, 2008 10:47 pm
| silent_code wrote: |
| this may be obsolete to you, but do you wait the required amount of milliseconds after enabling sound? |
This doesn't apply to the PSG registers, it's for powering the whole sound engine itself. For example, when I came out of sleep-mode, I used to get "stuck notes" in my music. As if it was too groggy to see any register writes, for a frame or so. :)
| Lazy1 wrote: |
| But isn't there a way to restart the application without having to reload it? |
Restarting is "halfway" possible, but I seem to remember some unpleasant side-effects. Such as certain globals not being reset, since they were initialized by the compiler... needless to say, code is not so well-behaved after that. >_>
While something like this could be properly arranged--DTCM data has to be be copied at runtime after all--, I don't think it's supported at the moment. (Someone correct me if I'm wrong.)
#154658 - Lazy1 - Sun Apr 20, 2008 12:33 am
What I might do for the sound is just throw the PC speaker emulation on the arm7, that should solve the stop/start problem as well as sound closer to the original.
Only thing is that it uses floats in a lot of places so I'm not sure if it'll be fast enough there.
I made a few attempts to convert the code PC side to fixed-point with the latest attempt sounding "closer" but eventually crashing :D
Maybe I still just can't wrap my head around it.
As for restarting the game there is a restart function to reset the game but the problem is that registering my atexit() function is not enough, something breaks along the way.
Now...
My old hack was really sick which added -Uexit -Dexit=NDSExitHack to the CFLAGS and simply called the game's restart function.
I'm not sure how well that would work since exit() is expected to never return.
#154660 - wintermute - Sun Apr 20, 2008 1:07 am
Restarting an application without reloading is not possible.
exit() is something I may look at again in the future, I'm making use of this in devkitPPC to return to the boot loader. This is slightly more problematic on the DS, especially given the vast array of devices available to boot homebrew code.
There's a pretty big argument for supporting only a limited subset of homebrew devices, I'm not really sure how well the general userbase would take to that though.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#154740 - dantheman - Mon Apr 21, 2008 3:26 am
| wintermute wrote: |
| There's a pretty big argument for supporting only a limited subset of homebrew devices, I'm not really sure how well the general userbase would take to that though. |
Given how quickly DLDI took off after it opened up the world of homebrew to more users, I'm rather skeptical myself.
#154917 - nutki - Tue Apr 22, 2008 11:01 pm
| wintermute wrote: |
exit() is something I may look at again in the future, I'm making use of this in devkitPPC to return to the boot loader. This is slightly more problematic on the DS, especially given the vast array of devices available to boot homebrew code.
There's a pretty big argument for supporting only a limited subset of homebrew devices, I'm not really sure how well the general userbase would take to that though. |
How about adding device dependent exit procedure as part of DLDI calls? This would move DLDI directly to toolchain while now it is a libfat thing, but has great advantage of being able to support future hardware without recompiling existing applications. Also possibly move some work from devkitARM maintainers to third parties.
I proposed changes to DLDI inteface also in 'Why does some homebrew demand root installation?' thread. Adding more DLDI features at once (not necessarily the ones I came up with) would help promoting new verion.
#154920 - Lazy1 - Tue Apr 22, 2008 11:15 pm
| nutki wrote: |
How about adding device dependent exit procedure as part of DLDI calls? |
Isn't DLDI arm9 only?
If I remember correctly restarting requires the help of the arm7 too.
#154924 - nutki - Tue Apr 22, 2008 11:47 pm
| Lazy1 wrote: |
Isn't DLDI arm9 only?
If I remember correctly restarting requires the help of the arm7 too. |
I was not aware of that. However DLDI is just a set of functions and is located in memory area accessible by both CPUs as far I know. Things would get complicated (but still doable) if exit procedure would be something more than call arm9_exit() then arm7_exit() or differ between devices.
#154949 - HyperHacker - Wed Apr 23, 2008 5:54 am
| Lazy1 wrote: |
My old hack was really sick which added -Uexit -Dexit=NDSExitHack to the CFLAGS and simply called the game's restart function.
I'm not sure how well that would work since exit() is expected to never return. |
To be honest I'd just use this (or atexit() if it works) and make the function print something like "Program terminated" and loop forever (or power off). exit() is supposed to end the process, this seems like the next best thing.
When I used exit() on the DS (a library I was using called it) it just showed the standard exception screen, which makes sense (though I'm not sure it was intentional). Returning to the loader would be better, but if that's not possible (due to having to get both CPUs involved), just showing the exception screen with a "Program terminated" or "exit() called" message seems like the next best idea.
With the plan to implement a standard ARM7 binary and use the FIFO, though, I think the best idea is to define a message in libNDS that gets sent to the other CPU when exit() is called, signaling it to enter the return-to-loader routine. For those who are using custom ARM7 binaries, there'd be some way to change the value of the message (#define it before including nds.h or something) so it doesn't collide with their own message protocol. (I.e. make the message 0xDEADBEEF or something by default, but if you're already using 0xDEADBEEF for something and it's infeasible to change it, you can re-define the message to some other value.)
The real problem would be the return-to-loader code itself. Could we stick this in the DLDI patches? Using some reserved field or magic word to find the function body within the DLDI section?
_________________
I'm a PSP hacker now, but I still <3 DS.
#154976 - silent_code - Wed Apr 23, 2008 2:55 pm
"It's now safe to turn off your (computer) NDS."
anyone? ;^)
it's also possible (as others have already pointed out) to shut the system down. (via the power register or what ever it is called [where you can turn off background lighting and stuff])
#155011 - tepples - Wed Apr 23, 2008 10:26 pm
| silent_code wrote: |
| it's also possible (as others have already pointed out) to shut the system down. (via the power register or what ever it is called [where you can turn off background lighting and stuff]) |
Yeah, that's what memtestARM and RAC do, with appropriately in-character remarks. It even appears to be recommended, given that three applications in the firmware do the same thing.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#155036 - simonjhall - Thu Apr 24, 2008 7:48 am
And I can vouch for tepples' shutdown code in memtestARM as I pinched it for Q2! (ta mate)
_________________
Big thanks to everyone who donated for Quake2