# VGMPlay for MSX

Page 13/47
6 | 7 | 8 | 9 | 10 | 11 | 12 | | 14 | 15 | 16 | 17 | 18
Grauw wrote:

On machines with V9938 VDPs I implemented a 300 Hz timer using line interrupts. This means the VGM playback is timed more accurately on MSX2, MSX2+, and a few MSX1 machines.

Technical details;

A single line takes 63.7 µs to display in both 50 Hz and 60 Hz modes. To achieve a 300 Hz frequency (3333 µs/tick), we need to generate an interrupt every 52.33 lines. Per frame, the VDP draws 313 lines in 50 Hz mode and 262 lines in 60 Hz mode. Note that this means on MSX, 50 Hz is actually 50.16 Hz and 60 Hz actually 59.92 Hz. Ignoring this fractional difference, this means we want an interrupt on the following lines:

```50 Hz lines: 0, 52, 104, 157, 209 and 261
60 Hz lines: 0, 52, 105, 157 and 210
```

The line on which the VDP must generate an interrupt can be specified in an 8-bit register. Although you can specify a line beyond the vertical display area of 192 or 212, the maximum value is 255, which means we can not generate an interrupt on line 261 at 50 Hz, it will have to come a little early. In the end, I generate interrupts on the following lines:

```50 Hz lines: 0, 51, 102, 153, 204 and 255
60 Hz lines: 0, 52, 104, 156 and 208
```

In other words, at 50 Hz I increase the line number by 51 and at 60 Hz I increase it by 52. After the value overflows, I reset it back to 0. This generates regularly-spaced interrupts, with the interrupt after the wrap taking a little longer because it accumulates the deviation from the ideal period. A nice benefit of picking these values is that it will generate 6 interrupts per frame at 50 Hz and 5 interrupts at 60 Hz without any additional code beyond setting up the increment value.

Because VGM is timed at a resolution of 44100 Hz, for each tick I increase the VGM timer by 147 (44100 / 300). I could increase it by more exact values to reflect the time more accurately (143, 144, 143, 143, 143, 163 at 50Hz, and 146, 146, 146, 146, 152 at 60 Hz), but for the sake of simplicity I do not take this into account, as the timing is not that critical.

I verified with the oscilloscope and as expected each interrupt is occurring evenly spaced (3.31 ms @ 60 Hz), with the last period of the frame taking a little longer (3.44 ms @ 60 Hz).

The cost of each tick of the line interrupt timer is about 1 line on both MSX2 and turboR, this amounts to about 2% CPU time. Actually, currently it’s more because I hook H.KEYI, but this should be reduced one I use interrupt mode 2 to bypass the BIOS ISR for detecting the interrupts.

Implementation here.

@hit9918 You need to build it yourself if you want the latest changes now (it’s easy though).

I’ll release VGMPlay 1.2 at the Nijmegen fair on January 23rd.

Hopefully you find the technical approach of the 300 Hz timer interesting .

I am still reading eagerly, hot stuff
The PAL interrupts in the lower border did work out?
One day I had issues with emu, but I forgot the details.

No problems in either emulator (openMSX) or the real machine that I noticed.

I especially liked how the line number cap at 50 Hz turned out to work in my favour, with 51 being an exact division of 255, and getting the 6 / 5 ints counting at 50 / 60 Hz essentialy for free, not needing to use a lookup table or counter.

6 interrupts, this is great, double as I imagined
Maybe one could get something new in the waveform section.
Be it going below the lowest hz of psg a bit or be it going above the usual arpeggio things.

Heh, VGMPlay runs too slow in 300 Hz mode on the Zemmix Neo .

I suspect it doesn’t support line interrupts past line 212.

VGMPlay now shows which MSX sound module takes care of which sound chip.

I also implemented SCC+ support.

I’ve added dual SN76489 DCSG support yesterday. There’s quite a couple of arcade games which use this combination. For example Wonder Boy in Monster Land has a nice soundtrack.

Also Franky and PlaySoniq are now detected separately so you can use them both at the same time to have two DCSGs, and of course the Musical Memory Mapper is also still supported.

This is getting better and better. I should resume my work on a VGMPlay-related initiative in order to have it ready for the next VGMPlay version. I can't wait to make it widely available.

Page 13/47
6 | 7 | 8 | 9 | 10 | 11 | 12 | | 14 | 15 | 16 | 17 | 18