Problem with Ganbare Goeman Gaiden: Keita Ougon Kiseru

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Problem with Ganbare Goeman Gaiden: Keita Ougon Kiseru

Post by BootGod »

Someone reported this emulation bug a few days ago here

I traced out the extra LS chips to see what they were for, but they ended up not being related. LS20 for WRAM CE control and LS139 for supporting a 2nd PRG ROM and something A12 related (more on this later)

Anyways the bug here is mainly due to the piggybacking of 2 wiring configs into mapper 25 (A0,A1) and (A2,A3). This game uses the A0,A1 config but at the end of the game for whatever reason writes to C004-C007 instead C000-C003. If the emulator was using the correct address mask (F003), this wouldn't an issue, but instead they combine the masks for both configs something like:

addr = (addr & F003h) | ( (addr & 0Ch) >> 2)

Which in this case causes the wrong banking routines to be called.

Nestopia (which can tell the difference between the 2 using its DB) still suffers from this problem because it doesn't use an address mask and instead assigns handlers directly to C000,C001,C002,C003 so the writes to C004-C007 go unnoticed.

On a side note, this cart doesn't seem to support one-screen mirroring for some reason. Writing to 9000h, bit 0 is for H/V as usual but bit 1 is ignored.

Here is rough routing of the relevant LS pins if anyone cares. I wasn't real thorough, could be missing something. If someone with a better understanding of electronics than me can tell me what the point of the 1st LS139 decoder is, I'm curious to know. It seems like A12 would just pass thru it in all cases.

LS20 pinout (2nd set of IO not used)
1 (1A) -> VRC 15 -> CON 32 (M2)
2 (1B) -> VRC 1 -> CON 34 (PRG A13)
4 (1C) -> VRC 2 -> CON 35 (PRG A14)
5 (1D) -> VRC 14 -> CON 44 (PRG /CE) -> LS139 1 (/1E)
6 (1Y) -> diode / resistor -> WRAM 20 (/CE)

LS139 pinout
1 (/1E) -> LS20 5 (1D) -> VRC 14 -> CON 44 (PRG /CE)
2 (1DA) -> PRG 4 -> WRAM 2 -> CON 33 (PRG A12)
3 (1DB) Fixed High
4 (/1Y0) NC
5 (/1Y1) NC
6 (/1Y2) -> VRC 37 (PRG A12)
7 (/1Y3) NC

15 (/2E) -> PRG 24 -> VRC 8 (PRG /CE)
14 (2DA) -> PRG 30 -> VRC 39 (PRG A17)
13 (2DB) Fixed High
12 (/2Y0) NC
11 (/2Y1) NC
10 (/2Y2) NC (Goes to solder pad, unjumped, to GND)
9 (/2Y3) NC (Goes to PRG /CE on unused PRG slot)
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

I don't know what VRC37 is exactly, but it's not passing through, the demultiplexer being enabled with the PRG /CE. This is the kind of timing you would want for reading/writing the bus.

The logic is this:

if - the CPU addresss is above $8000
and - M2/Phi2 is high
and - PRG A12 is low
then - VRC 37 is active

The result is that it'll be active when $8xxx, $Axxx, $Cxxx, $Exxxx are accessed. If A12 was passed through, it would also go active at $6xxx, $4xxxx, $2xxx, $0xxx, and also not during the usual time of the bus cycle (M2 being high).
edit: maybe I got the addresses wrong, I didn't check
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

I guess I figured it was something along these lines, but what seems strange about this is that the VRC2 / 4 must already have this type of behavior built-in to the mapper itself, as most other VRC games do not have additional logic like this and yet do not have any bus-conflict problems.
CaH4e3
Posts: 71
Joined: Thu Oct 13, 2005 10:39 am

Re: Problem with Ganbare Goeman Gaiden: Keita Ougon Kiseru

Post by CaH4e3 »

BootGod wrote:Anyways the bug here is mainly due to the piggybacking of 2 wiring configs into mapper 25 (A0,A1) and (A2,A3). This game uses the A0,A1 config but at the end of the game for whatever reason writes to C004-C007 instead C000-C003. If the emulator was using the correct address mask (F003), this wouldn't an issue, but instead they combine the masks for both configs something like:

addr = (addr & F003h) | ( (addr & 0Ch) >> 2)

Which in this case causes the wrong banking routines to be called.
Actually, leaving only &F003 doesn't solves the problem.

sequence is
$C, $F, $F, $F, $F, $D, $F, $C
$C007-$C004, $B003-$B000 accordingly

masked addresses
$C003-$C000, $B003-$B000

so banks are
bank0 - $DC, bank1 - $FF, bank2 - $FF, bank3 - $CF

but game expect
bank0 - $FC, bank1 - $FD, bank2 - $FF, bank3 - $CF

so we have here strange "on the fly" mapper behaviour switching,
all game uses:
bank 0 - hi B002, lo B000 10 00
bank 1 - hi B003, lo B001 11 01
bank 2 - hi C002, lo C000 10 00
bank 3 - hi C003, lo C001 11 00

sprite-based staff subtitles uses:
bank0 - hi B001, lo B000 01 00
bank1 - hi B003, lo B002 11 10
bank2 - hi C001, lo C000 01 00
bank3 - hi C003, lo C002 11 10

so we have here accidentally A0 and A1 swap... but there is no any other register setup performed by game to switch to this behaviour...

my crazy idea was if A2 for C0xx area control bitswap for first four 1K CHR banks lol, it's even simple to emulate, but actually this will for sure broke any game using A2, A3 as mapper control bits...
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

Damn you Konami! So the correct mask fixes the Cxxx writes (perhaps by chance, the odd Ax line swap wouldn't affect it in this case) but the Bxxx writes load the wrong banks.

The VRC2 has no A2 connection in this case, so the fact that A2 is set in the Cxxx writes (for whatever reason) couldn't be a trigger for this hypothetical alt mode. Using CopyNES, I tried all sorts of various combos to see if I could invoke said mode, including the specific sequence you mentioned, but I always got the expected "normal" results.

The extra LS logic certainly doesn't seem to be a factor here.

I'll take another look at it when I have a chance, but I must say I'm a bit stumped right now :(
CaH4e3
Posts: 71
Joined: Thu Oct 13, 2005 10:39 am

Post by CaH4e3 »

Someone should test in on real cart on real hardware to see if there is the same graphics problem ;)
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Post by Banshaku »

I have one of the gambare goemon gaiden (I think there is 2 of them if my memory is good) but I don't remember which one. I will see if I can find where I stored it.
CaH4e3
Posts: 71
Joined: Thu Oct 13, 2005 10:39 am

Post by CaH4e3 »

yep, two of them, goemon in question is the first one
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Post by Banshaku »

For now just found 2nd one. I was planning to use it as a dev cart someday (if ever I felt to check how vrc2 works with ram). I will check again if I do have the first one or not. Maybe I do.

edit:

After searching a little bit, I do have the first one. But I need to re-read the thread to see exactly what needs to be tested (the actual game? some code with that mapper?) since I didn't follow closely that thread.
etabeta
Posts: 109
Joined: Wed Nov 29, 2006 10:11 am
Location: Trieste, Italy

Post by etabeta »

Banshaku wrote:After searching a little bit, I do have the first one. But I need to re-read the thread to see exactly what needs to be tested
the current emulation problem is that text in the ending sequence is screwed.

I guess pictures of the ending sequence on the real hardware could at least confirm how the game actually behaves
CaH4e3
Posts: 71
Joined: Thu Oct 13, 2005 10:39 am

Post by CaH4e3 »

I think it's confirmed bug now
http://www.youtube.com/watch?v=g_4J5zZpivc
(Staff Roll)

がんばれ ゴエモン がいでん

ス タ ッ フ

[スタッフロールの文字が何故かバグって読めない状態
でしたので、判読可能範囲で記載します。
なお使用ファミコンはMODEL NO. HVC-101、
1993年製ニューファミコン(AV仕様)]





桑名勇
from here http://www.geocities.jp/bgrtype/gsl/fc/ ... aiden.html


it looks like programmers forgot which mapper they using in a whole game and tried to map another variant of this mapper with swapped address bits that is all...
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

This was actually a software bug? I thought someone had verified on a real cart that it worked! :(

At least the mystery is solved though. Kinda funny Konami did all this crazy wiring stuff, I assume to thwart pirates, and they managed to thwart themselves in the process.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Miss twice and your out!

Post by tepples »

BootGod wrote:This was actually a software bug? I thought someone had verified on a real cart that it worked!
Have PRG 0 and PRG 1 dumps been verified?
CaH4e3
Posts: 71
Joined: Thu Oct 13, 2005 10:39 am

Post by CaH4e3 »

prg1 version exists?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

If some authentic carts work and others don't, such a revision is the most likely explanation. I too wonder if its existence has been verified.
Post Reply