YS V msu

Misty Lake (not raining) isn't playing. It's playing Misty Lake (raining) instead.

Geiger savestate attached, spot 9. Just exit the inn.

I checked the ram Pev uses to determine whether it rains or not and $0274 isn't a good choice. It gets rewritten all time.

What triggers the rain, I can try to look for a better one?
I read a walkthrough, it seems boss dependent? If so, I need two savestates
- where you leave the house (above savestate) but it rains outside
- shortly before the triggerto stop rain (one hit to defeat the trigger boss or whatever)


Edit: here's the intermediate to have 70 and 83 to non-loop

savestates attached:
#8 - go north 1 screen - Raining
#9 - 1 hit from boss death, just walk up and keep swinging the sword, boss will walk into path of your swing, a short scene immediately follows.
#10 - go south 1 screen - not raining

*edit- @Conn Your no loop IPS from the post above this is broken, won't get past the intro screen (aeon-flux image, doesn't make it to falcom's logo)

Ok, this was a bit... hard to trace.
I corrected this code:

yesMisty:
PHA
lda $0407
bit #$08
BNE noRain

Bit 8 is set at $0407 as soon you defeated the boss. I verified throughcheating (7e0407-07: rains, 7e0407-08 no rain.
The patch of course also features the non loop 70 and 83 (from above

@Conn Same as the ys5_noLoop patch, the ys5_misty patch is broken (the IPS' at least).

Exact same way too, the Aeon Genesis screen comes on, starts to fade, and the game freezes on a black screen, before the Falcom logo has a chance to show up. (I think it's freezing as soon as it tries to play the first audio track)

There must be something wrong at your side. For me, I don't have a crash and the misty lake works flawlessly (I double and trible checked).

- try applying the patch on a fresh rom
If this doesn't work, verify the latest code fix is executed, breakpoint with X hook at
9ffd75 bit #$08               A:1013

when misty lake music shall be played. If there is anything different than bit #$08 something went wrong with your patched rom.

I experienced some of these memory troubles in the past with Geiger, it has an old rom somehow saved somewhere. If everything fails you need to rename all your files, e.g., from ys5_msu.sfc to ys_msu1.sfc (along with all the track files and so on).

To be on the safe side from what I can provide, here's again the asm and ips freshly compiled. If all fails we need to wait for Pev to confirm either side. As said, for me it works all.

I used IPS Peek to compare the june14th IPS Pep made (last working IPS on my end), and the NoLoop IPS you compiled (theoretically only 2 bytes difference from June14th one):


As you can see, there's MASSIVE differences in the IPS's.

No idea. I didn't change anything more than that what I wrote (and the asm fixes I made were little, there cannot be so high differences).
My unaltered rom name is
"Ys V - Ushinawareta Suna no Miyako Kefin (Japan).sfc" but I am not sure whether I applied an english patch (I should since my version is english as well.

I sent you my rom per mail, so you can try the last changes with it (your savestate are loadable). For a working patch compatible with your rom, you either need to compile the asm yourself with xkas, or you wait for Pev then.

https://www.diffchecker.com/e7CAZQVx
And this shows that the ASMs are how they should be for that change.

The only thing I can think is the "@ $9ffc10" in the commented section of line 65 on the noLoop ASM is mucking up the compiling somehow, since that's the only change besides the looptable.

*edit- that "@ $9ffc10" bit was also removed from pep's IPS he compiled from your Ys5_68 ASM (the one to fix the double-play of the transporter SFX), so that's looking more like the culprit.

I applied Pev's last patch and my new one and compared. Pev's ips is much larger but has no other effect on my base rom than my new one, means Pev has another base rom, the same alike yours.

Check your mail (*1@gmail.com) and see how it works. Other than that, you really need to use the asm or wait for Pev. I do not know what's wrong with my base rom so the patch is so much shorter.

My base ROM already has the latest Aeon English ROM patch already applied prior to ASM compilation. This most likely may explain the size difference. I don’t have access to my PC yet at the moment.

@Conn OK, the ROM you sent me works.

I replied with a copy of the English-patched ROM (no MSU patch applied) both me and pep have.

Alright, with the base rom you sent, I got a similar ips size. Attached is the version that should now work with your base roms

And that IPS works perfectly. Problem solved.

And yet another reason I rarely, if ever, download pre-patched ROMs; instead patching them myself. Compatibility nightmares, lol.

This is why I prefer BPS over IPS, for this reason. BPS will let you know something does not match.

@Conn @pepillopev If one of you has some free time, I'd appreciate it if one of you could trace this back for me.

The sandstorm track ($3A) is called 4-5 times in the game, every time but one is in the middle of the desert, the first time it's called though, you're on a raft on a river. I'm hoping to split the calls so that the call for $3A when your on the raft pulls up a different track instead.

I did something very similar in FFVI where I traced where the call for one track was coming from, then hex-edited that location in the ROM to a different track ID, letting me change the town theme for a town that was riddled with music-related event code, without changing the other towns that used that theme's music. (http://www.romhacking.net/forum/index.php?topic=25397 for more info on what I did in FFVI)

Hoping it would be just as simple (find the command that writes 3A to the A register, then follow the RAM address that got loaded from to see where it got the value from, etc. until I finally got back to an address I could map to the ROM).

Sadly, the coding on this is WAY beyond my meager (read non-existent) understanding of 65816 assembly, and I can only figure it out going back 1 step to where 3A is copied from the X register to the A register, and I can't figure out how it gets to the B register...

https://mega.nz/#!SNZX1DhJ!f_RvU5amItnCumy7soy1n9iODEZT-T8fWamBMjM3rEc
That's the 2-3 second trace I did, it's roughly 2.16 million lines long though, so don't even try opening it in notepad (it'll crash), use Notepad++.

Attached is a Geiger savestate right as you're getting on the raft, shortly before Sandstorm is called.


Basically, I want to change the single byte in the ROM where track 3A is called, changing it to a different (unused) value (probably $85). Hopefully this won't affect the other calls for track 3A.

Change at pc address
0x12f1e: 3a -> xx (xx = new track number mapped, like 85?)

There are 2 similar calls, maybe you are lucky and the desert calls use completely the other 3a call. You need to test that!

If this is safe (desert uses completely the other 3a call), we'd only need to add

Code:


org $82AF1E
db $85

to the asm

Conn wrote:Change at pc address
0x12f1e: 3a -> xx (xx = new track number mapped, like 85?)

There are 2 similar calls, maybe you are lucky and the desert calls use completely the other 3a call. You need to test that!

If this is safe (desert uses completely the other 3a call), we'd only need to add

Code:


org $82AF1E
db $85

to the asm

Awesome, I'll test the change out and see if it affects just the one call, or if it affects other calls for 3A as well.

Edit- Well... Looks like this is a bust.

I made the 1-byte change to the ROM, and it changed the PCM called correctly, but... The actual sandstorm and related events never started, leaving Adol floating on a raft with clear skies and a stormy soundtrack indefinitely, dead-ending the game.

There must be a call in the event code somewhere checking for the 3A value, that fails, so the events never trigger.

*edit2- It doesn't appear to interfere with the calls to Sandstorm in the ending at the very least.

Try this (hopefully this was the last extra wish...) - the raft 3a is mapped to 85. This would only work if the desert uses the other code as you said in edit2

@Conn It plays track 3A on the raft.

With the breakpoint at writes to $2004, I can see the write of 85 to A, but it  quickly is changed to 903A.

https://pastebin.com/bAp53wgw
Here's the code running between the write of 85 and the write of 903A.

Funnily enough, if I hexedit $12F1E from 3A to 85, it doesn't freeze anymore, but it still plays the normal sandstorm track.

Oh, and I'm only checking vs the times sandstorm is called in the ending atm, I don't have a savestate near the other times it's called in-game.

*lol, that f* security play check took over here

Check this out.

@Conn Alrighty, looks like it's working, New track plays on the raft, normal sandstorm track in the ending.

All that's left to do is finish my playthrough and make sure the other in-game calls to sandstorm are still calling 3A.

Thanks for the work on this Conn, it was a minor nitpick but it didn't feel right not having wave sounds on a storm on a river.

Yeah, those exceptions usually cause much trouble... I hope we are able to finish up the game now

Please also do some more tests, since I also hacked in the securityplay routine if adol, farwell and the others are still playing. They should (I tested the code run) but it is always better to double check.

@Conn And problem.

After beating the Oasis area, and returning to felte town, when the guy is giving you the tunnel key, instead of gaining the key and playing the item get jingle... it restarts the game, though the music keeps playing for a few seconds on the Aeon Genesis screen.

Scene works fine in the version of the patch before the sandstorm track changes.

Geiger savestate attached, just enter the town to the left to start the scene.

*gosh, this nitpicking request gets really awful.
I made a complex way round. I wrote $85 for $3a to be able to set a flag, then rewrite it again to 3a so the game doesn't crash.

See how it works, if not there's little more I can do and we have to stick to the old version