VGMPlay for MSX

I have discovered a bug in replay of OPL4 tracks for some systems (f.e. Fuuki) - which was introduced in version 1.3 while version 1.2 plays nicely. Sounds like it tries playing with ROM samples instead of playing with user loaded samples. Sounds quite a cacophony :) Tracks from MSX plays well with both versions, though

Finally I've been able to test the RC4 built and I found something interesting: the 2 bugs I encountered before (GR8NET SCC+ detection and DalSoRi R2 issue) seem to be correlated!

When I insert my DalSoRi (in a primary or seconday slot), VGMPlay isn't able to detect the SCC+ in my GR8NET (firmware 0.8). With DalSoRi not inserted, SCC detection functions like it should.

I hope this helps solving the last issues for the final release! If I can help you test some more, just let me know!

No, there is just one instance of the emulation. So if you want to play dual DCSG you need at least one real one. However you can modify the source to add a 2nd emulation instance with relative ease if you want it.

Ah, I see what you mean.

Noise always plays on channel 3, the DCSG noise frequency is partially tied to the 3rd channel so DCSG music will often already try to avoid playing noise and tone 3 at the same time. E.g. the MegaDrive SMPS music driver never plays tones on the 3rd channel. When both noise and tone play, it uses the highest volume of the two.

The PSG on DCSG emulation currently has the following imperfections:

1. Noise volume can not be separately controlled from tone channel 3 volume.
2. When channel 3 plays both tone and noise, they OR rather than sum, which sounds a bit different.
3. The volume scaling is different so the volume control is mapped and does not match exactly.
4. The noise uses a different LFSR so the colour of the noise is different.
5. The DCSG’s “periodic noise” waveform is not supported.
6. The noise frequency is sometimes different.

The first two are fixable by borrowing a channel off a second PSG, but it could introduce balance issues. But the real problem is that it makes the emulation code more complex, I would have to introduce a second code path depending on whether a 2nd PSG is available. Wrenching that into a single implementation is different, worst case I would need to make a 2nd.

Since even then the emulation is not going to be perfect, and the current approach does the job pretty well for most of the music I’ve tried, I’m quite happy with the current approach. Although I do try to make a good effort (e.g. I did improve the volume scaling), there’s a limit to how complex I want to make it.

If there were no DCSG cartridges for MSX it would be a different matter, but you can just get a real one if accuracy is really important. In the end it’s really meant as a better-than-nothing alternative so that people who don’t own a DCSG (or don’t have a free slot) can still listen to MegaDrive music, and if you own one DCSG you can listen to dual-DCSG music.

Note I don’t mean to dismiss any future suggestions for improving the DCSG emulation, just this particular thing seems too much trouble to be worth it. Similarly I choose not to attempt to dynamically pick a channel for the noise based on whether it was not used by a tone or had a similar volume, that would’ve just gotten too tricky.

Specifically regarding that link between tone and noise, the DCSG noise has two modes of specifying the frequency: either one of three fixed frequencies, or using the frequency of the 3rd tone channel. In the latter case DCSG music will generally mute the 3rd tone while noise sounds, which is convenient for us.

As for the noise frequency range (no. 6), the PSG can reproduce the first two fixed frequencies more or less correctly, but the third is clamped and plays higher than it should. When the noise frequency is taken from the tone channel, the DCSG can specify 10 frequency bits while the PSG specifies 5, so it’s again clamped when the frequency gets too low for the PSG.