Home » News » Music » VGMPlay MSX 1.3 released
VGMPlay MSX 1.3 released

VGMPlay MSX 1.3 released

by Grauw on 26-07-2020, 14:13
Topic: Music
Tags: grauw, vgm, vgmplay
Languages:

Today Laurens Holst released VGMPlay MSX version 1.3!

The highlight of this release is support for playing MegaDrive VGMs on a turboR with Yamaha SFG module. The OPN and OPNA which were used in the Japanese PC-88/PC-98 are also emulated on the Yamaha SFG, as well as the SN76489 on the PSG. Additionally, support was added for several new sound expansions like the Makoto, Neotron, Darky, DalSoRi R2 and OPL3 for authentic playback of their corresponding VGMs.

Changes in this version:

  • New chips: YM2203 OPN, YM2608 OPNA, YM2610 OPNB, YM2610B OPNB-B, YM2612 OPN2
  • New sound expansions: Makoto, Neotron, Darky, DalSoRi R2, OPL3 (C0H)
  • New timer: 1130 Hz if a MoonSound or OPL3 is present
  • Emulation of SN76489 DCSG on PSG
  • Emulation of YM2203 OPN, YM2608 OPNA and YM2612 OPN2 on Yamaha SFG
  • Translation of YM2612 OPN2 frequencies to correct tuning
  • Playback of YM2612 OPN2 PCM samples on MSX turboR
  • Playback of dual YM2203 OPN on a single Makoto + PSG or Yamaha SFG + 2x PSG
  • Playback of Y8950 MSX-AUDIO on MoonSound or OPL3, without ADPCM
  • Support of the DalSoRi R2 4MB RAM mode
  • Dual chip support for more chips
  • Support for VGM loop base and modifier
  • Improved detection of MSX-AUDIO, MoonSound, PSG, MMM and Franky
  • Improved sound chip reset and muting
  • Improved playback processing speed and accuracy
  • Samples load prior to playback
  • Added length and loop length to track information
  • Improved VGM chip overview output
  • Ability to stop playback with joystick buttons
  • Ability to use more than 4 MB memory by modifying a compile-time constant
  • Removed 1chipMSX / Zemmix Neo bug workaround (fixed in KdL firmware v3.3.1)
  • Fixed MSX-MUSIC playback issues on turbo R
  • Fixed MSX-AUDIO problem loading samples >128K
  • Fixed screen going blank on MSX1 during playback
  • Many code structure and footprint improvements

Get the latest version from the project page. Post your comments, suggestions and feedback in the forum thread. And find your favourite VGM music on vgmrips.net and project2612.org. Like YU-NO, Grounseed, Comix Zone, Alisia Dragoon and Sonic!

Relevant link: VGMPlay MSX

Comments (25)

By ToriHino

Paladin (927)

ToriHino's picture

26-07-2020, 14:56

Congrats on this new milestone! Cool

By knm1983

Hero (578)

knm1983's picture

26-07-2020, 15:37

Thanks , great work Grauw Smile

By msd

Paragon (1532)

msd's picture

26-07-2020, 15:59

Nice!

Just a question. For example these files strikers-1945, should they work as they are made for the ymf278b according that website.

By sd_snatcher

Prophet (3675)

sd_snatcher's picture

26-07-2020, 16:50

It seems like a lot of work! Kudos for you, Grauw!

By Grauw

Ascended (10821)

Grauw's picture

26-07-2020, 17:44

msd wrote:

Just a question. For example these files strikers-1945, should they work as they are made for the ymf278b according that website.

There are two problems with several OPL4 VGM packs from arcade machines:

  1. They use a 4 MB ROM for their samples, and the MoonSound and clones generally have less than that (up to 2 MB). Until I implement this feature the songs will not fit in sample memory. It does work on the DalSoRi R2 because it has a 4 MB RAM mode.
  2. They use a clock frequency other than 33.8688 MHz, which requires frequency translation. I do this for a few other chips, but for MoonSound it has not been implemented.

By Avkooi

Expert (101)

Avkooi's picture

26-07-2020, 19:18

Thanks Grauw! Great new release! Already throwing some tracks at it and they all sound fantastic!

By Manuel

Ascended (19691)

Manuel's picture

26-07-2020, 19:44

Just wondering: what are the limitations of the emulations mentioned?

By msd

Paragon (1532)

msd's picture

26-07-2020, 20:10

@grauw: Can you detect atm that those files will not play? Because probably it is better to give some not support message than try to play.

By Grauw

Ascended (10821)

Grauw's picture

27-07-2020, 18:26

Manuel wrote:

Just wondering: what are the limitations of the emulations mentioned?

DCSG on PSG: Mostly to do with the noise. Noise channel of DCSG is independent while on PSG it shares mixer channel 3, so volume is shared and if both sound the tone is a bit different. Noise LFSRs are also different, and frequency mapping as well. Additionally DCSG noise has a “periodic” mode that the PSG doesn’t.

OPN on Yamaha SFG: Various LFO parameter mappings are not exactly 1:1, and the OPM does not have the “3ch” mode of the OPN series. Additionally the internal divider is different so sounds using aliasing will not sound the same (e.g. YU-NO Opening).

Edit: Oh, and playing the YM2608 OPNA on Yamaha SFG also does not play the drum channels.

By Grauw

Ascended (10821)

Grauw's picture

26-07-2020, 20:29

msd wrote:

@grauw: Can you detect atm that those files will not play? Because probably it is better to give some not support message than try to play.

I’d rather improve the playback… Wink

By Victor

Champion (509)

Victor's picture

26-07-2020, 20:31

What have been the changes in the "SCC detection" routine???

In some devices now fails.. not detection... I'ld like to know...

By Grauw

Ascended (10821)

Grauw's picture

26-07-2020, 20:38

@Victor The biggest change to SCC detection was this one.

Can you be more specific about which devices? Let me know in this thread.

In general FPGA SCC detection is a crime. All those FPGA implementations have their own “version” of an SCC, all incomplete with differences in the details. It is very difficult to test all of them.

By Victor

Champion (509)

Victor's picture

26-07-2020, 20:39

Grauw wrote:

In general FPGA SCC detection is a crime. All those FPGA implementations have their own “version” of an SCC, all incomplete with differences in the details. It is very difficult to test all of them.

great.. thanks!!.. I'll take a look.

By Wierzbowsky

Guardian (3650)

Wierzbowsky's picture

27-07-2020, 13:21

Nice! What about the directory playback mode? When all files in the directory are played one by one. That's what I am really missing in the previous software...

By Latok

msx guru (3960)

Latok's picture

27-07-2020, 13:53

Alexey, you could use sofarun for that Smile

By Grauw

Ascended (10821)

Grauw's picture

27-07-2020, 15:23

I have wildcard support almost working but I need to finish it.

I myself normally run VGMPlay from Multi Mente so using that or SofaRun is recommended for the time being. The readme has some Multi Mente configuration instructions.

By Grauw

Ascended (10821)

Grauw's picture

27-07-2020, 18:26

Grauw wrote:

OPN on Yamaha SFG: Various LFO parameter mappings are not exactly 1:1, and the OPM does not have the “3ch” mode of the OPN series. Additionally the internal divider is different so sounds using aliasing will not sound the same (e.g. YU-NO Opening).

Oh, and playing the YM2608 OPNA on Yamaha SFG also does not play the drum channels.

By KdL

Paragon (1485)

KdL's picture

27-07-2020, 19:19

Great!! Thank you very much Grauw! Smile

By sdsnatcher73

Enlighted (4317)

sdsnatcher73's picture

27-07-2020, 21:52

Hey Grauw. Great release and too much to try out again. I did (potentially) spot an issue with plain old PSG (I was playing the second track of the Metal Gear pack). The start of that track does not sound right (tried on 2 machines). I wanted to raise a ticket on bitbucket but found the repo moved to source hut and could not find how to raise issues there. How should we raise issues?

Notes:
- I have not registered yet so that may explain I don't see the options for raising issues
- Played the same vgm with vgmplay 1.2 (the one that comes with SofaRun) but that also sounds off

By Grauw

Ascended (10821)

Grauw's picture

27-07-2020, 22:32

I moved all issues to SourceHut’s issue tracker, and you can also report them in the forum thread.

As for the Metal Gear track, I’ve heard of that issue before. It is a problem with the pack itself, it needs an update. An easy check you can do to see if the problem is with VGMPlay MSX is by listening to the problematic track on vgmrips.net.

By sdsnatcher73

Enlighted (4317)

sdsnatcher73's picture

27-07-2020, 23:19

Yeah I listened on vgmrips.net and on PC but at least there it is not that obvious.

I will try rerecording from kss...

By sdsnatcher73

Enlighted (4317)

sdsnatcher73's picture

29-07-2020, 19:44

About the playback of Mega Drive / Genesis OPN2 tracks (which sounds awesome). I've been reading (a little) about the OPN2 and it seems it's DAC is very similar to our beloved OPLL's DAC. Since you uncovered using the OPLL DAC directly would it be possible to play the PCM samples on the OPLL? This would open these tracks up to a broader audience and might even sound closer to the original??

By Grauw

Ascended (10821)

Grauw's picture

29-07-2020, 19:57

Where the other OPM, OPL and OPN chips output digital data and use a separate DAC IC to mix the channels and convert it to analog audio, indeed the OPLL and the OPN2 are similar because they have an internal DAC, which is incapable of mixing and outputs all the channels really quickly, letting the mixing be done by a low-pass filter.

A “DAC” used for PCM playback is actually a different thing. The term used in this context means that there is a special register which outputs any value written to it directly to one of the channels. Basically, whether software can stream digital samples. The OPN2 has this, but the OPLL does not.

So the difference in the usage of the term DAC is whether you are talking about something between the sound chip and the audio output, or between the CPU and the sound chip. The term DAC for the latter is not really technically correct, the term PCM channel is better.

Is it possible to play PCM on the OPLL though? The answer is yes, through a clever trick. However you can not play FM while you’re playing PCM like this. Additionally, the FM part of the OPL is very different from the OPN, so it is not possible to play the OPN2 music on the OPLL.

By sdsnatcher73

Enlighted (4317)

sdsnatcher73's picture

29-07-2020, 21:55

The idea was to combine FM->SFG and PCM->OPLL for OPN2 (where now you use FM->SFG + PCM->tR PCM) indeed making use of that clever trick. I think more people have SFG+OPLL than SFG+tR.

By Grauw

Ascended (10821)

Grauw's picture

29-07-2020, 23:50

Ah, gotcha. There are two problems.

First, there’s no standard high-resolution timer in MSX computers before the MSX turboR, which you need for PCM streaming in a general-purpose player like VGMPlay. The highest resolution timer before the turboR is 300 Hz (using line splits). Recently I added an 1130 Hz OPL3/4 timer though which can be configured to be 3100 Hz or 6200 Hz by changing the OPLTimer_RATE constant in the code.

Second, the 3.58 MHz Z80 is not fast enough to keep up with PCM playback in VGM files. You can test this yourself by commenting out the ret nc in Player_ConnectPCMWrite and modifying the TurboRPCM device to output to some other PCM device like the Music Module or Covox.

Now the other day I tested the new timer with OPN2 on an MSX2 in openMSX, changing the CPU speed to 7.16 MHz. It worked decently, certain songs it was able to play with few slow-downs. But a real machine with 7 MHz mod is different, they slow down on I/O and mess up the cartridge slot clock…