MoonSound, problem with custom samples on real machine

I think you set the header offset wrong.. register 2 should be 0x15 for writing to ram and than back to 0x14 when done.
The sram starts at 0x200000Hex. There can be 128Headers. start writing your sample data to address 200600H.

I made a version that increments the tone header by 8 after each pattern of the song, going through all possible values in increments of 8... and _none_ of the settings was right on the real machine. In OpenMSX, all values that had the critical bits, sounded right, like for example 0x10 and 0x30. I'll try once more with increments of 4... though I'm pretty sure that's not where the problem is.

Edit: ok, listened through all of the values in increments of 4, and nothing sounded right. Just pitched noises, except with some values it sounded like the Yamaha ROM tones, which is to be expected. I'm beginning to think that maybe the problem is with the contents of the headers I'm writing there.

Wow, you may not believe this but I just discovered this thing called OpenMSX Debugger... How come I didn't know I could have got it from apt-get all this time. I started to disassemble existing MoonSound prods to see what they actually do. It seems that the Coral1 music disk (which is the reason I started this whole project) is writing 0x11 to OPL4 register 2 every once in awhile. Many, many times. I wonder why. Does it do it for every sample upload perhaps?

Thanks, that out_wave routine looks great. But the PCM upload is pretty much what I currently have. I'll try more combinations. For wait, I had something like 30 NOPs just to make absolutely sure it's enough, but your ramtosram routine seems to blast away with OTIR.

Anyway, I made another test. I replaced all of my 7 header bytes with 40 18 3f 00 00 ee 6a, which is header number 1 in the ROM, and it actually does play that ROM sample without noises. So the problem has something to do with what there is in the SRAM, or in the way I'm pointing it to the stuff.

The stuff originates from a 4chn MOD, regular 8bit samples. This particular test tune is an old Amiga MOD first converted to XM and then converted to my own format and the samples written out to individual raw files (because then the songs in our planned music disk can share common samples). And it plays correctly in OpenMSX... The bytes 20 06 00 0E 0C F1 F4 are the first 7 bytes of my first sample header, at 0x200000. So I'm loading the sample starting from 0x200600, leaving room for all 128 headers before it. I see that for example the Coral music disk seems to load the sample data to 0x200300, so there's only room for 64 headers.

Thanks for your help already.

Anyway, I'm beginning to think that maybe I'm loading the data too slowly. Is it possible that the OPL4 "forgets" its address position if it takes too long for the data to arrive at port 0x7F? I'm loading the samples 128 bytes at a time with the old CP/M legacy (?) sequential read 14h DOS call. Though I _did_ also try re-setting the OPL4 address registers 3, 4 and 5 every time after loading a new block, and it didn't help at all.

The latest thing I tried was to just upload the same first 128 bytes over and over again, without loading the rest of the file at all, and it did in fact have an effect on the playback.

Tomorrow I'm going to try loading the samples with the faster "random block read", RDBLK, 27h DOS call. But now I need to sleep.