Banner
Views: 714,139,517
Time:
19 users online: Aqua-Grove-Prod, Bille, chickaDEE Magazine, DDC ecil, ExONightZ, Giftshaven, JacquesPaught, kyasarintsu, o LethalBrownies, Lsh0426, mario90, Mediocre Espurr, Mrmariobros222, prismmm, Sariel, SnowyBot, Svorass, The Milkman, UmHey420 - Guests: 40 - Bots: 118Users: 37,291 (1,617 active)
Latest: jpegsarebad
Winter 2019 C3 Content Spotlight
KKevinM's "Easy" To Use Reznor Sprite!
Not logged in.
Yoshifanatic's ASM Showoff: Part 7
Forum Index - Important - SMW Central Creativity Convention: Winter 2019 - Yoshifanatic's ASM Showoff: Part 7
Tags:
Pages: « 1 »
Happy C3 guys! :)

Anyway, I only have one thing to show this C3, but it's a pretty large thing, and those of you that saw my previous C3 thread will know what that thing is:

My SMW Disassembly

I've been working hard on this since July and it's now in a state where most of the major things have been finished. So, what has changed since July? Here is a short list containing some of the highlights:

- Fully isolated the code for every routine into separate macros.

- Added support for all 7 SNES versions of SMW (Japan, USA, PAL 1.0, PAL 1.1, SMAS+W USA, SMAS+W PAL, Arcade), which is one more version than I initially thought there were back in July.

- Added some patches that allows you to enable debug features, view level data outside of the standard 512 sublevel table in Lunar Magic, and a (WIP) one that shows you the location of specific LM labels and where they're supposed to be.

- Added tons of defines for things, like sprite IDs, controller bits, sprite properties, etc., which should make things easier to change and also make the code easier to follow.

- Made the level data use MWLs.

- Added a bunch of labels for Lunar Magic hijack locations (although I'm not too satisfied with their formatting).

- Created a makefile to allow non-Windows users to kind of assemble this disassembly. (I say "kind of" because it's incomplete and I'm struggling to implement the features I want).

- Tons of bug fixes, quality of life changes, etc.

- Added a changelog listing the updates for each version in more detail.

At this point, I'd say that my disassembly is now capable of being used as a resource, both for researching the function of different routines, and as a way to assemble a base ROM of one's hack (assuming you're not using any patches that require LM's ASM to work correctly). I need people to use this, especially the advanced ASM users, so I can get feedback on how to improve the disassembly. Because so far, I only know of two people who have actually downloaded and used it, and only one of them (DPBOX) has given any feedback on it.

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

As a little surprise, since I added support for the two SMAS+W versions, my SMW disassembly is now technically a SMAS+W disassembly because I had to disassemble the title screen and menu to get those versions working. Not only does that mean you could take advantage of that for your own hack (like if you wanted to make a hack similar to my own "Mario & Yoshi's Strange Quests" where it's multiple games in one), but that also means I or someone else could disassemble the other SMAS games and have them be handled separately from each other. And you know what? I decided to disassemble SMB3.

SMB3 is one of those games I've been curious to see how it worked, so since late November, I've been working on it in secret. I did this without any existing documentation, just me, a USA SMAS+W ROM, SHex, and BSNES Plus. While the SMB3 disassembly is far from finished, I got enough disassembled that you can at least reach the map screen (even though most of its data is missing):



Even then, there is still plenty that is not working. For starters, I haven't figured out what loads in all the colors on the title screen, so it looks like this:



I managed to figure out a bunch of RAM addresses, the location of the 1-1's sprite data and the format it's in, most of the normal and extended sprite IDs, and plenty more though. If you want more details, look at the ROM Map and Notes file for SMB3 in my disassembly.

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

Anyway, as I did last C3, here are some fun facts about SMW, specifically regarding the different versions. Did you know...

- Most of the version differences between the Japan and USA are very uninteresting. Most of them are simply compiler related, where various opcodes use different addressing.
- SMAS+W PAL's version of SMW is PAL 1.1.
- Due to removing the ability to start+select out of a level, the arcade version also removed the debug code that lets you beat a level this way.
- The two standalone PAL versions lack the powerup select and free movement debug codes while the SMAS+W PAL version combined them into the same routine.
- The two SMAS+W versions implement the separate Luigi graphics differently. USA has a separate routine at $33E05E for Luigi's graphics accessed from within UploadPlayerGFX ("MarioGFXDMA" in all.log). PAL has a JSL/RTS at the start of UploadPlayerGFX and puts a routine at $36F600 that handles both players' graphics in the same routine. Luigi's graphics are stored uncompressed at $02A000 in both versions.
- The SMAS+W ROM Map for SMW goes as follows: Bank 00-07 = 30-37, Bank 08-0B = 4A-4D, Bank 0C-0D = 2B-2C, Bank 0E-0F = 4E-4F.
- The PAL 1.1 and SMAS+W PAL versions have different compressed graphics data than the USA/PAL 1.0/SMAS+W U/Arcade versions despite the decompressed graphics being identical.
- The castle dirt map16 tile in PAL 1.1/SMAS+W PAL has its tiles Y flipped for some reason.
- The arcade version is the only version I'm aware of that has a bad checksum ($0000, when the assembled ROM's checksum is $4B30). I have no idea if the version I had is a bad dump or if it just happens to be that way.
- The arcade and two standalone PAL versions have garbage data in most of the freespace areas. I have no idea why it's there.
- 99% of the RAM map is accurate to all versions of SMW. Ignoring the global SMAS+W RAM addresses, here are the RAM addresses that are version specific:
Code
$7E007C - Used in the PAL versions as the Y equivalent of $7E007A.
$7E0110 - Scratch RAM in CreditsFadeOut routine in PAL 1.1/SMAS+W PAL.
$7EC700/$7FC700 - The map16 table starts 256 bytes earlier for some reason in the two SMAS+W versions.
$701000 - Start of the save file data in both SMAS+W versions.


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

Anyway, that's it for this post. I hope you guys liked what I had to show off! :)

Oh, and thanks to randomdude999 and the others working on asar for the latest version. I made some last minute adjustments to my disassembly to make use of it, which brought compile time down to 11 seconds (~17 second saved).

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My WIP SMW/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
It's hard to read this topic and not be impressed by the sheer amount of work you've put in and the many findings you were able to unearth.

Originally posted by yoshifanatic
I need people to use this, especially the advanced ASM users, so I can get feedback on how to improve the disassembly. Because so far, I only know of two people who have actually downloaded and used it, and only one of them (DPBOX) has given any feedback on it.


I must admit that using a split is much cleaner than our current clunky approach of inserting hijacks everywhere, but I do think that this is kind of an uphill struggle with all tools currently expecting that we do exactly that. I struggle to find a practical use for your work in everyday hacking, besides using it as an impressive source of documentation.

Nevertheless, your work is amazing! Thanks for sharing!
Originally posted by Ragey
It's hard to read this topic and not be impressed by the sheer amount of work you've put in and the many findings you were able to unearth.

Originally posted by yoshifanatic
I need people to use this, especially the advanced ASM users, so I can get feedback on how to improve the disassembly. Because so far, I only know of two people who have actually downloaded and used it, and only one of them (DPBOX) has given any feedback on it.


I must admit that using a split is much cleaner than our current clunky approach of inserting hijacks everywhere, but I do think that this is kind of an uphill struggle with all tools currently expecting that we do exactly that. I struggle to find a practical use for your work in everyday hacking, besides using it as an impressive source of documentation.

Nevertheless, your work is amazing! Thanks for sharing!


Thanks! ^_^


By the way, I took the current way hacks are made into consideration, as this disassembly has a couple features to make it somewhat usable with those tools. For example:

- A toggle-able feature to hardcode the locations routines are inserted at so that moving one doesn't cause other routines to shift and you're warned when the program counter is later than it should be.

- A macro that prints out the PC address of the label it's given.

- A system for applying patches to the disassembly so those that don't plan on modifying it will still be able to make use of it.

Unfortunately, there is only so much I can do, as yeah, the major tools aren't built to work with a split disassembly (though some are mitigated by the ability to output their changes as a patch, which removes the need to use said tools on the generated ROM). If it wasn't for Lunar Magic, I could see it being feasible for the average user to make a hack with custom levels, overworld, music, sprites, blocks, etc. without actually touching the underlying disassembly. FuSoYa did make it possible to insert some of LM's hijacks through the command line as of 3.00 (ex. put LM in the bin folder, then add
Code
"Lunar Magic.exe" -ImportLevel "%output%" "%GAMDID%\levels\105.mwl"
to Assemble_SMW.bat after the line where FinalizeROM.asm is applied), but he'd need to go further with this functionality before I'd consider it ideal.

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My WIP SMW/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
Your ASM disassembly project is pretty much solid at this point. It's impressive the work you have done.

You can write a ROM that it lets you take down the input (normal hijack based) ROM differences, take the hiack + freespace address and then insert into the disassembly based one. Of course it requires doing some reloc based changes that may not very easy at all, but if you modify the former ROM to have a freespace map similar to the disassembly based one, you only would have to worry about the hijack, I think.

How is LM 3.00 and SA-1 Pack support?
dude all of your c3 asm posts are amazing

So if I'm reading this right, the dissassembly could potentially replace the need to find a rom by taking its place?

my brain is half melted right now from drawing faces, beards, and hats on stuff.


Looking through the files, I must say that, while being rather complex... they're organized to the point that, if I ever wished to edit any aspect of SMW... I could find the necessary information quite easy.

Now the problem is... SMWC is too much accustomed to patching ROMs. I find the split disassembly approach to be nice in a sense of better find what routines in SMW do and how they're organized; however, for now, I don't see an immediate response good enough of the majority of SMWC. Do not be discouraged, though: this kind of work is important and, moreover, gives you a nice understanding of how the games you disassembled work.

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


LadiesMan is a ladies' man,
Eevee is cute;
Noivern can shatter eardrums,
and beware, Major Flare blinds you.


Hey your work is Fantastic Yoshifanatic!

I have no idea on how to dissemble any game, but you certainly have a nack for it! It is very interesting indeed to see how these games work on the inside.

Keep it up!
Originally posted by Major Flare
Looking through the files, I must say that, while being rather complex... they're organized to the point that, if I ever wished to edit any aspect of SMW... I could find the necessary information quite easy.

Now the problem is... SMWC is too much accustomed to patching ROMs. I find the split disassembly approach to be nice in a sense of better find what routines in SMW do and how they're organized; however, for now, I don't see an immediate response good enough of the majority of SMWC. Do not be discouraged, though: this kind of work is important and, moreover, gives you a nice understanding of how the games you disassembled work.

I mean if I understood ASM in the slightest I would definitely be ecstatic right now. Nevertheless I still think it's really cool, especially having the differences between versions lined up. Good stuff.

--------------------
Originally posted by Vitor Vilela
Your ASM disassembly project is pretty much solid at this point. It's impressive the work you have done.

You can write a ROM that it lets you take down the input (normal hijack based) ROM differences, take the hiack + freespace address and then insert into the disassembly based one. Of course it requires doing some reloc based changes that may not very easy at all, but if you modify the former ROM to have a freespace map similar to the disassembly based one, you only would have to worry about the hijack, I think.

How is LM 3.00 and SA-1 Pack support?


That's good to know!

Anyway, that sounds like a good idea. I could probably create a patch that reads hijacks from a LM hacked ROM, insert them at the expected location, and insert any expanded area stuff at the original location.

As for LM 3.00 and SA-1 support, I've added labels for some of the LM 3.00 hijacks, but I haven't really dug too deep into it. Some of the new code also seems particularly complicated and I haven't quite figured it out yet either. As for SA-1 support, the only thing I've done is add a couple SA-1 registers to Global_Definitions.asm, and that's because those ones were used by LM's ASM. I do plan on adding more register defines not only for the SA-1 but for the other chips as well. Given how useful of a patch your SA-1 patch is, would you like me to attempt to add built in support for it? I don't know how much work that will be, but a good chunk of the work is already removed thanks to every RAM address having a define.

Originally posted by Taffy
dude all of your c3 asm posts are amazing

So if I'm reading this right, the dissassembly could potentially replace the need to find a rom by taking its place?

my brain is half melted right now from drawing faces, beards, and hats on stuff.


Thanks! ^_^

Yeah, with this, you technically don't need to find a SMW ROM, not that they are hard to find. Well, maybe a couple of the versions are, but the one that most people hack (USA) is not hard to find.

Originally posted by Major Flare
Looking through the files, I must say that, while being rather complex... they're organized to the point that, if I ever wished to edit any aspect of SMW... I could find the necessary information quite easy.

Now the problem is... SMWC is too much accustomed to patching ROMs. I find the split disassembly approach to be nice in a sense of better find what routines in SMW do and how they're organized; however, for now, I don't see an immediate response good enough of the majority of SMWC. Do not be discouraged, though: this kind of work is important and, moreover, gives you a nice understanding of how the games you disassembled work.


That's good to know. Personally, I think a couple things could be organized better (like the macros in Routine_Macros_SMW.asm, but CTRL+F makes this kind of unnecessary), but in some ways, I'd say it's much easier to find things compared to all.log, especially since every routine and various tables now have a name attached to them.

Also, while the current tools don't favor hacking with split disassembles, I did take the hijack based hacking approach into consideration. For those that don't want to mess with the underlying code, I have a system in place to automate inserting patches when a specific define is set to !TRUE. This makes patch/tool development easier, makes it easier to test for patch conflicts and reduces the risk with trying out a patch before using it, makes it easier to create a base ROM for a collab or to simplify the process of porting things to a new ROM, etc. This disassembly has its uses even if it's not being used as the base for ones hack. That said, I'd like to see tools that are built with split disassemblies in mind (ex. Horrowind's WIP level editor, Mockup), but I'll just have to wait and see.

Originally posted by Final Theory
Hey your work is Fantastic Yoshifanatic!

I have no idea on how to dissemble any game, but you certainly have a nack for it! It is very interesting indeed to see how these games work on the inside.

Keep it up!


Thanks! ^_^

Also, disassembling an SNES game will be one of the future ASM lessons I'll be giving you, but that won't be for a while. To sum it up, using the SNES SMB3 as an example:

It's like a giant jigsaw puzzle with no picture on the pieces. You have to start with the things that are guaranteed such as the cartridge header/hardware registers (or the corner/edge pieces in a puzzle). Once you do that, you look for certain patterns. For example, if you find code that writes to $2104, then you now know where an OAM buffer is ($7E0800). If you see a routine that loads #$BBAA and #$CC into A/X/Y and also has references to $2140-$2143, then that's an SPC upload routine. If you see a routine writing a large number of bytes to $2122 from a RAM address, then that means the game is using a palette mirror ($7E1300, with $7E1500 being a flag determining whether to upload the buffer to CGRAM). Once that's done, other pieces fall into place (oh, this routine is writing to $0800-$080F and $0A00-$0A03 so it's drawing a sprite). You do this until you eventually have the whole game disassembled. You may hit a stumbling block somewhere, where you have no idea what the heck some random routine is doing, but that's where your debug emulator comes in. You have to figure out when the routine is executed/data is read, then once you do, you play around with the bytes to see what it affects. In addition, you keep notes so you don't forget what X routine was/is suspected of doing.

Originally posted by Gregor
I mean if I understood ASM in the slightest I would definitely be ecstatic right now. Nevertheless I still think it's really cool, especially having the differences between versions lined up. Good stuff.


Thanks! ^_^

Also, while you may not know ASM, you might be able to follow along with some routines in my disassembly because a lot of things have descriptive defines that make their function clear. While there is still plenty of things I could do to improve this further, I'd say what I've done so far is pretty decent.

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My WIP SMW/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
The sheer amount of work you're continuing to put into this is incredible.

I admit that SMWDisC has been serving me well enough so far, but for more in-depth ASM work, this is something nobody can afford to not keep in mind.

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


 
Wow your so silent, amazing talent often goes unnoticed unless it's c3. Really intelligent, your work is really impressive.
Originally posted by yoshifanatic
At this point, I'd say that my disassembly is now capable of being used as a resource, both for researching the function of different routines, and as a way to assemble a base ROM of one's hack (assuming you're not using any patches that require LM's ASM to work correctly). I need people to use this, especially the advanced ASM users, so I can get feedback on how to improve the disassembly. Because so far, I only know of two people who have actually downloaded and used it, and only one of them (DPBOX) has given any feedback on it.


I'm very much interested in trying this out. I'm already pretty deep into SMW's engine at the moment because of my work on Extra Mario World, so should be able to contribute with some insights. Without having actually tested anything, I can at least say that it seems like you've been working crazy hard on this. You really are a mad scientist, aren't you?
We’re looking for level designers to work on Extra Mario World!
Originally posted by WhiteYoshiEgg
The sheer amount of work you're continuing to put into this is incredible.

I admit that SMWDisC has been serving me well enough so far, but for more in-depth ASM work, this is something nobody can afford to not keep in mind.


Thanks! ^_^

Also, SMWDisC/All.log still have use over my disassembly, as my disassembly removed a lot of the X_Address: labels (though that was more galaxyhaxz doing). It's harder to pinpoint an exact address so it's beneficial to use t in conjunction with my disassembly to get around this. There's also the fact that most of the comments are gone (again, galaxyhaxz) and the new ones I've added generally don't explain what a routine is doing, but instead point out glitches, opportunities to optimize the code, trivia, LM related info, etc. I opted to have the code speak for itself, since the defines and labels are very descriptive. I also took the opportunity to fix a lot of the table formatting to be much more helpful. Just look at the table at $04F625 (overworld sprite data) or $019B83 (generic sprite GFX routine tile numbers) and to see what I mean.

Originally posted by zacmario
Wow your so silent, amazing talent often goes unnoticed unless it's c3. Really intelligent, your work is really impressive.


Thanks! ^_^

And yeah, I tend to be kind of inactive here. I do have a Discord server where I'm more active with posting updates about my projects (though not 100% of the time, as was the case with the SMB3 stuff). However, that might change a bit, at least for the SMW disassembly, since I'll probably make a thread for it after posting in the C3 threads is disabled.

Originally posted by Von Fahrenheit
I'm very much interested in trying this out. I'm already pretty deep into SMW's engine at the moment because of my work on Extra Mario World, so should be able to contribute with some insights. Without having actually tested anything, I can at least say that it seems like you've been working crazy hard on this. You really are a mad scientist, aren't you?


Alright! I'll be interested to see whatever insight you'll have on this.

Also, you could say that about me. XD *ominous thunder sound* Huh, when did it start raining?

And like any good scientist, I've been hard at work. Last night I made these changes to the disassembly for the next version:

- Made it so that the SRAM will automatically remap itself based on the memory map. LoROM maps it to $700000, HiROM maps it to $206000, and SA-1 maps it to $400000.

- Added support for 256 KB of SRAM/BW-RAM and 2.5 MB ROMs (the latter was due to SMAS+W being that size).

- Made asar display information about the current SNES header settings, specifically the internal name, memory map, cartridge contents (including certain chips if applicable), ROM/SRAM size, distribution region, licensee, and ROM version number.

- Rewrote the address offsetting used in the BANK_START macro to both be more efficient and to fix the broken HiROM offsetting (I didn't quite understand how that worked until recently). I'm currently not sure if the SA-1, ExLoROM, and ExHiROM offsetting is correct though. That said, even though the HiROM offsetting works now, SMW won't work if you compile it that way.

- Re-enabled the ability to use a custom ROM_Map.asm file, allowing one to edit the order of routines without needing to edit ROM_Map_SMW.asm.

- Added some defines for several hardware registers.


I'm also currently doing what Vitor suggested and attempting to write a patch that extracts LM's ASM from a hacked ROM and inserts it into the disassembly and attempts to put the data at the original location LM inserted it at. However, I'm stuck trying to figure out how to deal with RATS tags that are found at the end of a previous bank.

I've written asar code that extracts data from a ROM for my hack, but I never bothered with the RATS tags because they were just wasting space in my hack's ROM (no joke, 28 KB!). I think the check bankcross command would help so I don't have to worry about the current memory map, but then asar will decide "oh, I just noticed you're not using FastROM addressing! Here, let me fix that for you! *brain fart* What was I doing again? Oh right, turning bankcross checks back on...". Despite how it might sound, that's more of a problem than one might assume. I had to disable the routine location hardcoding for the freespace block at $0BFD0D because asar will switch to FastROM addressing when inserting the block of compressed graphics and then think that the current PC address is $8BFD0D afterwards and thus trigger the warnpc error. This would also cause the bank bytes of the compressed graphics to assemble incorrectly before I hardcoded them to not use FastROM values. As one might guess, that might get awkward if one decided to move these graphics to banks $FE/$FF...

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My WIP SMW/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
I've been working pretty hard on my disassembly these past few days, and I've decided to update it. You can find the update by clicking the link in the first post. Here's the changelog:


SMW:
- Added in defines for the SMW overworld maps.

- Removed the "&$7F" on the bank bytes for the compressed graphics, as asar 1.71 fixed the behavior of check bankcross.

- The freespace block at $0BFD0D no longer throws an error when hardcoding its position for the same reason as the above change.


SMB3:
- Restructured this disassembly to be in line with how SMW/SMAS are set up.


SMAS:
- Added in defines for various RAM addresses

- Made it possible to disable SMB3 from assembling if assembling SMAS.

- Isolated the code for several routines.

- Added an option to disable the copy protection checks in order to allow one to safely change the SRAM size of SMAS+W.


General:
- Made it so that the SRAM will automatically remap itself based on the memory map.

- Added support for 256 KB of SRAM/BW-RAM.

- Added support for 2.5 MB ROMs, since that's the size SMAS+W is.

- Made asar display information about the current SNES header settings.

- Rewrote the bank handling system to fix the memory mapping for HiROM and SA-1 (though ExLoROM/ExHiROM don't work yet). In addition, setting the ROM size greater than 4 MB and the mapper to SA-1 will now make asar use fullsa1rom addressing.

- Added a bunch of error checks when setting the banks to reduce the chances of overwriting data that's already been inserted. Banks must now also be inserted in ascending order.

- Enabled the ability to use a custom version of ROM_Map_X.asm, RAM_Map_X.asm, Macros_X.asm, Routine_Macros_X.asm, and Misc_Defines_X.asm. You may also specify the path to the file so asar will know where to look.

- Added in some defines for various hardware registers

- Updated the readme because it was pretty out of date.

- Updated the included asar version to 1.71.

- Cleaned up the InitializeROMSettings macro to be more general purpose. The SMW/SMAS specific stuff has been offsourced to a game specific version of these macros.

- Moved the ROM setting stuff from Global_Definitions.asm to game specific AssemblySettings_X.asm files. This also means that one can have different settings between SMW and SMAS.

- Made it possible to easily change the unused Native/Emulation mode vectors in the cartridge header, just in case some chip happened to use them or the user wants to make use of these 8 bytes.

- When inserting a block of data that spans multiple banks, asar will now print out both the amount of bytes inserted and the bank range they were inserted at.

- Removed various junk/unused files and organized the messy SMAS and SMB3 folders.

- Updated this changelog to divide it up into sections specific to each game and a general section for global changes. I also corrected the entry for (4/19/18) because I accidentally used the changelog for (4/16/19).

- Moved a couple files to a new Global folder to reduce clutter.

- Other miscellaneous changes.

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My WIP SMW/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
Now that's what we call the REAL SMW disassembly! Great job, yoshifanatic!

Don't forget to vote for me this C3!
Something that you SHOULD even try: Thin Tofu Brownies.
Next thing ya know, they'll be saying I've gone soft. Morph, knock it off.
Ha ha ha! Would you like to make any other comments about my place being in the kitchen?
Originally posted by kamekku14
Now that's what we call the REAL SMW disassembly! Great job, yoshifanatic!


Thanks! ^_^



Regarding updates, progress slowed down a little, but yesterday, I sat down and took another stab at the SMB3 disassembly. Now, I got it to where the level finishes loading without crashing... but then Mario dies, a glitchy "Time Up displays, and then the game crashes. XD I also figured out where the extended sprites ($27C536, 16-bit pointers at $27C5DD) and shooter sprites ($27D840, 16-bit pointers at $27D86E) are processed. Also, I fixed an oversight where when I changed the SMB3 disassembly to be in line with the others, I accidentally copy and pasted the SMB3 bank 40 macro 8 times. This meant that the graphics stored there also got copied to banks 41-47, and ... well...


You know, something seems off about this title screen. Maybe I'm just imagining it.




On the SMW side of things, I've been modifying Vitor Vilela's SA-1 pack (1.31) to work with the disassembly. So far, here is what I've done:

- Removed defines/hijacks/print statements/etc. that are made redundant by my disassembly's built in features. A good 95% of all the hijacks became unnecessary thanks to the fact that every RAM address has a define containing a 24-bit value and that I added the ability to specify a custom RAM Map file in the last update.

- Replaced some hardcoded RAM/register references with defines.

- Added a new "main" patch that gets applied instead of sa1.asm. This file throws errors if certain assembly settings are not set to what this patch expects (ex. You must set !Define_Global_Hack_ROMLayout to !ROMLayout_SA1ROM) and also integrates the functionality of 6/8mb.asm if the ROM size is set to be 6/8 MB.

- Modified the coding style a bit to be more in line with how the rest of the disassembly is handled (ie. putting .b/.w/.l after every opcode that supports them, changing if/else that use 0/1 to use !FALSE/TRUE, adding : after sublabels and +/- labels, etc.).

I'm doing this for a variety of reasons, like the fact that having this built in allows it to work even if you change the version (which opens the possibility of SMAS+W using the SA-1 if I figure out what hijacks to move), it's a major patch that's incredibly useful, and it will help give insight in how one would go about integrating a large patch.

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My WIP SMW/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
Most of this is way beyond the scope of what I understand when it comes to ASM, but that progress made on SMB3 has me excited in a way that I don't think I've felt about romhacking in a long time. Sure it's small so far, but the progress is incredible to see nonetheless.
The other disassemblies should come in handy for other users.
Pages: « 1 »
Forum Index - Important - SMW Central Creativity Convention: Winter 2019 - Yoshifanatic's ASM Showoff: Part 7

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

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


Total queries: 23

Menu

Follow Us On

  • Facebook
  • Twitter
  • YouTube

Affiliates

  • Talkhaus
  • SMBX Community
  • GTx0
  • Super Luigi Bros
  • ROMhacking.net
  • MFGG
  • Gaming Reinvented