FM Timer B bug + VDP vertical scrolling bug

AamirM's Regen forum

Moderator: AamirM

Post Reply
Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

FM Timer B bug + VDP vertical scrolling bug

Post by Eke » Mon Feb 22, 2010 8:29 am

Here are 2 bugs I encountered in my emu, which also happen in Regen:

(1) in the game "Der Langrisser II" (Langrisser Hikari II), there are DAC samples being played at the sega logo when they shouldn't .

After some investigation, I figured the problem came from Timer B counter not being loaded properly, in my case because I was doing this to detect Timer B LOAD bit changes (FM register 0x27):

Code: Select all

if ((v&2) & !(ym2612.OPN.ST.mode&2))
    ym2612.OPN.ST.TBC = ym2612.OPN.ST.TBL;
which obviously never happen (because !0 = 1 and 2 & 1 = 0)

it should be:

Code: Select all

  if ((v&2) && !(ym2612.OPN.ST.mode&2))


    ym2612.OPN.ST.TBC = ym2612.OPN.ST.TBL;
I suspect Regen is using the exact same bugged code, that's why I thought I should share it with you, the result being that Timer B is overflowing too early the first time (after the first overflow it is reloaded with correct value but it's enough to desync the Z80 program)


(2) In F1 World Championship (demo mode), the left-most 2-cells are sometime not vertically scrolled correctly. It's because vertical scroll value should not be added for the first 2-cells when the horizontal scroll value makes them only partially displayed (fine scroll value).

AamirM
Very interested
Posts: 472
Joined: Mon Feb 18, 2008 8:23 am
Contact:

Post by AamirM » Tue Mar 09, 2010 9:26 am

Thank you very much for bug reports and fixes. You save so much of my time :).

blargg
Newbie
Posts: 7
Joined: Sat Feb 20, 2010 6:27 am

Re: FM Timer B bug + VDP vertical scrolling bug

Post by blargg » Fri Mar 12, 2010 8:28 pm

Eke wrote:After some investigation, I figured the problem came from Timer B counter not being loaded properly, in my case because I was doing this to detect Timer B LOAD bit changes (FM register 0x27):

Code: Select all

if ((v&2) & !(ym2612.OPN.ST.mode&2))
    ym2612.OPN.ST.TBC = ym2612.OPN.ST.TBL;
I'm surprised your compiler didn't issue a warning, since it can easily determine that this will never be true. Hmmm, gcc 4.3.2 doesn't issue a warning, even with high warning levels. Even with -Wunreachable-code, the following generates no warnings:

Code: Select all

int main( int argc, char* argv [] ) {
    if ( (argc & 2) & !(argc & 4) )
        return 1; // unreachable
    return 0;
}
Changing it to if ( 2 & !(argc & 4) ) does generate a warning. Too bad, since accidentally using & instead of && is sort of like using = instead of ==, for which you generally do get a warning.

fox68k
Interested
Posts: 13
Joined: Wed Apr 01, 2009 1:22 pm

Re: FM Timer B bug + VDP vertical scrolling bug

Post by fox68k » Mon Apr 12, 2010 12:09 pm

Eke wrote:(2) In F1 World Championship (demo mode), the left-most 2-cells are sometime not vertically scrolled correctly. It's because vertical scroll value should not be added for the first 2-cells when the horizontal scroll value makes them only partially displayed (fine scroll value).
Eke,

this fix does not seem to be fine. For me, Gynoug scrolls incorrectly first two tiles when applied. HazeMD shows same issue, but i have not tried your emu out yet.

Could you please give it a try and let me know how your emu does?

Cheers.

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Mon Apr 12, 2010 3:20 pm

yes, it does the same. I guess it's another bug to track down.

EDIT: Kega / Gens have the same bug in Formula One (and got Gynoug vertical scrolling correct) so maybe it also happens on real hardware. Someone should test both games (Formula One and Gynoug) to check this out. I verified and the game does not do anything special related to timings.

from haze, about the bug in gynoug:
i’ll check the glitches but they may be correct, the Genesis has a bug when using column scroll and horizontal scrolling at the same time (which is what this game does) Basically the left most column (0-15 pixels) depending on the scroll value can’t be scrolled vertically.

I thought my implementation of the bug was correct, but I’ll double check it.
It might be interesting to check on real hardware which implementation is correct, note that F1 uses 32-cell mode while Gynoug uses 40-cell one, maybe the "bug" only affect the first mode.

fox68k
Interested
Posts: 13
Joined: Wed Apr 01, 2009 1:22 pm

Post by fox68k » Tue Apr 13, 2010 3:01 pm

Gynoug works fine on real hardware. F1 also looks fine in one youtube video i had a look at the other day, but would check on the real thing before stating anything.

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Tue Apr 13, 2010 3:46 pm

fox68k wrote:Gynoug works fine on real hardware. F1 also looks fine in one youtube video i had a look at the other day, but would check on the real thing before stating anything.
yes, I might be able to test this myself soon though when I got mt Everdrive cart :wink:

To reproduce the bug in F1, you need to let the demo mode run from the title screen and look at the left-most column, as it only happen in some conditions.

Interestingly, it's actually not really known or documented how 2-cell vertical scroll is handled when horizontal scrolling make the left-most column only partially visible:

(1) does it use VSRAM first entry, like the next column to be shown ?
(this fixes Gynoug and it's apparently what Gens/Kega are doing)

(2) is verticall scroll not applied to the left-most column while next columns use VSRAM entries as normal, incl. the last column ?
(this fixes F1)

(3) does the left-most column use VSRAM first entry then next columns use VSRAM entry #2,#3, etc ? (what about the right-most column that's also partially shown then ?)



EDIT: After investigating how this works , it appeared that Gynoug left column IS indeed corrupted on real hardware. More infos HERE.

Post Reply