Correct usage of VDP ports following the standard

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

By ARTRAG

Enlighted (6236)

ARTRAG's picture

09-06-2017, 18:06

Flying Spaghetti Monster, in you we trust....

By Grauw

Ascended (8382)

Grauw's picture

09-06-2017, 18:19

If you want to use some reserved space in upper memory, the PLAY queues are often a good candidate, as long as you don’t use the PSG BIOS routines I think.

By sd_snatcher

Prophet (3047)

sd_snatcher's picture

10-06-2017, 14:37

Sorry for the delay to answer. Free time is a scarce resource right now.

Quote:

(On a complete side note, my only concern is whether it wouldn’t conflict; OPL is a subset of OPLL because it lacks a waveform, also the damping works a bit differently. So for Basic music, which uses _MUSIC, wouldn’t it result in inferior playback if there’s an internal MSX-MUSIC? Same for MSX-MUSIC BIOS emulation.)

Could you elaborate a bit more on this issue?

Quote:

(Secondly, on your site you mention Yamaha's recommended algorithm for sound chip detection, got some link? Interested.)

You have just asked a question for something from 6 years ago, you know? Smile

Sadly, I was air headed enough to forget to take notes of this reference. But the basis for it can be found in the page-10 of the YMF278 application manual.

If I recall correctly, the rest of the info was written in a similar fashion inside the YMF262 Application Manual. Sadly, my copy of this document was gone in an HDD crash some 2 years ago. The PDF stored at your website is not the real Application Manual, but only the "YMF262 Catalog" that has only an overview of all the registers and pins.

Quote:

Aren’t the MSX-MIDI BIOS, MSX-AUDIO BIOS, MSX-MUSIC BIOS and SFG MBIOS all very similar and based on / evolutions (/ hackjobs) of the same codebase?

I don't know about the SFG MBIOS, since I have never dug into it. But I can assure you that the MSX-Music BIOS and MSX-MIDI BIOS are all forks/butchered versions of the MSX-Audio BIOS.

The MIDI BIOS seems to have completed the MIDI support that was still incomplete in the MSX-Audio BIOS. It seems possible to backport these completed routines to the MSX-Audio BIOS, but space is already a challenge. That's why I asked for a MegaROM in that DalSoRi v2 thread. Also it was my priority to translate the relevant MSX-Datapack parts before doing any further modifications in the MSX-Audio BIOS.

This project and the translation required a huge amount of work, you know. But sadly, since the translation finished I haven't been able to find the amount of time that such a complex project requires. And maybe not even the motivation, since I get way more negative feedback about it and BIOS-use-in-general than positive. To the point that some people are intentionally including routines to detect and ignore it.

By Grauw

Ascended (8382)

Grauw's picture

10-06-2017, 15:37

Hey FRS,

sd_snatcher wrote:
Quote:

(On a complete side note, my only concern is whether it wouldn’t conflict; OPL is a subset of OPLL because it lacks a waveform, also the damping works a bit differently. So for Basic music, which uses _MUSIC, wouldn’t it result in inferior playback if there’s an internal MSX-MUSIC? Same for MSX-MUSIC BIOS emulation.)

Could you elaborate a bit more on this issue?

On the OPLL bits 3-4 of register 3 turn the waveform from a sine into a half-sine with the bottom half clipped off, see page 12 of the OPLL application manual. The Y8950 does not have this waveform. Additionally, the OPLL has a quick dump-phase after key-on (DP on page 10), the remainder of the OPL series does not do this, and finally the DAC of the OPLL is quite different which gives the sound its own character.

So, if a real OPLL is present, I think it should take precedence because the sound will be authentic, and especially the Y8950/OPL can’t really mimick it. Or does the MSX-AUDIO BIOS v1.3 actually do address the OPLL when it is present, the only difference being which ROM is handling things?

sd_snatcher wrote:

If I recall correctly, the rest of the info was written in a similar fashion inside the YMF262 Application Manual. Sadly, my copy of this document was gone in an HDD crash some 2 years ago. The PDF stored at your website is not the real Application Manual, but only the "YMF262 Catalog" that has only an overview of all the registers and pins.

That’s too bad! I’m not able to find any other YMF262 manual, seems like it’s missing.

By sd_snatcher

Prophet (3047)

sd_snatcher's picture

10-06-2017, 21:37

@Grauw

What an excellent question! It will be a pleasure to answer this. But it's a long answer, so buckle up and prepare yourself for the ride. Smile

1) Waveform

Yes, the OPL1 can't select the waveforms. Keep in mind that my OPLL->OPL2 translator was developed with the latter in mind, so an OPL2 or newer is the only way to have a perfect OPLL translation.

That said, I felt it was unfair to leave the Y8950 uncovered back then, as a lot of users have either the NMS-1205 or HX-MU900. So I thought it would be nice to add support for this chip even if the fidelity wouldn't be the same. But for this special case, the translator takes some measures to achieve the best possible result.

What happens is that the half-sine waveform volume is quite lower than the full-sine. If did a lot of tests sampling the output of both the OPLL, OPL1 and OPL3 back then, to see how much the volume was affected. Then, when a half-sine is requested for the OPLL translator, it automatically adjusts the volume for that OPL1 channel to compensate. Further volume changes will also check if the channel has the half-sine selected and act accordingly, to make sure that the results are always consistent. Without this volume compensation, the should-be half-sine instruments sounded loud like hell in the OPL1.

The result is that the instruments that required half-wave will sound less complex in the OPL1, but that's all. I think it's an acceptable price to pay so the owners of Y8950 cartridges can enjoy the feature.

I want to reinforce that none of this volume adjustment is necessary for the OPL2 and newer chips. Those routines are not even compiled in their version of the BIOS. An IFDEF takes care of that.

BTW, a side comment: the waveform selection was an ingenious move by Yamaha. It allows to produce complex final sounds that otherwise would require a lot more operators to achieve. IOW, shallow comparisons with other FM soundchip families that state that the OPLs are worse because they have only two operators instead of four are just plain nonsense.

2) Quick dump-phase after key-on (DP on page 10)

This one also requires a long explanation. That "quick dump phase" shown in page-10 in just an effect of how the envelope generator works. Since the key-on/off trigger is binary, when it goes off then on to trigger a new note, the "DP" shown in the graphic is just the "RR" of the previous note. IOW, what they wanted to show you with more detail than in the OPLn manual, is that if you trigger a new note while a previous is still playing, the Key-off of that previous note will happen.

Notice that for percussive tones it's possible to see in the graphic that the "quick dump phase" has the same two stages (RR/RR') that is shown for the key-off event in the end of the cycle. Then, notice that for sustained tones, it shows only one stage just like the respective key-off event. They even show the key-off/key-on in the beginning of the graphic for this case, since sustained tones can be held indefinitely.

But why was this so important for the OPLL and not for the OPLn chips that they wanted to show it specifically in those two graphics, while they didn't in the OPLn soundchip datasheets?

The answer lies in the fact that the OPLL features a simplified register set that limits what can be done with the instruments. Because of that, some features are hardcoded in the OPLL, while they are free to be programmed at any moment in the OPLn chips. As I always say, the OPLL core is a low-cost, more limited, subset of the OPL2 core.

One of the most important things that are hardcoded is the SUSTAIN feature, and one of the reasons why the previous OPLL->OPLn translators before mine failed miserably, is a very subtle info on the Percussive Tone graphic of the page-10. Note that the Percursive tone has an RR', that is hardcoded, and is used when the SUSTAIN bit is off for that instrument.

On the OPLn soundchips, the programmer is free to implement the RR' with any value he wants. All he has to do is to write the new RR value at the same time he writes the key-off event. In the OPLL->OPL2 translator (part of the SoundChipFish library that I included in the ROM), I implemented the RR' with the same hardcoded value that the OPLL uses, of course.

The original MSX-Audio BIOS v1.0 had a bug in its own sustain code. It implemented all the sustain handling, but in the end there was no instruction to write the RR' to the soundchip on key-off. This is why all instruments always had the SUSTAIN activated in that version. So I fixed this bug for the v1.3.

Since the SUSTAIN feature is hardcoded in the OPLL, they had to show on the graphics how this affects the envelope. This is why the OPLL envelope graphics look a bit different than on the OPLn datasheets.

You can check yourself that on page-18 of the YM2413 Application Manual the usual envelope shape is shown again and explained in more detail, and it works just like the envelope generator of the OPLn soundchips.

3) "The DAC of the OPLL is quite different which gives the sound its own character"

This is an argument that is often repeated without questioning. The OPLL has a multiplexed output at 9x 49.71KHz (=447.4KHz!) for each of it's two outputs, that is then mixed externally by an analog mixer and a low-pass filter. Such sampling frequency is so absurdly high that it's questionable whether the human ear can detect any differences to the real 49.71KHz DAC used by the OPLn soundchips.

To me, this sounds like the endless discussions about the cheaper 1-bit DAC (aka pulse-density modulation) versus 16-bit DAC.

Not to mention that all OPLL circuits I found until now had miscalculated low-pass filters that blur any details so strongly that it would have been impossible to distinguish whatever difference people might think existed. It's like someone with a very high degree of myopia trying to distinguish between a real or fake Rembrandt painting without his glasses. ;)

3) OPLL vs OPLn precedence

I also think that this is an important topic, regardless of how good (or not, in some guys opinion) the OPLL->OPLn translation is, but because it's nice to allow the user to select which sound extension he desires to use. So I took many steps to solve this problem the best I could.

It goes like this:

a) For BASIC programs

In this case, the MSX-Audio BIOS will only start reacting to the CALL MUSIC command after a CALL AUDIO command is issued. Otherwise, the CALL MUSIC command will be ignored and any MSX-Music present in the system will be able to answer to it. This is the best possible scenario, as the user is free to decide which sound extension he wants to use. After the CALL AUDIO command is issued, the MSX-Audio BIOS will disable the CALL command handler of any MSX-Music extensions present in the system, to avoid conflicts.

b) For binary programs

I provided a distinct signature for the MSX-Audio: AUDnOPLL, where "n" is the version number of the OPLn soundchip in ASCII. This allows programmers:

- To easily know that the extension is an MSX-Audio, and select the priority he wants, or even provide switches for that. I.e., I implemented a command line switch for that in FireHawk HDD.
- To easily know the OPLn version present, so no complicated/slow/fail prone detection trickery is necessary.

But this case isn't perfect. For existing programs, there's a factor that is beyond my control: the detection algorithm has the user-software just looking for the "OPLL" string sequentially through all the slots and I can't change that. The priority in this case will depend exclusive on the order that the two extensions are installed in the slots. For the Panasonic MSX2+/TR machines, i.e., the internal MSX-Music will always have precedence as it sits in slot 0-2. If both extensions are external, then it's easy: it's just a matter to install the cartridges in the desired order.

For the Panasonic2+/TR machines case, I released an utility called NO-FM.COM that disables the internal MSX-Music so the MSX-Audio can be used with old programs.

By NYYRIKKI

Enlighted (5358)

NYYRIKKI's picture

10-06-2017, 22:01

sd_snatcher wrote:

For the Panasonic2+/TR machines case, I released an utility called NO-FM.COM that disables the internal MSX-Music so the MSX-Audio can be used with old programs.

Hmm... Shouldn't POKE &HFCC1,0 be enough?

By sd_snatcher

Prophet (3047)

sd_snatcher's picture

10-06-2017, 23:22

NYYRIKKI wrote:

Hmm... Shouldn't POKE &HFCC1,0 be enough?

Depends on the point of view. Since the majority of us run the games from .COM utilities like ExecROM, SofaROM and SofaRunIt, to use the poke would then require the user to type:

BASIC
POKE &HFCC1,0
_SYSTEM

Worst yet if he forgot to disable the FM before going to the folder where the game is stored. He will also have to type that CD \GAMES\MSX2\MEGAROM again. Smile

NO-FM makes the things more convenient and can even be included in .BAT scripts.

By Louthrax

Prophet (2076)

Louthrax's picture

10-06-2017, 23:59

There's a turboR specific "Disable FM-PAC" (or something like that) option in SofaRun (that should do extactly that poke before launching a game IIRC).

By Grauw

Ascended (8382)

Grauw's picture

11-06-2017, 01:34

Hey FRS, really nice explanations, and it sounds like it was an interesting project to work on! I could take some inspiration from that for VGMPlay. Maybe OPLL on Y8950 isn’t the first on my mind, but that kind of chip emulation on other chips, I do want to do as well.

The dump phase is specific to the OPLL, it’s not part of the OPL ADSR, and responds to key-on, check e.g. openMSX source code. But afaik the effect is very quick (~10ms?) and subtle, I bet it’s mostly there to avoid clicks from changing waveforms too abruptly. So that isn’t the biggest concern. As for the waveform, I wonder if the effect isn’t more pronounced when used as a modulator? Anyway I should try it myself in MoonBlaster 1.4 or something instead of asking random questions Smile.

But re. OPLL vs OPLn precedence, that was my most important question that I was curious about Smile. Indeed the BIOS case is a bit tricky. VGMPlay searches for APRLOPLL first, and then OPLL. I think this procedure is described in the MSX Datapack.

Anyway thanks for your elaboration Smile.

By sd_snatcher

Prophet (3047)

sd_snatcher's picture

11-06-2017, 14:32

@Grauw

Thanks for the tips, I'll take a look into that issue. It seems like another hardcoded feature of the OPLL.

I guess that in order to avoid those clicks, the OPL players like MoonBlaster must take some measures too, don't they? Do you know what exactly they do?

Yes, the difference in volume is only noticed when the half-sine is applied to the modulator.

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