#158729 - silent_code - Mon Jun 16, 2008 9:42 pm
Hi there!
As I have finally started to use libfat myself very recently, I am wondering why some homebrew does not load directly through the cards firmware loader (I use an M3 Real), but does perfectly when started via DS Organize?
The problem is, that it's not all HB. My own ROM works fine (I only have the VSD using libfat right now...), as do others, like Quake DS and of course DSO itself! I'm just wondering how I can ommit that to happen in my own implementations?
Let's take StillAliveDS for example. It's a really nice game and plays pretty well, saving, loading, everything works. But only, when loaded through DSO!
Why is that?
Another example: A music program, whose last version worked perfectly, now has the same problem... Although the card uses auto-patching, so the DLDI "driver" can't be the primary problem.
I wonder what file systems these programs use? Is it pure libfat?
Then another question: How can I make my ROM directory independent? Right now, it (and all data files) has to be in the root to work, which is "not cool." Any suggestions? Is there a manufacturer independent way?
Thanks a lot in advance. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#158740 - tepples - Tue Jun 17, 2008 12:05 am
| silent_code wrote: |
| Then another question: How can I make my ROM directory independent? Right now, it (and all data files) has to be in the root to work, which is "not cool." Any suggestions? |
One technique developed as a de facto standard: install all your program's data inside "/data/myprogram/". Another is to wait for all homebrew launchers to support "argv", but that won't happen any time soon because DSO is no longer maintained. A third is to search the card for your data files using the diropen() family of functions, but that takes a while.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#158756 - Lynx - Tue Jun 17, 2008 3:32 pm
I thought one of the reasons was that different launchers setup the hardware differently. On the Games N Music, for example, it apparently does a poor job of setting up the hardware prior to launching the homebrew. DSO does a much better job and is why it can pretty much launch any homebrew. By forcing the GnM to boot strait to DSO, it allows DSO to setup the hardware before the GnM can mess it up.
_________________
NDS Homebrew Roms & Reviews
#158757 - Sektor - Tue Jun 17, 2008 3:53 pm
Some launchers don't load the arm7 correctly if the homebrew has a WMB banner. I know the M3 Perfect had two methods for launching homebrew (A or start) and only one of them could load homebrew with a WMB banner.
_________________
GTAMP.com/DS
#158758 - silent_code - Tue Jun 17, 2008 5:28 pm
But again, why would an older version of a program boot with no problems and the newer not? (And the author doesn't know why!) Might this be due to an update in libfat? Then, why are other programs working well with the same libfat version?
I bet it's neither libfat, nor the loaders (although, speaking in general, they *do* cause bugs in some cases.) Is it maybe the way those programs are set up / they set up the HW? Then, what's wrong?
I wish, I could take a look at the sources, but both programs I have the problem with are closed source. But, if I'm not completely getting off course, one of them (StillAliveDS) uses EFS (or the like.) Though, I'm quite sure the other one doesn't... :^/
I am so confused! 8^\
The only seems to be one way to get to know more details: Ask the authors. I'll test my luck an see what I can find out.
About the other topic:
I originally planned to use /data/*, but as I wanted to provide emulator support via FCSR and the fat-image creation program would not work with sub folders (I always get an error, see below), I had to go with "all in the root."
The output I get from the program is:
| Quote: |
Builds a FAT disk image from a given directory.
454053
Creating image
creating FAT12 image size = 0.45 MB's
Working[.]DoneInjectFile("root\data\vsd_data\test.tga") failed
Blessing image
OK - start1:0 size1:0
"FAT12 image built as fat.img from /root" |
But I figured, that I could use two folders: If loading from /data/* doesn't succeed, try to load from the root. I think, I'll implement that. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#158770 - t4ils - Tue Jun 17, 2008 7:50 pm
| Quote: |
| How can I make my ROM directory independent? Right now, it (and all data files) has to be in the root to work, which is "not cool." Any suggestions? Is there a manufacturer independent way? |
My suggestion :
I start my homebrew by looking for the game directories on the card. If not found, i create them at the root, but you can move them later :)
StillAliveDS don't need to be put at the root of the card, you can place files anywhere you want ;)
e.g. : /homebrews/puzzleGame/StillAliveDS
Then, this is what i'm using in stillaliveds :
devkitpro r21
EFSLib V2 (and fatlib of course)
Wifilib
ASLib
the game is created with PALib community update (the latest build)
#158772 - silent_code - Tue Jun 17, 2008 8:28 pm
@ t4ils:
Thanks for the input! :^)
Do you have any idea what could cause the loading problem?
I'm aware of the fact, that it (at least to my knowledge) doesn't happen on other cards, so, I assume this is a multiple factors problem...
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#158777 - t4ils - Tue Jun 17, 2008 9:05 pm
I received an email stating that ...
| Quote: |
M3/G6 Homebrew Loader
As the M3 and G6 firmwares turn off the power to the 2D cores before running a program, homebrew which does not remember to turn the power on does not run on these flash carts.
Homebrew authors can ensure M3/G6 compatibility by adding "powerON(POWER_ALL_2D|POWER_SWAP_LCDS);".
|
First, "POWER_SWAP_LCDS" swap screens, so I can't put it in my code
maybe I can swap them again right after the powerON
secondly, I'm already making powerON in my homebrew (powerOn(POWER_ALL)
so I don't know if it's the solution
#158779 - silent_code - Tue Jun 17, 2008 9:29 pm
POWER_SWAP_LCDS is optional.
I don't use it either and I only power up what's needed, still, my programs run flawlessly on the M3. :^/
Good try, though!
PS: If you use lcdMainOnTop() (or bottom), you can ensure your display setup is correct.
I don't know, but may it have something to do with PAlib?
Other PAlib users: any simmilar experiences?
The other software doesn't use PAlib, though. It's not causing the problem. :^/
At this point, I can only offer to help with debugging. I think I could hunt down the cause of the problem, if given access to sources, that exhibit that bug.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#158793 - Sweater Fish Deluxe - Tue Jun 17, 2008 11:53 pm
I'm sure I've read somewhere that there is a problem loading EFSlib homebrews on the M3/G6 Real, so that's probably what you're running into. I don't know the exact source of the problem, but maybe Noda has some idea.
| t4ils wrote: |
| Quote: | | How can I make my ROM directory independent? Right now, it (and all data files) has to be in the root to work, which is "not cool." Any suggestions? Is there a manufacturer independent way? |
My suggestion :
I start my homebrew by looking for the game directories on the card. If not found, i create them at the root, but you can move them later :) |
I think this is a great solution since argv won't be implemented any time soon in the default loaders most flash cards use, however I definitely think throwing up a splash screen or even a loading screen before doing the search is a good idea so that users know the game has loaded correctly. Depending on how the card is layed out, the search can take 2 or 3 or more seconds. If there's nothing to show that the game has loaded during that time, your average antsy ADD flash cart gamer will often think the game isn't working at all and turn it off and then come to you asking why the game isn't working on their card.
EFSlib makes a similar search when you init it (at least the first time it's run), so you'd want to put up some graphics before initing EFS as well.
...word is bondage...
#158794 - silent_code - Wed Jun 18, 2008 12:04 am
| Sweater Fish Deluxe wrote: |
| your average antsy ADD flash cart gamer |
Not funny. :^\
But you are right, at least the console should be initialized and some text printed... unless the problem happens even before control is handed over to your program (e.g. "before" main()). :^(
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#158881 - dantheman - Fri Jun 20, 2008 5:25 am
| silent_code wrote: |
I originally planned to use /data/*, but as I wanted to provide emulator support via FCSR and the fat-image creation program would not work with sub folders (I always get an error, see below), I had to go with "all in the root."
The output I get from the program is:
| Quote: | Builds a FAT disk image from a given directory.
454053
Creating image
creating FAT12 image size = 0.45 MB's
Working[.]DoneInjectFile("root\data\vsd_data\test.tga") failed
Blessing image
OK - start1:0 size1:0
"FAT12 image built as fat.img from /root" |
But I figured, that I could use two folders: If loading from /data/* doesn't succeed, try to load from the root. I think, I'll implement that. :^) |
The BFI.exe file is a bit broken, causing that error. See http://forum.gbadev.org/viewtopic.php?t=15369 for a more stable program to use. Modify the build.bat file so that instead of the following line:
it says this instead:
| Code: |
| add_to_disk_image.exe %1 %2 |
Then try again. If this works, please reconsider using the DATA directory, as it helps declutter the root folder.
#158895 - silent_code - Fri Jun 20, 2008 11:22 am
I have implemented the two directories approach in the new release (out now) and it works fine, but I will definitely give this a try. Thanks! :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#158958 - Noda - Mon Jun 23, 2008 7:49 am
Concerning the M3Real problem, it seems its loader / dldi patcher is rather bad.
It doesn't work with latest PAlib for example because the arm7 makes use tight usage of its working ram, and some people reported that cleaning a little the arm7 memory usage makes it working on the M3R...
The thing is, the autodldi patcher often crash when loading some homebrew, and by crossing informations from all the feedback I had with problems concerning this linker, I suspect either their loader or their dldi patcher to allocate static memory on the shared work ram (used by the arm7), which would be causing those problems.
#158960 - silent_code - Mon Jun 23, 2008 10:02 am
Hey Noda, that was a nice bunch of info! Thanks!
So, what ARM7 binary does StillAliveDS use? It's build with an older devkitARM (R21) and (probably?) current libs / current PAlib (which I guess doesn't cause the problem itself.)
Maybe that behaviour is becaused by the M3R loader interfering with ASlib or libwifi?
This is so confusing... :^/
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#158966 - Noda - Mon Jun 23, 2008 2:01 pm
AFAIK, StillAliveDS use latest palib (which works on r21) which makes use of ASLib packed with DSWifi. Both libs fitting on the arm7 makes it very tight on arm7 working ram (64K + 32K shared) which cause the M3R loader to fail.
Michoko used the same Palib but removed the dswifi lib from the arm7 bin and as a result his homebrew works on M3R (and it use EFS too)...
Another notable thing: Michoko released a version using my new (currently under beta) EFSv2 and it seems to crash (nothing but black screen) on M3R on loading (while the same code one using EFSv1 works). EFSv2 doen't do anything fancy and oviously doesn't use any arm7 ram so it's rather strange... (and no problems with other linkers)
The better thing to do is probably to beg the M3R to review their loader / dldi patcher to address these issues, cause when homebrews works on all but 1 linker, I think the one who should fix this is the maker of the card.
#158968 - silent_code - Mon Jun 23, 2008 2:48 pm
@ Noda: You are totally right. The reason I wanted to know why this would happen, is that I would like to avoid those issues in my own HB for the time the manufacturer doesn't fix the driver. :^)
I hope they will, eventually do just that: fix it. :^D
I'm going to move my project to use the new default ARM7 binary some time in my next releases. I wonder if it will work on the M3R. ;^)
Thanks for all the information!
PS @ Noda: When you release EFS2 officially, I'll definitely try it. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#159070 - HyperHacker - Wed Jun 25, 2008 3:13 am
If clearing RAM before loading the binary fixes it, does that not mean the program is relying on the values of uninitialized variables?
_________________
I'm a PSP hacker now, but I still <3 DS.
#159092 - silent_code - Wed Jun 25, 2008 11:18 am
@ HH: Could you please elaborate a little bit, maybe give an example?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#159111 - Noda - Wed Jun 25, 2008 5:00 pm
| HyperHacker wrote: |
| If clearing RAM before loading the binary fixes it, does that not mean the program is relying on the values of uninitialized variables? |
not clearing it, bug freeing up some more ram did it.