Talk:Nitrofs
Contents |
Hellos...
Hi, thanks for viewing and hope you find the file-system driver useful. Have tried best to make the read-only nitro driver possible but here you may help improve it with comments, bugs report, and questions without an account.
Change log
- Now the .nds file should work with both emulators and flashcards. (thx wintermutes) :DD (v0.2)
- Fixed bug in fseek. SEEK_CUR should now work properly. (v0.2)
- ftell() now works as expected (v0.3)
- Put back support for .gba and .sc.nds formatted files, now both .nds and .gba files should work in emulation (v0.3)
- added stat() support (v0.3)
- added SEEK_END support.. (v0.3.1)
- added chdir functionality (v0.4)
- corrected SEEK_END so that the position argument is utilized (v0.5.turbo)
- greatly improved file opening speed by around 106ms in dldi mode by reusing the .nds filehandle created at init for all subsequent operations. Details are on the discussion page. (v0.5.turbo)
The latest 'turbo' release as mentioned improves file and directory opening and closing times, by using a single filehandle to access the .nds file when not in GBA mode. This is great for situations requiring reading a lot of seperate small files which most users will probaby desire, however it does take slightly longer when reading from multiple files at once.
Older changes and such
Just today (2008-05-01) heard there was a discussion about nitrofs on gbadev's forums, and found out why i was not able before to use a .nds file with emulators. Both thanks to Wintermutes Thx!!!!!! :DD
After reading the forums found out there was a bug with fseek() and the SEEK_CUR, i am sorry. u_u This was not noticed immediately as I only used SEEK_SET in testing. The problem turned out to be an improper return value in my fseek() function. Guess i should thank noda for pointing this out, and btw, hellos! ^^/
Now, a single .nds file should work equally well with both emulators and flashcards, hopefully... I tried this before in the previous version but did not realize passing -o option to ndstool prevented GBA access. After fixing the Makefile and zeroing the offset used previously for the older style .ds.gba
2008-05-21 - fixed ftell() issues, and re-enabled support for ds.gba files in addition to .nds on emulators (best of both worlds! :PP).. also added stat() support for reading file lengths w/o opening..
2008-05-26 - Added chdir() functionality, lets see how long till someone usurp the insanely simple method...
2008-06-16 - Relased turbo version.
YAY!!
Why not read from the card directly?
Noticed someone asked about this on another forum. I'll try to explain (based on what i've been told so please correct me if am wrong)...
Original games are encrypted and read over SPI buss from the card which decrypts using hardware. When these games are loaded off flashcards, the flashcard's loader modifies the card/SPI functions which are patched to use flashcard specific functions that emulate normal SPI access to the card's data.
The details of this are foggy, since flashcard companies don't wanna say what they are doing exactly and help competitors. :/ So to make homebrew that uses official SPI style calls would be sort of pointless since the loaders would prolly not pick up on this, not patch them, and thus not work at all.
♥ eris
Multiple vs Single FAT filehandles when in .nds mode
After pondering this a bit, have decided most uses would prefer quicker open/close times versus a very slight slowdown when reading from multiple files.
When using the .nds file and FAT, is there any advantage in using opening only one ".nds" instead of opening a ".nds" file for each file opened on the nitrofs.
fopen uses up quite a few cpu cycles, so obviously f/opening of files from the nitrofs would be faster if the same .nds file were used instead of opening a new one each time. This would speed up most other operations as well such as directory openings, file/dir closes, stat() calls, etc.
What happens if your reading from two nitrofs files at once?? In this case the single .nds file would need be seeked back and forth like crazy every time a different nitrofs file was read from. Have heard that FAT may take a bit of time to search the allocation tables and change file position, is this take any longer than opening up multiple files that hafta read from different positions on the card, and how the different DLDI implementations would affect this is truly a guess to me??? If anyone wants to try I'd like some feedback here.
I tested it with my newflash 8gbit, here are the results:
| Test | Multi | Single | diff |
|---|---|---|---|
| 2files | 956 | 1078 | -122 |
| fread | 432 | 326 | 106 |
| read | 338 | 232 | 106 |
| shortread | 113 | 5 | 108 |
- all results in ms
2files
this test reading 2 files simultainiously, 0x100 bytes at a time, over 10327 reads (file is 1032793 bytes), one file is fopen'd other is open'd.
As i suspected, reading multiple files with single .nds file is slower, but.... not by much at all, especially given the number of reads this spans.
fread & read
just freading (or reading) the same 1032793 byte file. Times include open/close calls. here the winner is the single file mode, saving about 106ms for both methods. open is always gonna be a bit faster because its a simpler method than fopen (this is why i prefer open to fopen *shrug*)
shortread
ok this is reading a short 16 bytes or so from a file and doing a bit of seeking around. Here the biggest advantage can be seen. If your opening alot of small files (as i suspect most will be doing) there would be a big improvement as all those fopen/open calls add up.
Bug in ndstool
There is a bug in ndstool causing the last byte of the last file included into nitrofs to be 0!! Its a wonder no one has spotted this before rly. Thanks to Lacey for pointing this out and helping to find it. I've not had a chance to look into it further.
One simple workaround is create a file of 1 or more bytes and name it zzzzz.txt or such so that the last mangled byte ends up on an unused file.. This is HORRIBLE i know, ill look into it soon.
