News: 11 March 2016 - Forum Rules

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Quick Curly

Pages: [1] 2 3 4 5 6
Hello, Ridley X. I tried to take a look. Hopefully these findings are relevant.
There is code that overwrites the palette attributes for the heads and feet of the Koopas.
Assuming that you are modifying the "(U) (PRG1) [!]" version of the game, 0x09529 and 0x0959C in the ROM file are these values. The original values for both are 03. You can modify these accordingly to the values you wish (with the options being 00, 01, 02, or 03). The following image provides a visual of these values in the hex editor, the PPU Viewer to provide the palette options, and how the different Koopas are affected.

These values affect the Green and Red Koopas, and not the Giant Koopas. However, they are shared between the Green and Red Koopas.
Since, by the sounds of it, you want the unique colours to match respectively for both the Green and Red Koopas, instead of modifying the values directly, you might have to disable these lines of instructions within the code. As a result, the Green Koopa will use the third quarter of the sprite palette ("02", as seen in the image) for all of its body parts, and the Red Koopa will use the second quarter of the sprite palette ("01", as seen in the image) for all of its body parts.

If this would be the specific change that you need, then perform these modifications in the ROM file.
Change "29 FC 09 03" to "EA EA EA EA" at 0x09526-0x09529 (0x4) in the ROM file.
Change "29 FC 09 03" to "EA EA EA EA" at 0x09599-0x0959C (0x4) in the ROM file.

Please confirm if this does what you need it to do, or otherwise, you might have to play around with this code accordingly (if you need only one of those two strings disabled, and/or a combination of direct modifications and overwritten code, etc.) and/or hopefully I or someone else can try to take another look at things with you to try to better figure out what else might need to be done to get it working.

Best of luck.

Personal Projects / Re: Balloon Fight (VS System Port)
« on: April 09, 2021, 08:00:02 pm »
This is amazing! I've had the desire to try to modify the VS port for a while, but unfortunately, I haven't had the free time to commit to anything. Thank you very much for your efforts with this project! :beer: :cookie:

There is another game that could also be ported for the NES: Wrecking Crew. But strangely enough, the console version is much better, and this is the reason to not make such a port.
The arcade version is single-screen, unlike the console version - two game's screens plus a camera.

There is this hack on the site:

"VS Wrecking Crew" by Morgan Johansson, released March 17, 2021

Code: [Select]
This ROM-hack makes “VS Wrecking Crew” playable in one-player mode on your NES.
Mapper is converted to MMC1, palette is patched and coinslot-emulation is included.

Not sure if the changes in this hack are exactly what you would have had in mind and account for everything that you would have wanted to change, that is, if you did ever decide that a port would have been worth making, but I've always felt the VS versions certainly deserve more attention than they seem to receive, though that's not to say that they haven't received any entirely, and I'm probably thinking back to more than a decade ago when I was initially interested in them.

But remembering Climber, I thought it would be nice to enable two-player mode for Balloon fighters. The first player controls the camera, and the second one helps to defeat enemies.
Playing together, the players themselves took care not to be off the edges of the screen.
We know this style thanks to games like Contra.  Easy mode can allow players not to burst each other's balloons.

It would be amazing if a 2-player mode could be implemented, but it's understandable that a simple application may not be entirely practical or straightforward given the technical limitations and whatnot, and/or not come without any drawbacks and shortcomings.

I'm not sure how it could work out due to the available space on the screen, but if you've ever heard of and/or played the NES version of Nintendo World Cup, playable with up to 4 players, there is a section of the screen dedicated to a mini-map display, and if players are off-screen, they can still tell where they are. Understandable as well, it might still not be such a practical or straightforward solution, as there are enemies that would be off-screen, any interactions with ground, objects, enemies, and other players might not be so easily handled and accounted for, and there really just doesn't seem to be any good part of the screen to commit a miniature map for location tracking.

In theory, with some crazy, super technical status bar IRQ implementation (mapper dependent for compatibility), a map could maybe be added, but it probably still wouldn't be practical or pretty, as everything would probably be squished together and unsightly. I don't know. Just typing on autopilot, I guess. My apologies.

I look forward to any additional ideas and potential future updates you come up with for this hack, as well as any other projects you create that we have the honour of receiving and being able to enjoy.

I wish that there was some way that I could contribute something given that I was intending to try to look at this port, and how much I enjoy Balloon Fight overall, but again, I'm afraid that I just wouldn't be able to promise anything, unfortunately.

However, for what it's worth, if anything, I was really, really excited about this when it was first posted. I was following the original progress for the early attempts for the VS-to-NES conversion that started years ago over at NesDev, and to see the progress now, it is truly a blessing. So, again, thank you very much. :angel:

Personal Projects / Re: NES RoboCop with Arcade sprites
« on: February 08, 2021, 10:13:50 pm »
Hi. Not sure how useful this post will be. Unfortunately, I'm not too familiar with the RoboCop game. However, it looks like a pretty neat project you have going on here, and I was interested in checking it out.

0x199F4-0x19A13 (0x20) - Palette for scene.


Code: [Select]
0F 32 26 16 0F 22 12 02 0F 0F 0F 0F 0F 0F 0F 0F
0F 22 12 02 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F

Test (to see how things are affected when attribute byte tests are also performed later):

Code: [Select]
0F 32 26 16 0F 22 12 02 0F 3A 2A 1A 0F 3B 2B 1B
0F 22 12 02 0F 27 17 07 0F 23 16 04 0F 37 2A 05

0x19E16-0x19F0F (0xFA) - Free space(?): "FF" bytes
0x19F10-0x1A00F (0x100) - Free space(?): "00" bytes

$B64D-$B66D = 0x1965D-0x1967D (0x21)

Code: [Select]
B64D:A2 00     LDX #$00      ; Beginning of sprites.
B64F:BD 54 BC  LDA $BC54,X   ; $BC54 = 0x19C64.
B652:9D 00 02  STA $0200,X   ; Byte 0 = Y position.
B655:BD 55 BC  LDA $BC55,X   ; $BC55 = 0x19C65.
B658:9D 01 02  STA $0201,X   ; Byte 1 = Tile ID.
B65B:A9 00     LDA #$00      ; Same attribute for all.
B65D:9D 02 02  STA $0202,X   ; Byte 2 = Attribute.
B660:BD 57 BC  LDA $BC57,X   ; $BC57 = 0x19C67.
B663:9D 03 02  STA $0203,X   ; Byte 3 = X position.

Code: [Select]
B666:E8        INX           ; Increment X 4
B667:E8        INX           ; times to account
B668:E8        INX           ; for next sprite.
B669:E8        INX           ; Check if 15 sprites/
B66A:E0 3C     CPX #$3C      ; 60 bytes reached.
B66C:90 E1     BCC $B64F     ; If not yet, go back.

Disclaimer: Text dump is likely not 100% accurate nor included as part of a balanced breakfast.

Disregarding all of the above nonsense, to answer your question of why they made the code the way they did by using the same attribute byte for those animations of RoboCop... who knows? On one hand, you could argue that they were doing it to save space somehow, but really, what space did they save? By logging the data and code used, you can see that they had groups of 4 bytes for that sprite data starting at 0x19C64, but they weren't logged because the code doesn't load those data bytes. So, the bytes still exist and occupy space, but are essentially wasted instead, and they only saved one byte by not using a "BD" LDA instruction/opcode there. Plus, it appears as though there is still free space at the end of that specific ROM bank that they could have used if they needed to. So, what was the point? There was no point! There's no point to anything in life!

Was it to reduce/save time for the game to perform the code? How much time would it really save overall?

Nonetheless, assuming that the free space at the end of the bank is indeed unused (it wasn't logged by the Code/Data Logger), then you could potentially just insert a jump at the appropriate point in the code, and then jump back after your custom code of how it should have been all along!

As a test, I replaced "A9 00 9D 02 02" with "20 C0 BF EA EA" at 0x1966B-0x1966F (0x5), and "00 00 00 00 00 00 00" with "BD 56 BC 9D 02 02 60" at 0x19FD0-0x19FD6 (0x7).

Code: [Select]
B65B:20 C0 BF  JSR $BFC0
B65E:EA        NOP
B65F:EA        NOP

Code: [Select]
BFC0:BD 56 BC  LDA $BC56,X
BFC3:9D 02 02  STA $0202,X
BFC6:60        RTS

The result was the following:

Since it appears that you're creating a custom scene, you would need to play around with the data bytes to fit your specific needs. In addition, it appears that there's additional code to load additional data for other parts of the scene - maybe? So, there might possibly be additional code that you'll also need to manipulate. However, again, there seems to be free space for you to work with, so hopefully, you'll be able to work it out.

With the above code to load individual attribute bytes, you'll have to modify the "00" of each sprite on your own to what you want/need it to be.

As for the additional time for the code to perform the jump and the return back, not only once but multiple times for all of RoboCop's sprites in that part of the scene, efficiency could be improved if you were able to shift everything forward at that point by one byte so that you could just fit in the "LDA $BC56,X" line where the original code already is; however, unless you have a disassembly to work with to make this a much easier and quicker process, it might not be worth your time and effort to manually shift everything through the hex editor, and have to account for manually adjusting branch lengths like the one at $B66C, as well as any JSR and JMP jump sources and destinations. Unless inefficient code causes you a headache, I would avoid the headache caused by all of the extra work for what really amounts to little reward or appreciation.

Sorry again if this post is inaccurate or incomplete (and as a result, unhelpful), and/or difficult to read through because it was verbose, like my code: "consuming much time".
Perhaps it can still be some sort of starting point towards a solution. We can only hope so, anyway.
In any case, I believe that, ultimately, you can do it in the end! Do it for RoboCop!
Best of luck with your project! :beer: :cookie:

Personal Projects / Re: NES Games Disassembly (possible requests)
« on: January 31, 2021, 05:11:21 pm »
Awesome stuff, as always! I've been checking out your stuff lately and it's great that you're providing resources for others to expand their horizons! :)

I debated posting this because I don't want to derail your thread, and it's possible that you already know about this other information out there anyways; however, just in case you or even someone else might be interested, I guess I'll risk taking the bullet as a result of stepping out of my dark corner.

Since you mentioned that you're currently working on The Legend of Zelda, I thought I would point out this link that I remember finding way back in 2009:

However, I'm not really sure how complete it might be. I just remember back when I first found it, I thought that it was pretty cool that it existed.

Trax also has some documentation for the game's ROM banks and RAM. Not sure how complete it is either, but again, it's pretty cool that it exists.

To come full circle, your recent disassembly projects are pretty cool and interesting to me, and hopefully will be useful to many others. As sebastianangel put it, contributions like your disassembly projects and helpful posts in general are what continue to make this hobby enjoyable and bring the community to new heights! I will look forward to what you come out with next.

Those graphics and colours look amazing! Keep it up! You can do it! :thumbsup: :beer: :cookie:

ROM Hacking Discussion / Re: SMB1 Title Screen help
« on: January 13, 2021, 01:02:03 pm »
Just as a heads up, if you have anymore Super Mario Bros. related questions, it's probably best to keep them all in one thread. Keeps things more organized for everyone (including people who are willing to try to help and would like to know what information has already been covered) and doesn't take over the whole board with multiple threads for a single project.

Assuming that you are familiar with using emulators with special tools and features like FCEUX and Mesen, using the Name Table Viewer, you can hover over locations on the screen to find out the PPU addresses for specific tiles. With that information, you can set write breakpoints in the Debugger to find when the tile values are drawn, so that hopefully you can track down where they're coming from.

The pointer is a background tile instead of a sprite, at PPU address $2249, with a tile ID of CE. I set a write breakpoint for PPU address $2249, reset, and followed the writes until I found the one that we're looking for. The data was coming from the beginning of the $0300 page in RAM. So, I set write breakpoints for this range, and kept searching. Turned out that the relevant code was at $8325, or 0x00335 in the ROM file.

The string "07 22 49 83 CE 24 24 00" is what gets stored at $0300-$0307. By looking over the code, if a 2 player game is selected, $0304 and $0306 will get overwritten with a blank tile and the pointer to display the pointer at the bottom spot.

Depending on the tile IDs of your ground graphics, replace CE 24 24 at 0x00331-0x00333 in the ROM file with the appropriate values so that the ground is displayed there for you instead. In addition, replace 24 at 0x00346 and CE at 0x0034B with appropriate matching values as well. Really, you shouldn't have to worry about those values, since the previous modification in your other thread to prevent a 2 player game from being selected should also prevent those values from ever replacing the values displayed for a 1 player game, but this would just be to try to account for all relevant data and code for the original game as it applies to your modified title screen.

It seems that the "TOP-" part of the high score display near the bottom of the title screen, starting at PPU address $22EC, is part of the actual title screen data, so it's already taken care of on your modified title screen. However, for the numerical score display itself, it seems that there is a bit of code involved with it. The blank tile between the location "TOP-" was originally displayed and the score tiles is at PPU address $22F0. The 6-digit score is the range of PPU address $22F1-$22F6. Once again, it seems that the data comes from the $0300 page in CPU memory.

The code starting at $8F28 appears to be reused multiple times for title screen related displays, so we can't really try to overwrite or erase it to be done with it and move on. However, after setting an execute breakpoint for $8F26, I found that the "LDA #$22" line only gets used once when preparing the PPU address $22F0 for the high score display.

So, I made the following modifications:

0x00F04: Change F0 to 62.
0x00F37: Change 22 to 20.

This is a cheap workaround I decided to make since there is also a score displayed under the "MARIO" tiles at the top of the screen, at PPU address $2063. I changed 0x00F04 to 62 rather than 63 to account for the blank tile that is added to the score. Otherwise, the "0" tile at PPU address $2063 would be overwritten with a blank tile, resulting in a 5-digit score under the "MARIO" tiles, but after the demo played and the score was affected, the original 6 digits would be restored. As usual, this isn't the only way you could probably go about this. This approach doesn't seem to break anything through the quick testing I performed, though it doesn't account for any additional changes you've made or will make, or a high score following a game over, so keep that in mind.

For the original game, PPU address $22F6 was still displaying a fixed "0" tile for the score, so I also had to change 00 to 24 at 0x09FED in the ROM file. Tile ID 00 was the fixed 0 tile, and 24 is a blank tile.

As already covered, your title screen is no longer displaying "TOP-". However, for anyone in the future who hasn't modified their title screen yet, the relevant data for the "TOP-" display is at 0x9FE3-0x9FE9 (0x7 bytes) in the ROM file. "22 EC 04 1D 18 19 28" represents PPU address $22EC, and 4 tile values, "1D 18 19 28", are used to display "TOP-".

Now, in addition for your title screen, I would like to point out a couple more things.

It's your choice, but there might be some people out there who feel like the one cloud to the left of "MARIO" that is cut off maybe takes away from the overall appearance. However, I know nothing about what it takes to make anything appealing, so perhaps I'm wrong to try to assume other people's opinions without asking for them. Either way, just thought that I would bring it up.

The palette attribute data is at 0x9FEE-0xA000 (0x13 bytes in hex with 0xA000 as the 00 terminator byte). One of your trees and the ground are displayed with a part of the palette that I don't believe you intended for it to be. You would have to modify the attribute byte(s) accordingly. If you need help with this, please provide the PPU addresses for the tiles that are affected, so that the correct attribute byte(s) that need(s) to be modified can be identified. There is documentation on attributes if you feel that you can figure this out on your own.

As always, best of luck.

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!

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.*

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! :cookie:

ROM Hacking Discussion / Re: Help removing 2 player from Super Mario Bros
« on: December 24, 2020, 02:18:20 pm »
There's a disassembly for the game that should help, but I went searching in FCEUX on my own to see what I could hopefully find.

Switching between 1 and 2 players on the title screen/menu affected $077A in memory, so I set read and write breakpoints for that address in CPU memory in the FCEUX debugger. After pressing the Select button on the title screen again, the debugger came up at the line of code at $828E, or 0x0029E in the ROM file.

Depending on who you ask, there are really countless ways you could go about this, some more efficient than others. For instance, when you account for CPU cycles, instructions, free space in the ROM, etc.

The code that switches between 1 and 2 players are those 3 lines of code, 8 bytes in length. Simply using the "EA" opcode, No Operation, will overwrite it so that it never does what it currently does again.

Testing it out, pressing the Select button doesn't affect $077A any longer, and a 2 player game couldn't be selected. However, it still resets the counter used for the game to begin the demo (at $07A2). So, again, depending on the depths of your intended changes, you may need to look at other lines of code as well.

In addition, how *deep* do you mean to "remove 2 player mode"? Depending on that, any RAM addresses originally used as variables for Luigi, i.e. the second player, if you want to free those up for an advanced 1 player only game, again, you would have a lot more of the original game to look through and possibly reorganize so that you could effectively make use of all the space that you have to work with, without potentially changing the mapper and expanding the ROM through more advanced means.

I've never made a hack of this game, but considering that there is a disassembly for it, and many SMB hackers who are still around, hopefully if you're planning to make a hack of this game, you should be able to find the guidance and resources that you need.

Best of luck! You can do it!

ROM Hacking Discussion / Re: Kickle Cubicle Level Editing
« on: June 25, 2020, 09:08:10 am »
It took some time to extract (90% correct) the level data and enemy data from the documents.

Editor Questions
Why does the enemy data look awful?
I have the wrong enemy data input! I pulled the enemy data via powershell scripts from parsing the CurlyNotes_AKA_almostEverything.txt file. This knowing led to a few levels with wierd (or in some cases NO) data.

I did mention that the information was likely not all correct, but what exactly was incorrect? Can you be more specific? I pulled all the data bytes directly from the ROM back when I was still working on a hack that I haven't touched for over 4 years now, so I can't guarantee you (nor did I try to) that I didn't somehow miss something.

Also, if the document had incorrect information in it, then why would you submit it to I never did because I wasn't trying to rush to release an unrefined document. I only roughly put it together from all my collective mini-notes so that I could provide it to you.

I don't mean for any of that to sound aggressive or harsh, but I can't help but feel a little confused since you used the document as a reference, claimed that some of it is incorrect, and unless I'm missing something, never tried to bring it to my attention before uploading it to this site and your GitHub. To be clear, I don't mind you using it. I guess I just wish that it and/or I wasn't an excuse something didn't work out. It's not like I wanted to provide the wrong information to you, or anyone else who might have tried to use it.

From you saying the "enemy data" specifically is wrong without additional details yet, my first thought is that it's possibly due to offsets that the original game had in those spots like for levels 7D-7F. While the pointers for the level layout data are the same for all of them (just more level 01 repeats), the enemy data is different for each (and I can only assume that they are just garbage pointers for non-existing, not actual "levels" to begin with, and who knows if those bytes have another purpose or none at all).

That, and/or maybe it has something to do with the enemy identifiers. I never did get around to the specific purpose of each byte and how it all works, so it would probably take some time if there was an issue to work out there.

In any case, if there's something wrong, I don't want to provide misinformation if I can help it. I can't always figure everything out, but I'm more than willing to try... to try. So, we can look at the data again in the ROM if you want, if you provide me with some more details.

As for the level editor itself, congratulations on what you've put together so far.

EDIT: I misunderstood the situation and it's my fault. Sorry.

ROM Hacking Discussion / Re: Kickle Cubicle Level Editing
« on: May 22, 2020, 03:00:31 pm »
Hey there! How's it going? It's awesome to meet another Kickle Cubicle fan!
I assume that you already have the two documents for the level data, as seen on the Kickle Cubicle Data Crystal page.

Kickle Cubicle level data in data order
Kickle Cubicle level data in game order

I'm not sure if they will be useful at all, but here are my old notes going back as far as 2009. They're not complete (or necessarily accurate) by any means, which is why I never released them, but hopefully they are a decent beginning ground towards general documentation, and maybe can save a little bit of time with your documenting process. :)

Kickle Notes 5/22/2020 (200.7 KB)

Do you have specific goals in mind for a potential project? Are you planning to create a utility for the game, and/or are you simply planning to create a straight level hack to provide a new Kickle experience?
In any case, I'm interested and I hope that you'll keep us updated! Best of luck!

ROM Hacking Discussion / Re: SMB3 Workshop Help
« on: December 23, 2018, 08:48:13 am »
Sorry for the late reply. Not sure if you'll see this, or if you've already figured out what you've needed to by now.

This question comes up now and again, and I elaborated on different things in this 2015 RHDN post.

Basically, Object Sets are in specific ROM banks. Some Object Sets are in the same bank as others, and they can be changed. However, not the others. For example, you can't change a Plains level into a Sky level, or vice versa. However, you can change a Sky level into an Ice level, or an Ice level into a Sky level. That's because they're in the same ROM bank, and they share the same object definitions.

Here's a diagram to better illustrate this:

Code: [Select]
 - Sky & Ice
 - Piranha Plant, Giant & Cloudy
 - Water & Pipe

       1 - Plains: 0x1E509 - 0x2000F
     2 - Fortress: 0x2A7F7 - 0x2C00F
            *NOTE: 0x2A7F7 - 0x2A866 = 7 End Castles
        3 - Hilly: 0x20587 - 0x2200F
          4 - Sky: 0x227E0 - 0x2400F -----------------+
5 - Piranha Plant: 0x26A6F - 0x2800F -----+           |
        6 - Water: 0x24BA7 - 0x2600F -----+-----+     |
         8 - Pipe: 0x24BA7 - 0x2600F -----+-----+     |
       9 - Desert: 0x28F3F - 0x2A00F      |           |
         A - Ship: 0x2EC07 - 0x3000F      |           |
        B - Giant: 0x26A6F - 0x2800F -----+           |
          C - Ice: 0x227E0 - 0x2400F -----+-----------+
       D - Cloudy: 0x26A6F - 0x2800F -----+
  E - Underground: 0x1A587 - 0x1C00F

As for changing an Object Set of an original SMB3 level that allows you to, you need to remember to change the pointer on the world map accordingly with the SMB3 Map Editor utility.

If you want a specific Object Set for your custom level, just find a level made with the Object Set to edit in SMB3 Workshop, and then set the level to the desired pointer in the SMB3 Map Editor.

If you need any clarification, please feel free to ask.

Best of luck. Hopefully we'll hear from you again, and that you'll have some hack progress to share with us.

ROM Hacking Discussion / Re: SMB3 General Changes (Fireworks)
« on: December 23, 2018, 08:15:12 am »
This might be a bit of a chaotic post that's all over the place. Sorry about that.
If more clarification is needed, hopefully I or even someone else can attempt to provide that in a following post.

Each formation is made up of a large block of data, broken up by groups. For each formation, there are pointers leading to each group of data.

First off, let's just establish the ROM offsets that we're looking for.
The following large blocks of data don't account for the palette, definitions, "YOU GOT A CARD" text string, and/or the card image of the Mushroom, Fire Flower, or Star.

0x01EE2-0x01F60 (0x7F) - Mushroom formation.

Code: [Select]
      20 8D 46 A9 20 AB 44 A9 20 B1 44 A9 20 CA
45 A9 20 D1 45 A9 21 4A C3 A9 00 20 E9 05 A9 A9
FC A9 A9 20 F2 05 A9 A9 FC A9 A9 21 28 C7 A9 21
09 C6 A9 21 4D C3 A9 00 21 2E C8 A9 21 2F C5 A9
21 30 C5 A9 21 31 C8 A9 21 52 C3 A9 00 21 55 C3
A9 21 16 C6 A9 21 37 C7 A9 21 CB 4A A9 21 E9 C2
A9 00 21 EA C4 A9 21 EB 84 A9 FC FC A9 21 F4 84
A9 FC FC A9 21 F5 C4 A9 21 F6 C2 A9 22 6B 4A A9

0x01F61-0x0200F (0xAF) - Fire Flower formation.

Code: [Select]
   20 8B 4A A9 20 A9 43 A9 20 B4 43 A9 20 C8 42
A9 20 D6 42 A9 20 E8 C3 A9 20 EB 43 A9 21 0B 01
A9 00 21 48 42 A9 20 CD 46 A9 20 F2 43 A9 20 F7
C3 A9 21 4D 46 A9 21 2B 43 A9 21 56 42 A9 21 A9
42 A9 00 21 14 01 A9 21 0E 44 A9 21 32 43 A9 21
69 43 A9 21 74 43 A9 21 8B 4A A9 21 B5 42 A9 21
D7 C3 A9 00 21 AE C6 A9 21 B1 C6 A9 21 C8 C3 A9
21 CB 42 A9 21 D3 42 A9 21 EA 04 A9 FC FC A9 21
F2 04 A9 FC FC A9 00 22 0B 01 A9 22 14 01 A9 22
29 04 A9 FC FC A9 22 33 04 A9 FC FC A9 22 4A 04
A9 A9 FC A9 22 52 04 A9 FC A9 A9 22 6C 48 A9 00

0x3C229-0x3C2A5 (0x7D) - Star formation.

Code: [Select]
                           20 8F 42 A9 20 AE C2
A9 20 B1 C2 A9 20 ED 01 A9 20 F2 01 A9 21 08 46
A9 21 12 46 A9 00 21 28 01 A9 21 37 01 A9 21 49
01 A9 21 4E C3 A9 21 51 C3 A9 21 56 01 A9 00 21
6A 01 A9 21 75 01 A9 21 8B C2 A9 21 94 C2 A9 21
CA C2 A9 21 D5 C2 A9 00 22 09 C2 A9 22 0F 42 A9
22 16 C2 A9 22 2D 42 A9 22 31 42 A9 00 22 48 05
A9 FC FC A9 A9 22 53 05 A9 A9 FC FC A9 22 68 43
A9 22 75 43 A9 00

Tile A9 is the animated graphic repeatedly used to create the image of the Mushroom, Fire Flower, and Star.
Tile FC is the blank tile used to create the blank space around the "fireworks".

There are pointers that are used to tell the game where to look for all this data.

Mushroom formation:

0x3C078-0x3C079 (0x2) - D2 DE - $DED2 - 0x01EE2
0x3C07E-0x3C07F (0x2) - EB DE - $DEEB - 0x01EFB
0x3C084-0x3C085 (0x2) - 08 DF - $DF08 - 0x01F18
0x3C08A-0x3C08B (0x2) - 1D DF - $DF1D - 0x01F2D
0x3C090-0x3C091 (0x2) - 32 DF - $DF32 - 0x01F42

Fire Flower formation:

0x3C07A-0x3C07B (0x2) - 51 DF - $DF51 - 0x01F61
0x3C080-0x3C081 (0x2) - 72 DF - $DF72 - 0x01F82
0x3C086-0x3C087 (0x2) - 93 DF - $DF93 - 0x01FA3
0x3C08C-0x3C08D (0x2) - B4 DF - $DFB4 - 0x01FC4
0x3C092-0x3C093 (0x2) - D7 DF - $DFD7 - 0x01FE7

Star formation:

0x3C07C-0x3C07D (0x2) - 19 82 - $8219 - 0x3C229
0x3C082-0x3C083 (0x2) - 36 82 - $8236 - 0x3C246
0x3C088-0x3C089 (0x2) - 4F 82 - $824F - 0x3C25F
0x3C08E-0x3C08F (0x2) - 68 82 - $8268 - 0x3C278
0x3C094-0x3C095 (0x2) - 7D 82 - $827D - 0x3C28D

While the large blocks of data might be difficult to read at first, it becomes easier when we take it one step at a time. The general system functions as follows; you start with a PPU address, determine how many bytes make up the tiles, the direction to draw them, and the data for the tiles to draw. Rinse and repeat. A "00" byte indicates the end of a group, and then the game proceeds to use the next pointer.
To illustrate how this basically works, let's break up the data strings for the Mushroom formation, using the pointers listed above.

0x3C078-0x3C079 (0x2) - D2 DE - $DED2 - 0x01EE2-0x01EFA (0x19)

20 8D 46 A9 - 6 A9 tiles, left to right (PPU $208D-$2092).
20 AB 44 A9 - 4 A9 tiles, left to right (PPU $20AB-$20AE).
20 B1 44 A9 - 4 A9 tiles, left to right (PPU $20B1-$20B4).
20 CA 45 A9 - 5 A9 tiles, left to right (PPU $20CA-$20CE).
20 D1 45 A9 - 5 A9 tiles, left to right (PPU $20D1-$20D5).
21 4A C3 A9 - 3 A9 tiles, up to down (PPU $214A, $216A, $218A).
00 - Terminator/end of group.

0x3C07E-0x3C07F (0x2) - EB DE - $DEEB - 0x01EFB-0x01F17 (0x1D)

20 E9 05 A9 A9 FC A9 A9 - 5 tiles, "A9 A9 FC A9 A9", left to right (PPU $20E9-$20ED).
20 F2 05 A9 A9 FC A9 A9 - 5 tiles, "A9 A9 FC A9 A9", left to right (PPU $20F2-$20F6).
21 28 C7 A9 - 7 A9 tiles, up to down (PPU $2128, $2148, $2168, $2188, $21A8, $21C8, $21E8).
21 09 C6 A9 - 6 A9 tiles, up to down (PPU $2109, $2129, $2149, $2169, $2189, $21A9).
21 4D C3 A9 - 3 A9 tiles, up to down (PPU $214D, $216D, $218D).
00 - End of group.

0x3C084-0x3C085 (0x2) - 08 DF - $DF08 - 0x01F18-0x01F2C (0x15)

21 2E C8 A9 - 8 A9 tiles, up to down (PPU $212E, $214E, $216E, $218E, $21AE, $21CE, $21EE, $220E).
21 2F C5 A9 - 5 A9 tiles, up to down (PPU $212F, $214F, $216F, $218F, $21AF).
21 30 C5 A9 - 5 A9 tiles, up to down (PPU $2130, $2150, $2170, $2190, $21B0).
21 31 C8 A9 - 8 A9 tiles, up to down (PPU $2131, $2151, $2171, $2191, $21B1, $21D1, $21F1, $2211).
21 52 C3 A9 - 3 A9 tiles, up to down (PPU $2152, $2172, $2192).
00 - End of group.

0x3C08A-0x3C08B (0x2) - 1D DF - $DF1D - 0x01F2D-0x01F41 (0x15)

21 55 C3 A9 - 3 A9 tiles, up to down (PPU $2155, $2175, $2195).
21 16 C6 A9 - 6 A9 tiles, up to down (PPU $2116, $2136, $2156, $2176, $2196, $21B6).
21 37 C7 A9 - 7 A9 tiles, up to down (PPU $2137, $2157, $2177, $2197, $21B7, $21D7, $21F7).
21 CB 4A A9 - 10 A9 tiles, left to right (PPU $21CB-$21D4).
21 E9 C2 A9 - 2 A9 tiles, up to down (PPU $21E9, $2209).
00 - End of group.

0x3C090-0x3C091 (0x2) - 32 DF - $DF32 - 0x01F42-0x01F60 (0x1F)

21 EA C4 A9 - 4 A9 tiles, up to down (PPU $21EA, $220A, $222A, $224A).
21 EB 84 A9 FC FC A9 - 4 tiles, "A9 FC FC A9", up to down (PPU $21EB, $220B, $222B, $224B).
21 F4 84 A9 FC FC A9 - 4 tiles, "A9 FC FC A9", up to down (PPU $21F4, $2214, $2234, $2254).
21 F5 C4 A9 - 4 A9 tiles, up to down (PPU $21F5, $2215, $2235, $2255).
21 F6 C2 A9 - 2 A9 tiles, up to down (PPU $21F6, $2216).
22 6B 4A A9 - 10 A9 tiles, left to right (PPU $226B-$2274).
00 - End of group.

Here's a diagram to further break it down, byte for byte, using the first string of data:

Code: [Select]
[20 8D] [46] [A9]
 |       |    |
 |       |    [Tile(s).]
 |       |
 |       [Left = function to draw; right = number of tiles to draw.]
 [PPU address.]

If the function is 0, a specific set of data is drawn from left to right.
If the function is 4, the same tile is drawn repeatedly from left to right.
If the function is 8, a specific set of data is drawn from up to down.
If the function is C, the same tile is drawn repeatedly from up to down.

I use the term "function" here loosely, and there is most certainly a better way to label it (that's my bad), but hopefully what I'm trying to communicate is transparent enough.

There are definitions, other data, and additional pointers as well.

0x3C2A6-0x3C359 (0xB4) - Palette, definitions, "YOU GOT A CARD", etc.

Code: [Select]
                  23 CA 44 FF 23 D2 44 FF 23 DA
44 FF 23 E2 44 FF 00 23 D3 02 BF EF 23 DB 02 FB
FE 00 23 D3 02 6A 9A 23 DB 02 A6 A9 00 23 CA 04
BF AF AF EF 23 D2 04 BB 55 55 EE 23 DA 04 BB 55
55 EE 23 E2 04 FB FA FA FE 00 23 CA 04 7F 5F 5F
DF 23 D2 04 77 55 55 DD 23 DA 04 77 55 55 DD 23
E2 04 F7 F5 F5 FD 00 23 CA 44 55 23 D2 44 55 23
DA 44 55 23 E2 44 55 00 3F 0D 43 0F 00 3F 05 03
0F 30 3C 3F 09 03 0F 10 2C 3F 0D 43 0F 00 22 C7
13 0D 0E 0A FC 06 0E 09 FC 00 FC 05 00 02 07 FC
26 FE FE 27 22 B6 04 20 21 21 22 22 F6 04 26 FE
FE 27 23 16 04 28 24 24 25 00

0x3C076-0x3C077 (0x2) - 08 83 - $8308 - 0x3C318-0x3C31C (0x5)

3F 0D 43 0F
00 - End of group.

0x3C096-0x3C097 (0x2) - 96 82 - $8296 - 0x3C2A6-0x3C2B6 (0x11)

23 CA 44 FF
23 D2 44 FF
23 DA 44 FF
23 E2 44 FF
00 - End of group.

0x3C098-0x3C099 (0x2) - 0D 83 - $830D - 0x3C31D-0x3C32D (0x11)

3F 05 03 0F 30 3C
3F 09 03 0F 10 2C
3F 0D 43 0F
00 - End of group.

0x3C09A-0x3C09B (0x2) - A7 82 - $82A7 - 0x3C2B7-0x3C2C1 (0xB)

23 D3 02 BF EF
23 DB 02 FB FE
00 - End of group.

0x3C09C-0x3C09D (0x2) - B2 82 - $82B2 - 0x3C2C2-0x3C2CC (0xB)

23 D3 02 6A 9A
23 DB 02 A6 A9
00 - End of group.

0x3C09E-0x3C09F (0x2) - BD 82 - $82BD - 0x3C2CD-0x3C2E9 (0x1D)

23 CA 04 BF AF AF EF
23 D2 04 BB 55 55 EE
23 DA 04 BB 55 55 EE
23 E2 04 FB FA FA FE
00 - End of group.

0x3C0A0-0x3C0A1 (0x2) - DA 82 - $82DA - 0x3C2EA-0x3C306 (0x1D)

23 CA 04 7F 5F 5F DF
23 D2 04 77 55 55 DD
23 DA 04 77 55 55 DD
23 E2 04 F7 F5 F5 FD
00 - End of group.

0x3C0A2-0x3C0A3 (0x2) - F7 82 - $82F7 - 0x3C307-0x3C317 (0x11)

23 CA 44 55
23 D2 44 55
23 DA 44 55
23 E2 44 55
00 - End of group.

0x3C0A6-0x3C0A7 (0x2) - 1E 83 - $831E - 0x3C32E-0x3C359 (0x2C)

22 C7 13 0D 0E 0A FC 06 0E 09 FC 00 FC 05 00 02 07 FC 26 FE FE 27 - "YOU GOT A CARD" + second row of box display.
22 B6 04 20 21 21 22 -+
22 F6 04 26 FE FE 27  +--- Box display.
23 16 04 28 24 24 25 -+
00 - End of group.

Most of this data is for setting the palette and attributes (which parts of the screen use which quarters of the palette). Depending on the depths of your planned changes, you may or may not need to mess with it. The last group (0x3C32E-0x3C359) is for displaying "YOU GOT A CARD" and the box with the Mushroom, Fire Flower, or Star. The "FE FE" tiles are replaced with the appropriate selection.

These are the tiles used for each display:

Mushroom card:

0x05E7A - 60 - Top-left.
0x05E7C - 61 - Top-right.
0x05E86 - 62 - Bottom-left.
0x05E88 - 63 - Bottom-right.

Fire Flower card:

0x05E7E - 64 - Top-left.
0x05E80 - 66 - Top-right.
0x05E8A - 67 - Bottom-left.
0x05E8C - 68 - Bottom-right.

Star card:

0x05E82 - 2C - Top-left.
0x05E84 - 2D - Top-right.
0x05E8E - 2E - Bottom-left.
0x05E90 - 2F - Bottom-right.

Hopefully this provides at least a general idea of how to mess around with the fireworks related stuff.
Sorry if it's confusing, incorrect, and/or doesn't cover everything. I tried... I'll continue to use my excuse of not ROM hacking anymore and probably eating something that was still alive and shouldn't have been.
I would recommend maybe drawing out your planned design(s) on a grid labelled with the appropriate PPU addresses/locations so that you can more easily organize how you'll have to manipulate the data to achieve what you want.
Best of luck. You can do it! Please keep us updated on your progress!

Personal Projects / Re: Basu Bacteria - My new Krazy Kreatures hack
« on: August 22, 2018, 05:57:23 pm »
To use the palette for the pointer, we would have to look to see if we can find and change the sprite attributes. I found that the sprites for this game are within the $0700-$07FF range in RAM. As we can see, there are a bunch of "02" values found within that range, in an organized manner (because each sprite consists of four values, including its X and Y position values, the graphical tile used for the sprite, and which part of the palette is used for it). With the PPU Viewer, it can be seen that the third quarter of the sprite palette is what the "G" and "O" uses. Considering values/identifiers of 00, 01, 02, and 03, we can break the sprite palette up into groups of four values each.

So, I used the first "02" attribute value that I could see within the sprites range, since the attribute for the sprite is what we're trying to change, at $0706 in RAM, to set a conditional write breakpoint. I assumed the value of "02" that we're looking for would be loaded into the Accumulator register, so my condition is "A==#02".

When transitioning to the Game Over screen, the debugger froze at $9A62 in RAM. When scrolling up, a line of code where a load of a value of "02" is found, unlike previously when the load wasn't found in the nearby code, and was actually in a different area that we located by referring to the stack.

$9A60 in RAM is 0x1A70 in the ROM, so let's look there.

Since the pointer uses the first quarter of the sprite palette, let's try to change the 02 to 00 at 0x1A71 in the ROM file.

Following this, I reloaded a save state that I made on the fourth level and lost again. After transitioning to the Game Over screen again, the "G" and "O" sprites appeared different. Looking closely, the insides of the letters were now pink instead of grey, and the outer borders were light blue instead of light green. Looking within the $0700-$07FF range in RAM, the values that were originally 02 are now all 00. Therefore, it is reasonable to conclude that the change we intended to make was successful.

As you pointed out, the third quarter of the sprite palette (02) was different depending on which level you got a Game Over on. However, it seemed that the first quarter of the sprite palette (00) was always the same. So, hopefully this is the change that you wanted.

Like before, I could be missing something. Hopefully not. Maybe I need to eat something...

Best of luck with your project! :beer:

Personal Projects / Re: Basu Bacteria - My new Krazy Kreatures hack
« on: August 21, 2018, 04:14:20 pm »
I took a look, and hopefully I found it and am not missing something. If I am, please let me know.

The palette values for the Game Over screen are not a normal palette with sequential values, but rather, retrieved from code.

Change 30 to 2A at 0x1696 in the ROM file to change the white text to your intended green.

Again, if I'm missing anything from this and/or your other topic, please let me know. It's very possible. I don't really ROM hack anymore, so I could be out of it...

In my opinion, this would be one "easier" way to prevent the N-Spade Bonus card game. As far as I can tell, it works as intended.
Like I mentioned in my previous post, more in-depth modifications can't necessarily be accomplished with the game-specific utilities like SMB3 Workshop or the SMB3 Map Editor unless the appropriate ROM offsets are programmed in. (For instance, in SMB3 Workshop, under the Edit menu, you can select "Edit Miscellaneous" to modify some in-game settings from directly within the level editor. However, the possibilities are limited to the included variables.)
Therefore, you'll have to use a hex editor (like the one in FCEUX/FCEUXD, or a standard hex editor like HxD or WindHex32) to change these bytes at the appropriate offsets in the ROM file (not RAM or PPU).

0x16CDF-0x16CE1 (0x3)
Change "99 15 7F" to "EA EA EA".

0x16CFD-0x16CFF (0x3)
Change "8D F6 04" to "EA EA EA".

To explore exactly what these changes accomplish:


$ACCC is 0x16CDC in the ROM.

Code: [Select]
$ACCC:BD 4F AC  LDA $AC4F,X @ $AC4F = #$09   ; N-Spade Bonus.
$ACCF:99 15 7F  STA $7F15,Y @ $7F18 = #$00   ; It appears!

$ACEB is 0x16CFB in the ROM.

Code: [Select]
$ACEB:A9 10     LDA #$10                     ; Bonus appearance sound.
$ACED:8D F6 04  STA $04F6 = #$00             ; It plays!


Code: [Select]
$ACCC:BD 4F AC  LDA $AC4F,X @ $AC4F = #$09   ; N-Spade Bonus.
$ACCF:EA        NOP                          ; Why
$ACD0:EA        NOP                          ; you
$ACD1:EA        NOP                          ; do?

Code: [Select]
$ACEB:A9 10     LDA #$10                     ; Bonus appearance sound.
$ACED:EA        NOP                          ; Nothing
$ACEE:EA        NOP                          ; going
$ACEF:EA        NOP                          ; on.

The first change prevents the game from ever adding the N-Spade Bonus (09) to the active collection of sprites on the current world map.
The second change is to prevent the game from playing the sound that indicates the N-Spade Bonus has appeared (it probably seems weird to hear it, only for nothing to appear).

Concerning the previous posts and deciding which utilit(y)(ies) and SMB3 hacking method(s) you would prefer to use, consider what exactly you want to accomplish with your SMB3 hack. Are you going for a simpler hack or a more in-depth hack?

What sics claimed about NoDice being "easier" to use may very well be true - I can't say one way or another because I've never used it - but from the image that I saw of the editor back in the day, it wasn't entirely clear what more the level editor can accomplish and/or how exactly it makes level editing "easier" than SMB3 Workshop. Even from sics' provided GIF, NoDice looks pretty similar to SMB3 Workshop in terms of level building/editing, but possibly accomplishes its goals in different ways. Perhaps the editor's main advantage is being able to work more directly with the accompanying disassembly? In which case, unless you're planning to make an advanced hack, it might be a bit overkill.

My preference for SMB3 Workshop is simply that - my personal preference and opinion that SMB3 Workshop, and everything else that I listed in my previous post, simplifies level editing and modifying SMB3 easier for me; but that's also, admittedly, because those utilities and methods are what I've used frequently and consistently. In summary, "the way I do". Something could be the easiest thing in the world, but the first time you do it, you have to learn how to do it, and that could prove to be very time consuming and difficult. On the other hand, something that is super difficult becomes easier the more that you practice it, to the point that it comes naturally to those who master it, and comes across as impossible to newcomers who have no idea where to start. As I've stated in the past, ROM hacking is a hobby that people have to commit to and become familiar with before they will eventually be rewarded with the successes and accomplishments that they seek in completing their desired projects.

So, with regards to "easily" copying or moving levels designed in SMB3 Workshop to NoDice/nesasm/whatever else, without any personal knowledge or familiarity with the alternative options/methods, my educated guess would be that there's no direct compatibility between the utilities and methods, and that your primary option is to re-design your SMB3 Workshop-built levels again in NoDice to add them to the build of your hack designed through the newer utilit(y)(ies). I could most certainly be completely wrong and out of line about it though. However, we would need someone else to come in and cover all the details for us. SMB3 Workshop has a method of saving levels you create in an M3L format of sorts, but I wouldn't account for NoDice following the same 'outdated' method of that. From what I can recall about the format from some old forum posts, the method wasn't really a sure, reliable answer to saving time, either.

In short, do what you feel is best, and make your hack the way that you want to make it, to the best of your ability.

If you have questions concerning methods involving NoDice and the like, unfortunately, I can't provide specific details for any of that. As it is, I stopped ROM hacking a few years ago, so I'm rusty overall, and have no necessary reason or desire to attempt to use NoDice. However, that's just me, and by no means should it prevent you from using it, especially if it's easier in today's modern world, as sics claimed.

If you have questions concerning the old utilities and methods that I previously listed and covered, I'll try my best to continue helping you out when I have the time and provided I can figure it out again for myself. :P

Apologies for the long post. Best of luck, as always.

There is more scattered information spread around many different corners of the Internet, along with the entire SMB3 disassembly, as opposed to specific tutorials, I would say.

SMB3 Workshop is excellent for creating/editing/viewing levels/areas. However, it doesn't help you modify everything.
The SMB3 Map Editor is perfect for taking care of everything to do with the overworld maps.
You can edit your title screen with SMB3TE.
You can edit the graphics with graphics editors like Tile Layer Pro and YY-CHR, if it's something that you're considering as well.
For other modifications in the ROM file, you're better off having a hex editor (like HxD or WindHex32) and/or a special emulator (for example, FCEUX/FCEUXD) to handle the ROM file more directly. However, it's recommended that you build some experience first, since you need to have an idea of what you're looking at and trying to do.

It sounds like you might have figured out your objects and enemies problem.
With SMB3 Workshop in general, yes, you need to click on one of the buttons between 3-byte objects, 4-byte objects, and enemies depending on which one you want to add next, and then you have to click on the screen to add it in, each and every single time.
If "Freeform Mode" under the Edit menu is checked, and "Limit Size" is unchecked, you should be able to add an object and/or an enemy. Otherwise, the editor should prevent you from doing so. However, this is for a very good reason, and it's best to learn this as early as possible in your ROM hacking journey: You do NOT have unlimited space to work with. The ROM file you are modifying is a fixed size, and each level cannot be exceeded by even one byte if you are editing the levels using the original game's ROM offsets.

The defaults for adding objects and enemies are:

3-byte object: Bank 0, Type 0 (00) (ex. "Background Hills A" in 1-Plains, "Door" in 2-Dungeon, etc.)
4-byte object: Bank 2, Type 176 (B0) (ex. "Blue X-Blocks" in 1-Plains, "Blocks with circles in the middle" in 2-Dungeon, etc.)
Enemy: Type 114 (72) (Goomba)

However, if there's a specific object or enemy that you're using a lot of and don't want to switch to multiple times in a row, select an object or enemy, and under the Object menu, select "Clone Object/Enemy". Then, instead of the regular default, that will be the starting object/enemy when you add another one in, until you copy another one, or close the program until next time.
Remember that left mouse clicks and drags deal with 3-byte objects and 4-byte objects, while right mouse clicks and drags deal with enemies. You can left-click the "Add an enemy" button and add it into your editing area with a left click, but to move the enemy, you'll need to use the right mouse clicker and hold it to drag the enemy to the spot that you want it.

As for your new problem regarding level crashes, that is because of yet another limitation within the original game's engine.
You cannot change a level's Object Set, because the levels are laid out within specific banks of the ROM file.
Some level types are interchangeable, but only because they share the same bank.

Code: [Select]
 - Sky & Ice
 - Piranha Plant, Giant & Cloudy
 - Water & Pipe

       1 - Plains: 0x1E509 - 0x2000F
     2 - Fortress: 0x2A7F7 - 0x2C00F
            *NOTE: 0x2A7F7 - 0x2A866 = 7 End Castles
        3 - Hilly: 0x20587 - 0x2200F
          4 - Sky: 0x227E0 - 0x2400F -----------------+
5 - Piranha Plant: 0x26A6F - 0x2800F -----+           |
        6 - Water: 0x24BA7 - 0x2600F -----+-----+     |
         8 - Pipe: 0x24BA7 - 0x2600F -----+-----+     |
       9 - Desert: 0x28F3F - 0x2A00F      |           |
         A - Ship: 0x2EC07 - 0x3000F      |           |
        B - Giant: 0x26A6F - 0x2800F -----+           |
          C - Ice: 0x227E0 - 0x2400F -----+-----------+
       D - Cloudy: 0x26A6F - 0x2800F -----+
  E - Underground: 0x1A587 - 0x1C00F

This is what you would have to do instead if you want 1-2 in your hack to be a Sky level; specifically, the original 1-6.
Open your ROM in the SMB3 Map Editor. Under the Mode menu, you can see that "Viewer" is checked by default. Select/switch to "Pointers".
You should see blue squares over each space on the map that can potentially be entered by Mario/Luigi, with Pointer #1 for 1-1 selected by default.
Left-click on 1-2 (labelled Pointer #3). This is the pointer that you want to change. Press the Enter key, and a "Select Stage" window appears.
Select 'World 1-6'. Press OK. Next, select the "Implement Changes (Do Before World/Mode Change)" option in the main window. Afterwards, under the File menu, select Save. To ensure your changes are saved successfully, and before you change to a different Mode, you have to do this every single time you change something.

Now, consider these two points while you are changing things within the SMB3 Map Editor.
Firstly, you will most certainly change your overworld layouts in the future so that they won't look like the maps in the original game. Therefore, the pointer you need to modify to make sure that your 1-2 points to the original 1-6 Sky level might not necessarily be Pointer #3, as the pointers are laid out going left-to-right, and up-to-down.
Secondly, to simplify testing levels as you are creating them, you can always edit the pointer for 1-1 to load up the level that you are currently editing while play-testing your hack in an emulator, if you choose to do so. This saves you time from having to play through every other level before you make it to the level you could be currently editing. Of course, you'll probably want to beta test the whole game from start to finish once or twice before you eventually release it.

Another point to consider in general:
If you have your ROM file open in SMB3 Workshop to edit the levels, but you also open it up in another utility to edit something else, like the SMB3 Map Editor to modify map details or change a pointer for testing purposes, or the hex editor in FCEUX/FCEUXD to modify level headers directly or other variables in the game, you HAVE to reopen your ROM in any other utilities that you have it open in. Think about it. You are saving changes to your ROM in Utility B, but the ROM is still actively open in Utility A in the state it was in before you just changed and saved it in Utility B. If you change something and save your ROM in Utility A without reopening it first, the changes you just made and saved to it in Utility B will be lost.
Therefore, if you use multiple utilities for different hacking purposes, be sure to take care and keep track of your modifications. To eliminate any potential risk, only ever have your ROM open in one utility at a time, save your ROM and exit the utility when you're done, and then open the new utility, followed by opening your ROM in that utility, so then there's no doubt that your ROM is in the most recent state when opened in the next utility.

It might not be a thread, and for that I apologize, but I definitely recommend that you read through the "General SMB3 Hacking Thread" on Board 2. While there are a lot of posts that were made in regular conversation, there is a lot of valuable information, general and hacking related, buried within the (currently) 22 pages of posts.
General SMB3 Hacking Thread (Board 2 Link)

Sorry if this post is a lot to take in, and/or if the directions provided haven't supplied you with the information that you've requested. If you can possibly provide anymore specific details about your actions and processes taken so far, and even provide some visuals of any issues in question, perhaps I and/or other members can attempt to provide you with some more direct assistance.

Until next time, hopefully you're able to figure more things out as you continue playing around with SMB3 Workshop and other utilities, and discover and learn from more resources available out there.
As always, best of luck. You can do it! Take care. :)

ROM Hacking Discussion / Re: SMB3 Autoscroll in SMB3 Workshop
« on: March 06, 2018, 06:07:34 am »
Hello! :)

I like to do all my manual enemy hex editing in the hex editor in FCEUXD.
So, the first 'enemy' placed in the Autoscrolling levels is the "Autoscrolling" sprite (Type: 211 (D3 in hex)).
We also need the data for the levels that we're looking at; in this case, 3-3 and 7-8.

Object Data: 1FE79
Enemy Data: C59E
Object Set: 1-Plains

Object Data: 1EF7F
Enemy Data: C33D
Object Set: 1-Plains

With the SMB3 ROM open in FCEUXD, when you scroll down to 0xC59E, the first 4 bytes in the original data that you would see are: 01 D3 00 50.
Enemy data sets should always begin with a "00" or "01" byte, so don't remove it and make sure that it's there. SMB3 Workshop displays your enemies by looking for this 'first' byte.
The "D3 00 50" is the Autoscrolling data that you're looking for.
Scroll back up to 0xC33D. The first 4 bytes in the original data would be: 01 A0 11 18 (the necessary "01" and the first "Green Piranha Plant (upward)" enemy). Simply replace "A0 11 18" with "D3 00 50", and you should have your Autoscrolling set up for your custom 7-8!

For reference, the other Autoscrolling settings seen in other original SMB3 levels (where the Autoscrolling sprite is further down while viewing the level in SMB3 Workshop) are the following:

World 1-Dungeon Spike Room
Object Data: 2AA3A
Enemy Data: D361
Object Set: 2-Dungeon
Relevant Data: D3 01 30 D3 1C 30
(This area actually uses 2 Autoscrolling sprites for its effect.)

World 2-Dungeon Spike Room
Object Data: 29C0C
Enemy Data: D264
Object Set: 9-Desert
Relevant Data: D3 04 31

Object Data: 1AC69
Enemy Data: C964
Object Set: E-Underground
Relevant Data: D3 00 51

Object Data: 27077
Enemy Data: CF24
Object Set: B-Giant
Relevant Data: D3 00 52

Object Data: 27212
Enemy Data: CF8B
Object Set: D-Cloudy
Relevant Data: D3 00 20

World 6-Dungeon #3 Falling Room
Object Data: 2B136
Enemy Data: D4B2
Object Set: 2-Dungeon
Relevant Data: D3 08 40

Lost Levels-Lost 6 - Ice
Object Data: 232CF
Enemy Data: CBF5
Object Set: C-Ice
Relevant Data: D3 00 53

Lost Levels-Lost 9 - Clouds
Object Data: 26CB9
Enemy Data: CECD
Object Set: D-Cloudy
Relevant Data: D3 00 55

Lost Levels-Lost 10 - Clouds
Object Data: 279BB
Enemy Data: CECD
Object Set: D-Cloudy
Relevant Data: D3 00 55

Hopefully this helps. Best of luck. You can do it! :)

ROM Hacking Discussion / Re: smb2 and 3 door/pipe destinations
« on: January 31, 2018, 10:53:56 am »
For SMB3 pointers, you need to set 4 things:

1. Entrance horizontal - The horizontal range (x0-xF) of the pipe/door to enter.
2. Exit horizontal - The horizontal location of the pipe/door to exit.
3. Exit vertical - The vertical location of the pipe/door to exit.
4. Exit action - What Mario/Luigi should do once they arrive to the next area.

You determine #1 from the starting area where you're entering the pipe/door.
You determine #2, #3, and #4 from the destination area where the exiting pipe/door is located.
You set the destination area in the Level Header Editor, in the "Next area/Start" tab, in the "Pointer for next area of level" section on the left side.
To note, you can potentially have an area connect to itself. You can also connect to bonus areas like the worldly Underground areas that are generally for bonus items from the giant '?' blocks, or the worldly Plains areas that serve as endings with Goal Cards for some levels. You can refer to this post for more information on the appropriate ROM offsets to change.

With your 3-byte pipe/door selected, look at the bottom-right corner in the editor to see 3 hex values. The second/middle value will determine the "Entrance horizontal" range. For example, in the original 1-1, the downward pipe leading to the bonus area has the following hex values: 27 8D 9B. 8D is its X offset in hex, and therefore, the pipe is within the 80-8F range.

Until you have figured out the *exact* spot that the exiting pipe/door will be in the next area, there's no real point in setting the pointer.

In the next area, select your destination pipe/door and, again, the second/middle value is what you want to get. If you're using a door system and there's no exit door (one-way) then you'll have to figure out the horizontal value of the exiting spot in hex. Either count, or click on a nearby object to check its horizontal value, and use it as a reference. Use the exact hex value you find for this setting.

In a similar fashion, refer to the following image to determine the *approximate* exiting spot for the pipe/door.

You will most likely have to place your exiting pipe/door around this value because, depending on the situation, there may be an undesired black/red-X sprite that will appear as Mario/Luigi exits a pipe, or Mario/Luigi might drop down if your ground isn't placed at the correct level. Therefore, some trial and error/testing may be necessary to get it right.

Depending on the objects that you're using to go from one area to the next, the "Exit action" will be different. They should be self-explanatory.
To note, "7 - ?" is for "Red Invisible Note Block" 3-byte objects (Bank 2, Type 7 (07)) that can be found in some SMB3 levels like the original 1-3.

Not sure if this covers everything for you, but hopefully it's something.

Pages: [1] 2 3 4 5 6