sound: fix ym2612 address handling

[notaz]

I already fixed this back in 2017 with 151df6adf9d63c9b8c8a61946243800610ac3a65, but forgot about ym2612_write_local(). Fixes missing sounds in Overdrive2.

[notaz]

Was surprised how well Overdrive2 worked already, so this motivated me to hunt down this remaining issue.

[irixxxx]

I actually put some work into getting Overdrive 2 working. I guess a lot of that work is only relevant for exactly this, but I actually felt challenged ;-)

[irixxxx]

Open problems with OD2, to my knowledge:

• in the classroom scene, when the curtain falls, the top 1 or 2 lines flicker. A timing problem with the 68k accessing the vdp, but there is no easy solution for this. It's possibly related to the late instruction cycles billing which makes the vdp access timing some guesswork. I already had problems with this in other places, where modifying the timing by a single cycle may break a game (e.g. the MegaCD intro of Puggsy).

• the z80 needs to be overclocked very slightly (about 1 CPU cycle per scanline), else the sound is lagging some secs after the ending scene. However, the timing between z80, vdp and 68k looks ok to me and passes the timing tests I could find as well as matching my own experiments on real MD1 hardware. OD2 is doing something which somehow triggers a slight slowdown in picodrive which accumulates to those some secs over the length of the demo.

Drop me a note if you find any other problems. I surely might have a look at it. BTW, my MD1 is one of those having problems with the debug register - OD2 is looking much better in picodrive than on my hardware.

[notaz]

My MD1 is also having problems in some scenes, and shows the warning about "plane instabilities" (which do actually happen on plane mixing+sprites scene). Occasionally (perhaps <1/10 runs) it even completely crashes for me (shows a register dump with "OD2 BSOD"), I wonder what exactly happens there. Supposedly the demo doesn't work properly on at least 30% megadrives (by Titan's own estimate) so no surprise.

Personally I wouldn't care about those few lines, I haven't even noticed that issue. What hits me more is the audio issues that still remain, for example wrong effects in spaceship piloting scene near the beginning. It's not super obvious but I have seen the demo so many times that slight sound differences stick out to me.

Ok while writing this I investigated further. The effect is on channel 4 that has SSG-EG enabled.

• if you play the demo without fast-forward, or only disable frame limiter to get to the scene, or use savestates, the effect is wrong
• if you fast forward (backspace) the effect is right (or at least much closer to what it should be)

Could be related to SLOT->ssgn or something.

[irixxxx]

It's really tight on timing. Mix it up even only a tiny bit, and it crashes in picodrive as well. Just saving and loading is sufficient in some places.

I basically gave up on those flickering lines. It's barely noticeable. It's a timing issue, the 68k just isn't synchronous to the scanline at the start of the frame. It magically heals itself within some 3 scanlines. I don't think it's really worth diving further into it.

As for the sound, have you used the arm assembly or the C version? Sound is possibly incorrect after loading a state, since it doesn't save the internal state of the FM, it only saves the register values. I reckon that's why the sound is off when using run-ahead with libretro. Save/Load is on my todo list for some time, but it is some work since it spans a lot of the source. I haven't yet come around to tackle it.

[notaz]

Sound is possibly incorrect after loading a state, since it doesn't save the internal state of the FM, it only saves the register values.

Actually this is not quite true, YM2612PicoStateSave2/YM2612PicoStateLoad2 tries to stick some of the internal state into unused register space (I guess I did it that way to maintain savestate compatibility).

Now that I came back to this code it's quite horrible from maintenance point of view, especially trying to stuff all the bits everywhere to try to keep stuff in registers in asm code. Looking at it now I wonder if all this stuffing hasn't wasted more cycles than saved on the asm side.