[技术]目前DS自制软件主流FileSystem综述

tring

目前自制软件主流的3种FileSystem为
PAFS,GBFS,LIBFAT
特点分别为：

1，PAFS
简介：
PALIB配套的一个FILESYSTEM库
优点：
简单完善，可后期再制作
缺点：
只支持SLOT2卡（改版PAFS_RAM可支持SLOT1，但是缺点同GBFS）
原理：
通过将数据和FAT表捆绑在ROM尾端，在SLOT2卡载入ROM的时候一起被载入烧录卡的SRAM中，便可直接访问
（改版的PAFS_RAM原理同GBFS）

2，GBFS
简介：
LIBNDS配套的一个FILESYSTEM库
优点：
SLOT1,2通用
缺点：
1，FAT结构不如PAFS完善
2，数据大小限制在4MEG之内
原理：
通过将数据和ARM9代码段（SOUND数据是同ARM7代码段）捆绑，在载入时同代码一起被载入DS的RAM中，便可以随意访问，但是由于DS的内存只有4MEG，而且同时还要载入代码段内的内容，所以数据大小被限定在一个很小的范围内（一般不能超过1~2MEG）

3，LIBFAT
简介：
目前主流FS，可以直接读写在SD（TF）卡上的内容，在07年以后的版本支持DLDI，新版LIBNDS配套
优点：
1，支持SLOT1,SLOT2
2，大小无限制，卡上文件随意读写
3，不仅可读而且可写，这是和上面2种的本质区别
缺点：
其实没什么确切缺点，不过有一点值得提出，就是这种FS确实经常RP……运气不好可能就会毁卡……
原理：
没太多好介绍的，就是读写SD（TF）卡的一个IO库，07后的版本支持了DLDI补丁，便可更好的兼容各种烧录卡


其他：
值得一提的是老N官方使用的FileSystem：NitroFs（貌似是这个名字，英语不好，但愿我没误解）
这个是目前所有正式DS ROM使用的一种FS
打开随便一个DS游戏的文件头，相信大家都会看见fat.bin和fnt.bin两个段，这两个段就是NitroFS使用的FAT表，数据文件会按照这2个段依次以独立的段被安插在ROM之中，这些数据段在游戏启动的时候不会被读取，只有在游戏中需要读取的时候才会被载入内存（就是游戏中的LOADING），下面就介绍一下这个的具体实现机制：
1，Z版卡，这个么什么好多说的，直接从卡带的ROM中读取。
2，SLOT2卡，所有S2卡在载入ROM的时候都是事先将完整ROM载入SRAM缓存中（部分官方的DS游戏可能有的是分段载入，这就是为什么S2卡在烧录的时候都会设定载入方式，但是文件头是肯定会在开始被载入的），因此此时只用从0x8000000开始往后扫描即可依次找到DS文件头，FAT表，数据文件，可以说是很方便的实现，但是依旧，这个方法只适用于SLOT2卡
3，SLOT1卡，正规DS游戏在SLOT1卡上的NitroFS的实现过程依旧不明，但是这里介绍一个比较少用到但是比较巧妙的自制FileSystem库：
LIBEFS：
简介：
目前唯一一款可以同时在SLOT1,SLOT2上使用的支持NitroFS系统的自制库，
同时也是目前唯一一款支持SLOT1的ROM-EMBEDDED FILESYSTEM（数据文件捆绑在ROM中）
但是LIBNDS和PALIB都未配套提供，请独立下载
优点：
捆绑式FS，支持SLOT1卡
缺点：
需要LIBFAT的支持，并且依旧需要打DLDI补丁
SD（TF）卡越大，上面的目录层次越复杂，初始化的速度就越慢
原理：
相信看见上面写的缺点，大家就基本可以猜到这个库的工作原理了吧，这个库是作为LIBFAT的一个高级库被设计的，他的作用说直接一点，就是在SD（TF）卡上扫描到自身的ROM文件，然后打开读取，然后依照以前的方法在自身ROM文件中依次找到DS文件头，FAT表，数据文件段
也就是说这个库的本质还是LIBFAT，而且由于是要事先在SD（TF）卡上扫描自身，所以对于记忆卡会反复读取，而且卡的本身情况对于该代码的速度影响巨大

从上面的叙述中不难看出，在烧录卡在载入ROM的时候，Z版卡读ROM，S2卡读SRAM和存储卡，S1卡读存储卡（此处为假设烧录卡处理官方ROM的做法大致同EFS），也就是说在游戏中的LOADING速度，应该是SLOT1卡反而不及SLOT2卡，而且SLOT1卡的游戏速度更受SD（TF）卡读写速度的影响（以上结论为建立在假设上的猜测）

最后
在某外国DS开发的权威网页上我看见了这句话：
Unfortunately there are no homebrew libraries available yet that allows reading this filesystem from the DS hardware.
我觉得此时我的心情实在是很难用Unfortunately这么一个简单的词语带过
非常不幸，现在还没有一款自制库能够只靠DS硬件本身读取官方的FILESYSTEM
也就是说本人这几天来的研究本仅仅是为了寻求一个能够绕过LIBFAT的合理且通用的为ROM附加大量资源的方法，可是最终的结果确被现实不得已的逼向了使用LIBFAT的最后一个选择（EFS也属于变相使用LIBFAT）
但愿这篇文章能够帮助和我遇见同样困境的人少走一些弯路：
就目前现状看来DS自制软件开发对于资源读取的最佳也基本可以说是唯一的选择就是：LIBFAT

参考资料：
http://osdl.sourceforge.net/main ... DS.html#datastorage

以上内容属原创
转载请注明作者：Tring.

bobo129

消灭0回复。。帖子叫好不叫座阿。。。估计是看不懂，曲高和寡

speedfly

暂时还没看明白，等以后慢慢看。

该用户已被禁言

看不懂。。。。。。。。

killertom

貌似明白了为什么SLOT2的卡载入游戏速度比SLOT1快.........
被扫盲扫到了....

anotherone

是不是与WINDOWS中FAT与NTFS的争论一样呢？

又或许是各种介质上所使用的读取格式？

需要做些比方，否则甚难理解啊。

tring

下面是引用anotherone于2008-02-11 12:50发表的:
是不是与WINDOWS中FAT与NTFS的争论一样呢？

又或许是各种介质上所使用的读取格式？

需要做些比方，否则甚难理解啊。

纯粹是几种目前主流的自制软件的文件部分的开发库而已~

开发库说简单点就是一组人家写好了给其他软件开发者用的一组函数~
文章介绍的几个库的共同点就在于库里的那些函数的作用都是一个~就是管理“文件”（广义上的~不只指的SD卡上的~其实说是管理数据和资源更恰当）~
因为函数的实现都是依赖硬件的~但是每套函数的实现方法又都不相同~所以真要比喻的话还不知道如何比喻是好~……

WINDOWS的FAT和NTFS从硬件实现上来说~媒介都是硬盘~区别更注重于格式上~（因为本人对这2东西没啥了解~不细讲）
但是相反~几种DS的FILESYSTEM在具体的格式上可以说基本相似（都是用FAT表）~主要是在硬件层上的实现区别很大~
不过同样也谈不上是各种媒介上的读取格式~因为毕竟是以软件为主线在讲~而不是纯粹的硬件介绍~……