VGMPlay for MSX

Pagina 45/47
38 | 39 | 40 | 41 | 42 | 43 | 44 | | 46 | 47

Van Avkooi

Expert (76)

afbeelding van Avkooi

13-10-2019, 22:59

Here are my findings:
I tried all combinations on my TurboR GT with an Tecnobytes slot expander, Junsoft's DalSoRi2, Junsoft's NeoTron, WozBlaster Enhanced, GR8NET Stereo, Musical Memory Mapper.

  • DalSoRi2 detection is depended of the installation of the MSX-Audio ROM file in the cartridge. Without the ROM installed, OPL4 tracks play with issues on the DalSoRi2, I guess because the correct samples can't be loaded.
  • Detection of a DalSoRi2 in a secundary slot doesn't function. Even with the MSX Audio ROM flashed, VGMPlay doesn't 'see' the cartridge.
  • SCC detection of the emulated SCC(+) in the GR8NET doesn't work with a DalSoRi 2 inserted in a secondary slot. It doesn't matter if MSX Audio ROM is flashed or not, it interferes somehow with the detection of the SCC on the GR8NET. Extra strange: VGMPlay displays '->Konami SCC+' as an output devices, but no SCC sound is heard. In a primary slot, everything is OK: detection of SCC and detection of DalSoRi 2.
  • With the WozBlaster Enhanced everything works like it should, but it doesn't play the sample heavy tracks like Asura Blade.
  • Neotron soundtracks, like YM2203 in PC88 and YM2610 in Neo Geo sound fantastic!

Thanks for all the time and effort to make this my favorite MSX software! If I can test some more for you, please let me know!

Van ToriHino

Champion (366)

afbeelding van ToriHino

14-10-2019, 01:02

In a first quick check i see detection of the DalSoRi in a subslot already fails at the first SetConfig call i.e. it can still find the OPL4 after disabling all ports.

Van Pencioner

Paladin (951)

afbeelding van Pencioner

15-10-2019, 12:51

ToriHino wrote:

In a first quick check i see detection of the DalSoRi in a subslot already fails at the first SetConfig call i.e. it can still find the OPL4 after disabling all ports.

Which computer did you use? I can check with others than Sanyo Wavy to see, because on Sanyo it works in subslot, maybe issue with particular models

Van ToriHino

Champion (366)

afbeelding van ToriHino

15-10-2019, 15:51

I used the combination of a Turbo-R (ST) and the CIEL Mini Slot Expander.

Van Grauw

Ascended (8451)

afbeelding van Grauw

15-10-2019, 19:53

About the DalSoRi R2;

What DIP switch settings are you guys using? Mine are 1 on (BIOS disable), 2 off (SROM), 3 off (I/O C0H disable), 4 on (I/O C4H enable).

I don’t think I ever flashed the MSX-AUDIO BIOS, did you? If so, how do you “uninstall” the ROM, by erasing the FlashROM memory using Jun’s tool or by toggling the 1st DIP switch?

VGMPlay checks address 4000H for 8x 0FFH (no BIOS flashed) or address 80H for the string “AUDIO” (MSX-AUDIO BIOS flashed). It would be interesting to dump a few bytes of the contents of address 4000H and 80H to see what’s in the memory.

Van ToriHino

Champion (366)

afbeelding van ToriHino

15-10-2019, 20:54

I have the same switch settings, and indeed also no AUDIO BIOS flashed.

I can indeed check what is found on those addresses. Unfortunately the DalSoRi register itself write only.

Also did some more testing and found the following:
- Put the DalSoRi R2 in subslot 0 of the expander: detected and plays correct
- Put the DalSoRi R2 in any other subslot of the expander: detected as MoonSound and does not play correct.
- Use VGMPlay 1.2: detected as MoonSound but plays correct in all subslots (detection is explainable since 1.2 did not have yet specific DalSoRi code)

BTW I checked with the same slot expander and DalSoRi on my Sony MSX2+ and there i see exactly the same behaviour.

Checked already which slot id's are used during detection and this all looks correct i.e. first some subslots of slot 0, but after that also all subslots of the expander are tested.

Van Grauw

Ascended (8451)

afbeelding van Grauw

15-10-2019, 22:41

That’s all very strange. I wonder what it could be.

Fyi I just pushed a RAM slot check to every slot scan (querying the mapper support routines), this way there is no risk that any detection based on ROM ID strings or memory-mapped I/O accidentally misdetect it or modify program code in RAM. Though I don’t think that’ll be the cause for this issue.

Additionally I added a Utils_PrintSlotString helper function to print slot memory contents. It matches the signature of Memory_MatchSlotString and does not modify any registers, so it can be called right before that to print out the bytes that it’s going to be matching against.

Van Grauw

Ascended (8451)

afbeelding van Grauw

15-10-2019, 23:40

About playing ROM sample based packs like Asura Blade on MoonSound, these games have 4 MB sample ROM while the MoonSound (or DalSoRi R2 in default mode) has 2 MB sample RAM or less, has only 128 user instruments instead of 512, and the RAM base address is also different from ROM (200000H instead of 0H).

So VGMPlay tries to deal with this by applying an offset to the addresses and instrument numbers, this can work if only samples in the first 2 MB and 128 instruments are used, but as you can imagine this fails otherwise.

The solution is to remap every individual sample that’s used in the track to a different memory address and instrument number, “compacting” it as it were so that it fits (generally only part of the sample memory and instruments are used in one song so that’s why this can work). Unfortunately that feature still has to be developed, so for now packs like Asura Blade only work properly on the DalSoRi R2.

Van ToriHino

Champion (366)

afbeelding van ToriHino

16-10-2019, 00:43

The RAM slot check indeed did not change anything for this problem.

I used the Utils_PrintSlotString to print out content of both 4000H and 80H in MatchSlot with the following result:
DalSoRi in slot 2-0:

DalSoRi in slot 2-1:

As you can see in the first run it stops at slot id 0x82 since it found the DalSoRi here. The second run it continues while it should stop at slot it 0x86.

Van Grauw

Ascended (8451)

afbeelding van Grauw

16-10-2019, 01:56

Okay, this is very useful info Smile. So the ID check isn’t the problem, but the check which follows is.

After the memory checks pass, it first disables the I/O ports though the DSR2 configuration register, and then runs the OPL4 detection. Next it enables the I/O port C4H and tries to detect it again. If the first check fails and the second succeeds, the configuration register worked and it’s the DalSoRi R2.

Pagina 45/47
38 | 39 | 40 | 41 | 42 | 43 | 44 | | 46 | 47