Banner
Views: 943,274,663
Time:
10 users online: Bo8ox, DasFueller, HammerGuy,  JamesD28, Kevin,  Maxodex, muzzl, Nairobii, Nanita, supermerkurii - Guests: 97 - Bots: 85 Users: 52,451 (1,995 active)
Latest: Nairobii
Tip: You can use your My Files section to upload screenshots, videos, etc. of your hack.
Not logged in.
Posts by LF_MrL314
LF_MrL314's Profile - Posts by LF_MrL314
Pages: « 1 »
Hello there loki700! I happen to also be someone very interested in Super Mario Kart hacking/disassembly. I would love to get in contact with you and maybe share some notes on the subject! I'm looking to get a team together to disassemble SMK on the scale that SMW and YI have been already on this site. I am passionate about this subject and if you are interested in collaborating, I would be more than happy to accept!

If not, I will still be on the lookout for results screen text so I'll try to keep you updated either way. :)


Some advice from me personally:
-Use BizHawk's TraceLogger and log to a local file
-Create a TAS or just someway of remotely running a single frame
-Activate the TraceLogger and run it for a single frame when the results text screen loads in, when the results text appears, one frame before each, and one on a different screen as a control, saving each to a different file just in case.
-Locate the differences between each frame and the control, and narrow your search from there, looking at similarities possibly between loading and displaying certain sprites.
-See if any happen to address certain tables and look into those tables (most likely candidates would be lines that use a load indirect addressed by x or y, or load absolute addressed by x or y, as those usually indicate a data table)



Hope I was of some help to you! If you would like to participate in the SMK hacking group, feel free to contact me!

Thanks,
MrL314
Hello BrutalValenti and CatadorDeLatas!

I am also very interested in Hacking/Disassembling Super Mario Kart, and I am putting together a group of people also interested in the same sort of thing. I would love to have you guys on board as it looks like you are interested in hacking it anyway. If you are interested in joining, feel free to contact me and maybe we can exchange some notes of discoveries we've made. :D

I personally am very interested in reverse engineering SMK and seeing how it ticks to see how I can break it.


Thanks,
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


Potential Subroutines Map

Potential RAM Map


Discord link is here for anyone interested: https://discord.gg/QNcKNQC
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
Aw man! Well hopefully they'll come back sometime!
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
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
Pages: « 1 »
LF_MrL314's Profile - Posts by LF_MrL314

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