A quick note, the code I posted before was flawed. You'd also need to find the line:
and add an instruction after it:
(just before the subsequent XBA)
Under normal circumstances, A is already 0 at this point, but adding the code that checks track numbers meant A was still set to the track number instead of 0.Edit:
Just saw your edit. Too much code added to the spot specified means the relative jumps (BEQ, BRA, BNE, etc.) can no longer jump far enough to get over your newly added code. They can only jump over a max of 127 (0x7F) bytes. Including other code already there, there's room for 76 (0x4C) bytes to wedge in new code where you're putting it.
LDA RequestedSong :8 = 2 bytes
Each CMP / BEQ pair = 4 bytes
That quickly adds up to > 76 bytes.
Since you have so many you want to filter, a lot of those comparisons can be merged. For example:
You seem to be filtering 0 through F, so those could be changed to:
Which means compare to #10, and BCC means if less than compared value, jump.
As far as I know, no one has ever messed with SoM's music data. My "Turbo_Song" alternate title screen music is probably the closest, but all that actually is is an unmodified vanilla song with a custom instrument set.
No wait, that's wrong. Mop, who makes the SoM Randomizer (http://secretofmanaancientcave.blogspot.com/
) has inserted new songs. As far as I know, SoM's music format is related to but not exactly the same as other Square titles of the era.
Regarding multiple MSU tracks, that was actually something I had considered, but never got around to it because I figured no one would ever use it. The way it'd actually work would be track number + offset, so to have two tracks for track 1, they'd be named:
For track 2:
(etc., or something similar).
However, I don't know when I'd get around to this. It's not super difficult to implement, but I'm stretched thin at the moment.
Also, see the MSU download in the first post of this thread, it has an option for converting the vanilla SoM music that's included with the 2018 remake.
Aside from altering the SPC music data to adjust volume, it would also be possible to adjust music volume in the gave event scripts that cause them to play. If you search the Turbo ZPS file for "\music===" you'll find hundreds of results. Each is followed by 3 bytes, example:
\music=== 2D 8B FF
2D = track number (in this case the Whalesong)
8B = settings regarding echo, fade time, etc.
FF = first F is initial volume before fade, second F is final volume after fade
Most songs have F (max) as their final volume (though there are exceptions), and many have F as their initial volume as well. You could, theoretically, go through and change all song volumes by changing those. I don't advise it though.
A third option would be to change the code that plays music to reduce or cap the volume level. This wouldn't allow differing volume control per song but would be the most practical to implement.
Hey, your later edit removed the Day_Night_Cycle question, now my response looks like a non sequitur.
Day_Night_Cycle works by timing how long you stay on one screen. If you stay on one screen long enough (roughly 20 seconds: 255 / 12), when you change screens, time will advance by 1 hour. If you change screens sooner than that threshold, the time counter resets, so rapidly changing screens means time won't advance. Other than when sleeping, time only advances by 1 hour when it does. Most game events don't explicitly mess with the time; if time advances it's because the 20 second timer was tripped before a screen change.
There are also time zones, but there's a safety mechanism in place so that if a screen change would cause a time of day change from later to earlier (e.g. morning to night), it won't (time will advance so that it remains morning). Time zones' practical effect is that going east will make time seem to advance faster (fewer consecutive screens at a given time of day) and going west will make time seem slower (more screens of the same time of day). You can witness the time zones clearly when flying (and time doesn't pass when flying).
Upcoming feature, FastROM indicator at the title screen menu.
Typically, it will look like this to indicate it's on as expected (upper right corner, the orange thing):
If FastROM is enabled, but the emulator compatibility detection finds Snes9x 1.36 - 1.43, it will look like this (and sound shouldn't be jacked up):
And just to be thorough, it'll look like this if something went wrong (no one will ever see this unless they do something dumb):