Забавная ситуация получается...
Прописал калькулятор CheckSum для SNES, оказывается большинство ромов неправильную контрольную сумму имеют
, и что ещё более забавно, меняешь сумму на верную...
открываешь в одном эмуляторе неправильная колнтрольная сумма... в другом, - правильная, как можно написать хороший эмулятор если даж контрольную сумму посчитать не могут!
Народ ромы хачит, ну ладно неправильную контрольную сумму вписал, ну ты хоть комплимент к контрольной сумме введи правильно, google не молчит, но то что нашел по этому поводу вызывает приступы смеха в перемешку с приступами булемии...
например вот:
ROM Checksum (2 bytes)
The checksum is a 16bit word with the lower 8bits stored first, followed by the upper 8bits.
The checksum is calculated by dividing the ROM into 4Mbit chunks then adding all the bytes in these chunks together. Once you have the checksum for each chunk, add them together and take the lower 32bits of the result.
With a non-standard image size, you do not get it equally divisible by 4Mbit (excluding 2Mbit images). e.g. 10Mbit = 4Mbit + 4Mbit + 2Mbit chunks.
Therefore, you must create a 4Mbit chunk from what is left over. Using the same example, you would add the checksum of the following chunks to get the ROM checksum:
4Mbit + 4Mbit + (2Mbit + 2Mbit)
or
4Mbit + 4Mbit + (2 x 2Mbit)
Вот чё загон написан?
Сам то читал?
Если коротко:
- Посчитать сумму можно просто, берем делим ром на куски по 4 мегабита, суммируем байты в этих кусках, потом прибавляем оставшийся кусок берем нижние 32бита (реально берем 16 нижних битов, ну автор не посчитал нужным перечитать написанное перед публикацией 
) и получаем сумму
а не проще всё просуммировать?!?!! Ах да, если принять на грудь литрушку, становиться понятно что последний кусок надо таки помножить на два перед суммированием!
Ток алгоритм всёравно неправильный! Если взять 12-ти мегабитный ром уже неправильная контрольная сумма.
Вот тут ваще гомосятина написана, и ещё назвали язык "С" чудовищьным, из за того что долго считает, ну дык правильно, кувалдой сложно чай пить!
fseek(fp,0,SEEK_END);
endofrom=ftell(fp);
fseek(fp,0,SEEK_SET);
for (romoffset=0; (romoffset+rhoffset)<=endofrom-1; romoffset++)
{
fseek(f, romoffset+rhoffset, SEEK_SET);
fread(obbuffer, 1, 1, f);
checksumvalue=(checksumvalue+*obbuffer);
}
Вот так детки не надо писать код для "С" Чудовищно
, я просто о..ел увидев такое издевательство над кодом, после чтения байта и так сдвигается на след позицию, вот это зачем
fseek(f, romoffset+rhoffset, SEEK_SET); , типа контрольный в голову? Вначале перешли на следующую позицию потом её поставили, ага, специально выделили массив под 1 байт, и читаем в него... неописуемая фантазмогория, а попросту, - уродство.
А в конце резюме от этого чела, - код медленный потому что язык Си идеотический, эт не язык Си идеотический, эт наполение мозга такое...
я бы вот так написал:
fseek(fp,0,SEEK_SET);
while(!feof(fp))
checksumvalue+=fgetc(fp); И строчек меньше, и работает быстрее, и тож самое, тока всёравно это неправильно!!!
В общем приложил калькулятор, у кого какие идеи по этому поводу будут?
Вот например ROM с этого сайта, контрольная сумма неверная, по сути во всем архиве с верной контрольной суммой тока 4 файла, если правильно помню (после двойного двоеточия значение которое должно быть, до, - значение записанное в роме)...
P.S.
Бесит не то что мало инфы, а то что вранья навалом.
Попрежнему не могу понять, почему людям не интересно узнавать новое и разбираться в сути вещей, ведь пугает-то неизвестное...
