I will document relevant patches and development related to patches here.

See also Mario Kart 64 Game Resources

Mario Kart 64 runs at 30 input frames per second (fps) of in-game time. Under ideal conditions there is one lag frame between each input frame. Internally the game makes calculations at 60 fps. On the actual Nintendo 64 hardware, this is typically true in one player modes but not true in multiplayer modes. The game engine is not capable of dynamically adjusting the game pacing based on the number of actual input frames per run time. Because of this, additional lag frames in multiplayer mode would make the game run slowly to players (although the simulated speed internal to the game would be the same as in comparable one player modes). To counteract this and make the play speed feel similar to one player modes, the developers introduced a scaling factor to change the amount of in-game time elapsed per input frame. In one-player modes this factor is 2, meaning that from one input frame to the next, 2 units of in-game time (2/60 of a second) are simulated to have elapsed. In multiplayer this scaling factor is adjusted based on the number of players and the course that is being played. It is adjusted to either 3 or 4 units of in-game time (3/60 or 4/60 of a second respectively). These adjustments were presumably made by game testers late in development with the hope of mimicking the intended game pacing showcased in one-player modes. They represent a 50% and 100% increase in in-game time elapsed per input frame and a corresponding decrease in temporal resolution by 1/3 and 1/2 respectively. Given only these large adjustments, the resulting game pacing on actual hardware is inconsistent and the loss in temporal resolution makes the controls less responsive.

When played on more capable hardware, including the official Virtual Console and iQue releases but also unofficial emulators, fewer lag frames are experienced. The result is these scaling factors actually change the effective speed of the game. They directly increase the pacing by 50% or 100%. Combined with the loss in temporal resolution, three and four player modes become almost unplayable. In these cases, it would be preferable to remove these hardware dependent scaling factors and accept a consistent real-time 30 fps.

The scaling effects are summarized in the following tables:

Thankfully, it is possible to set these scaling factors to assume 30 input fps with some simple codes. These codes set the game time units per input frame to always be 2, regardless of what the actual game specified:

Three and Four Player game tempo fix:
81001C90 240A
81001C92 0002
81001C94 240A
81001C96 0002

Two Player game tempo fix:
81001A38 2409
81001A3A 0002
81001A3C 2409
81001A3E 0002

It is also possible to set the game time units per input frame to 1. This produces 60 frames per in-game second but the lag frames every other frame still exist. Thus, these codes result in the game playing at an effective runtime pacing of 50% of normal. To overcome this, it is necessary to use an emulator capable of fast forwarding at 200%. The end result is a normal pacing and very smooth 60 fps in all modes. However the music will be double speed and some frame-rate dependent animations (like power slide smoke) occur twice as often as normal.
Note: Requires emulator to be played at 200% speed for correct pacing
One Player 60fps tempo:
810015C4 240F
810015C6 0001
810015C8 240F
810015CA 0001

Two Player 60fps tempo:
81001A38 2409
81001A3A 0001
81001A3C 2409
81001A3E 0001

Three and Four Player 60fps tempo:
81001C90 240A
81001C92 0001
81001C94 240A
81001C96 0001

1P, 3P and 4P: 81150148 3FDF
2P: 81150148 4060
Note: You can only have one of these on at at time. Need to make a more complicated code to edit this value based on the number of players.

810B3924 2400
810B3936 7FFF
810B39A4 2400
810B39B6 7FFF
810B3A38 2400
810B3A4E 7FFF