Hi, thanks for mentioning my name, Oplx. I'm still very interested at checking the Silpheed and Ys problem on the YM2203 whenever you have time for it.

I've been a bit busy this summer investing my retro-time into an atari STe1040 I acquired in the hope to learn about it. It's sound interface is what motive me the most and I see the current implementation of the AY3891x/YM2149 into SBVGM as an opportunity to learn about it. With YMtoVGM I could convert some well known music from my YM collection, SBVGM.EXE would see those VGM files as YM2149 and would only play them on the SAA1099 of the soundblaster 1.5 with C/MS addon. Most of the music sound alright but it seemed to lack an instrument. Playing the VGM with IN_VGM.DLL on WINAMP show that it is specific to SBVGM.EXE and not something lost in the conversion. I did some analysis with ST-Sound from Arnaud Carre which allow me to mute AY3891x/YM2149 voices. I was surprised to see that the drum could be spanned on Voice B and Voice C. I'm not 100% positive on that yet, but I think I have identified that melodic instruments played on Voice C would not play using SBVGM.EXE.

I used VGM-Conv in the hope to allow SBVGM.EXE to play the missing notes on the YM2151 of the SAAYM or the OPL2 of the SB1.5. Since the SAAYM is on another computer upstairs, I tested the SB1.5 tonight. I believe I can say it brought back all the melodic instruments to the mix, I also pay close attention to drum that have parts on multiple voice and they all there too ! It was quite the technical musical trip and I was quite impressed that in the end the result was the same as the original YM file.

At this point I still have the YM262 conversion to evaluate on the SAAYM. Of course OPL2/3 is far more common than YM2151 on the PC scene. I did attached the Cybernoid and Cybernoid ][ theme I used in this post. Since it produce quite some big files I had to use the -x parameter on SBVGM. On cyber1-2.zip archives you will find 8 files with C1_ and C2_ prefix refer to the Cybernoid 1/2 theme. c?_ay8910.ym is the source music passed thru YMtoVGM to produce c?_ym2149.vgm that is then converted with VGM-Conv to both c?_ym262.vgm and c?_ym3812.vgm.

Thanks for version 1.39, the RSX is recognized properly again. Now to fully test out the YM2608/2203 features on my new SAAYM.

ElBrunzy wrote on 2021-12-28, 06:22:

Hi, thanks for mentioning my name, Oplx. I'm still very interested at checking the Silpheed and Ys problem on the YM2203 whenever you have time for it.

You're welcome. Checking the sound output levels is next on my list.

ElBrunzy wrote on 2021-12-28, 06:22:

I've been a bit busy this summer investing my retro-time into an atari STe1040 I acquired in the hope to learn about it. It's sound interface is what motive me the most and I see the current implementation of the AY3891x/YM2149 into SBVGM as an opportunity to learn about it. With YMtoVGM I could convert some well known music from my YM collection, SBVGM.EXE would see those VGM files as YM2149 and would only play them on the SAA1099 of the soundblaster 1.5 with C/MS addon. Most of the music sound alright but it seemed to lack an instrument. Playing the VGM with IN_VGM.DLL on WINAMP show that it is specific to SBVGM.EXE and not something lost in the conversion. I did some analysis with ST-Sound from Arnaud Carre which allow me to mute AY3891x/YM2149 voices. I was surprised to see that the drum could be spanned on Voice B and Voice C. I'm not 100% positive on that yet, but I think I have identified that melodic instruments played on Voice C would not play using SBVGM.EXE.

I used VGM-Conv in the hope to allow SBVGM.EXE to play the missing notes on the YM2151 of the SAAYM or the OPL2 of the SB1.5. Since the SAAYM is on another computer upstairs, I tested the SB1.5 tonight. I believe I can say it brought back all the melodic instruments to the mix, I also pay close attention to drum that have parts on multiple voice and they all there too ! It was quite the technical musical trip and I was quite impressed that in the end the result was the same as the original YM file.

At this point I still have the YM262 conversion to evaluate on the SAAYM. Of course OPL2/3 is far more common than YM2151 on the PC scene. I did attached the Cybernoid and Cybernoid ][ theme I used in this post. Since it produce quite some big files I had to use the -x parameter on SBVGM. On cyber1-2.zip archives you will find 8 files with C1_ and C2_ prefix refer to the Cybernoid 1/2 theme. c?_ay8910.ym is the source music passed thru YMtoVGM to produce c?_ym2149.vgm that is then converted with VGM-Conv to both c?_ym262.vgm and c?_ym3812.vgm.

It looks like you found a bug! I listened to the files, but unfortunately I could not hear where the problem is. Could you provide more information on this?

McCheeseBob wrote on 2021-12-28, 16:56:

Thanks for version 1.39, the RSX is recognized properly again. Now to fully test out the YM2608/2203 features on my new SAAYM.

You're quite welcome! Thank you for bringing it to my attention. By the way, the YM2151 in the SAAYM is architecturally different from the YM2608/2203. The main similarities are that they share the same FM algorithms, but beyond that there are noticeable differences (from a programming point of view). What SBVGM does is just reinterpret the YM2608/2203 commands onto the YM2151 and SAA1099 found on the SAAYM. With some VGMs it sounds just like the YM2608/2203 and with others it won't because of the YM2151's limitations.

OPLx wrote on 2021-12-31, 13:12:

It looks like you found a bug! I listened to the files, but unfortunately I could not hear where the problem is. Could you provide more information on this?

I made a stereo music of two mono music output using SBVGM 1.39 on the SB1.5+CM/S and sync them. The left one is with parameters -a -x -noscan on the C1_YM3812.VGM using the SB1.5 YM3812, it's on the left of the stereo music. On the right I recorded using SAA1099 with -C option the C1_YM2149.VGM file.

To keep the file as small as possible, I kept only small sample where there was a difference.
-------------------------------
0:00 sec ; part Cybernoid I
0:03 sec ; lead music can only be heard on the YM3812 synth
0:21 sec ; part of the melody can be heard on YM2149 but high pitched sustained notes are cut.
0:41 sec ; part Cybernoid ][
0:43 sec ; the rythmic "chords" are only on the YM3812 synth
0:51 sec ; same as above but they are played differently.

With those section isolated I could notice that in ST-Sound they where all from voice C, but it seem that not all instrument from this voice are muted. Maybe it's related to pitch threshold, previous volume state or data delay ?

I hope this make it more convenient for you to analyze, maybe it play correctly on the SAAYM's SAA1099s ? If you need anything else please just ask, I would be glad to investigate further.

Thank you for the sample data! It will help out for sure. I'm not yet 100% sure what the cause is, but I did find out something about the YM2149. Any of the 3 channels can be set up to use the envelope generator output level and when this happens, the envelope generator output level determines the final volume that channel. While the SAA1099 has envelope generators, it does not have the same feature. If certain VGMs use the envelope generator to control the volume, this will cause there to be no sound output. I don't think that this is the issue that you have come across though, so I will take a closer look.

ElBrunzy wrote on 2022-01-04, 05:19:

I hope this make it more convenient for you to analyze, maybe it play correctly on the SAAYM's SAA1099s ? If you need anything else please just ask, I would be glad to investigate further.

The SAAYM's SAA1099s are the same as the ones in the Sound Blaster C/MS. If I run across any more issues I'll be sure to let you know. Thank you again!

ElBrunzy wrote on 2021-06-09, 22:33:

I think I found some difference in silpheed from this url, it's also easy to compare with them online player https://vgmrips.net […]
Show full quote

I think I found some difference in silpheed from this url, it's also easy to compare with them online player https://vgmrips.net/packs/pack/silpheed-nec-pc-8801
- the music "01. The Legend of Silpheed (opening)" sometimes do a weird noise if it's the first thing I play with the SAAYM. I'm not sure what trigger it exactly or is it just random. So maybe now it's not very important.
- "03. Silf of Wind"
there seem to have some noise very loud noise in the vgm that make the music barely audible, but it's hard to say if it's related to any instrument, so maybe it's an error from the original recording ? If you listen to the emulated online version very carefully you can hear it being very soft.
- "05. Silf of Wind ]["
a very high pitched note is heard and stop when the arpeggio start playing, I think it would be on the emulated version too but I guess we would need visual tool to detect it, I cannot hear it anyway.

On the "YS 1" Soundtrack here https://vgmrips.net/packs/pack/ys-ancient-ys- … men-nec-pc-8801 there seem to have variant drum, they sound a bit differently. I dont know how of a close match to the ym2203 sbvgm is supposed to be with an ym2151 so maybe it's just normal, I dont know if it's a problem but I though you might want to know, it's particularly present in those music:
08. palace of destruction
12. Final Battle
15. see you again

I finally had some time to take a look at these issue. The loud noise you are hearing in "03. Silf of Wind" is a bug. Basically the song uses a feature of the YM2149 core in the YM2203 where if a note is playing at a high pitch, it is effectively in audible. The SAA1099 does not have this feature, but I have implemented a fix that resolves this using the SAA1099's features.

In regards to the other songs, they use another feature of the YM2149 where the envelope generator can be used to control the final volume on a channel as I mentioned here. While the functionality is on the YM2149 is relatively simple, to get it to work exactly the same way on the SAA1099 effectively requires simulating the envelope shape and driving the channel's volume level in this manner. Since the method I'm using to simulate the YM2149 on the SAA1099 is relatively simple, it would take some time (that I'm limited on) to rework things.

I'll try to take a look at the volume levels that you mentioned; hopefully I can get time to take a look into that as well.

ElBrunzy wrote on 2022-01-04, 05:19:

I made a stereo music of two mono music output using SBVGM 1.39 on the SB1.5+CM/S and sync them. The left one is with parameters […]
Show full quote

OPLx wrote on 2021-12-31, 13:12:

It looks like you found a bug! I listened to the files, but unfortunately I could not hear where the problem is. Could you provide more information on this?

I made a stereo music of two mono music output using SBVGM 1.39 on the SB1.5+CM/S and sync them. The left one is with parameters -a -x -noscan on the C1_YM3812.VGM using the SB1.5 YM3812, it's on the left of the stereo music. On the right I recorded using SAA1099 with -C option the C1_YM2149.VGM file.

To keep the file as small as possible, I kept only small sample where there was a difference.
-------------------------------
0:00 sec ; part Cybernoid I
0:03 sec ; lead music can only be heard on the YM3812 synth
0:21 sec ; part of the melody can be heard on YM2149 but high pitched sustained notes are cut.
0:41 sec ; part Cybernoid ][
0:43 sec ; the rythmic "chords" are only on the YM3812 synth
0:51 sec ; same as above but they are played differently.

With those section isolated I could notice that in ST-Sound they where all from voice C, but it seem that not all instrument from this voice are muted. Maybe it's related to pitch threshold, previous volume state or data delay ?

I hope this make it more convenient for you to analyze, maybe it play correctly on the SAAYM's SAA1099s ? If you need anything else please just ask, I would be glad to investigate further.

OK. I found out the bug; it was introduced in v1.33. Originally the SAA1099 registers were cleared, but some improvements I made in v1.33 only cleared registers of the SAA1099 that were used for YM2149 emulation. The problem is fixed now and should be available in v1.40. Thank you for finding this!

That was quick ! Congrats on fixing this one too ! People with SAAYM will sure be happy about that, I know I will ! I usually compare with older version, dont know why for this bug I did not, would had saved us some time. Maybe next time I'll try to remember that, but there is no more bug, right ? 😁

ElBrunzy wrote on 2022-04-29, 14:17:

That was quick ! Congrats on fixing this one too ! People with SAAYM will sure be happy about that, I know I will ! I usually compare with older version, dont know why for this bug I did not, would had saved us some time.

Thank you. The fix will benefit any sound cards with the SAA1099 chips (SAAYM, CMSLPT, and original Sound Blaster). The sheer number of VGM files makes it hard to catch all these different edge cases, so I do really appreciate your help and feedback.

ElBrunzy wrote on 2022-04-29, 14:17:

Maybe next time I'll try to remember that, but there is no more bug, right ? 😁

Well ... um ... who knows what the future will bring! 😉

SBVGM v1.40 is available from: http://www.oplx.com/code/

This update includes:

• Fixed bug where low AY3891x/YM2149 frequency values translated to SAA1099 frequency values would result in a high pitched sound.
• Fixed bug (introduced in v1.32) that did not properly clear the SAA1099 registers at start up; fixes issues with AY3891x/YM2149 playback.

Thank you to @ElBrunzy for reporting these issues.

SBVGM v1.41 is available from: http://www.oplx.com/code/

This update includes:

• Fixed PRE(processed) logging that likely got broken in v1.33.
• Added YM2151 PRE(processed) logging.
• Added PRE(processed) loop support.

I used the cyber1-2.zip files to check it out using an SAAYM and it seem everything is in there now! I also noted SBVGM1.32&1.33 would leave a weird noise at the end of the music but it was corrected in 1.41, but the noise is still somewhere. When using OPL3 to play YM262 files it end up leaving a noise, but if you play the YM3812 file it end up correctly now. So maybe it was just a cleanup condition left unlinked ?

On another note, I had the opportunity to talk with Maxim from SMSPower! about the VGM format and I could correct some timing issues on my own player (remember that project of playing 2A03 VGM on SN76489 chip?) it's now quite precise at playing Sega Master System VGM on SN76489 but not as much as your SBVGM.EXE so I wanted to ask you a question about how you used the PIT routine. I think the way I used it is not ideal and timing is not always precise, as you will see. Since VGM are sampled at 44100hz you need to find the length of one frame for instruction 0x61 X samples wait, and instruction 0x62 and 0x63 will respectively be 735 and 882 frames. The way I did it is using the PIT in mode 2 (rate generator) and to find the interval of a 44.1khz frame I used "int divisor = 1193180 / 44100;" which is 27.05623, so 0.056623 is being lost, I think it might end up doing some small glitch over time. If I get function 0x63 I will wait 23814 frames instead of 23864. Over the years we could test how precise and exact your SBVGM timings are so I would be glad to know how you use the PIT and implement wait functions. Now I know you prefer not release the source code to your program, but for the reasons you explained me I believe your motives wont conflict with this inquiry, that's why allow myself to bring this topic. If worry if you prefer not or miss time, I will understand (also at the pace my project go I think you understand I'm in no hurry 😅).

ElBrunzy wrote on 2022-05-13, 20:35:

I used the cyber1-2.zip files to check it out using an SAAYM and it seem everything is in there now! I also noted SBVGM1.32&1.33 would leave a weird noise at the end of the music but it was corrected in 1.41, but the noise is still somewhere. When using OPL3 to play YM262 files it end up leaving a noise, but if you play the YM3812 file it end up correctly now. So maybe it was just a cleanup condition left unlinked ?

I don't fully understand. Do you mean that playing the OPL3 VGM files produces the noise? I only examined the SAA1099 issues. If this is the case, it's probably an issue with the OPL3 VGM data itself.

ElBrunzy wrote on 2022-05-13, 20:35:

On another note, I had the opportunity to talk with Maxim from SMSPower! about the VGM format and I could correct some timing issues on my own player (remember that project of playing 2A03 VGM on SN76489 chip?) it's now quite precise at playing Sega Master System VGM on SN76489 but not as much as your SBVGM.EXE so I wanted to ask you a question about how you used the PIT routine. I think the way I used it is not ideal and timing is not always precise, as you will see. Since VGM are sampled at 44100hz you need to find the length of one frame for instruction 0x61 X samples wait, and instruction 0x62 and 0x63 will respectively be 735 and 882 frames. The way I did it is using the PIT in mode 2 (rate generator) and to find the interval of a 44.1khz frame I used "int divisor = 1193180 / 44100;" which is 27.05623, so 0.056623 is being lost, I think it might end up doing some small glitch over time. If I get function 0x63 I will wait 23814 frames instead of 23864. Over the years we could test how precise and exact your SBVGM timings are so I would be glad to know how you use the PIT and implement wait functions.

The 16-bit version sets the PIT (running in Mode 2) to run at 180Hz while the 32-bit version 540Hz, thus each update is a ratio of 44100Hz; 245 or 81. Using the 180Hz PIT value example, there needs to be at least 245 VGM "updates" so the program will process (loop) that number of times to attempt to keep up with the appropriate VGM playback rate. It's definitely not perfect and can be slow on slower CPUs with VGMs that have a lot of small delays. This is why VGMs with sample playback won't work because it's just too slow.

I believe the issue you are running into by setting the PIC to 27 is that it's probably taking longer than 22.67573 microseconds to update the VGM playback if the program just playing the VGM data as-is. There can be a lot of overhead in this manner. @Scali's Putting the things together discusses a much better method for playback, but that requires pre-processing the data ahead of time.

ElBrunzy wrote on 2022-05-13, 20:35:

Now I know you prefer not release the source code to your program, but for the reasons you explained me I believe your motives wont conflict with this inquiry, that's why allow myself to bring this topic. If worry if you prefer not or miss time, I will understand (also at the pace my project go I think you understand I'm in no hurry 😅).

My intent was to release the source at some point, but things got very busy and I simply did not have time. Because SBVGM was originally an experiment, much of the source is not necessarily in a "clean" state (lots of unfinished and/or uncommented code). There is also the issue of picking which license to use. Whenever the source does get released, I won't be offering any support or any more bug fixes though! 😅

I guess my explanation are hard to understand, even I could not get it back and had difficulty to reproduce the problem. So I made a table of result to have a clear view. That computer have a AWE32 and a SAAYM so I noted that (sbvgm and sbvgm32 behaved the same) :

I realize only ym262 files would be problematic. I tested with all other ym262 vgm I have (the lost vikings, simcity 2000, ultima underworld 2, doom ymf262 version rip) and everything worked fine. So I guess it's something in the converter I used when using that ym262 option to produce vgm out of ay8910 files there is something fishy. At this point I'll leave it to you to check it out but I dont think it's worth much. I guess you are right to say that it's the file where reside the problem. Maybe the author of the conversion tool would be interested in this.

Thank you for the insight about how you did your PIT timing. There is certainly some food for thought there. Even so I use a pentium 1 isa bus to host most of my vintage soundcards there is certain limit to what can be done between two interrupt. Maybe my too frequent call can create some contention and regrouping chunk by a common denominator might help timing precision in the end. I'll review my code giving it some consideration in that regard.

Now I'm also trying to figure out how to interpret Ricoh 2A03 register set and convert them to something that can be used in the SN76489. I was in the impression that one VGM data of NES instruction could hold many different instructions in a bit field and I had to extract them using some bitwise boundaries (like bit 1 is mute on/off, bit 2 to 6 is frequency and bit 7-8 is whatnot), but apparently it's not and it's always that sequence : 0xB4 addr data. Maybe that explain why NES VGM are so big. So I'm considering to do like you and use XMS memory to read the whole file. I think I'm not very far from having something recognizable output from a SEGA Master System that was recorded on a NES.

🤞 For your source release code I wishes things goes as you plan !

Hi OPLx!

I have an AWE32 for digital playback and also have a true OPL2 exact Adlib clone in my computer. I configured so the Adlib plays midi / FM, while the AWE32 does everything else (it has no real OPL3, since it's a PnP).
My problem, I try to lauch SBVGM with parameters -a388. -a389, -a0388, -a0389 and it "searches" for Sound Blaster at 220h, then it fails (the card has a fixed port at 388h / 389h like the original Adlib had). I tried also with lauching sound.com (some player need it), but it did not change much.
I'm using Caldera Dr-Dos on real hw.

All the other players I used were recognizing the card finely. What I'm I doing wrong?

EDIT:
Okay, I understand. I have to put the filename at the end, because it plays only one track at the time. 😁 I gonna download the VGMs I like from vgmrips and generate a batch file in python based on the folder tree. 😁

Have you tried to add the -noscan parameter ? In version 1.35 OPLx implemented that function that comes in very handy when you have multiple soundcards with overlapping features and you want to disable "searches" and manually specify what devices you want in the mix. For instance "sbvgm.exe -a388 -noscan filename.vgm" would make sure the player use the adlib at port 388 and do not consider the soundBlaster.

ElBrunzy wrote on 2022-06-29, 14:20:

Have you tried to add the -noscan parameter ? In version 1.35 OPLx implemented that function that comes in very handy when you have multiple soundcards with overlapping features and you want to disable "searches" and manually specify what devices you want in the mix. For instance "sbvgm.exe -a388 -noscan filename.vgm" would make sure the player use the adlib at port 388 and do not consider the soundBlaster.

It seems that what was wrong had been figured out. 😁

It was just a suggestion, for me it still dont add up why an .VGM would not play using an SB but would work on an Adlib. Maybe it's one of those recording that have multi-chip instruction on them ? I would be curious to know what is his T parameter on his SET environment BLASTER variable. I read on nerdlypleasure that it is needed to run AWEUTIL.EXE to init the FM chip. I tested it on my non-pnp awe32 and it's just silent without it. I hope memberAtari will give us some feedback and maybe more details on the problem if it's still here.

I never tested thoroughly to have multiple OPL2/3 chip on the same basePort. if I remember correctly all devices play the same sound. So in the case of a Adlib + SB config I assume it make no difference what device SBVGM.EXE use.

Hi OPLx, I must have forgot that the SAAYM soundcard allow to play Genesis/Megadrive VGM, and most of them sound perfect ! But I realized that one of the very best soundtrack for the console was not plaing properly, it's the Dune music from Cryo. The music by Stephane Picq and Philippe Ulrich is something unique and very good. There are many version and I would suggest you take a look at it if you do not know it already. The game is turn based strategy, I think the best version must have been on PC.

Unfortunately the music is only playing some random sound. The files of that game are very big and if I render them as ROM on the Genesis it take three cartridge to hold it. But the player can play other big music, so the size must not be an issue. I read your note about the YM2612 support in SBVGM.TXT and I see some limitations : I dont think there is sample playback on those VGZ, the frequency range do not seem like a problem. So my guess would be the SSG-EG envelope thing or the LFO that must be missing on the YM2151. The VGM are huge and the musics is not particularly complex, so that's why I think maybe the problem could be a controller like the LFO or the SSG-EG ?

Using VGMTool 2 R5 I could not find anything particular but I think there is another VGM tool analyzer that could help see what's the problem with that soundtrack. Right now vgmrips.net is down and I do not have it. Maybe are you aware of the problem already ? In any case I'll leave the smallest .vgz here:

(I'm aware it's useless to zip a vgz but the forum dont let me upload it otherwise)