Wrong sounds - Githubissues

gyurco commented 2 years ago

I've tried to put this OPL2 code to the Next186 SOC here: https://github.com/gyurco/Next186/tree/jtopl

As this is much more resource-friendly than the original, it looks a great replacement. However there are some issues:

sounds are often missing if the CPU writes too fast. That might be not a jtopl2 issue, but the game itself doesn't prepared for fast CPUs. However the original has a kind of FIFO between the CPU and the opl3 (reminds me of the Genesis core). Is it possible somehow to expose a 'busy' bit for implementing such FIFO?
some sounds are wrong even if the CPU is slowed down. Example: Buzz Aldrin's Race Into Space. There's a 'ringing' sound where it shouldn't. I can try to export from Dosbox to VGM to check if it helps.

jotego commented 2 years ago

Strangely, the OPL chips don't have a busy bit, like the other Yamaha chips. I think that if PC software fails to write to the OPL2, it is running too fast indeed. If you want to prevent bad writes, just have a 1/2-bit counter ran by the OPL2 sample output. If the CPU tries to write twice to addr=1 before the counter expires, then hold the CPU or use your FIFO. In any case, what you need to look at is at least one sample distance between two writes to addr=1.

As for the bad sounds, it's probably the same as #2. I'm closing it here for now but if you see #2 fixed and you still have problems, please let me now.

jotego commented 2 years ago

Could you get those VGM files after all? This chip goes with another two in the DEC0 games and it's hard to pin point what's going in that set.

gyurco commented 2 years ago

Here's one capture I did in DosBox. The game has an extra ringing sound with some notes when the game itself plays the tune via jtopl. Unfortunately I couldn't cross-check the captures replayed with jtopl, as I didn't find a DRO or VGM player for DOS real mode yet. baris.zip

gyurco commented 2 years ago

I tried to use the 'sample' output to rate-limit the input data, however it's connected to nowhere in jtopl.v.

jotego commented 2 years ago

I noticed it myself today too! I just connected the sample output to the right place in this commit. https://github.com/jotego/jtopl/commit/061aca180d6dff3ee4df6555527f4c7e90636e19

jotego commented 2 years ago

I couldn't play that VGM straight away as it seems to use other instruments that I don't have implemented in the simulation. I guess it may have a DAC or something. Nonetheless, I caught a problem similar to what you described in Monkey Island's introduction track and fixed it here: https://github.com/jotego/jtopl/commit/2dbc69187fabf99d4e557ed336dbf91d6e592bbc Please give it a go.

jotego commented 2 years ago

This was the bug: https://github.com/verilator/verilator/issues/3290

gyurco commented 2 years ago

I found your sim, and I think it just mis-parses the VGM somewhere, as I didn't find any reference about that missing VGM command. Also the sample rate and the YM frequency displayed are very wrong.

YM Freq = 1077321369 Hz
Sample rate 17536 Hz. Sampling period 57024ns
ERROR: Unsupported VGM command 0xaa at offset 0x87

However the fix worked, the tune sounds perfectly! Thanks.

I found out how PC games made sure that no change was sent to the chip before it was ready: they read the status register a number of times. Reading on the ISA bus held the CPU for a constant amount of time, hence they timed the delay with those reads.

jotego / jtopl

Wrong sounds #3