The Past Memory 2006

shawn8888
初级会员

注册日期: Jun 2002

刚才下了goodsnes 0.999.5校验了一下几个RC不能识别的roms.的确是可以通过的.
这就奇怪了:
照理说,goodsnes用来校验goodsnes的rom是最权威的,那么RC的Dat就是垃圾了?因为明明是好的roms,RC的Dat却显示CRC错误!如果说1,2个还可能是那个Rob van der Drift自己弄错了,但我发现这样的roms有几十个之多!
只有两种可能性可以解释:
1.Rob van der Drift.是白痴,把goodsnes转成RC的dat时大量的CRC数据都弄错了.
2.GoodSNES根本不是用CRC32来校验,是通过其它方法

这两种怀疑到底哪种对呢?还请高手指教!
------------------------------------------------------------------------
chris_gift
初级会员

shawn8888, u really silly to say someone stupid!
at first, the dat for RC is translated from goodtool, that means the reasult in goodtool must be correct, any difference between RC and Goodtool that means the translation got something wrong. Unstanding!
Secondly, If u think the dat for RC is better, that is up to u.
Lastly. YMKK said many times that all the roms of Good series are managed by "Good tool", if u find any CRC error on the rom which caused by RC or RM or others, that is your problem, not him or anyone.
------------------------------------------------------------------------
DQANDFF456
來自未知世界的人

注册日期: Jul 2002

嗯~~的確
整理good roms就一定要用good tool整理
用rc整理good roms的出錯率太多了!!
其實真正要整理遊戲
good roms就用good tool整理
其他的就用cm整理
真的只有rc專用的dat才用rc整理
------------------------------------------------------------------------
shawn8888
初级会员

注册日期: Jun 2002

@chris_gift
yea,it is true that ymkk had said it many times. But the problem is : the result of goodtools is much diffrient with the one of RC. I can't see which is right. So I ask if goodtool adjust roms by CRC or the maker of RC's dat make a big mistake.

@DQANDFF456
你说的其实我也知道,毕竟goodtool是good系列数据库的维护者,只有他们的数据最可靠,但我不解的是,既然如此,为什么还要弄什么错误的dat让人家去校验呢?浪费时间不说,混淆是非啊!你说这样的dat制造者是不是该骂呢?(而且也没见有什么修改版发布,照理说,这种错误是非常容易发现的啊!
------------------------------------------------------------------------
chris_gift
初级会员

注册日期: Apr 2002

@shawn8888,
Firstly, i want to ask u "Do u know how to write a programmer?"
if i am "Rob van der Drift", i will write a program to translate the Goodtool to RC's data, in the translation processes, we cannot ensure that the "result" is same as the original one, that same as we emulate the PS by PSX emulatar. we need to give the time which let the program become correct. understand?
if u angry that why he released the dat file so early, why u don't angry the PSX emulatar release so early (still have many bug in there)??
------------------------------------------------------------------------
DQANDFF456
來自未知世界的人

注册日期: Jul 2002

我想是作者為了方便rc的使用者;所以把dat轉到rc上,可惜錯誤率高
反正以後都用goodtool整理就ok了
shawn8888兄放輕鬆點吧^^不要為了這小事煩惱
畢竟遊戲是用來娛樂放鬆的;不是嗎??
------------------------------------------------------------------------
shawn8888
初级会员

注册日期: Jun 2002

In fact I am a programmer. Of course I had bugs in my program. but what I know is I should fix them as soon as possible!
If the Rob van der Drift check roms by the dat files made by him , he would find the error immediately. But obviously, he didn't do that!
Anyway. thank you DQANDFF456 and chris_gift . I will check all my goodXXX roms with Goodtools. Never do that with RC dats from now on.
BTW, in my opinion, I think RC is a great tool and is much better than CM and Goodtools, for it is easy to use! When I see all my roms is green , the feeling is so wonderful!
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

其实这个问题很简单。在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刻入光盘，而不必将它们放在硬盘上。
------------------------------------------------------------------------
shawn8888
初级会员

注册日期: Jun 2002

果然是高手啊!
其实我也一直在怀疑GoodTools不是单纯用crc32来校验这么简单.
不过这样一来,可能多个CRC不一样的文件都能通过GoodTools的校验.这倒是蛮混乱的.yang朋友有没有兴趣写个中文的教程让大家学习一下啊?呵呵!
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

这方面涉及的东西太多，要写成通俗易懂的很难。实际上CRC32并不是标识唯一ROM的最好方法，在一些条件下人们可以生造出CRC32一样的文件，最好的例子就是mame中现在唯一缺少的raflsiau，前一阵子网上出现一个zip，CRC32同需要的文件一模一样，但却不能玩，实际上这是个生造出来的rom。现有一些用rc校验会出错的系统都是一些比较流行的系统，而这些系统文件格式特别多，这些文件格式大多是盗版的产物，各种各样的磁碟机有各种各样的文件格式，同样的一个游戏ROM被dump下来后，在不同机器上就被改造为该机器的格式，主要是为了谋利，因为那些dumper有很多都是为生产这些机器的公司服务的，如果你的游戏在其他机器上可以玩，那就不必买你的机器了。这些格式的rom只不过是同一个游戏的不同文件格式而已，比如一个文件的内容为12345678，而另一个文件内容为21436587，看起来两个文件不一样，但实际内容却一样，再假设有个文件内容为SNES12345678，它同第一个文件的区别是多了四个字符，但主内容是一致的，因此对于不同的CRC的文件有可能对应同一个正确dump的游戏。关键在于模拟器懂得如何读取并转换这些格式的文件，只要转换后的内容一致即可。因此不应认为CRC32不同就不是同一个ROM，也不应认为CRC32相同就是同一个ROM，但对于街机ROM在一般自然情况下（排除生造的情况），CRC32可以作为检验的标识。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

对于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这个工具。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

在所有系统中以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
初级会员

注册日期: Jun 2002

@yang
老兄不会是dumper吧?怎么知道的这么清楚?
很多和我以前的猜想一样,又学到一点知识.
有一个奇怪的问题是goodtool居然连zip包的完整性都不检测就能知道rom的好坏.这一点我碰到过,但还是很奇怪.
------------------------------------------------------------------------
linlin
初级会员

注册日期: Jul 2002

这么些行家呀，能帮帮我吗？

为什么我用GOODTOOL整理一些ROM后总出现：
You are missing 2143 of 2999 known Sega Genesis/MegaDrive/32X (0.999.6 BETA) ROMS (302 excluded)

这“(302 excluded)”是什么意思？为什么出现这种现像呢？
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

linlin:
excluded的意思是不包含。你出现这条提示是因为你可能使用了goodtool包中的goodinfo.cfg文件而没有进行修改，这个文件是goodtool的配置文件，它定义了一些goodtool的行为，默认情况下它在miss文件中不包含baddump（坏的dump）、overdump（过量dump）等文件的列表，因为这些对于一般的rom收集者（使用者）是不需要的（很多都不能玩），也是比较难找的，但对于我等人而言，关键是要都收集全，因此要编辑一下这个文件，可以寻找“;n”将其替换成“;”或“;y”，就会出现完整的列表。

Shawn8888:
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
初级会员

注册日期: Jul 2002

怎么修改呀？我不太明白，能不能告诉我具体的方法呀？

曾经有网友要我把那个文件删掉就好了，这样的话不用那个文件整理出的ROM有没有问题呀？
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

删了没有问题。
你可以使用一个标准的字编辑软件，如ultraedit-32，使用它的寻找并替换（ctrl+R）。或者用windows自带的记事本软件打开这个文件，在[genesis]这个节中（大约50几行），将每行后面是;n 的n删掉
即可。
------------------------------------------------------------------------
linlin
初级会员

注册日期: Jul 2002

哦~~好复杂，谢谢你的解答。

不过我有一点想不通，删掉goodinfo.cfg也对ROM没什么事的话，何必要这个文件呢？在说还那么麻繁。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

这个文件同gootool的一些功能有关，如果你只是"goodgen ren"的话，就用不上这些功能，它还有好几种功能（根据系统不同而有所区别），比如可以按ROM的发行国家归类到不同目录，这些功能就要通过这个文件来配置。我建议你多学一些windows的基本操作，编辑文件是基本操作，并不难学，多学一些对各方面都有好处。
------------------------------------------------------------------------
shawn8888
初级会员

注册日期: Jun 2002

谢谢yang!
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

不用谢。
对于ines这种结构的缺陷，现在出现一种新的nes rom的格式，叫unif，这种格式挺不错的，多了很多控制字段和描述字段，下一版goodnes就要支持它了。有几个新的nes模拟器也支持了它，不过现有用这种格式的rom不多，但据称新的dump的rom就要使用这种格式。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

你的这些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]
初级会员

注册日期: Jul 2002

不好意思，我不能说你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 有所有（？）goodtool的dat。

顺便提一下，rmd的mame dat也不能算是完全正确，logiqx的才对。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

很久没有摆弄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
初级会员

注册日期: Jun 2002

yang兄
您说rmd的mame dat 不对,其实我也发现有问题.有人说可以用RC结合mame.exe直接自己做dat,这样就完全正确了.您说对吗?
再有,您要做的nesbase.dat就是专门用来修正nes roms的头信息的吗?
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

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进行跳过文件头和文件格式转换的操作，但我试验了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的艰难，真真佩服他。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

应该说以前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的准确性比较高。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

上一段中我以前发现RMD mame 0.5x dat有问题，刚才我是对RMD mame 0.61 dat进行检查，发现还有问题。（写时没写清楚）
------------------------------------------------------------------------
shawn8888
初级会员

注册日期: Jun 2002

能把dat研究的这么透彻,你已经很令我敬佩了!
能不能教教我怎样把snes的所有roms转为统一的格式.比如我手头的roms有smc,fig两种.我想把它们全部转为smc.我用的是goodwindows结合goodsnes.
另外做这种转化是否安全?
谢谢!

刚才试了一下,好象对snes的转化convert这一项是不可用的.但是对goodgen却可以.
算了,不弄了,还是刻盘吧. 忙了几星期总算把snes收全了.爽!
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

很高兴能大家一起提高对模拟器的认识。

shawn8888:
要在各种格式间转化，对于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系列的外加应用程序（名字忘了）就十全十美了。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

我刚刚看到在模拟器教学社区里有UCON & CTOOL的使用介绍，没看内容。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

我从romcenter上下载（可能要到制作者的站点）了对应RC 2.5的goodgen和goodsnes dat，试了一下goodgen，对我的一张光盘进行测试，容量大概500多MB，结果检查时候非常缓慢，看来可能是在新的plugin起作用了，最后提示我这些都对，就是有些需要改名，约要10几分钟（？），而同样容量的rom，我用goodgen测试，不到一分钟就可以了，速度差别之大令人吃惊，看来除非万不得以，还是不要使用RC检查了。对不对我没看出来（需要多测一下），不过从RC论坛中看来没有问题。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

上面提到的忘了名字的good工具就是goodzip（最新版本2.1），它可以直接对zip中的文件名进行重命名（根据zip的文件名），是一个windows程序，它先对zip文件进行一遍扫描生成一个需要改名的zip文件列表，再根据这个文件对zip文件进行重命名。
------------------------------------------------------------------------
雲来也
初级会员

注册日期: Mar 2002

順便問一個問題...SFC與N64的ROM裡有遊戲的英文名字...但不知如何更改他...就是用ZSNES執行遊戲時左下角所出現的名字
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

应该会有一些工具可以修改，但我没有这个需要，也就没注意。
但一个比较简单的办法就是使用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 名，可能修改的内容不一定会显示出来。
------------------------------------------------------------------------
雲来也
初级会员

注册日期: Mar 2002

yang大大真是強...
不過內容太深了...至少有個方向
再次說聲謝謝
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

刚刚试用了一下UCON的增强版本UCON64（最新版本1.9.8beta4，需要下两个动态链接库，beta3不用）（网址：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前端可以使用，我未测试。

总而言之，它看起来是一个集各种工具功能于一身的超强工具，强烈建议有意使用者使用。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

上面要看rom信息，应该是运行:
ucon64 ff6.smc
写错命令了，不是ucon。
使用这个工具前要好好看一下它的说明，可以运行：
ucon64 >ucon64.txt
来获得它的帮助信息（保存在ucon64.txt中）。转换改名等操作前最好备份一下你的rom，虽然它对文件进行修改时会备份原来的文件，但小心为妙。
------------------------------------------------------------------------
waterrr
初级会员

注册日期: Apr 2002

yang兄你好，看了你的文章真是受益非浅，可我理解有限，还有很多地方是懂非懂，想再请教你

假设说nes rom有文件头是由于历史原因造成的，最初因为商业上的原因被dump，用途是用在不同的兼容机上，所以rom被人为的加上了不同的文件头，就形成了不同的版本。
如果我上面的理解对的话，那么请问有什么方法可以把这些文件头或里面的垃圾信息去掉？毕竟它们并不属于游戏本身，对游戏来说只不过是一堆垃圾信息？！难道只能像你提到的最好的解决方法是redump？改变原有的格式才能彻底解决这个问题？比如unif格式？！

还有snes，snes rom文件头的形成原因是由于游戏本身存在不同的格式？没有被人为的添加垃圾信息？！所以只要把snes rom转换成统一的格式，比如smc，那么它们的crc就因该全部一样，并且可以同时被good和rc识别，就不会再有能被goodsnes识别而rc不能的现象了是吗？但还有如你提到的，有的ROM还是存在文件头，那这些文件头是dumper添加的还是游戏本身就具有的呢？

另外n64 rom的z64和v64格式之间有什么区别呢？？哪种格式更好一点？如果把n64 rom都转换成v64的格式，那么这些rom也同snes的smc一样能同时被goodn64和rc识别，也就是绝对正确的rom了，对吗？

我是外行，说错请别见怪！因为我只想收集“完全”正确的rom，看了你的所写的文章后虽然明白了一些这方面的知识，可是却疑惑更多了.....

ps：没有文件头的snes和统一了格式的snes、n64、ren rom都可以用rc来检测了是吗？这样的情况下rom的正确率就因该是100%了吧？！
------------------------------------------------------------------------
waterrr
初级会员

注册日期: Apr 2002

可能我对文件头的理解有点不对
文件头是家用机rom被dump下来后为了被识别，而被dump加上去的，而所有的家用机rom都有文件头？！只不过是nes的文件头并不只是为了被识别，加了很多“垃圾”信息，所以导致格式混乱
如果是这样的话，每个n64 rom的文件头都可以自己重新改名了吗？以前的名字是dumper加上去的吧？改完文件头，crc也改变了吧？这样就不能用rc检测了..？！
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

对于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个字节，可能导致模拟器误操作。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

如果垃圾信息只占用后8字节的话，那倒不影响目前的模拟器，毕竟目前还没用到后8字节（但如果以后扩展到后8字节，就会出问题），可以保留也可用一些工具清除，nnnesterj支持这个清除功能，它能把所有非压缩的rom的后8个字节清零。比较麻烦的是占用$ 7字节的垃圾信息，你搞不清楚到底这个字节应该有东西还是为零，这时可以使用nesdbase.dat配合nnnesterj来变更文件头（动态或永久），问题就是nesdbase.dat内容有限，个别好象不对，所以需要对nesdbase.dat进行扩充修正。
------------------------------------------------------------------------
[yang]
初级会员

注册日期: Jul 2002

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检验也可以通过。
------------------------------------------------------------------------