RoboPlay - Multi format music player in Fusion-C

Page 18/18
11 | 12 | 13 | 14 | 15 | 16 | 17 |

By ToriHino

Paladin (727)

ToriHino's picture

17-09-2021, 10:33

After creating 4 games for MsxDev'21 it's time to pick up RoboPlay again. This time I added support for the TurboFM Compiled file format. These files are for the TurboSound FM, a ZX Spectrum sound card which contains two YM2203 OPN chips.

Current player plays these two chips back on the OPM (a.k.a. SFG-05) chip on MSX, giving 6 channel 4-op FM sound.

In this video some examples are shown. Most things already work fine, one of the things not working (yet) is a full reset of the OPM after playing, leaving some tones active.

By ToriHino

Paladin (727)

ToriHino's picture

17-09-2021, 23:31

When looking further in why the reset of the SFG-05 is not working, I found that in OpenMSX the status register always returns 0xFF, however using a real OPM cartridge on a real system it returns 0x00 when not busy, using address 0x3FF0.

Anyone knows if this difference is due to OPP versus OPM? Or is this just not working under OpenMSX?

Btw, strange thing is that even when waiting for the busy flag it still does not reset, however putting in some delay between the calls seems to resolve it.

By Manuel

Ascended (18162)

Manuel's picture

18-09-2021, 00:56

From openMSX code on the read part of the SFG device:

        case 0x3FF0: // (not used, it seems)
        case 0x3FF1: // OPM STATUS REGISTER
        case 0x3FF2: // Data buffer for SD0 to SD7 input ports
                return peekMem(address, time);
        case 0x3FF5: // MIDI standard UART DATA READ BUFFER
                return ym2148.readData(time);
        case 0x3FF6: // MIDI standard UART STATUS REGISTER
                return ym2148.readStatus(time);

and here's the peek code which it refers to:

        case 0x3FF0: // (not used, it seems)
                return 0xFF;
        case 0x3FF1: // OPM STATUS REGISTER
                return ym2151.readStatus();
        case 0x3FF2: // Data buffer for SD0 to SD7 input ports
                // TODO: return getKbdStatus();
                break;
        case 0x3FF5: // MIDI standard UART DATA READ BUFFER
                return ym2148.peekData(time);
        case 0x3FF6: // MIDI standard UART STATUS REGISTER
                return ym2148.peekStatus(time);

So, yeah, apparently status is supposed to be at 3FF1 according to this implementation and 3FF0 is not used and returns always 0xFF... Do you have information that this is wrong? Does 3FF0 mirror 3FF1?
It looks like we explicitly changed this after investigation done by Grauw, see https://github.com/openMSX/openMSX/commit/0ea4529c35049fa42d... I found back in the IRC logs of that day that he tested it:

jul 18 2015 20:46:00 [Quibus>   grauw: btw, this seems wrong:
jul 18 2015 20:46:07 [Quibus>           case 0x3FF0: // OPM STATUS REGISTER
jul 18 2015 20:46:07 [Quibus>                   return ym2151.readStatus();
jul 18 2015 20:46:07 [Quibus>           case 0x3FF1: // OPM DATA REGISTER
jul 18 2015 20:46:07 [Quibus>                   return ym2151.readStatus();
jul 18 2015 20:46:45 [Quibus>   What do you get when reading from 0x3FF1?
jul 18 2015 20:47:44 [Quibus>   do you read from the register you wrote in 3FF0?
jul 18 2015 20:49:17 [grauw>    not sure which is the status register
jul 18 2015 20:49:36 [grauw>    but perhaps it is correct, it may just ignore the A0 pin when in read mode
jul 18 2015 20:49:57 [Quibus>   grauw: then your doc is incorrect
jul 18 2015 20:50:10 [grauw>    which doc?
jul 18 2015 20:50:22 [Quibus>   <a href="http://map.grauw.nl/resources/midi/ym2148.php" title="http://map.grauw.nl/resources/midi/ym2148.php">http://map.grauw.nl/resources/midi/ym2148.php</a>
jul 18 2015 20:50:29 [grauw>    this is YM2151 status read
jul 18 2015 20:50:45 [Quibus>   it says 3FF1 R is FM data register
jul 18 2015 20:50:53 [Quibus>   not FM status register
jul 18 2015 20:51:00 [grauw>    for write
jul 18 2015 20:51:14 [Quibus>   it says R/W
...
jul 18 2015 20:52:05 [grauw>    well I don’t know for sure, I copied it off existing docs, need to confirm
...
jul 18 2015 20:56:44 [Quibus>   what's on 3FF0 then?
jul 18 2015 20:56:49 [grauw>    idk
...
jul 18 2015 21:24:56 [Quibus>   grauw: the French doc says that 3FF1 is the status register. It doesn't say whether something is behind 3FF0 when reading
jul 18 2015 21:25:13 [grauw>    yeah
jul 18 2015 21:25:25 [Quibus>   perhaps you can do some experiments to see what 
you get when you read from that address
jul 18 2015 21:25:29 [grauw>    so I had found that out experimentally in vgmplay ;p
jul 18 2015 21:25:59 [grauw>    yeah
jul 18 2015 21:26:28 [grauw>    ok

...
jul 18 2015 23:25:01 [Quibus]   grauw: by the way - don't forget to update the MAP regarding 3FF0/1
jul 18 2015 23:25:07 [grauw]    oh yeah
jul 18 2015 23:42:58 [grauw]    btw
jul 18 2015 23:43:20 [grauw]    3FF0H returns 0FFH
jul 18 2015 23:43:32 [grauw]    I’ll update the MAP, you can update openMSX ;p

And so he did in http://map.grauw.nl/resources/midi/ym2148.php But perhaps something was wrong with that test?

By ToriHino

Paladin (727)

ToriHino's picture

18-09-2021, 01:54

Ah ok that does explain indeed why it reads 0xFF. Btw I used the information from NYYRIKKI’s documentation page (I could not find this information on MAP, but apparently it's also located under the YM2148).

I did not really dive further into the behavior of my actual hardware yet (which is a SFG05 clone with a YM2151, so not the YM2164).

By Grauw

Ascended (10074)

Grauw's picture

18-09-2021, 02:58

If it returns FFH on one machine and 00H on another, then it suggests it’s open bus. An FFH result in itself suggests that tbh. Like reading a nonexistent I/O port. That would mean the value depends on the machine, whether it has pull-up resistors on the data bus, in which case it will return FFH, or not. @ToriHino what machine did you try the SFG-05 with?

(I believe there was an openMSX ticket about emulating open bus reads.)

By ToriHino

Paladin (727)

ToriHino's picture

18-09-2021, 09:32

I tried the SFG-05 now a bit more on both a turbo-r FS-A1ST and on a Sony HB-F1XDJ. Not exactly sure what was different now but on both I get 0xFF on 0x3FF0 and the status on 0x3FF1. So on both machines behavior is indeed similar to what is seen in openMSX.

By ToriHino

Paladin (727)

ToriHino's picture

20-09-2021, 16:29

I uploaded the latest version of RoboPlay to this location and it now also contains the current version of the TFC format player. Some minor changes since the first version:

  • stereo replay (original files are mono, tried to distribute as good as possible over left, right and middle)
  • reset of the OPM works now, so no active notes hanging after the song

I also updated the RoboPlay starter pack with ~200 TFC files, which can be downloaded from this location.

Note that for timing still the OPL4 is used so you need both OPM and OPL4 for TFC files replay. Next tot that, current implementation is a bit slow on a regular Z80 so a faster MSX is recommended (see if that can be optimized further).

Source code as always available here.

Page 18/18
11 | 12 | 13 | 14 | 15 | 16 | 17 |