After redownloading SBVGM v1.16, it no longer freezes on the Tandy 1000 TX. Must have previously been a bad sector or something.

Which brings me to two lesser issues: SAA1099 .VGM files cannot be played back on the CMS-chips-having Sound Blaster 1.5 even with the -c option specified on the command line, claiming that no suitable hardware has been found. Apparently, it performs some misguided checks even if -c is specified. The BLASTER environment variable is "A220 I7 D1 T1". I have to specify the -gb option, which would preclude the playback of files that use the SAA1099 chips together with the YM3812 (not that I currently have any).

The second issue: The attached NES .VGM sounds out of tune when played back on the Sound Blaster 1.5 using the CMS chips; apparently the frequencies of the triangle channels are not correctly converted. This may well be a limitation of the SAA1099, but I thought I should let you know.

Edit: I suppose I should attach the NES .VGM, not the DOSBox-captured .VGM of SBVGM's SAA1099 output.

Jepael wrote:

But there are also rumours that if you try to access the CMS chips while the sockets are empty, it hangs the machine, as there is nothing to generate DTACK signal so ISA bus cycle is lengthened forever with IOCHRDY.

That is correct --- an SB 1.5 without CMS chips will freeze the system if the CMS I/O addresses are written to. Reading the CMS I/O addresses only yields FF with or without installed chips, but does not freeze the system. On the SB 2.0, writing to the CMS I/O addresses will not freeze the system if the chips are not installed, and reading them will yield different results depending on whether the chips are installed or not.

NewRisingSun wrote:

After redownloading SBVGM v1.16, it no longer freezes on the Tandy 1000 TX. Must have previously been a bad sector or something.

That's a relief to hear! Thank you for checking.

NewRisingSun wrote:

Which brings me to two lesser issues: SAA1099 .VGM files cannot be played back on the CMS-chips-having Sound Blaster 1.5 even with the -c option specified on the command line, claiming that no suitable hardware has been found. Apparently, it performs some misguided checks even if -c is specified. The BLASTER environment variable is "A220 I7 D1 T1". I have to specify the -gb option, which would preclude the playback of files that use the SAA1099 chips together with the YM3812 (not that I currently have any).

Do you mind sending me any example VGM files that exhibit this issue? I haven't (yet) come across any VGMs that use both the SAA1099 chips and YM3812 chip directly, so it's likely that the VGM in question has some other information that causes playback to fail. SBVGM converts Xak: The Art of Visual Stage's AY-3-8910 and YM2413 commands to SAA1099 and YM3812 commands respectively, but it's definitely not the same as "native" SAA1099 + YM3812 data.

NewRisingSun wrote:

The second issue: The attached NES .VGM sounds out of tune when played back on the Sound Blaster 1.5 using the CMS chips; apparently the frequencies of the triangle channels are not correctly converted. This may well be a limitation of the SAA1099, but I thought I should let you know.

This is a limitation of the SAA1099 when using the envelope generator to create a triangle waveform. I don't have the data in front of me, but the NES APU triangle channel has a much higher frequency range than the SAA1099. Unfortunately, there was either the option of playing the highest frequency possible (which won't sound correct) or no sound at all.

OPLx wrote:

Do you mind sending me any example VGM files that exhibit this issue?

Every file that uses the SAA1099, be it directly or via NES APU->SAA1099 conversion. The problem is not file-specific; it is that "SBVGM -c file.vgm" works in DOSBox with "sbtype=sb1/sb2" but not on real hardware. When specifying "-c", SBVGM displays "Sound Blaster(C/MS)" in DOSBox, but on real hardware, just "Sound Blaster". It must do some ill-advised detection of Sound Blaster versus Sound Blaster Pro/16 that fails on real hardware. A quick debugging session seems to indicate an access to the mixer registers, although I cannot quite make out what it does there.

NewRisingSun wrote:

Every file that uses the SAA1099, be it directly or via NES APU->SAA1099 conversion. The problem is not file-specific; it is that "SBVGM -c file.vgm" works in DOSBox with "sbtype=sb1/sb2" but not on real hardware. When specifying "-c", SBVGM displays "Sound Blaster(C/MS)" in DOSBox, but on real hardware, just "Sound Blaster". It must do some ill-advised detection of Sound Blaster versus Sound Blaster Pro/16 that fails on real hardware. A quick debugging session seems to indicate an access to the mixer registers, although I cannot quite make out what it does there.

Hello!
Hardware playback (with the -c option) should work when the appropriate BLASTER environment variable is present (I have it working on my SB1.5 as I'm typing). There should definitely not be any access to the SB mixer ports (base + 0x4 or base + 0x5); if there is no BLASTER environment set, SBVGM attempts to detect what kind of Sound Blaster maybe present via querying the DSP version across the valid SB port ranges. There is definitely an issue though when the environment variable is not present; I will have to look into why this is the case. Thank you for pointing this out!

[EDIT]
I took a quick look at the problem and there is a bug where though the Sound Blaster DSP version is detected correctly, which SB type is not set and as a result SBVGM attempts to detect the FM chip at the incorrect base address which will fail for SB 1.x or 2.x. For the time being entering SBVGM -sb -c file.vgm should allow proper hardware playback. I will try to get this fixed some time in the next few days.

OPLx wrote:

Hardware playback (with the -c option) should work when the appropriate BLASTER environment variable is present (I have it working on my SB1.5 as I'm typing).

It doesn't here. That's the problem. With or without BLASTER=, with or without -sb, but always tried with -c. Maybe you could isolate just the code that decides between "Sound Blaster at 220h" and "Sound Blaster(C/MS) at 220h", so I can trace through it on the Tandy 1000 TX with DEBUG to see what the problem is (the Tandy is too weak to run any fancy debugger).

NewRisingSun wrote:

OPLx wrote:

Hardware playback (with the -c option) should work when the appropriate BLASTER environment variable is present (I have it working on my SB1.5 as I'm typing).

It doesn't here. That's the problem. With or without BLASTER=, with or without -sb, but always tried with -c. Maybe you could isolate just the code that decides between "Sound Blaster at 220h" and "Sound Blaster(C/MS) at 220h", so I can trace through it on the Tandy 1000 TX with DEBUG to see what the problem is (the Tandy is too weak to run any fancy debugger).

I think I understand what you mean now. I probably could not reproduce since I don't have a Tandy to test on. Do you mind trying SBVGM v1.17? I (foolishly) stayed up late to fix the other bug. Perhaps this will resolve it? If not, I will try to see what I can do to help address the problem that you are running into.

That did not take care of the problem. SBVGM -c file VGM detects the SB but not the CMS chips, while SBVGM -sb -c does not even detect the Sound Blaster.

I tried debugging SBVGM, but gave up after spending twenty minutes in string-handling functions and various internal structure massaging with no hardware accesses at all.

NewRisingSun wrote:

That did not take care of the problem. SBVGM -c file VGM detects the SB but not the CMS chips, while SBVGM -sb -c does not even detect the Sound Blaster.

I tried debugging SBVGM, but gave up after spending twenty minutes in string-handling functions and various internal structure setups with no hardware accesses at all.

Sorry to hear about that. The -c option only forces the usage of the C/MS chips since they can't be auto detected on the SB 1.x/2.x series. I'll send you a private message to figure out how to resolve this problem.

With help from NewRisingSun, the hardware issue was resolved and v1.18 can be downloaded from here.

How do you listen to your .vgm/.vgz with sbvgm.exe ?

I run freedos, altho people on vgmrip.net told me sbvgm work on win9x fullscreen (I dont trust win9x timings anyway), and when come the time to play .vg? I use command.com. I have classified my collection by system then title name (ie.: /nes/castlev1) and use a "for %%F" batch loop.

I would like to have a file browser to build a playlist then call sbvgm to play each file. I did try some file commander, quickview, mpxplay, cubicplayer, dualmodulecompanion but found none could do that.

ElBrunzy wrote:

How do you listen to your .vgm/.vgz with sbvgm.exe ?

I run freedos, altho people on vgmrip.net told me sbvgm work on win9x fullscreen (I dont trust win9x timings anyway), and when come the time to play .vg? I use command.com. I have classified my collection by system then title name (ie.: /nes/castlev1) and use a "for %%F" batch loop.

I would like to have a file browser to build a playlist then call sbvgm to play each file. I did try some file commander, quickview, mpxplay, cubicplayer, dualmodulecompanion but found none could do that.

Hello! Believe it or not, I actually use SBVGM in fullscreen under WinME since that allows me to copy files to the machine over a network during testing. The timings are 100% all right if you run in fullscreen; though the OS can sometimes cause some skips if the screen saver turns on or the machine is put into power saving mode.

I did some tests under FreeDOS and it worked all right. I don't recall any utilities that allow one to build a "playlist" or execution list of sorts for batch files.

At present, I generally just play files via batch a file that plays all the files found in a particular directory.

I did try on sbvgm 1.5 and with 1.8 and with 1.8 with -x and a memory manager: those music always crash the player. On 1.5 it just freeze and on 1.8 it give invalid opcode 017 if using no xms and otherwise the memory manager just crash dump. I did not try it on windows. Those are two very good vgm music from sega master system's Phantays Star : the story and the medusa tower. I attach them both to this message. I hate to be reporting a problem but I believe that's how we can help you make a better player. The fm version of those game work fine, they are saa1099 who are bad.

ElBrunzy wrote:

I did try on sbvgm 1.5 and with 1.8 and with 1.8 with -x and a memory manager: those music always crash the player. On 1.5 it just freeze and on 1.8 it give invalid opcode 017 if using no xms and otherwise the memory manager just crash dump. I did not try it on windows. Those are two very good vgm music from sega master system's Phantays Star : the story and the medusa tower. I attach them both to this message. I hate to be reporting a problem but I believe that's how we can help you make a better player. The fm version of those game work fine, they are saa1099 who are bad.

Thank you for reporting the problem! There are so many VGMs that have been made it is simply impossible for me to test all of them. 😀 In this case, the problem was that the VGM file reports that it does not use the YM2413 FM chip, but there is one VGM command that sends data to the chip. I've updated the player to ignore this command in this case and you can find the latest version of SBVGM here.

Thank you again for reporting the problem! 😀

wow thank you so much, now I can listen the entire Phantasy Star on SN76489 without a crash, it means so much to me 😀

story.vgm : music heard when you meet a new companion on your rpg quest.
medusa.vgm : was the music of the most difficult dungeons!

ElBrunzy wrote:

wow thank you so much, now I can listen the entire Phantasy Star on SN76489 without a crash, it means so much to me 😀

story.vgm : music heard when you meet a new companion on your rpg quest.
medusa.vgm : was the music of the most difficult dungeons!

You're quite welcome! Thank you for helping to find the bugs! 😀

Hello, OPLx

Do you plan to open source? I want make DOS player YM2149F/AY-3-8910 chiptunes for Creative Music System/Game Blaster but unfortunately, i cant understand how convert envelope... My first attempt: http://www.vcfed.org/forum/showthread.php?599 … em-Game-Blaster

Thank you.

Tronix wrote:

Hello, OPLx

Do you plan to open source? I want make DOS player YM2149F/AY-3-8910 chiptunes for Creative Music System/Game Blaster but unfortunately, i cant understand how convert envelope... My first attempt: http://www.vcfed.org/forum/showthread.php?599 … em-Game-Blaster

Thank you.

Yes, I am planning to release the source: It just needs some cleaning up a little, but I keep getting side-tracked with other more pressing obligations. 😢 I currently don't have direct access to the development machine that has the source, but hopefully sometime soon ... though I honestly can't give a concrete time.

The envelopes on available on the SAA1099 do not necessary match the envelopes on YM2149F/AY-3-8910; so without doing some additional work behind the scenes (essentially generating your own envelopes using the external envelope clock on the SAA1099), it will be very tricky to get the exact same sound on the SAA1099.

I took a look at the comments on the vcfed.org link and here's my my thoughts (based on my experiences):

• The current DOSBox SAA1099 has a bug with envelope emulation. It is kind of there, but the way it gets mixed with the PWM output is wrong. You can download CMSVIEW (a test program I wrote) to play around with the SAA1099 registers from here. Of course, if you are working with actual hardware then no worries. 😀
• In SBVGM, there is minor support for YM2149F/AY-3-8910 envelopes, but that was simply done by trying to match between the chips what was similar based on the datasheet descriptions.

If there's anything else you would like to know, please feel free to ask.

Added support for OPL3LPT to SBVGM. It can be downloaded from this link: http://www.oplx.com/code/

Congratulation on your new hardware support. I'm certain your player will make many owner of the opl3lpt glad, it can only be good this way.

Thank you. It's a really nice piece of hardware. 😀