NES文件格式
NES文件格式
|
http://www.bjsgm.com/a/a.asp?B=101&ID=12
9、NES文件格式 .NES文件为模拟用来储存NES卡带的映像。下面是一个.NES文件的结构。 偏移 字节数 内容 0－3 4 字符串“NES^Z”用来识别.NES文件 4 1 16kB ROM的数目 5 1 8kB VROM的数目 6 1 D0：1＝垂直镜像，0＝水平镜像 D1：1＝有电池记忆，SRAM地址$6000-$7FFF D2：1＝在$7000-$71FF有一个512字节的trainer D3：1＝4屏幕VRAM布局 D4－D7：ROM Mapper的低4位 7 1 D0－D3：保留，必须是0（准备作为副Mapper号^_^） D4－D7：ROM Mapper的高4位 8－F 8 保留，必须是0 16- 16KxM ROM段升序排列，如果存在trainer，它的512字节摆在ROM段之前 -EOF 8KxN VROM段, 升序排列 nesdev.parodius.com EmuChina 模拟社区 (http://bbs.emuchina.net/index.php 访问网址超出本站范围，不能确定是否安全 继续访问 取消访问http://bbs.emuchina.net/index.php) - 模拟器教学攻略区 (http://bbs.emuchina.net/forumdisplay.php?f=3 访问网址超出本站范围，不能确定是否安全 继续访问 取消访问http://bbs.emuchina.net/forumdisplay.php?f=3) - - 关于Goodx rom的内容。 (http://bbs.emuchina.net/showthread.php?t=4368 访问网址超出本站范围，不能确定是否安全 继续访问 取消访问http://bbs.emuchina.net/showthread.php?t=4368) [yang] 2003-05-16 08:04 PM -------------------------------------------------------------------------------- 关于Goodx rom的内容。 这是我以前写的关于goodx rom的内容，由于论坛两次出问题丢失了，还好sunye有保存，由于很多人问类似问题，所以重新发一下，现在恢复过来比较乱，有空再整理一下： shawn8888问： 以下roms不能通过校验 goodsnes 0.999.5 3x3 eyes - jyuma houkan (j) angelique - premium box (j) bakumatsu korinden oni 2 (j) bakuto dochers (j) batman forever (e) [!] battle racers (j) 是CRC不对,恳请版主尽快修复 好象还有不少也是同样情况,还在checking中 答：其实这个问题很简单。在goodx中有很多系统的rom是有文件头的，如nes有16字节的文件头记载mapper和一些信息，如果在文件头的保留区域（空白区域）有一些垃圾字符并不影响正常使用，因为真正的rom内容是正确的，所以说它也是一个gooddump，而snes的rom有很多文件格式，有的有文件头（512字节??)，有的没有，有的格式是将rom内容交错排布，对于gen的rom也有bin、smd等格式之分，这些只不过是一个rom的不同格式而已，而goodtool好就好在它能区分不同的格式而识别相同的rom，或识别rom时不把文件头计算在内（对nes等），种种智能识别技术，而romcenter只能对应整个rom的CRC32，因此有些dat不能正确识别goodx（因为做dat的人的rom可能是一种格式的，而你的却是另一种格式的）。不过对于nes这种识别方法存在问题。因为对于nes模拟器而言，文件头的信息也是rom的一部分，它们是根据这些信息而启用相应的模拟功能，这种good rom如果文件头存在垃圾信息或文件头为空，则在模拟器中无法正常运行。因为有存在这样的问题，所以才会有nesbase.dat存在的空间，它记载了基本上是正确的nes rom的信息。在nnnesterj中，它可以根据nesbase.dat对相应的rom的文件头进行修改，使其反映真正的信息。顺便提一下，goodnes的早期版本也支持对nes rom的修正，但可能工作量太大，cowering说暂时取消以后再加入，结果就没有下文了。总而言之，对于goodx系列以goodtool管理为好，它的db功能使你可以不断将rom刻入光盘，而不必将它们放在硬盘上。 [yang] 2003-05-16 08:04 PM -------------------------------------------------------------------------------- shawn8888： 果然是高手啊! 其实我也一直在怀疑GoodTools不是单纯用crc32来校验这么简单. 不过这样一来,可能多个CRC不一样的文件都能通过GoodTools的校验.这倒是蛮混乱的.yang朋友有没有兴趣写个中文的教程让大家学习一下啊?呵呵! 这方面涉及的东西太多，要写成通俗易懂的很难。实际上CRC32并不是标识唯一ROM的最好方法，在一些条件下人们可以生造出CRC32一样的文件，最好的例子就是mame中现在唯一缺少的raflsiau，前一阵子网上出现一个zip，CRC32同需要的文件一模一样，但却不能玩，实际上这是个生造出来的rom。现有一些用rc校验会出错的系统都是一些比较流行的系统，而这些系统文件格式特别多，这些文件格式大多是盗版的产物，各种各样的磁碟机有各种各样的文件格式，同样的一个游戏ROM被dump下来后，在不同机器上就被改造为该机器的格式，主要是为了谋利，因为那些dumper有很多都是为生产这些机器的公司服务的，如果你的游戏在其他机器上可以玩，那就不必买你的机器了。这些格式的rom只不过是同一个游戏的不同文件格式而已，比如一个文件的内容为12345678，而另一个文件内容为21436587，看起来两个文件不一样，但实际内容却一样，再假设有个文件内容为SNES12345678，它同第一个文件的区别是多了四个字符，但主内容是一致的，因此对于不同的CRC的文件有可能对应同一个正确dump的游戏。关键在于模拟器懂得如何读取并转换这些格式的文件，只要转换后的内容一致即可。因此不应认为CRC32不同就不是同一个ROM，也不应认为CRC32相同就是同一个ROM，但对于街机ROM在一般自然情况下（排除生造的情况），CRC32可以作为检验的标识。 对于FDS的ROM，有个fdspray(?)软件可以标识FDS的文件，而RC用于FDS也存在问题。FDS是任天堂NES的磁碟机系统，它是一个3寸软盘，玩家可以将游戏进度存在磁盘上，就有可能出现虽然游戏程序区是一样的，但因为存盘内容不一样或位置不同（？），而导致两个文件的CRC32不同，但是因为我们所需要的游戏程序区一样，因此这两个FDS是同一个ROM。Romcenter的立足点是整个文件的CRC32值，只要不同就认为不对（应该是与制作dat的ROM不一致）。rc用于通常的街机系统rom的识别还是很好用的，用于tosec也会出现问题，比如nec 98xx系列类似于FDS，也会出问题。顺便提一下，在ROMCenter中没有问题的zip文件最好要用工具检测一下zip包，很多zip的问题如包损坏它都检查不出来。 因此，在使用工具进行管理时要针对不同的情况使用不同的工具，对于goodx系列以goodtools为最好，对于fds应该是fdspray，对于其他情况可以使用Romcenter或CMPro。但RC比较易用，本人也使用RC这个工具。 在所有系统中以nes的rom为最乱。按照INES的文件格式规定，每个rom有一个16字节的文件头，文件头之后如果这个rom有trainer（hack code ）则紧接着有512个字节（？）的trainer代码，接着就是从卡带中dump出来的内容，先PRG-ROM后CHR-ROM，rom大小在文件头中有第4、5字节标明，nes卡带rom中没有对自身的说明（在gen、n64中有一些标识自身的内容），都是具体的程序代码、图形代码。在卡带中有个Mapper芯片（mapper0除外），它是一个内存管理芯片(MMC)，有的还有一些额外声音电路，而这个mapper有很多种，很多公司为了使自己的游戏跑的更快都生产自己的MMC芯片，加上大量的盗版游戏、合集，而模拟器为了跑这些rom，除了模拟主机外还要模拟这些芯片，这些芯片的资料很少，基本上要靠反向工程等技术猜它的特性，因此虽然大多数模拟器都能支持很多rom，但要提高兼容性却很少可以，台湾的fwnes是比较早支持多mapper的模拟器，所以它的名气很好，现在的smynes也继承它的传统，在mapper支持上甚至超过了ines规范的范围（它支持Mapper256）。谁叫台湾是这些乱七八糟的卡带的来源地呢，先天条件好。鉴于要模拟这些mapper，导致虽然nes模拟器发展这么多年了一抓一大把，但真正100%兼容的模拟器却没有出现。而扩充mapper支持需要大量工作，难怪武田氏被称为铁人（Uonester的作者）。在文件头中第6、7字节包含mapper信息和mirror类型、是否可存盘等信息。这些都是模拟器要正确模拟所必须的信息，而现在的goodnes rom大多在文件头存在各种问题，很多垃圾信息和错误信息导致模拟器不能正常工作。由于这些文件头本质上不是卡带的一部分，而是为模拟器服务的，因此如果除文件头外其他部分内容是正确的，它也是一个gooddump。我估计goodnes在检测时是将整个rom的CRC扣掉文件头16节的CRC而得到除文件头部分外的CRC（我不记得CRC是如何计算的了，猜的）并将其同数据库中的比较而将其正确命名。 要修正这些文件头，需要巨大的工作量，你可以使用nesbase.dat这个文件头数据库来修正，它存在少量错误，但基本上是正确的。nnnesterj可以使用这个dat来修正文件头，但也存在问题，它好象是根据PRG-ROM和或CHR-ROM的CRC值来反查出是那个rom及正确的头信息并进行修正，而要计算PRG-ROM和CHR-ROM的CRC，首先要知道它们的大小，这又是通过头信息获得，因此就存在一个问题就是头信息中这两个字节必须正确，否则无法反查出正确的信息。 nesbase.dat是比较早的数据库，对应的rom较少，在nnnesterj的网站上有一个对应goodnes的新的数据库，大家可以试一试。 顺便提一下，nnnesterj在0.22c这个版本之前对这两个的CRC计算有问题，导致识别错误，而且英文版和日文版的DLL有部分功能的差别，我向作者反映了这些问题，在0.22c中基本上修复了。而virtuanes就不存在这个问题。 Shawn8888: @yang 老兄不会是dumper吧?怎么知道的这么清楚? 很多和我以前的猜想一样,又学到一点知识. 有一个奇怪的问题是goodtool居然连zip包的完整性都不检测就能知道rom的好坏.这一点我碰到过,但还是很奇怪. goodtool在这方面同rc一样，都存在这种问题，只要zip文件可以打开看到内容，就认为这个zip包是好的，这样经常会出现goodtool认为是正确的Zip，结果却打不开。但仔细想想，如果它要对每个包都检查，那个速度估计要好几十倍的时间，现在数据库越来越大，象goodnes就有8820个，而n64的goodump有10几GB大，从头进行一遍，太可怕了。cowering充分利用了zip的一些特性，使检查速度加快很多，你可以试试看对没有zip的文件进行识别的速度。所以我建议大家下完rom后都要集中对rom进行zip包检查，以确保真正拥有这个rom。我觉得cowering应该包含这个检查功能，但默认情况下不使用。 我不是一个dumper，这些信息在很多模拟器的readme.txt中都有部分提及，在一些web网站的资料和bbs中也有一些材料。有些是我自己发现的(bug)。 我对现有的nesbase.dat不大满意，想制作goodnes（1.00）的nesbase.dat，在利用nes模拟器对8000多个nes rom的进行检查时发现了一些问题。不过nes rom的数量实在太可怕了，而且有一些问题无法解决（不理解为什么会这样），初步的dat已经出来的，但要对其进行文字编辑，内容查错，工作量太可怕，时间也不允许，因此不知何时可以完成。 linlin： 为什么我用GOODTOOL整理一些ROM后总出现： You are missing 2143 of 2999 known Sega Genesis/MegaDrive/32X (0.999.6 BETA) ROMS (302 excluded) 这“(302 excluded)”是什么意思？为什么出现这种现像呢？ 怎么修改呀？我不太明白，能不能告诉我具体的方法呀？ 曾经有网友要我把那个文件删掉就好了，这样的话不用那个文件整理出的ROM有没有问题呀？ excluded的意思是不包含。你出现这条提示是因为你可能使用了goodtool包中的goodinfo.cfg文件而没有进行修改，这个文件是goodtool的配置文件，它定义了一些goodtool的行为，默认情况下它在miss文件中不包含baddump（坏的dump）、overdump（过量dump）等文件的列表，因为这些对于一般的rom收集者（使用者）是不需要的（很多都不能玩），也是比较难找的，但对于我等人而言，关键是要都收集全，因此要编辑一下这个文件，可以寻找“;n”将其替换成“;”或“;y”，就会出现完整的列表。 删了没有问题。 你可以使用一个标准的字编辑软件，如ultraedit-32，使用它的寻找并替换（ctrl+R）。或者用windows自带的记事本软件打开这个文件，在[genesis]这个节中（大约50几行），将每行后面是;n 的n删掉 即可。 这个文件同gootool的一些功能有关，如果你只是"goodgen ren"的话，就用不上这些功能，它还有好几种功能（根据系统不同而有所区别），比如可以按ROM的发行国家归类到不同目录，这些功能就要通过这个文件来配置。我建议你多学一些windows的基本操作，编辑文件是基本操作，并不难学，多学一些对各方面都有好处。 对于ines这种结构的缺陷，现在出现一种新的nes rom的格式，叫unif，这种格式挺不错的，多了很多控制字段和描述字段，下一版goodnes就要支持它了。有几个新的nes模拟器也支持了它，不过现有用这种格式的rom不多，但据称新的dump的rom就要使用这种格式。 kengamer： 你的这些dat还是有问题。这些crc可能同cowering手里的rom的crc一样，但它还是错误的，原因我已经解释过了。我举一下例子，比如我用你的dat检查了一下我的goodnes 1.01新的rom，其中有个rom，名为260-in-1.nes，这个rom用你的dat检查是正确的，用goodtool检查也是正确的，因为你做dat用的rom和我的可能是从同一个下的，当然crc一模一样，但是打开这个rom（用ultraedit-32），在文件头部分8-F这八个ines保留区内有垃圾字符（原则上不应有东西），在4，5字节（标注prg-rom、chr-rom大小）为0，即根据文件头这个rom没有prg-rom和chr-rom，这样这个rom根本不能用任何模拟器启动，而假设我知道4,5字节应该填什么，并将8-F填0，这样的rom才是完全正确的，你能说我的rom不是gooddump吗？还有好些rom的文件头根本没有内容（全为0）。而goodtool就比较智能，它检查时排除了文件头这16个字节再检查crc，这样你的和经过我处理的rom都可以被认为是gooddump（为什么说我们的rom都是gooddump，因为真正从nes卡带里dump的内容都是一样的）。但你的gooddump不能算是完全正确的gooddump，而经过修正的才能算完全正确的。想想为什么现在比较好的nester家族和virtuanes这几个模拟器都有根据nesbase.dat修正文件头的功能？并且你仔细看一看这几个模拟器及fceu的源代码（它们都是开放源代码的模拟器），它们除了外部利用nesbase.dat修正rom文件头外，内部还建有特定的修正部分rom文件头的功能。实际上经过我的检查，有的[!]的rom的文件头可能都不一定正确，所以我的nesbase.dat才一直做不出来。但只要dump部分是正确的，总有办法把其他部分修正。 我们再假设你做了一个n64的dat，你的rom都是直接dump出来的z64的格式，而我的却都是byte-swap的doctor64(v64)的格式（有些工具可以在两种格式之间进行转换），这样用你的dat检查我的rom全为错，但是两种格式的差别就是z64为1234，v64为2143（每两个字节都交换一下位置），对于goodtool而言我们俩的都是正确的，而对于RC则我的全为无法识别的rom。 总而言之，不能因为用RC检查不对就认为手里的rom就一定不是正确的，只能说明这些rom同dat制作者的rom不一致。 [yang] 2003-05-16 08:06 PM -------------------------------------------------------------------------------- 不好意思，我不能说你dat是错误的，因为对于校验手头现有的rom而言，你的dat可能同cowering手头的rom一模一样，也是我们最有可能能找到的rom，但对于有多种格式的rom用RC就会出错，而大多数用RC校验goodtool的都是新手（不是说没有老鸟），容易误导。 我看到有人要goodgen的dat，实际上常见的gen rom有两种格式，一种是bin一种是smd，goodgen就内置对其格式的转换，如果有人把所有的gen rom都转为bin格式再放出来，下的人用你做的既有smd又有bin格式（可能）的goodgen dat检查就会认为自己还缺少部分rom。实际上这篇讨论起点就是这种情况。 在 http://opothspants.free.fr/rmd/DATabases.html 访问网址超出本站范围，不能确定是否安全 继续访问 取消访问http://opothspants.free.fr/rmd/DATabases.html 有所有（？）goodtool的dat。 顺便提一下，rmd的mame dat也不能算是完全正确，logiqx的才对。 heimu：SNES的ROM有Hirom和Lowrom两种，Romcenter只认其中的一种，而Goodtools则包含两种Rom的CRC校验。 很久没有摆弄Snes rom了，有些细节记不大清楚了。Hirom和Lowrom是原始的snes卡带rom的组织方式，差别就是lowrom的每个块是32KB，而Hirom的每个块是64KB，Lowrom格式支持最大16MB的ROM，Hirom支持最大32MB（？）的ROM， LoROM: 32kbyte pages/banks (A15 not used - assumed high) HiROM: 64kbyte pages/banks 在smc这个程序中把这两种称为banktype，它同snes 内存映像方式有关(memory map)，因此可以认为16MB以上的ROM都是Hirom。这两种原始格式的rom dump出来后，格式就固定了，因为用于各种磁碟机，各种磁碟机又将其根据自己的定义重新组织成其他格式，而这其他格式才是我们通常讨论的rom的格式。因此可以认为lowrom和Hirom不是我们通常所说的rom格式的分类方式，而是一种区分块大小的一种类型分类方式。 snes Rom 格式有很多种，有分割文件格式和单独文件的格式，分割的格式是将一个Rom文件分成几个文件“.1 .2 .3 .....”及“a b c d ...”，这个格式好象叫GD3 和 MGD2，它一般是将 rom分割成几个如512KB、1024KB大小，再在第一个文件头上加文件头（大小好象也是512字节）（有一种格式没有文件头）。goodtool 只认识合并成单独文件的ROM，而单独文件的rom的后缀名通常为.rom .smc .swc .fig，这些是一些磁碟机的文件格式，这些格式也大多不相同，而goodtool可以认识这些格式并识别（他可能是将其统一转换为某一种格式的rom对其CRC进行判别）。 我举个我遇到的例子。我从网上下来的Tales of Phantasia (J)根据goodsnes判别就是它所认识的rom，但这个rom在被snes9x和zsnes加载时都提示我这不是一个gooddump，而用smc程序判别它也不是一个gooddump，而出现这种情况的原因是在snes rom中第$7fde-7fdf字节（如果有文件头再加$0200（512字节））保存有这个rom的CRC32值，而我手头的这个rom这两个字节都为0，snes gooddump的一般判别标准是计算出来的CRC同这两个字节保存的是否一致，所以它们认为我的不是一个gooddump，我就在这两个字节填入它的crc32，再用goodsnes识别，它还是认为是它所认识的rom，而且模拟器也认为是个gooddump，从这个例子看goodsnes也不是简单地将其统一转换为某一种格式的rom就进行判别，应该是再以类似smc程序的方法进行CRC的检查。 我再重申一遍，Romcenter只知道CRC32，它不能识别任何文件格式，它只能根据dat制作者的Rom的CRC32来识别你的ROM的CRC32同其一致不一致，dat制作者通常是使用goodtool识别完自己的rom后再制作dat，这样同他的rom的crc一致，当然肯定goodtool也可以识别，但对于同dat制作者手头的rom格式不同的goodrom就不能被识别。因此goodtool的RC dat只能作为参考，不能完全作为判别依据。 shawn8888： 您说rmd的mame dat 不对,其实我也发现有问题.有人说可以用RC结合mame.exe直接自己做dat,这样就完全正确了.您说对吗? 再有,您要做的nesbase.dat就是专门用来修正nes roms的头信息的吗? yunm： rmd的mame dat 很好啊 我一直用 比logiqx的全一些 有什么不对的地方吗 rmd的mame dat在一般使用上没有问题，但在部分rom的合并上有问题，根据mame32的显示表明，有些应该合并的它没有合并，有些不该合并的又错误合并，用mame32检查不会出错，但这不是它应有的方式，而用logiqx的mame dat就完全符合合并关系。 用RC生成mame的dat，我在发现logiqx dat的准确性之前一直使用rc 1.91版本对dmame.exe生成新的dat，因为我一直觉得rmd 的dat不对，但经过仔细检查后，我觉得生成的dat不如logiqx的准确，而logiqx又更新得很及时，所以我没有用rc2.xx对mame.exe生成dat，现在logiqx暂停更新，我只好使用rmd的mame dat修正，有时还用rc 1.91生成，因为没有用过不能对rc2.xx以上版本的dat说什么，我只能说1.91版生成的在合并上也有问题。 我刚才仔细看了一下RC的文档，发现新版RC2.5针对nes、snes、genesis rom有专门的plugin进行跳过文件头和文件格式转换的操作，但我试验了http://www.romcenter.com/ 访问网址超出本站范围，不能确定是否安全 继续访问 取消访问http://www.romcenter.com的goodnes/ dat不兼容RC 2.5，而kengamer的dat制作上没有启用新的功能（在[DAT]这个节要加入plugin=nes.dll这句话），我试着加入这句话再对我的1.01新rom进行检查，结果发现全部无法通过，它提示我文件头有问题，我试着修正，结果文件被删除，并且程序崩溃，根据RC论坛上的说法，新的nes plugin有问题，不久会有一个新的修正，snes、genesis dat已制作（我没试，哪位试试？），看来RC也认识到它的问题并试图通过外挂来解决问题，但dat看来要进行特殊的制作，否则可能不能用。实际上这个外挂已经相当于另外制作程序了。制作这样一个外挂可比简单比对CRC32复杂多了，随着RC的不断改进应该会越来越好。可是相比两种工具在针对goodrom的优缺点，当前阶段还是应该使用goodtool，毕竟它是一个专门针对goodrom的工具，新版一出来就可以用，不用等待别人制作dat，不用担心会不会有其他的bug。它的db功能是目前这几种rom工具中最为我欣赏的，我可以把rom刻到光盘上而不必把大量的rom放在硬盘上（毕竟好的刻录盘的寿命比硬盘长多了，现在硬盘动不动就出问题，看看近来的一些模拟界的新闻很多人的硬盘都出了问题，我用柯达的白金盘进行刻录保存），如果tosec能有这功能就好了（tugid还是不够全面和智能，一升级就可能出问题，缺少很多dat）。 我要做的nesbase.dat是要配合这几个现在最好的nes模拟器的修正文件头信息功能的，但难度太大，因为在对这个dat的使用流程上的限制，使得4、5字节必须正确，否则可能就不能正确找到对应的信息（不过在nesbase.dat中还有一栏是all crc不知能不能起作用，还得试试，有些功能得通过猜加试来理解）。还有大量的small dump（就是文件长度小于文件头标识的rom的大小）通常称为Baddump，这些baddump在进行prg-rom crc 和（或）chr-rom crc计算时是0，无法通过这个功能识别；还有一般情况下[!]的应该文件头是正确的，我可以根据这个文件头修正它的其他dump，但看来有部分[!]文件头好象也不大对；再有就是ROM数量8820！！！！还有一些其他方面问题，太难了，现在才体会cowering的艰难，真真佩服他。 应该说以前rmd的mame dat（mame 版本0.5x时）有部分rom有merge（合并）的问题，我刚刚粗粗看了一下，还是存在这个问题。 举个例子：根据mame32和mameinfo.dat的显示Hero是个主集，hero in the Castle of DOOM(DK Conversion) & Hero in the Castle of DOOM(DK Conversion no encrypted)是它的子集，而RMD's DAT表明它们是单独的ROM集，不应进行合并，这样的例子还有3个，所以说它有一些问题。 我试着用RC 2.5对mame.exe生成dat，初步看来完全正确（至少在rmd有问题的rom上是正确的），看来还是用RC2.5生成的dat的准确性比较高。 上一段中我以前发现RMD mame 0.5x dat有问题，刚才我是对RMD mame 0.61 dat进行检查，发现还有问题。（写时没写清楚） shawn8888： 能把dat研究的这么透彻,你已经很令我敬佩了! 能不能教教我怎样把snes的所有roms转为统一的格式.比如我手头的roms有smc,fig两种.我想把它们全部转为smc.我用的是goodwindows结合goodsnes. 另外做这种转化是否安全? 谢谢! 刚才试了一下,好象对snes的转化convert这一项是不可用的.但是对goodgen却可以. 算了,不弄了,还是刻盘吧. 忙了几星期总算把snes收全了.爽! 很高兴能大家一起提高对模拟器的认识。 要在各种格式间转化，对于snes rom有很多工具但都是dos下的，比较著名的有ucon,ctool,snestool及smc（还有一个叫inSNESt，没用过），使用起来都挺复杂的，不是很方便，建议大家如果用得挺好，就不要转着玩（容易出错）。（下面的有些东西记不大清了，两年前摆弄的，可能有些小错）。 ctool：原来很有名，但在Win98后就不能使用了，好象同win98的dos不大兼容。 snestool：最有名的工具，版本1.2，主要用于打IPS补丁（最常用的功能，可用于其他系统），加、去文件头，把ROM在合并、分割之间转化，看ROM的信息和格式，还有一些功能不大常用，前端方式，一些功能使用不当会出错，不过挺好用。 ucon:挺好用的，可用于snes & genesis 系统的ROM。在Winxp下还可用。它可在各种格式间转化，通常用“ucon c ff6.rom（rom名）”，但要注意ROM的后缀，因为每种格式都有一个默认的后缀，如SMC格式的后缀名叫(.smc)，合并的mgd2的后缀叫.rom(?)等等，但并不是叫这个后缀名的都是这种格式，要先使用“ucon ff6.rom”来显示ROM的信息，在将其改名后使用第一个命令转换，如果一个mgd2格式的ROM的后缀为smc则转换时会出错，因为该程序默认：如果是mgd2格式就向smc转化，文件名一样，就会出现自己覆盖自己的情况。它还有很多相互转换的命令，只要运行ucon就会提示你它的使用格式及相应的命令信息。 smc:最终（？）版本为0.o，它可以进行interleave格式同正常格式的互相转化（有时不能进行转化，因为某些特殊芯片的ROM的原始格式就是interleave 格式，必须保持，否则模拟器好象就会出错）。（顺便说一下，snes9x在对interleave格式的rom进行自动格式探测上不如zsnes，有些rom要指定格式才能正常运行，大家可以试一试yoshi's island(E)），它最大的用处就是可以看到rom的一些信息（其他程序不支持的，比如这个ROM的卡带有特殊芯片S-DD1、SA-1、Super FX等及是哪家公司出的等等），同时它可以进行CRC 的运算看这个rom是否为gooddump。看信息就用“smc ff6.rom”或“smc /e ff6.rom”（比较详细），计算CRC“smc /s ff6.rom”。运行smc就会提示它的使用格式及相应的命令信息。 还有几个工具具体记不大清楚了，以前摆弄这些工具主要是要将手头光盘上的分割格式的合并。 由于这些工具都是在dos下使用，而且没有详细的使用文档，加上snes的格式众多，在加上基本上没有转化的必要（一般情况下最好的几个超任模拟器都对格式支持很好），因此不推荐进行统一格式的转化。 convert这个命令选项只针对goodgen，因为genesis的rom格式相对较少，常见好象就这两个，而应众人的要求，cowering就加入了这个功能（在goodgen的文档里有说明）。 实际上统一格式好象对n64的rom比较有用，因为n64 rom的patch都是针对byte-swap格式的rom（常见后缀为.v64），好象以前有些人问过为什么从EC上下的n64 patch不能用，原因就是这个，必须先将[!]的n64 rom转为byte-swap格式再对它使用patch。而且有个很好用的工具叫tool64，windows程序，它支持4种常用n64 rom的格式转换，能直接对zip操作（不用解压缩），转完自动改后缀名并zip，可以进行大量rom的zip和unzip操作（类似于ROM Zipper，只不过只能对n64 rom）。就差一个改文件名了，但配合另一个good系列的外加应用程序（名字忘了）就十全十美了。 我从romcenter上下载（可能要到制作者的站点）了对应RC 2.5的goodgen和goodsnes dat，试了一下goodgen，对我的一张光盘进行测试，容量大概500多MB，结果检查时候非常缓慢，看来可能是在新的plugin起作用了，最后提示我这些都对，就是有些需要改名，约要10几分钟（？），而同样容量的rom，我用goodgen测试，不到一分钟就可以了，速度差别之大令人吃惊，看来除非万不得以，还是不要使用RC检查了。对不对我没看出来（需要多测一下），不过从RC论坛中看来没有问题。 上面提到的忘了名字的good工具就是goodzip（最新版本2.1），它可以直接对zip中的文件名进行重命名（根据zip的文件名），是一个windows程序，它先对zip文件进行一遍扫描生成一个需要改名的zip文件列表，再根据这个文件对zip文件进行重命名。 [yang] 2003-05-16 08:06 PM -------------------------------------------------------------------------------- 雲来也： 順便問一個問題...SFC與N64的ROM裡有遊戲的英文名字...但不知如何更改他...就是用ZSNES執行遊戲時左下角所出現的名字 应该会有一些工具可以修改，但我没有这个需要，也就没注意。 但一个比较简单的办法就是使用16进制编辑软件（如Ultraedit-32）。 SNES：将该ROM用uedit32载入，用寻找功能(Find)寻找该字符串，只要第一个单词即可，注意要将"search for ASCII"前面打上勾，找到即可修改（注意不要超过21个字母，因为后面是其他内容）它的所在位置同文件格式有关，所以我无法给出确切的偏移地址（有的在$7FC0（有文件头加$200），有的在$FFC0（或101C0））。 N64：同它的文件格式有关，一般N64ROM有以下格式 --DWORD formats-- Big Endian - 0123 Byteswapped - 1032 Little Endian - 3210 Wordswapped - 2301 Byteswapped格式默认后缀名是V64，Big Endian格式默认后缀名是Z64，另外两种很少见。n64 rom的文件名从$20（第33个字节）开始，具体允许有多少字节我没研究，但可能为20个字节（看ROM的内容猜的）。如果要比较好修改名字，可以使用tool64将其转换为big endian格式后就可以随意修改，而不必根据格式颠倒顺序。 但要注意有些模拟器内置一个goodtool数据库，它根据数据库显示相应的ROM的good 名，可能修改的内容不一定会显示出来。 刚刚试用了一下UCON的增强版本UCON64（最新版本1.9.8beta4，需要下两个动态链接库，beta3不用）（网址：http://ucon64.sourceforge.net/index2.html 访问网址超出本站范围，不能确定是否安全 继续访问 取消访问http://ucon64.sourceforge.net/index2.html 需要代理），功能真是巨强大，修改名字易如反掌，它支持nes,snes,genesis,gba,pce,neogeo, wsx,ngpx,sms,n64,dc,ps1/ps2(CD Only)等等等等，还有各种磁碟机及各种备份设备（对于GBA备份设备支持中有一种Flash Advance Linker有些名气），还有很多根本没听说过的东西，它的内置数据库认识15216个rom，运行ucon64出来的帮助内容就有300多行，它可以直接对各种机种的rom（CD当然不行）进行直接指定格式的转换，直接改名（内部名），修改部分系统rom的内部CRC值（使其看起来是Gooddump），将模拟器的存档.srm(SRAM)转给磁碟机，也可以把磁碟机的存档转为模拟器的存档文件，内容太多无法一一说明。 要看一个rom的信息，只要运行： ucon ff6.smc（ROM名）即可显示rom的系统，生产商，名字，国家、CRC及各种ROM的信息。 上面所说的改名很容易实现，假设一个n64 rom mario.v64，要将内部名改为MARY，运行这个命令： UCON64 -n --file=MARY mario.v64 对于snes的同样命令格式处理。 对于一般使用者来说可能比较困难的是它是一个命令行工具，但据它主页说有一个java前端可以使用，我未测试。 总而言之，它看起来是一个集各种工具功能于一身的超强工具，强烈建议有意使用者使用。 waterrr： 可能我对文件头的理解有点不对 文件头是家用机rom被dump下来后为了被识别，而被dump加上去的，而所有的家用机rom都有文件头？！只不过是nes的文件头并不只是为了被识别，加了很多“垃圾”信息，所以导致格式混乱 如果是这样的话，每个n64 rom的文件头都可以自己重新改名了吗？以前的名字是dumper加上去的吧？改完文件头，crc也改变了吧？这样就不能用rc检测了..？！ 对于nes而言，因为ines格式比较简单，除了16个字节的文件头，和512字节的trainer（如果有的话）外的内容都是真正卡带上的ROM的内容（部分dump时出问题overdump或baddump除外），而卡带上的rom中没有多余的东西来标识这个游戏的厂家，游戏名等等内容（毕竟是80年代的东西），而因为nes的机器功能比较弱（为了省钱）因此为了延伸它的生命扩展它的功能，很多厂家在卡带中加入了部分芯片来替换主机中的一些芯片的功能，这就是Mapper，而模拟器为了正确模拟这个游戏，就要了解mapper的运作方式及PRG-ROM,CHR-ROM的大小及其他卡带的硬件相关细节，因此文件头就起了一个象备注一样的功能，它是必须的。但因为nes mapper的多样性及游戏本身所需的一些特殊外设超出了ines文件格式设计时的想象，而发起人又不能及时扩展它的相应格式定义（当然要向下兼容），导致很多人都扩展自己的格式，而这些格式有的互相矛盾（比如Smynes支持256的mapper，它占用了$7的低4位作为mapper的第三部分（原来只定义了两部分，最大255），而这同另外一个比较广泛使用的扩展冲突，结果导致一个位置有两种定义），因此ines格式已经无法完全反映nes卡带的内容，所以出现了unif格式，这个格式比较灵活，不再有mapper之说，如果组织者能同dumper通力合作，及时扩展定义，那么可以说它是一个比较理想的格式。实际上ines格式还有可扩展的空间，毕竟还有8个字节没用，而所谓的垃圾信息，就是很多dumper在后8字节写了一些内容（做签名），甚至占用了第$7个字节，可能导致模拟器误操作。 如果垃圾信息只占用后8字节的话，那倒不影响目前的模拟器，毕竟目前还没用到后8字节（但如果以后扩展到后8字节，就会出问题），可以保留也可用一些工具清除，nnnesterj支持这个清除功能，它能把所有非压缩的rom的后8个字节清零。比较麻烦的是占用$7字节的垃圾信息，你搞不清楚到底这个字节应该有东西还是为零，这时可以使用nesdbase.dat配合nnnesterj来变更文件头（动态或永久），问题就是nesdbase.dat内容有限，个别好象不对，所以需要对nesdbase.dat进行扩充修正。 n64最常使用的是v64和z64格式（两者格式区别见上），z64格式的好处是模拟器载入这种rom时，速度比较快，而且某些n64模拟器对这种格式的rom支持较好，而且这种格式的rom在进行压缩后的尺寸较小。v64格式的rom模拟器载入后要进行反交错处理，转化成z64格式，但估计是v64格式的磁碟机比较流行，因此这种格式是网上最流行的格式，n64rom的patch都是针对这种格式的rom做的，至于模拟器的支持性，因为大家都用的是最好最新的模拟器，格式上支持是没有问题的，只是如果你使用较旧的模拟器才会出问题。 绝对正确的ROM要看你如何看：如果是从Goodtool的方面看，各种格式的同一个ROM都是绝对正确的，因为它们都是同一个东西的不同表现形式。但这种正确是指这个ROM同cowering手头的ROM是同一个东西，并且Cowering经过各种检验，认为这个是一个Gooddump或者一个Baddump或者一个Hack版本。但有时他也无法保证一定对，毕竟这些东西是别人Dump出来的，在网上流传经过多少人的手什么事情都可能发生。那些[!]的是有确切的信息来源（通过Redump）告诉Cowering这个ROM的内容同卡带上的完全一致，绝对正确。而对于RC而言，没有绝对正确这一说，只能说它同DAT作者手头的ROM的CRC32一致，而作者手头的ROM又经过Goodtool检验通过，因此反推出你手头的东西如果用Goodtool检验也可以通过。 waterrr：非常感谢YANG兄的指教！！看了你的文章，我又用Ultraedit-32试着把N64 ROM的文件名改了一下，对ROM文件名有了更多的认识 把N64 ROM文件名改变后，用TOOL64不仅能识别，而且还能把改过的文件名显示出来，这样我又有点小问题，如果文件头里的名字可以随意改的话，那文件名是什么不就无关紧要了吗，那这个文件名是DUMPER为了识别游戏而加上的还是游戏卡带里原本就有的呢？？？如果只是DUMPER加上的，如果用Ultraedit-32把文件头的占用空间删除（就是去掉文件头）对ROM使用有影响吗？（不知道能不能）反正GOOD64和模拟器的检测方式都可以略过文件头而直接读ROM本身，对N64 ROM来说，文件头本来就是多余的吧？！ 从我目前了解的情况看，SNESROM有一个（看格式而定，有的没有）文件头，这个文件头是原有格式所定，为512个字节，这个文件头似乎不是很重要，没有也可以，在这个文件头内还有一个ROM信息区，这里记录了游戏的生产发行厂商，游戏名，ROM的速度，CRC32，有没有特殊芯片等等信息，似乎有的还有磁盘机的BIOS（好象在那里有看到这个信息，没有验证），一个ROM去掉文件头512字节（如果有的话）和这些信息区才是真正的游戏ROM区，而信息区记录的CRC32是真正ROM区的CRC32，而一个snes rom是不是interleave好象是指这部分真正游戏ROM区有无interleave，而不是整个文件。从上面看，只要这个真正游戏ROM区是一样的（不管是什么编码格式）都被goodsnes认为是同一个ROM，因此就有可能会出现你将这个信息区的文件名改掉结果goodsnes还是认为是同一个ROM的情况，这就同nes rom的16字节文件头就算是后12个字节全为零也同这个文件头有内容的rom是同一个rom的情况一样。 N64的情况同snes又不大一样，它的v64 & z64格式是对整个文件，就是说整个文件（包含文件头）都是2143或者1234格式，而不是内部某个部分才是这种格式。对于N64ROM更多的格式信息我也不是很清楚，好象这些文件名等信息也是后加的（不敢肯定），还要学习学习再学习。 上面有些东西是我从网上的一些论坛中获得部分信息加上某些试验得来的，有的信息不是很明确，加入了一些我个人的理解。因为都是英文的理解起来比较困难，可能有错的地方，欢迎指正，共同学习。 实际上，snes rom的格式非常复杂，前一阵子snes9x现在的主要的两个编程人员（非正式，但是目前唯一活动的两个半正式人员）之一MK（snes9x1.39mk的作者）还在论坛上问一些snes rom格式的问题，连主编程人员都有些东西搞不清楚，可以想见格式的复杂。我前面说过Hirom支持最大32MB的游戏ROM，但有几个游戏的容量超过了32MB，那这几个rom是什么格式呢？从那次讨论的内容看，48MB的游戏TOP的ROM是由两个完整格式的ROM合成，一个32MB，一个16MB，在读取这个合并的rom时要进行特殊处理，对第二部分的ROM也要进行解析，把真正ROM区提出来，40MB的游戏也类似这样。够复杂吧！ [yang] 2003-05-16 08:10 PM -------------------------------------------------------------------------------- 新的内容：（2003-5-6） crj_hyj：以前RC的GOODGEN DATA都有BIN和SMD两种格式，有没这两种之间的转换工具？ 还有就是SFC的ROM以前用RC来扫的话总有些ROM不齐，能不能用你给的SMC工具转换ROM来补全呢？ 答： SMC只能转snes的ROM（不一定是SMC格式的才行），具体用法运行一下它就有提示，而Gen的ROM也有一个对应的工具叫SMD（smd.com），不过不如SMC有名。这两个工具功能比较有限，我主要用于计算ROM的CRC32看是否与ROM内部保存的CRC32值一致，以此来初步确定是否为Gooddump。 以前比较有名的转ROM的工具主要有ctool和ucon，这些是我以前常用的，对snes和gen的ROM都可以使用，有对应的命令行选项。现在有个工具继承了ucon的优点，又不断在增加新的功能，就是UCON64，我在新闻更新区有它的更新新闻和主页地址，最新是1.9.8beta8，有很多修正和新功能，但它去掉了内部的ROM数据库（变成支持romcenter dat），我试一下好象在运行dos重定向命令（>）时会出错，因此我还用beta7。 如果只是需要把GEN的ROM从SMD格式转换为BIN格式，可以直接使用goodgen这个工具，运行goodgen convert就可以把所在目录下所有SMD格式的ROM转换为BIN格式的ROM，但它只能用于Goodgen可以识别的ROM，如果你手头的md rom还不能被goodgen所识别，就不起作用了。 我再简单说一遍，Good系列的ROM要用Good工具来识别是最为准确的，RC的DAT只是记录DAT制作者手头的SNES ROM的CRC32值，如果你手头的同作者手头的ROM是同一个ROM，但格式不一样就不能用RC识别出来，你可能到处去找这个ROM都找不到，却把手头正确的ROM删掉了。 Good系列中的Nintendo和SEGA的很多机种的ROM都有多种格式，此外很多可以添加文件头(header)，这时整个文件的CRC32就变化了，但你不能否认你手头的ROM是正确的那个ROM。 Good系列工具可以不管ROM的格式及文件头，识别出它可以识别的对应的ROM，而RC用DAT却不行（这就是它死板的地方），新版的RC也意识到这个问题，并试图通过DLL（实际上也就是一个外部程序，已经不是RC原始的方式了）来做到Good系列工具的效果，但因为DLL还有问题，因此目前还是存在不能识别各种格式ROM的问题。 因此你不必拘泥于手头的ROM同DAT中的一致，只要用goodsnes可以识别就可以了，不过如果你一定要一样的话，用这些工具应该（理论上，如果没有人闲着没事干乱改ROM再做DAT的话）可以得到那些CRC32一样的ROM，但你首先要猜对方手头的snes rom是什么格式、有没有文件头等等再来进行转换尝试。 [yang] 2003-05-16 08:15 PM -------------------------------------------------------------------------------- （2003-5-5） shadow-zero： 为什么这个SFC游戏无法模拟？ daisenryaku expart ww2 (j).zip ZSNES，SNES9X，SNEShout，改版的SNES9X我都试过了，都无法模拟………… ROM是在EC下的………… 答： 这个游戏是一个FX Chip(SA-1)特殊芯片游戏，使用这个芯片最有名的游戏就是Mario RPG，但这个芯片的模拟并不完全，在zsnes的readme.txt中有“Several special chip emulation (SA-1) have unknown bugs to them”（一些特殊芯片的模拟(SA-1)有未知的Bug），而snes9x提到它模拟了SA-1的大部分特性，足以玩作者所找到的三个使用这个芯片的游戏，但这三个游戏中并没有这个游戏。 因此有些SA-1游戏无法模拟是正常的。 但这个游戏无法运行的原因是：从EC下载的这个ROM是一个normal(noInterleave)格式的ROM，不能玩，我手头的是Interleave格式的ROM却可以玩，因此该问题估计出现在模拟器处理这些特殊芯片的ROM的方式上，可能它们假定这些SA-1 ROM都应该是Interleave的，因此处理上就出现了问题。我用smc这个工具把它转成interleave格式的rom就搞定了。目前这个问题好象是通病，只能通过转ROM解决（实际上你手头的这个ROM也是经过某些人转过的，否则原始的不应该会出这个问题），我已在snes9x的开发论坛上提出这个问题，不知道会不会解决。 这也提醒我们某些完美主义者，不必太拘泥于ROM格式的统一，我原来也曾经想把手头的goodsnes rom统一转换为一个smc格式，把interleave格式转换为normal格式，但好象也是因为发现了这个问题才罢手的。 转换命令： smc /ci d2.smc new.smc（我把那个rom改名成d2.smc，因为原来是长文件名，转换后的ROM名字为new.smc） 根据snes9x开发论坛上开发者给我的答复： The Dumper：SA-1的ROM原始状态就是Interleave的，而noInterleave格式的SA-1 ROM是某些人自己用工具（可能是用SMC）转的，在任何磁碟机上都不能运行，也不存在这种ROM（原生），因此不应该认为是Snes9x的问题。 Nach：如今知道有这种畸形的ROM存在，可能在模拟器中添加对这种ROM的纠正。 唧唧男 2003-07-12 10:01 PM -------------------------------------------------------------------------------- 写的很好，表扬！！！！:HAAA babyone 2003-07-21 03:35 AM -------------------------------------------------------------------------------- 绝对长知识！解决了很多原先一直盘绕在心头的问题，尤其是用RC整理GOOD ROM时的困惑，大感激~~ airholder 2003-09-17 02:58 PM -------------------------------------------------------------------------------- 嗯，获益匪浅 qoo61521 2003-10-20 11:22 AM -------------------------------------------------------------------------------- 高手. 好文章... alexhouww 2003-10-22 09:45 AM -------------------------------------------------------------------------------- 看了一个小时，太棒了 zsyf 2003-11-08 11:45 AM -------------------------------------------------------------------------------- 绝对的好东东！收藏ing! sonicada 2003-11-27 02:37 AM -------------------------------------------------------------------------------- 我只想收集[!]的ROM 我想問一下要刪除Excluded的ROM,用什麼方法比較快與保險? 精華區說用尋找功能來刪除,但是我覺得此方法不保險. 還有就是用指令的goodxxx ren dirs來做分類,然後 最後再把BadDumps與OverDumps資料夾刪除. 但是此方法只能刪掉BadDumps與OverDumps的ROM. 而且會分類出一些有的沒有的資料夾. 但是我想把除了[!]之外其他都要刪掉,要如何辦到? 我的想法是修改Goodinfo.cfg內容. 加入[!]:GoodDumps;;y 其他行刪掉. 這樣執行Goodxxx rename dirs 就會把[!]的ROM分類到GoodDumps資料夾裡面去, 而其他的ROM就沒有分類到而可以方便刪掉.這樣就只有 留下[!]的ROM.然後再把xxxx.db與xxxmiss.txt xxxHave.txt檔刪掉, 在重新Rename一次,再去看xxx.miss所缺的ROM,再去網路上下載 所Miss的ROM,下載完之後,就算把[!]的ROM補完了. 我這樣的做法對嗎? [!]:GoodDumps;;y 上面這一行的y是代表沒有Excluded的ROM嗎? 也就是說在xxxMiss.txt裡面看到的都是[!] 的ROM名字,也就是我想要收集的ROM,不知我的 說法是否正確? 希望各位能不吝告知,不勝感激,謝謝. love_liangjuan 2005-08-20 07:14 PM -------------------------------------------------------------------------------- 那VCD上的8位游戏的bin,dat文件怎么转换成nes呢？ 所有时间均为格林威治时间+8。现在的时间是 08:39 PM. Powered by: vBulletin Version 3.0.0 Translate by: CNVBB Studios Copyright ?2000 - 2006, Jelsoft Enterprises Ltd. http://www.bjsgm.com/a/a.asp?B=101&ID=12
|
