Problems with YM sound effects on real hardware (works in emulators)

[DragWx]

9 NOPs is 18 cycles, are you sure that many are necessary after an address write? Our own documentation recommends 10 cycles, which would just be 5 NOPs.

If it works, it works, I just want to know where these cycle counts and requirements come from.


For BUSY (or, delay after writing DATA), I looked at Nuked-OPM and jt51, and they both agree that BUSY takes 32 YM2151 cycles. The YM2151 application manual says the master clock is halved internally, so each YM2151 cycle is actually 1.79MHz.
If you allow (up to) 1 cycle for the YM2151 to poll its async address/data interface, 33 cycles is about 147.5 CPU clocks (at 8MHz), so that matches the "wait 150 cycles" advice.

For the delay after writing ADDRESS, I don't have hard data, but if I assume it takes one cycle to set the address (after allowing up to one cycle to poll that interface again, like above), 2 cycles is about 8.94 CPU clocks, which matches our documentation recommending a 10-cycle delay.

[doslogo]

Glad that fixed it. Once I got thinking about it, I realized how familiar that "works on emu, but not hw" problem was.

I knew you would find a solution quite quickly since the music already worked.

Now, while the sound effects are primitive, they give the cycles to the game engine to come up with a queue system etc, so that is good. But converting from ZSM to sound effects is quite a hack at the moment. Your zsm2sfx php script has a line like this:

Code: Select all

$i = 18; // skip ZSM header bytes

Is 18 correct here?

When using the script unmodified, there is always the result:

We've gone off the rails!!!

The switch statement differs quite heavily from the one in zsmdecode.

My modified script managed to get the sound exactly like I wanted it, but that was probably with luck. Also, I don't like that DefleMask instruments are required for dmp2x16. It isn't a free software, like Furnace who has its own instrument format.

Maybe zsm2sfx should be able to export the instrument for function patchym from the ZSM directly instead?

9 NOPs is 18 cycles, are you sure that many are necessary after an address write? Our own documentation recommends 10 cycles, which would just be 5 NOPs.

I tested it with 5 NOPs on real hardware with success! All updates to the YM registers that were using 9 NOPs were changed to 5, and I am playing that Super Mario 64 ZSM at the same time at as spamming YM ZFX and PSG at the highest channels not to screw up the music. No errors.

It all runs at 60 Hz even at loop points, which is so ridiculous awesome.

I also introduced artificial lag and music and sound effects are still playing at slower rate (because I am not updating in vblank), but there are no errors in the playback, so 5 NOPs (10 cycles) were correct DragWx!
I will later test 5 NOPs on the real hardware with both sound effects and music playing at the same time. I'll post my result then.

EDIT: Works with the Green Hill Zone ZSM as well, spammed sound effects, and doesn't miss a beat. That ZSM have many instruments changes though so it lags every loop, and is a typical example of how to not make music for the X16. The 5 NOPs work perfectly!

[DragWx]

Nice, I'm happy that helped.

I'm also trying to figure out a good way to stream writes to the YM2151 without having to do busy-waiting (in general), it's a challenging puzzle.

[doslogo]

I'm slowly getting the YM2151 knowledge by hardcoding sound effects. The size of the sound effects cost LORAM which is not good, so I am thinking about doing lower resolution fade outs (by simply skipping steps), and hopefully that also costs less register waiting.

And the sound effects are so nostalgic too. It helps when it is real YM2151 hardware and not some emulation

[ZeroByte]

The size=18 is due to the fact that when Zsound first released, there was no headerless mode loading routine, so all files on X16 had to have the 2-byte PRG header. That should be 16 now.

I'm also trying to figure out a good way to stream writes to the YM2151 without having to do busy-waiting (in general), it's a challenging puzzle.

Unfortunately, the busy-wait period is a hardware requirement of the YM2151. The only way to avoid entering the busy loop is to ensure that your writes to it happen at least 68 YM clocks apart from each other.

The YM is clocked at ~3.5Mhz, which means that you must wait at least 152 CPU clocks between writes to the YM.

I'd tried to come up with ways to avoid wasting time waiting for this, but it's just long enough to really waste time from your program, but not long enough to make it economical to go do other things and then come back later. The overhead of swapping tasks is more expensive on average than just biting the bullet whenever a large block of YM writes takes place.

I'd considered making the music driver reserve 2 pages of memory as a ring buffer for the YM, and then perhaps creating an ISR to drain it based on VIA timers but the overhead of entering IRQ, polling sources, ACK-ing the chip, and doing the work eats up a large portion of the 152 clock cycles so you're not really going to be getting much done anyway.

The best solution I've thought of is to optimize your audio data. I think I'm going to write a ZSM optimizer that will time-shift writes to the YM where possible to avoid large spikes of activity. Basically, pre-loading patches before they're needed, and spreading the loads over multiple frames of time if available.

[ZeroByte]

Also, the 9 NOPs is to accommodate the YM2164.

It's been a while, but I seem to recall us landing on 5 NOPs as the amount that completely cleared up any corrupted audio during early HW testing with the YM2151.

[DragWx]

It takes 232 writes to initialize all 8 channels and trigger 8 new key-ons. You could space these writes out up to ~480 CPU cycles and still get all of these writes done before your next vblank ISR, before you start cutting it close.

My draft idea would be to sprinkle calls to a "poke the FM write buffer" routine in between loop iterations, etc, in the music engine. Then after the music engine exits, start a repeating interrupt (using the VIA) to keep poking at it. The nice thing about using the VIA is, when the buffer is empty, you can turn the interrupt off and save yourself the ISR overhead.

[doslogo]

The size=18 is due to the fact that when Zsound first released, there was no headerless mode loading routine, so all files on X16 had to have the 2-byte PRG header. That should be 16 now.

I thought as much. I have had only good result making YM sounds with the broken script so far. Which is good news to me. I don't think it will help others though.

I'd considered making the music driver reserve 2 pages of memory ... ring buffer ... perhaps creating an ISR ... VIA timers

ZSound is very good as it is, because it doesn't require all those resources to be taken away from the game developer. My game is completely struggling with LORAM already (because game code takes up space, never thought about that), and bank swapping is scary when so much is going on. My ISR is complicated (has several paths for differences in emulator and real hardware, VGA, NTSC timings differ even on hardware, it is a hell where I currently live) and can barely handle music as it is. And I already required both VIA timers since using VERA is hysterical *tries to keep a sane face*.

But at least, ZSound does what it promised to do, and that is incredible after all these years! Let the game programmers deal with resource management. YM writes can be controlled by music composers thankfully.