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 - Madsiur

Pages: [1]
One warning, I noticed you're storing a lot of state variables in $7E1xxx. That's safe most of the time but FF6 craps all over that area of RAM during the ending sequence, which is part of why I laid my variables out partly in there and partly in $1Exx. When I relied on memory in the $7E1xxx block earlier it caused repeated restarts of the ending theme due to not being able to properly check if it was already playing.

$7E0000-$7E1FFF is a mirror of $000000-$001FFF and $001600-$001FFF is save ram, so those unused SRAM bytes are ok to use, unless my info on free SRAM was not accurate. Really the only reason I used it this way is because CT MSU-1 hack had it laid down this way and I did not changed it. Anyway in bass doing a STA.w or LDA.w on a 3 bytes variable result in assembling LDA or STA $1EXX (high byte is ignored). And since majority of time DB is set to $00 in FF6, it write and read  from/to $001EXX.

I'm not sure how far you wanted to go with your version or if you wanted to contribute the code directly to the project, but provided you can reach feature parity with current code without any regressions (look at the closed bugs on github), I'd be more than willing to incorporate this version of the patch directly into the project. If you'd rather keep it a seperate project that's cool too. If you're contributing this as is with an eye to me finishing it up, I'm alright with that idea too but it'd take me a while to get truly comfortable with this codebase.

I'll keep this version of the hack for an "enhanced audio" mod I plan to do (some music related mod with Ocarina of Time elements). I find it much simpler dealing with relevant SPC commands ($10 for play, $14 interrupt, $81 fade in/out and the subsong one used for Dancing Mad song) and include extra ones as each "bug" is encountered. But I labeled all SPC command used in game there are 7 or 8 but 2-3 of those are still unknown to me as for their effect. But really this approach and hooking the MSU-1 routine to the calls to $C50004 rather than in $C50004 was easier for me because I was at ease already with FF6 music code and knew a majority of the hooks already.

But you are really close to your goal, I would prefer forking your project on Github and make a separated branch for the fading only and then have people test the thing deeply (because I am a bad tester that don't spend enough time testing) and after submit a merge request to be in the official release when we are sure it is fully compatible and working. It will be a good way to learn WLA too. Howevere I'm busy with university project and finals until end of April so I can't guarantee a short integration in time of the fading code.

So I've played a bit with this and started my "own" implementation just for fun, taking your project and more heavily DarkShock's CT MSU-1 code as a base. I implemented fade-in fade-out and it's the reason of this post. After some tests, there is no battle slow down, same for regular maps. The only fade test that was done is with the "wind song" I created with a WAV wind sample in the intro that is faded-in with event command $F1 and faded-out event command $F2. You can get my .asm file here. The $C2 .bin file included is there to make the .asm file compile because there are SPC routine hooks in the compressed intro code. You'll need bass to assemble the code.

First the code will look for SPC command $81. Following FF6 code logic, at that point on a fade-in the song should be already playing at volume $20, since there is 2 calls for a fade-in; first with SPC comand $10 and volume $20 and second with SPC command $81, $1301 being the fade speed (#$00 to #$FF) and $1302 expected max volume once fade completed (#$FF as far as events are concerned). On a fade-out parameters are the same except expected volume is usually #$00. A check is made for volume #$00 to label the action as a fade-out (and otherwise a fade-in).

In the .asm file, msu_prepareFade is called on SPC command #$81. The fade counter is initialized and the fade steps required is calculated (in msu_computeFade). The rest is taken care in the NMI loop (msu_updateLoop), where a frame counter check fading every two frame and does necessary calculation on volume and decrement the fade counter. Most of this logic is DarkShock's work, I mainly adapted his code and added the fade-out logic based on the fade-in one.

I'm not sure if code could be improved and it does require more testing but it's a good first step IMO and it does seems to work properly.

Thanks for this quick fix. I'll test this tomorrow.. and sorry about the typo D8 instead of D2 if it was misleading, I kinda assumed it was hex when writing my post, I even debugged the thing before this and I was in the correct bank lol.

On a side note I was partially wrong about the FF6 ROM always using $C0 as a base, the only case I've found in original ROM is the NMI hook (JSL $001500) at C0/FF10 and some bank $C3 function that queue function calls by code and do not use and bank number based on $C0.

Well... Insidious knows what you're talking about, lol.

Good news! To answer his concern, all ASM instructions in vanilla FF6 code use HiROM notation, as an example there is never something like JSL 186040 but always JSL D86040. Same goes for all instructions requiring a bank byte (3 bytes offset).

And I don't know if the mod is using HiROM or LoROM notation, but I know the mod works with the Ted Woolsey Uncencor patch, which has a 4MB expanded ROM (which I think you're explanation earlier said would mean HiROM).

A regular FF6 ROM or one expanded to 4MB is HiROM + FastROM type. Once you expand beyond 4MB to like 6MB, you need ExHiROM mapping change because you now need and can access banks $40 to $5F, that are the continuation of $C0 to $FF ($00 to $3F in LoROM / absolute format). I'm no expert in ROM mapping so I'll stop here :P

So if I'm understanding this right (I'm not, lol), the patch is coded with LoROM, so it won't work with ExHiROM (but does work with HiROM?) patches? And if Insidious changes the ASM coding to HiROM, it'll work with all other patch types?

It is something like this... Bank $D8 can be accessed with $18 or $D8 on regular FF6 (I guess loROM work on HiROM) but ExHiROM can only deal correctly with $D8.

Opened a new issue at:
This is far beyond what I know about, we'll see what Insidious says.

Thanks man! Yeah my message was aimed at insidious, I had the impression he visit daily or so this thread. Basically using HiROM notation for long instructions (bank number + 0xC00000) will make the mod work on every FF6 carts and roms possible, regular FF6 ROM type (HiROM + FastROM) or expanded 6MB ROM type (ExHiROM). I don't fully understand the technicalities underlying the mapping differences between both rom types but I tested both versions on debugger emulator and made a fix after seeing the JML instruction not jumping where it should.

Since he coded this with an ASM file it could even be something not wanted in the first place but that was working with vanilla FF6 ROM type. As I said no instruction in FF6 use absolute bank notation, it's all in HiROM notation.

Nice work on advancing the Beta to an almost final stage!

I tested the mod on a FF6 ExHiROM mod (RotDS more specifically) and the ExHiROM mapping break some instructions more specifically the way you coded JMLs and such. As an example JML 18FA72 will work but an ExHiROM cart or ROM will require it to be JML D8FA72 in order to jump at the same place. I'm not sure if there is an advantage to use first notation but while it work on regular HiROM + FastROM carts and ROM, it breaks on ExHiROM carts / ROMs.

I got the mod working by changing all bank bytes of all problematic instructions, what is to check are JML, JSL, LDA XXXXXX, etc. In vanilla FF3us, all instructions use the HiROM notation for banks.

I'll try to fiddle with the fadeout NMI code soon, I know you tried stuff but I'll try a few things, somebody will get it right eventually!   ;)

I'm not sure if you saw my post on RHDN but I tried a few weeks ago to implement fade in/out with result of some lags on the dungeons or town maps. I've used CT fading routine bt with some extra stuff that was not necessary I think. A simplified version of the MSU-1 update loop could look like this. I think it worth a second try, but I don'T think I'll have the time really soon to test it:

Code: [Select]
rep #$20
lda fadeCount
beq .CallNMI
sta fadeCount
rep #$20
lda fadeVolume
adc fadeStep
sta fadeVolume
sep #$20
lda fadeVolume+1

rep #$20
jml $001500

Hey, always glad to have another eye on the code. And thanks so much for the commented disassembly, this may help, even if just in implementing a single-case workaround.  This project has been literally my first time doing anything serious in ASM, and my first time doing anything with the SNES, so the more the merrier as far as eyeballs. Feel free to submit a patch if you've got a really clever idea.

I will look into this soon. There are other uses of this event command but I'm not sure if it would affect the song selection elsewhere in your MSU-1 hack.

I've already tried messing with the NMI a little, and yeah, it's *really* tight, and I feel like I'm nowhere near good enough at optimization to touch that atm. I've tried with a variation of mlarouches code and got massive corruption, so clearly CT is much looser as far as how much "extra time" you have during the NMI.

I've never messed with NMI but using an unused RAM variable during the event code to store the fading (0 = song isn't fading, 1 = fade song) and checking the actual volume (0 = fade up to max, max = fade down to 0) *might fit* during NMI. I guess the only way is to try it. That's something that interest me enough to pass some time on it. I'll report back in a week or two.

As for a perpetual beta phase, that's ok as long as there is room for improvement. There can't be a definitive version since more orchestral remix or enhanced OST might see the light of the day sooner or later. Your project has interested quite a few people that have a FF6 hack in development in hope of implementing their own hi-quality OST.

I'm really stoked by the progression of this project!

I had a look at your tracker and the Figaro bug intrigued me. I have little knowledge of bank $C5 code, but know fairly well event stuff. I can't tell if it's the exact cause of the bug, but the flashback event use command $F2 (fade out) and $F3 (resume from pause). Note that the resume command has two jumps to $C50004 and it seems in both command $1301 plays another role than song ID (I'm 100% sure $EB is a fade in/out speed). Maybe the code will help you understand. I can't suggest anything to change in bank $C5 to cover those cases.
Code: [Select]
Fade out current song with speed xx (higher == slower)
(gen. act. F2)
C0/B811: A981    LDA #$81 ;spc command (fade in/out?)
C0/B813: 8D0013  STA $1300
C0/B816: A5EB    LDA $EB ;fade out value (from event code)
C0/B818: 8D0113  STA $1301 ;NOT the song ID
C0/B81B: 9C0213  STZ $1302 ;goal volume (0)
C0/B81E: 220400C5 JSL $C50004 ;play the song (fade out)
C0/B822: A902    LDA #$02
C0/B824: 4C5C9B  JMP $9B5C

Continue song that was previously paused, xx is fade in speed
(gen. act. F3)
C0/B827: A910    LDA #$10 ;expected command is $10 when silence (or no song?) is currently playing like after a fade out
C0/B829: 8D0013  STA $1300
C0/B82C: AD0913  LDA $1309 ;previous song
C0/B82F: 8D0113  STA $1301 ;store as song ID to play
C0/B832: 8D801F  STA $1F80 ;store as current song in SRAM
C0/B835: 9C0213  STZ $1302               ;initial volume (0)
C0/B838: 220400C5 JSL $C50004 ;maybe this just restart the song before the fade in?
C0/B83C: A981    LDA #$81 ;spc command (fade in/out?)
C0/B83E: 8D0013  STA $1300
C0/B841: A5EB    LDA $EB ;fade in speed (from event code)
C0/B843: 8D0113  STA $1301 ;NOT the song ID
C0/B846: A9FF    LDA #$FF ;goal volume (full)
C0/B848: 8D0213  STA $1302     
C0/B84B: 220400C5 JSL $C50004 ;play the song (fade in)
C0/B84F: A902    LDA #$02
C0/B851: 4C5C9B  JMP $9B5C

Finally if you plan on implementing the fade in/out feature during NMI, "adding more than ~70 cycles will start causing major graphic glitches" (quoting a hacker that modified the routine for other purpose). FF3 NMI is pretty tight. You may check if someone like mlarouche has a similar implementation in one of his hack. Thank you so much for making your ASM file and code public! I'll have a better look at it this week!

I'm really interested by this project! Good work so far!

I was thinking implementing MSU-1 in FF6 myself, but since you started this project, I was hoping I could use your project as a base for mine (a more extensive hack). I have two question:

1) Have you succeeded in  hijacking the NMI routine in order to fade out tracks? A guy on a FF6 hacking forum reported the same graphical glitches when trying to implement MSU-1, I wonder now if it's possible to implement fading out with the NMI routine...

2) A number of event commands are use for song. Did you modify any or all of them? Here's the list. They are use in event sequence:

Code: [Select]
#  Bytes  Description
EF : 3    : Play song A with volume B. Song is actually A AND $7F. Bit 0x80 is unknown.
F0 : 2    : Play song A, full volume.
F1 : 3    : Fade in song A, with transition time B.
F2 : 2    : Fade out current song with transition time A.
F3 : 2    : Fade in previously faded out song with transition time A.
F6 : 4    : Song tweaking, with various subcommands on first parameter. (not sure if can be applied to MSU-1)
F7 : 1    : End most recent loop of currently playing song. (not sure if can be applied to MSU-1)
F9 : 2    : Pause execution until music passes through point A. (Needs investigation, I'm not sure how that actually works).
FA : 1    : Stop temporarily played song.

Once again, Good work!

Pages: [1]