Mario Kart 64 Hacking General Discussion

[mib_f8sm9c]

(30-03-2016, 06:52 PM)queueRAM Wrote: This sounds like a solid plan. I think I'm working on a path very parallel to yours to create 3D contols for editing levels in the Blast Corps Editor (although it is F3D, not F3DEX). I'm currently using OpenTK on top of Windows Forms. Out of curiosity, what frameworks are you working with to accomplish this?

I am intrigued by your microcode visualizer idea. Do you have more detailed plans for this? Is this just to break down microcode into human readable descriptions or something that could render F3D blocks on the fly while editing?

If you haven't seen it already, you might be interested in looking at xdaniel's SceneNavi project, a level editor for Ocarina of Time and Majora's Mask written in C# using WinForms and OpenTK.

​

I'm doing the exact same thing, building on top of OpenTK in C#. I really hate OpenGL, so I'm pretty happy that I'm done with the low-level rendering code. Even if it didn't turn out to be so difficult.

The visualization is just a way to try to make it easier to group the microcode into clumps of same data-types, and to allow those clumps to move independently of each other. I already have some stuff to make the F3DZEX into human readable/editable format, like this:



But the visualizer would look something like this:



So there'd be a block of consecutive texture data, and a block of consecutive vertex data, and a block of consecutive F3DZEX code, and then a consecutive block of unknown data. And this'd be continued throughout the whole file, so you'd have all the 3d model information bits mapped out in the file. Then it would allow you to re-arrange the blocks around each other, and automatically update any references in the blocks so the code would keep working. While this seems useless by itself, it'd make importing information much more easy to handle since you could literally drag blocks from one file to another, and re-arrange them in an order you'd prefer. A little silly and unnecessary perhaps, but I already have the data blocks programmed, so I just need a visualizer/auto-updater for when references change.

Basically all my previous projects were based off of xDaniel's Starfox64Toolkit code, and I'm active in the Zelda modding scene, so I'm aware of SceneNavi. I'll probably want to revisit it in the future if I return to making zelda modding software. Thanks for the heads up though.

Your Blast Corps editor looks really impressive man, I hope I can get around to making some editors that look that handy!

EDIT: For the question about editing F3D on the fly, I want to tie the VisOb64 elements (contain data to display in OpenGL) with the vertex/F3D/texture information in the code being edited, and allow a change in one to affect the other. So yes, I plan on being able to allow dynamic editing of models both through the microcode and through the OpenGL interface (ex. moving/scaling object groups)

[queueRAM]

(30-03-2016, 07:41 PM)mib_f8sm9c Wrote: I'm doing the exact same thing, building on top of OpenTK in C#. I really hate OpenGL, so I'm pretty happy that I'm done with the low-level rendering code. Even if it didn't turn out to be so difficult.

​

Cool. OpenTK seemed like the best 3D framework for C# at the moment, but I worry a little bit about future support since the main dev hasn't been heard of in a while and the forums and docs are filled with spam. Another option I keep thinking about is building on top of Unity, like Jedi did for the SM64 level editor. It gives a lot of 3D editing features right out of the box and uses C#/Mono.

(30-03-2016, 07:41 PM)mib_f8sm9c Wrote: ​
The visualization is just a way to try to make it easier to group the microcode into clumps of same data-types, and to allow those clumps to move independently of each other. I already have some stuff to make the F3DZEX into human readable/editable format, like this:

​

That's really neat. I wish I'd known about the PropertyGrid before working on the Blast Corps Editor. Makes me want to redo a lot of that.

(30-03-2016, 07:41 PM)mib_f8sm9c Wrote: ​
So there'd be a block of consecutive texture data, and a block of consecutive vertex data, and a block of consecutive F3DZEX code, and then a consecutive block of unknown data. And this'd be continued throughout the whole file, so you'd have all the 3d model information bits mapped out in the file. Then it would allow you to re-arrange the blocks around each other, and automatically update any references in the blocks so the code would keep working. While this seems useless by itself, it'd make importing information much more easy to handle since you could literally drag blocks from one file to another, and re-arrange them in an order you'd prefer. A little silly and unnecessary perhaps, but I already have the data blocks programmed, so I just need a visualizer/auto-updater for when references change.

​

Ok, makes sense. Just note that this would probably be game-specific.  e.g., Mario 64 stores texture data in multiple banks and vertex data alongside the F3D display lists in another bank whereas Blast Corps dynamically writes textures out to RAM and updates the segmented address in the F3D display lists at run-time and stores vertex data in a separate bank. Maybe F3DEX games are more consistent though.

(30-03-2016, 07:41 PM)mib_f8sm9c Wrote: ​
Your Blast Corps editor looks really impressive man, I hope I can get around to making some editors that look that handy!

​

Thanks, it's all MIT licensed open source so feel free to use anything out of it. I'm also interested in helping with the Mario Kart 64 editor, so let me know if there is anything I can help with.

[mib_f8sm9c]

(30-03-2016, 08:39 PM)queueRAM Wrote: Another option I keep thinking about is building on top of Unity, like Jedi did for the SM64 level editor. It gives a lot of 3D editing features right out of the box and uses C#/Mono.

​

Oh man, that's a really great idea. I probably should've went down that path, but I've already got some working OpenGL, so might as well stick with it.

(30-03-2016, 08:39 PM)queueRAM Wrote: ​
Just note that this would probably be game-specific.  e.g., Mario 64 stores texture data in multiple banks and vertex data alongside the F3D display lists in another bank whereas Blast Corps dynamically writes textures out to RAM and updates the segmented address in the F3D display lists at run-time and stores vertex data in a separate bank. Maybe F3DEX games are more consistent though.

​

Yep, probably my least favorite aspect of N64 romhacking is how varied all the different rom structures are. Luckily for me, all my projects I've looked at have a similar method of clumping all info for specific 3d models in blocks and referencing the data within those blocks.

The microcode visualizer would probably be better labeled as an N64DataElement visualizer, since it would visualize N64DataElements (an abstract class I made to represent a section of binary data in a rom file). Vertex info, textures, microcode, and any other data types in Cereal64 inherit from N64DataElement. So if I were to work on Starfox64, and there's a specific table of enemy information, I could make 2 new N64DataElements, SF64EnemyTable and SF64EnemyTableEntry. The visualizer would be able to display these types as blocks as well as the more common microcode/vertex/texture ones.

Cereal64 is literally an N64 ROM deserialization/serialization library that is meant to give a basic level of data objects as well as provide structure for users to add their own data objects. Rom-specific stuff will have to be implemented by the user, but the intent is to keep things flexible enough to give that freedom to users. Cereal64 isn't a rom editing tool, it's a tool used to build rom editing tools, and hopefully it'll be generic enough that it'll be able to reach across all the different games I want to work on : )

[mib_f8sm9c]

Just a note on this, I finished up the rendering code & a F3DZEX->VO64 parser, which was the first goal on my to-do list.



Gonna clean up the code a bit and fix some bugs, then I'll start working on reading Smash Bros 64 & Mario Kart 64 model data. It'll probably only be a viewer at first, though I could probably expand the OpenGL form to allow for basic translation/rotation/scaling of rendered objects. Not that close to the goal yet, but I want to keep up to date here at least.

[MRKane]

Wow - great going! This is the kind of thing that childhood dreams are made out of!!!

[shygoo]

I mapped out most of eeprom today


Mario Kart 64 uses EEPROM to save time trial records and the selected sound mode. A mirror of EEPROM data is kept at 8018EB90 in RAM.
^ Offset   ^ Length ^ Description                               ^
| 0x000    | 24     | Luigi raceway record set                  |
| 0x018    | 24     | Moo Moo Farm record set                   |
| 0x030    | 24     | Koopa Troopa Beach record set             |
| 0x048    | 24     | Kalimari Desert record set                |
| 0x060    | 24     | Toad's Turnpike record set                |
| 0x078    | 24     | Frappe Snowland record set                |
| 0x090    | 24     | Choco Mountain record set                 |
| 0x0A8    | 24     | Mario Raceway record set                  |
| 0x0C0    | 24     | Wario Stadium record set                  |
| 0x0D8    | 24     | Sherbet Land record set                   |
| 0x0F0    | 24     | Royal Raceway record set                  |
| 0x108    | 24     | Bowser's Castle record set                |
| 0x120    | 24     | D.K's Jungle Parkway record set           |
| 0x138    | 24     | Yoshi Valley record set                   |
| 0x150    | 24     | Banshee Boardwalk record set              |
| 0x168    | 24     | Rainbow Road record set                   |
| 0x180    | 4      | Unknown (Unused padding?)                 |
| 0x184    | 1      | Audio setting                             |
| 0x185    | 1      | Unknown (Unused padding?)                 |
| 0x186    | 2      | Unknown (Checksum?)                       |
| 0x188    | 48     | Copies of all 1st records                 |
| 0x1B8    | 6      | Unknown (Padding?)                        |
| 0x1BE    | 2      | Unknown (Checksum?)                       |
| 0x1C0    | 48     | Another 16 records (What for?)            |
| 0x1F0    | 6      | Unknown (Padding?)                        |
| 0x1F6    | 2      | Unknown (Checksum?)                       |
| 0x1FC    | 1      | Copy of audio setting (0x184)             |
| 0x1FD    | 1      | Copy of Unknown (Unused padding?) (0x185) |
| 0x1FE    | 2      | Copy of Unknown (Checksum?) (0x186)       |

​Course record set structure
For each course, there is a 24 byte structure that contains the five best completion records and the best lap record. There is an additional byte which indicates whether or not any records have been saved for the set, and another byte which could be a checksum.

^ Offset ^ Length ^ Description                ^
| 0x000    | 3      | 1st record               |
| 0x003    | 3      | 2nd record               |
| 0x006    | 3      | 3rd record               |
| 0x009    | 3      | 4th record               |
| 0x00C    | 3      | 5th record               |
| 0x00F    | 3      | Best lap record          |
| 0x012    | 1      | Records exist (00 or 01) |
| 0x013    | 4      | Unknown (Unused?)        |
| 0x017    | 1      | Unknown (Checksum?)      |



​Record Format

Record entries are 24 bits each and are formatted in the following manner:

tttttttt tttttttt cccc tttt

Where t is a 20 bit little endian value for the completion time and c is a 4 bit ID of the character used in the trial. The game seems to display the time as ((t / 6000) * 10000) + (t % 6000)'' in decimal notation, with the literal digits split into minutes, seconds, and centiseconds (e.g. a t value of 1234 will simply display 00'12"34 and a value of 65536 will display 10'55"36). If a record has a time greater than or equal to 100 minutes, it is not displayed.

Valid character IDs for c are as follows:
^ ID ^ Name   ^
| 0  | MARIO  |
| 1  | LUIGI  |
| 2  | YOSHI  |
| 3  | TOAD   |
| 4  | D.K.   |
| 5  | WARIO  |
| 6  | PEACH  |
| 7  | BOWSER |
| 8  | (none, unused) |
| 9  | (none, default) |

The default value applied to record entries is ''0xC02709'', which is 100 minutes and no character.


A more tidy and likely more up-to-date version of these notes is here on the wiki https://wiki.origami64.net/mario_kart_64/eeprom_map

[abney317]

(10-04-2016, 06:52 AM)shygoo Wrote: | 0x180    | 4      | Unknown (Unused padding?)                 |

​

MK64 GP Trophies

NTSC-U

18ED10: 50cc
18ED11: 100cc
18ED12: 150cc
18ED13: Extra

Format:

00000000 = No trophies for that mode
11111111 = All Golds for that mode

xx | xx | xx | xx
Special | Star | Flower | Mushroom

00 = Nothing for cup
01 = Bronze
10 = Silver
11 = Gold

[dashn64]

Not sure if anyone is interested, but Rena Kunisaki (the person who made this custom level: https://www.youtube.com/watch?v=L1l687bxko4 years ago) just released all their MK64 notes: https://github.com/RenaKunisaki/mariokart64

Hope it's useful to you guys.

[krom]

Hi guys,

Using the help from this forum, I decided to make a Mario Kart 64 hack called 1500cc Edition.

You can find it here: https://github.com/PeterLemon/N64/tree/master/Hack/Mario%20Kart%2064%201500cc

I have provided source code in the form of an assembly patch using a modified bass assembler.
You can find the assembler here: https://github.com/ARM9/bass
This assembler contains the full instruction set of the N64's CPU / RSP / RDP, but I am only using the big-endian data functionality in this patch.
This assembly file requires you to have Mario Kart 64 (U) [!].z64 in the same directory, and will produce a file called Mario Kart 64 1500cc.z64.

I have also provided a .ips patch as well, for people who just want to apply a patch to Mario Kart 64 (U) [!].z64.

I mapped out all the Kart Property values I could find on this forum, & found where they exist in the cartridge ROM (for hard patching).
I then filled in the blank spaces in-between with unknown sections (I label each of the 8 Karts per section).
I worked out lots of the properties were IEEE32 values, so I am using float32 values from from the original cart.
I have only changed a few properties for the Karts CC speeds, which I will highlight here:
​https://github.com/PeterLemon/N64/blob/master/Hack/Mario%20Kart%2064%201500cc/Mario%20Kart%2064%201500cc.asm#L222-L273

You can see the new float32 number I have used on the Left, compared to the original cartridge ROM float32 number on the Right.

These patches have the effect of making each Kart have much more power & speed, pretty fun in all the modes!

The CPU players also have the same speed increase, & the AI works well for a fun race =D

​Current Bugs:
• Staff Ghosts in Time Trial mode get confused, as they prob use timed controller input saving, so they can get stuck in corners etc!
• When you use a Super Jump, e.g on Donkey Kong's Jungle Parkway or Princess Peach's Royal Raceway, the distance travelled is much further than normal.
(You can do a tight turn to land on track, but I'd like to edit the properties of those jumps, to make it a little less severe.)
• With the extra power of the Karts, going thru Grass or Sand etc., hardly effects the speed of the Kart.
(I also want to find the properties that will let me add some more slowdown when going thru these surface types, with the added Kart speed)

Anyway, I'll try to find out what all these unknown sections inbetween known Kart properties are, and fill in the blanks.
I'll update here with anything new I find out, thanks for all the help to get me started =D

[Luke]

This is a great hack thank you!

(23-04-2016, 07:54 PM)krom Wrote: ​
Hi guys,

Using the help from this forum, I decided to make a Mario Kart 64 hack called 1500cc Edition.

You can find it here: https://github.com/PeterLemon/N64/tree/master/Hack/Mario%20Kart%2064%201500cc

I have provided source code in the form of an assembly patch using a modified bass assembler.
You can find the assembler here: https://github.com/ARM9/bass
This assembler contains the full instruction set of the N64's CPU / RSP / RDP, but I am only using the big-endian data functionality in this patch.
This assembly file requires you to have Mario Kart 64 (U) [!].z64 in the same directory, and will produce a file called Mario Kart 64 1500cc.z64.

I have also provided a .ips patch as well, for people who just want to apply a patch to Mario Kart 64 (U) [!].z64.

I mapped out all the Kart Property values I could find on this forum, & found where they exist in the cartridge ROM (for hard patching).
I then filled in the blank spaces in-between with unknown sections (I label each of the 8 Karts per section).
I worked out lots of the properties were IEEE32 values, so I am using float32 values from from the original cart.
I have only changed a few properties for the Karts CC speeds, which I will highlight here:
​https://github.com/PeterLemon/N64/blob/master/Hack/Mario%20Kart%2064%201500cc/Mario%20Kart%2064%201500cc.asm#L222-L273

You can see the new float32 number I have used on the Left, compared to the original cartridge ROM float32 number on the Right.

These patches have the effect of making each Kart have much more power & speed, pretty fun in all the modes!

The CPU players also have the same speed increase, & the AI works well for a fun race =D

​Current Bugs:
• Staff Ghosts in Time Trial mode get confused, as they prob use timed controller input saving, so they can get stuck in corners etc!
• When you use a Super Jump, e.g on Donkey Kong's Jungle Parkway or Princess Peach's Royal Raceway, the distance travelled is much further than normal.
(You can do a tight turn to land on track, but I'd like to edit the properties of those jumps, to make it a little less severe.)
• With the extra power of the Karts, going thru Grass or Sand etc., hardly effects the speed of the Kart.
(I also want to find the properties that will let me add some more slowdown when going thru these surface types, with the added Kart speed)

Anyway, I'll try to find out what all these unknown sections inbetween known Kart properties are, and fill in the blanks.
I'll update here with anything new I find out, thanks for all the help to get me started =D

​