Separate names with a comma.
Discussion in 'NDS - Emulation and Homebrew' started by xxRAG3, Jan 22, 2009.
In terms of what?
I dont get it..
Do you mean "Does it matter how large a homebrew is, for it to work on a flashcart?"
or "Do you guys care how large the size is on a homebrew?"
I believe he means, does it matter how long the tiltle of the game is. Like "Mario Kart DS.nds" and that would be no. You just wont see the entire name on you card. It will just get cuz off like Mario Ka.... or something
Size doesn't matter, women will like it if you know how to use it regardless of its size..
Some GBA slot carts use .ds.gba format which they load to their ram making the actual ds file have that size limit (16 megs through 32 for the decent ones).
Since DLDI or even the earlier libfat became the standard nothing has approached that (rarely do I see more than 10 megs).
File name/character limits are the same as commercial roms for your cart (I would point to the FAT and FAT32 limits but some carts are lower for whatever reason).
You arm9 has to be loaded into memory so there's the limit of ram. I think it was his question.
I also think this.
So, that would be 4mb.
Alternative for if your homebrew is too big:
Loading images from the SD, and sound files and stuff.
i guess he means how large in file-size...
Actually you dont have to get your hamebrew at a round number like 2,4,8,16,32,64,128,256 ...MegaByte to get it running
what the limit is.. i dunno
4 MB is the limit for anything that will run on a slot-1 device. Some older homebrew programs embed everything in the *.nds file, and so they might go above 4 MB. These will only run on a slot-2 device with GBA compatibility, such as a slot-2 Supercard (non-Rumble) or M3 Perfect or 3in1. Some examples: TranslatorDS, SnezziDS, SNES DS compilations above 4 MB, and Lupidan's homebrew Zelda fangame that never got finished.
But what about those roms (games) that are 128mb? or am I missing something here? o.O
Commercial DS games have a built-in filesystem that works differently. The carts know to only load the first part and then stream data from the microSD card as the game requests it. DS homebrew *.nds files however do not run like this. Instead, the homebrew app is loaded entirely into DS RAM and then executed from there, so if your program is larger than 4 MB it will not run. The homebrew files I mentioned earlier get around this by executing directly from the GBA cartridge, something slot-1 cannot do, and because of that their limit is 32 MB since that's the limit for the total filesize of a GBA file.
Most DS applications nowadays however use microSD card access for storing files. When doing this, you load just the core data in a *.nds file that's less than 4 MB, and then you can access external files that let the program work correctly. This is how, for instance, Moonshell can play a 20 MB video file. Moonshell's *.nds file is less than 4 MB so it gets loaded into RAM and run, and then it streams the larger file from your card and works with that. Come to think of it, this method of loading data is very similar to the way commercial games work, just without packaging everything into a single executable file.
There actually was a way to embed your media files into Moonshell's *.nds file up until version 1.5, but again this was only useful for slot-2 users, especially ones with NOR-based carts that don't have filesystems, and you could only have up to about 30 MB of media files or you'd go over the GBA's 32 MB limit.
I understand, but what I don't get is... why can commercial game work in a different way? I mean, we have done wonders in the homebrew sector (with passme and all that stuff) but still we can't replicate that file system the commercial games use? Or is there a way?
Like if I were to program a commercial-like game... is it impossible without resorting to tricks like the slot-2 thing or loading external files from the microSD?
It can be done (why do you think the homebrew dev kit program ndstool works with commercial roms?) but the reason we do not replicate commercial roms is precisely because we have DLDI and what have you; imagine having to rebuild the homebrew every time you wanted a new video, music track..... and it also dodges kludges like overlays.
However if for some reason you do want a massive file like what DanTheManMS was speaking of then the technique was reborn for the DLDI era as FCSR, several ways to do it but the easiest is with DLDIrc:
The picodrive DS website has some info if you need it for whatever reason but I can be bothered to dig it up right now.
edit: see DanTheManMS's post below.
Thanks a lot for your info I appreciate that.
I think EFS (E-something (Extended?) File System) is a way to make homebrew files work like commercial DS games, but honestly I've never tried to see if it will work with >4 MB compilations. There's a large thread on GBAdev about it at least.
Also, it's worth pointing out that FCSR will also only work on slot-2 devices to the best of my knowledge. It can also be used for testing a DLDI-capable program in no$gba, which is a nice plus. However, one of the applications used in building an FCSR image is slightly broken and will fail to create a workable FAT12 image sometimes. Dwedit made a more reliable program but it requires you to edit a batch file for proper usage. I can dig up more info on this if you're actually interested in it.
In MB, does it matter how large its in IN MB.
(Sorry for doublepost, i thought they would autocombine since no one posted inbetween)
I'm sorry, but could you dumb that down just a little bit
EFS is catching on, and yes, it does allow nds files to breech the 4MB limit. It's an embedded filesystem not too dissimilar to the one used by the official devkit.
FCSR and slot-2 NDS devices have both gone the way of the dodo bird.