[SkyLizardGirl]

-I keep having this major problem when i try to edit Super Mario Bros 3.

For some reason the First level of my SMB-3 Rom hack always breaks, even though i don't go over the limit of the object placement data, or of enemies, it still kills my first level from working.

I even redid this all carefully.

What is causing my editing the first level to not load in the emulator??

This is really driving me nuts."

Is it some kind of Bug?

Also 'nothing overwrote anything this time around' and the first level still broke.
the Object enemy bars never were saved on Red.

[Cyneprepou4uk]

Sounds like a problem with pointers or control bytes.

[SkyLizardGirl]

Sounds like a problem with pointers or control bytes.

What does that even mean?


https://i.imgur.com/ykIjdCS.png 
^Look at this level,  What pointers?

https://i.imgur.com/31aeQax.png
^Full Level

[Cyneprepou4uk]

Doesn't matter, I thought you were editing bytes manually.

If you are using an editor, this could be anything. Buggy tool, enabled options, incorrect version of the game.

[Jorpho]

For some reason the First level of my SMB-3 Rom hack always breaks, even though i don't go over the limit of the object placement data, or of enemies, it still kills my first level from working.

Most of the time when it comes to troubleshooting, it helps to start by making small changes and keep progressing to making bigger changes until you find what causes the problem.

Can you make any changes at all?

[SkyLizardGirl]

Most of the time when it comes to troubleshooting, it helps to start by making small changes and keep progressing to making bigger changes until you find what causes the problem.

Can you make any changes at all?

I don't understand why the first level in SMB 3 is always buggy like this.

This has happened in countless roms i tried to edit, the first level always stops working.

I am even using the latest SMB3 Editing tool, it even did this with the old editor tools.


December 26, 2020, 10:17:39 pm - (Auto Merged - Double Posts are not allowed before 7 days.)

Doesn't matter, I thought you were editing bytes manually.

If you are using an editor, this could be anything. Buggy tool, enabled options, incorrect version of the game.

I am using the latest Mario 3 editor, but it has also done this with older editors i used, i have tried every single one and it still messes up the very first level.

[Cyneprepou4uk]

By the looks of it, you're using SMB3 Foundry.
https://github.com/mchlnix/SMB3-Foundry

Read the manual, maybe you've doing something wrong.

If not, find out the very minimum actions you need to perform in the tool so the level would break. Open a new issue or contact the author.

[SkyLizardGirl]

Oh ok, .. i will try that.

[Quick Curly]

Hi. This might be a false memory I'm having, since it's been so long since I've bothered with SMB3 related stuff, but I do seem to recall that when dealing with the different coloured block platforms, between the platforms that extend to the ground and the floating platforms, depending on their placements, the hack would sometimes crash/fail/explode when trying to load and test out the level. Have you always tried to use them, regardless of your editor of choice and level design attempts?

Like previously mentioned, try testing out different object combinations and layouts. Try modifying 1-1 in a simple way and see if the level still doesn't fail. For example, try adding a few 4-byte ground objects, and maybe a few 3-byte objects. However, don't try using the different coloured block platforms this time.

Your current design, just like any design, can be salvaged, but you would have to test going from object to object to see which one is, or which multiple objects are, causing the crash in the first place.

In the past, I would do this by navigating to the object/level data in a hex editor, like in FCEUX (refer to the object data offset in the level editor to know where the data you're currently modifying is located in the ROM file), and adding the "FF" byte at the end of each object one by one to effectively terminate the level data at that point, followed by resetting and reentering the level to check if the level successfully loads or not. This is the most thorough approach to testing your current level design without having to completely start over again.

I've never used any of the newer level editors that are possibly still ongoing developments, but with SMB3 Workshop, there's never been a level that couldn't be worked out, one way or another. The problems with them, of course, are my personal design choices that only I actually like!

Best of luck with your SMB3 hacking!

[SkyLizardGirl]

Hi. This might be a false memory I'm having, since it's been so long since I've bothered with SMB3 related stuff, but I do seem to recall that when dealing with the different coloured block platforms, between the platforms that extend to the ground and the floating platforms, depending on their placements, the hack would sometimes crash/fail/explode when trying to load and test out the level. Have you always tried to use them, regardless of your editor of choice and level design attempts?

Like previously mentioned, try testing out different object combinations and layouts. Try modifying 1-1 in a simple way and see if the level still doesn't fail. For example, try adding a few 4-byte ground objects, and maybe a few 3-byte objects. However, don't try using the different coloured block platforms this time.

Your current design, just like any design, can be salvaged, but you would have to test going from object to object to see which one is, or which multiple objects are, causing the crash in the first place.

In the past, I would do this by navigating to the object/level data in a hex editor, like in FCEUX (refer to the object data offset in the level editor to know where the data you're currently modifying is located in the ROM file), and adding the "FF" byte at the end of each object one by one to effectively terminate the level data at that point, followed by resetting and reentering the level to check if the level successfully loads or not. This is the most thorough approach to testing your current level design without having to completely start over again.

I've never used any of the newer level editors that are possibly still ongoing developments, but with SMB3 Workshop, there's never been a level that couldn't be worked out, one way or another. The problems with them, of course, are my personal design choices that only I actually like!

Best of luck with your SMB3 hacking!

So are you saying objects for the underground levels such as Blue blocks might be causing it to crash?
I will look into that.

I never thought about that before, i just assumed the levels can use any such pieces.



December 29, 2020, 02:23:02 pm - (Auto Merged - Double Posts are not allowed before 7 days.)

Also is there a way to extend the timer on the Star Powerup or is there a Mario 3 Power-up editor someplace?
Or what was used in the rom hack - Mario Adventure?

[Jorpho]

Also is there a way to extend the timer on the Star Powerup or is there a Mario 3 Power-up editor someplace?
Or what was used in the rom hack - Mario Adventure?

Most of the time, extensive changes to the powerups require directly editing the assembly language of the program.  There is no quick-and-easy "editor".

There is a disassembly of the SMB3 ROM available that makes things a lot easier than it would be with other games – but it's still not trivial.

[Quick Curly]

So are you saying objects for the underground levels such as Blue blocks might be causing it to crash?

These are the 3-byte objects that I was referring to in this specific case.



I want to emphasize, again, that I might not be remembering correctly. In any case, when things go wrong, the issue(s) could really be anything. You just have to test out any multiple ideas that you or others might come up with until solutions are discovered.

I never thought about that before, i just assumed the levels can use any such pieces.

You *can* use those objects. However, if I'm not just remembering the previous universe I warped in from, I believe that there are limitations to where and how you can place them. If you were to follow the directions from the previous post by hunting down for any troublesome objects in real time within an emulator's hex editor - testing object to object, not saving the "FF" byte change so that you can undo it if the current object passes the test of not crashing the game - once you possibly find which object(s) crash(es) the game, if there are any, you can either delete them, or you can try to move their placements to see if you can find a way to use them that doesn't crash the game.

I've had a couple levels in the past that either crashed the game upon entering, or when Mario/Luigi died, he would fly all the way to the right side of the map, the screen would fade and then reload, Mario/Luigi would land on the Start space from the left side of the map, and then he wouldn't be able to move, as the game sending him back to the Start space wasn't the intended way that it was supposed to happen. Through testing out the objects placed in my level, I was able to track down a specific object that, after it was completely removed, that bug didn't occur anymore. I don't remember any additional specific details other than it was an E - Underground Object Set kind of level.

Anyway, if the objects you cycle through appear correct/valid in the editor while you're placing them, and they aren't just "crash" objects and appear like a yellow/red glitch block, then normally, they should be able to be used for your level without any problems (fingers crossed). Remember that there are different objects available depending on the specific Object Set for the level you're currently creating/modifying, so with each new Object Set, it'll take some getting used to at first.

Also is there a way to extend the timer on the Star Powerup or is there a Mario 3 Power-up editor someplace?
Or what was used in the rom hack - Mario Adventure?

Like Jorpho mentioned, there is a disassembly for SMB3 available that you should be able to find if you look for it. However, understandably, it might seem like a lot of code and nonsense if you're only looking at something like it for the first time. Furthermore, depending on how advanced of a hack you're actually making, it might be a bit overkill dealing with the entire disassembly anyway. If your primary goal is just creating new levels and world maps, you should be able to get by with just the general tools. If you want to create new power-ups, game mechanics, or cinematic enhancements, etc. then you'll need to deal with a lot of the inner workings of the ROM, and therefore, the disassembly being available makes larger visions a whole lot easier.

With all that said, I remember the general area in RAM where invincibility and invisibility variables were stored. So, let's take a look to see if we can find anything.

After some playing around and watching how the memory addresses changed in the FCEUX hex editor, I tracked down the star timer to $0553 in RAM. (I recalled it was in this general range from back in the day, so it was easier to narrow down.) Under the Debug menu, I opened the Debugger, and set a write breakpoint to $0553 in CPU Memory.

There is a star in a note block in 1-2, so I played up to that point to collect it. The debugger froze at $A812, or 0x02822 in the ROM.

Code: [Select]

A810:A9 E0     LDA #$E0
>A812:8D 53 05  STA $0553 = #$00
 A815:4C B0 A8  JMP $A8B0
So, the default value for the star timer is E0, at 0x02821 in the ROM file.
You could max the value out by modifying E0 to FF in a hex editor.

With the write breakpoint still set, after collecting the star, I pressed the Run button to resume game-play. The debugger froze at $CEE7, or 0x3AEF7 in the ROM.

Code: [Select]

CEDC:AD 53 05  LDA $0553 = #$E0
 CEDF:F0 2A     BEQ $CF0B
 CEE1:A5 15     LDA $0015 = #$51
 CEE3:29 01     AND #$01
 CEE5:F0 03     BEQ $CEEA
>CEE7:CE 53 05  DEC $0553 = #$E0
After pressing the Run button a few more times, the "writes" continued to occur at this specific line of code. So, it seems that this is the area where the magic happens of keeping track of how much longer the star power lasts, by first performing the load at $0553 in memory, and if it's not equal to zero, that means that there should still be star power, and the game has to decrement it again.

Now, in theory, if you wanted to extend the amount of time the star power lasts even beyond a value of FF, the maximum possible with only one variable at your disposal, I would like to believe that, if you had an unused memory location to use, you could fit it into the code somewhere in the relevant locations, by writing a specific value to it within the occurrence of first collecting the star, and then to decrement its value around the time of decrementing $0553, if $0553 reaches 00, branch to code that decrements the other relevant location in memory, and then focus on $0553 again, until both are zero, and then the star power would be done. That would be the general idea, anyway. Unfortunately, it might not be that simple, and trying to fit that additional code in would require additional jumps to expanded code elsewhere in free space, or a bunch of frustrating shifts and thrusts.

Something else to consider is when you select a star from your inventory on the world map, and then enter a level.
Mario's 28 items are at $7D80-$7D9B (0x1C in hex) in RAM.
The value for a star is 09. So, give yourself a few "09" values to play with. (Shh... I won't tell anyone.)
Use a star, and then enter a level. When I did this, with the $0553 write breakpoint still active, the debugger froze at $A173, or 0x10183 in the ROM.

Code: [Select]

A171:A9 E0     LDA #$E0
>A173:8D 53 05  STA $0553 = #$00
So, there are two individual values that would need to be modified to be the same, and if you were to try doing ASM magic to squeeze in another new variable in the mix, you would need to fit in the additional write within this area of code for star power when entering a level from the world map as well.

The default value for the star timer from the world map is E0, at 0x10182 in the ROM file.
You could max the value out by modifying E0 to FF in a hex editor, or whatever you modified the value at 0x02821 to be, so that they match.

I recall Mario Adventure did make the star power last longer than what FF alone would seem to allow. So, I checked it out for you. Thankfully, the RAM for Mario's items didn't change, so it was easy to get a star power-up without having to take too much time.
The code for setting the star power appeared familiar, but after pressing the debugger's Run button a few more times, there was some interesting, different code. Relevant addresses: $CEE1 (0x3AEF1 in ROM), $D810 (0x3B820 in ROM), and froze at $D818 (0x3B828 in ROM) for the actual $0553 write breakpoint.

Code: [Select]

CEE1:A5 15     LDA $0015 = #$43
 CEE3:29 01     AND #$01
 CEE5:F0 03     BEQ $CEEA
 CEE7:20 10 D8  JSR $D810

 D810:8D B2 01  STA $01B2 = #$01
 D813:AD B3 01  LDA $01B3 = #$00
 D816:F0 0D     BEQ $D825
>D818:CE 53 05  DEC $0553 = #$DB
 D81B:A9 00     LDA #$00
 D81D:8D B3 01  STA $01B3 = #$00
 D820:AD B2 01  LDA $01B2 = #$01
 D823:60        RTS
 D824:00        BRK
 D825:A9 01     LDA #$01
 D827:8D B3 01  STA $01B3 = #$00
 D82A:AD 00 F0  LDA $F000 = #$95
 D82D:60        RTS
 D82E:A5 15     LDA $0015 = #$79
 D830:4A        LSR
 D831:4A        LSR
 D832:4A        LSR
 D833:4A        LSR
 D834:4A        LSR
 D835:AA        TAX
 D836:BD 41 D8  LDA $D841,X @ $D87F = #$FF
 D839:EA        NOP
 D83A:EA        NOP
 D83B:CE 53 05  DEC $0553 = #$CE
 D83E:A2 0E     LDX #$0E
 D840:60        RTS

 D841-D848:01 02 03 05 06 05 03 02
$0015 appears to be a timer, and there's some additional fancy code to use $01B3 in the stack to effectively double the amount of time that the $0553 star timer can effectively provide the star power. There's also a data table at $D841-$D848 (0x3B851-0x3B858).

Like with anything, this likely isn't the only way you could go about it. Perhaps directly copying isn't necessarily the way to go either, though I do recall an old post through someone else's words claiming that DahrkDaiz once told them that if they could find the code for something that they wanted, they could use it. You could possibly request permission if you want, or you could refer to this code, yes, but instead of just copying it as it is, you could use it as inspiration, study it, and determine a way that you could effectively program your own super advanced, super increased star timer from scratch, and implement it into your hack.

It's very possible that there's more involved than what I discovered from these tests, but I stopped at this point because it's already a lengthy, involved post, and with the basic concepts and processes there, perhaps more experienced users can provide better insight and directions if you have additional questions that I can't answer because... my planet needs me.

*Gets abducted and thrown into Galactic Prison.*

[SkyLizardGirl]

These are the 3-byte objects that I was referring to in this specific case.



I want to emphasize, again, that I might not be remembering correctly. In any case, when things go wrong, the issue(s) could really be anything. You just have to test out any multiple ideas that you or others might come up with until solutions are discovered.

You *can* use those objects. However, if I'm not just remembering the previous universe I warped in from, I believe that there are limitations to where and how you can place them. If you were to follow the directions from the previous post by hunting down for any troublesome objects in real time within an emulator's hex editor - testing object to object, not saving the "FF" byte change so that you can undo it if the current object passes the test of not crashing the game - once you possibly find which object(s) crash(es) the game, if there are any, you can either delete them, or you can try to move their placements to see if you can find a way to use them that doesn't crash the game.

I've had a couple levels in the past that either crashed the game upon entering, or when Mario/Luigi died, he would fly all the way to the right side of the map, the screen would fade and then reload, Mario/Luigi would land on the Start space from the left side of the map, and then he wouldn't be able to move, as the game sending him back to the Start space wasn't the intended way that it was supposed to happen. Through testing out the objects placed in my level, I was able to track down a specific object that, after it was completely removed, that bug didn't occur anymore. I don't remember any additional specific details other than it was an E - Underground Object Set kind of level.

Anyway, if the objects you cycle through appear correct/valid in the editor while you're placing them, and they aren't just "crash" objects and appear like a yellow/red glitch block, then normally, they should be able to be used for your level without any problems (fingers crossed). Remember that there are different objects available depending on the specific Object Set for the level you're currently creating/modifying, so with each new Object Set, it'll take some getting used to at first.

Like Jorpho mentioned, there is a disassembly for SMB3 available that you should be able to find if you look for it. However, understandably, it might seem like a lot of code and nonsense if you're only looking at something like it for the first time. Furthermore, depending on how advanced of a hack you're actually making, it might be a bit overkill dealing with the entire disassembly anyway. If your primary goal is just creating new levels and world maps, you should be able to get by with just the general tools. If you want to create new power-ups, game mechanics, or cinematic enhancements, etc. then you'll need to deal with a lot of the inner workings of the ROM, and therefore, the disassembly being available makes larger visions a whole lot easier.

With all that said, I remember the general area in RAM where invincibility and invisibility variables were stored. So, let's take a look to see if we can find anything.

After some playing around and watching how the memory addresses changed in the FCEUX hex editor, I tracked down the star timer to $0553 in RAM. (I recalled it was in this general range from back in the day, so it was easier to narrow down.) Under the Debug menu, I opened the Debugger, and set a write breakpoint to $0553 in CPU Memory.

There is a star in a note block in 1-2, so I played up to that point to collect it. The debugger froze at $A812, or 0x02822 in the ROM.

Code: [Select]

A810:A9 E0     LDA #$E0
>A812:8D 53 05  STA $0553 = #$00
 A815:4C B0 A8  JMP $A8B0
So, the default value for the star timer is E0, at 0x02821 in the ROM file.
You could max the value out by modifying E0 to FF in a hex editor.

With the write breakpoint still set, after collecting the star, I pressed the Run button to resume game-play. The debugger froze at $CEE7, or 0x3AEF7 in the ROM.

Code: [Select]

CEDC:AD 53 05  LDA $0553 = #$E0
 CEDF:F0 2A     BEQ $CF0B
 CEE1:A5 15     LDA $0015 = #$51
 CEE3:29 01     AND #$01
 CEE5:F0 03     BEQ $CEEA
>CEE7:CE 53 05  DEC $0553 = #$E0
After pressing the Run button a few more times, the "writes" continued to occur at this specific line of code. So, it seems that this is the area where the magic happens of keeping track of how much longer the star power lasts, by first performing the load at $0553 in memory, and if it's not equal to zero, that means that there should still be star power, and the game has to decrement it again.

Now, in theory, if you wanted to extend the amount of time the star power lasts even beyond a value of FF, the maximum possible with only one variable at your disposal, I would like to believe that, if you had an unused memory location to use, you could fit it into the code somewhere in the relevant locations, by writing a specific value to it within the occurrence of first collecting the star, and then to decrement its value around the time of decrementing $0553, if $0553 reaches 00, branch to code that decrements the other relevant location in memory, and then focus on $0553 again, until both are zero, and then the star power would be done. That would be the general idea, anyway. Unfortunately, it might not be that simple, and trying to fit that additional code in would require additional jumps to expanded code elsewhere in free space, or a bunch of frustrating shifts and thrusts.

Something else to consider is when you select a star from your inventory on the world map, and then enter a level.
Mario's 28 items are at $7D80-$7D9B (0x1C in hex) in RAM.
The value for a star is 09. So, give yourself a few "09" values to play with. (Shh... I won't tell anyone.)
Use a star, and then enter a level. When I did this, with the $0553 write breakpoint still active, the debugger froze at $A173, or 0x10183 in the ROM.

Code: [Select]

A171:A9 E0     LDA #$E0
>A173:8D 53 05  STA $0553 = #$00
So, there are two individual values that would need to be modified to be the same, and if you were to try doing ASM magic to squeeze in another new variable in the mix, you would need to fit in the additional write within this area of code for star power when entering a level from the world map as well.

The default value for the star timer from the world map is E0, at 0x10182 in the ROM file.
You could max the value out by modifying E0 to FF in a hex editor, or whatever you modified the value at 0x02821 to be, so that they match.

I recall Mario Adventure did make the star power last longer than what FF alone would seem to allow. So, I checked it out for you. Thankfully, the RAM for Mario's items didn't change, so it was easy to get a star power-up without having to take too much time.
The code for setting the star power appeared familiar, but after pressing the debugger's Run button a few more times, there was some interesting, different code. Relevant addresses: $CEE1 (0x3AEF1 in ROM), $D810 (0x3B820 in ROM), and froze at $D818 (0x3B828 in ROM) for the actual $0553 write breakpoint.

Code: [Select]

CEE1:A5 15     LDA $0015 = #$43
 CEE3:29 01     AND #$01
 CEE5:F0 03     BEQ $CEEA
 CEE7:20 10 D8  JSR $D810

 D810:8D B2 01  STA $01B2 = #$01
 D813:AD B3 01  LDA $01B3 = #$00
 D816:F0 0D     BEQ $D825
>D818:CE 53 05  DEC $0553 = #$DB
 D81B:A9 00     LDA #$00
 D81D:8D B3 01  STA $01B3 = #$00
 D820:AD B2 01  LDA $01B2 = #$01
 D823:60        RTS
 D824:00        BRK
 D825:A9 01     LDA #$01
 D827:8D B3 01  STA $01B3 = #$00
 D82A:AD 00 F0  LDA $F000 = #$95
 D82D:60        RTS
 D82E:A5 15     LDA $0015 = #$79
 D830:4A        LSR
 D831:4A        LSR
 D832:4A        LSR
 D833:4A        LSR
 D834:4A        LSR
 D835:AA        TAX
 D836:BD 41 D8  LDA $D841,X @ $D87F = #$FF
 D839:EA        NOP
 D83A:EA        NOP
 D83B:CE 53 05  DEC $0553 = #$CE
 D83E:A2 0E     LDX #$0E
 D840:60        RTS

 D841-D848:01 02 03 05 06 05 03 02
$0015 appears to be a timer, and there's some additional fancy code to use $01B3 in the stack to effectively double the amount of time that the $0553 star timer can effectively provide the star power. There's also a data table at $D841-$D848 (0x3B851-0x3B858).

Like with anything, this likely isn't the only way you could go about it. Perhaps directly copying isn't necessarily the way to go either, though I do recall an old post through someone else's words claiming that DahrkDaiz once told them that if they could find the code for something that they wanted, they could use it. You could possibly request permission if you want, or you could refer to this code, yes, but instead of just copying it as it is, you could use it as inspiration, study it, and determine a way that you could effectively program your own super advanced, super increased star timer from scratch, and implement it into your hack.

It's very possible that there's more involved than what I discovered from these tests, but I stopped at this point because it's already a lengthy, involved post, and with the basic concepts and processes there, perhaps more experienced users can provide better insight and directions if you have additional questions that I can't answer because... my planet needs me.

*Gets abducted and thrown into Galactic Prison.*

That's extremely interesting.'

Thank you.' I will look into this.

The Mario 3  Star in general is a pathetic power-up for the point that it's timer is way too short.
The Star feels less than 10 seconds when you use it, and then it ends too briefly.

I wanted to extend the power up to 35 seconds at the least, to make it a-lot more worth using as a collectible power up.  Possibly 45 or 55 seconds if it could make for some interesting level passing mechanic but idk.
December 30, 2020, 04:48:25 am - (Auto Merged - Double Posts are not allowed before 7 days.)


Just re-arranged the level again in a fresh mario-3 rom, .. it's still doing the same thing.
 
https://i.imgur.com/webZBJX.png
^There 
So are you saying, if i enter something in the code like FF something in all objects, it will force the game to play the levels it wont play or something?

[Quick Curly]

In your most recent screenshot, you're still using some block platforms. There is even an orange block platform that extends to the ground where there is *no* ground. I suggested making a small test level with *no* 3-byte object block platforms at all to see if your hack would still crash, and if it still did, then there's still at least one other problem with something else.

Regarding the "FF" object check process, I'll try to cover it step by step to hopefully be specific enough.
Consider how your level is made up. You have enemy data and object data. Both are individual data sets. Let's ignore the enemy data for now.
Before the level's object data, there is a 9-byte header for basic settings such as the next area to connect to through pipes, doors, red invisible note blocks, and pointers, etc., scrolling type, the amount of time, the level's music, etc.
Following the header, you have all the 3-byte and 4-byte objects that build your level.
Finally, you have an "FF" byte that basically, to put it simply, tells the game that that's the end of the level.

I'll be using SMB3 Workshop as a reference in this instance. In the editor, when clicking on objects one by one, you can follow the order of them in the bottom-left corner. In the bottom-right corner, you'll see the hexadecimal representation of the data. Without any objects selected, the editor displays the total length of the level in the bottom-right corner. In the case of the original 1-1, there are 263 bytes of object data (or 107 in hex). With all that information covered, let's look at the first few objects in the original 1-1.

000. (X:000, Y:000) 3-byte: White Mushrooms, Flowers and Stars (00 00 03)
001. (X:000, Y:026) 4-byte: Flat Ground (1A 00 C0 26)
002. (X:007, Y:017) 3-byte: Background Clouds (11 07 E3)
003. (X:001, Y:022) 3-byte: Background Hills A (16 01 00)
004. (X:005, Y:023) 3-byte: Background Hills B (17 05 01)

The object data for 1-1 is at 0x1FB92 in the ROM. So, in FCEUX, open the hex editor and navigate to that location in the ROM file.



The layout is as follows:
0x1FB92-0x1FB9A (0x9) - Level header
0x1FB9B-0x1FCA1 (0x107) - Object data
0x1FCA2 (0x1) - FF byte/the end of the data for 1-1

As you can see in the image, the level header is highlighted in red, and the first few objects that we looked at in order in the editor are highlighted in orange and yellow.

0x1FB9B-0x1FB9D (0x3) 3-byte: White Mushrooms, Flowers and Stars (00 00 03)
0x1FB9E-0x1FBA1 (0x4) 4-byte: Flat Ground (1A 00 C0 26)
0x1FBA2-0x1FBA4 (0x3) 3-byte: Background Clouds (11 07 E3)
0x1FBA5-0x1FBA7 (0x3) 3-byte: Background Hills A (16 01 00)
0x1FBA8-0x1FBAA (0x3) 3-byte: Background Hills B (17 05 01)

To look for a troublesome object, you have to effectively *end* the level earlier than where it currently ends, because the only objects that will be used are the ones that come before the FF terminator byte. You don't want to place the FF byte in the middle of a single object's data, either.

So, between the emulator and its hex editor, you'll test out each individual object, one by one, to see if you can find one that causes the crash. You might want to set a save-state on the world map in front of the level that you're testing, or you'll have to reset after each test.

The first object to test is the White Mushrooms, Flowers and Stars (00 00 03). Do this by replacing the first byte of the next object with an FF byte. Specifically, at 0x1FB9E, replace 1A with FF. Do not save this change. The byte will be highlighted in red, but you can undo the change at any time so the original data isn't lost. Now, in the emulator window, enter the level and see if it loads normally. Of course, without any ground objects, Mario will hopelessly fall into nothingness, but if he does, well, congratulations! Mario won't appreciate it, but the level loaded, and that's all that matters!

First object passed. So... now, the next one. Undo the previous change, and at 0x1FBA2, replace 11 with FF. In the emulator window, enter the level and see if it loads normally. If it does, at least Mario won't be falling this time, since you just tested the flat ground 4-byte object to see if it was causing a problem or not.

You would continue following this process to test out all of the objects in your level. As soon as you experience a crash, you know that the most recent object that you were testing is causing a problem, because if the previous tests passed, up to that point in the object data, all of the other objects were valid and weren't causing any problems (that you know of).

In the case of your modified 1-1 attempts, if you don't have the patience to test every single object from the beginning to the end, if I were you, I would initially focus primarily on the block platforms that I referred to previously.

If nothing pans out yet again from these sessions, I would scan the checksums of your ROM to see if you even have a valid dump in the first place. I would assume yes, but we can't really rule anything out with only hope. With that said, here's *hoping* that the problem(s) can eventually be resolved!

[ThroughT1m3]

 I am not sure about SMB3 but in SMB 1 the disassembly has it called StarInvincibiltyTimer and a value of #$23 is loaded into it for the star duration. By simply changing the value to a larger value makes the star last longer. I figure it would be just as simple for SMB3. Maybe download the disassembly by Captain Southbird and finding that value and changing it. Even if you don't plan to work off of the disassembly you could just change the star duration value, build the game and go from there. After  looking at the smb3 disassembly it seems the value #$e0 is loaded into Player_StarInv. Manipulating that value is where i would start. Just a suggestion.

[SkyLizardGirl]

In your most recent screenshot, you're still using some block platforms. There is even an orange block platform that extends to the ground where there is *no* ground. I suggested making a small test level with *no* 3-byte object block platforms at all to see if your hack would still crash, and if it still did, then there's still at least one other problem with something else.

Regarding the "FF" object check process, I'll try to cover it step by step to hopefully be specific enough.
Consider how your level is made up. You have enemy data and object data. Both are individual data sets. Let's ignore the enemy data for now.
Before the level's object data, there is a 9-byte header for basic settings such as the next area to connect to through pipes, doors, red invisible note blocks, and pointers, etc., scrolling type, the amount of time, the level's music, etc.
Following the header, you have all the 3-byte and 4-byte objects that build your level.
Finally, you have an "FF" byte that basically, to put it simply, tells the game that that's the end of the level.

I'll be using SMB3 Workshop as a reference in this instance. In the editor, when clicking on objects one by one, you can follow the order of them in the bottom-left corner. In the bottom-right corner, you'll see the hexadecimal representation of the data. Without any objects selected, the editor displays the total length of the level in the bottom-right corner. In the case of the original 1-1, there are 263 bytes of object data (or 107 in hex). With all that information covered, let's look at the first few objects in the original 1-1.

000. (X:000, Y:000) 3-byte: White Mushrooms, Flowers and Stars (00 00 03)
001. (X:000, Y:026) 4-byte: Flat Ground (1A 00 C0 26)
002. (X:007, Y:017) 3-byte: Background Clouds (11 07 E3)
003. (X:001, Y:022) 3-byte: Background Hills A (16 01 00)
004. (X:005, Y:023) 3-byte: Background Hills B (17 05 01)

The object data for 1-1 is at 0x1FB92 in the ROM. So, in FCEUX, open the hex editor and navigate to that location in the ROM file.



The layout is as follows:
0x1FB92-0x1FB9A (0x9) - Level header
0x1FB9B-0x1FCA1 (0x107) - Object data
0x1FCA2 (0x1) - FF byte/the end of the data for 1-1

As you can see in the image, the level header is highlighted in red, and the first few objects that we looked at in order in the editor are highlighted in orange and yellow.

0x1FB9B-0x1FB9D (0x3) 3-byte: White Mushrooms, Flowers and Stars (00 00 03)
0x1FB9E-0x1FBA1 (0x4) 4-byte: Flat Ground (1A 00 C0 26)
0x1FBA2-0x1FBA4 (0x3) 3-byte: Background Clouds (11 07 E3)
0x1FBA5-0x1FBA7 (0x3) 3-byte: Background Hills A (16 01 00)
0x1FBA8-0x1FBAA (0x3) 3-byte: Background Hills B (17 05 01)

To look for a troublesome object, you have to effectively *end* the level earlier than where it currently ends, because the only objects that will be used are the ones that come before the FF terminator byte. You don't want to place the FF byte in the middle of a single object's data, either.

So, between the emulator and its hex editor, you'll test out each individual object, one by one, to see if you can find one that causes the crash. You might want to set a save-state on the world map in front of the level that you're testing, or you'll have to reset after each test.

The first object to test is the White Mushrooms, Flowers and Stars (00 00 03). Do this by replacing the first byte of the next object with an FF byte. Specifically, at 0x1FB9E, replace 1A with FF. Do not save this change. The byte will be highlighted in red, but you can undo the change at any time so the original data isn't lost. Now, in the emulator window, enter the level and see if it loads normally. Of course, without any ground objects, Mario will hopelessly fall into nothingness, but if he does, well, congratulations! Mario won't appreciate it, but the level loaded, and that's all that matters!

First object passed. So... now, the next one. Undo the previous change, and at 0x1FBA2, replace 11 with FF. In the emulator window, enter the level and see if it loads normally. If it does, at least Mario won't be falling this time, since you just tested the flat ground 4-byte object to see if it was causing a problem or not.

You would continue following this process to test out all of the objects in your level. As soon as you experience a crash, you know that the most recent object that you were testing is causing a problem, because if the previous tests passed, up to that point in the object data, all of the other objects were valid and weren't causing any problems (that you know of).

In the case of your modified 1-1 attempts, if you don't have the patience to test every single object from the beginning to the end, if I were you, I would initially focus primarily on the block platforms that I referred to previously.

If nothing pans out yet again from these sessions, I would scan the checksums of your ROM to see if you even have a valid dump in the first place. I would assume yes, but we can't really rule anything out with only hope. With that said, here's *hoping* that the problem(s) can eventually be resolved!

Thank you, i will look into all this.  This actually helps alot more, because i did not understand what numbers and stuff in the hex editor did at first.'  This really helps alot thanks.*//



December 30, 2020, 07:46:00 pm - (Auto Merged - Double Posts are not allowed before 7 days.)

I am not sure about SMB3 but in SMB 1 the disassembly has it called StarInvincibiltyTimer and a value of #$23 is loaded into it for the star duration. By simply changing the value to a larger value makes the star last longer. I figure it would be just as simple for SMB3. Maybe download the disassembly by Captain Southbird and finding that value and changing it. Even if you don't plan to work off of the disassembly you could just change the star duration value, build the game and go from there. After  looking at the smb3 disassembly it seems the value #$e0 is loaded into Player_StarInv. Manipulating that value is where i would start. Just a suggestion.

Oh ok, i will try to figure out where the star power-up numbers are hiding at.

All i want to do is change the Star to 35 seconds at least.  I am also quite interested in what activates the 'Star Spinning' Mario performs as i had an idea for a new power-up where he normally jumps like that.
It would work similar to a flower or leaf, but mainly like the Hammer Brother suit, but he gets a news paper folded hat with a black spade on it and a large paper-like sword.

But if somebody could program it, where it only spins if you press 'the up arrow as you jump' or something that would be insane.

Also Mario when he jumps he holds the Wand when he retrieves it from Koopa'lings.
- So I am wondering if he could hold something like a Sword, just in theory, as he holds the wand and also jumps and Spins like the star.

But that may be deeper programming i think.

[ThroughT1m3]

 I looked into it a bit and it seems that it doesn't count the same way it does in SMB 1. in SMB3 it seems to count each flash mario makes when the star is active. no matter what I did the star seemed to not last very long. could be due to how they chain stars in SMB3. when you get a star and get another out of a box. not sure. I wish I had more time to help you. I even looked for game genie codes to make it last longer. no go. sorry. 

[SkyLizardGirl]

I looked into it a bit and it seems that it doesn't count the same way it does in SMB 1. in SMB3 it seems to count each flash mario makes when the star is active. no matter what I did the star seemed to not last very long. could be due to how they chain stars in SMB3. when you get a star and get another out of a box. not sure. I wish I had more time to help you. I even looked for game genie codes to make it last longer. no go. sorry. 

It's ok, thank you.*