Alternative msu1-hack close to completion #11

Open
Conn79 opened this Issue Oct 21, 2014 · 22 comments

Comments

Projects
None yet
4 participants
@Conn79

Conn79 commented Oct 21, 2014

Hi,
I'm working on a different Approach and we are in the final stage of Debugging.
http://www.zeldix.net/t453-enable-msu-streaming-music

You find the current hack here:
http://bszelda.zeldalegends.net/stuff/Con/zelda3_msu.zip
(it could be updated in case further bugs are found so track the Forum.)

I unfortunately cannot provide a source code since I directly code into the hex sheet.

I also wish to thank you, mwreichelt, since before I was pointed to your asm, my hack was bsnes only. Examining your code with finding lda $2000 bvs $fb and finally giving $0133 and $2140 #$F1 gave the breakthrough and now it is sd2snes compatible.

@mwreichelt

This comment has been minimized.

Show comment
Hide comment
@mwreichelt

mwreichelt Oct 21, 2014

Owner

This is fantastic! I'm super excited that you've succeeded where I failed.
I just woke up and am about to head to work, but I'll download your patch
when I get home. I'd really like to take a closer look at your hex though
so I can figure out what I've been doing wrong and maybe look into applying
it to other SNES games (though I know different games implement different
SPU programs). If you're writing hex directly to the rom file, could you
tell me where in the file you're writing it?
On Oct 21, 2014 5:25 AM, "Conn79" notifications@github.com wrote:

Hi,
I'm working on a different Approach and we are in the final stage of
Debugging.
http://www.zeldix.net/t453-enable-msu-streaming-music

You find the current hack here:
http://bszelda.zeldalegends.net/stuff/Con/zelda3_msu.zip
(it could be updated in case further bugs are found so track the Forum.)

I unfortunately cannot provide a source code since I directly code into
the hex sheet.

I also wish to thank you, mwreichelt, since before I was pointed to your
asm, my hack was bsnes only. Examining your code with finding lda $2000 bvs
$fb and finally giving $0133 and $2140 #$F1 gave the breakthrough and now
it is sd2snes compatible.


Reply to this email directly or view it on GitHub
#11.

Owner

mwreichelt commented Oct 21, 2014

This is fantastic! I'm super excited that you've succeeded where I failed.
I just woke up and am about to head to work, but I'll download your patch
when I get home. I'd really like to take a closer look at your hex though
so I can figure out what I've been doing wrong and maybe look into applying
it to other SNES games (though I know different games implement different
SPU programs). If you're writing hex directly to the rom file, could you
tell me where in the file you're writing it?
On Oct 21, 2014 5:25 AM, "Conn79" notifications@github.com wrote:

Hi,
I'm working on a different Approach and we are in the final stage of
Debugging.
http://www.zeldix.net/t453-enable-msu-streaming-music

You find the current hack here:
http://bszelda.zeldalegends.net/stuff/Con/zelda3_msu.zip
(it could be updated in case further bugs are found so track the Forum.)

I unfortunately cannot provide a source code since I directly code into
the hex sheet.

I also wish to thank you, mwreichelt, since before I was pointed to your
asm, my hack was bsnes only. Examining your code with finding lda $2000 bvs
$fb and finally giving $0133 and $2140 #$F1 gave the breakthrough and now
it is sd2snes compatible.


Reply to this email directly or view it on GitHub
#11.

@DoctorDan1986

This comment has been minimized.

Show comment
Hide comment
@DoctorDan1986

DoctorDan1986 Oct 21, 2014

I linked this site in the thread, which apparently made all the difference...somehow. I'd be super excited for successful implementation in other games, particularly the Mega Man and Final Fantasy series. This could really open up MSU-1-enhanced games!

I linked this site in the thread, which apparently made all the difference...somehow. I'd be super excited for successful implementation in other games, particularly the Mega Man and Final Fantasy series. This could really open up MSU-1-enhanced games!

@mwreichelt

This comment has been minimized.

Show comment
Hide comment
@mwreichelt

mwreichelt Oct 21, 2014

Owner

That's partly why I want to know more about the algorithm he used. When I
started this I wanted to make a patch for FF6 (thinking about the opera
scene!) or Mega Man X but LttP was easier since it just takes one write to
start playing a song. From what I can tell FF6, and other Square games on
the console, use a different system where it sends more nuanced commands (I
think maybe it calls a table of individual notes, but I'm not sure). I want
to learn from this more successful patch so I can write up how to replicate
it's success! Thanks for mentioning my (woefully incomplete) patch in his
thread!
On Oct 21, 2014 6:20 AM, "DoctorDan1986" notifications@github.com wrote:

I linked this site in the thread, which apparently made all the
difference...somehow. I'd be super excited for successful implementation in
other games, particularly the Mega Man and Final Fantasy series. This could
really open up MSU-1-enhanced games!


Reply to this email directly or view it on GitHub
#11 (comment)
.

Owner

mwreichelt commented Oct 21, 2014

That's partly why I want to know more about the algorithm he used. When I
started this I wanted to make a patch for FF6 (thinking about the opera
scene!) or Mega Man X but LttP was easier since it just takes one write to
start playing a song. From what I can tell FF6, and other Square games on
the console, use a different system where it sends more nuanced commands (I
think maybe it calls a table of individual notes, but I'm not sure). I want
to learn from this more successful patch so I can write up how to replicate
it's success! Thanks for mentioning my (woefully incomplete) patch in his
thread!
On Oct 21, 2014 6:20 AM, "DoctorDan1986" notifications@github.com wrote:

I linked this site in the thread, which apparently made all the
difference...somehow. I'd be super excited for successful implementation in
other games, particularly the Mega Man and Final Fantasy series. This could
really open up MSU-1-enhanced games!


Reply to this email directly or view it on GitHub
#11 (comment)
.

@mwreichelt

This comment has been minimized.

Show comment
Hide comment
@mwreichelt

mwreichelt Oct 21, 2014

Owner

Ah, it looks like you extended the ROM and just wrote your code there. I
don't know anything about how to extend the ROM banks and assumed this
would be an involved process that'd require swapping memory banks at
runtime or something. I'm excited to take a closer look and learn more, but
I'm already late for work now! :)

On Tue, Oct 21, 2014 at 6:26 AM, Michael Reichelt <jumbocactuarx27@gmail.com

wrote:

That's partly why I want to know more about the algorithm he used. When I
started this I wanted to make a patch for FF6 (thinking about the opera
scene!) or Mega Man X but LttP was easier since it just takes one write to
start playing a song. From what I can tell FF6, and other Square games on
the console, use a different system where it sends more nuanced commands (I
think maybe it calls a table of individual notes, but I'm not sure). I want
to learn from this more successful patch so I can write up how to replicate
it's success! Thanks for mentioning my (woefully incomplete) patch in his
thread!
On Oct 21, 2014 6:20 AM, "DoctorDan1986" notifications@github.com wrote:

I linked this site in the thread, which apparently made all the
difference...somehow. I'd be super excited for successful implementation in
other games, particularly the Mega Man and Final Fantasy series. This could
really open up MSU-1-enhanced games!


Reply to this email directly or view it on GitHub
#11 (comment)
.

Owner

mwreichelt commented Oct 21, 2014

Ah, it looks like you extended the ROM and just wrote your code there. I
don't know anything about how to extend the ROM banks and assumed this
would be an involved process that'd require swapping memory banks at
runtime or something. I'm excited to take a closer look and learn more, but
I'm already late for work now! :)

On Tue, Oct 21, 2014 at 6:26 AM, Michael Reichelt <jumbocactuarx27@gmail.com

wrote:

That's partly why I want to know more about the algorithm he used. When I
started this I wanted to make a patch for FF6 (thinking about the opera
scene!) or Mega Man X but LttP was easier since it just takes one write to
start playing a song. From what I can tell FF6, and other Square games on
the console, use a different system where it sends more nuanced commands (I
think maybe it calls a table of individual notes, but I'm not sure). I want
to learn from this more successful patch so I can write up how to replicate
it's success! Thanks for mentioning my (woefully incomplete) patch in his
thread!
On Oct 21, 2014 6:20 AM, "DoctorDan1986" notifications@github.com wrote:

I linked this site in the thread, which apparently made all the
difference...somehow. I'd be super excited for successful implementation in
other games, particularly the Mega Man and Final Fantasy series. This could
really open up MSU-1-enhanced games!


Reply to this email directly or view it on GitHub
#11 (comment)
.

@Conn79

This comment has been minimized.

Show comment
Hide comment
@Conn79

Conn79 Oct 21, 2014

Thanks ^^ as said, your code gave the breakthrough!!! It seems to be completely debugged now so please redownload (fall-back to native spc in case no msu-1 found fixed). It is possible though that more stuff will be found. EmuandCo and TheRetromancer are still playtesting. But it Looks good

Oh sorry, I should have said this. Simply Google Lunar expand and enlarge your Rom to 1.5 MB; apply the patch then on non-headered US rom.
The complete code is here 11/6880-11/6DFF
The main difference is that I made no global hook for all themes but hooked around 40 times whenever a theme is stored to $012c
The rest is custom code like fade-out, decrease volume when on map and such...

Conn79 commented Oct 21, 2014

Thanks ^^ as said, your code gave the breakthrough!!! It seems to be completely debugged now so please redownload (fall-back to native spc in case no msu-1 found fixed). It is possible though that more stuff will be found. EmuandCo and TheRetromancer are still playtesting. But it Looks good

Oh sorry, I should have said this. Simply Google Lunar expand and enlarge your Rom to 1.5 MB; apply the patch then on non-headered US rom.
The complete code is here 11/6880-11/6DFF
The main difference is that I made no global hook for all themes but hooked around 40 times whenever a theme is stored to $012c
The rest is custom code like fade-out, decrease volume when on map and such...

@mwreichelt

This comment has been minimized.

Show comment
Hide comment
@mwreichelt

mwreichelt Oct 21, 2014

Owner

Lunar IPS takes care of expanding the ROM when you apply your .ips patch
(though I didn't have time to try it out on my SNES before I left this
morning).
I'm super excited to go home and try it out. This is my roommate's favorite
game of all time, so I've been forcing him to test my patches (though it
doesn't take much forcing ;) but when I get home today I'll make him start
playing through yours as well. The more eyes looking it over, the better,
right?

The main difference is that I made no global hook for all themes but
hooked around 40 times whenever a theme is stored to $012c
By this, do you mean that you just looked for everywhere the theme is
stored to that address and overwrote it? I'm unable to check this myself
right now, but this sounds like a lot of work (though I suppose it has paid
off)!

The rest is custom code like fade-out, decrease volume when on map and
such...
This is the sort of thing I'm most interested in. I'm still a total novice
at SNES programming, so I'm very interested to see what you did differently
and where I could improve. Would it be okay with you if I wrote about your
algorithm on my blog later (after I understand it better, of course)?

On Tue, Oct 21, 2014 at 9:07 AM, Conn79 notifications@github.com wrote:

Thanks ^^ as said, your code gave the breakthrough!!! It seems to be
completely debugged now so please redownload (fall-back to native spc in
case no msu-1 found fixed). It is possible though that more stuff will be
found. EmuandCo and TheRetromancer are still playtesting. But it Looks good

Oh sorry, I should have said this. Simply Google Lunar expand and enlarge
your Rom to 1.5 MB; apply the patch then on non-headered US rom.
The complete code is here 11/6880-11/6DFF
The main difference is that I made no global hook for all themes but
hooked around 40 times whenever a theme is stored to $012c
The rest is custom code like fade-out, decrease volume when on map and
such...


Reply to this email directly or view it on GitHub
#11 (comment)
.

Owner

mwreichelt commented Oct 21, 2014

Lunar IPS takes care of expanding the ROM when you apply your .ips patch
(though I didn't have time to try it out on my SNES before I left this
morning).
I'm super excited to go home and try it out. This is my roommate's favorite
game of all time, so I've been forcing him to test my patches (though it
doesn't take much forcing ;) but when I get home today I'll make him start
playing through yours as well. The more eyes looking it over, the better,
right?

The main difference is that I made no global hook for all themes but
hooked around 40 times whenever a theme is stored to $012c
By this, do you mean that you just looked for everywhere the theme is
stored to that address and overwrote it? I'm unable to check this myself
right now, but this sounds like a lot of work (though I suppose it has paid
off)!

The rest is custom code like fade-out, decrease volume when on map and
such...
This is the sort of thing I'm most interested in. I'm still a total novice
at SNES programming, so I'm very interested to see what you did differently
and where I could improve. Would it be okay with you if I wrote about your
algorithm on my blog later (after I understand it better, of course)?

On Tue, Oct 21, 2014 at 9:07 AM, Conn79 notifications@github.com wrote:

Thanks ^^ as said, your code gave the breakthrough!!! It seems to be
completely debugged now so please redownload (fall-back to native spc in
case no msu-1 found fixed). It is possible though that more stuff will be
found. EmuandCo and TheRetromancer are still playtesting. But it Looks good

Oh sorry, I should have said this. Simply Google Lunar expand and enlarge
your Rom to 1.5 MB; apply the patch then on non-headered US rom.
The complete code is here 11/6880-11/6DFF
The main difference is that I made no global hook for all themes but
hooked around 40 times whenever a theme is stored to $012c
The rest is custom code like fade-out, decrease volume when on map and
such...


Reply to this email directly or view it on GitHub
#11 (comment)
.

@Conn79

This comment has been minimized.

Show comment
Hide comment
@Conn79

Conn79 Oct 21, 2014

mh, better you use lunar expand first... there's an ingame Header where a Byte must be changed. Most Emulators Play also expanded roms by LunarIPS but it's better you use LunarExpand before applying the patch.

Yepp, making a hook for every theme Change was a pain in the ...a... but I hacked much more difficult things like complete new items and such, e.g.
http://www.zeldix.net/f31-brand-new-items
But I hacked much more even...:
complete patch with most of my work (use the srm in the package to get an idea):
http://www.zeldix.net/f43-the-all-in-patch
(will be updated with the new msu patch as soon verified bug-free).

You can of course take, improve, post, do whatever with my codes as you like. I'm sorry that I'm to sloopy to make a documentation, but with all my hacks I'd write more than code actually ^^

Conn79 commented Oct 21, 2014

mh, better you use lunar expand first... there's an ingame Header where a Byte must be changed. Most Emulators Play also expanded roms by LunarIPS but it's better you use LunarExpand before applying the patch.

Yepp, making a hook for every theme Change was a pain in the ...a... but I hacked much more difficult things like complete new items and such, e.g.
http://www.zeldix.net/f31-brand-new-items
But I hacked much more even...:
complete patch with most of my work (use the srm in the package to get an idea):
http://www.zeldix.net/f43-the-all-in-patch
(will be updated with the new msu patch as soon verified bug-free).

You can of course take, improve, post, do whatever with my codes as you like. I'm sorry that I'm to sloopy to make a documentation, but with all my hacks I'd write more than code actually ^^

@DoctorDan1986

This comment has been minimized.

Show comment
Hide comment
@DoctorDan1986

DoctorDan1986 Oct 21, 2014

If you want to download my own person version of the patch and audio files, you can do so here:

http://www.mediafire.com/download/07bqz1scl3lvwx2/MSU_Zelda.rar

Apply the .ips patch to the unheadered US version, and extract all the files to the same directory as the patched ROM.

If you want to download my own person version of the patch and audio files, you can do so here:

http://www.mediafire.com/download/07bqz1scl3lvwx2/MSU_Zelda.rar

Apply the .ips patch to the unheadered US version, and extract all the files to the same directory as the patched ROM.

@Conn79

This comment has been minimized.

Show comment
Hide comment
@Conn79

Conn79 Oct 21, 2014

Thanks, I check this file ^^
Edit: sounds awesome! Let's see whether more bugs are found and if you like, I can add the link to your updated file - (Blind bug e.g., was fixed since this Version in your zip, redownload the patch file) on zeldix.net
But first we should wait whether more bugs are found.

Since my last post a missing Music at blind Boss was fixed
(redownload http://bszelda.zeldalegends.net/stuff/Con/zelda3_msu.zip ) but I hope now the hack is completely debugged!

There's an issue left which must most likely be fixed with sd2snes Software. When you pull out the master sword, some People experienced Hyrule Castle theme is played.
Most likely because mastersword theme hex0a=dec10; hyrule Castle theme hex10=dec16
So maybe some sd2snes Versions mix up 0a with 16.

Conn79 commented Oct 21, 2014

Thanks, I check this file ^^
Edit: sounds awesome! Let's see whether more bugs are found and if you like, I can add the link to your updated file - (Blind bug e.g., was fixed since this Version in your zip, redownload the patch file) on zeldix.net
But first we should wait whether more bugs are found.

Since my last post a missing Music at blind Boss was fixed
(redownload http://bszelda.zeldalegends.net/stuff/Con/zelda3_msu.zip ) but I hope now the hack is completely debugged!

There's an issue left which must most likely be fixed with sd2snes Software. When you pull out the master sword, some People experienced Hyrule Castle theme is played.
Most likely because mastersword theme hex0a=dec10; hyrule Castle theme hex10=dec16
So maybe some sd2snes Versions mix up 0a with 16.

@qwertymodo

This comment has been minimized.

Show comment
Hide comment
@qwertymodo

qwertymodo Nov 4, 2014

If anybody is interested, I have disassembled Conn79's final patch and uploaded it here: https://github.com/qwertymodo/MSU1-Zelda

If anybody is interested, I have disassembled Conn79's final patch and uploaded it here: https://github.com/qwertymodo/MSU1-Zelda

@mwreichelt

This comment has been minimized.

Show comment
Hide comment
@mwreichelt

mwreichelt Nov 4, 2014

Owner

Thanks for the link. I'll edit the readme file later today to direct anyone who stumbles across this project to go check out that one.

Owner

mwreichelt commented Nov 4, 2014

Thanks for the link. I'll edit the readme file later today to direct anyone who stumbles across this project to go check out that one.

@mwreichelt

This comment has been minimized.

Show comment
Hide comment
@mwreichelt

mwreichelt Nov 4, 2014

Owner

Looking over the disassembly, I'm wondering why there are so many NOPs in the later functions. I understand the ones earlier in the file are for blanking out instructions that used to change the SPC track, but why the ~12 NOPs here? Or why the 4 NOPs here? I mean, I can imagine reasons, but what's the real reason and why this specific number of NOPs? Is this something to do with the way the SNES' CPU works?

Owner

mwreichelt commented Nov 4, 2014

Looking over the disassembly, I'm wondering why there are so many NOPs in the later functions. I understand the ones earlier in the file are for blanking out instructions that used to change the SPC track, but why the ~12 NOPs here? Or why the 4 NOPs here? I mean, I can imagine reasons, but what's the real reason and why this specific number of NOPs? Is this something to do with the way the SNES' CPU works?

@qwertymodo

This comment has been minimized.

Show comment
Hide comment
@qwertymodo

qwertymodo Nov 4, 2014

I believe Conn wrote his patch directly in a hex sheet, so he included all of the NOPs to give himself room to move code around as he tweaked things. They serve no functional purpose, and can be removed. My initial goal disassembling the code was to recreate his patch exactly (though I did make 2 minor changes in order to get it to assemble in bass), so I left the NOPs. Next up, I'll be running through and cleaning it up, removing the NOPs and hopefully also removing some of the redundant track loading code toward the end. Eventually, I'd like to be able to fit it all back into the original, un-expanded ROM, but we'll see.

I believe Conn wrote his patch directly in a hex sheet, so he included all of the NOPs to give himself room to move code around as he tweaked things. They serve no functional purpose, and can be removed. My initial goal disassembling the code was to recreate his patch exactly (though I did make 2 minor changes in order to get it to assemble in bass), so I left the NOPs. Next up, I'll be running through and cleaning it up, removing the NOPs and hopefully also removing some of the redundant track loading code toward the end. Eventually, I'd like to be able to fit it all back into the original, un-expanded ROM, but we'll see.

@mwreichelt

This comment has been minimized.

Show comment
Hide comment
@mwreichelt

mwreichelt Nov 4, 2014

Owner

Hmm... I had assumed they were there to account for some sort of video blank cycle or something. When I was working on my patch, I remember changing something and getting egregious graphical glitches when I had instructions that took up too many cycles. I assumed it was to avoid something like that.

Owner

mwreichelt commented Nov 4, 2014

Hmm... I had assumed they were there to account for some sort of video blank cycle or something. When I was working on my patch, I remember changing something and getting egregious graphical glitches when I had instructions that took up too many cycles. I assumed it was to avoid something like that.

@qwertymodo

This comment has been minimized.

Show comment
Hide comment
@qwertymodo

qwertymodo Nov 4, 2014

If that were the case, adding NOPs would actually make it worse, because although they don't do anything, they still tie up CPU cycles.

If that were the case, adding NOPs would actually make it worse, because although they don't do anything, they still tie up CPU cycles.

@mwreichelt

This comment has been minimized.

Show comment
Hide comment
@mwreichelt

mwreichelt Nov 5, 2014

Owner

I clearly have a lot to learn about SNES development, but I figured the problem in that video was something was getting out of sync and the NOPs were there to be just long enough to put it back into sync. But from what you're saying that's totally not the case, so I wonder what caused those glitches in the first place is all.

Sorry if I didn't make that clear the first go around.

Owner

mwreichelt commented Nov 5, 2014

I clearly have a lot to learn about SNES development, but I figured the problem in that video was something was getting out of sync and the NOPs were there to be just long enough to put it back into sync. But from what you're saying that's totally not the case, so I wonder what caused those glitches in the first place is all.

Sorry if I didn't make that clear the first go around.

@Conn79

This comment has been minimized.

Show comment
Hide comment
@Conn79

Conn79 Nov 6, 2014

yeah, the code isn't very clean, unfortunately. Initially I had several hooks for every Change of Music one. After tinkering one global code to initialize the msu turned out to serve well enough. Some remains that have no effect on the code are still there, like These nops. But also every hook still has a a9 ff 8d 06 02 which isn't needed as well and can be left out. this volume code is actually only needed here:

Global volume 11/69ca: a9 FF 8d 06 20 – The FF is (max), value 00 would be mute, so choose something inbetween
Map volume 11/6a27: a9 75 8d 06 20 – 75 is half volume as in native Zelda; 11/6a57: a9 FF 8d 06 20 – FF is again max volume when returning back from map
In house volume 11/6a9e: a9 75 8d 06 20 – 75 is half volume as in native Zelda; 11/6a8d: a9 FF 8d 06 20 – FF is again max volume when leaving house

But yes, as I am tinkering directly in hex These artefacts can remain; however they have no influence on the working code so, even if the code isn't much clean I leave them in as too much cleaning tinkering may destroy the code in the end ^^

Conn79 commented Nov 6, 2014

yeah, the code isn't very clean, unfortunately. Initially I had several hooks for every Change of Music one. After tinkering one global code to initialize the msu turned out to serve well enough. Some remains that have no effect on the code are still there, like These nops. But also every hook still has a a9 ff 8d 06 02 which isn't needed as well and can be left out. this volume code is actually only needed here:

Global volume 11/69ca: a9 FF 8d 06 20 – The FF is (max), value 00 would be mute, so choose something inbetween
Map volume 11/6a27: a9 75 8d 06 20 – 75 is half volume as in native Zelda; 11/6a57: a9 FF 8d 06 20 – FF is again max volume when returning back from map
In house volume 11/6a9e: a9 75 8d 06 20 – 75 is half volume as in native Zelda; 11/6a8d: a9 FF 8d 06 20 – FF is again max volume when leaving house

But yes, as I am tinkering directly in hex These artefacts can remain; however they have no influence on the working code so, even if the code isn't much clean I leave them in as too much cleaning tinkering may destroy the code in the end ^^

@qwertymodo

This comment has been minimized.

Show comment
Hide comment
@qwertymodo

qwertymodo Nov 6, 2014

My hope is to clean up the code so that it's more readable to somebody attempting to do the same for another game, so thanks for the insight on things I can probably take out. I'm also working on condensing all of the redundant code at $22EAB0-$22EDD0, since that should be able to be handled as a single subroutine with track selection logic, instead of a separate copy for each track. In any case, I have already committed your final, working version, so that will always be there to go back to as I tinker. That's the nice thing about source control ;)

My hope is to clean up the code so that it's more readable to somebody attempting to do the same for another game, so thanks for the insight on things I can probably take out. I'm also working on condensing all of the redundant code at $22EAB0-$22EDD0, since that should be able to be handled as a single subroutine with track selection logic, instead of a separate copy for each track. In any case, I have already committed your final, working version, so that will always be there to go back to as I tinker. That's the nice thing about source control ;)

@Conn79

This comment has been minimized.

Show comment
Hide comment
@Conn79

Conn79 Nov 7, 2014

This surely is possible. As said you can renounce on all the lda ff / sta $2006 there. Then make a pha before checking whether $2002 is 53 (msu). After this make pla to store it either to only $012c (no msu) $012c and $0130 (msu). You can also check whether all the hooks between $22EAB0-$22EDD0 are necessary anyways, maybe you can renounce on all These hooks (I almost don't think they're really necessary) as $012c and $0130 are coupled and $012c is stored later to $0130 anyways by the native code! This would make the code much more easier and shorter .

If the hooks are necessary you Need to .be careful if there is a stX $012c (0x116b90, you have a txa before the jump).

Also, take 0x116c80, there's a stz $0129. This means is the fairy theme resetted every time the great fairy reappears after throwing something into her Pond. So this hook probably should remain.

Conn79 commented Nov 7, 2014

This surely is possible. As said you can renounce on all the lda ff / sta $2006 there. Then make a pha before checking whether $2002 is 53 (msu). After this make pla to store it either to only $012c (no msu) $012c and $0130 (msu). You can also check whether all the hooks between $22EAB0-$22EDD0 are necessary anyways, maybe you can renounce on all These hooks (I almost don't think they're really necessary) as $012c and $0130 are coupled and $012c is stored later to $0130 anyways by the native code! This would make the code much more easier and shorter .

If the hooks are necessary you Need to .be careful if there is a stX $012c (0x116b90, you have a txa before the jump).

Also, take 0x116c80, there's a stz $0129. This means is the fairy theme resetted every time the great fairy reappears after throwing something into her Pond. So this hook probably should remain.

@qwertymodo

This comment has been minimized.

Show comment
Hide comment
@qwertymodo

qwertymodo Nov 7, 2014

Right now, I'm first trying to understand some of the quirks of the way bass handles addresses. byuu designed bass to be more of a generic, table-based assembler, so getting the LoROM addressing working right is not quite as straightforward as it would be in xkas or some other SNES-specific assembler. Once I get labels working, I'll start poking around with some of this stuff.

Right now, I'm first trying to understand some of the quirks of the way bass handles addresses. byuu designed bass to be more of a generic, table-based assembler, so getting the LoROM addressing working right is not quite as straightforward as it would be in xkas or some other SNES-specific assembler. Once I get labels working, I'll start poking around with some of this stuff.

@mwreichelt

This comment has been minimized.

Show comment
Hide comment
@mwreichelt

mwreichelt Nov 7, 2014

Owner

Do you have some documentation for how to do that in bass? I wanted to use
bass when I stopped working in hex but I couldn't find much guidance on it
so I just used xkas instead.

On Fri, Nov 7, 2014 at 12:46 PM, qwertymodo notifications@github.com
wrote:

Right now, I'm first trying to understand some of the quirks of the way
bass handles addresses. byuu designed bass to be more of a generic,
table-based assembler, so getting the LoROM addressing working right is not
quite as straightforward as it would be in xkas or some other SNES-specific
assembler. Once I get labels working, I'll start poking around with some of
this stuff.


Reply to this email directly or view it on GitHub
#11 (comment)
.

Owner

mwreichelt commented Nov 7, 2014

Do you have some documentation for how to do that in bass? I wanted to use
bass when I stopped working in hex but I couldn't find much guidance on it
so I just used xkas instead.

On Fri, Nov 7, 2014 at 12:46 PM, qwertymodo notifications@github.com
wrote:

Right now, I'm first trying to understand some of the quirks of the way
bass handles addresses. byuu designed bass to be more of a generic,
table-based assembler, so getting the LoROM addressing working right is not
quite as straightforward as it would be in xkas or some other SNES-specific
assembler. Once I get labels working, I'll start poking around with some of
this stuff.


Reply to this email directly or view it on GitHub
#11 (comment)
.

@qwertymodo

This comment has been minimized.

Show comment
Hide comment
@qwertymodo

qwertymodo Nov 7, 2014

byuu walked me through the process. Check out my latest commit, specifically the seek macro.

byuu walked me through the process. Check out my latest commit, specifically the seek macro.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment