search

EmulatorArchive / genplus-gx

Automatically exported from code.google.com/p/genplus-gx
Other
1 stars 0 forks source link

Final Fight CD Invisible Opening #335

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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 :)

Original issue reported on code.google.com by TheRealB...@gmail.com on 3 May 2013 at 6:32

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ekeeke31@gmail.com on 4 May 2013 at 7:03

GoogleCodeExporter commented 9 years ago 
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.

Original comment by TheRealB...@gmail.com on 5 May 2013 at 3:45

GoogleCodeExporter commented 9 years ago 
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...

Original comment by ekeeke31@gmail.com on 12 May 2013 at 7:53