Problem with Ganbare Goeman Gaiden: Keita Ougon Kiseru
Moderator: Moderators
Problem with Ganbare Goeman Gaiden: Keita Ougon Kiseru
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)
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)
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
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
Re: Problem with Ganbare Goeman Gaiden: Keita Ougon Kiseru
Actually, leaving only &F003 doesn't solves the problem.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.
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...
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
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
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.
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.
the current emulation problem is that text in the ending sequence is screwed.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
I guess pictures of the ending sequence on the real hardware could at least confirm how the game actually behaves
I think it's confirmed bug now
http://www.youtube.com/watch?v=g_4J5zZpivc
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...
http://www.youtube.com/watch?v=g_4J5zZpivc
from here http://www.geocities.jp/bgrtype/gsl/fc/ ... aiden.html(Staff Roll)
がんばれ ゴエモン がいでん
ス タ ッ フ
[スタッフロールの文字が何故かバグって読めない状態
でしたので、判読可能範囲で記載します。
なお使用ファミコンはMODEL NO. HVC-101、
1993年製ニューファミコン(AV仕様)]
桑名勇
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...
Miss twice and your out!
Have PRG 0 and PRG 1 dumps been verified?BootGod wrote:This was actually a software bug? I thought someone had verified on a real cart that it worked!