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.
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.
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?
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).
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.)
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.
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.
Refactored the RoboPlay project and updated to R1.5, with following changes:
- Updated code to support SDCC 4.2
- Removed dependency on Fusion-C (R1.3 takes unfortunately too long)
- Moved out as much as possible .asm files (which also caused SDCC 4.2 compatability issues) out of the main program
- Rearranged folder structure and make files
- Brought it under VS Code
- Fixed two long-time bugs in the players:
MOD.PLY: initial sample load/selection sometimes gave problems (example: Signia mod, first time after cold start)
SOP.PLY: fixed a bug in global volume change, causing the tempo to go wrong (example: Jam777 - Evangelion)
Source code is still available here, binaries can be found in the dsk folder.
The RoboPlay starter pack with a large collection of music files for all supported formats can still be downloaded from here.
Wow, that must have been a lot of work. Congratulations on getting it done! 
Very cool! RoboPlay is an awesome project, and it gets awesomer by the day. Congrats!