 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
1 user currently in Rom Hacking:  hukka |
| Acmlm's Board - I2 Archive - Rom Hacking - Locks on the World Maps in SMB3 Are Very, Very, Very Complicated |
 |  |  |
| Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| User | Post | ||
beneficii Lakitu Level: 36 Posts: 106/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
| I found a chunk of code that I believe is related to the locks in SMB3. I'm trying to find the code that goes before this code, and I'm trying to find the later ASM that uses the values stored by this one. Note that the bank of code starting at the Rom's 14010 and lasting 2000 bytes is stored at bank C000. To convert an address found here to the ROM address. In the comments, all numbers mentioned are in hexadecimal unless otherwise specified. But here goes: This code starts at 148DD in the ROM, C8CD in the game's memory: DEC $0745 LDA #$80 STA $04F2 LDY $0727 LDA $C898,Y //These values seem to increment by four lasting 10 bytes. CLC ADC $0745 TAY LDA $C878,Y //These values seem to affect what happens down the code more--keep an eye out for where the value here is kept stored for the whole code from here: $0745 STA $0745 LDA #$01 STA $20 //This'll come up shortly LDY $0300 LDX $0745 // I'm guessing that this is the current lock number, but I'm not entirely confident in this LDA $C7BD,X //Change the value of the first one (which seems to affect the first lock) and there are weird effects on the first lock when it is unlocked; changing it seems to change wildly the position of graphical change STA $0A STA $0301,Y INY LDA $C7CE,X //The arbitrary values here affect the position where the new tiles will replace the old ones; I was able to get this to actually replace a lock in a different position from the original, but I couldn't make the graphical change stick after Mario entered another stage; there is obviously another piece of data missing STA $0B STA $0301,Y INY LDA #$02 STA $0301,Y INY LDA $0745 ASL ASL TAX LDA $C801,X //C801 seems to be the 4 8x8 tiles that replace the lock (try modifying them--you'll notice that it does change the graphics that replace the lock), with the first byte being the upper left, then upper right, then lower left, then lower right; it has been somewhat interesting trying to change the values of these; set them to 0 and you get weird dancing hills; STA $0301,Y INX INY LDA $C801,X STA $0301,Y INX INY LDA $0B CLC ADC #$20 STA $0B LDA $0A ADC #$00 STA $0A STA $0301,Y INY LDA $0B STA $0301,Y INY LDA #$02 STA $0301,Y INY LDA $C801,X STA $0301,Y INY INX LDA $C801,X STA $0301,Y INY LDA #$00 STA $0301,Y STY $0300 LDA $0745 ASL TAY LDA $C7DF,Y //Try changing these values; they have interesting effects actually; STA $0A INY LDA $C7DF,Y STA $0B LDY $0A LDA $7D00,Y //I believe that if C878 were set to 0 (as it seems to be for most locks), then it loads from $7D06 to be exact; of course, what this piece of code does is a bit confusing, so it might be helpful to try to find what stores to this address; but I find using nnesterj that during most gameplay, this is zero; after finishing the first fortress and as the code changed, 7D06 changed to 8 then finished at 18 and stayed that way AND $0B BNE SAFETY //I'm not sure what this about, but it is dependent on C7DF + 1 + (current lock number?) and the value at 7D00 + )value of C7DF+ (current lock number?)); if any of their bits match up, then you ride the BNE to the next desitnation and skip the whole next piece of code; LDA $7D00,Y ORA $0B STA $7D00,Y LDA $7D40,Y ORA $0B STA $7D40,Y LDX $0745 //Keep an eye on X LDA $C856,X //The screen data at the low nibble? AND #$0F ASL //This doubles the screen data value TAY //and transfers it to Y LDA $8000,Y //I think checking the second-to-last-bank of this PRG-ROM could be helpful; I noticed in the RESET routine of the ROM that the two last 8k banks of the PRG-ROM are hardwired to 8000 and E000; apparently, the screen data is important to this, but the values are woefully random and are hard to make any meaning of CLC ADC #$F0 STA $0E LDA $8001,Y //Another interesting set ADC #$00 STA $0F LDA $C856,X //X data as posted by Dahrk Daiz, but does not affect graphical change LSR LSR LSR LSR ORA $C845,X //Y data as posted by Dahrk Daiz, but does not affect graphical change TAY LDA $C867,X //Tile data as posted by Dahrk Daiz; this does not seem to change the graphic, it only changes the passability to the matching map tile STA ($0E),Y //Y data affects where exactly this is stored; it seems an address was stored here; all addresses you access seem to be on the SaveRAM; LDA $15 AND #$03 BNE SAFETY2 //I'm not sure what address 15 is about, but if it's 3, then you get to skip the BNE; INC $20 LDA $20 CMP #$07 BEQ SAFETY SAFETY2: LDY $0745 LDA $C845,Y STA $00 LDA $C856,Y AND #$F0 STA $01 LDY $20 JSR $ABCF //I'm not sure which bank is currently attached to A000, but I'm guessing the one before this (I'm not entirely sure how PRG-ROM is attached, if both both 8k banks have to be consecutive); unfortunately I've not ventured down this line of code yet; JMP $CF29 SAFETY: LDA #$00 STA $0745 STA $20 INC $0729 JMP $CF29 //Meaningful lock code seems to end here; I'm not sure what the other stuff below this line is for LDA $0711 AND #$04 LSR LSR ORA #$18 STA $16 DEC $0711 RTS These are my observations thus far. It'll be interesting to hear the inputs of others. Solving the locks mystery will be difficult, I think. EDIT: I've done some more experimentation as regards locks in SMB3. Observe the photo:  There is a lock two spaces below where it normally is, while where it normally is is replaced with sand. The first level has been replaced by a fortress.  After completing one fortress, you can see a little green glitch southeast of that fortress. This is the graphic that was supposed to be changed into. I deliberately messed up the position where it was going to be. The lock remains and the sand dune remains.  See? You can pass the lock, because that position was not messed up.  This was after dying once, which unfortunately made the lock unpassable again and got rid of the green glitch. Interestingly, it did not change the sand to a road (or anything else), which confuses me. I would think the sand would be replaced with a road (or the green glitch), because I thought the game does that every time the world map is reloaded. As you know, I thought the issue was that it was simply redrawing the road to where the lock originally was (and redrawing everything to their original spaces), but that does not seem to be the case. Do you guys know what I'm saying? What is going on? (edited by beneficii on 06-07-05 01:32 PM) (edited by beneficii on 06-07-05 01:33 PM) |
|||
Jigglysaint Red Cheep-cheep Level: 24 Posts: 187/215 EXP: 76907 For next: 1218 Since: 03-17-04 Since last post: 7 days Last activity: 3 days |
| ||
| In my experence with these kind of things, I've noticed that graphics are one aspect, but there's usually also a tile type defined elsewhere. For example, in Link's Awakening, you can change the graphics of an appearing chest into somthing else, like stairs, but changing what graphic is loaded doesn't change the tile type. This is loaded seperately. In this case, it's most likely that the road piece is defined seperate to the graphics, plus there might be an extra routine that "saves" the lock into ram so that when you die, it won't go away. | |||
|
beneficii Lakitu Level: 36 Posts: 109/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
Originally posted by Jigglysaint What a pain, LOL. As of late, my leads have been getting worse and worse. I know that World 1 at least in RAM is stored at 6100 (and that its location is stored at 8000, which in the ROM file is 3C010, in two bytes as 6000 and that the location is copied--often with slight alteration--to 63). When I beat the fortress, the corresponding tile there changes, but when I die and come back to the map, the old tile (the one I wanted changed) comes back in the memory. A pain. But I'm trying to figure it out. (edited by beneficii on 06-07-05 05:12 PM) (edited by beneficii on 06-07-05 05:15 PM) |
|||
|
BMF98567 BLACK HAS BUILT A SILLY DICE-MAZE! GO! Current list of BURNING FURY >8( recipients: - Yiffy Kitten (x2) - Xkeeper Level: 53  Posts: 899/1261 EXP: 1094149 For next: 62970 Since: 03-15-04 From: Blobaria Special Move: Rising Meatloaf Backhand Combo Since last post: 21 hours Last activity: 1 hour |
| ||
Oh, God, the locks.  I spent an entire night or two staring at FCEU's debugger, trying to figure out how the locks are handled, to no avail...just like you, I was able to move either the graphic or the attributes, but it would always either change back after the map screen reloaded, or f*ck up in some other aggravating way. Did Nintendo really NEED to make the code that complex? |
| Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| Acmlm's Board - I2 Archive - Rom Hacking - Locks on the World Maps in SMB3 Are Very, Very, Very Complicated |
| | |
