Advanced hardware configuration questions

Por Briqunullus

Expert (74)

Imagen del Briqunullus

13-06-2020, 13:46

So, after my dual PSG question I started tinkering my openMSX hardware configuration. And I ran into a few questions along the way. So here we go.

I already had created my custom configuration and including a second PSG turned out te be easy.

    <PSG id="PSG2">
      <type>AY8910</type>
      <sound>
        <volume>21000</volume>
      </sound>
      <io base="0x10" num="2" type="O"/>
      <io base="0x12" num="1" type="I"/>
    </PSG>

Just a few quick questions here. Is there any difference between type YM2149 and AY8910? And how important is the id? It's probably enough to have it differ from the original PSG, isn't it?

Then I also learned about the MSX Audio in slave mode. That looked easy to include at first sight as well.

    <MSX-AUDIO id="Generic MSX-Audio slave">
      <io base="0xC2" num="2"/>
      <io base="0x0A" num="1" type="O"/>
      <type>Philips</type>
      <sound>
        <volume>12000</volume>
      </sound>
      <sampleram>256</sampleram>
    </MSX-AUDIO>

However, this shares the same I/O port for the DAC (0x0A) as the master MSX Audio. Can I leave it this way? Should I assign a different I/O port? Or should I just delete the line completely? And how about the MusicModuleMIDI section, should a include a copy of that as well? And if so, on what I/O ports?

And finally I discovered the SN76489. I copied that one from the Franky extension.

    <SNPSG id="SN76489 Franky">
      <io base="0x48" num="2" type="O"/>
      <sound>
        <volume>21000</volume>
      </sound>
    </SNPSG>

But soon I found out the MMM uses different I/O addresses. And I included a second one for the sake of it (without the memory).

    <SNPSG id="SN76489 MMM">
      <io base="0x3F" num="1" type="O"/>
      <sound>
        <volume>21000</volume>
      </sound>
    </SNPSG>

However, this one uses one I/O port, where the Franky used two. Isn't this strange? I tried to find documentation for the device specifics, but I couldn't find any. I ended up browsing this openMSX source on Github, but got a bit lost there.

So, this probably is a bit of a deep dive into openMSX. And it's more out of interest than for practical use. But I hope someone can give a few insights on openMSX's internals.

And in the end I might have created the ultimate openMSX sound machine. But that wasn't my goal. I just want to have a config where I can open any game and have sound with it. That's all...

Login sesión o register para postear comentarios

Por Manuel

Ascended (16689)

Imagen del Manuel

13-06-2020, 15:31

Briqunullus wrote:

Just a few quick questions here. Is there any difference between type YM2149 and AY8910?

There is a difference, but it's subtle. Both are used on real MSX hardware. See e.g. https://github.com/openMSX/openMSX/issues/114#issuecomment-1... but it has been discussed on MRC as well (as the comment in that issue also points out).

引用:

And how important is the id? It's probably enough to have it differ from the original PSG, isn't it?

The ID is used to make names for sound devices, debug devices, etc. If you use an identical ID, openMSX will make it unique by itself. You can see them for instance when you enable the vu-meters script (toggle_vu_meters or in the Toys and Utils submenu of the OSD menu).

引用:

Then I also learned about the MSX Audio in slave mode. That looked easy to include at first sight as well.

That term confuses me a bit. You mean a 2nd MSX-AUDIO right? Check the audio2 extension for that.

引用:

However, this shares the same I/O port for the DAC (0x0A) as the master MSX Audio. Can I leave it this way? Should I assign a different I/O port? Or should I just delete the line completely? And how about the MusicModuleMIDI section, should a include a copy of that as well? And if so, on what I/O ports?

I don't think all these things are relevant for a 2nd MSX-AUDIO. See the comments in audio2.xml.

引用:

And finally I discovered the SN76489. I copied that one from the Franky extension.

Um, we don't have a Franky extension... but we do have an SN76489 extension that has this chip on the same port as Franky. And you used that.

引用:

However, this one uses one I/O port, where the Franky used two. Isn't this strange? I tried to find documentation for the device specifics, but I couldn't find any. I ended up browsing this openMSX source on Github, but got a bit lost there.

The SN76489 config says:

引用:

This extension contains an SN76489 sound chip on I/O ports $48 and $49 (mirror).

So, the 49 is the mirror. The chip really has only one port (see SNPSG.cc in writeIO).

引用:

So, this probably is a bit of a deep dive into openMSX. And it's more out of interest than for practical use. But I hope someone can give a few insights on openMSX's internals.

I hope all is clear now! It's not really about openMSX internals, but more about the actual hardware, I think! :)

引用:

And in the end I might have created the ultimate openMSX sound machine. But that wasn't my goal. I just want to have a config where I can open any game and have sound with it. That's all...

Enjoy playing around with configs! It's much easier than soldering in chips in real machines, that's for sure! :)

Por Briqunullus

Expert (74)

Imagen del Briqunullus

13-06-2020, 18:53

引用:

There is a difference, but it's subtle. Both are used on real MSX hardware. See e.g. https://github.com/openMSX/openMSX/issues/114#issuecomment-1...

I get it. I don't think I will hear the difference, nor I am interested in this. The thing I was afraid of was that I would add a second MSX engine to my system if I choose two YM2149. But now it sinks in and that's bullshit. The one thing I will take from this however is to have both PSG's use the same type.

引用:

You can see them for instance when you enable the vu-meters script (toggle_vu_meters or in the Toys and Utils submenu of the OSD menu).

Good point. I will remember to use readable names. :)

引用:

That term confuses me a bit. You mean a 2nd MSX-AUDIO right? Check the audio2 extension for that.

I had read the term slave in the wiki for instance. But you are right, the two devices aren't interacting with eachother, so there is no true master/slave configuration. I had missed the audio2 extension. I see it leaves out the other I/O port so I will do that as well.

引用:

Um, we don't have a Franky extension... but we do have an SN76489 extension that has this chip on the same port as Franky. And you used that.

My bad. I should have phrased it differently. I probably got confused because of the Franky comment in the SN76489 extension. :D

引用:

So, the 49 is the mirror. The chip really has only one port (see SNPSG.cc in writeIO). I hope all is clear now! It's not really about openMSX internals, but more about the actual hardware, I think! :)

Well, let's say we are at the boundary of openMSX and the hardware then. The thing I'm looking for is how openMSX interprets the xml file.

The one question I left out was how does openMSX know what I/O port is for what use? You pointed me in the good direction with that writeIO function. In MSXAudio.cc I can see these are sort of hardcoded. And from the code I can deduct it needs three I/O ports.

For the SN76489 I still can't figure out why the port mirroring works, but I have changed my configuration so it works with all known I/O ports.

    <SNPSG id="SN76489">
      <io base="0x3F" num="1" type="O"/>
      <io base="0x48" num="2" type="O"/>
      <sound>
        <volume>21000</volume>
      </sound>
    </SNPSG>
引用:

Enjoy playing around with configs! It's much easier than soldering in chips in real machines, that's for sure! :)

Yeah, thanks for your answers. It sure is fun. B-)

Por Manuel

Ascended (16689)

Imagen del Manuel

13-06-2020, 19:21

As you can see in the write IO function, it doesn't check which port is written. The XML file determines which ports are effective.

Por sdsnatcher73

Paladin (974)

Imagen del sdsnatcher73

14-06-2020, 08:07

With your last piece of XML you get (I think) a single DCSG which reacts to both ports, apparently sharksym’s fork of vgmplay allows dual DCSG playback. So it may be cool to add two DCSG entries in the XML at different ports (and see if they are detected and work as 2 individual chips.

Por Briqunullus

Expert (74)

Imagen del Briqunullus

14-06-2020, 08:55

OMG, yeah that would be a reason to have two of them. Smile Smile Smile

Por Grauw

Ascended (9156)

Imagen del Grauw

14-06-2020, 11:39

Just adding the ports isn’t enough though, since the DCSG is read-only and there is no way to detect its presence. VGMPlay supports the Musical Memory Mapper (supported by openMSX) and the Franky or PlaySoniq (not supported by openMSX). So I recommend to plug in the Musical Memory Mapper extension into openMSX if you want to listen to DCSG music. If you want your set-up to work, you need to edit the VGMPlay source code and hard-code the DCSG detection to always return true.

Por sdsnatcher73

Paladin (974)

Imagen del sdsnatcher73

14-06-2020, 11:44

What Briqunullus is trying to do is make his own “Boosted” machine on openMSX by creating a machine config. So how does vgmplay detect the MMM? It has no ROM, right? I guess for the machine config adding the total MMM config into a sub slot of the machine that is empty will work but then how is the Franky DCSG detected by vgmplay? Or is it not usable in openMSX with VGMplay? And what tools can use it then (in openMSX)?

Por Grauw

Ascended (9156)

Imagen del Grauw

14-06-2020, 12:13

Detection code here.

https://hg.sr.ht/~grauw/vgmplay-msx/browse/src/drivers/MMM.a...
https://hg.sr.ht/~grauw/vgmplay-msx/browse/src/drivers/Frank...
https://hg.sr.ht/~grauw/vgmplay-msx/browse/src/drivers/PlayS...

I have to say that T-Wave’s detection looks a ton simpler. Just using the mechanism provided by switched I/O ports, easy peasy. If I might say so, hardware designers in general could pay more mind to detection of their hardware…

Por Briqunullus

Expert (74)

Imagen del Briqunullus

14-06-2020, 21:58

I finally managed to wrap my head around this. After reading some more code and changing my perspective to the CPU point of view I totally get what's happening. If you're defining too few I/O ports you are simply lacking functionality (that secondary MSX Audio has no DAC), if you specify too many you are duplicating functionality across multiple I/O ports. It is code dependent of course, but in case of the SN76489 there is only one function and it is simply mirrored.

So I know how to create useless extensions now. Like a single MSX Audio that works on both the primary and the secondary ports. Evil

    <MSX-AUDIO id="Don't try this at home">
      <io base="0xC0" num="4"/>
      <type>Philips</type>
      <sound>
        <volume>12000</volume>
      </sound>
      <sampleram>256</sampleram>
    </MSX-AUDIO>