[Source Code] Super Mario World

1) the useful thing is easier remapping the ram address, no longer need to add a jump to a freespace, by simply adding code in between.

2)checking bank by bank to see if there is a mistake as well as glitches NOT from the original game. This snes9xdebugger and this can help you.

3)helpful if it's a snes development kit.

4)well, it's great, but the problem is that asar users will get unfamiliar with this new patching tool, for example, if I'm modifying the physics, I'll have to use a new macro or command.

---

Give thanks to RPG hacker for working on Asar.

1) At least on SMWC it's useful mostly for understanding and copying SMW's code. Last time I checked (read: months ago), I think it already did a very good job at that.

2 & 3) ~

4) Not for SMW hacking I don't, because I assume hackers will mostly turn SMW's code into patches, and Asar is the de facto standard for that. The homebrew scene will certainly think otherwise though.

---

 

1) It is still very useful, but see #4...

2) I'd suggest focusing on making a code disassembly generator for conversion to different assemblers.

3: See #4

4: as I said, WLA code is proven to be a bad SPC700 assembler, specifically, and also has a few other minor problems...

-----------------------------------------------

If you are using WLA no matter what I say, At least I'd suggest making adjustments to use another assembler for SPC code.

Still... Please consider either staying with Asar, or use the recent XKAS Plus (fork), or convert it to CA65, using Tepples' (Damian Yerrick's) SPC macro set found on his website included in his LoROM example at https://pineight.com/snes

Edit: I'd also try to avoid assembler choice #3 (CA65) for reasons that WYE replied, as it does not create Text (.ASM) file based patches as an option!

---

A.K.A. SmilyMZX,

Also on NESDEV, and on various other forums, Find me on other places if I'm there.

Look for me also on YT...

Beware of false lookalikes!

Q1: Super useful. I am trying to write a SMW Level Editor. A key concept I want to develop is using the source of SMW directly. The steps would be:

1. Change something in the editor (move a tile).
2. The editor modifies some part of the ASM Code.
3. The whole code is assembled into a new ROM.
4. The editor executes some routines in the ROM and interprets the results to display an updated view.

This should also allow for handwritten changes instead of step 1/2.

For this I am in need of a relocating assembler, which I want to write next.

Q2: What would help me the most, if the source code is easily compatible with the to be written assembler. Maybe we can coordinate our efforts so that I write an assembler that fits both of our needs.

Q3: -
Q4: One of my main reasons for writing my own assembler (besides educational reasons) is my Need for Speed™. If I want my application to not lag, I have to be able to hit 30FPS at least, so the above four steps have a timeframe of about 30ms. Therefore, I assume the overhead of an external assembler is too large, which also rules out WLA.

---

Your layout has been removed.

Isn't asar more or less SMW specific? Despite this being a SMW disassembly, I still value portability. That said, I can't recommend what assembler to use, as I'm not at all versed on their strengths and weaknesses.

1). I find it very useful. In fact, I'm using your source code as a base for my future SMW hacks since it offers several advantages over doing things the normal way. The biggest one being that I can integrate custom code within the existing code without worrying about overwriting something and without jumping away or needing any restore code as well as being able to move things around if I need to make room for something else or if doing so will allow me to better optimize a routine. If you're not using LM as well, you will have full control over the ROM and can do pretty much anything you want with it. If you are using LM as well, then the source code is still very powerful, but you do have to jump through some hoops to keep LM working with your ROM. If more people were to use the source code for their hacks, then I'd say you ought to continue working on the source code to improve it.

2). You ought to convert every RAM address into a define so that all RAM addresses can be remapped. Also, certain other things in the code could be replaced with defines as well, such as sound effect numbers.

3). This is very useful for SMW hacking in addition to homebrew. Using the source code for SMW hacking would allow one to do things that would generally be too difficult or would require huge amounts of remapping to do normally, such as making most of the original sprites dynamic or increasing the max number of sublevels. Of course, if you're also using LM, then that can limit how much you can do. For homebrewers, there is no doubt that this would be useful to them.

4). I don't know what WLA has to offer over asar, and either way, asar suits my needs fine, aside from an annoying quirk asar has where it doesn't allow me to put ROM data in the upper half of banks 70-7D despite that area being valid for ROM data in the LoROM map. I'm forced to use xkas if I need that last .5 MB of space, and my ROM's checksum is also broken because the ROM size is 3.5 MB. I'd need to apply data in banks 70-7D in addition to 7E-7F just to make it the exact same size as what LM expands it to when you tell it to expand a ROM to 4 MB.

---

My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.

I appreciate the feedback. I won't post everything in detail but for now...


The update sitting on my desktop has every single ram address, aside from SMW's palette/image table defined. It also has structs/enums created. Definitions for the sound effects, button presses, sprite ID's, etc. etc. are planned as well.


Xkas was 100% neutral, then asar changed a couple small things to optimize it for smw. But asar is still homebrew capable.


I like the idea! Nonetheless in my current update I have a command line tool that can extract most of SMW's data since FuSoYa wouldn't add the option in LM. It can extract level data, overworld data, sprite lists, and RATS tag all from a ROM.


I agree that WLA's SPC assembler isn't the best. But nonetheless it works and assembles an identical rom. I tried many different assemblers, and technically CA65 would be the best but I liked the simple design of WLA more.

WLA? WHY??
Whenever I release the update, I'll go into full detail but in short here are some things i liked about it:
- Enumeration/structures for RAM (C/C++ people know this!)
- Library support (e.g. ditch patches and standardize code for everyone)
- Sectioning of code possible (pick and choose location)
- Makefile support (ohhhhh boy!)
- More well known, tutorials and examples written in WLA around the internet (SNES dev wiki)
- More portable/standard. WLA tends to look more like ANSI-C.
- More versatile macro commands. One can create table generating macros!
- Ability to specify the SNES header and memory map
- Ability to read specific data from an .INCBIN'd file. That is, writing GFX files across banks.
- (Asar needs this badly) Ability to do something based on user input. See below for example.
- Last but not least, WLA's definition system is more universal and versatile. You don't have to put an exclamation mark every time you need to reference a definition. Also, it allows you to redefine/undefine which is VERY useful. Especially in macros!!!

---

Super Mario World Source Code

Yep, same person. XD

I'm not really sure how the first thing you said relates to what I was saying, but maybe I'm just missing something. It sounds like you were replying to someone else, yet you only quoted me in your post.


Also, while I can move stuff around in the ROM, that doesn't mean I will. I'm attempting to maintain compatibility with LM while working with the source code so I must make sure certain things stay where they are or else certain LM features will not work, LM will think the ROM is locked/corrupted or LM will attempt to re-insert a hijack where it expects one to be and thus cause the game to either crash and burn, glitch up, or waste ROM space by inserting a copy of certain LM data and routines that are already in the ROM. If I move something, it's generally because I wanted to make a major change to it that required extra ROM space.

Banks 00,04,05 and the second half of 03 I have to be particularly careful with. However, I have free reign over banks 01 and 02 because LM inserts very few hijacks in them (and LM doesn't seem to try to re-insert them) and doesn't seem to check for anything located in those banks (aside from the Sprite 19 fix, but that can be turned off).

Also, I'm planning on switching to the BPS format anyway. At the very least, it will reduce the chances of someone applying a patch for my hacks to an unheadered SMW ROM and then PMing me for help because it didn't work.



As for the last thing you said, thanks! I assumed that asar treated banks 80+ not much differently from banks 00-7F so I never thought to try that. But, it worked. That will save me a lot of annoyance later on now that I know this.





Nice! I'll be looking forward to when you release the next update.

---

My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.

About WLA. Ville is active and has been updating it for the past little while. I also made some changes to improve its speed when a massive number of labels are present. Now would be a good time to file bug reports, about those SPC700 bugs and whatever else.

https://github.com/vhelin/wla-dx

I would be interested, especially that I was coding a special tool for my own disassembly but since yours is already completed, I'd love to input my own optimizations along the way. But good work anyway!

Thanks, I'm currently doing a couple of updates to the project. Theres a couple small bugs in the batch files that need to be worked out, once they are I'll update my OP with a link.

---

Super Mario World Source Code

Check out the new updates, the file is also now hosted on smwcentral in my files for convenience.

---

Super Mario World Source Code

The reversing of SMW all started when a friend of mine wanted to make his own Mario game. So I began this entire project with no other reason than to complete the source code and use it as a "base". However, time passed and neither of us had interest anymore. Towards the end of working on this project, I began converting the game to C. The intention of expanding the game to other systems well beyond the game's limits. Due to limitations of the SNES and poorly optimized compiler, however, this was not viable...

Today I began cleaning out my computer and decided to make a final release of the last thing I worked on. I began converting the code to C in October and haven't done anything since. Although this will serve as a "Proof of Concept", it should not be taken lightly. With enough time and effort, this could essentially be the next modding platform. I however, will not be furthering any more in the world of SMW. So I've decided to make this final, but perhaps the next person will take the task into their own hands down the road.

Anyhow, I enjoyed the learning experience and the great community here. I've posted the download link to the final "POC" project in the first link. Sorry for the lack of documentation on the project. The batch file can be a bit confusing. And the debug library (Crash handler) has no instructions how to set it up. But the files of interest are:
"ccode.c" -> Main program code
"smwmem.h" -> C memory header
"dbbrk.c" -> BRK/Crash library partially converted

As you will see, a variety of functions were converted. The game uses both ASM and C to compile. Many functions are commented out. This is due to the extreme cycle wastage thanks to bad optimization.

To use the batch file, for example, type:
Screen 1 -> "1" for project
Screen 2 -> "mw_e10" for your project folder
Screen 3 -> "1" to compile project

I'm off to another castle. But maybe one day I'll return with something...

---

Super Mario World Source Code

>SMW in C

... wait what.

---

There isn't much I can say but "whoa, kudos for trying and getting so far already" and "and it only took 10 years".

---

 

Not sure how I feel about this...
The idea of easy port to another system sounds great. However lets not forget about fullscreenmario either, or smbx or whatever it is. Iam quite sure nintendo will frown apon its source code being even more asscible then it is now.

There is a couple ways this could go, If nintendo doesn't plan on 2d mario platformers in the near future ( which I suspect its going to be long time, certainly after switch atleast.) They may see this as a positive thing that keeps that group of people interested in that genera for free to them while they make us wait for the next 2d mario.
however if they do have plans and people are able to make high quality mario games that a million people play as aposed to few thousand around there will be issues.

That all being said I would consider keeping it quiet untill its realeased.

Maybe in 2027 well get out of our flying cars to code for a 36 year old game

---

Super Mario World Source Code