#40224 - FeaRog - Sat Apr 16, 2005 11:12 am
Hi all,
Some of you may know that I've been writing a filesystem in my free time. Well, I've got it to a point where I'm happy to release it, so here is!
http://www.geocities.com/codefiend.geo/DSFilesystemR1.zip
Included is the source for the filesystem generation tool, and a simple demo program that uses it.
Note that it doesn't run on any emulator that I've tried, only on real hardware.
Its pretty easy to use, since I've modelled the interface on the stdio one.
All data is loaded straight from the GBA cart, so no longer does your program's data have to be linked into the binary and copied into RAM on startup!
Enjoy!
#40226 - chrissieboy - Sat Apr 16, 2005 11:55 am
sorry but can you tell me what a filesystem is? Because i still dont have a passme!!
Is this a file browser for nds?
#40227 - FeaRog - Sat Apr 16, 2005 12:15 pm
The NDS has no native fileIO, so up until now everyone has been linking their data directly into the executable. This results in a maximum code+data size for any demo of 4MB, makes the load times horrendous, and means that a full recompile needs to be done every time you change your data. It also means that the programmers need to manage a bunch of magic variable names all through the code, and means that artists need to have a full development environment to test any art they're working on.
The filesystem is a binary file that has basically a "directory" at the start, and all the file data at the end. It is not part of the executable, it is appended to the executable just prior to putting it on your flash cart. Due to this, it doesn't need to be copied into RAM on startup, speeding up loading times heaps. Then, from code, you can open and close the "files" in the filesystem and read from them, just like you would on a PC. It makes integrating art and audio assets into your demos MUCH easier and neater, and means that artists won't need a full development environment to work on their contributions to projects.
Anyway, theres the provision for version information in the format, and the code is all GPL'd, so we could develop this further in the future.. I'm keen on the idea of getting it included with NDSLib, as I think everyone would be keen to have this functionality..
#40228 - chrissieboy - Sat Apr 16, 2005 12:58 pm
Very COOL !
Now i understand it , thanx for your explanation!!!
#40229 - polysign - Sat Apr 16, 2005 1:13 pm
Very nice FearFrog... good work... as soon as I have my dev-environment running and my Ralink Adapter, I will try to contribute my knowledge...
#40233 - Chetic - Sat Apr 16, 2005 2:24 pm
Does this really mean we can get more than 4MB demos now?
Like media players and whatnot..
I certainly wouldn't mind :)
#40237 - FeaRog - Sat Apr 16, 2005 3:33 pm
Chetic - that certainly should be possible, but I haven't tried it yet :)
#40245 - tepples - Sat Apr 16, 2005 4:12 pm
What does this do that, say, GBFS doesn't?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#40246 - dovoto - Sat Apr 16, 2005 4:25 pm
Although interesting it probably should be noted that nds does have a built in file system inherent in the nds file format. Ndstool allready supports inclusion of files as well as the FAT generation (you just give it a directory and it does the rest). No code has been included in ndslib as of yet to access this file system but it will soon. There are also plans to integrate it into devkitarm so fopen and its kin work like expected (ie fopen("nds:\data\blah")).
_________________
www.drunkencoders.com
#40248 - Darkain - Sat Apr 16, 2005 5:07 pm
NOW the question is... is this file system designed around the idea of random access, or write once read many? and if it is designed around a read/write scheme, what is thr cluster size?
i'm curious about this, because i want some sort of read+write access in dsPaint (as well as other applications im developing), this way they can do more then what is available within a single session.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#40249 - FeaRog - Sat Apr 16, 2005 5:17 pm
tepples - it allows you to do your file loading seamlessly from the arm9 side. These are blocking loads, but could easily be made asynchronous.
dovoto - since I hadn't heard of this "ndstool" until now, thats not terribly helpful now is it. Whats the point of having features unless people know about them? Also - a binary scan of every file on my hard drive shows no trace of the string "ndstool". And if its part of the NDS file format, thats hardly built in. I have *working* code right here (and in that zip file I've posted also), right now, that works just like fopen and its kin. No plans. Working (theres bound to be a few bugs that need fixing though). To dismiss this with just a "although interesting" seems a little silly to me.
Darkain - there is no support for writing in my library as of yet - you write it once (when you flash your cart) and read from it when you like. If you can write to the cart from arm7 code then writing could be added - its not something I've played with though. Another possibility is to add writing to the save game memory.
#40250 - FeaRog - Sat Apr 16, 2005 5:59 pm
Note that with the exception of the actual locating of the file in the system (the easy part), the code in my library is pretty generic. You could easily modify it to support any different underlying file table type. The bulk of the code relates to the actual loading of data, communication between arm9 and arm7, and the fopen-style interface.
#40255 - sajiimori - Sat Apr 16, 2005 7:02 pm
I'd make a sarcastic remark about genetalia measurement, but if it weren't for this mentality maybe there wouldn't even be a homebrew community!
#40256 - Series-8 - Sat Apr 16, 2005 7:19 pm
Good get the code in NDSlib.
at the very least it can be used until something better comes along.
(and if 'something' never does come along we still have FeaRog's FS)
#40258 - linus - Sat Apr 16, 2005 7:48 pm
| Quote: |
| there is no support for writing in my library as of yet - you write it once (when you flash your cart) and read from it when you like. If you can write to the cart from arm7 code then writing could be added |
surely the arm7 can write to the gba cart as it needs to for save games, but i think this is limited to the sram part or something.
well done on the library, i havent had a chance to use it but still the fact its there is enough :)
#40265 - bluknight - Sat Apr 16, 2005 10:11 pm
Is it possible to write to these flash carts though?
#40266 - Darkain - Sat Apr 16, 2005 10:25 pm
| bluknight wrote: |
| Is it possible to write to these flash carts though? |
you have to flash the demos on them in the first place, right? :)
each card has its own unique register set tho. personally, i'm most concern about visoly carts.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#40270 - bluknight - Sat Apr 16, 2005 11:28 pm
I know but I wasn't sure if it was possible to do the same thing while it was in the GBA or if it needed to be hooked up to something special.
#40271 - bluknight - Sat Apr 16, 2005 11:30 pm
It won't let me edit. -.-'
I meant in the DS though, since we're talking about the DS and not the GBA. (screwed up because they are GBA flash carts, so I had GBA in my head when I meant to type DS)
#40272 - octopusfluff - Sat Apr 16, 2005 11:34 pm
| Darkain wrote: |
| each card has its own unique register set tho. personally, i'm most concern about visoly carts. |
A standard library with access instructions for writing to the major flash chips would be handy. Bundling that with a filesystem layer would seem to be a good idea to me.
#40275 - tepples - Sun Apr 17, 2005 12:15 am
Don't many of the standard flash chips have 128 KB sectors? And don't those sectors wear out after about 10,000 writes?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#40277 - octopusfluff - Sun Apr 17, 2005 12:28 am
| tepples wrote: |
| Don't many of the standard flash chips have 128 KB sectors? And don't those sectors wear out after about 10,000 writes? |
Numbers I've previously been quoted were in the hundreds of thousands, or millions, for higher grades.
'course, could always load up the spec sheets to find out for sure.
#40280 - ampz - Sun Apr 17, 2005 1:11 am
| tepples wrote: |
| Don't many of the standard flash chips have 128 KB sectors? And don't those sectors wear out after about 10,000 writes? |
Depends... Intel guarantee a life of 10'000 erases per sector, while AMD guarantee 100'000 erases per sector.
#40281 - Darkain - Sun Apr 17, 2005 1:16 am
my cart uses 256k sectors, but yes, 128k is the standard (mine uses 2 chips w/ interleaving, so it doubles)
including the read/write code along w/ the "boot sector" of the file system would actually be a nice idea.
as for read/write counts... lets put it this way, you will wear out the pins on your cart before you wear out the flash chip.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#40282 - ector - Sun Apr 17, 2005 1:17 am
unless you try using the flash cart as a swap partition for linux :)
#40285 - Darkain - Sun Apr 17, 2005 1:35 am
| ector wrote: |
| unless you try using the flash cart as a swap partition for linux :) |
that wont work well tho, because of the fact it is 128kb or 256kb sector size. everything must be writen in increments of this size.
flash carts just wont work well for a linux swap partition. in fact, the only way it could is if you implement a software based virtual memory controller, which would be painfully slow.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#40292 - josath - Sun Apr 17, 2005 2:45 am
Here are the changes to make filesystem.cpp compile on linux. i tested it, and the output is identical for the test files.
| Code: |
98c98
< DEBUG_BREAK();
---
> //DEBUG_BREAK();
201c201
< void main(int argc, char* argv[])
---
> int main(int argc, char* argv[])
342a343,346
>
>
> exit(0);
> return 0;
|
as far as concatenator, you can make a script that does the same thing
concat.sh
------------
and to replace the addfs.bat:
addfs.sh
---------
| Code: |
| sh concat.sh fstest.nds testfs.bin fstest.pme |
#40298 - FeaRog - Sun Apr 17, 2005 4:52 am
I suppose we could write a library of writing functions for different flash carts and support them all, as long as theres enough information around and enough people that are interested in helping. I can't see that it would be terribly fast however - I don't think it'd be useful as a swapfile, but could definitely see it being used for applications such as Darkains DS Paint etc. Anyone keen on doing this?
josath - Cheers, I've modded my version of the source and it will be part of any future release.
#40302 - Darkain - Sun Apr 17, 2005 5:24 am
| FeaRog wrote: |
I suppose we could write a library of writing functions for different flash carts and support them all, as long as theres enough information around and enough people that are interested in helping. I can't see that it would be terribly fast however - I don't think it'd be useful as a swapfile, but could definitely see it being used for applications such as Darkains DS Paint etc. Anyone keen on doing this?
josath - Cheers, I've modded my version of the source and it will be part of any future release. |
i typed this in the channel right before i checked my email to see the reply to this thread:
| Quote: |
| [21:21:58] DarkainMX: "FLASH: 2X INTEL I28F128J3A" <<< DarkStar told me that. :) |
i'm already working on getting older Visoly carts working in DarkStar (which is what dsPaint is built on top of)
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#40333 - dagamer34 - Sun Apr 17, 2005 5:42 pm
Has anyone tried to see if saving using the GBA flash cart's SRAM works?
_________________
Little kids and Playstation 2's don't mix. :(
#40339 - Darkain - Sun Apr 17, 2005 6:31 pm
| dagamer34 wrote: |
| Has anyone tried to see if saving using the GBA flash cart's SRAM works? |
SRAM is limited to 64kb?... its really small. you could get more with bank switching, but its still no where near the space you would get from flashing a flashcart.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#40555 - shadow1w2 - Wed Apr 20, 2005 7:54 am
Wow, nice work.
A sticky note program might be a fun idea to try, I still need to practice my codeing though, but I'll make it a project :3
Besides, I need something usefull for my College classes.
PDAs are so lame and expensive :p
Not to mention the terrible button layouts they have, ugh so nasty they are.
Cant wait to see this file system go far, it looks very promising.
#40562 - FeaRog - Wed Apr 20, 2005 10:02 am
Yeah its going pretty well, I've found and fixed a bunch of issues with it and might do another release soon..
#40582 - darkfader - Wed Apr 20, 2005 4:19 pm
Funny... Darkain is doing a filesystem too :)
And soon, there will be FAT support.
Anyway, I really think the NDS loader should support filehandling real soon or else highscores will overwrite SRAM on GBA cartridge and whatever.
#40596 - Darkain - Wed Apr 20, 2005 7:41 pm
| darkfader wrote: |
Funny... Darkain is doing a filesystem too :)
And soon, there will be FAT support.
Anyway, I really think the NDS loader should support filehandling real soon or else highscores will overwrite SRAM on GBA cartridge and whatever. |
hey, i only want to do one because i want both read/write support from within the GBA/DS. all of the filesystems out there right now seem to be designd around "write once / read many", which doesnt work at all for what i want to do.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#40688 - FeaRog - Thu Apr 21, 2005 5:11 pm
The next release is coming along nicely... I've figured out how to read from the GBA cart from ARM9 code so it has been mostly rewritten - the portion that used to run on the ARM7 is gone, and its a bucketload faster :) Theres still a small bit of code in the bootloader, but not as big as before. There are also some bug fixes, and the filesystem creater now aligns the files to 4 byte boundaries, allowing for DMA if the receiving buffer is also 4 byte aligned. I've changed it from C++ to C. I may also change it to a BSD license....
Future plans (ie, for after R2):
- Support the file system generated by NDSTool - this will be accessible using DOS style pathname "c:\" (or possibly "nds:\") and mine will be accessible using POSIX style "/" pathnames
- Bringing the ARM7 code back and using it as a fully asynchronous file streaming system
- Allowing reads & writes to the save game memory using "/save/"
Stay tuned..
#40691 - jstart - Thu Apr 21, 2005 5:19 pm
You know what would be awesome, was if you made handwriting recognition software for it like the apple newton. Then maybe we could write save and it would save or type hom and it would go to the top directory.
just an idea
_________________
-=Jstart=-
#40696 - Jolarix - Thu Apr 21, 2005 6:00 pm
jstart - Another cool thing would be for somebody to release a really simple touch keyboard, that would take up half of the bottom screen. If it was open source, anyone could use it in any sort of program without having to make one themselves every single time.
You don't have to re-invent the wheel every time you program. It's useful to use the tools others have already created, with the right creditation. (NDSlib anyone?)
#40697 - TJ - Thu Apr 21, 2005 6:02 pm
I would imagine a standardized onscreen keyboard would eventually get added to NDSLib at some point.
#40704 - jstart - Thu Apr 21, 2005 6:31 pm
well isn't there that pandaforth thing that desktopman made?
_________________
-=Jstart=-
#40800 - shadow1w2 - Fri Apr 22, 2005 8:12 pm
It will be cool to see an FAT filesystem on the NDS, and maybe even an OS way before nintendo even bothers with one :p
Maybe it would get Nintendo to make their own and stuff, kinda like the afterburner light kit convinced nintendo to add the same kinda light to their GBA SP.
But I guess Im getting alittle ahead of myself,
still though, this is freakin sweat XD
and if there is a preprogramed screen keyboard in NDSlib, I hope it'll be preprogramable, though I guess that goes without saying, but a premade tool is nice, but sometimes it needs a flashlight or something ductaped to it :p
But anyway, this filesystem, wouldnt it have to be specificly patched for certain GBA flash carts? If it goes off the "write once/read many" type of system that is. Since most carts simply wont work that way, unless you know how to get the system to write to the card itself somehow, but thats still not very workable. Though the newer EZ-Flash 3 has a filesystem thing, maybe that could be used with the NDS :p
Or maybe a new format of GBA flash carts might be helpfull.
It'll be great to see how this turns out.
Cool stuff :3
#40804 - Darkain - Fri Apr 22, 2005 8:31 pm
| shadow1w2 wrote: |
| Maybe it would get Nintendo to make their own and stuff, kinda like the afterburner light kit convinced nintendo to add the same kinda light to their GBA SP. |
You mean the Gameboy Light? (which was inbetween the Gameboy Pocket, and Game Color) ?
It was a Japanese release only tho.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#40807 - shadow1w2 - Fri Apr 22, 2005 8:50 pm
| Darkain wrote: |
| shadow1w2 wrote: | | Maybe it would get Nintendo to make their own and stuff, kinda like the afterburner light kit convinced nintendo to add the same kinda light to their GBA SP. |
You mean the Gameboy Light? (which was inbetween the Gameboy Pocket, and Game Color) ?
It was a Japanese release only tho. |
Um no, I meant the AFterburnet Kit for the GBA that was completly unofficial and made by the Afterburner group who now do music it seems O_o
Didnt know they made a Gameboy light though XD
Acording to afterburner they said they accomplished stuff by getting nintendo to do it too. Maybe it wasnt the Afterburner that got nintendo to use the light, but the afterburner is still kick ass homebrew stuff :p er, mod, not code, but still XD
#40841 - Sebbo - Sat Apr 23, 2005 3:52 am
think someone could rip a HD out of an ipod or ipod mini and try to cram it into a gba cart? :-P thats at least 20GB instantly accessible
#40848 - TJ - Sat Apr 23, 2005 4:28 am
Nintendo had designed and conceptualized the SP long before Afterburner even got off of the ground.
#40859 - tepples - Sat Apr 23, 2005 5:15 am
| Sebbo wrote: |
| think someone could rip a HD out of an ipod or ipod mini and try to cram it into a gba cart? :-P thats at least 20GB instantly accessible |
Hack the Supercard to take the thicker CF type 2 cards, and you can use a Hitachi Microdrive.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#41088 - linus - Mon Apr 25, 2005 12:11 am
How big is the sram on ur average gba cart?
#41105 - tepples - Mon Apr 25, 2005 5:21 am
SRAM on official GBA Game Paks: 1 bank of 32 KBytes.
SRAM on GBA compatible flash carts: 4 banks of 64 KBytes. See PogoShell source code to learn how to bankswitch.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.