MiSTer-devel / ao486_MiSTer

ao486 port for MiSTer
Other
252 stars 69 forks source link

King's Quest VII won't go to menu after core update #117

Closed Karmeck closed 2 years ago

Karmeck commented 2 years ago

Full discussion here https://misterfpga.org/viewtopic.php?p=49685#p49685

Game freeze befor geting to the menu. Logo works fine but after that there is a soft freeze.

Last working core was from October 10 2021. All cores after that result in game freeze.

Suspected reasons is this update, from February 11 2022:

ao486:

Found here https://misterfpga.org/viewtopic.php?p=43913#p43913

Karmeck commented 2 years ago

While all discussions is available using the provided link, I think some of it should be here as well.

User7182 replied: After rolling back that change KQ7 does get to the main menu.

Looking at the logic traces for the sound_dsp the game is polling to see if the DSP busy, and (apparently) never getting the answer it expects. This game uses 16-bit audio and auto init DMA, but nothing stands out to me where that would make a difference.

I'll run some more tests and see if I can narrow down what is happening.

Held posted some useful links:

Here's a thread with a list of 16-bit audio games: https://www.vogons.org/viewtopic.php?f=62&t=54670 And a thread on the hanging note bug with a fix: https://www.vogons.org/viewtopic.php?f=24&t=77392

user7182 commented 2 years ago

It appears that Kings Quest 7 doesn't poll the write status port fast enough before the next auto-init DMA transfer starts. The result is every time the game asks if the DSP is busy it always returns yes. The logic around the DSP busy flag that I added was written to guarantee games saw at least one busy edge regardless of timing, but that approach clearly doesn't work (especially with auto-init).

I don't have any real hardware to know how this is supposed to work, so I'm basing everything on what the software needs. I took a look at some other emulators to see how they approached it.

DOSBox will return busy for 8 write status reads, and not-busy for another 8.

PCem has a similar approach, but it does 2 reads busy, 2 reads not busy.

DOSBox-X has more logic, and gives you the option to configure the period and duty cycle. Depending on your config setting it will try and simulate the timing.

SnarkBarker sets the busy flag when when its handling a command, and when its executing in the TF0 (Timer 0 Interrupt Vector) on the 8051 micro-controller. However long it takes to execute the code will be the busy time.

I did a test that set a fixed busy time of around 1 ms, and cleared the flag at the end regardless if the software ever polled the write status port. This worked for both the original problem with Monkey Island, as well as Kings Quest 7. I'm going to do some more testing to see how this could effect any other games.