Viva Las Vegas (J) problem

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
NewRisingSun
Posts: 1282
Joined: Thu May 19, 2005 11:30 am

Viva Las Vegas (J) problem

Post by NewRisingSun » Sat Apr 01, 2006 1:55 pm

When playing "Blackjack", the screen split is totally messed up on almost any emulator I've tried, including Nestopia and Nintendulator. On the other hand, the US version ("Vegas Dream") does not have this problem. Therefore, I would believe that the current Japanese ROM image is bad, were it not for the fact that VirtuaNES displays it correctly.
So, is this a bad ROM image (so does VirtuaNES patch a bad ROM without telling me? Would be the first time ever...), or does every other emulator have incorrect emulation of this game's split screen?

I have the actual Japanese cartridge (no cartridge dumping tool however), so I know that the problem is not a bug in the game itself.

(Reposted from the Nestopia board, since I believe it might be relevant here.)

Josh
Posts: 69
Joined: Sat Mar 19, 2005 11:18 am

Post by Josh » Sat Apr 01, 2006 3:58 pm

I checked the VirtuaNES source, and there is indeed a game-specific hack for Viva Las Vegas. Here's the code in question:

Code: Select all

	if( crc == 0x11469ce3 ) {	// Viva! Las Vegas(J)
	}
	if( crc == 0xd878ebf5 ) {	// Ninja Ryukenden(J)
		nes->SetRenderMethod( NES::POST_ALL_RENDER );
	}
I haven't examined enough of the code to know what this actually does, though. It'd probably be a good idea to (1) open the cart and find out exactly which S?ROM board is used, and (2) have someone redump it.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Sun Apr 02, 2006 5:05 am

Code: Select all

if( crc == 0x11469ce3 ) {   // Viva! Las Vegas(J) 
   } 
And the hack is? Looks like an empty controlled block to me.

EDIT: Looking at VirtuaNES 0.92 source, I see this:

Code: Select all

if( crc == 0x11469ce3 ) {	// Viva! Las Vegas(J) ñ≥óùñÓóùÉpÉbÉ`(^^;
    lpCHR[0x0000] = 0x01;
}
It looks as if that merely sets the first byte of CHR data to 0x01 (which is what it already is on my copy).
Last edited by blargg on Sun Apr 02, 2006 5:22 am, edited 1 time in total.

User avatar
dXtr
Posts: 375
Joined: Tue Sep 21, 2004 12:11 am
Location: Karlshamn (Sweden)

Post by dXtr » Sun Apr 02, 2006 5:10 am

blargg wrote: And the hack is? Looks like an empty controlled block to me.
maybe that's why the game is messed up ;)
Sorry for misspellings, I'm from Sweden ^^

Marty
Posts: 40
Joined: Fri Nov 12, 2004 5:02 am

Post by Marty » Sun Apr 02, 2006 6:54 am

The first CHR byte is 0x00 on my copy. When I change it to 0x01 like VirtuaNES does it fixes the glitch. Not sure if that's a hack or a repairment of a bad dump though.

NewRisingSun
Posts: 1282
Joined: Thu May 19, 2005 11:30 am

Post by NewRisingSun » Sun Apr 02, 2006 7:21 am

Bad dump probably. The US version has "FF" as the first CHR byte, so I guess that's what it ought to be in the Japanese version as well. Glad we cleared that up.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Sun Apr 02, 2006 10:24 am

I'm still wondering how a CHR byte matters that much. I'm guessing it's used as a sprite #0 hit. And ignore my previous comment about my copy; it also had zero as the first CHR byte, and changing it to $FF works here too.

Post Reply