It's not a bug per se as that is how the VGM data was captured. Some PSG chips (like the SN76489 and the NES' RP2A03) have the side effect of when a note was played at a particular high frequency, it wouldn't be audible to the human ear. As a consequence of this, some musicians used this as a means to "silence" the note rather than turning off the volume. The current version of SBVGM just takes whatever SN76489 data it receives and translates it in real time for the SAA1099. At some point, I will get around to adding support for silencing the note (it does this for the NES VGMs) so please be patient. 😀
Yes it's my mistake, I was too blunt when I wrote this message. Of course by VGMPLAY I meant SBVGM and by BUG I meant FEATURE 😅. Jokes apart I understand it was indelicate to use such word when it's just an implementation incompatibility in between the saa1099 and sn76489, I'm sorry if I offended you. I'm glad you make effort to compensate for it.
I wasn't offended at all. In many cases these chips on the surface seem more or less "the same", but as one starts to get to examining the details, there can be large differences. For example, amongst the PSG chips, the AY-3-8910 seems to actually be the most versatile, but while the RP2A03 lacks envelope generators it has some hardware features that all the others don't have.
I've also been curious as to why the SAA1099 seemingly has very little presence beyond usage on the SAM Coupé and of course the Game Blaster; there are only two arcade games on VGMRips.net that use it as well.
If it wasn't for you pointing this out, I would not have known as there are seemingly thousands of SN76489 VGMs! 😀 Even though I tested on a large number of VGMs, I still missed the ones you pointed out.
I have gone futher on intergrating those sound cards to my motherboard and now I noticed something quite comfusing.
Dual SN76489AN, SAA1099 and YM2151 can be assigned to left and right channel easily (by the way is ch1 goes to left and ch2 goes to right?); OPL2 and Digital Sound Processor of Sound Blaster is mono output; but OPL3 has four channels, so how they are combined to form stereo?
PS: i have already implemented software programmable address decoding, interruption and dma channel assignment to 2xSN76489AN,OPL2,OPL3,SAAYM and SoundBlaster with CPLD. (SAAYM and SoundBlaster will share the same SAA1099 so they can't be both enabled at the same time)
I have gone futher on intergrating those sound cards to my motherboard and now I noticed something quite comfusing.
Dual SN76489AN, SAA1099 and YM2151 can be assigned to left and right channel easily (by the way is ch1 goes to left and ch2 goes to right?); OPL2 and Digital Sound Processor of Sound Blaster is mono output; but OPL3 has four channels, so how they are combined to form stereo?
PS: i have already implemented software programmable address decoding, interruption and dma channel assignment to 2xSN76489AN,OPL2,OPL3,SAAYM and SoundBlaster with CPLD. (SAAYM and SoundBlaster will share the same SAA1099 so they can't be both enabled at the same time)
Looking at the datasheet for the YM2151 using the YM3012 D/A, it looks like CH1 is left and CH2 is right. Most PC OPL3 sound cards only use the first two channels (CHA = left, CHB = right) for stereo output. CHC and CHD are typically not connected. To my knowledge, the only PC soundcard that uses all four channels is TexElec's Resound OPL3 in a quadraphonic-like configuration requiring two sets of speakers.
I'm pretty sure those "Bell" thing would not be a matter using the sn76489 chip and I will try it using older version of sbvgm to test it, but I'm pretty certain it will not be a problem... who knows ? That bring me to the question about how did you fixed the issue with saa1099 audio chip ?
I'm pretty sure those "Bell" thing would not be a matter using the sn76489 chip and I will try it using older version of sbvgm to test it, but I'm pretty certain it will not be a problem... who knows ? That bring me to the question about how did you fixed the issue with saa1099 audio chip ?
The older versions of the program likely exhibit this. When I first added SN76489 support, I had used DOSBox to test and it didn't have the issue. I just need to make time to do some additional checks with actual hardware. The way I fixed the issue on the SAA1099 is that any time a VGM SN76489 frequency produces an octave value of 7 and a frequency value of 255 (from the internal conversions done), it emulates the SN76489 behavior by disabling the SAA1099's frequency generator for that channel that produces a similar effect.
The older versions of the program likely exhibit this. When I first added SN76489 support, I had used DOSBox to test and it didn't have the issue. I just need to make time to do some additional checks with actual hardware.
I started to test the tndy nano sn76489 with sbvgm and older version (1.15 and 1.18) did not exhibit the problem. Although they freeze the computer on some .vgm that work well (but with the note off bug) with a saa1099. So that's not a problem anymore, if you want I can try to pinpoint at what version it do not crash, must be somewhere in the 1.2x.
I experienced another thing, that matze79 noticed too, is that even if you declare the card on 0c0 with 3tool.exe, sbvgm.exe only use it if you force it at 2c0 (-t2c0). Does it's the same with the TNDLPT ? It can be a bit annoying if you have a OPL2/3 on your computer and listen to soundtrack with PSG and FM music since it will just play silence on C0. Maybe it's normal behavior, I don't know, I'm very new to the tandy and having a real PSG on an AT computer.
The older versions of the program likely exhibit this. When I first added SN76489 support, I had used DOSBox to test and it didn't have the issue. I just need to make time to do some additional checks with actual hardware.
I started to test the tndy nano sn76489 with sbvgm and older version (1.15 and 1.18) did not exhibit the problem. Although they freeze the computer on some .vgm that work well (but with the note off bug) with a saa1099. So that's not a problem anymore, if you want I can try to pinpoint at what version it do not crash, must be somewhere in the 1.2x.
I can check v1.15 and 1.18 to see if it plays the VGMs without the sound issue. If you have access to the MS-DOS program DEBUG, you could try entering these commands at the prompt (assuming 0x2c0 is the address the tndy nano is at):
What the above code does is silence all the sound channels, programs channel 0 to a frequency value of 0, then turns on the volume. What should happen is that you shouldn't hear any sound (I think this is how the SN76489 variant on the Master System behaves). If you hear sound on the tndy nano, then it's a variant that behaves differently which is to be expected since the variant that exist on the Master System is a custom implementation. To silence the sound just enter:
I experienced another thing, that matze79 noticed too, is that even if you declare the card on 0c0 with 3tool.exe, sbvgm.exe only use it if you force it at 2c0 (-t2c0). Does it's the same with the TNDLPT ? It can be a bit annoying if you have a OPL2/3 on your computer and listen to soundtrack with PSG and FM music since it will just play silence on C0. Maybe it's normal behavior, I don't know, I'm very new to the tandy and having a real PSG on an AT computer.
This is how the program presently works since at the time SBVGM was originally released, there weren't any SN76489-based devices to my knowledge outside the Tandy 1000 series, the IBM PCJr, and the IBM PS/1. For auto-detection, SBVGM checks to see if the PC that it is running on is an actual Tandy 1000 or IBM PCJr. Unless there is some means to auto-detect the tndy nano, forcing the port on the command line is the only way. I'm not familiar with 3tool.exe. What is it suppose to do?
I'm still learning about it all, I was in the impression that 3tool.exe was a kind of init tool that redirect call from AT DMA2 computer to another port via a TSR so on an AT you could only have PSG on 0x2c0. But now I see sbvgm work without it so you dont really need to run it. It also use as a muter, so I wont run it to try your debug test. Without it, now the card is noisy as hell (you could run sndoff.exe too but I wont)
- at 2c0,9f the noise became very loud
- at 2c0,ff all was muted
- at 2c0,90 a clean wave could be hear
-at 2c0,9f muted it
I think it's problematic that if you have an OPL then the player only detect the PSG at the wrong address and cannot use it, adding blank in your playlist. But that make me wonder how the program will behave if you have a sb1.5 with saa1099 and a tandy sn76489 (those rich bastards) playing at the same time ?
So I dont know what to think of it...
Really, I start to think I'm offloading my mistake to you, the problem is that I put my music collection soundtrack FM and PSG in the same directory. For video game that have both version I should simply create two different subdir. But still that 2c0 thing puzzle me, I think it's related to that second AT DMA being put at c0.
ElBrunzywrote on 2020-08-07, 23:32:I'm still learning about it all, I was in the impression that 3tool.exe was a kind of init tool that redirect call from AT DMA2 […] Show full quote
I'm still learning about it all, I was in the impression that 3tool.exe was a kind of init tool that redirect call from AT DMA2 computer to another port via a TSR so on an AT you could only have PSG on 0x2c0. But now I see sbvgm work without it so you dont really need to run it. It also use as a muter, so I wont run it to try your debug test. Without it, now the card is noisy as hell (you could run sndoff.exe too but I wont)
- at 2c0,9f the noise became very loud
- at 2c0,ff all was muted
- at 2c0,90 a clean wave could be hear
-at 2c0,9f muted it
It takes a while to grasp how everything fits together; it's what made the old PC hardware frustrating, yet interesting and challenging. If my understanding is correct, XT class hardware didn't use port 0xC0, but AT class hardware does. SBVGM takes the safe approach when it auto-detects the hardware. When the user specifies the port address on the command-line, the assumption is that the user knows what they are doing. In this case 3tool.exe isn't necessary since SBVGM can write directly to the Tandy Nano's configured port address.
If you can hear the sound from that debug test, then the SN76489 variant doesn't implement the Master System approach to handling a frequency value of 0. In a future release, I'll have to look into fixing this. I'm now curious what that debug test program sounds like on an actual Tandy 1000; that would help to give me some insight on how to address fixing the problem without introducing another one.
I think it's problematic that if you have an OPL then the player only detect the PSG at the wrong address and cannot use it, adding blank in your playlist. But that make me wonder how the program will behave if you have a sb1.5 with saa1099 and a tandy sn76489 (those rich bastards) playing at the same time ?
So I dont know what to think of it...
In the current version, if you try: SBVGM -ts2c0 file.vgm, SBVGM will use the Tandy Nano and the OPL2 portion of the Sound Blaster since it gives priority to actual SN76489 hardware. By the way the -t and -ts option do the same thing (in this case).
Since I mostly use the TNDLPT for the programming, I'm generally writing to the hardware directly. I'll take a look at the tool though; thank you for the link!
Really, I start to think I'm offloading my mistake to you, the problem is that I put my music collection soundtrack FM and PSG in the same directory. For video game that have both version I should simply create two different subdir. But still that 2c0 thing puzzle me, I think it's related to that second AT DMA being put at c0.
The main solution for this situation is to just have a batch file that gives SBVGM the necessary command line parameters so you can hear the VGMs on your preferred set up. The auto-detection is primarily just for convenience since there are so many different chips and configurations available.
It takes a while to grasp how everything fits together; it's what made the old PC hardware frustrating, yet interesting and challenging. If my understanding is correct, XT class hardware didn't use port 0xC0, but AT class hardware does. SBVGM takes the safe approach when it auto-detects the hardware. When the user specifies the port address on the command-line, the assumption is that the user knows what they are doing. In this case 3tool.exe isn't necessary since SBVGM can write directly to the Tandy Nano's configured port address.
If you can hear the sound from that debug test, then the SN76489 variant doesn't implement the Master System approach to handling a frequency value of 0. In a future release, I'll have to look into fixing this. I'm now curious what that debug test program sounds like on an actual Tandy 1000; that would help to give me some insight on how to address fixing the problem without introducing another one.
I dont know what to think anymore, I read the SEGA used the SN76489AN and it's what I have. They are clone but similar in functionality. Only difference I'm reading are insignificant to our purpose. Like inverted output signal phase, different random noise generator, certainly nothing that would affect how you interface the chip logic. I have a IRC friend with a tandy 1000 whom is very interested into your program. He his the one who is sad because sbvgm could not output NES vgm on the SN76489, be sure I will get back with that to you soon enough now because I'm sad too, I will ask him to run the debug next time I see him. My understanding is that he should not hear the tone at 2c0,90 ?
Btw about your AT/XT interpretation, I think you got the right difference, only I believe it's the opposite. AT presented a second DMA controller and put it at C0 and that's why the standard dont allow for the synth being there.
Since I mostly use the TNDLPT for the programming, I'm generally writing to the hardware directly. I'll take a look at the tool though; thank you for the link!
I still dont really understand what 3tool is used for. It seem the tndy nano was ment to be used on 2c0 and cannot be chaged... I just finished reading the source code and I still dont understand what it does really, except that mute thing.
In the current version, if you try: SBVGM -ts2c0 file.vgm, SBVGM will use the Tandy Nano and the OPL2 portion of the Sound Blaster since it gives priority to actual SN76489 hardware. By the way the -t and -ts option do the same thing (in this case).
Yeah that work well, I dont understand what I was complaining about... probably my brain got overwhelmed with all the possibility of that new soundcard. I understand there is no way for you to detect at which address the synth is.
I'm very grateful for all the explanation you gave me about how to use sbvgm with the tndy nano, since it's the only reason why I bought this card kit. But there is another problem I havent brought with you still. Since it's an impression I wanted to make sure it was real. The bass line most often sound wrong. It look like an envelope or maybe pitch problem, I dont really know how to describe it. I'll find a music that apparently exhibit this problem and record it with the tndy nano and the sega master system. I trust you could compare it with the saa1099. The first thing I did is to check if it was not related to your note off bug fix, and it's not. I'll get back to you later about that.
It takes a while to grasp how everything fits together; it's what made the old PC hardware frustrating, yet interesting and challenging. If my understanding is correct, XT class hardware didn't use port 0xC0, but AT class hardware does. SBVGM takes the safe approach when it auto-detects the hardware. When the user specifies the port address on the command-line, the assumption is that the user knows what they are doing. In this case 3tool.exe isn't necessary since SBVGM can write directly to the Tandy Nano's configured port address.
If you can hear the sound from that debug test, then the SN76489 variant doesn't implement the Master System approach to handling a frequency value of 0. In a future release, I'll have to look into fixing this. I'm now curious what that debug test program sounds like on an actual Tandy 1000; that would help to give me some insight on how to address fixing the problem without introducing another one.
I dont know what to think anymore, I read the SEGA used the SN76489AN and it's what I have. They are clone but similar in functionality. Only difference I'm reading are insignificant to our purpose. Like inverted output signal phase, different random noise generator, certainly nothing that would affect how you interface the chip logic. I have a IRC friend with a tandy 1000 whom is very interested into your program. He his the one who is sad because sbvgm could not output NES vgm on the SN76489, be sure I will get back with that to you soon enough now because I'm sad too, I will ask him to run the debug next time I see him. My understanding is that he should not hear the tone at 2c0,90 ?
Btw about your AT/XT interpretation, I think you got the right difference, only I believe it's the opposite. AT presented a second DMA controller and put it at C0 and that's why the standard dont allow for the synth being there.
Since I've never programmed the SN76489 variant in the Master System I can not say for certain, but if the SN76489AN is mostly the same as the Master System, the VGM data should just work without any modifications. What I am aware of is that the SN76489 implementation is not a separate chip, but included as part of the Master System's video display processor. This is what lead me to suspect that there are subtle differences between the two.
It would be nice if your friend who has the Tandy 1000 could run those DEBUG commands on his machine. I just want to know if there is any tone when the 2c0, 90 command is sent. In this case though, he would have to chance the 2c0 address to c0. So for the Tandy 1000, the commands should be:
1o c0, 9f ; turn off volume for channel 0 2o c0, 80 ; set frequency value of 0 (low 4-bits) for channel 0 3o co, 00 ; set frequency value of 0 (high 6-bits) for channel 0 4o c0, 90 ; there may or may not be a sound here 5o c0, 9f ; turn off volume for channel 0
Also, I think he may have to enable the multiplexer to hear the sound; I'll send you a direct message with two programs that he can run to check.
If the SN76489 could reliably playback NES VGMs, I would have supported it. One of the main issues is that the frequency range of the NES' sound chip is much wider than that of the SN76489. If your friend's Tandy 1000 has a parallel port maybe he could use the CMSLPT once it is available for purchase? SBVGM currently doesn't support this, but I am planning on doing so once I can buy it.
Since I mostly use the TNDLPT for the programming, I'm generally writing to the hardware directly. I'll take a look at the tool though; thank you for the link!
I still dont really understand what 3tool is used for. It seem the tndy nano was ment to be used on 2c0 and cannot be chaged... I just finished reading the source code and I still dont understand what it does really, except that mute thing.
It looks like the main purpose of the program is to just turn off the sound channels on the SN76489 for whichever sound card or system that is being used. I don't know all the details, but one of the quirks of the chip is that when power is initially supplied to the chip you can hear sound coming out of it (I think this is a side effect of the maximum volume being 0 rather than 15).
In the current version, if you try: SBVGM -ts2c0 file.vgm, SBVGM will use the Tandy Nano and the OPL2 portion of the Sound Blaster since it gives priority to actual SN76489 hardware. By the way the -t and -ts option do the same thing (in this case).
Yeah that work well, I dont understand what I was complaining about... probably my brain got overwhelmed with all the possibility of that new soundcard. I understand there is no way for you to detect at which address the synth is.
I'm very grateful for all the explanation you gave me about how to use sbvgm with the tndy nano, since it's the only reason why I bought this card kit. But there is another problem I havent brought with you still. Since it's an impression I wanted to make sure it was real. The bass line most often sound wrong. It look like an envelope or maybe pitch problem, I dont really know how to describe it. I'll find a music that apparently exhibit this problem and record it with the tndy nano and the sega master system. I trust you could compare it with the saa1099. The first thing I did is to check if it was not related to your note off bug fix, and it's not. I'll get back to you later about that.
Which VGM has this problem? The bass line sounding wrong is likely the note off issue. On the Master System it will work, but on an SN76489AN, it may not. I played one of those Master System VGMs you sent me on the TNDLPT using the VGM player that was made for it, and this issue exists on the SN76489AN. One reason why I wanted to verify if the same problem exists on a Tandy is to fix the notes for the proper sound chip in a future version of SBVGM.
Dual chip support for SN76489, YM3812, YM3438, YM2151
Various bug fixes
In order to better facilitate dual-chip support, a new method of treating the sound chips as a resource was added so it's now possible to mix and match different supported chipsets. In the general scenario it will "just work" in that SBVGM will attempt to auto-detect the hardware (as before) and will assign whatever is available to be a resource for VGM playback (if the sound hardware is capable). The most likely case is that it will be necessary to specify via the command line options what's available. For example, to play a VGM that supports two SN76489 chips, just specify: SBVGM -tndlpt -tndlpt278 song.vgm. In this case, it will use a TNDLPT at 0x378 and 0x278 respectively. Some VGMs which use two SN76489 have them at different clocks (typically the first is at 4MHz and the second at 2MHz). Often this was done to work around the frequency limitations encountered when an SN76489 is clocked at 3.58MHz/4MHz. In this case, notes for the second SN7689 may not sound correct due to the fact that hardware is not clocked at 2MHz; this is a hard limitation with no direct workaround. Since the SAA1099 can handle this, SBVGM -tndlpt -cmslpt278 song.vgm will allow the SAA1099 to act in place of the second SN76489.
Sound hardware is used based on the order specified (followed by SBVGM's default auto-detect order). For example, if a TexElec SAAYM and a Sound Blaster with C/MS chips are available and the desired order is SAAYM first, then Sound Blaster, the command-line setting would be: SBVGM -saaym -sbc song.vgm.
This update was a long time coming with the advent of newer hardware options that did not exist back at the initial release. I hope some will find this update useful. 😀
I'm not sure if it's possible but do you think FB-01 and/or IBM Music Feature card support could be done? Not sure how close the YM2164 is to the YM2151 but it would certainly be cool to utiluze those devices for 2151 VGM, and if not then VGM of the few games they support. More just wondering the feasibility of adding those devices to SBVGM.
I'm not sure if it's possible but do you think FB-01 and/or IBM Music Feature card support could be done? Not sure how close the YM2164 is to the YM2151 but it would certainly be cool to utiluze those devices for 2151 VGM, and if not then VGM of the few games they support. More just wondering the feasibility of adding those devices to SBVGM.
There are some minor differences between the YM2151 and YM2164, but there is currently no known way to access the YM2164 registers directly via the MIDI interface on the FB-01 and IMFC. I tried an experiment a while back for real-time VGM playback on the FB-01 and while it did (kind of) work (it involves translating the YM2151 data to the appropriate MIDI messages); the raw VGM playback rate is too high for the FB-01's MIDI interface to keep up and often ended up with the device locking up. Also, there doesn't seem to be a way to drive the noise generator via MIDI so any VGMs that use that feature would not sound correct on the FB-01.
The only way I can presently think of is to do an offline conversion the VGM data to MIDI (too much CPU required for real-time conversion) and playback as normal. I believe there are VGM to MIDI converters out there, but I don't know if they target the FB-01 or IMFC.
Alright, figured as much. Just trying to stretch my Tandy 1000 RSX into as many corners as I can with VGM playback. Thanks though!
I haven't tried it out, but this tool might do the job: New VGM to MIDI + OPM + SYSEX tool for YM2151
This sorta works, it is a nice way to get some YM2151 patches onto the FB-01. For simpler tracks it usually works pretty well, early CPS1 music especially. On more complex tracks or anything with heavy percussion usage you can tell it gets pretty far from the source, more of a gross approximation. Still a fun converter to mess with.
Alright, figured as much. Just trying to stretch my Tandy 1000 RSX into as many corners as I can with VGM playback. Thanks though!
I haven't tried it out, but this tool might do the job: New VGM to MIDI + OPM + SYSEX tool for YM2151
This sorta works, it is a nice way to get some YM2151 patches onto the FB-01. For simpler tracks it usually works pretty well, early CPS1 music especially. On more complex tracks or anything with heavy percussion usage you can tell it gets pretty far from the source, more of a gross approximation. Still a fun converter to mess with.
I do remember the early CPS1 VGMs mostly playing on the FB-01 test I did. Glad that program worked somewhat. I wish there was more software that used the FB-01 to it's fullest.
