Final Fight CD Invisible Opening

[Former user]

Original issue 335 created by TheRealBurntLasagna on 2013-05-03T18:32:39.000Z:

Q: What steps will reproduce the problem?

A: Start Final Fight CD on SVN r774 and the intro video doesn't show, but the music plays. Intro is also not skippable anymore.

Q: What is the expected output? What do you see instead?

A: Intro should normally show up and be skippable. Now its a black screen and unskippable.

Q:What version of the emulator are you using (official, SVN revision,...)?

A: SVN r774.

I went back to SVN r773 and the problem didn't occur, which makes me think it is a problem with the changes made in r774.

Also, thanks for the fantastic Sega Multi emulator ekeeke! Your work is quite amazing :)

[Former user]

Comment # 1 originally posted by ekeeke31 on 2013-05-04T07:03:10.000Z:

Indeed, it seems this game does not like to wait for disk seek ime which was added in r774 and was needed for Panic!/Switch intro.

The thing is, both seek an audio track at the end of the disc so there should be some delay. The only difference is that in Final Fight CD, seeking is done when the drive is at the end of the first (data) track while in Switch/Panic!, it is done from the middle of the first track, the data track being much larger in this game than in Final Fight CD. I need to find a way to emulate disc seek time that work with both games (and other as well), but it is hard to modelize accurately since this is originally mostly mechanical.

[Former user]

Comment # 2 originally posted by TheRealBurntLasagna on 2013-05-05T03:45:14.000Z:

Interesting.
I noticed that even Kega Fusion has this issue with Panic!/Switch, and I'm tempted to say Gens as well. Looks like this issue is covered in allot of weeds.

In either case, I'm curious to see your antidote to this long lived emulation illness.

[Former user]

Comment # 3 originally posted by ekeeke31 on 2013-05-12T19:53:20.000Z:

Fixed in r777

For the record, it was an issue with CDD emulation and some undocumented status byte returned when a SEEK (and maybe others) command is sent. I figured that there was a return value indicating that current track infos should be invalidated/reseted, which is likely to happen when seeking in progress.

If the track infos are not invalidated/reseted, after some time (~17 CDD interrupts), a program jump occurs based on the previous track infos, which crashes the Main-CPU (and makes the intro hanging).

It just appeared that if seek time was ignored after a SEEK command and the command processed immediately (or with a delay < 17 interrupts), which is unlikely to happen with a real CD drive, the BIOS would have the time to read the next track time info and resets internal value to 0 (00:00:00 being track relative time after seeking the beginning of a track), and the bad jump would not occur...