VGMPlay for MSX | MSX Resource Center (Page 54/55)

Ascended (10767)

08-05-2021, 21:16

denjhang wrote:

Are you currently interested in studying OPN VGM playing on Moonsound? I found that vgm-conv can convert OPN (4OP FM) to OPL3 (2x2OP FM), and it can also convert SSG to FM, which seems to mean that vgmplay plays OPN in Moonsound and even OPM VGM can be processed in a similar way.

What I am most looking forward to is to use Moonsound to play OPNA (FM only) and OPM VGM, because Moonsound (OPL3 part) supports up to 8 2x2OP FM channels, so this seems to be feasible, although some timbres will change after using vgm-conv conversion It's strange.

Hi denjhang,

The OPL3/4 can not reproduce all of the timbres of the OPN, neither with its 4-op algorithms nor with paired 2-op ones. These FM chips series were developed in quite a different direction and aren’t compatible. To illustrate, the OPNA has eight 4-op algorithms, while the OPL3 has only four of which only two are truly 4-op. The OPL series focused more on extending the waveforms, of which the OPL3 has eight while the OPNA has only one.

In VGMPlay MSX I only want built-in conversions that sound faithful to the original, and for OPNA on OPL4 that’s unfortunately not possible. The conversion would not sound as intended (as you have noticed), and also be too complicated to do in Z80 code.

But if vgmconv is able to perform a lossy conversion, even if the timbres change, I think it’s great to have that available .

Par denjhang

Rookie (30)

09-05-2021, 08:25

By the way, vgmtransmute cannot adjust the volume of the drum sound using PMD PPS.
So I suggest vgmtransmute to increase the separate volume adjustment of FM and PCM.
In addition, for the lossy conversion of OPM or OPNA (OPN2) to OPL3, vgmconv does not currently have this function. I found that you are also good at nodejs development. Are you interested in improving this conversion function?

Par da_Dude

Resident (33)

13-04-2022, 19:36

Updated my VGM folder once again.
Most content from VGMrips.net, All unpacked en renamed to *.VGM files.

Link: https://www.mediafire.com/file/eoi72jvrl2rjehk/SceneCAT_VGM_...

Enjoi!
Greetz,

SceneCAT

OPL / OPL2 / OPL3 / OPL4 / OPLL / OPM / OPN / OPN2 / OPN2C / OPNA / OPNB / PSG / SAA1099 / SCC / SCC+ / SN76489

Par ducasp

Paladin (680)

14-04-2022, 16:16

Grauw,

Not sure if this is a bug or not, I'm implementing Franky support on SM-X and it's variants and the audio part is ready, it works quite well with COL4EMM and SG1000, but I was having some issues with VGMPLAY.

The issue was due to a bad design in the chip selection logic that caused it to have the noise volume set to really high during boot (won't be detailing this as it is not really important for you) and I've solved it. It was nice that vgmplay is working as is now because I could figure out this bug easily, but COL4MMM and SG1000 (or the games themselves) initialize all sound channels to volume 0, including noise, and all work fine.

Since VGMPLAY seems to not do it, if playing VGMs that don't initialize the noise channel, the fpga version with bad design will keep making noise while playing some VGM that doesn't use the noise channel.

I'm speculating here, but perhaps the same would apply if someone exits vgmplay with the noise channel actively playing something, it would keep playing some noise? Wouldn't be a good idea to set all channels volume to 1111 at startup and when exiting to avoid getting unwanted sounds for channels not in the VGM file?

Again, probably not a bug, but perhaps something worth adding. I've already fixed the design, so that is not exactly an issue for me, but I think that if you got to MSX BASIC, type OUT &H40,0 (make sure no switched io is selected), OUT &H48,F0 and then go back to system and call vgmplay to play, as an example, streets of rage 2 vgm tracks 1 to 7 (I've tested those) that have no noise channel information, music will be ruined because noise will be playing in the background.

Par QBee Sam

Champion (289)

14-04-2022, 19:05

Thank you!

da_Dude wrote:

Updated my VGM folder once again.
Most content from VGMrips.net, All unpacked en renamed to *.VGM files.

Link: https://www.mediafire.com/file/eoi72jvrl2rjehk/SceneCAT_VGM_...

Enjoi!
Greetz,

SceneCAT

OPL / OPL2 / OPL3 / OPL4 / OPLL / OPM / OPN / OPN2 / OPN2C / OPNA / OPNB / PSG / SAA1099 / SCC / SCC+ / SN76489

Par Grauw

Ascended (10767)

14-04-2022, 23:21

ducasp wrote:

Not sure if this is a bug or not, I'm implementing Franky support on SM-X and it's variants and the audio part is ready, it works quite well with COL4EMM and SG1000, but I was having some issues with VGMPLAY.

The issue was due to a bad design in the chip selection logic that caused it to have the noise volume set to really high during boot (won't be detailing this as it is not really important for you) and I've solved it. It was nice that vgmplay is working as is now because I could figure out this bug easily, but COL4MMM and SG1000 (or the games themselves) initialize all sound channels to volume 0, including noise, and all work fine.

Since VGMPLAY seems to not do it, if playing VGMs that don't initialize the noise channel, the fpga version with bad design will keep making noise while playing some VGM that doesn't use the noise channel.

Hmm I know the SN76489 produces sound in its initial state, but once I detect it I immediately mute it…

See here. Am I not doing it right?

p.s. The one thing I do not like about Franky is that it stabs a register right in the expanded I/O space (40H-4FH). Franky is not extremely common so if someone makes a cartridge that uses expanded I/O, IMO they can get away with ignoring Franky, and if they can’t avoid using 48H/49H there is a simple workaround for the user: don’t plug in the Franky. But if this were to become a built-in function of the OCM, that would worsen the problem :(.

To avoid this problem, I recommend to only enable the Franky ports 48H and 49H when the switched I/O is in its default bank (0). Then it won’t interfere with other devices using expanded I/O proper. Technically, using a proper device ID for Franky would be even better, though then you would need to run a command to select the Franky bank before being able to use the tools.

Par ducasp

Paladin (680)

15-04-2022, 00:08

Grauw wrote:

ducasp wrote:

Not sure if this is a bug or not, I'm implementing Franky support on SM-X and it's variants and the audio part is ready, it works quite well with COL4EMM and SG1000, but I was having some issues with VGMPLAY.

The issue was due to a bad design in the chip selection logic that caused it to have the noise volume set to really high during boot (won't be detailing this as it is not really important for you) and I've solved it. It was nice that vgmplay is working as is now because I could figure out this bug easily, but COL4MMM and SG1000 (or the games themselves) initialize all sound channels to volume 0, including noise, and all work fine.

Since VGMPLAY seems to not do it, if playing VGMs that don't initialize the noise channel, the fpga version with bad design will keep making noise while playing some VGM that doesn't use the noise channel.

Hmm I know the SN76489 produces sound in its initial state, but once I detect it I immediately mute it…

See here. Am I not doing it right?

p.s. The one thing I do not like about Franky is that it stabs a register right in the expanded I/O space (40H-4FH). Franky is not extremely common so if someone makes a cartridge that uses expanded I/O, IMO they can get away with ignoring Franky, and if they can’t avoid using 48H/49H there is a simple workaround for the user: don’t plug in the Franky. But if this were to become a built-in function of the OCM, that would worsen the problem :(.

To avoid this problem, I recommend to only enable the Franky ports 48H and 49H when the switched I/O is in its default bank (0). Then it won’t interfere with other devices using expanded I/O proper. Technically, using a proper device ID for Franky would be even better, though then you would need to run a command to select the Franky bank before being able to use the tools.

Not sure about that, I can make some tests later now that I've fixed it, like the proposed test to turn on the noise in basic and try vgmplay afterwards. Perhaps that bug was causing your reset to not take effect, that would occur if port reads to 48 or 49 occur after reset....

I was fixing OPL3 in OCM for SM-X family that was broken for VGMPLAY 1.3 and now will work nice. Interrupts were disabled (so the timer was not triggering interrupts) and also timer timing was way off, slower than programmed, now working like a charm :)

Par ducasp

Paladin (680)

15-04-2022, 00:16

P.s.: I've tested the scenario

BASIC
OUT &H40,0
OUT &H48,&HF0 (noise starts)
_SYSTEM

Then I've open vgmplay to play streets of rage 2 track 1 vgm, white noise persisted

Now that the design/bug in the logic was fixed, if I just use it normally, not changing anything (as all channels volume are set to no volume at start up, so it is like SMS VDP version of SN, not Texas SN itself), it works wonderfully... If you have a Franky perhaps you can try the above mentioned sequence and see if you get the same results....

Par Grauw

Ascended (10767)

15-04-2022, 00:17

ducasp wrote:

I was fixing OPL3 in OCM for SM-X family that was broken for VGMPLAY 1.3 and now will work nice. Interrupts were disabled (so the timer was not triggering interrupts) and also timer timing was way off, slower than programmed, now working like a charm

Nice!

Par Grauw

Ascended (10767)

16-04-2022, 14:41

I converted Daytona USA from MultiPCM to OPL4:

Daytona USA (OPL4).zip

The Yamaha YMW258-F aka MultiPCM is the ancestor of the WAVE section of the Yamaha YMF278B OPL4, so there are a lot of similarities, but the conversion applies dynamic channel (re-)remapping to get the channel count down from 28 to 24.

The longer tracks need an OPL4 with 2 MB of sample memory, and sufficient system RAM as well.