RoboPlay - Multi format music player in Fusion-C

Página 12/13
5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13

Por Parn

Hero (570)

Imagen del Parn

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?

Por ToriHino

Hero (543)

Imagen del ToriHino

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

Por Parn

Hero (570)

Imagen del Parn

01-07-2020, 16:40

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

Por msd

Paragon (1384)

Imagen del msd

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 .

Por ToriHino

Hero (543)

Imagen del ToriHino

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.

Por msd

Paragon (1384)

Imagen del msd

11-07-2020, 19:14

In this case I tried muzax3 files .

Por msd

Paragon (1384)

Imagen del msd

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.

Por ToriHino

Hero (543)

Imagen del ToriHino

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.

Por msd

Paragon (1384)

Imagen del msd

12-07-2020, 16:27

I’ll check it later today :-)

Por msd

Paragon (1384)

Imagen del msd

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.

Página 12/13
5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13