Banner
Views: 943,280,484
Time:
18 users online: Arash, autisticsceptile1993, BabaYegha, Caracc, FrozenHydra, Gamet2004,  idol, imamelia,  JamesD28, Jordan,  Lazy, OnlySpaghettiCode, Phyll, RichardDS90, Stivi, supermerkurii, WhiteYoshiEgg, YouFailMe - Guests: 98 - Bots: 74 Users: 52,451 (1,994 active)
Latest: Nairobii
Tip: Use the Iggy/Larry Battle Tools to edit Iggy/Larry's platform.
Not logged in.
Super Mario Kart Hacking
Forum Index - Non-SMW Hacking - Misc. ROM Hacking - Super Mario Kart Hacking
Pages: « 1 » Link
Hello all!

I am very excited to enter into the SNES hacking scene, with a certain affinity for Super Mario Kart for SNES! I'm creating this thread mainly as a meeting place for other SMK hackers to meet up and have a space to post any news or information on Super Mario Kart (Hacks, Maps, Code, ROM maps, RAM maps, etc.) For starters, I'll post my current confirmed and potential RAM maps, and I will update them as needed. If you have any additions, feel free to add them, but please post links to the files.

I'm looking forward to working with you all! Hopefully we can crack open the mysteries of this game and make great things of it!

-MrL314


Potential Subroutines Map

Potential RAM Map


Discord link is here for anyone interested: https://discord.gg/QNcKNQC
iiiiiinteresting....

I've actually looked at SMK very quickly some month ago, but haven't spent more than a week on it.
BUT in this time I looked at the inner workings of SMK, I have actually made a very small RAM map:

Code
$0800 = List of checkpoint properties (Speed, angle) [THIS WAS NOT VERIFIED IN ANY WAY!]

$1300 = AI kart variables (256 bytes?), offsets:
 $12 = Character (16-bit)
 $14 = Something related to drawing the sprite?
 $15 = Palette (sprite properties)
 $17 = X coordinate (24-bit)
 $1B = Y coordinate (24-bit)
 $1F = "Z coordinate" (altitude) (16-bit)
 $22 = Velocity (X?)
 $24 = Velocity (Y?)
 $2A = Facing (16-bit)
 $5C = Collision timer? (16-bit)
 $A2 = Momentum direction?
 $AC = Speed change routine?
	00 = Normal;
	02 = Lock speed;
	04/06/0A/0C/0E = Zero speed;
	08 = Gain/lose 1 unit of speed (0.00390625 px/f), top speed = #$007C (0.484375 px/f);
	10 = Boosting (mushroom/dash plate);
	12 = Slight boost (top speed = #$0520 [5.125 px/f]);
	14 = Subtract #$0038 (0.21875 px/f) from speed (hit by item?);
	16 = ???;
 $C0 = Current checkpoint
 $C1 = Current lap
 $C8 = Affects AI top speed (and turn speed?) [UNKNOWN]
 $DA = Affects AI top speed if not zero? [UNKNOWN]
 $E2 = Various flags (16-bit) [STILL NEED TO LOOK WHAT'S 0001, 0002, 0004, 0008, ... 4000, 8000]
 $E6 = Affects AI top speed if $DA is zero? [UNKNOWN]
 $EA = Speed (16-bit)
 $EE = Speed gain (signed 16-bit)
 $FA = Target facing (calculated by arctan)


You might want to verify with what you already have, but I don't guarantee any accuracy whatsoever on my RAM map.

I also have the disassembly notes from Puresabe, who is some guy who created a level editor for F-Zero and a (now obsolete?) editor for SMK. There are some interesting RAM addresses documented by him, but their description are all in Japanese (and Google Translate doesn't help 100% of the time with those).



That said, I'd REALLY like to help you out. BUT, one big hurdle for me to help you is free time.
One thing I have big interest in is getting to know how some SNES games work internally (fun-fact: I've tried disassembling Earthbound but it was just plain awful for me to understand it; large portions of that game was coded in C, so the assembly output is a complete mess).

F-Zero is a game I already (mostly) understand how it works internally, it wasn't very hard for me to reverse-engineer it, despite not having much previous documentation on routines/RAM. It is a very simple game; it was a launch title.
SMK is obviously, without a doubt, a more complex game than F-Zero in terms of programming matters, so that may prove it a little harder to reverse-engineer it.

--------------------
I'm reverse-engineering and hacking F-Zero (SNES)!

My YouTube channel, with various hacking tests
Hey CatadorDeLatas!

Thank you so much for your input on some of the RAM addresses you provided! (They actually helped me name some variables and subroutines in the ROM, more on that in a second). Don't feel rushed, I mainly just wanted to jump-start the Super Mario Kart community again. That being said, I'm starting a Discord for Super Mario Kart Hacking if you ever do feel inclined to join in. Again this would all be a "do when you please" sort of thing, so don't feel any pressure to go and decode the entirety of the RAM map or anything!

Tying in the ROM map and the Discord, I think it would be a very interesting way to handle sharing everything (since forums may not be the most ideal way to keep up with updates). In there would be some shared files of discovered addresses and subroutines and data tables, etc. and would be routinely updated on the forums for any users who just happen to want to use the data we collect.

Again don't feel pressured to do so, this is mainly a grouping of people who just like Super Mario Kart and want to contribute to dissecting this game in any way. :)



-MrL314
Originally posted by LF_MrL314
Hello all!

I am very excited to enter into the SNES hacking scene, with a certain affinity for Super Mario Kart for SNES! I'm creating this thread mainly as a meeting place for other SMK hackers to meet up and have a space to post any news or information on Super Mario Kart (Hacks, Maps, Code, ROM maps, RAM maps, etc.) For starters, I'll post my current confirmed and potential RAM maps, and I will update them as needed. If you have any additions, feel free to add them, but please post links to the files.

I'm looking forward to working with you all! Hopefully we can crack open the mysteries of this game and make great things of it!

-MrL314

Confirmed RAM Map

Potential RAM Map



Interesting.. So do you have any ROM maps yet? I'm interested to know if you know where the items code is.

Anyway I'm done with SMK hacking Super Baldy Kart did change almost everything... but I'll leave this here for youhttps://epicedit.stifu.fr/smk_doc/
Originally posted by Dirtbag2
Interesting.. So do you have any ROM maps yet?


I do not currently have a map, I am still actively working on disassembling the code, adding names to different subroutines, etc. I can definitely work on identifying some data maps (they aren't really hard to identify, just hard to classify).


Originally posted by Dirtbag2
I'm interested to know if you know where the items code is.


If you are referring to the subroutines that each item uses, I'm actually working on the trace logs from the frame of the driver being hit by a green shell, so I may be able to pick apart a couple of different routines from there. I will definitely keep you updated if I do.

-MrL314
As per Dirtbag2's request, I have been looking into the Items code.


TL;DR - 80FE07 updates each driver's xyz positions and velocities, on-field items are treated as drivers, and are stored after driver data banks. Red shells are possibly special green shells, and yoshi eggs are just re-textured bananas. If you are interested in contributing in any way, link to discord is in top post.


I have good news and bad news. Good news is, I believe that the item data in race is stored similar to this fashion. I will need some verification and some time to have sufficient evidence that this is the case, but I believe that right after the Driver Data Banks in RAM (7E:1000-17FF) is where the in-race data for items is stored. I also believe that in the 1A bank (7E:1Axx), two item's data are being stored. I believe 7E:1A00-1A7F is the data for shells (Both green and red shells showed in this area during testing), and 7E:1A80-1AFF is the data for a Banana.

As for my theories on this: I presume that this may not be sufficient as I am unsure of whether or not multiple instances of a shell can exist in a race at any given time. BUT if in fact this is the case, it seems that the banks are unchecked until the first instance of that item enters a driver's item box (which I am still investigating as to which address that is per driver). Then when the first is initialized, it copies the data of that driver (only the first $80 bytes), until use. Then from that point, the item exists as its own entity until a collision with a driver occurs.

Due to this presumed theory of the items, I feel I must explain what the data structure of these items are. The answer to that is surprisingly very simple: The data is formatted pretty much exactly how the driver data is, but only uses the first $80 addresses.

More good news arises from this actually. If -- and I very intently mean IF -- this theory is correct, then the last $80 bytes for each driver bank SHOULD correspond to driver specific data, that would be useless to an item (for example Surface type, Angle, Checkpoint, Lap, Absolute Speed, Race Time, etc.). As it stands currently, I have not been able to prove this theory extensively, but one piece of evidence I have to provide the framework of these items being treated as "drivers" is substantiated by a subroutine.


The subroutine in question is the 80FE07 subroutine, to which I have aptly named "Update position and speed for driver $B4", as the current driver is given by the address at 00:00B4, and the subroutine seems to process the updating of the driver Z, X, and Y Position and Speed respectively. (In my notation, Z is the vertical axis, as X and Y are more commonly used in the 2D plane of the racing world). The evidence lies in the tracelogs of when a shell is in motion on the track. The 80FE07 subroutine is called on all of the usual drivers, i.e. 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, but curiously is ALSO called on 1A00. This in fact means that on field items (at least shells as far as I am aware) are treated as drivers! This would make sense as the current theory is that it is easy to handle collisions if handled in this manner.


Now onto the bad news: If the way the items are being handled REALLY is how this theory holds, then at least in RACES SPECIFICALLY, then handling AI for new potential items will be a serious problem. If requested, I can explain my reasoning behind that bold statement, but for now the explanation would make this post even longer than it should be.

So to Dirtbag2 and anyone looking into tracelogs to look for items code, I would suggest looking for calls to RAM that have the indexes of xx1Axx to see if it is calling something that has to do with shells or bananas, or items that are in banks xx18 and xx19. (current theory is that those are for non-field items).

FINAL THEORY (sorry this post is getting WAY too long):
Red and Green Shells are being handled under the same item data.
Bananas and Yoshi Eggs are being handled under the same item data.
Implications of these theories are yet to be considered.


If you read this entire post THANK YOU for listening to my ramblings, and I hope I have inspired some of you to see how much one little piece of information can have an effect on the entire workings of a game.

Again if anyone is at all interested in delving deeper into the mysteries of this fantastic game, the link to the discord is in the top post of this thread.

-MrL314
Hello again!

I cannot believe it's been almost a full year since my last post, lots has happened in the mean time. I cannot fully describe every new piece of information gathered in the past 11 months (mostly because I didn't bother to keep track until around two months ago, but also because there is a LOT of new information). I feel it is appropriate to update on one finding, that just occurred today in fact, just to get the project back on its feet. One request I had attained was being able to change the starting order of the CPU karts at the beginning of the Grand Prix races.

It turns out this is not that big of a challenge because it ended up boiling down to a table in ROM (as suspected). The table is located at 1EE97 in ROM, and is an 8x8 WORD table where each row corresponds to the character selected. It would be easier to just show it and use that to explain.

Code
Grand Prix Character-Based Starting Order Table 
DATA_81EE97:        08 00 06 00 0E 00 02 00 0C 00 04 00 0A 00 00 00 ; DPYLTBKM (Mario)
                    0E 00 00 00 04 00 0A 00 06 00 08 00 0C 00 02 00 ; YMBKPDTL (Luigi)
                    00 00 02 00 06 00 0E 00 08 00 0C 00 0A 00 04 00 ; MLPYDTKB (Bowser)
                    04 00 0C 00 00 00 08 00 02 00 0E 00 0A 00 06 00 ; BTMDLYKP (Peach)
                    0C 00 04 00 0A 00 02 00 06 00 00 00 0E 00 08 00 ; TBKLPMYD (DK)
                    02 00 0E 00 06 00 00 00 04 00 08 00 0C 00 0A 00 ; LYPMBDTK (Koopa)
                    06 00 08 00 00 00 0E 00 02 00 0A 00 04 00 0C 00 ; PDMYLKBT (Toad)
                    0A 00 08 00 06 00 04 00 00 00 0C 00 02 00 0E 00 ; KDPBMTLY (Yoshi)


Each word corresponds to a specific character number, specifically in this format:

Code
0x0000: (M) Mario
0x0002: (L) Luigi
0x0004: (B) Bowser
0x0006: (P) Peach
0x0008: (D) DK
0x000A: (K) Koopa
0x000C: (T) Toad
0x000E: (Y) Yoshi



So when you select, for example Peach as your player, the game orders the CPUs from left to right using the 4th row (since Peach is 4th in that list above), meaning the character order would be Bowser, Toad, Mario, DK, Luigi, Yoshi, Koopa, Peach. And from a quick screen-grab, this is confirmed:


Now what if you want to change that order? Its as simple as rearranging the correct row to the order you want. For example lets say I really hate this ordering of the characters in Peach's cup. I think I'd rather have it in this order: Yoshi, Toad, Bowser, Mario, DK, Koopa, Luigi, Peach. The only change I would need to make is to change the 4th row of this table to

Code
0E 00 0C 00 04 00 00 00 08 00 0A 00 02 00 06 00


Now running this through a simple test I get this:


AMAZING! Okay, maybe a bit underwhelming, but the point still stands that everything can be manipulated in clever ways. If you were making a ROM hack and alongside custom characters wanted a custom ordering, this would allow you to do so. Also rearranging the characters (as far as I know) does not change anything gameplay-wise about each CPU, just its position. Further testing is required, but as of right now I do know that setting the first row to all zeroes does not make every CPU Mario, although it does make one other one Mario (I need to test more).


TL;DR, The CPU starting order is at 1EE97 in ROM, and its separated into rows corresponding to the character you select. I will be attempting to update more on the forums, but if you are really interested in keeping up to date on the work done with this project, you can join our discord https://discord.gg/QNcKNQC, we would be glad to have you on board! No amount of experience with hacking is necessary to join.

I know this has been a long post but you made it through! Thank you for your time! I hope I have been of some assistance!

-MrL314
I thought about making new Tracks, but the AI would be srewed up, is this true?
Hi Gents,

I am a member of the SMK Netplay discord, SMK main discord, and a participant at this years' SMK World Championships in the Netherlands.

The potential of the powerful potential traning aids for world championship players has once again come back to the fold, as SNESOT (SMK netplay) has been supplanted by retroarch Super Mario Kart Play, which has the benefits of removing latency.

Current mission is to synthesise certain features achieved on NTSC rom hacks into PAL, which is the frequency mode use at the annual world championships, these include getting 10 coin 150cc speed in time trial, integrating speedometer, and infinite item selectors too to train mushroom longs boosts, feather skips for tournament play.

Have a look at this:

https://gamehacking.org/game/44859

I am trying to get in touch with this community too on discord. Please if anyone is keen and you either reply back here (ill then look to DM you), or feel free to get in contact with me on discord via YorkshireSMK#0291.

Thanks again,

Chris.
Well well, it seems it has been a long time as usual. In the time since the last post, the community over on the discord has grown immensely, and I cannot thank everyone enough on the server. You have all been very wonderful and have made this little passion project of mine into something I could never have imagined.

Now onto the information. Since most of the information has been posted to the discord, I will spare the nitty gritty details, but I figured some of you would like to know about....

d e b u g m o d e.

Yep! Very recently I found a few tidbits and things indicating "unused" features of the game, that when delved deep into, turned out to be debug options! So far, I have only been able to mess with two of the options, but it is surprisingly simple to do.

The main culprit of this whole thing is the address $1F06. Now this address has shown up a bit and was stumping me for a while, but while researching the items code, I stumbled upon the routine responsible for item debugging. The good news is that it is super easy to enable this mode (provided you have an ability to edit hex values, via emulator or game genie). Simply set the value of $1F06 to 0x10. That's it.

Now, this debug mode allows you to use any item effect at any time**. To enable each action, simply folow these button combinations:

Code
A: Mushroom
Y: Feather
X: Star
Select: Banana
L: Green Shell
R: Red Shell
Y+Down: Boo
Y+Up: Lightning



However, the two "Y+Up" and "Y+Down" inputs must be entered on the same frame, which is sometimes a bit tricky to pull off. However, I find that the most fun ones are easier to use. I may or may not have spent about 20 minutes messing around spamming mushrooms and feathers to break courses. And yes, you can spam them, because you are in essence enabling the "item used" action for that item.

** because time trial does not have the notion of place-able items, they cannot be used in time trial mode. However, the non-place-able items like mushrooms and feathers can still be used. Everywhere else though, no restrictions apply.



The less exciting debug option that can be enabled is done by setting the value of $1F06 to 0x04. This mode simply allows you to press L at any time to change it to the last lap for every racer. You can now have the fastest Ghost times ever with little effort. :) (or, you know, you could spam mushrooms and feathers like a mad man like me)



Another recent discovery, made as a side effect of the debug options, was that SMK handles item memory allocation in a very odd way. Normally, it will reserve the $1A00 bank for 2 items, however it is possible to allow up to 8 items easily by changing 2 bytes of code. Now, I won't go into the full explanation here, as I am still looking into this, but it seems that there is a possibility to be able to allocate 23 (!!!!!!!) items, provided there is enough free RAM. This would probably not be feasible in GP, but for a quick and dirty solution it is PROBABLY possible to get a battle or a match race with 23 items zooming around. (combine that with debug mode for a world of fun... or pain).

If you would like to be a part of this ever-growing community of SMK lovers, the discord link is in the top of this thread and in the bottom of this post. Information to here is a bit slower for me as I am more active on the discord. I tend to publish completed and polished notes here to keep accurate content on here, whereas I post general notes on the discord where the information can be discussed. I promise there is WAY more information there than I have discussed here.

Thanks again!
- MrL314


Join our Discord!: https://discord.gg/QNcKNQC
I want to edit the music, but how do i import them?
https://cdn.discordapp.com/attachments/775158348323487774/815391081734471700/snesggg.PNG
i have snesssgg with audacity
Pages: « 1 » Link
Forum Index - Non-SMW Hacking - Misc. ROM Hacking - Super Mario Kart Hacking

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2021 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy
  • sm64romhacks