MoonSound, problem with custom samples on real machine

Page 2/3
1 | | 3

By yzi

Champion (441)

yzi's picture

12-04-2014, 11:13

Thanks for your help. This is something DOS related. I was able to get the loaded samples to play by copying all the files to a real floppy disk and booting without the Nowind cartridge. There are still some glitches with some samples that don't appear in OpenMSX. Maybe there's something wrong with how I initialize the FCB or something.

By Manuel

Ascended (15763)

Manuel's picture

12-04-2014, 12:47

When comparing to emulators, make sure you use exactly the same configuration... then you compare apples to apples and you can more easily find the issues.

By yzi

Champion (441)

yzi's picture

12-04-2014, 13:07

Now it's working even on the real machine, and with Nowind! Yeeeehaa. The problem had something to do with how I was clearing the FCB, not MoonSound.
In the process of debugging this, I got the disk loading much faster, as a nice side-effect. Now I'm using the 27h RANDOM BLOCK READ call in 4k blocks so it's super fast. Maybe 2k would be enough.

To use the exact same configuration, I would have to have Nowind in OpenMSX. Wink But I know what you mean.

Anyway, I found another thing that OpenMSX does differently than a real OPL4. As far as I know, there's no way to tell the OPL4 that there is no looping of any kind, so for non-looping samples I have to set a very short loop at the end of the sample. If I set the Loop address field of the wave header to exactly the length of the sample, then the real OPL4 seems to continue reading past the end or something, but OpenMSX stops there nicely. I need to set the Loop address to the length minus one, to make the real OPL4 not play random garbage.

By the way, I wonder if it's possible to utilize this glitch for having samples longer than 64k samples.

By yzi

Champion (441)

yzi's picture

12-04-2014, 13:19

...the other non-emulated thing, aside from too fast accesses, was that if bit 0 of register 2 is set, then the OPL4 shouldn't produce sound.

By Manuel

Ascended (15763)

Manuel's picture

12-04-2014, 13:20

There is Nowind emulation in openMSX, but it's the state of Nowind of 2009.... Usable with older firmware.

By Manuel

Ascended (15763)

Manuel's picture

28-07-2018, 22:00

yzi, can you check whether the latest development version of openMSX has this improved?

By yzi

Champion (441)

yzi's picture

23-08-2018, 21:59

The incorrectly set loop points seem to be emulated now (title bar says "openMSX 0.14.0-296-g1a11697 [opt]"), but CPU READ/WRITE MODE register is not. Uninitialized Moonsound RAM noise doesn't seem to be emulated.

Here are my test programs in .dsk format. Press Esc to exit or skip to next part.
http://www.kameli.net/~yzi/opl4tests.zip

I made recordings from Panasonic FS-A1ST, "Sunrise" Moonsound 1 MB, and Nowind.

Loop points test: (also note the NOISE probably coming from uninitialized Moonsound RAM)
https://www.youtube.com/watch?v=XTqlwZFzjrU

CPU READ/WRITE MODE test
https://www.youtube.com/watch?v=Kjb88a7RNFc

By Manuel

Ascended (15763)

Manuel's picture

23-08-2018, 23:35

Oh, I forgot about that other issue. It's this, right? https://github.com/openMSX/openMSX/issues/918 (so the one you mentioned on 12-04-2014, 13:19).

About the uninitialized Moonsound RAM, can you establish the pattern in the unitialized RAM? Then we can add that to the configuration. The default pattern is all bits to 1.

Thanks a lot for your testing!

By yzi

Champion (441)

yzi's picture

24-08-2018, 21:40

Yes that's the issue. By the way, when the CPU read/write bit is set to enable CPU access, the Moonsound's output is not completely silent, as you can hear on the Youtube video. It's making tiny click/pop sounds.

About the uninitialized RAM... I'm not interested enough to write a program that dumps the after-boot memory from various OPL4 cartridges to see what the statistical behavior might be. At least the one I tried now seemed to output noise that resembles full-scale white noise. Random stuff. If that's a general behavior or just this one example with this one turboR machine, no idea. But for helping software development it might be better to initialize the memory with rand() instead of all ones, because playing from uninitialized sample RAM should be a bug. Not that I'd considered it likely that anyone would write another OPL4 music player though. Wink

By Manuel

Ascended (15763)

Manuel's picture

24-08-2018, 23:01

We're not going to use random numbers, because we are making a deterministic emulation (otherwise the reverse feature couldn't work).

There's no need to dump it from various cartridges. Just the RAM of one (preferably an original Sunrise MoonSound) would be good enough. I doubt it's really random.

Note that there is a way to track reads from uninitialized RAM. That could perhaps be extended to include sampleRAM too Smile

Page 2/3
1 | | 3