it took me some times to get back to it, but I have good new. the vgmtool 2 release 5 option to optimize VGM and remove silent PSG/offsets fixed that "bell" issue. I have added two files to that post, the vgm is original and the .vgz is the fixed one by vgmtool. Enjoy the difference 😀 now I hope there is a way to process my files via a batch command. I think it's the offset that might had fixed the issue, I understand why people want to keep that information into the original rip. Since vgmtool is opensource maybe you would consider adding a switch to add offset ? Because your player is targeted at playing vgm on a wide variety of audio chip it would make sence to support it. Of course it's only a suggestion as I know you are busy and wanted to move on other projects.

btw why did you remove ctrl-alt-delete and pause/break function key on your program ?

i found that latest version of sbvgm (1.30) is not working well. i tried to play rydeen.vgz from vgmrips.net/packs/pack/super-locomotive-arcade which is fine when using 1.28 and the latest version skipped some segments while playing. i don't know whether it's my computer's problem because it's not original IBM5150 but a redesigned version that i mixed 5150 pcjr and xt together using 8086 with an auto adjusted 8/16 bit data bus.

another thing is that i noticed the program can not use double SN76489AN. i use two '-tnnn' options to tell the problem where they are, but it's still using first one in them, resulting in the missing of some tracks.

ElBrunzy wrote on 2020-04-05, 00:57:

it took me some times to get back to it, but I have good new. the vgmtool 2 release 5 option to optimize VGM and remove silent PSG/offsets fixed that "bell" issue. I have added two files to that post, the vgm is original and the .vgz is the fixed one by vgmtool. Enjoy the difference 😀 now I hope there is a way to process my files via a batch command. I think it's the offset that might had fixed the issue, I understand why people want to keep that information into the original rip. Since vgmtool is opensource maybe you would consider adding a switch to add offset ? Because your player is targeted at playing vgm on a wide variety of audio chip it would make sence to support it. Of course it's only a suggestion as I know you are busy and wanted to move on other projects.

Thank you for the information and the files! If I have a chance, I can look into adding an option to remove those offsets (or skip playing the note) just for non-SN76489 chipsets.

ElBrunzy wrote on 2020-04-05, 00:57:

btw why did you remove ctrl-alt-delete and pause/break function key on your program ?

Well, I never actually removed them per se. Back when I started working on SBVGM, I had initially intended the program to have some kind of graphical interface, but later decided not to bother since I didn't have much time to focus on working on the program. SBVGM takes over the keyboard interrupt and I never added in support for those key strokes; since only the ESC is read, I could probably look into removing the custom keyboard handler.

黄禄轩 wrote on 2020-04-11, 07:51:

i found that latest version of sbvgm (1.30) is not working well. i tried to play rydeen.vgz from vgmrips.net/packs/pack/super-locomotive-arcade which is fine when using 1.28 and the latest version skipped some segments while playing. i don't know whether it's my computer's problem because it's not original IBM5150 but a redesigned version that i mixed 5150 pcjr and xt together using 8086 with an auto adjusted 8/16 bit data bus.

Since I don't have a PCJr to test on, is it possible to get some kind of audio recording of the problem that you are having? I'm having trouble understanding what you mean by "skipped some segments while playing". Do you mind also trying out SBVGM v1.29 (attached to this message) and see if you have the same playback issue? There is a chance that a bug was introduced into v1.30.

黄禄轩 wrote on 2020-04-11, 07:51:

another thing is that i noticed the program can not use double SN76489AN. i use two '-tnnn' options to tell the problem where they are, but it's still using first one in them, resulting in the missing of some tracks.

For the PCJr or Tandy 1000, this is correct. When SN76489 support was originally added, there was no known way to support two of these chipsets on those platforms so you will hear sound data for the first chip. Dual SN76489 is supported on Game Blaster or the TexElec SAAYM though.

Just to make sure I understand what is going: When you play rydeen.vgz using v1.28 you are only hearing audio for the 1st SN76489 (SBVGM never could playback audio data for two SN76489s on PCJr) and the issue that you are having is the segments that are skipped in v1.30? Is this correct?

OPLx wrote on 2020-04-11, 14:22:

Since I don't have a PCJr to test on, is it possible to get some kind of audio recording of the problem that you are having? I'm having trouble understanding what you mean by "skipped some segments while playing". Do you mind also trying out SBVGM v1.29 (attached to this message) and see if you have the same playback issue? There is a chance that a bug was introduced into v1.30.

maybe my broken english is quite confusing, but what I actually mean is that the program starts to play from somewhere in the middle of the music and then suddenly jumps to another place, or repeats a small segment. I'm not quite sure whether it's because my circuit isn't very stable or there is a bug in the program because i found v1.28 is working well. and i will try v1.29 to see is it working well.

OPLx wrote on 2020-04-11, 14:22:

For the PCJr or Tandy 1000, this is correct. When SN76489 support was originally added, there was no known way to support two of these chipsets on those platforms so you will hear sound data for the first chip. Dual SN76489 is supported on Game Blaster or the TexElec SAAYM though.

I assigned two SN76489AN to io port 0xc0 and 0xc1, and I'm finding a solution to play a 2xSN76489AN vgm file. and theoretically, original pcjr is able to support many SN76496 just by connecting their clk and D[0..7] together, modifying addressing logic and wiring their audio in and out in series. and also I think if the program can support more flexible hardwares, it will be fun to build a sound card integrated many sound chips to create and play music which is more complex.

I think I can look if vgmtool can be used in batch process and convert my vgm collection because it is so better to listen to them music without the bell bug, since I now noticed it. But if you add a fix for it I wont convert files.

I was introducing your player to a friend that own a tandy 1000 with the sn76489 audio chipset and since the sb 1.5's saa1099 can reproduce both SMS PSG and NES APU I was expecting that his SMS PSG could also play some NES VGM, but apparently not. Would you be kind enough to explain why such incompatibility issue ?

OPLx wrote on 2020-04-11, 14:22:

Since I don't have a PCJr to test on, is it possible to get some kind of audio recording of the problem that you are having? I'm having trouble understanding what you mean by "skipped some segments while playing". Do you mind also trying out SBVGM v1.29 (attached to this message) and see if you have the same playback issue? There is a chance that a bug was introduced into v1.30.

well, i tried v1.29, it's working well. and i even tried to rebuild BIOS and reinstall ms-dos6.22, v1.30 is still not working. the file witch causes the problem is https://vgmrips.net/packs/pack/super-locomoti … rydeen-main-bgm

ElBrunzy wrote on 2020-04-11, 22:50:

I think I can look if vgmtool can be used in batch process and convert my vgm collection because it is so better to listen to them music without the bell bug, since I now noticed it. But if you add a fix for it I wont convert files.

It might be a while before I have a chance to add this. For the time being, you could convert the files and keep the originals as a backup.

ElBrunzy wrote on 2020-04-11, 22:50:

I was introducing your player to a friend that own a tandy 1000 with the sn76489 audio chipset and since the sb 1.5's saa1099 can reproduce both SMS PSG and NES APU I was expecting that his SMS PSG could also play some NES VGM, but apparently not. Would you be kind enough to explain why such incompatibility issue ?

In the current version of SBVGM, there is no support for playing NES VGMs on the SN76489. If you remember, SBVGM was originally an experiment to play NES VGMs on the SAA1099 since I could program the SAA1099 to simulate the NES APU (except for the DPCM and the duty cycles). Support was never added simply because up until now, no one ever mentioned anything about it. 😀

The SN76489 at the NTSC clock speed on the Tandy can't reproduce the full frequency range that the NES APU does so it's possible that certain NES VGMs simply won't sound correct or good on the SN76489. A while back someone on YouTube did this trick where they assigned the NES channel 3 playback to the PC speaker which seems to work (but no volume control on the PC speaker). You can listen to that here: Tandy 1000 Soundchip revisited: ASM programming example

Having said that, apparently certain Tandy 1000 models have what is called "PSSJ sound" and from what I read the PSSJ SN76489 variant has additional support for duty cycles. Since I don't have access to such hardware, there's no way to be sure of how it works; I haven't seen or heard of any other software that uses the duty cycles.

There is the CMSLPT : Creative music system (game blaster) on parallel port that is being worked on, but it may be a while before that is available (I'm waiting for it too!).

黄禄轩 wrote on 2020-04-12, 07:03:

OPLx wrote on 2020-04-11, 14:22:

Since I don't have a PCJr to test on, is it possible to get some kind of audio recording of the problem that you are having? I'm having trouble understanding what you mean by "skipped some segments while playing". Do you mind also trying out SBVGM v1.29 (attached to this message) and see if you have the same playback issue? There is a chance that a bug was introduced into v1.30.

well, i tried v1.29, it's working well. and i even tried to rebuild BIOS and reinstall ms-dos6.22, v1.30 is still not working. the file witch causes the problem is https://vgmrips.net/packs/pack/super-locomoti … rydeen-main-bgm

Thank you for trying out v1.29. Is there a way to get an audio recording (wav or mp3 file) of this problem? I have a TNDLPT that I test with and I don't seem to hear any differences between v1.29 and v1.30 so it's difficult for me to know what the "skipped some segments while playing" problem may be. Since v1.29 works without any problems, it's not your machine but an issue in v1.30.

OPLx wrote on 2020-04-12, 13:37:

黄禄轩 wrote on 2020-04-12, 07:03:

OPLx wrote on 2020-04-11, 14:22:

Since I don't have a PCJr to test on, is it possible to get some kind of audio recording of the problem that you are having? I'm having trouble understanding what you mean by "skipped some segments while playing". Do you mind also trying out SBVGM v1.29 (attached to this message) and see if you have the same playback issue? There is a chance that a bug was introduced into v1.30.

well, i tried v1.29, it's working well. and i even tried to rebuild BIOS and reinstall ms-dos6.22, v1.30 is still not working. the file witch causes the problem is https://vgmrips.net/packs/pack/super-locomoti … rydeen-main-bgm

Thank you for trying out v1.29. Is there a way to get an audio recording (wav or mp3 file) of this problem? I have a TNDLPT that I test with and I don't seem to hear any differences between v1.29 and v1.30 so it's difficult for me to know what the "skipped some segments while playing" problem may be. Since v1.29 works without any problems, it's not your machine but an issue in v1.30.

since i can't upload mp4 file so there's a link to the video. https://b23.tv/av625205199 (i think it's easy to know how to play although it's a website in Chinese)

黄禄轩 wrote on 2020-04-11, 19:44:

OPLx wrote on 2020-04-11, 14:22:

Since I don't have a PCJr to test on, is it possible to get some kind of audio recording of the problem that you are having? I'm having trouble understanding what you mean by "skipped some segments while playing". Do you mind also trying out SBVGM v1.29 (attached to this message) and see if you have the same playback issue? There is a chance that a bug was introduced into v1.30.

maybe my broken english is quite confusing, but what I actually mean is that the program starts to play from somewhere in the middle of the music and then suddenly jumps to another place, or repeats a small segment. I'm not quite sure whether it's because my circuit isn't very stable or there is a bug in the program because i found v1.28 is working well. and i will try v1.29 to see is it working well.

I somehow missed this message on only saw the other one. Please don't worry about your English; I think it's perfectly all right. When you mentioned about "skipped some segments" several different meanings (in terms of what SBVGM is doing internally) came to mind and hearing the problem makes it easier for me to try to determine what is happening.

黄禄轩 wrote on 2020-04-11, 19:44:

OPLx wrote on 2020-04-11, 14:22:

For the PCJr or Tandy 1000, this is correct. When SN76489 support was originally added, there was no known way to support two of these chipsets on those platforms so you will hear sound data for the first chip. Dual SN76489 is supported on Game Blaster or the TexElec SAAYM though.

I assigned two SN76489AN to io port 0xc0 and 0xc1, and I'm finding a solution to play a 2xSN76489AN vgm file. and theoretically, original pcjr is able to support many SN76496 just by connecting their clk and D[0..7] together, modifying addressing logic and wiring their audio in and out in series. and also I think if the program can support more flexible hardwares, it will be fun to build a sound card integrated many sound chips to create and play music which is more complex.

I do agree that having that support for different hardware configurations is useful. When SBVGM was originally written it was just meant to be a quick experiment for another chipset so there was not too much consideration given to supporting different hardware and configurations. One thing I tried to make a requirement was to make sure I can test SBVGM on actual hardware as the classic PC architecture can be difficult to program for given the various chipsets and standards. Also time to work on the program generally is sparse so I tend to lean more towards the standard hardware configurations that the PC had in the past. I'll give support for dual hardware some thought and whenever I have a chance, I may be able to add it in.

黄禄轩 wrote on 2020-04-13, 05:13:

OPLx wrote on 2020-04-12, 13:37:

黄禄轩 wrote on 2020-04-12, 07:03:

well, i tried v1.29, it's working well. and i even tried to rebuild BIOS and reinstall ms-dos6.22, v1.30 is still not working. the file witch causes the problem is https://vgmrips.net/packs/pack/super-locomoti … rydeen-main-bgm

Thank you for trying out v1.29. Is there a way to get an audio recording (wav or mp3 file) of this problem? I have a TNDLPT that I test with and I don't seem to hear any differences between v1.29 and v1.30 so it's difficult for me to know what the "skipped some segments while playing" problem may be. Since v1.29 works without any problems, it's not your machine but an issue in v1.30.

since i can't upload mp4 file so there's a link to the video. https://b23.tv/av625205199 (i think it's easy to know how to play although it's a website in Chinese)

Thank you for the video. I can hear what you mean now! 😁 That is some very custom hardware! How fast is it running? It also sounds like the SN76489 is clocked at a higher clock rate than the standard NTSC 3.579545 speed. The main differences between v1.29 and v1.30 was adding support for playback of YM2612 VGMs files on the TexElec SAAYM hardware. There were some adjustments made to the SN76489 volume levels (when YM2612 VGMs are played), but nothing that would cause the program to skip over the audio.

I will still take a look and see what else may have changed, but one thing that comes to my mind is that it seems that your hardware's timer clock isn't stable; it runs quickly in some cases or slowly in others. I can't say for sure though. Unfortunately I don't have access to a machine that's 4.77MHz to compare with so it could be a while before tracking down the true source of the problem.

OPLx wrote on 2020-04-13, 09:31:

黄禄轩 wrote on 2020-04-13, 05:13:

OPLx wrote on 2020-04-12, 13:37:

Thank you for trying out v1.29. Is there a way to get an audio recording (wav or mp3 file) of this problem? I have a TNDLPT that I test with and I don't seem to hear any differences between v1.29 and v1.30 so it's difficult for me to know what the "skipped some segments while playing" problem may be. Since v1.29 works without any problems, it's not your machine but an issue in v1.30.

since i can't upload mp4 file so there's a link to the video. https://b23.tv/av625205199 (i think it's easy to know how to play although it's a website in Chinese)

Thank you for the video. I can hear what you mean now! 😁 That is some very custom hardware! How fast is it running? It also sounds like the SN76489 is clocked at a higher clock rate than the standard NTSC 3.579545 speed. The main differences between v1.29 and v1.30 was adding support for playback of YM2612 VGMs files on the TexElec SAAYM hardware. There were some adjustments made to the SN76489 volume levels (when YM2612 VGMs are played), but nothing that would cause the program to skip over the audio.

I will still take a look and see what else may have changed, but one thing that comes to my mind is that it seems that your hardware's timer clock isn't stable; it runs quickly in some cases or slowly in others. I can't say for sure though. Unfortunately I don't have access to a machine that's 4.77MHz to compare with so it could be a while before tracking down the true source of the problem.

the machine is basically IBM-PC compatible and the CPU is 8086 running at 4.77MHz with 16bits width data bus directly running to the SRAM. so i think why it slows down is just that the CPU is full loaded. because if it were the system clock that cause the slowly playing, the frequency of every tone should drop together. (Asking myself over and over again: is the subjunctive tone corret?)

It would be easy to support more frequencys on TNDY Soundcard and also another SN76489..

So the SN76489 is simply connected to input of each other ? no Stereo ?

黄禄轩 wrote on 2020-04-13, 09:53:

the machine is basically IBM-PC compatible and the CPU is 8086 running at 4.77MHz with 16bits width data bus directly running to the SRAM. so i think why it slows down is just that the CPU is full loaded. because if it were the system clock that cause the slowly playing, the frequency of every tone should drop together. (Asking myself over and over again: is the subjunctive tone corret?)

I'm sorry, I should have said that the timer driven by the PIC may be what's affected which could cause the playback to slow down or speed up. I'm guessing that the SN76489 is clocked at 4.77MHz? If this is the case, then that would explain why the notes sound at a slightly higher pitch than what the original VGM plays back at. I'll send you a private message to see if I can get more details from you.

matze79 wrote on 2020-04-13, 09:59:

It would be easy to support more frequencys on TNDY Soundcard and also another SN76489..

So the SN76489 is simply connected to input of each other ? no Stereo ?

I'm not sure what his hardware set up is, but some dual SN76489 VGMs have a "stereo" configuration while others use the extra chip to add more channels. I suppose some kind of software switch on the card could allow the selection of either configuration ... though there would be no current software to support it.

OPLx wrote on 2020-04-13, 11:49:

黄禄轩 wrote on 2020-04-13, 09:53:

the machine is basically IBM-PC compatible and the CPU is 8086 running at 4.77MHz with 16bits width data bus directly running to the SRAM. so i think why it slows down is just that the CPU is full loaded. because if it were the system clock that cause the slowly playing, the frequency of every tone should drop together. (Asking myself over and over again: is the subjunctive tone corret?)

I'm sorry, I should have said that the timer driven by the PIC may be what's affected which could cause the playback to slow down or speed up. I'm guessing that the SN76489 is clocked at 4.77MHz? If this is the case, then that would explain why the notes sound at a slightly higher pitch than what the original VGM plays back at. I'll send you a private message to see if I can get more details from you.

i tried slow irq0 version and found speed problem did improved, i recorded a video and analysed it and found it is playing faster and in some section which is obviously slower than normal speed now is pretty closed to the normal speed. and another important clue is that both v1.30, v1.30s and v1.30_before_release work well when running in debug.exe and crash without it (v1.30s prints strange string and causes divide overflow, the other two just not working properly). which is probably because something is wrong in my own BIOS, and would you mind I do some reverse engineering to figure out what causes it crash?

黄禄轩 wrote on 2020-04-13, 13:54:

i tried slow irq0 version and found speed problem did improved, i recorded a video and analysed it and found it is playing faster and in some section which is obviously slower than normal speed now is pretty closed to the normal speed. and another important clue is that both v1.30, v1.30s and v1.30_before_release work well when running in debug.exe and crash without it (v1.30s prints strange string and causes divide overflow, the other two just not working properly). which is probably because something is wrong in my own BIOS, and would you mind I do some reverse engineering to figure out what causes it crash?

Thank you for the feedback. Since the slow IRQ version updates at 60Hz, there is nothing in SBVGM that changes speed during playback; all that happens is data is sent to the sound chip based on the delays from the VGM data. I also took a look at the dump of the VGM data itself and I did not see anything that looks unusual.

One thing the program does do is check to see if it is running on actual PCJr or Tandy 1000 hardware by reading address F000:FFFE (for PCJr) and address F000:C000 (for Tandy 1000) if it detected the appropriate value (FDh for PCJr) or (21h for Tandy 1000) it will set up the multiplexer via BIOS INT 1Ah, passing in 80h in AH and 3h in AL. On program exit, 0h is passed in AL and INT 1Ah is triggered. Maybe this could be what's causing issues on your hardware or BIOS?

OPLx wrote on 2020-04-13, 14:32:

Thank you for the feedback. Since the slow IRQ version updates at 60Hz, there is nothing in SBVGM that changes speed during playback; all that happens is data is sent to the sound chip based on the delays from the VGM data. I also took a look at the dump of the VGM data itself and I did not see anything that looks unusual.

I guess what's going on is similar to lots of keys press in a short time making midi player software struck.

OPLx wrote on 2020-04-13, 14:32:

One thing the program does do is check to see if it is running on actual PCJr or Tandy 1000 hardware by reading address F000:FFFE (for PCJr) and address F000:C000 (for Tandy 1000) if it detected the appropriate value (FDh for PCJr) or (21h for Tandy 1000) it will set up the multiplexer via BIOS INT 1Ah, passing in 80h in AH and 3h in AL. On program exit, 0h is passed in AL and INT 1Ah is triggered. Maybe this could be what's causing issues on your hardware or BIOS?

i checked F000:FFFE and the model byte i filled is 0FEh means pc txt 11/8/1982 version, so it's OK. and it 1Ah, if ah is above 7 then immediately return with CF set so it can't cause crash. there must be some other problems. i think maybe some routine destroy the stack. i'm working on it.

OPLx wrote on 2020-04-13, 11:53:

matze79 wrote on 2020-04-13, 09:59:

It would be easy to support more frequencys on TNDY Soundcard and also another SN76489..

So the SN76489 is simply connected to input of each other ? no Stereo ?

I'm not sure what his hardware set up is, but some dual SN76489 VGMs have a "stereo" configuration while others use the extra chip to add more channels. I suppose some kind of software switch on the card could allow the selection of either configuration ... though there would be no current software to support it.

yeah simple stereo / mono switch (mix both outputs)