 |
|
 |
|
| Disassembling SMAS (SMASH DIZ! Project) |
|
Forum Index - Non-SMW Hacking - Super Mario All-Stars - Disassembling SMAS (SMASH DIZ! Project) |
|
|
|
|
| Posted on 2009-07-05 05:40:16 AM |
Link |
|
I've been investigating Super Mario All-Stars (U) and Super Mario All-Stars (U) [!]. They seem to have no difference when it comes to code, graphics, tables etc. Except the [!] doesn't have a header, and the other one does have a header. And since I like working without headered ROMs...
So all the information we release here, can be used for Super Mario All-Stars (U) [!] too.
|
|
| Posted on 2009-07-05 11:51:41 AM |
Link |
|
Random n00b question[/shame]
What exactly is a header? I heard that it is important for some stuff, but not for what exactly. Like HDMA in SMW.
|
|
| Posted on 2009-07-05 02:47:00 PM |
Link |
|
No, it is not very important at all, in fact. At least not for ROM hacking.
Any decent tool should be able to work with and without headered ROMs. =/ Unfortunately, most do not.
|
|
| Posted on 2009-07-05 03:21:44 PM |
Link |
|
|
But LM does look at the header, right?[/offtopic]
|
|
| Posted on 2009-07-05 03:42:30 PM |
Link |
|
Exactly - that is one of the reasons why there could be a better level editor than Lunar Magic.
</off-topic>
|
|
|
|
| Posted on 2009-07-12 05:45:34 PM |
Link |
|
Sorry for not updating for such a long time - just wanted to say I finally know where the Layer 2 Map16 RAM table is (well, actually I knew 1 week ago).
The table is at $7F2000-$7FBFFF, and it's built up for the entire level, much like the Layer 1 Map16 table.
Sadly, however, almost half of it is data that is never used. =/ But I'm not sure if one should flag it as 'free RAM', since it might get overwritten, even though it serves no purpose.
Either way, I was too lazy to make an illustration of the Layer 2 Map16 pages, and I'm quite glad I didn't do so either yet, because Layer 2 seems to be different.
I mean, all these BGs SMB2 uses, they cannot possibly fit into 1 Map16 page. And that's right, they don't.
Instead, SMB2 uses tilesets for them. To be exact, tilesets 0-D. Perhaps you could compare them a bit with Map16 pages 10 and 11 in SMW. (Actually they're also 0 and 1 for backgrounds.) Except SMB2 has tons more. (Although a lot of these tiles are unused/garbage.)
Quote
POINTER_13A6E5: .dw TABLE_13A701 ; Tileset 0.
.dw TABLE_13A969 ; Tileset 1.
.dw TABLE_13A9C9 ; Tileset 2.
.dw TABLE_13AE41 ; Tileset 3.
.dw TABLE_13B029 ; Tileset 4.
.dw TABLE_13B201 ; Tileset 5.
.dw TABLE_13B351 ; Tileset 6.
.dw TABLE_13B3D1 ; Tileset 7.
.dw TABLE_13B7C9 ; Tileset 8.
.dw TABLE_13B9E1 ; Tileset 9.
.dw TABLE_13BDB1 ; Tileset A.
.dw TABLE_13C151 ; Tileset B.
.dw TABLE_13C309 ; Tileset C.
.dw TABLE_13C3E9 ; Tileset D.
After that, I was searching for character data writes to VRAM. I found all of the ones I was searching for - FG/BG and sprites.
Interestingly enough, in some levels, SMB2 doesn't load GFX slots per 7F tiles, like SMW does, but instead per 3F tiles.
This isn't really a fast and space-saving way to do it, I suppose, but I also suppose it allows you to mix tilesets very easily.
So with this information, and the information I got about the layer 2 tilesets, I created this (the palette is still off):
I also found additional stuff, like GFX pointers for the credits and such.
Oh yeah, and this was unrelated (some ROM address I found, you can change after which level the credits get activated):
|
|
| Posted on 2009-07-12 05:50:56 PM |
Link |
|
|
Is that last image an unused background? If it is, that is a very nice find.
|
|
| Posted on 2009-07-13 04:57:59 AM |
Link |
|
Originally posted by Airbourne BubblunIs that last image an unused background? If it is, that is a very nice find.
If I remember correctly, it's from the ending of SMB2.
|
|
| Posted on 2009-07-13 06:44:21 AM |
Link |
|
Originally posted by Airbourne BubblunIs that last image an unused background? If it is, that is a very nice find.
No, but I can conclude that this room has a HDMA BG slot of its own... because in the original ending, it looks quite different. I take it this room is actually considered a room of its own, in the big table of rooms?
|
|
| Posted on 2009-08-07 06:25:02 PM |
Link |
|
|
Anyone still disassembling this game?
|
|
| Posted on 2009-08-07 06:38:25 PM |
Link |
|
Roy is. I am still taking a break.
Yesterday I attempted to continue but I pretty much stopped after 2 minutes already. >_>
I either need some huge motivation or some huge break.
|
|
| Posted on 2009-09-05 05:55:18 PM |
Link |
|
I've been documenting some stuff from SMB1, and it is going really well. I have documented the level header and level number handler. Seems like bits 5 and 6 of the level number are used as a map type. They get shifted to the left 4 times. First time without carry, then 3 times with carry. The 2 bits eventually end up as bit 0 and 1, which can be used as the following for the map type:
Code00-Underwater
01-Ground
02-Underground
03-Castle
Right now I'm looking for the code which actually places stuff on the level (like objects).
(I am sure this data is useless to SWR though. Oh well it is MY disassembly. *shot*)
|
| Last edited on 2009-09-05 06:02:30 PM by Ersanio. |
|
| Posted on 2009-09-06 04:10:24 PM |
Link |
|
hmm... not a bad find.
As for finding objects, the data should be there somewhere, it's just finding some sort of a lead to it. Sometimes you get lucky. 
|
|
| Posted on 2009-09-12 09:51:22 AM |
Link |
|
OK, I took a break in August too, but now I'm documenting like crazy again.
So I found out that there's not only a sprite status table like in SMW (I'm still busy documenting that one), there's also (and that's something SMW does not have) a player status RAM address, $50. It does a number of things, namely these:
Quote
CODE_128039: A5 50 LDA $50 ; \ Execute pointer depending on player status.
CODE_12803B: 22 76 87 11 JSL CODE_118776 ; /
POINTER_12803F: .dw CODE_128071 ; 00 - Walk normal.
.dw CODE_12813B ; 01 - Climbing, normal.
.dw CODE_128109 ; 02 - Picking something up.
.dw CODE_1281F1 ; 03 - Climbing, entering new room.
.dw CODE_1281A7 ; 04 - Moving inside a jar.
.dw CODE_1281D5 ; 05 - Moving out of a jar.
.dw CODE_12822C ; 06 - Player walking into Hawkmouth.
.dw CODE_1280DE ; 07 - Dying.
.dw CODE_12824D ; 08 - Hurt / growing.
I haven't studied each single one in-depth yet, but I certainly will later.
I've only really looked into 04, 05 and 06, and I found some interesting results on the former one, while I was at it.
Namely, the table for the warp jars. Which worlds they warp to.
I've noticed that this has (severe) limits, though. First of all, you can only jump to the first level of each world. Secondly, you can only warp to 1 specific world per world. So if you want to warp to World 5 in 1-1, and you put a warp jar in 1-2 as well, that will lead to World 5 too. It shouldn't be too hard to get around this, though...
Finally, with the current method, it's impossible to warp to Worlds 1-3 seeing as there are no graphics for those numbers. They even compressed the tables to only include Worlds 4-7.
Here's what I'm talking about:
Quote
CODE_118CE5: AC 35 06 LDY $0635 ; \ Store original world number into $0405.
CODE_118CE8: 8C 05 04 STY $0405 ; /
CODE_118CEB: B9 B4 CD LDA TABLE_11CDB4,y ; \ Get new world number to warp to.
CODE_118CEE: 8D 35 06 STA $0635 ; /
CODE_118CF1: A8 TAY ; Into Y.
CODE_118CF2: A6 8F LDX $8F ; Player number into X.
CODE_118CF4: B9 B4 C9 LDA TABLE_11C9B4,y ; \ Get appropiate level number. (x-1)
CODE_118CF7: 8D 33 05 STA $0533 ; |
CODE_118CFA: 8D E8 04 STA $04E8 ; /
CODE_118CFD: 98 TYA ; World number to warp to into Y.
CODE_118CFE: 38 SEC ; \ Subtract 3 from the value. (There are no 'World X' graphics for Worlds 1-3)
CODE_118CFF: E9 03 SBC #$03 ; |
CODE_118D01: 0A ASL A ; | Multiply by 2 since we're going to read from a 16-bit table.
CODE_118D02: A8 TAY ; / And back into Y again.
CODE_118D03: C2 20 REP #$20 ; A = 16-bit.
CODE_118D05: B9 BB CD LDA TABLE_11CDBB,y ; \ $11BD-$11C2 = Tilemap of number in 'World X'.
CODE_118D08: 8D BD 11 STA $11BD ; | TTTTTTTT YXPCCCTT format.
CODE_118D0B: B9 C3 CD LDA TABLE_11CDC3,y ; |
CODE_118D0E: 8D BF 11 STA $11BF ; |
CODE_118D11: B9 CB CD LDA TABLE_11CDCB,y ; |
CODE_118D14: 8D C1 11 STA $11C1 ; /
CODE_118D17: E2 20 SEP #$20 ; A = 8-bit.
This is what you get if you try to warp to World 1 either way:
As for TABLE_11CDB4, yes, that's the table which contains the values of the world numbers you will warp to if you enter a warp jar, per world.
QuoteTABLE_11CDB4: .db $03,$01,$04,$05,$06,$05,$06
Warp jars were never existant in World 2, so that value doesn't really matter either way.
Hm... this reminds me of something SMB:TLL has done, warp pipes which don't lead you to a higher, but lower world. How evil. <
tl;dr : Well, that was my update. Nothing too interesting but I just thought I'd show that I wasn't taking a break on this. Right now I'll probably go more in-depth on those other states from $50.
Then the sprite states, and then I finally need to find the Layer 1 Map16 tile data. (And what it acts like, as well.)
|
| Last edited on 2009-09-12 11:38:16 AM by Roy. |
|
| Posted on 2009-09-16 02:21:17 PM |
Link |
|
Yay for double post.
So as I promised, I've been into SMB2 spriting. But not the kind of spriting I told I was going to do, at all. I said I was going to research sprite states, but at first, I actually stumbled upon something completely different : 'Tweaker' bytes. Data that controls if a sprite is vulnerable to bombs and shells, if it hurts the player or not, rideable, etc. I was only to place 1 bit (invincible to bombs and shells) yet, but I want to document every single one of them in the end, so don't worry about that.
Then... well, I went to the general sprite routines (I don't know if I told this already, but I've known the init and main sprite pointers for ages), and that increased the ROM/RAM map I maintain quite a lot.
I found out that SMB2 has $47 ($00-$46) regular sprites, and 3 generators. (Albatoss and Beezo generators, and one that stops them.) I didn't find out which routine handles these yet.
I've also noticed some sprites have dupes, mainly the bosses, but also sprites around them. There's a version which acts like normal, but there's also a boss version of them that activates a door when defeated. Yes, this means you can use bosses (not sure about Wart, but most likely) in regular levels without them opening doors or anything out of the regular.
And in the end I found a routine that handles object -> sprite things, like picking up a mushroom block or vegetable. I found stuff like how to keep getting a 1UP even after it's collected, and I also found a sprite table which contains which sprites are spawned for each object. By that, I was able to create this:
I'll certainly use this table in my SMB2 hack. Maybe not for picking up a Pidgit, but something will certainly come to mind.
And... that's about it, again.
Edit: Oh yeah, anyone who's interested in the list of sprites ($00-$46), wall of data coming in:
Quote
POINTER_129EEC: .dw CODE_129F96 ; 00 - Heart
.dw CODE_129F96 ; 01 - Shy Guy, red
.dw CODE_129F96 ; 02 - Tweeter
.dw CODE_129F96 ; 03 - Shy Guy, blue
.dw CODE_129F96 ; 04 - Porcupo
.dw CODE_129F96 ; 05 - Snifit, red
.dw CODE_12AC85 ; 06 - Snifit, grey
.dw CODE_129F96 ; 07 - Snifit, blue
.dw CODE_129F96 ; 08 - Ostro with red Shyguy
.dw CODE_12A01C ; 09 - Bob-Omb
.dw CODE_129F96 ; 0A - Albatoss with Bob-Omb
.dw CODE_12B27D ; 0B - Albatoss, coming from left
.dw CODE_12B276 ; 0C - Albatoss, coming from right
.dw CODE_129F96 ; 0D - Ninji, running
.dw CODE_12AC85 ; 0E - Ninji, jumping
.dw CODE_129FE3 ; 0F - Beezo, gold
.dw CODE_129F96 ; 10 - Beezo, red.
.dw CODE_129F96 ; 11 - Wart Bubble.
.dw CODE_129F96 ; 12 - Pidgit, carpet.
.dw CODE_12AE10 ; 13 - Trouter.
.dw CODE_129F96 ; 14 - Hoopster.
.dw CODE_12A9CB ; 15 - Shyguy generator.
.dw CODE_12A9CB ; 16 - Bob-omb Generator
.dw CODE_12A00F ; 17 - Phanto
.dw CODE_12CCBA ; 18 - Cobrat, jar
.dw CODE_12CCBA ; 19 - Cobrat, sand
.dw CODE_12CDE8 ; 1A - Pokey
.dw CODE_129F96 ; 1B - Bullet
.dw CODE_12AF2D ; 1C - Birdo
.dw CODE_12C7F8 ; 1D - Mouser
.dw CODE_129F96 ; 1E - Egg
.dw CODE_12CA80 ; 1F - Tryclyde
.dw CODE_129F96 ; 20 - Fireball
.dw CODE_12C270 ; 21 - Clawglip
.dw CODE_129F96 ; 22 - Rock
.dw CODE_12AC85 ; 23 - Panser, red
.dw CODE_129F96 ; 24 - Panser, blue
.dw CODE_12AC85 ; 25 - Panser, green
.dw CODE_129F96 ; 26 - Autobomb with Shyguy
.dw CODE_129F96 ; 27 - Autobomb fire
.dw CODE_12D595 ; 28 - Whale spout
.dw CODE_129F96 ; 29 - Flurry
.dw CODE_12D2FD ; 2A - Fryguy
.dw CODE_12D2FD ; 2B - Small Fryguy.
.dw CODE_12DB43 ; 2C - Wart.
.dw CODE_12D800 ; 2D - Hawkmouth boss.
.dw CODE_12A9D3 ; 2E - Sparky, right, slow.
.dw CODE_12A9D3 ; 2F - Sparky, right, fast.
.dw CODE_12A9D3 ; 30 - Sparky, left, slow.
.dw CODE_12A9D3 ; 31 - Sparky, left, fast.
.dw CODE_129F96 ; 32 - Small vegetable.
.dw CODE_129F96 ; 33 - Fresh vegetable.
.dw CODE_129F96 ; 34 - Vegetable thrower vegetable.
.dw CODE_129F96 ; 35 - Shell
.dw CODE_129F96 ; 36 - Coin
.dw CODE_129F96 ; 37 - Bomb
.dw CODE_129F96 ; 38 - Rocket
.dw CODE_129F96 ; 39 - Mushroom block
.dw CODE_129F96 ; 3A - POW block
.dw CODE_12BA59 ; 3B - Rolling log
.dw CODE_129F96 ; 3C - Door to dark room
.dw CODE_12ABAA ; 3D - Key
.dw CODE_129F96 ; 3E - Potion
.dw CODE_12AC85 ; 3F - Mushroom
.dw CODE_12AC85 ; 40 - 1UP
.dw CODE_129F96 ; 41 - Pidgit's carpet
.dw CODE_12AC78 ; 42 - Hawkmouth, face to the right
.dw CODE_12AC78 ; 43 - Hawkmouth, face to the left
.dw CODE_12ABCA ; 44 - Crystal ball
.dw CODE_12ABCA ; 45 - Star
.dw CODE_12ABCA ; 46 - Stopwatch
Ignore the stuff in front of the semi-colons, those are just the init subroutine pointers.
|
| Last edited on 2009-09-16 02:22:34 PM by Roy. |
|
| Posted on 2009-10-11 09:51:00 AM |
Link |
|
The following is related to SMASH DIZ to some extent, but mainly about my SMB2 hack.
I found a way to make 24-bit sprite pointers. This means sprite data that is going to be loaded for the level, does not have to be placed in bank 11 only - now, you can choose any bank you want. All sprite data from the same level has to be in the same bank, but that is really doable though. No-one is going to use up more than 32768 bytes for all sprite data from one level, because 1 level at max = 10 rooms of 16 screens each. So, you could see this as limitless.
I have yet to make 24-bit level pointers, however. These are a little bit trickier to make as the indirect pointer they use is not 24-bit, but 16-bit. They use ($D9), whereas the sprite pointers use [$00].
I would have to affect the data bank register to achieve a 24-bit effect, but it's not as simple as that. There are plenty of 16-bit loads and stores (STA $xxxx,y, LDX $xxxx,y, etc.), so moving them to banks 40-6F and F0-FF is tricky. I would have to pretty much rewrite the entire routine.
Banks 00-3F are not an option because the freespace in this area is scarce. If all else fails though, then I'll be sure to cram this code in this scarce freespace.
Note: Reason why I was unable to finish these sprite pointers earlier was because I had no idea how banks 40-6F and F0-FF worked. Blame this page for completely misinforming me. I had to patch to $408000, not $400000 like this page stated. Derp.
|
| Last edited on 2009-10-11 09:55:43 AM by Roy. |
|
| Posted on 2009-10-30 12:31:32 PM |
Link |
|
Originally posted by RoyI have yet to make 24-bit level pointers, however.
Roy...I am smashdizappointertable.
...
Well, anyway, interesting. What is $DB used for? You can't just change the routine to use [$D9] instead? Then again, the level data isn't all in one bank...is it? If so, then, yeah, you might have to change the data bank depending on the level number. As for the sprites, that's interesting...as you may or may not know, I'm always interested in the sprite stuff. The player status thing, $50, is really interesting too...$71 in SMW is sort of like that, but it's not quite the same. /me includes it in his custom RAM table
|
|
| Posted on 2009-10-30 08:49:53 PM |
Link |
|
Eh. We're 3 weeks further, but alright. So you got your idea from imamelia, SWR. 
Well, I'll say the same as I said to SWR:
I think $DB is already used (it would be too good to be true if it wasn't), but I'll double-check that.
As for level data. It's all in bank 11, no trouble here.
Lately I've been trying to document a few other things such as Layer 3 displacement when entering a room in a certain screen, but I can't tell a lot about this yet.
No noteworthy SMASHDIZ post, sorry. Haven't been busy at all with 24-bit level pointers.
|
|
| Posted on 2009-11-04 01:25:31 PM |
Link |
|
It's time we get this project GOINGNGNGNGNGNGNGNGNGNGNGNGNGNGNGetc. so I decided to stagnate the SMB2 part of SMAS Dis for a while.
Instead, I'm going to try to disassemble all of SMB3, or at least, whatever part of that is relevant. (NOT: SPC and graphics, that could be done at a later time.)
I know Ersan hasn't decided this with me yet, but it seems like the best way to speed this thing up. Ersan will do the documenting.
I expect to be done with this in 1-2 weeks.
So yeah, don't expect any SMB2 stuff soon. This also means I won't release any demo of SMB2:TLD for C3. Heh.
|
|
|
|
|
|
|
Forum Index - Non-SMW Hacking - Super Mario All-Stars - Disassembling SMAS (SMASH DIZ! Project) |
|
|
 |
|
 |
The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.
Copyright © 2005 - 2013 - SMW Central
Legal Information - Link To UsTotal queries: 27
|
|
|
|
