I've got it working and love the MSU1 audio. I was wondering is there a way to make the audio work with the ROM having a different name as I would like an original MSU1 version and a ROM hack version with MSU1 too.

You need to rename all pcm files and the .msu file to the new rom name. All files need to have the exact same name.

Ah ok awesome. Thank you! I'll do that.

You can use a bulk rename utility. Pev suggested one once, I used it without issues (really fast in contrast renaming by hand, especially when considering the amount of pcm files used for eb), but de-installed and can't find it anymore. Maybe Pev can help you finding that program.

@Conn The name of the app is Bulk Rename Utility. It pops up right away searching it in Google.

Thank you guys. I'll try the program out and see how it goes.

Conn wrote:
You can use a bulk rename utility

Pepillopev wrote:
The name of the app is Bulk Rename Utility

That's funny in a way

Indeed, I got a chuckle out of that one.

Has anyone else playing on sd2snes experienced a bug where the graphics occasionally flicker in the battle text box?

I've been able to make it happen using Conn's MSU-1 patch as well as ShadowOne's MaternalBound Redux MSU-1 patch. It also occurs in my own WIP rom hack that uses the MSU-1 code in it.

Interestingly, it had been happening with a clean EarthBound rom so I thought it might be sd2snes itself, but I disabled in-game hooks and that resolved it for the clean rom.  

But even with in-game hooks disabled, it still happens with MSU-1 patched roms (although not as often).

As an example, it happens about 18 seconds into this video:



And looks pretty much like this:


Edit: I also went and compiled a version of my rom hack to not include the MSU-1 code and the glitches went away. So I'm almost certain at this point the issue is being caused by the MSU-1.

Also I forgot to mention that I've been able to reproduce this glitch on bsnes, so folks who don't have an sd2snes can test it there to see what I mean.

Ballz wrote:Has anyone else playing on sd2snes experienced a bug where the graphics occasionally flicker in the battle text box?

I've been able to make it happen using Conn's MSU-1 patch as well as ShadowOne's MaternalBound Redux MSU-1 patch. It also occurs in my own WIP rom hack that uses the MSU-1 code in it.

Interestingly, it had been happening with a clean EarthBound rom so I thought it might be sd2snes itself, but I disabled in-game hooks and that resolved it for the clean rom.  

But even with in-game hooks disabled, it still happens with MSU-1 patched roms (although not as often).

As an example, it happens about 18 seconds into this video:



And looks pretty much like this:


Edit: I also went and compiled a version of my rom hack to not include the MSU-1 code and the glitches went away. So I'm almost certain at this point the issue is being caused by the MSU-1.

Also I forgot to mention that I've been able to reproduce this glitch on bsnes, so folks who don't have an sd2snes can test it there to see what I mean.

Hello Ballz, I am Polargames,feel free to call me Polar. To answer your post, it sounds like your wip rom hack has changed the msu-1 break. I am not a expert in this, but I have read and been told that when it comes rom hacks, sometimes they can be a unseen problem. If I were you, I would finish your hack and then if you would want it to be msu'd, Ask Conn politely for what break code he used, then run that threw an snes debugger. That would be the only fix that I could come up with because that would be what can fix it. I hope that answers your post. :-D

Polargames wrote:

Hello Ballz, I am Polargames,feel free to call me Polar. To answer your post, it sounds like your wip rom hack has changed the msu-1 break. I am not a expert in this, but I have read and been told that when it comes rom hacks, sometimes they can be a unseen problem. If I were you, I would finish your hack and then if you would want it to be msu'd, Ask Conn politely for what break code he used, then run that threw an snes debugger. That would be the only fix that I could come up with because that would be what can fix it. I hope that answers your post. :-D

It happens in Conn's original MSU-1 patch, not just my ongoing project.

This is probably due to the nmi stuff to fade the music. Why it occurs during the battle scene is something strange. There is neither a fade, music change or anything possibly trigggering it. Unfortunately, it is impossible to trace sd2snes stuff. What I did in below patch:

Code:


org $C08183
JSL nmi
NOP
NOP

changed to

Code:


;org $C08183
;JSL nmi
;NOP
;NOP

So I commented out the nmi stuff, means there will be no fading of the music. If it works for you (I do not own a sd2snes to test myself) I try to tinker a bit, but there is little I can do. I think fading is more important than this flickering...

Attachments

eb_msutest.zip You don't have permission to download attachments.(1 Kb) Downloaded 1 times

Conn wrote:This is probably due to the nmi stuff to fade the music. Why it occurs during the battle scene is something strange. There is neither a fade, music change or anything possibly trigggering it. Unfortunately, it is impossible to trace sd2snes stuff. What I did in below patch:

Code:


org $C08183
JSL nmi
NOP
NOP

changed to

Code:


;org $C08183
;JSL nmi
;NOP
;NOP

So I commented out the nmi stuff, means there will be no fading of the music. If it works for you (I do not own a sd2snes to test myself) I try to tinker a bit, but there is little I can do. I think fading is more important than this flickering...

That does indeed fix the graphic glitch! But yeah, it then introduces a new issue with a lack of fading.  This is particularly noticeable in certain buildings where the volume is meant to be lowered a couple of dB.

Edit: I have encountered this issue in bsnes as well as sd2snes, so maybe it's possible to do debug it through that?

I'm limited in what I can do to avoid this issue. What I tried in below patch is to shift the code for reading $4210 to the end of the code. So hopefully this debugs this issue. If not there is nothing more I could do.

Attachments

eb_msutest2.zip You don't have permission to download attachments.(1 Kb) Downloaded 1 times

Conn wrote:I'm limited in what I can do to avoid this issue. What I tried in below patch is to shift the code for reading $4210 to the end of the code. So hopefully this debugs this issue. If not there is nothing more I could do.

I just did about a dozen battles with this patch and the glitch didn't appear! I'm going to test it some more later tonight, but I'm cautiously optimistic that this may have fixed it once and for all.

Update: Nope, I encountered it again. I now believe only certain enemies are affected. The Spiteful Crow at the beginning of the game seems to consistently cause the glitch, for example.

Might just have to be something to live with if you're playing on sd2snes...

Too bad. Ah well...

Or higan, or bsnes, or any hypothetical MSU1 implementation on real hardware other than the sd2snes.

ikari_01 wrote:Or higan, or bsnes, or any hypothetical MSU1 implementation on real hardware other than the sd2snes.

Yeah and I am sorry if I singled out sd2snes in particular. In fact as best as I can tell, this happens on any device that is MSU-1 compatible.  I originally thought it didn't happen on Snes9x because that was the emulator I used the most while creating and testing my PCMs but honestly I hadn't really played the game -- grinding, battling, exploring, etc. -- on Snes9x.  

It wasn't until I sat down in front of my TV and popped my sd2snes into my Super Nintendo that I started seeing those blips and thinking to myself, "Huh, that's new..."

Now that I know what exactly to look for I went back and sure enough, it happens on Snes9x as well.

This glitch is no way a dealbreaker for EarthBound MSU-1 projects, and I'm probably now more attuned to spotting it just because it has been such a focus of mine in beta testing the past several days.  Going forward, at least we all now now what it is and why it's happening.

Some technical details as well as a possible solution:

The cause of the glitches is that the game, on rare occasions, re-triggers the HDMA engine just a little bit too late (some place during scanline 0 of the next frame) because it can't manage to do it in time - at the end of the current frame. By then the HDMA counters have started running and it's probably already read some bytes so it is now applying bogus window and main/sub-screen enable values throughout the rest of the frame.

This is good:
c08348 stx $420c [00420c] A:0000 X:0024 Y:0000 S:1fa6 V:246 H:273 F:29

This is bad:
c08348 stx $420c [00420c] A:0000 X:0024 Y:0000 S:1faa V:  0 H: 12 F:31

It is so rare because it only happens when it has a lot of DMA transfers scheduled to perform during blanking, which still complete successfully but then there's not enough time to complete the HDMA setup within the frame.

side note:

@Conn
As far as I can see the HDMA enable "stx $420c" still happens within the NMI routine. So if you could move the long jump to your injected MSU code somewhere after $C08348 it should make the glitch disappear. The rest of the NMI routine seems uncritical, it's just important that the point at $C08348 is reached before the next frame starts.

Had to drop by with all of this on :p
I will follow up on Ikari's possible solution tomorrow perhaps

In the meanwhile, I have been notified that one specific track (22) has a crackle, which I believed waa caused due to my computer fucking up during recording of the wav.

I will repair that one tomorrow, but wanted to ask, what do I do to include the fixed track in the whole PCM pack, Conn?
Should I post it here so the hoster uploads it, or how do I go about it?

@ShadowOne333 Just upload the files you fixed and I will add them to the already hosted pack. Leave a link I will get to them ASAP.

@Ikari: I was assuming this and moved the STZ $420C around in test2 ips above. But this is a good idea, I will try to make the complete jump to msu after this code already was executed. Thanks for this tipp, will try it when I have time later.

@ShadowOne: I can only second Pev here. You can pm him the link to the new pcm and he will update your pack on his host.

Ok, please download and try

http://bszelda.zeldalegends.net/stuff/Con/eb_msu_patch.zip

Differences:
Before I hooked to nmi here:

Code:


$C0/8183 AD 10 42    LDA $4210 
$C0/8186 9C 0C 42    STZ $420C  [$00:420C]


New patch hooks here:

Code:

$C0/8189 A9 80      LDA #$80               
$C0/818B 8D 00 21          STA $2100  [$00:2100]

I cross all my fingers that it works, the chance is good from a logical view

As always the browser history notes. The ips patch size is 575 bytes, changed July, 31 2019. If not, clear browser history and download again.
Also german version has been adjusted.

Wrong place I think, STZ is irrevant. You are still postponing the STX $420c at $C08348.