[Super Game Boy] Pokemon Generation 1 MSU1

Yes, the wait busy is missing.
@Zumi, the fxpak needs a while until it has the track loaded.

You need a wait busy loop between sta $2004 and sta $2007

001893 lda $001803 [001803] A:9003 X:0002
001897 sta $2006 [012006] A:90ff X:0002
00189a ldx $1801 [011801] A:90ff X:0002
00189d stx $2004 [012004] A:90ff X:0003
insert loop code here
0018a0 lda $001804 [001804] A:90ff X:0003
0018a4 sta $2007 [012007] A:9003 X:0003
0018a7 bra $18cf [0018cf] A:9003 X:0003

The wait loop is simply this:

Code:


waitloop:
   Bit $2000
   BVS waitloop

or alternatively (e.g., if DB:7f):

Code:

   waitloop:
      LDA $002000
      AND #$40
      bne waitloop

Thanks for the tip!

I thought simply skipping MSU1 track processing entirely should be enough when it detects that the MSU1 is busy... either way I'll put track locking as you demonstrated (along with bug fixes) and see if the problem is resolved by the next release.

P.S. Would that still help if I changed bit.b #%10000000 to bit.b #%1000000 on the "single" busy check? I just realized that the typo makes it check for the DATA_BUSY bit, not AUDIO_BUSY.

(or would that still help if I changed bit.b #%10000000 to bit.b #%1000000 on the busy check? I just realized that the typo makes it check for the DATA_BUSY bit, not AUDIO_BUSY)

I did not work myself into your code but I think not. You see, you store a track id to $2004, and reset $2005, to tell a new track has been introduced.

In this moment the sd2snes loads the new track which takes some frames (2-3 usually). Only THEN you can make the track play command to $2007.


The problem is that this waitloop here can cause flickering so your nmi check is basically a good thing... but I think you need to rewrite it maybe:

sort of pseudocode

// play a song
stz   {MSU_VOLUME}
ldx   i_track_number
stx   {MSU_TRACK}

Sta flag that new track is introduced
bra end

Then after introducing a new song you can check like

If new track is introduced flag set
lda   {MSU_SEEK}
and.b #%01000000 //#$40
bne   .skip
lda   i_play_mode
sta   {MSU_CONTROL}
lda i_volume
sta {MSU_VOLUME}
bra   .reset_flags

Damned, I forgot another tip,
Make a stz $2006 (or stz $2007) before writing to $2004
And then, when writing to $2007 give the full volume ($2006-#$ff).

If sd2snes has full volume when loading a track it will give a really aweful scratching noise

How's this?

The MSU1 status checking is already handled at the beginning of the interrupt routine, and skips the whole thing if the MSU1 is still busy

I am not sure (I usually do not work with bit and bit.b), but if I understand correctly:

Code:

lda.b #%10000000
 sta   i_ask_restart // set 'new song loaded' flag

You store #$80 to a new track introduced flag

Code:

bit.b #%10000000
 bne   .load_new_song // load a new song if bit 7 is set

Here you test the bit 7 (#$80), and if set play the new song

Code:

.load_new_song:
 lda   i_play_mode
 sta   {MSU_CONTROL} // set looping mode
 
 lda   i_volume
 sta   {MSU_VOLUME} // set track volume

 bra   .reset_flags

Here you reset the flag if the play command is given.

I am not sure if there is a logical error.

Code:

lda.b #%10000000
 sta   i_ask_restart // set 'new song loaded' flag

This is correct, you set the flag in case new track has been introduced

Code:

bit.b #%10000000
 bne   .load_new_song // if flag is set, proceed to play the new song


correct, play command if new song is introduced

But here is an error in my opinion:

.load_new_song:
       BIT {MSU_STATUS} //you need to check if the track is ready
   BVS .skip //if not skip (overflow flag is set)
lda   i_play_mode
sta   {MSU_CONTROL} // set looping mode

lda   i_volume
sta   {MSU_VOLUME} // set track volume

bra   .reset_flags

I see you have this check here

Code:

lda   {MSU_STATUS}
 bit.b #%01000000
 beq   .continue

But I think this is the wrong place, e.g. the fading will not work (since the track is loaded). This must come where I marked in red in above post (this does the same as the bit $2000 bvs+):

So if I understand your fix, I should just need to check MSU_STATUS upon track load?

(And TIL about BIT used in this way, I come from a GBZ80 background so I kinda used the 65816 as I would with it ^^; )

yes, at least I only do it there. Sometimes I make an error bit test (lda $2000 And #$08) to play spc music but I don't know if this can be done in SGB.

I think before you had at this place a

Code:

   lda  {MSU_STATUS}
   bit.b #%10000000 //And #$80
   bne  .skip   

This isn't necessary (at least I never did this check for Data busy), so you can delete this code and just make the AND #$40 check (or bit $2000 bvs) at the place where I marked it

Here goes another release lol
Hopefully it should fix the issue with FXPak and stuff

The PCM pack included has Pokemon Red file names, I'd upload the Blue pack (it's the same thing anyway) but it's getting late lol

MEGA folder (2020-10-26): https://mega.nz/folder/dPYXnaZC#1zDdHs2nmKL4Dd46ygxeQA
MEGA folder (all releases): https://mega.nz/folder/NPgWUIbT#SGNqtrZWlb-u8oormOrddg

Source tree: https://github.com/ZoomTen/pokered-sgb-audio/tree/msu1

On FXPAK. There was a small Bug Noise when
- Skip to Title Screen.
- Start New Game.
- Load a Save Data.
- After Prof. Oak Intro.
- Rival Appears Music starts.

Progress, FXPak works

The problem should be this code:

Code:

lda   i_force_volume
 cmp.b #0
 beq   .reset_volume // don't force volume when forced volume = 0

This flag (i_force_volume) is never set or cleared, so you always go here (if not fading):

Code:

.reset_volume:
 lda   i_volume
 sta   {MSU_VOLUME} // reset msu1 volume

.process_audio:
 lda   i_ask_restart

The reason why the buzz appears is following, you stz $2006 when introducing a new track, but immediately set it to FF again in the next frame (while on FXPak is still in audio busy mode, causing the buzz).

Also, the current code makes a STA $2006-FF EACH frame, which is not good!

Possible solution:

lda   i_force_volume
cmp.b #0
beq   .reset_volume // don't force volume when forced volume = 0

instead simply
bra .process_audio:

The volume is set with a new track introduction or with the play command

Ah guys. I think it will be preferable to enhance french versions into MSU-1 but by beginning in first with Red & Blue versions (Pokémon Rouge and Pokémon Bleue in french) and then, Pokémon Yellow (Pokémon Jaune Édition Spéciale Pikachu) instead of the enhancing the patch of the french version's hack of Pokémon Yellow into MSU-1

Conn wrote:This flag (i_force_volume) is never set or cleared

It gets set/cleared when the GB ROM sends a SGB packet affecting it, though I do agree that setting the volume every frame is definitely janky as hell lmao

I guess I could manage it by making a "ask volume bit" at $1800, and *only then* will it set the volume, especially since fading takes precedence anyway

Pardon the doubleposting, but how's this?

It looks good but I cannot compile it (gives blank screen if I try with xkas 14+1). Can you compile it so we can test whether the buzz is gone?

Conn wrote:It looks good but I cannot compile it (gives blank screen if I try with xkas 14+1). Can you compile it so we can test whether the buzz is gone?

Yeah, it is simply raw patch code. I'll incorporate this into the next "release"

Try now perhaps?

Also I think I fixed the looping in track 13, I got trim_end and loop swapped ^^;

MEGA folder (2020-10-27): https://mega.nz/folder/gfB1SQJL#Zf3-Fr3TDEc3OwuEwebwHg
MEGA folder (all releases): https://mega.nz/folder/NPgWUIbT#SGNqtrZWlb-u8oormOrddg

Source tree: https://github.com/ZoomTen/pokered-sgb-audio/tree/msu1

I traced (also with simulating FXPak (if overflow is set)) and it looks all nice, I think that's it now, but we should wait for the ABOhiccups report

Tested on SD2SNES Pro. No buzz while changing tracks!

MSU1 Audio is not playing after being defeated by Wild Pokemon or Trainer to send you back to Pokemon Center or your Mother's House (where your Pokemon was last recovered from). MSU1 Audio will go back to normal after enter inside Building with different theme or enter new area.

Fixed some event stuff and *hopefully* the glitch you described

MEGA folder (2020-10-29): https://mega.nz/folder/4SQDASSS#XLb1M9t_0Wa2y3l8sMoT7g
MEGA folder (all releases): https://mega.nz/folder/NPgWUIbT#SGNqtrZWlb-u8oormOrddg

Source tree: https://github.com/ZoomTen/pokered-sgb-audio/tree/msu1

It's perfect! No bugs found! Next up, Pokemon Yellow!

Zumi Are you hosting PCM Packs? If you are. Can you change Lavender Town Track from Pokemon Origins to Let's Go Pikachu and Eevee in Anime Pack? Or if you happen to found Lavender Town Theme that sounds a lot better for Anime Pack.

Awesome
@zumi, if you think you are done (or only small bugs remaining), please post it into the database:
https://www.zeldix.net/f71-msu-1-hacks-database
If you make that entry you can edit yourself if there are further updates, just please stick to our format (presentation video - Patch link - pcm link).

I am not sure where it belongs to, I'd think RPG: Round-based?

Conn wrote:Awesome
@zumi, if you think you are done (or only small bugs remaining), please post it into the database:
https://www.zeldix.net/f71-msu-1-hacks-database
If you make that entry you can edit yourself if there are further updates, just please stick to our format (presentation video - Patch link - pcm link).

I am not sure where it belongs to, I'd think RPG: Round-based?

Zumi has to finish Pokemon Yellow first before publishing it.

Can somebody clear me up here? The internet is not really clear on all these versions. So red/blue are SGB, is yellow only the japanese version SGB (and the other GBC/SGB), what about gold/silver... it says they are also SGB. So all versions compatible with SGB+MSU1 are red/blue/yellow/gold/silver, is this correct?

@zumi, if a game is gbc only (like crystal), it cannot be run on SGB. Are you going to port your code for all sgb compatible versions (red,blue,yellow,gold,silver)? Are there even more versions?