Language…
11 users online: Cristian Cardoso, Darolac, howardadam1126, lean4, marvisjj, Oskise, RenkoV2,  Segment1Zone2, Shiki_Makiro, SpacePea, Zavok - Guests: 260 - Bots: 296
Users: 64,795 (2,377 active)
Latest user: mathew

SA-1 Pack - v1.40 released

Originally posted by WhiteYoshiEgg
  • In what order should I be doing things? I've applied sa1.asm to an expanded but otherwise untouched ROM, so far so good. Do I absolutely have to apply all other patches right after that, before doing anything in LM? I should still be able to apply them later, shouldn't I?

In my hack, I've applied some patches after I've modified some levels, so yes, you can apply patches after doing something with LM.

Originally posted by WhiteYoshiEgg
  • Is transforming RAM addresses all there is to patch converting? There seems to be something I'm not getting. I've tried to convert this patch of mine by simply changing $0E to $300E, but patching that just freezes the ROM after the title screen.

I know that you have to convert only 16-bit addresses and addresses which are used for sprites, like $0ADE or $19F3 into SA-1 addresses. ($14EC for example is an exception because it's used in sprites. You have to change it into a very different address. $9E, $D8 and $E4 are even changed into 16-bit addresses!) Did you have deleted "fastrom" and changed "lorom" into "sa1rom"? Without changing them in asar patches with an automatic freespac freespace searching will crash the game by patching it. #ab{;)}

Edit: Non working button FTW!
Originally posted by MarioFanGamer659
Originally posted by WhiteYoshiEgg
  • In what order should I be doing things? I've applied sa1.asm to an expanded but otherwise untouched ROM, so far so good. Do I absolutely have to apply all other patches right after that, before doing anything in LM? I should still be able to apply them later, shouldn't I?

In my hack, I've applied some patches after I've modified some levels, so yes, you can apply patches after doing something with LM.

Originally posted by WhiteYoshiEgg
  • Is transforming RAM addresses all there is to patch converting? There seems to be something I'm not getting. I've tried to convert this patch of mine by simply changing $0E to $300E, but patching that just freezes the ROM after the title screen.

I know that you have to convert only 16-bit addresses and addresses which are used for sprites, like $0ADE or $19F3 into SA-1 addresses. ($14EC for example is an exception because it's used in sprites. You have to change it into a very different address. $9E, $D8 and $E4 are even changed into 16-bit addresses!) Did you have deleted "fastrom" and changed "lorom" into "sa1rom"? Without changing them in asar patches with an automatic freespac freespace searching will crash the game by patching it. #ab{;)}

Edit: Non working button FTW!


24-bit addresses need to be converted too. 8-bit adresses don't need to because the Direct Page is set to 3. in the docs folder included are text files that list all addresses that were remapped. Also, if your code is being run by SA-1 (dunno how to tell if it is), you can't use the SNES' arithmetic registers and maybe other registers too.

Also, for your first question, after using LM you can still use AddMusic and SpriteTool too. Using SA-1 isn't very different from regular hacking, once you get used to it.
Alright, let me get this straight. To make an existing patch work with SA-1, what you need to do is:

  • Change lorom to sa1rom and remove fastrom (the latter isn't actually necessary since newer Asar versions ignore fastrom anyway).
  • Replace RAM adresses in this manner:
    • $0000 - $00FF  →  $3000 - $30FF (technically applies to 8-bit addressing as well, but since the direct page is set to $3000, 8-bit addresses need not be changed)
    • $0100 - $1FFF  →  $6100 - $7FFF
    • $7EC800 - $7EFFFF  →  $40C800 - $40FFFF
    • $7FC800 - $7FFFFF  →  $41C800 - $41FFFF
    • $7F9A7B - $7F9C7A  →  $418800 - $4189FF
    • $700000 - $7007FF  →  $41C000 - $41C7FF
    • $700800 - $7027FF  →  $41A000 - $41BFFF
    • All Sprite addresses as documented in docs/Sprite Remap.txt

Is everything correct? More importantly, is there anything I missed?

Also, regarding the new sprite addresses: Are there any addresses that weren't used for sprite tables in the original SMW?
For example, one of the new sprite tables is $754C, and looking at the RAM Map, $154C was also a sprite table in SMW, which is fine. Are there any addresses, though, that don't map like that? I mean, is any of the new tables something like $6DBF (whereas I'd expect $0DBFto still hold the amount of coins)?

Hope I made myself at least remotely clear.


 
Originally posted by WhiteYoshiEgg

Also, regarding the new sprite addresses: Are there any addresses that weren't used for sprite tables in the original SMW?
For example, one of the new sprite tables is $754C, and looking at the RAM Map, $154C was also a sprite table in SMW, which is fine. Are there any addresses, though, that don't map like that? I mean, is any of the new tables something like $6DBF (whereas I'd expect $0DBFto still hold the amount of coins)?

Hope I made myself at least remotely clear.


The only RAM used for sprite tables now that wasn't used for sprite tables in the original SMW is IRAM, specifically $3200 to $3425.

On a different note, I've been encountering a weird bug that only happens with ZSNES. It seems that if subroutine $00BEB0 is called from SA-1 then there is a very small chance that it will crash ZSNES. $00BEB0 is the subroutine used to change a map16 tile and is called by sprites at times such as when a mole jumps out of the ground to generate the hole in the ground, or as a vine climbs to generate the vine tiles.

The bug is difficult to reproduce on the original game but I wrote a sprite that makes it easier to get the bug:
Code
print "INIT ",pc
    RTL

print "MAIN ",pc
    LDA $322C,x
    STA $9A
    LDA $326E,x
    STA $9B
    LDA $3216,x
    STA $98
    LDA $3258,x
    STA $99

    LDA #$03
    STA $9C
    JSL $00BEB0
    RTL

Place 4 or so of these next to eachother in a level and run around for a bit and it should cause zsnes to crash.

I did a little digging around and saw that the $00BEB0 subroutine gets hijacked by the SA-1 pack at $00BFC5 (see boost/sprites.asm for the code for this hijack). The hijack checks if it's currently running on the SA-1 CPU and if so it calls the SNES CPU to perform the remainder of the subroutine. The crashing must have something to do with the CPU switching here because in the sprite above, if I instead get the SA-1 to call SNES and have SNES call $00BEB0 itself so that no CPU switching happens in the subroutine itself, then it will no longer crash ZSNES. However, I've looked through the hijack code and can't see anything that might cause problems.

So I don't really know what could be causing this problem. Like I said, I can only get it crash on ZSNES and not on BSNES or SNES9x, so it could even be some weird unpredictable ZSNES bug. Any ideas?
Hmm, the conversion of uberASM doesn't seem to work. The game just crashes on startup.

EDIT: Only happens in the asar version. The xkas version works fine. This is really annoying regardless.

EDIT2: And the xkas version seems to randomly crash the game while in a level. It happens in every level, ~7 seconds after entering it. I have no code inserted anywhere.
Originally posted by Sakuya Izayoi
Hmm, the conversion of uberASM doesn't seem to work. The game just crashes on startup.

EDIT: Only happens in the asar version. The xkas version works fine. This is really annoying regardless.

EDIT2: And the xkas version seems to randomly crash the game while in a level. It happens in every level, ~7 seconds after entering it. I have no code inserted anywhere.


There really should be zero difference other than freespace between the asar and xkas versions. Try dumping the addresses asar uses for freespace and whether or not the range is SA-1 acceptable.

As for the later crash I would suggest investigating conflicting hijacks. Especially with other patches if you have additional patches installed. If I had to take a stab in the dark I imagine the level number isn't being properly saved which would execute garbage. Easy test for this would hardcode the pointer index to zero -- that was it is for a fact executing a valid levels data, which level is irrelevant for this test.
Well, for one thing, I disabled the OW, NMI and statusbar hijacks because I'm fairly sure they would conflict (I'm using the NoOW patch, I disabled the status bar and I don't think I'll need the NMI one so let's save some precious NMI time by disabling that hijack.

Also, I tried finding conflicting hijacks (with those I enabled), but couldn't. And I hardcoded the pointer and it still crashes.
Originally posted by Sakuya Izayoi
Well, for one thing, I disabled the OW, NMI and statusbar hijacks because I'm fairly sure they would conflict (I'm using the NoOW patch, I disabled the status bar and I don't think I'll need the NMI one so let's save some precious NMI time by disabling that hijack.

Also, I tried finding conflicting hijacks (with those I enabled), but couldn't. And I hardcoded the pointer and it still crashes.



If you have snes9x(-rr/debugger) or bsnes debugger around could you get me a trace log of the crash? You may have to use the bsnes debugger since I don't know if the SA-1 will be caught by the snes9x tracer -- but it may be.
@Arujus: Alright, I will take a look. But since I guess SA-1 Pack v1.12 will get removed, I may do it later together with the possible changes.

@Sakuya: Arujus found a LOROM tag on level.asm which probably is the cause of the crash bug on uberASM. Download the patch again with all hijacks on and try again. I forgot to upload his version.
GitHub - Twitter - YouTube - SnesLab Discord
If patch requests are still being taken, I'd like to request that the tile generation unrestrictor be converted.
For a semi-private project I'm working on, can I have this converted?

EDIT: hell, if it's possible, haxorz the patch so we only get the bank switching
thx to e r i k for layout
Originally posted by Vitor Vilela


thanks!

By the way, I'm getting an error message from the sprite converter: "cannot remap address $7fab70". Where does that get remapped to?


EDIT: ah, i figured it out. that address is read by a sprite clipping patch. is there a sa-1 compatible sprite clipping unrestrictor?
jesus, I never heard about this patch. Can you give me it?

Also, I just updated the SA-1 version of Sprite Tool. I fixed the silver p-switch bug which was crashing the ROM. Just redownload from the SA-1 Compatible Tools page and run normally. You don't have to port anything.
GitHub - Twitter - YouTube - SnesLab Discord


Originally posted by Vitor Vilela
jesus, I never heard about this patch. Can you give me it?


I think he is using this patch. (I may be wrong)


Now, a simple question: Is there a SA-1 version of this patch? Custom blocks are the only thing that makes me to not use SA-1 yet, along with custom music and other minimal issues. But I'll give it a try for sure.





Dream team (feed them, please):






Yes, there's a manual custom block inserter for SA-1: https://dl.dropboxusercontent.com/u/16203903/A/SA1/cpatches.html.

For custom music, you can use AddmusicK, which has native support for SA-1.

About the custom sprite clipping patch, I'll take a look.
Also, I added the piranha plant fix patch.
GitHub - Twitter - YouTube - SnesLab Discord
Another thing, should I convert all patches to asar format already?
I'm pretty sure everyone here agrees asar is much better than xkas and since I'm converting to SA-1 anyway...
GitHub - Twitter - YouTube - SnesLab Discord
I guess you should keep the asar format.
Alright, I'll convert all future patches to SA-1 and to asar format too.

Also, I don't very sure if I should do this or not, but I'm having a lot of complications with Sprite Tool. I'm thinking on undo open of More Sprites code and decrease the maximum number of allowed sprites from 255 to 128.

It means all SA-1 sprites will need to be reconverted, SA-1 Convert will need a update, not counting Sprite Tool, a couple of undo hacks and mainly, the maximum amount of sprites per level will get reduced to 128, but it will have much higher stability and compatibility.

Also, I'm sorry, but for now I won't be able to convert any patch to SA-1. School is coming back and I have more important projects to do together and mainly, make SA-1 Pack get more stable.
GitHub - Twitter - YouTube - SnesLab Discord
Good news, I managed to fix Sprite Tool. The maximum number of sprite per level won't be decreased.

Also I updated uberASM, I found a RAM conflict that could make SMW crash if the 12th sprite slot get used with uberASM's game mode and sprites hack activated.
GitHub - Twitter - YouTube - SnesLab Discord