The formula for calculating the checksums of Nintendo 64 ROMs can be found on Google Code
, so grab it before the end of the year when Google Code shuts down. Checksums are only calculated for the 0x100000-byte area between 0x1000 and 0x101000.
This is a problem that needs to be addressed by the emulator developers. It should not be the ROM hacker's responsibility to work around the defective-by-design emulator behavior. Naming save states and save RAMs after internal names is just asking for errors up the wazoo. Did you know that the unhacked versions of The Legend of Zelda: Ocarina of Time Master Quest have the same internal name as the regular non-Master Quest versions ("THE LEGEND OF ZELDA")? They even use a different SRAM format, so if you save your game in one version and load the other, you will get gibberish in your save files. Both versions were officially developed by Nintendo.
The Nintendo 64 internal header is encoded in Shift JIS. For English names that use ASCII characters, Shift JIS is fine, but there are Japanese games that write their internal names in half-width katakana. These games will not play nice with non-Japanese operating environments unless the emulators that run them convert them to Unicode before saving and loading SRAM files and save states.
In addition, nothing prevents filename-incompatible characters such as slashes from being stored into the header. Project64 guards against forward slashes ( / ), colons ( : ), and backslashes ( \ ), but other characters such as asterisks and question marks will crash Project64 if used in filenames.
I would publish a tool to simulate higan-like cartridge folder support for Project64 (complete with putting save states into a "Project64" folder inside the cartridge folder), but cartridge folders are really unpopular (besides, I foolishly wrote it in Ruby, not C++).