VGMPlay for MSX

Page 38/47
31 | 32 | 33 | 34 | 35 | 36 | 37 | | 39 | 40 | 41 | 42 | 43

By alexito

Hero (537)

alexito's picture

29-01-2019, 00:26

Franky NTSC tested and working fine with sanno msx1 with F18A VDP UPGRADE+LPE MMCSD V6+MMM

https://www.youtube.com/watch?v=0l3PuNFmuSA

;)

By Pentarou

Master (212)

Pentarou's picture

29-01-2019, 00:50

Mmh... If I remove the Franky I still have:

SN76489 (DCSG): 3000000 Hz
-> Musical memory Mapper: 3579554 Hz

but then the 2nd DCSG is emulated by the
-> Internal PSG: 1789773 Hz

For some reason VGMPLAY thinks that I have a MMM

By Grauw

Ascended (8406)

Grauw's picture

29-01-2019, 08:56

Thanks for testing Pentarou and Alexito.

@Pentarou I will look into the MMM detection false positive. That seems to explain the missing sound. What's your hardware configuration? I can try to replicate it in openMSX.

By Pencioner

Paladin (933)

Pencioner's picture

29-01-2019, 11:11

@Grauw i had MMM detection false positive with Carnivore 2 - after some investigation and looking into docs of MMM and into source code of the FPGA firmware of C2 i found out that it uses same mapper control logic as MMM (i will explain in more detail later if there's need of it). So basically vgmplay plays DCSG tunes when MMM is in lower slot than C2 but other way around it has false positive and there's no sound (because SN chip activation sequence reaches C2 not MMM so chip is silent)

By Grauw

Ascended (8406)

Grauw's picture

29-01-2019, 12:18

Pencioner wrote:

@Grauw i had MMM detection false positive with Carnivore 2 - after some investigation and looking into docs of MMM and into source code of the FPGA firmware of C2 i found out that it uses same mapper control logic as MMM

I see! @Pentarou, are you also using the Carnivore2?

Pencioner wrote:

(i will explain in more detail later if there's need of it).

Would be appreciated to have more detail. I need to know how the C2 works so I can see which parts are similar and which parts are different, and what I need to do to distinguish them from each other.

By Pentarou

Master (212)

Pentarou's picture

29-01-2019, 12:43

Yes, the problem is caused by my Carnivore2.

By Grauw

Ascended (8406)

Grauw's picture

29-01-2019, 13:42

Mmm, I see MMM mentioned in the documentation here indeed:

https://github.com/RBSC/Carnivore2/blob/master/Doc/carnivore...

Um, yeah... if it fully emulates the MMM except for the sound chip, that’s gonna be annoying to deal with. What I don’t understand why it would even emulate the MMM’s mapper in the first place. It’s not particularly awesome or anything... Why not just a regular mapper.

I really really would prefer not to have to write code to also explicitly detect the Carnivore2 slot, and then exclude scanning all its subslots. Can’t the Carnivore2 just be updated to remove the MMM emulation in favour of a regular mapper? I don’t understand why FPGA gates are wasted on it. Or be complete and add SN76489 support.

By Parn

Champion (403)

Parn's picture

05-02-2019, 14:06

@Grauw, I don't want to sound annoying myself, but I was wondering, would you consider adding MegaRAM support to VGMPlay? In favor of it, we can never have enough RAM to play VGM files. And I suspect it wouldn't be too hard, since it's super well documented and it doesn't conflict with mapper. Against it, I can imagine some difficulties managing two different types of memory expansion, and of course MegaRAM isn't really popular outside of Brazil. What do you think?

By the way, this is not directly related, but I was wondering... How can DOS2 keep track of all available memory when you have many memory mappers on a system? Does it keep some kind of allocation map? What about VGMPlay? Can it use all available memory mappers transparently or does it just pick one?

By MsxKun

Paladin (919)

MsxKun's picture

05-02-2019, 15:22

Parn wrote:

How can DOS2 keep track of all available memory when you have many memory mappers on a system? Does it keep some kind of allocation map?

Yup.

By Grauw

Ascended (8406)

Grauw's picture

05-02-2019, 19:39

Parn wrote:

@Grauw, I don't want to sound annoying myself, but I was wondering, would you consider adding MegaRAM support to VGMPlay? In favor of it, we can never have enough RAM to play VGM files. And I suspect it wouldn't be too hard, since it's super well documented and it doesn't conflict with mapper. Against it, I can imagine some difficulties managing two different types of memory expansion, and of course MegaRAM isn't really popular outside of Brazil. What do you think?

Hmm, it would complicate the mapped buffer to support different mapper types. I think for me the priority is to invest in reducing the memory requirement by doing this or this. But you can file a ticket on the project page, that way the idea won’t get lost.

Parn wrote:

What about VGMPlay? Can it use all available memory mappers transparently or does it just pick one?

It uses all mappers that are found by DOS2.

Page 38/47
31 | 32 | 33 | 34 | 35 | 36 | 37 | | 39 | 40 | 41 | 42 | 43