Hi OPLx, I realized past weekend there was a problem with a soundtrack, so I wanted to investigate a bit more and post as much info about it. But as I made the package and noted the anomaly I realized that we already had a problem with this soundtrack and you fixed it in 1.14 where a vgm have ym3812 and saa1099 data. So that might explain this strange behavior (I should had started by that): on the miracle warrior soundtrack if you use the -sb options only the version with ym3812 play and that's ok. But if you use the -C (or the -c but that would be ok) then both versions play. I guess, as you noted in v1.14, it's that they have saa and opl data so the player think they can both be played. So at this point I would think that it's the soundtrack or the rip which is the problem. Still if my SWAG theory is good, I'm surprised opl version of the music play with the -C switch. So I reported that and packaged you 2 files (opl and saa version of the same music) if you ever feel to peek at issue. But I think your opl3 support is far more interesting as it would be fun to experience the difference in those two chips. That soundtrack anyway only consist of only 24 files total with the opl and saa version so it's not really a problem. But maybe it has other incidences? I guess you would prefer to know.

I noticed your web site is still down, I have a personal server and with my reverse proxy I could host http://www.oplx.com in the meantime you resolve your issue ? Just PM if I could be of assistance, I would be glad to help.

ElBrunzy wrote:

Hi OPLx, I realized past weekend there was a problem with a soundtrack, so I wanted to investigate a bit more and post as much info about it. But as I made the package and noted the anomaly I realized that we already had a problem with this soundtrack and you fixed it in 1.14 where a vgm have ym3812 and saa1099 data. So that might explain this strange behavior (I should had started by that): on the miracle warrior soundtrack if you use the -sb options only the version with ym3812 play and that's ok. But if you use the -C (or the -c but that would be ok) then both versions play. I guess, as you noted in v1.14, it's that they have saa and opl data so the player think they can both be played. So at this point I would think that it's the soundtrack or the rip which is the problem. Still if my SWAG theory is good, I'm surprised opl version of the music play with the -C switch. So I reported that and packaged you 2 files (opl and saa version of the same music) if you ever feel to peek at issue.

Thank you for the files! I will take a look at them as soon as I can; it's likely that I overlooked something somewhere. 😀

ElBrunzy wrote:

But I think your opl3 support is far more interesting as it would be fun to experience the difference in those two chips. That soundtrack anyway only consist of only 24 files total with the opl and saa version so it's not really a problem. But maybe it has other incidences? I guess you would prefer to know.

Adding OPL3 support for SN76489 data isn't impossible, but the noise channels won't sound correct on the OPL3. I will give some more thought to it though.

ElBrunzy wrote:

I noticed your web site is still down, I have a personal server and with my reverse proxy I could host http://www.oplx.com in the meantime you resolve your issue ? Just PM if I could be of assistance, I would be glad to help.

Thank you for the kind offer. I've contacted my ISP and they are looking at it; it was down for a few days before I was informed. The problem lies with the domain name itself; hopefully it will be resolved soon. I didn't think that too many people visit the site; I don't check it often myself.

I'll let you know once I get a chance to find out what the problem is. Thank you again!

(Edit)
I took a very quick look and found out that MWOPL.VGM has information that says that SN76489 data is present. I think what I need to change is to only enable chips that were detected or forced; so in this case SBVGM will still "play" MWOPL.VGM but there will not be any audio when the -C option is present because of the incorrect tagging of the SN76489 information.

OPLx wrote:

I took a very quick look and found out that MWOPL.VGM has information that says that SN76489 data is present. I think what I need to change is to only enable chips that were detected or forced; so in this case SBVGM will still "play" MWOPL.VGM but there will not be any audio when the -C option is present because of the incorrect tagging of the SN76489 information.

I read that the vgm format support many hardware into one music : it can record a practically unlimited number of sound hardware changes per sample. so it's only mwopl.vgm music that make useless call to sn76489 hardware, I understand we are not facing a bug but an unexpected operation.

Obviously your player should be the most flexible around the norm and not about workaround for "broken" music. So let's pretend we have a music that take advantage of two hardware supported by the SAA1099 [edit: not SAA76489] and OPLx (in reference of the opl2 and opl3 support, not the sbvgm author 🤣) it could be expected usage to use the automatic or -c switch to fully listen to it. But then it can get interesting to listen to only the parts of the music that use the saa or opl instruction with some forced hardware switch. But with the silent behavior you suggest I'm afraid some playlist might result in having alot of long silence one have to skip regularly. Maybe you could enforce a strict compliance switch that every hardware should be present to play a file otherwise it's auto-skipped ? Or the other way around with a relaxed switch that allow to play music even if not all hardware is present. Also, as you mentioned earlier we have to take in consideration the actual way the player work for the other users before adding anything. I really dont know anymore, maybe we could start with what you suggest and see what it gives.

ElBrunzy wrote:

I read that the vgm format support many hardware into one music : it can record a practically unlimited number of sound hardware changes per sample. so it's only mwopl.vgm music that make useless call to sn76489 hardware, I understand we are not facing a bug but an unexpected operation.

Obviously your player should be the most flexible around the norm and not about workaround for "broken" music. So let's pretend we have a music that take advantage of two hardware supported by the SAA76489 and OPLx (in reference of the opl2 and opl3 support, not the sbvgm author 🤣) it could be expected usage to use the automatic or -c switch to fully listen to it. But then it can get interesting to listen to only the parts of the music that use the saa or opl instruction with some forced hardware switch. But with the silent behavior you suggest I'm afraid some playlist might result in having alot of long silence one have to skip regularly. Maybe you could enforce a strict compliance switch that every hardware should be present to play a file otherwise it's auto-skipped ? Or the other way around with a relaxed switch that allow to play music even if not all hardware is present. Also, as you mentioned earlier we have to take in consideration the actual way the player work for the other users before adding anything. I really dont know anymore, maybe we could start with what you suggest and see what it gives.

Thanks to your requests, you managed to expose a bug in the program! 😀 If someone tried to play MWOPL.VGM on a Tandy 1000, the current version of SBVGM will still attempt to write to the OPL2 which is incorrect as data should only be sent for hardware that is actually present. So when MWOPL.VGM reports the presence of YM2413 and SN76489 and we tell SBVGM we want to hear only the SN76489 data (but there is actually none), then silence is the correct (though not desirable) result. A good example is the Sonic the Hedgehog VGM data. PCs (at least outside of Japan) didn't have the YM2612 chip and when playing these VGMs you'll only hear the SN76489 portion, but depending on where the SN76489 data is played in those files, there will only be silence until the SN76489 data is played.

In regards to your suggestion. In the present VGM format, to my knowledge, the only way to know if there is actually SN76489 data is to examine all the commands in the VGM before attempting to play. This could introduce longer delays before playback and trying to resolve the problem by having SBVGM attempt to workaround bad data of this nature is not the proper way; the right solution is to fix the bad VGM data. I think there might be tools to do this, but I am not 100% sure.

Yes I can do that with vgmtool 2. I'll fix my miracle warrior soundtrack. But I encourage you go on with your idea and make that sbvgm wont use another hardware if forced. I'll keep a bogus version of that soundtrack to test it if you ever do it.

I couldn't help myself but to upload a screenshot of vgmtool 2 because I find the little Alex Kidd head on the [Header] tab just too cute 😊

I remember I used that tool to make a .vgm rip version of the ninja gaiden trilogy .nsf for your player.

OPLx wrote:

Fox Mulder wrote:

Hello. Would somebody be so kind as to provide me with an alternate download link? The website has been dead for some days now, it seems. Thank you.

Hello, sorry about the inconvenience. I'm currently getting some DNS issues worked out with my ISP. You can download the most recent version here for the time being: SBVGM125.ZIP

Thank you! 😊

ElBrunzy wrote:

Yes I can do that with vgmtool 2. I'll fix my miracle warrior soundtrack. But I encourage you go on with your idea and make that […]
Show full quote

Yes I can do that with vgmtool 2. I'll fix my miracle warrior soundtrack. But I encourage you go on with your idea and make that sbvgm wont use another hardware if forced. I'll keep a bogus version of that soundtrack to test it if you ever do it.

I couldn't help myself but to upload a screenshot of vgmtool 2 because I find the little Alex Kidd head on the [Header] tab just too cute 😊

vgmtool.png

I remember I used that tool to make a .vgm rip version of the ninja gaiden trilogy .nsf for your player.

Glad you could fix it! Whoever made that tool was really having fun making it. 😁

Fox Mulder wrote:

OPLx wrote:

Fox Mulder wrote:

Hello. Would somebody be so kind as to provide me with an alternate download link? The website has been dead for some days now, it seems. Thank you.

Hello, sorry about the inconvenience. I'm currently getting some DNS issues worked out with my ISP. You can download the most recent version here for the time being: SBVGM125.ZIP

Thank you! 😊

You're welcome!

I'm experiencing a bug where the latest version (1.26) doesn't detect my PnP Sound Blaster 16 no matter what I do.
It just says:

1SBVGM v1.26 by OPLx
2
3Searching for sound hardware ...
4* None!

My BLASTER variable is the usual A220 I5 D1 H5 P330 T6
I tried both the 16 and 32 bit versions, in DOS (no memory manager) and in windows 98, specifying -a388 and/or -sb220 does not help.
Versions 1.25 and below work just fine.

p166s wrote:

I'm experiencing a bug where the latest version (1.26) doesn't detect my PnP Sound Blaster 16 no matter what I do. It just says: […]
Show full quote

I'm experiencing a bug where the latest version (1.26) doesn't detect my PnP Sound Blaster 16 no matter what I do.
It just says:

Copy code to clipboard

1SBVGM v1.26 by OPLx
2
3Searching for sound hardware ...
4* None!

My BLASTER variable is the usual A220 I5 D1 H5 P330 T6
I tried both the 16 and 32 bit versions, in DOS (no memory manager) and in windows 98, specifying -a388 and/or -sb220 does not help.
Versions 1.25 and below work just fine.

Thank you for letting me know about this bug. It looks like fixing one bug introduced another. 🙁 I will take a look soon and let you know.

@p166s The bug turned out to be in the auto-detection of the OPL3 chip (I'm usually testing with hardware that has an OPL2 chip). I've fixed it and you can download v1.27 from here
Thank you again for letting me know about it.

I would love to add vgm playback to a tandy 1000 game I am making. Is there a c++ library by chance? It sounds great on the tandy vgm 's I played with it.

OPLx wrote:

In case anyone is interested, I recently released a VGM player for DOS that can be downloaded here. […]
Show full quote

In case anyone is interested, I recently released a VGM player for DOS that can be downloaded here.

Supported Sound Hardware

• IBM PCJr
• Tandy 1000
• Tandy Sound (SN76489) Adapter

digress wrote:

I would love to add vgm playback to a tandy 1000 game I am making. Is there a c++ library by chance? It sounds great on the tandy vgm 's I played with it.

Unfortunately there currently isn't a library available. I haven't done any timings per se, but I would reckon that the amount of CPU time used for playback wouldn't make it suitable for games on top of the additional overhead incurred with the decoding VGM format which I don't get the impression that it was made for in-game use. @scali made a VGM player that pre-processes the VGM format to something more efficient for playback on older hardware (SBVGM supports exporting to this format), but I'm not sure how well it would be suited for games (though he did use it in a intro he released a while back).

It would take a little bit more work, but SnevenTracker might be a more viable option in terms of using the "Export text" option and writing a converter to transform the data into a useful format for playback on actual hardware. The only caveat with SnevenTracker is that you may have to replace the SN76489 emulator with an emulator that supports the Tandy 1000 variant of the chip.

There is also SnoozeTracker ... but I think SnevenTracker would be the better choice in this situation.

OPLx wrote:

@scali made a VGM player that pre-processes the VGM format to something more efficient for playback on older hardware (SBVGM supports exporting to this format), but I'm not sure how well it would be suited for games (though he did use it in a intro he released a while back).

If you would use my routine as-is, then it depends on 2 things:
1) What kind of timing does your game require?
2) What kind of music do you intend to play?

For 1), the 'issue' is that my routine uses the system timer to be able to play back any kind of VGM data, including samples, up to 44.1 kHz. If your game requires the system timer as well, this would be a problem (unless you target AT systems and can get away with using the secondary timer of the AT chipset). If your game does not require any specific timing, or you can get away with synchronizing the game on polling the vsync status, then you could use it as-is.

This brings us to 2). Most games use music that is synchronized to the display refresh. This means that you wouldn't necessarily require a system timer dedicated to the music. You could just make sure that the audio routine is called once per frame (eg during the vsync interval). With some simple modifications, my routine can be used in this way.
A big problem specific to the PC platform however, is that the refresh rate of Hercules is 50 Hz, CGA/EGA is 60 Hz and VGA is 70 Hz (although you can program custom 50 Hz and 60 Hz modes on VGA). So you can't make a single piece of music that is synced to the display refresh for all possible adapters.

Another possible issue is sound effects. VGM is very raw low-level data. If you stick to music that only uses 3 of the 4 channels, then you'd have one channel free for sound effects. Otherwise, you'd need to add logic that allows you to 'mute' one or more of the channels while your sound effect plays.

VGM is also not the most size-efficient format, so if you want to target machines with just 128k or such, you would only be able to play relatively short pieces of music before you run out of memory (I added disk streaming to my player for that reason, but that might not be too practical for a game. It also doesn't work on a real PCjr because it doesn't have a DMA controller. I think the same goes for the original Tandy 1000). Adding LZ4 compression could help there though. The data tends to compress really well. But currently there is no support for this in my player.

ok.

Their is a c library that does vgm playback for colecovision that I've been using
it supports muiltiple music songs in 1 compressed file
colecovision has Texas Instruments SN76489A PSG which is similar to the tandy and the sega master system

it updates during the video blank 60 times per second and it works well during game play.

colecovision has 1kb of ram and the z80 is 3.58mhz

digress wrote:

ok. […]
Show full quote

ok.

Their is a c library that does vgm playback for colecovision that I've been using
it supports muiltiple music songs in 1 compressed file
colecovision has Texas Instruments SN76489A PSG which is similar to the tandy and the sega master system

it updates during the video blank 60 times per second and it works well during game play.

colecovision has 1kb of ram and the z80 is 3.58mhz

Which library is this? The only one I know of is mentioned here VGM Compression Tool. That library doesn't use the VGM format as-is, but does some pre-processing and then compression on the data to make it more compact; this is similar to @scali's PRE format (but no data compression). SBVGM just uses the VGM data as-is (with no pre-processing) hence the greater overhead. Using a library (such as the one in the link) which re-arranges the data to remove the processing overhead would definitely work for your needs.

that's the same one i use. it works well. you're correct it's pre processing the vgm files in another form.

i used it to play the same songs files on the coleco as your tandy vgm player and it sounded identical.

I might have to bug tursi to get it converted to work on the tandy . Ideally under turbo c++ which is what i'm using.

Basically I am converting a colecovision game already written in c over to the tandy 1000. I got the graphics part coming along well enough.

digress wrote:

I might have to bug tursi to get it converted to work on the tandy . Ideally under turbo c++ which is what i'm using.

It shouldn't be very difficult. The SN76489 only has a single register, which is mapped to port C0h on PCjr/Tandy machines.
So you'd just have to replace the code that writes to the Coleco's SN76489 register with code that writes the same data to port C0h. Probably just means changing 1 or 2 lines.

And there's already a feature to mute channels to play sound effects, so you have that part solved as well.

Oh, there's one more thing you need to do, and that is program the 'multiplexer', which controls which audio is routed to the output.
This can be done with a simple BIOS call, int 1Ah, ah=80h, where you pass the audio source in register al, where '3' is the value for the SN76489.

1	// Audio Multiplexer is Int1A AH=80 AL=Audio source (0=PC speaker, 1=Cassette, 2=I/O channel "Audio In", 3=SN76496).
2	union REGS in, out;
3
4	in.h.ah = 0x80;
5	in.h.al = 3;
6	int86(0x1A, &in, &out);

The next best thing after I realize a new version of sbvgm is out is reading the what's new history. It's usually added support for hardware that don't concern my SB1.5+CMS setup. But this time I was very intrigued by this line of text:

1* SA1099 RP2A03 emulation improvements; use only one SA1099 instead of two

So I tested all my favorite music and see no problem, what a relief! This make me wonder how the SB1.5 achieve it's mono sound for CMS. And, just out of curiosity, why did it need 2 SAA1099 for the arduino in the first place ?

ElBrunzy wrote on 2019-12-31, 23:18:

The next best thing after I realize a new version of sbvgm is out is reading the what's new history. It's usually added support […]
Show full quote

The next best thing after I realize a new version of sbvgm is out is reading the what's new history. It's usually added support for hardware that don't concern my SB1.5+CMS setup. But this time I was very intrigued by this line of text:

Copy code to clipboard

1* SA1099 RP2A03 emulation improvements; use only one SA1099 instead of two

So I tested all my favorite music and see no problem, what a relief! This make me wonder how the SB1.5 achieve it's mono sound for CMS. And, just out of curiosity, why did it need 2 SAA1099 for the arduino in the first place ?

While I was thinking about what would be necessary to add RP2A03 DPCM support, I realized that the initial implementation didn't need to use both SAA1099 chips for the stock NES sound set up so I went ahead and cleaned things up. Having said that, DPCM support (using the SAA1099) is not likely to happen any time soon though (if at all)! 😀 It's not impossible, but requires some time to think about and implement.

By "arduino" I'm assuming you mean the emulate the NES' sound hardware? It's been a while, but I think I had initially set things up to use both chips since I was trying to figure out how to emulate the RP2A03's channel 1 and channel 2 duty cycle feature. By default the SAA1099's square waves are at 50% duty cycle, and if you use another channel on the SAA1099 at an octave higher (or something along those lines) you can fake a 25% or 75% duty cycle (I think). It's been a while since I tried that, but realized that there are limitations to that approach. There is a way to simulate duty cycles, but it comes at the cost of more CPU time. SBVGM was originally just meant to be a "simple and quick" experiment for playing NES VGMs on the SAA1099. At the time since my initial goal was realized, adding duty cycle support was outside the scope of what I wanted to verify.

I hope that answers your question!