RoboPlay - Multi format music player in Fusion-C

Page 12/13
5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13

By Parn

Hero (565)

Parn's picture

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?

By ToriHino

Hero (543)

ToriHino's picture

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);
    }

By Parn

Hero (565)

Parn's picture

01-07-2020, 16:40

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

By msd

Paragon (1384)

msd's picture

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 .

By ToriHino

Hero (543)

ToriHino's picture

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.

By msd

Paragon (1384)

msd's picture

11-07-2020, 19:14

In this case I tried muzax3 files .

By msd

Paragon (1384)

msd's picture

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.

By ToriHino

Hero (543)

ToriHino's picture

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.

By msd

Paragon (1384)

msd's picture

12-07-2020, 16:27

I’ll check it later today :-)

By msd

Paragon (1384)

msd's picture

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.

Page 12/13
5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13