Hello, I have a problem with my Nintendo 64 US games (Mario Kart 64, Zelda ...) launched on my two Nintendo 64 PAL RGB (with Passport 64 or other). The sound is sizzling. :-( I have no problem with Nintendo 64 Japan or PAL games. I tested different RGB cable (retrogamingcables.co.uk ...), the problem persists. Tested on N64 PAL composite (no-RGB), same probleme. I made a little video :
I used to get this problem with the Chinese import adapter (plane grey case), i never had any sound problems with the passport series adapters. These days i just bought cheap ntsc (jap or usa) console from ebay n remove the lockout taps to play any region ntsc cartridge.
You need to spoof the internal region of the console. During bootup the PIF chip initializes the N64 and sets a number of things up. One of them is the region of the console, implemented as a value stored on the N64's RAM. The N64 OS reads this as variable "OsTvType". Known values are PAL, NTSC, and MPAL. Handling of this variable is entirely up to the game's code and quite a few number of different outcomes can be observed when the OsTvType value doesn't match what the game's code expects. In MK64's case, as with other early games, sound gets garbled, apparently something to do with the audio libraries. Other games will use that value for region protection and will complain about the region of your console or just won't even boot. There's the rare NTSC game that will actually adapt and even play in full screen 50hz in PAL consoles (Extreme-G, for example). Other effects are possible. There's an actual hardware difference between NTSC and PAL consoles that can affect game execution in noticeable ways, and that's the RDRAM bus clock, which is slighty higher in PAL. This causes desynchronization between sound and animation in some game's cutscenes when you run them in the "wrong" console even if you spoof the region identifier. There's possibly other effects depending on how the game was programmed. Since you are using a Passport, you can enter a code to change the region value before the game kicks in. Zoinkity will surely know how. According to the SDK's documentation, all American NTSC games are expected to also accept the MPAL OsTvType and behave correctly on MPAL consoles (Brazil). http://www.romhacking.net/hacks/n64/patches/539readme.txt 8002E221 0000 I think this may be the code. IF this is what I think it is, it is spoofing the region code to 0 (PAL) so that the 40 Winks prototype will boot. Try adding that code to your games, but change the 0000 to 0001. IF it works, report, please. Also, try games that just refuse to boot or that show some "wrong region" screen and see if they will boot. So, resuming, IF this code is what I think it is, it will make your N64 appear to be a certain region to game code. 8002E221 0000 makes hardware look like it is PAL 8002E221 0001 makes hardware look like it is NTSC 8002E221 0002 makes hardware look like it is MPAL
Hello and thanks radorn for your help. I testes on MK64 US on N64PAL with Passeport : boot whithout code : sound problem. 8002E221 0000: sound problem. 8002E221 0001 : sound problem and game freeze in demo. 8002E221 0002: sound problem and bug when demo, white square in black screen.
It seems the code for a PP3 is different than for an AR/GS. This one should work. E1100304 0000000X Change the last digit according to the region you want to spoof in. That is, match the code to the ROM if the ROM doesn't match your console.
I tested : E1100304 00000000 : sound problem, good music speed (60hz) E1100304 00000001 : NO sound problem but music speed slow (50hz ?) E1100304 00000002 : NO sound problem but music speed slow (50hz ?) Not tested in game for the moment, i'll test tomorrow. Look (poor quality) video :
It works for me. Did you use the bubble on the right and set it to "BOOT CODE"? Be careful: If you type the code in and then change to "BOOT CODE" the code will change too, so make sure you re-type it.
Yes, i use Boot Code, sure. The music is more slow with code but the game action is normal (60 hz). Look the video capture without and with code. The music is "slow" with code and more speed without code but Mario hit the walll at 12'03 with or with code. Do you know if we can add this boot code in the rom named Mario Kart 64 (U) [!].z64 ?
If you are running ROMs on hardware it means you have a ROM emulator (also known as flashcarts). Any decent one should be able to recognize the ROM's intended region and automatically spoof it in for you. No need to patch the ROM itself. Since you were using a Passport3 I assumed you were using original cartridges. With those you need to spoof the region with codes, but for flashcarts better stick to the included manual or automatic spoofing. I myself am a 64drive user and I know for a fact that it's menu/bios can identify most (all?) ROM regions and automatically set the region spoofing. UPDATE: The music speed with the code ON is the correct speed. Your perception of it being "slow" is because you seem to think the faster version is the correct one, but that's not so. What you think is the good one is actually playing too fast.
I use an original cartridge, it was just a question. I search the correspondence GS code / ROM for E1100304.
That code doesn't modify a ROM address, but a RAM address, and it only does it once, as implied by it being a "BOOT CODE". On the N64 there's this microcontroller called the PIF (Peripheral InterFace). It manages the controllers, the reset button, the CIC chip and initializes the hardware. During that initialization, it writes the region value to RAM and doesn't do it again until you power-cycle or reset(?). Thanks to this, software running on the CPU can change that value. This is exploited for region spoofing. A boot-emulator, flashcart menu, or bootloader (such as AR/GS or passport) can change it to any desired value BEFORE running a ROM or cartridge. When the ROM is run, it will find whatever region value is present in RAM, whether it is the one set by the onboard PIF or spoofed by some other program. In other words, each ROM will deal with the region value in it's own way. You can't patch this code to a ROM unless you also hack in the code engine along with it... or just hack the ROM in any other way.
I did notice about that in the previous video. What I told you is that the one that you call "slow" is actually playing at the correct speed... That's how the game is supposed to sound, I assure you. The speed at which it plays without the code in both your videos is wrong. That's not how it is meant to sound. It's playing too fast. Just find the official soundtrack to the game and compare the speeds. You'll surely find it in YT if you don't have it. So, it's not that with the code it goes slow, but that without the code it goes faster than it should. "SLOW" = CORRECT "NOT SLOW" = WRONG