RoboPlay - Multi format music player in Fusion-C

Paladin (833)

30-06-2020, 21:40

That would be very cool. Looking forward to it. Another question about FM MIDI: how are you treating track 10 note events? I'm curious... Are you using rhythm mode at all? If so, are you translating all track 10 events into those 5 internal instruments? Or just those 5 instruments, while others play in melodic channels?

Van ToriHino

Paladin (826)

30-06-2020, 23:45

Channel 10 is completely handled by the rhythm mode, with a mapping of a number of instruments on to these 5, see this part of the code:

    /* Bass drum */
    if (number == 35 || number == 36 || number == 41 || number == 43) 
    {  
        g_roboplay_interface->write_opl_fm_1(0xBD, g_byte_bd);
        g_roboplay_interface->write_opl_fm_1(0x53, velocity);
        g_roboplay_interface->write_opl_fm_1(0xBD, g_byte_bd | 16);
    }

    /* HiHat */
    else if (number == 37 || number == 39 || number == 42 || number == 44 ||
             number == 46 || number == 56 || number == 62 || number == 69 ||
             number == 70 || number == 71 || number == 72 || number == 78) 
    {       
        g_roboplay_interface->write_opl_fm_1(0xBD, g_byte_bd);
        g_roboplay_interface->write_opl_fm_1(0x51, velocity);
        g_roboplay_interface->write_opl_fm_1(0xBD, g_byte_bd | 1);
    }

    /* Snare drum */
    else if (number == 38 || number == 40) 
    {       
        g_roboplay_interface->write_opl_fm_1(0xBD, g_byte_bd);
        g_roboplay_interface->write_opl_fm_1(0x54, velocity);
        g_roboplay_interface->write_opl_fm_1(0xBD, g_byte_bd | 8);
    }

    /* TomTom */
    else if (number == 45 || number == 47 || number == 48 || number == 50 ||
             number == 60 || number == 61 || number == 63 || number == 64 ||
             number == 65 || number == 66 || number == 67 || number == 68 ||
             number == 73 || number == 74 || number == 75 || number == 76 ||
             number == 77) 
    {       
        g_roboplay_interface->write_opl_fm_1(0xBD, g_byte_bd);
        g_roboplay_interface->write_opl_fm_1(0x52, velocity);
        g_roboplay_interface->write_opl_fm_1(0xBD, g_byte_bd | 4);
    }

    /* Cymbal */
    else if (number == 49 || number == 51 || number == 52 || number == 53 ||
             number == 54 || number == 55 || number == 57 || number == 58 ||
             number == 59 || number == 79 || number == 80 || number == 81) 
    {
        g_roboplay_interface->write_opl_fm_1(0xBD, g_byte_bd);
        g_roboplay_interface->write_opl_fm_1(0xBD, g_byte_bd | 2);
        g_roboplay_interface->write_opl_fm_1(0x53, velocity);
    }

Van Parn

Paladin (833)

01-07-2020, 16:40

Oh, I see. Nice and easy to understand. Thanks!

Van msd

Paragon (1510)

11-07-2020, 17:44

I tested roboplay today . It detects 1088KB on the OPL4 instead of 1024KB. The ADPCM playback seems to not play on the correct frequency. Are these knowN issues? Checking the OPL4 memory can be tricky because you will always read back a value written to sram even when there is no sram connected. You always need to write to another address before read back to make sure there is sram on the test address .

Van ToriHino

Paladin (826)

11-07-2020, 18:56

The ADPCM frequency is a known issue indeed, at least for FAC soundtracker files, a fix is needed for that. Memory detection i will check that as well, i did not see that go wrong on my own device before.

Van msd

Paragon (1510)

11-07-2020, 19:14

In this case I tried muzax3 files .

Van msd

Paragon (1510)

12-07-2020, 14:03

 /* Write block number to corresponding OPL4 RAM address */
        opl4_write_wave_register(0x03, i + 0x20);               /* Register 3: memory addres bits 16-21 */
        opl4_write_wave_register(0x04, 0x00);                   /* Register 4: memory addres bits 08-15 */
        opl4_write_wave_register(0x05, 0x00);                   /* Register 5: memory addres bits 00-07 */
        opl4_write_wave_register(0x06, i + OPL4_MAGIC_NUMBER);

        /* Read back the number from the same location and check */
        opl4_write_wave_register(0x03, i + 0x20);               /* Register 3: memory addres bits 16-21 */
        opl4_write_wave_register(0x04, 0x00);                   /* Register 4: memory addres bits 08-15 */
        opl4_write_wave_register(0x05, 0x00);                   /* Register 5: memory addres bits 00-07 */
       
if (opl4_read_wave_register(0x06) != (i + OPL4_MAGIC_NUMBER))
        {
            result = i;
            break;
        }

Probably when you add an extra write in between to another address your check will be fixed. Like I mentioned before even with no SRAM attached you will read back the last written value. It could be it doesn't always fails because of this. I didn't check this on all configurations.

Van ToriHino

Paladin (826)

12-07-2020, 15:43

I updated the binaries with a version that does an additional write in between. Hope this helps, my DalSoRi2 still shows 2048K.

Van msd

Paragon (1510)

12-07-2020, 16:27

I’ll check it later today :-)

Van msd

Paragon (1510)

12-07-2020, 19:04

yep, that fixed it, now it correctly detects 1024KB. It could be that this issue is only an issue on the 'original' moonsounds (1.0 and 1.1). The design of the sunrise HW was not super good. Especially the GFX9000 for exmaple, that PCB has very bad grounding.