I had many difficulty using sbvgm 1.33, to boot from : I like how it display it when all synth needed playing a music, but my request being : can it also display it when it fail at matching a play ? Also why I have to specify -t2c0 while opl388 is autodetected ? This dont make sense. Why some players are autodetected and some are not ? I would prefer audio device being autodetected via command line parameters. It but crash the player if I dont thoroughly disable the sblive in there too

also I hope your coding team are also working on the PSG playing problem that skip some bass notes

ElBrunzy wrote on 2020-12-24, 17:45:

I had many difficulty using sbvgm 1.33, to boot from : I like how it display it when all synth needed playing a music, but my request being : can it also display it when it fail at matching a play ? Also why I have to specify -t2c0 while opl388 is autodetected ? This dont make sense. Why some players are autodetected and some are not ? I would prefer audio device being autodetected via command line parameters. It but crash the player if I dont thoroughly disable the sblive in there too

I'll keep displaying the names of the chips that caused the player to fail in mind for when I can work on fixes for the next version. In the case of SN76489 detection: The primary reason is that there is simply no auto-detection method available on the current SN76489 sound cards. In regards to the crash that you are experiencing with the sblive installed, what are your environment variables settings for the sound card and what are the sound devices (including their port addresses)?

ElBrunzy wrote on 2020-12-24, 17:48:

also I hope your coding team are also working on the PSG playing problem that skip some bass notes

I haven't forgotten about that and have an idea for how to fix it, it's just been very busy lately. I will try to take care of it as soon as possible. Thank you for the feedback! 👍

About the set blaster bug, I think any random (but wrong) set blaster= settings might cause the player to crash. I'll try to give you the info if I can find them.
About auto-detect of audio chip really, I think you should add a way to disable them or ask to detect them, like "sbvgm 123.vgm +t2c0 -opl3" so that would add tandy and remove opl from the mix. Now you have a new version of your engine you might also try to make it more modular, like you add players in command line "sbvgm.exe music.vgm +synth1 +synth2 -synth3"

about the psg note bug. I'm about ready to make a audio of using sbvgm.exe on the saa1099 and sn76489 for comparison. I was wondering if you had any music in mind that you would like me to use. Do you want to delay this project until you fix the PSG Bass note problem ?

ElBrunzy wrote on 2020-12-26, 03:02:

About the set blaster bug, I think any random (but wrong) set blaster= settings might cause the player to crash. I'll try to give you the info if I can find them.
About auto-detect of audio chip really, I think you should add a way to disable them or ask to detect them, like "sbvgm 123.vgm +t2c0 -opl3" so that would add tandy and remove opl from the mix. Now you have a new version of your engine you might also try to make it more modular, like you add players in command line "sbvgm.exe music.vgm +synth1 +synth2 -synth3"

Having some kind of command line option to exclude certain chips is not a bad idea. At the moment I am not sure if changing the format (+ for adding and - for exclusion) is a good idea since that could break other programs that assume the current format.

ElBrunzy wrote on 2020-12-26, 03:02:

about the psg note bug. I'm about ready to make a audio of using sbvgm.exe on the saa1099 and sn76489 for comparison. I was wondering if you had any music in mind that you would like me to use. Do you want to delay this project until you fix the PSG Bass note problem ?

Since things are a bit busy at the moment, I'm not sure how soon I will be able to fix the problem. If you wanted to work on the project and not wait, you could use VGM files that don't exhibit the bug.

Huge success! I made it! Dual SN76489AN, OPL2, OPL3, SAAYM, Sound Blaster, 5 in 1! With a CPLD controller which can be used to program the io address and irq and dma in PIO mode.

Video https://b23.tv/av971375234
Some pictureshttps://b23.tv/7IZ8Wf

黄禄轩 wrote on 2021-02-03, 03:04:

Huge success! I made it! Dual SN76489AN, OPL2, OPL3, SAAYM, Sound Blaster, 5 in 1! With a CPLD controller which can be used to program the io address and irq and dma in PIO mode.

Video https://b23.tv/av971375234
Some pictureshttps://b23.tv/7IZ8Wf

Congratulations on a job well done! 😀👍

黄禄轩 wrote on 2021-02-03, 03:04:

Huge success! I made it! Dual SN76489AN, OPL2, OPL3, SAAYM, Sound Blaster, 5 in 1! With a CPLD controller which can be used to program the io address and irq and dma in PIO mode.

Video https://b23.tv/av971375234
Some pictureshttps://b23.tv/7IZ8Wf

Congratulations! Really happy to see that you got things working and very nice demo of the device. By the way, v1.33 has support for dual chipsets so it should work with your soundcard. A while back, I was finally able to get a hold of 4.77MHz hardware and I realized that it's not necessary to wait so long for the address and data writes for the YM3812, YMF262, and YM2151. The simplest fix would be to add a command line parameter to specify using a short wait time. Currently, things are very busy for me right now, but a future update should have it along with some other requests that were made in the past. Thank you for sharing your accomplishment! 👍

I did a audio comparison of a SN76489 (left) and SAA1099 (right) recording using a tndy nano v1.0 card by matze79 that's built around an SN76489 and a soundblaster 1.5 with saa1099 addon. I used sbvgm.exe v1.33 by to play a list of music since it support both cards. I added a pause in between each track so I could re-sync the audio in between each track. Since I did not want to add mp3 compression artefact I saved a 44.1khz 16bit wave file. I wanted to make a new playlist but I could not find enough new music for it, so I re-used the one I made already with the addition of WonderBoy3. Maybe it will help us understand the audio problem with the bass note on some music. I think it is apparent in the phantasy star and y's music again, but I think you are aware of that problem and just need some time to address. Other than that I think the tone and timing resemblance is very convincing but there seem to be some amplitude difference in between some instruments so it's hard to balance stereo signal. Since the file is around 90mb I will put it on 💾 google drive.

Here is the lineup:
Alex Kidd in Miracle World - 04 - Underwater.vgm
Choplifter - 02 - Round 1.vgm
Gunstar Heroes (GG) - 04 - Choose a Path.vgm
Gunstar Heroes (GG) - 08 - Rolling Chaser.vgm
Lord of the Sword - 04 - Story.vgm
Miracle Warriors - 04 - Castle.vgm
Phantasy Star - 15 - Medusa.vgm
SpellCaster - 05 - Forest.vgm
Wonder Boy - 04 - Boss Round.vgm
Ys - 05 - First Step Towards Wars.vgm
Wonder Boy III - 10 - The Danger Zone.vgm

While I had everything open I'll make a spectrograph of Ys since the bass problem seem to be more apparent here. Maybe it will eventually be of any help. It's a zoom of the first 2 seconds 0-4khz frequency of Ys with the SN76489 on top, SAA1099 in the middle and the difference in bottom. It look like where there is supposed to have a mute the bass line get to be played too loud... or something like it. I'm eager to have your opinion on that.

@ElBrunzy, what you for making the recordings and looking further into the issue. The main cause of the incorrect bass sound on the SN76489 is that the Sega Master System implementation is different from that of the SN76489AN. At the time I added support for the SN76489, I did not have actual hardware and used DOSBox. Under DOSBox, you won't hear the issue with the bass notes so the SN76489 variant used by DOSBox is likely the Sega Master System version and not what is found on the Tandy 1000 or SN76489AN. Fortunately, there are some SN76489 flags in the VGM data that can be checked and thus it will be possible to correct for the behavior which is in this case, silencing the note.

Fixing this is not difficult; it's more of an issue of having a sufficient block of time which at present, is lacking on my end.

Hi OPLx, I hope I did not stressed you with that issue, I know is must be the third time I bring it to your attention. Having an hobby can become a burden if you feel an obligation to work on it and it's not what I'm trying to achieve. On the opposite, I was in the impression that to document the problem would allow to securely postpone the fix.

From wikipedia and smspower we can read that the "AN" designate the packaging and the presence of an audio in. They also say that sega used the AN in sg-1000 and sc-3000 but used a clone in the VDP chip. Although on a seemingly more complete documentation we can read that "Up to 4 MHz Clock input: Part SN76489N is identical to the SN76489A except that the maximum clock input frequency is 500 kHz. A "divide by eight" stage is deleted from the input circuitry and only 4 clock pulses are required to load the data, compared to 32 pulses from the SN76489AN."... oh well I'm not sure what to make of all that.

I did try to play the problematic musics lowering the speed on my own "player" (if you call your player an experimentation, then we should call mine a bunch of code line thrown together that luckily work) and what I noticed is those loud bass notes always appear when a 0x00 value is from the 0x50 instruction. Resetting the PSG at this moment (sending 0x9f, 0xbf, 0xdf, 0xff) did not help, I seem to remember some test related to that from you. the sn76489an dont seem to like receiving that 0x00 instruction, but on another hand stripping it from the stream dont seem to be the solution either.

ElBrunzy wrote on 2021-03-06, 01:50:

Hi OPLx, I hope I did not stressed you with that issue, I know is must be the third time I bring it to your attention. Having an hobby can become a burden if you feel an obligation to work on it and it's not what I'm trying to achieve. On the opposite, I was in the impression that to document the problem would allow to securely postpone the fix.

There's no stress at all; thank you for your investigations. 😀

ElBrunzy wrote on 2021-03-06, 01:50:

From wikipedia and smspower we can read that the "AN" designate the packaging and the presence of an audio in. They also say that sega used the AN in sg-1000 and sc-3000 but used a clone in the VDP chip. Although on a seemingly more complete documentation we can read that "Up to 4 MHz Clock input: Part SN76489N is identical to the SN76489A except that the maximum clock input frequency is 500 kHz. A "divide by eight" stage is deleted from the input circuitry and only 4 clock pulses are required to load the data, compared to 32 pulses from the SN76489AN."... oh well I'm not sure what to make of all that.

There are different variants/implementations of the SN76489 chip which try to accommodate the type of hardware (specifically clocks) that were available during its time of production, so it's not too surprising to see the differences.

ElBrunzy wrote on 2021-03-06, 01:50:

I did try to play the problematic musics lowering the speed on my own "player" (if you call your player an experimentation, then we should call mine a bunch of code line thrown together that luckily work) and what I noticed is those loud bass notes always appear when a 0x00 value is from the 0x50 instruction. Resetting the PSG at this moment (sending 0x9f, 0xbf, 0xdf, 0xff) did not help, I seem to remember some test related to that from you. the sn76489an dont seem to like receiving that 0x00 instruction, but on another hand stripping it from the stream dont seem to be the solution either.

The only real solution that I can think of for this particular issue is to manually (in code) silence the channel since it seems that some songs were written taking advantage of this idiosyncrasy. I know what needs to be done to fix it. Hopefully it won't be too much longer before I can get to it.

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

This update includes the fix for the SN74689 'low bass note' issue that occurs with Sega Master System VGM's that use a frequency value of 0 to 'silence' the note which was reported by @ElBrunzy.

Wow that's great news, OPLx! Since you have the habit to release achieved builds I was certain your new version would work alright but I was eager to test it anyway. It was a real treat to listen to all of my favorite SEGA Master System music via a playlist on original hardware while I could do something else. Of course I payed a special attention to the problematic soundtrack (Y's and Phantasy Star) but I could not find anything wrong this time. So, in the name of all Tandy and SN76489 owner who enjoy SMS music, I want to thank you for this fix.

Now if you please allow me, there is another topic I would like to discuss with you, it's not really a bug, but more about the command line argument and autodetection behavior. I think we once briefly talked about it but it was short lived. I realize you can manually add many cards, like "sbvgm -t2c0 -a388 music.vgm" so this would allow to play music.vgm if it comtain PSG, OPLL or both instructions in the stream. But your autodetection routine will still launch to try to detect other cards. It is quite long and can take a while if you use the FOR batch script to pass thru a series of incompatible VGM. Maybe there could be a switch to disable autodetect, or it could be used only if no soundcard are specified ? I'm not sure I remember it correctly but I think the autodetection routine might be necessary for the multi-synth support you added lately.

ElBrunzy wrote on 2021-03-10, 04:37:

Wow that's great news, OPLx! Since you have the habit to release achieved builds I was certain your new version would work alright but I was eager to test it anyway. It was a real treat to listen to all of my favorite SEGA Master System music via a playlist on original hardware while I could do something else. Of course I payed a special attention to the problematic soundtrack (Y's and Phantasy Star) but I could not find anything wrong this time. So, in the name of all Tandy and SN76489 owner who enjoy SMS music, I want to thank you for this fix.

Thank you for the kind comments, and also thank you for pointing out this bug. There are so many VGMs it's impossible to be able to catch all the errors.

ElBrunzy wrote on 2021-03-10, 04:37:

Now if you please allow me, there is another topic I would like to discuss with you, it's not really a bug, but more about the command line argument and autodetection behavior. I think we once briefly talked about it but it was short lived. I realize you can manually add many cards, like "sbvgm -t2c0 -a388 music.vgm" so this would allow to play music.vgm if it comtain PSG, OPLL or both instructions in the stream. But your autodetection routine will still launch to try to detect other cards. It is quite long and can take a while if you use the FOR batch script to pass thru a series of incompatible VGM. Maybe there could be a switch to disable autodetect, or it could be used only if no soundcard are specified ? I'm not sure I remember it correctly but I think the autodetection routine might be necessary for the multi-synth support you added lately.

Adding a switch to disable auto-detection at the beginning is no problem. With the auto-detection disabled, it would be up to the user to know exactly what audio options desired. This would decrease the start up time (especially for the slower machines). With the current VGM format, there's no way to know what chips are supported until the VGM header data is loaded into memory. This unfortunately means there's no way to quickly skip over files that can't be played by the sound chip options given to SBVGM.

Since it's not too hard to add this, I'll keep this in mind for the next release. Thank you for the suggestion.

OPLx wrote on 2021-03-10, 12:34:

Adding a switch to disable auto-detection at the beginning is no problem. With the auto-detection disabled, it would be up to the user to know exactly what audio options desired. This would decrease the start up time (especially for the slower machines). With the current VGM format, there's no way to know what chips are supported until the VGM header data is loaded into memory. This unfortunately means there's no way to quickly skip over files that can't be played by the sound chip options given to SBVGM.

Since it's not too hard to add this, I'll keep this in mind for the next release. Thank you for the suggestion.

Yes that's the point, let's not be too hasty. Like you say often, there is many variant of VGM and many playback configuration. Right now I have a temporary setup with the TNDY Nano and no OPL2/3 in it so unexpected stuff start to appear. Like there is some .VGM that has OPLL and PSG set in the header but only music on the OPLL who then play as complete silence on that setup. Would one prefer not to play an incomplete .VGM or try to play the part that he can ? I think the latter option is preferable and it's the actual behavior. It also allow to play 2xSN76489 if you only have one, which is a good thing.

About the autodetection I was tempted to mention that it would be longer on slow machine but I'm not sure, even on that pentium 4 2.6ghz it's surprisingly slow, so probably that's it's tied to ancient timing and would be relatively the same on a slower computer. The ability to disable the autodetection can have some advantage for people that keep them OPLL and PSG game in the same directory since it would allow to quickly skip the FM version for instance. I wonder how to implement it the most efficiently possible though... I think you should let it on by default unless specified to be disable as most user will want it. And it only become handy in some specific situation where user are well aware of what they are doing.

At this point I totally agree that you should sleep on it and integrate it in a latter release. Which bring me to the question of what you have in mind for the player future ?

ElBrunzy wrote on 2021-03-11, 05:12:

Yes that's the point, let's not be too hasty. Like you say often, there is many variant of VGM and many playback configuration. Right now I have a temporary setup with the TNDY Nano and no OPL2/3 in it so unexpected stuff start to appear. Like there is some .VGM that has OPLL and PSG set in the header but only music on the OPLL who then play as complete silence on that setup. Would one prefer not to play an incomplete .VGM or try to play the part that he can ? I think the latter option is preferable and it's the actual behavior. It also allow to play 2xSN76489 if you only have one, which is a good thing.

There are various Master System VGMs that are with header information indicating that both the SN76489 and OPLL data exists, but in reality lacks data for one of the chips. The only way to correctly verify if the data exists is to actually run through the VGM commands which obviously is not really a good idea. In this case, the VGM file header needs to be corrected.

ElBrunzy wrote on 2021-03-11, 05:12:

About the autodetection I was tempted to mention that it would be longer on slow machine but I'm not sure, even on that pentium 4 2.6ghz it's surprisingly slow, so probably that's it's tied to ancient timing and would be relatively the same on a slower computer. The ability to disable the autodetection can have some advantage for people that keep them OPLL and PSG game in the same directory since it would allow to quickly skip the FM version for instance. I wonder how to implement it the most efficiently possible though... I think you should let it on by default unless specified to be disable as most user will want it. And it only become handy in some specific situation where user are well aware of what they are doing.

SBVGM is generally tested on a Pentium III/450MHz machine and DOSBox and the time it takes for the auto-detection is not noticeable. I was finally able to have access to an actual 8088/4.77MHz to test on and it's fairly slow. Disabling the auto-detection will require a command-line switch so it shouldn't affect how things are normally.

ElBrunzy wrote on 2021-03-11, 05:12:

At this point I totally agree that you should sleep on it and integrate it in a latter release. Which bring me to the question of what you have in mind for the player future ?

There have been a few requests (in addition to the ones you made) that needs to be addressed (as time allows). After adding in support for the YM2612, I started had looking into supporting the other OPN-based VGMs for playback on the YM2151, but that will definitely require some focused time to examine the differences between the OPN family and OPM (YM2151) and then implement the support to translate from OPN to OPM. Besides this, I would say that SBVGM is probably near being "done enough"; it's gone well beyond my original goal of testing out some things with the SAA1099.

You are right, the autodetection was not slow before... I wonder what make this system so slow, I timed it around 1 to 2 seconds (which become noticeable if you have to skip a bunch of incompatible vgm). The presence of BLASTER= environment variable seem to make the autodetection faster. Oh well, seem to only affect that p4 that have only a TNDY NANO in it, but it's a temporary situation so let's not waste more time on that. A new card with opl2/3 or the autodetection switch will take care of this sooner or later anyway.

Wow I never noticed you supported the YM2151. I read that this allow for a somewhat limited support for the YM2161 too. I'm a big fan of the Golden Axe soundtrack on the genesis/megadrive YM2161 or on the PC OPL2. I did not realized your player could play the arcade VGM rip on the TEX Elec, of course now I need one! I'm going to make some research first but probably order one since they seem to be in stock now for a reasonable price.

Does any FM homebrew card maker dont use your player to showcase them product ? 😁

ElBrunzy wrote on 2021-03-12, 04:05:

You are right, the autodetection was not slow before... I wonder what make this system so slow, I timed it around 1 to 2 seconds (which become noticeable if you have to skip a bunch of incompatible vgm). The presence of BLASTER= environment variable seem to make the autodetection faster. Oh well, seem to only affect that p4 that have only a TNDY NANO in it, but it's a temporary situation so let's not waste more time on that. A new card with opl2/3 or the autodetection switch will take care of this sooner or later anyway.

There are at least three different sound cards that get auto-detected via their respective port ranges; the more auto-detection that is required, the longer it will take. The BLASTER environment variable makes things a lot faster since the exact settings are there.

ElBrunzy wrote on 2021-03-12, 04:05:

Wow I never noticed you supported the YM2151. I read that this allow for a somewhat limited support for the YM2161 too. I'm a big fan of the Golden Axe soundtrack on the genesis/megadrive YM2161 or on the PC OPL2. I did not realized your player could play the arcade VGM rip on the TEX Elec, of course now I need one! I'm going to make some research first but probably order one since they seem to be in stock now for a reasonable price.

YM2151 support was added around late 2019. When I had been doing some earlier research I noticed the similarities between the YM2151 and YM2612 and was happy to be able to get YM2612 VGMs to work. There are some differences between the chips so certain YM2612 features (EEG, Ch3, sample playback on channel 6) won't work on the YM2151. Also, the LFO speeds are different and the YM2612 can go to much lower frequencies than the YM2151 so the YM2612 VGM playback in certain cases simply won't sound correct and there's no way around it.

ElBrunzy wrote on 2021-03-12, 04:05:

Does any FM homebrew card maker dont use your player to showcase them product ? 😁

Well, I think the individuals who took the time to make the VGM format are the ones who really should get the credit as I only adopted the VGM format since there were already many RP2A03 VGMs to do my experiment with. If the VGM format didn't exist, I doubt SBVGM would exist as well. 😀 I'm glad the homebrew sound card makers (at least for DOS) can use SBVGM to at least test out their hardware. What I would personally love to see is newer software that uses some of the newer sound cards that have come out in the last several years.

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

This update includes:

• Addition of command line switch (-sbp1) to force Sound Blaster Pro 1.0 dual OPL2 mode now possible to hear 2xYM3812 VGMs and Impact MuSiX Disk #1 (no Y8950 ADPCM playback support)
• Addition of command line switch (-noscan) to disable auto-detection at start up.
• Implementation infinite looping of VGM playback via command line switch (-r0)
• Fix a of bug where sound chip that was force added via command line switch could also get added via auto-detection routine.