黄禄轩 wrote on 2020-06-10, 10:32:

although i didn't build any pull up res to the data bus, it shouldn't cause the problem. i tried to use debug.exe to figure out […]
Show full quote

NewRisingSun wrote on 2020-06-10, 10:05:

In what kind of computer? If the computer has no pull-up resistors on the ISA bus, the documented "port 388 returns 06" check will not work correctly.

although i didn't build any pull up res to the data bus, it shouldn't cause the problem. i tried to use debug.exe to figure out what's wrong, and the result shows that the hardware is correct.

================
debug:
-o388 4
-o389 e0
-i388
06
-o388 2
-o389 ff
-o388 4
-o389 21
-i388
C6
-

Hello, I noticed that your DEBUG sequence writes e0h to address 4 rather than 60h and 80h separately. Also, there is no sequence at the end for resetting the timers and the IRQ. This last part is what is used to determine whether an OPL2 or OPL3 is present.

Could you try this DEBUG sequence?
=====
-0388 4
-0389 60
-0388 4
-0389 80
-i388
[result]
-o388 2
-o389 ff
-o388 4
-o389 21
-i388
[result]
-0388 4
-0389 60
-0388 4
-0389 80
-i388
[result]
=====

For the OPL2, the result sequence should be: 06, C6, and 06.
For the OPL3, the result sequence should be: 00, C0, and 00.

My guess is that your hardware may be returning some value that when ANDed with 06h returns 00h. If this is the case, @NewRisingSun's suggestion might resolve the problem.

OPLx wrote on 2020-06-10, 12:53:

For the OPL2, the result sequence should be: 06, C6, and 06.
For the OPL3, the result sequence should be: 00, C0, and 00.

I got 06,C6,06 but OPL3 is "detected".

黄禄轩 wrote on 2020-06-10, 13:39:

OPLx wrote on 2020-06-10, 12:53:

For the OPL2, the result sequence should be: 06, C6, and 06.
For the OPL3, the result sequence should be: 00, C0, and 00.

I got 06,C6,06 but OPL3 is "detected".IMG_20200610_213456.jpgIMG_20200610_213505.jpg

Thank you for the information. This is very strange. Do you mind running OPLCHECK (it's hard coded to check address 388h) and tell me what the output is? I've attached the ZIP file to this message.

1 means OPL2 detected, 3 means OPL3 detected, and the value in parenthesis is the result returned from reading port 388h after the detection sequence is finished.

Thank you.

OPLx wrote on 2020-06-10, 14:18:

1 means OPL2 detected, 3 means OPL3 detected, and the value in parenthesis is the result returned from reading port 388h after the detection sequence is finished.

well, it's becoming more and more confusing...

黄禄轩 wrote on 2020-06-10, 14:37:

OPLx wrote on 2020-06-10, 14:18:

1 means OPL2 detected, 3 means OPL3 detected, and the value in parenthesis is the result returned from reading port 388h after the detection sequence is finished.

IMG_20200610_223321.jpg
well, it's becoming more and more confusing...

I think I see what the problem is now. SBVGM uses method 2 which checks for the value of 6 after ANDing with 6h (which is not really reliable apparently), and method 1 checks for the value of 0h after ANDing with 6h.

All of the OPL2-based hardware I had tested with always returned 6h after the final timer and IRQ reset. I’m not sure why your system returns 0h (with method 2). The only thing I can think of is that the clock feeding the OPL2 isn’t running exactly at 3.579545 MHz or there is some kind of interference coming in from another source. All OPLCHECK does is set up the hardware timers for the purpose of detection. When we use DEBUG to write and read the values, it’s likely because our response time for entering the values is much slower we see the correct results; the CPU sending and reading the data is much faster.

Either way, I’ll fix this in the next day or two (in v1.32) since method 1 is the more reliable approach.

Thank you for bring up this problem.

OPLx wrote on 2020-06-10, 15:09:

I think I see what the problem is now. SBVGM uses method 2 which checks for the value of 6 after ANDing with 6h (which is not r […]
Show full quote

黄禄轩 wrote on 2020-06-10, 14:37:

OPLx wrote on 2020-06-10, 14:18:

1 means OPL2 detected, 3 means OPL3 detected, and the value in parenthesis is the result returned from reading port 388h after the detection sequence is finished.

IMG_20200610_223321.jpg
well, it's becoming more and more confusing...

I think I see what the problem is now. SBVGM uses method 2 which checks for the value of 6 after ANDing with 6h (which is not really reliable apparently), and method 1 checks for the value of 0h after ANDing with 6h.

All of the OPL2-based hardware I had tested with always returned 6h after the final timer and IRQ reset. I’m not sure why your system returns 0h (with method 2). The only thing I can think of is that the clock feeding the OPL2 isn’t running exactly at 3.579545 MHz or there is some kind of interference coming in from another source. All OPLCHECK does is set up the hardware timers for the purpose of detection. When we use DEBUG to write and read the values, it’s likely because our response time for entering the values is much slower we see the correct results; the CPU sending and reading the data is much faster.

Either way, I’ll fix this in the next day or two (in v1.32) since method 1 is the more reliable approach.

Thank you for bring up this problem.

well, solved by pull up res...

and i also tried some special designed program
mov dx,388
in al,dx
db ff ff
db ff ff
db ff ff
db ff ff
int 1
int 20

and

mov dx,388
in al,dx
push di
push di
push di
push di
push di
push di
push di
push di
add sp,10
int 1
int 20

so i think maybe the YM3812 uses OC outputs on D0 to D4 which is never documented in the datasheet so it won't work correctly without pull-up resistor

my suggestions is using the second program i provide. low 3bits of "push di" is both 1 so it will pull the databus high before executing "in al,dx" because the CPU will firstly fill the instruction queue then start execute which i have proved on intel original 8086 with logic analyzer.

by the way, repeating "xchg di,ax" for 8 times maybe better

OPLx wrote on 2020-06-10, 15:09:

When we use DEBUG to write and read the values, it’s likely because our response time for entering the values is much slower we see the correct results; the CPU sending and reading the data is much faster.

i think maybe it just because a byte following the in instruction in the DEBUG.EXE pulled the data bus high. i tried my ROM_DBG which i built into my bios and with the same command line i get 04 which also proves my theory right.

so basically it's a hardware bug which i think it may had happened on other some computers too. (i used the word "basically" because i doun't have any oscilloscope to see what actually is going on)

OPLx wrote on 2020-06-10, 15:09:

The only thing I can think of is that the clock feeding the OPL2 isn’t running exactly at 3.579545 MHz or there is some kind of interference coming in from another source.

this time i have already build a fourfold frequency divider to provide an enough accurate 3.57MHz clock to all these chips including those two SN76489AN i was working on month before.

and by the way do you know how fast the clock should be sending to the SAAYM and OPL3, i found nothing about it for some "All-Chinese-Know"-Reason

Thank you for all your suggestions; it's clearer now what is going on. It is tempting to try that method, but I'm not sure if that will have the same behavior on later generations of the x86 architecture (especially the Pentium line), but it's something that I will try to keep in mind. Software DOS PCs is always a challenge because so many different architectures and variants exist. 😀

黄禄轩 wrote on 2020-06-10, 15:59:

this time i have already build a fourfold frequency divider to provide an enough accurate 3.57MHz clock to all these chips including those two SN76489AN i was working on month before.

That's wonderful to hear! Many years ago, I had a USB device that allowed the use of ISA hardware and found out that the clock speed was slower than the recommended ISA speeds.

黄禄轩 wrote on 2020-06-10, 15:59:

and by the way do you know how fast the clock should be sending to the SAAYM and OPL3, i found nothing about it for some "All-Chinese-Know"-Reason

The SAAYM supports two clock speeds: The standard ISA bus speed of 14.31818 MHz (from the ISA bus) and 8 MHz (which I believe is a separate clock crystal on the card). For the YM2151, there is a jumper that allows selection of either 3.579545 MHz (ISA) or 4 MHz (from the separate clock). For the SAA1099 chips, there is a separate jumper which allows selection of 7.15909 MHz (ISA - for Game Blaster compatibility) or 8 MHz (from the separate clock).

For the OPL3, 14.31818 MHz is what is used to drive the IC.

I just spent some time thinking about the final result of the detection sequence. The value of 06h should be correct for the OPL2, so I think it may not be necessary to change SBVGM's detection routine. When I have time, I'll do some tests with the OPL2 Audio Board and see what values the OPL2 returns to verify.

Hi OPLx, do you think this kind of soundcard would work well with sbvgm ? If your player already work well on tandy I have high hopes it can be used on a clone pc. Tandy Nano - 3 Voice Soundcard ISA - Lowprofile

ElBrunzy wrote on 2020-06-27, 21:57:

Hi OPLx, do you think this kind of soundcard would work well with sbvgm ? If your player already work well on tandy I have high hopes it can be used on a clone pc. Tandy Nano - 3 Voice Soundcard ISA - Lowprofile

If it works with other Tandy 1000 software (like those Sierra games), I don't see why it wouldn't work with SBVGM. SBVGM won't be able to auto-detect the soundcard, but it is possible to tell the program to use the soundcard via the -ts command line option.

it works without any problems with any variant of the card.

Support for Serge's CMS2LPT planned?

matze79 wrote on 2020-06-29, 09:03:

it works without any problems with any variant of the card.

Happy to hear that! Thank you for confirming this. 😀

jaZz_KCS wrote on 2020-06-29, 09:04:

Support for Serge's CMS2LPT planned?

Yes, as soon as it goes on sale and I can buy one to test with! 😀

jaZz_KCS: I could not find info about cms2lpt but I assume it's an saa1099 plugged on an printer interface. If your intend is to use it with vgmplay.exe to listen to sega master system sn76489 chip let me warn you about a bug, it's a sustained bell when some good games music try to cut a note.

I'm tryiing to list all music affected and fix them, but it's a long issue as I found no automation. Otherwise, what's your interest of cms2lpt and vgmplay.exe ?

ElBrunzy wrote on 2020-07-01, 03:00:

jaZz_KCS: I could not find info about cms2lpt but I assume it's an saa1099 plugged on an printer interface. If your intend is to use it with vgmplay.exe to listen to sega master system sn76489 chip let me warn you about a bug, it's a sustained bell when some good games music try to cut a note.

I'm tryiing to list all music affected and fix them, but it's a long issue as I found no automation. Otherwise, what's your interest of cms2lpt and vgmplay.exe ?

By vgmplay.exe, you mean SBVGM, right?

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. 😀

Here's the thread for CMSLPT thread: CMSLPT : Creative music system (game blaster) on parallel port.

[Edit]
I just took a closer look at the SN76489 datasheet. The "note off" via frequency value behavior is different from the RP2A03. It looks like it's possible to silence the channel with a value of 0x000 and I am remembering now that doing this on the SN76489 causes the square wave to remain high and some games have used this feature as a DAC to play back sample data on the chip. The SAA1099 doesn't behave in this manner; I'll try to see if I can take this behavior into account soon.

OPLx wrote on 2020-07-01, 09:36:

By vgmplay.exe, you mean SBVGM, right?

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.

Thanks for the information about the cmslpt, I'm curious to read that thread.