MSXgl – A new C game library for MSX

بواسطة aoineko

Paragon (1132)

27-01-2022, 17:30

Moved to https://msx.org/forum/msx-talk/development/how-to-detect-sou...

بواسطة Grauw

Ascended (10818)

27-01-2022, 19:30

Grauw wrote:

In VGMPlay MSX I mask out various writes to control registers:

FLAG CONTROL (04H) writes are completely ignored
MISC CONTROL (08H) writes ignore bits 0-1 and 3-5
IO CONTROL (18H) writes are completely ignored
IO DATA (19H) writes are completely ignored

I bet the IO Control and IO Data register writes are the culprit. I believe the Philips NMS-1205 has a sound output enable on one of the GPIOs, where on the Panasonic FS-CA1 it has a different function. OpenMSX matches the real hardware in this regard. BlueMSX is no longer maintained for more than 10 years.

Correction in bold above. Writes to 19H are also ignored.

بواسطة Grauw

Ascended (10818)

27-01-2022, 23:34

Similarly, for PSG a general VGM player should enforce register 07H’s bit 7 and 6 to be 1 and 0 respectively, and block writes to registers 0EH and 0FH. Otherwise the VGM playback could interfere with joystick and keyboard I/O, or even potentially cause damage on some machines due to causing short circuits. That’s why in VGMPlay MSX there are checks for this.

Now perhaps for a library intended to offer an easy method to have BGM music in games this is unnecessary overhead if the VGM files are preprocessed to remove those commands, but then the programmer should be made very much aware of this and it should be made part of the build pipeline.

Maybe this could be achieved by having checks only in debug builds, that intentionally halt the CPU (or throw an exception of sorts) when improper writes to registers are encountered.

Or alternatively by using a different format that is similar to VGM, so that songs are forced to go through a converter which does this filtering. It could then also apply some simple optimisations like quantising the waits to 300 Hz (the common denominator of 50 & 60 Hz), and simplifying the SCC commands to just a register / value pairs instead of the more complicated encoding of VGM. Then VGM is more a convenient intermediate format for recording. That’s how I use it in my projects, I never use VGM directly except in the general purpose player of course.

The one does not exclude the other of course, one could have both a slower general purpose player and fast and compact specialised format(s).

بواسطة aoineko

Paragon (1132)

28-01-2022, 00:47

I didn't realize that the problem was within the VGM file data.
Thanks for the explanations and even the 'ready to use' piece of code.
Indeed, for my PSG management module, I filter what is written in the 07h register.
It seems to me normal in a generic library to have this kind of security.
As you say, it is unlikely that the VGM format will be used as is in a game so it seems more interesting to optimize other replayer.
And I use a lot of #define in my library to let the user configure how it works. If someone wants a faster version of the VGM player, I could add a #define to remove all these safeguards.

BTW, I wonder: why are these data in the VGM file?
If they are there, it's because these registers were modified by the original music, isn't it?
Did the original music already not working with a Music-Module?
Or is it a problem with the program that creates the VGM file?

بواسطة gdx

Enlighted (6422)

28-01-2022, 10:06

I understand your library only reads lite VGM files. So why not set bits 7-6 to 01 when converting? This will avoid putting an AND and an OR in the replayer to place these bits correctly.

بواسطة Grauw

Ascended (10818)

28-01-2022, 10:27

aoineko wrote:

BTW, I wonder: why are these data in the VGM file?
If they are there, it's because these registers were modified by the original music, isn't it?

Not necessarily, a VGM typically starts with a dump of all registers to set the initial state.

aoineko wrote:

Did the original music already not working with a Music-Module?

Xevious requires MSX-AUDIO BIOS, so it only worked with the Panasonic FS-CA1.

But if the Philips NMS-1205 is retrofitted with an MSX-AUDIO BIOS, the music works afaik. The mute function is not set by the game, but by the Panasonic FS-CA1’s BIOS initialisation probably.

In Japan they were not aware of the Philips or Toshiba modules without BIOS (they were released in Europe only). I’m not sure what sequence of historical events lead to a standard being defined but two out of three modules being shipped without the appropriate BIOS. Maybe it wasn’t ready in time, from what I can tell the FS-CA1 was released in ’88 and the Philips and Toshiba in ’87 and ’85 respectively. Although the Y8950 chip in all three is still called MSX-AUDIO.

aoineko wrote:

Or is it a problem with the program that creates the VGM file?

I think for a general dumb register log format that is most often used with PC players which just run emulators that don’t care, you can’t expect the logger programs to be picky about which registers they do and do not log. Unless they get spammed so much that they increase the file size significantly, people probably wouldn’t notice or care.

بواسطة gdx

Enlighted (6422)

28-01-2022, 10:28

MSX-AUDIO BIOS is optional, PCM too.

بواسطة Grauw

Ascended (10818)

28-01-2022, 10:34

gdx wrote:

MSX-AUDIO BIOS is optional, PCM too.

Interesting, do you have a source to reference for that?

By PCM being optional, do you mean the sample RAM?

بواسطة gdx

Enlighted (6422)

28-01-2022, 10:39

When the Datapack talks about the specifications of the MSX-AUDIO, it only talks about the chip, the possible RAM size for the PCM and the I/O ports.
So hard to interpret it any other way: BIOS, BASIC, RAM for PCM and MSX-AUDIO slave (for stereo or not) are optonal. And the facts confirm it.

بواسطة Grauw

Ascended (10818)

28-01-2022, 10:44

Quote MSX datapack:

Quote:

4.1.1 Basic configuration

1. Minimum configuration
■ Sound source LSI MSX-AUDIO LSI (Y8950)
■ DAC LSI YM-3014
■ RAM 256K bits for ADPCM / PCM data
■ Program ROM 128K bytes
■ Program RAM 4K bytes
■ Input / output terminal Music keyboard connection terminal
Audio input terminal (microphone level mini jack)
Audio output terminal (line level RCA jack)

2. Maximum configuration
■ Sound source LSI MSX-AUDIO LSI (Y8950) x 2
■ DAC LSI DAC LSI (YM-3014) x 2
■ RAM 256K x 8 bits for ADPCM / PCM data
■ ROM for ADPCM / PCM data 256K x 8 bits
■ Program ROM 128K bytes
■ Program RAM 4K bytes
■ Input / output terminal Music keyboard connection terminal
Audio input terminal (microphone level mini jack)
Audio output terminal (line level RCA jack)

Firstly in both minimum and maximum configuration it says there is program ROM and RAM. Even if you would interpret this as “it does not explicitly say BIOS” (even though the BIOS is documented in the following chapters), the NMS-1205 and HX-MU900 still do not implement RAM.

Secondly it says 32K sample RAM is the minimum configuration, and the HX-MU900 has none.