News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Internal Name of N64 ROM  (Read 5346 times)

inthenameofDT

  • Newbie
  • *
  • Posts: 3
    • View Profile
Internal Name of N64 ROM
« on: April 02, 2015, 09:12:47 pm »
Hey, I've read a couple of old posts on the matter, and through a couple hours of trying to make something work, it seems I am unable.

What I am trying to do is change the internal name of, in this case, Zelda's Birthday, in order to give it its own set of savestates. I read a bit about editing the project64.rdb file, but in truth this just isn't my forte. If there is anyone that could help, I would greatly appreciate it. Thanks

DT

Jorpho

  • Hero Member
  • *****
  • Posts: 4182
  • The cat screams with the voice of a man.
    • View Profile
Re: Internal Name of N64 ROM
« Reply #1 on: April 03, 2015, 02:21:18 am »
How about http://www.romhacking.net/utilities/791/ ?

I read a bit about editing the project64.rdb file, but in truth this just isn't my forte.
Perhaps you have a specific question in mind?
This signature is an illusion and is a trap devised by Satan. Go ahead dauntlessly! Make rapid progres!

Zoinkity

  • Hero Member
  • *****
  • Posts: 562
    • View Profile
Re: Internal Name of N64 ROM
« Reply #2 on: April 03, 2015, 09:27:22 am »
Internal name starts at 0x20, 0x14 bytes long.  It can be freely edited without worrying about checksums and the like.
To be honest, the bytes leading up to the 5-byte game ID are unused, but things that read the name won't read up past 20 bytes.

Database entries will look something like this:
Code: [Select]
[DBF4EA9D-333E82C0-C:45]
Good Name=Snowboard Kids (U)
Internal Name=SNOWBOARD KIDS
...
The DBF4EA9D-333E82C0 above is the ROM checksum found at 0x10-0x18.  The country code--C: above--is the byte at 0x4E.  I believe only that first line is used to detect the game, and although different emus use the rdb file different ways PJ64 probably displays the actual internal name, not the one on this list.

If you make a new hack that alters the checksum and expect HLE emus to play it you need to copy the original game's existing entry and paste it in, changing that checksum + country code entry.

inthenameofDT

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Internal Name of N64 ROM
« Reply #3 on: April 03, 2015, 01:39:31 pm »
How about http://www.romhacking.net/utilities/791/ ?
Perhaps you have a specific question in mind?

This tool simply does not work on my machine. Thanks though!

April 03, 2015, 01:40:48 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Internal name starts at 0x20, 0x14 bytes long.  It can be freely edited without worrying about checksums and the like.
To be honest, the bytes leading up to the 5-byte game ID are unused, but things that read the name won't read up past 20 bytes.

Database entries will look something like this:
Code: [Select]
[DBF4EA9D-333E82C0-C:45]
Good Name=Snowboard Kids (U)
Internal Name=SNOWBOARD KIDS
...
The DBF4EA9D-333E82C0 above is the ROM checksum found at 0x10-0x18.  The country code--C: above--is the byte at 0x4E.  I believe only that first line is used to detect the game, and although different emus use the rdb file different ways PJ64 probably displays the actual internal name, not the one on this list.

If you make a new hack that alters the checksum and expect HLE emus to play it you need to copy the original game's existing entry and paste it in, changing that checksum + country code entry.

That all makes sense, but for Zelda's Birthday using the Ocarina of Time Debug rom, which entry would I need to copy and paste? I saw a post you made elsewhere helping someone with The Final Star. But I'm wondering how you come up with the new 0x10-0x18 number? I should note that I'm not making any new hack, I simply want PJ64 to recognize hacks differently from the original game so that shared savestating can be avoided.
« Last Edit: April 03, 2015, 02:32:10 pm by inthenameofDT »

hex_usr

  • Jr. Member
  • **
  • Posts: 19
    • View Profile
Re: Internal Name of N64 ROM
« Reply #4 on: April 03, 2015, 05:17:02 pm »
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++).

Zoinkity

  • Hero Member
  • *****
  • Posts: 562
    • View Profile
Re: Internal Name of N64 ROM
« Reply #5 on: July 07, 2015, 08:11:35 pm »
I know this is an older topic, but besides the linked algo disappearing with Google Code soon it also lacks support for the full range of N64 titles.

This one supports all N64 CICs, including the Aleck64 and 64DD IPL.  It also lets you calculate the bootstrap checksum in case you want to burn a unique CIC for a custom bootstrap.  Note IPL and Aleck checksum algos work on different memory sizes.
http://www.mediafire.com/view/wwy88kc9h1d8dew/N64.py

The header names are actually codepage-932, though by design the two intersect quite well.

Code: [Select]
0x0 4 intial PI settings
80000000 indicator for endianess
00F00000 initial PI_BSD_DOM1_RLS_REG
000F0000 initial PI_BSD_DOM1_PGS_REG
0000FF00 initial PI_BSD_DOM1_PWD_REG
000000FF initial PI_BSD_DOM1_LAT_REG
0x4 4 clockrate
FFFFFFF0 ClockRate; if 0 uses default rate
0000000F unknown
0x8 4 boot address; depending on the CIC used may require alteration
0xC 4 release; unused by all known commercial carts
0x10 8 checksum
0x18 8 RESERVED
0x20 0x14 internal name, using codepage 932
0x34 7 RESERVED
0x3B 1 format: {'N':cart, 'C':combo cart+disk, 'D':disk, 'Z':Aleck64}
0x3C 2 gameID
0x3E 1 region code
0x3F 1 version, fixed decimal (ie: 00 = 1.0, 15 = 2.5)
0x40 0xFC0 bootstrap code copied to A4000040 and run by PIFRAM, containing the cart CRC algo and booting game code