Langrisser II (v1.2) opening tile graphics bug

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Post Reply
byuu
Interested
Posts: 40
Joined: Thu Feb 28, 2008 4:45 pm

Langrisser II (v1.2) opening tile graphics bug

Post by byuu » Thu Feb 23, 2017 8:24 am

Long-term veterans may remember that Genecyst had a problem with this game, where it rendered the characters displayed in the intro incorrectly. And it looks like I'm experiencing the same bug. But unfortunately, nobody ever explained what actually caused it :/

So this is what the bug looks like:

Image

And this is what it's supposed to look like:

Image

The text at the bottom of the screen is rendered as 16x16 sprites.

The problem is that the sprite layout in VRAM is:

AB
CD

Which requires sprite addressing like this:

Code: Select all

uint tileNumber = tileY * (o.width >> 3) + tileX;
However, this isn't how the Genesis works. That breaks every other large sprite in every other game. It's supposed to be like this:

Code: Select all

uint tileNumber = tileX * (o.height >> 3) + tileY;

In other words, for the tiles in Langrisser II to render correctly, they should exist in VRAM like this:

AC
BD

... but they don't!!

I suspected I had an emulator bug where I was writing to VRAM improperly.

So I traced the game back to PC=$008c6a where it triggers a 68K->VRAM DMA from $ffd208 to $a180 for the tile that resides onscreen at Y=176-191; X=64-79.

So I looked for where $ffd208 was being filled out, and that's at PC=$02c45c.

I then compared higan's trace log to Mednafen's, and the exact same bytes are being written in the exact same order into work RAM.

As such, the tile data in VRAM when the sprite is being rendered is definitely laid out in memory as:

AB
CD

So ... what gives here? How are other emulators rendering tiles, that are in memory in the wrong order, correctly? :/

User avatar
Stef
Very interested
Posts: 2627
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Langrisser II (v1.2) opening tile graphics bug

Post by Stef » Thu Feb 23, 2017 12:12 pm

From my memory (it was 15 years ago so i may be wrong) i think this bug is due to an incorrect VRAM to VRAM DMA copy implementation.

byuu
Interested
Posts: 40
Joined: Thu Feb 28, 2008 4:45 pm

Re: Langrisser II (v1.2) opening tile graphics bug

Post by byuu » Thu Feb 23, 2017 2:13 pm

Yep, you were right, thank you! :D

It's really weird because the game loads the tiledata incorrectly into VRAM via 68K->VRAM DMA.

I guess it then does some weird VRAM copy magic to reorder data. Which is ... ridiculous, but whatever.

The problem was that I was trying to do the VRAM copy as word-based transfers instead of byte-based transfers.

The latter is actually really difficult and means I can't simulate VRAM copy as if they were writing to the data port. Also means the address (A0-A15) is incremented after every byte, rather than after every word.

User avatar
Stef
Very interested
Posts: 2627
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Langrisser II (v1.2) opening tile graphics bug

Post by Stef » Thu Feb 23, 2017 4:26 pm

Yeah the VRAM copy (and in fact all VRAM writes internally) is byte wide, i had it wrong as well when i first implemented it in Gens.
If i remember correctly you can also observe the bug in James Pond 3 - Operation Starfish game (some platforms requires correct VRAM Copy DMA for correct display, no idea how the implemented that internally O_o ?)

Mask of Destiny
Very interested
Posts: 557
Joined: Thu Nov 30, 2006 6:30 am

Re: Langrisser II (v1.2) opening tile graphics bug

Post by Mask of Destiny » Thu Feb 23, 2017 11:50 pm

byuu wrote:The latter is actually really difficult and means I can't simulate VRAM copy as if they were writing to the data port. Also means the address (A0-A15) is incremented after every byte, rather than after every word.
Yeah, only 68K->VDP DMA goes through the FIFO as if it was written to the data port. Both VRAM copy and VRAM fill bypass it (though fill does use a value from the FIFO in a hacky way).

It's worth noting that while it checks a bunch of other things that are not especially important, the VDP FIFO Test ROM Nemesis wrote is useful for verifying that you got all the FIFO/DMA stuff correct.

byuu
Interested
Posts: 40
Joined: Thu Feb 28, 2008 4:45 pm

Re: Langrisser II (v1.2) opening tile graphics bug

Post by byuu » Fri Feb 24, 2017 10:24 am

Thanks, I definitely want to work my way to that. I still don't understand the VDP FIFO at all, nor how to go about emulating it.

But I do hope to emulate that at some point, especially given I have a cycle-timed VDP core, so I should be able to handle it with no serious problems. I'll be sure to use his test ROM when I get there.

Current nightmare fuel is the YM2612. Thankfully, Cydrak wrote an implementation that's extremely readable. Now I just have to study it for a few weeks to learn how it all works.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests