BlackVega wrote on 2025-07-04, 17:31:

Please see Cosmo Police Galivan: https://vgmrips.net/packs/pack/cosmo-police-g … -police-galivan […]
Show full quote

OPLx wrote on 2025-07-04, 14:34:

Could you point me to the VGM data does it not work correctly on? That way I'll have something to validate against when I have a large block of time to look into the issue. Thank you.

Please see Cosmo Police Galivan:
https://vgmrips.net/packs/pack/cosmo-police-g … -police-galivan

All tracks sound a little off at times. I suspect other tracks from games from the same developer will do the same. Also some tracks from Duke Nukem 2 hang the system completely

I can use the Cosmo Police to figure improve things. Since there are twenty of them, do you mind telling me which Duke Nukem 2 tracks cause your system to hang? I'll try to look at these as soon as I can. Thank you.

OPLx wrote on 2025-07-04, 22:16:

BlackVega wrote on 2025-07-04, 17:31:

Please see Cosmo Police Galivan: https://vgmrips.net/packs/pack/cosmo-police-g … -police-galivan […]
Show full quote

OPLx wrote on 2025-07-04, 14:34:

Could you point me to the VGM data does it not work correctly on? That way I'll have something to validate against when I have a large block of time to look into the issue. Thank you.

Please see Cosmo Police Galivan:
https://vgmrips.net/packs/pack/cosmo-police-g … -police-galivan

All tracks sound a little off at times. I suspect other tracks from games from the same developer will do the same. Also some tracks from Duke Nukem 2 hang the system completely

I can use the Cosmo Police to figure improve things. Since there are twenty of them, do you mind telling me which Duke Nukem 2 tracks cause your system to hang? I'll try to look at these as soon as I can. Thank you.

Some OPL2 rips, including Duke II and Alone in the Dark are known to hang on certain VGM players as the rips use the "opl2 wait" command. I don't know technical details, but this was fixed in MAmidiMEmo by simply adding a function to ignore it.

SuperDeadite wrote on 2025-07-04, 23:00:

Some OPL2 rips, including Duke II and Alone in the Dark are known to hang on certain VGM players as the rips use the "opl2 wait" command. I don't know technical details, but this was fixed in MAmidiMEmo by simply adding a function to ignore it.

I played through all the VGMs in Duke Nukem II and there was no crash. Sadly, I won't be able to analyze what the source of the problem is.

OPLx wrote on 2025-07-05, 13:42:

I played through all the VGMs in Duke Nukem II and there was no crash. Sadly, I won't be able to analyze what the source of the problem is.

Oh darn it does in fact work but I need to bypass DOS=HIGH,UMB and after that track 05 from DN2 plays fine! 😮 But once I enter a filer (FILMTN) and play it from there then it plays a single note and crashes with EMM386 saying "EMM386 has detected error #12 in an application at memory address 7DE9:EB43.". Darn how I hate using MS-DOS sometimes...

I was doing some computer maintenance when I noticed that SBVGM would say that the YM2151 of the Golden Axe VGM dump was at 4mhz. Then I checked on the SAAYM and the jumper was to 3.58mhz so I set it to 4mhz. Now I'm not sure if it's the placebo effect but the sound seem less muddy. I then wanted to make sure the SAA1099 CLK where correct too and noticed SBVGM reported something about 3.79540 which is more in par with the 7.16 settings on the card. I set it to 8mhz setting out of curiosity and was in the impression that some instruments in the music where maybe out of pitch, but again, is it just an impression ?

It is not very convenient for me to record and compare now so if someone could please advise on correct settings, this wold be much appreciated. Thank

ElBrunzy wrote on 2026-03-16, 21:31:

I was doing some computer maintenance when I noticed that SBVGM would say that the YM2151 of the Golden Axe VGM dump was at 4mhz. Then I checked on the SAAYM and the jumper was to 3.58mhz so I set it to 4mhz. Now I'm not sure if it's the placebo effect but the sound seem less muddy. I then wanted to make sure the SAA1099 CLK where correct too and noticed SBVGM reported something about 3.79540 which is more in par with the 7.16 settings on the card. I set it to 8mhz setting out of curiosity and was in the impression that some instruments in the music where maybe out of pitch, but again, is it just an impression ?

It is not very convenient for me to record and compare now so if someone could please advise on correct settings, this wold be much appreciated. Thank

While it is possible to detect the clock that the SAAYM is using, SBVGM just assumes that it's set to 3.579545 MHz and handles the internal frequency conversions. Unlike the other OPLx chips, the way to set the frequency on YM2151 is an indexed value that corresponds to the desired note to play (not the actual frequency value) so there is a change that things won't sound as correct. While it's not official, generally for "PC" settings 3.579545 MHz for the YM2151 and 7.15909 MHz for the SAA1099 are the correct defaults. Especially in the case of the SAA1099 since the GameBlaster uses a 7.15909 MHz clock.

I believe the SAAYM was a result of the early work TexElec did while designing what would end up becoming the Commander X16's sound system. Initial designs were going to use the SAA1099 chips, but that was superseded by VERA's PSG core which has features the SAA1099 lacks.

I should probably find some time to support the SAAYM at different clock settings and use an environment variable to determine what they are.

Thank you OPLx for your quick and precise answer ! There goes my career as a piano tuner with that post 😅 So now I blame placebo effect and those cheap small monitors I use to test if audio work. I'm not sure I understand correctly the implication of changing the frequency of the YM2151 and SAA1099, I assumed it would change the speed at which they operate hence change their pitch. But apparently it is not the case, maybe it change the speed at which they pickup and treat data, a bit like a bus speed thing. Oh well, dont feel the obligation to explain anything, I would not want to be of any burden. Maybe when it will be more convenient I could do comparison recording and hopefully understand it better. In the meantime I appreciate you told me about the correct setting to use.

Honestly, I think your time could be more well spent than adding support for different speed of the YM2151. I'm not aware of any other PC implementation of the YM2151 and I'm not even sure why there is a jumper to change speed of those chip on the SAAYM now. It just puzzled my mind to see that 4mhz tag info in SBVGM for those VGM files and that the SAAYM was set at 3.579545mhz. Maybe supporting 4mhz would mean less timing conversion handling for SBVGM and maybe a more precise playback for 4mhz .VGM ?

The FM chip clock effects basically everything, including pitches. You can transpose the pitches in software to correct for a different clock. There are 12 note numbers and a 6-bit key fraction, which means 768 steps per octave (better than OPL's 512 steps, but worse than OPN's 1024 steps). You can't fine tune the envelope timing though, because one step is a factor of 2 or square-root-of-2.

X68000 has a YM2151 at 4MHz, but eg. CPS1 games use 3.58MHz. So both are common.