User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
super_mario_64:console_compatibility [2018/03/04 12:09] david [Console compatibility with SM64 ROM hacks] |
super_mario_64:console_compatibility [2018/03/04 16:29] (current) david [Trying to write to the framebuffer's area of memory (8038F800-803FFFFF)] |
||
|---|---|---|---|
| Line 24: | Line 24: | ||
| To fix this issue, we will have to look through the entire ROM file and adjust every 0x17/0x18/0x1A level script commands that have odd ROM address values. Thankfully, some people have made tools to do this automatically [[https://smwc.me/1374314|like queueRAM's sm64compress tool]]. | To fix this issue, we will have to look through the entire ROM file and adjust every 0x17/0x18/0x1A level script commands that have odd ROM address values. Thankfully, some people have made tools to do this automatically [[https://smwc.me/1374314|like queueRAM's sm64compress tool]]. | ||
| - | If you want to make your own tool that will implement this fix, then just follow these steps: | + | If you want to make your own tool that will implement this fix, then you can follow these steps: |
| 1.) Look through all of the levels scripts to find 0x17/0x18/0x1A commands | 1.) Look through all of the levels scripts to find 0x17/0x18/0x1A commands | ||
| 2.) Test if either the ROM start address or ROM end address is odd. | 2.) Test if either the ROM start address or ROM end address is odd. | ||
| Line 67: | Line 67: | ||
| **How to fix it?** | **How to fix it?** | ||
| - | This issue can be fixed by changing the camera's far value back to being a positive number. The largest possible positive number is 0x7FFF (32767). A simple way to fix this problem is to look through all the bytes in the ROM file and look for a specific pattern of bytes: | + | This issue can be fixed by changing the camera's far value back to being a positive number. The largest possible positive number is 0x7FFF (32767). A simple way to fix this problem is to look through all the bytes in the ROM file and find a specific pattern of bytes: |
| 1.) Find all occurrences of: 0A 01 00 2D 00 64 96 96 80 29 AA 3C | 1.) Find all occurrences of: 0A 01 00 2D 00 64 96 96 80 29 AA 3C | ||
| Line 88: | Line 88: | ||
| ==== Trying to write to the framebuffer's area of memory (8038F800-803FFFFF) ==== | ==== Trying to write to the framebuffer's area of memory (8038F800-803FFFFF) ==== | ||
| - | Older versions of the SM64 Editor moved the music pointer to address 0x803E0000. The problem with using that address is that the region from 0x8038F800 to 0x803FFFFF is constantly being overwritten with the game's framebuffer, so any data that gets stored within that region will be erased immediately. Some graphic plugins for Project64, like jabo's, have the option of writing the framebuffer to memory turned off by default, which is probably why this was not caught earlier. | + | Older versions of the SM64 Editor moved the sound allocation to address 0x803D0000. The problem with using that address is that the region from 0x8038F800 to 0x803FFFFF is constantly being overwritten with the game's framebuffer, so any data that gets stored within that region will be erased immediately. Some graphic plugins for Project64, like jabo's, have the option of writing the framebuffer to memory turned off by default, which is probably why this was not caught earlier. |
| **How to fix it?** | **How to fix it?** | ||
| + | |||
| + | To fix the music allocation issue, you just need to do the following: | ||
| + | |||
| + | 1.) Check if the 2 bytes at ROM offset 0xD48B6 is equal to 0x803D. | ||
| + | 2.) If so, then change that value to 0x805C. | ||
| Later versions of the SM64 Editor will put the music memory pool in extended memory, which is safe to use. Please do not store data within 0x8038F800-0x803FFFFF if you want your hack to be compatible. | Later versions of the SM64 Editor will put the music memory pool in extended memory, which is safe to use. Please do not store data within 0x8038F800-0x803FFFFF if you want your hack to be compatible. | ||
| Line 96: | Line 101: | ||
| ---- | ---- | ||
| - | ===== The Project64 problem ===== | + | ===== The problem with N64 emulators ===== |
| + | |||
| + | As we all know, Nintendo 64 emulation has never been perfect in the 20+ years since the console's release. This is mainly due to the architecture that was created by Silicon Graphics back in the mid 1990's. The console truly was a unique piece of hardware. While most N64 emulators do a good enough job for casual players who want to only play games, there are some inaccuracies that can create problems for ROM hackers. | ||
| - | Project64 is a popular, and performance friendly, Nintendo 64 emulator that was initially created back in 2001. While it is highly compatible with most of the N64 library when it comes to casual players, it is not cycle accurate and depends on plugins for graphics and audio. This fact makes it easy for us, as ROM hackers using the emulator, to unknowingly create the issues seen above. It is not so much the emulator itself that is the main problem, but rather the fact that most SM64 hackers will only use Project64 that creates these problems. | ||
| ===== See Also ===== | ===== See Also ===== | ||
| [[super_mario_64:list_of_console_compatible_hacks|List of console compatible ROM hacks]] | [[super_mario_64:list_of_console_compatible_hacks|List of console compatible ROM hacks]] | ||
