Talk:Bandai FCG board: Difference between revisions
From NESdev Wiki
Jump to navigationJump to search
(JBF Customs Delivers Again With This Refresh Jordan 1 “Red Python”!ENDVALUE!) |
No edit summary |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
The game "SD Gundam Gaiden - Knight Gundam Monogatari 2: Hikari no Kishi" (PRG-ROM CRC 73AC76DB) is listed [http://bootgod.dyndns.org:7777/profile.php?id=1752 on NesCartDB] as using an X24C02P (256-byte serial EEPROM), but the game's code interacts with it as if it were an X24C0'''1'''P (128-byte serial EEPROM). The game claims to have two (128-byte) save slots, and the game even calls its "read from EEPROM" ($08:$9CEC) and "write to EEPROM" ($08:$9D22) routines with addresses greater than 128, only to have the upper bit get masked off (to replace it with the R/W bit) - as a result, both save slots always contain the same data. Is this for real, or am I losing my mind? --[[User:Quietust|Quietust]] ([[User talk:Quietust|talk]]) 09:41, 20 May 2020 (MDT) | |||
:I have not checked the original Nintendulator, but NintendulatorNRS has the game provide two independent save slots. I don't see anything at PC $9CEC in particular, but the address byte is set at PC $9C92, where it is given as an input in $D2, copied to $D3, with a loop counter in $D4. In every iteration, $D3 is shifted one bit to the left, with carry deciding whether a 0 or 1 bit is sent. I don't see where anything is masked off and replaced with R/W. [[User:NewRisingSun|NewRisingSun]] ([[User talk:NewRisingSun|talk]]) 11:43, 20 May 2020 (MDT) | |||
::The routines at $9CEC and $9D22 take the input address from $D2 and send it to the EEPROM with the high order bit either set (to read) or clear (to write). I tried setting a breakpoing at $9C92 and it never got hit - maybe the game has code to support ''both'' types of EEPROMs and something in my mapper code is causing it to go the wrong way? --[[User:Quietust|Quietust]] ([[User talk:Quietust|talk]]) 15:35, 20 May 2020 (MDT) | |||
:::Turns out that's exactly what's happening - apparently, the X24C02P responds with data=1 when reading in certain "invalid" states while the X24C01P responds with data=0, and this game relies on that to detect what type of chip is attached. Time to go back to the datasheets... --[[User:Quietust|Quietust]] ([[User talk:Quietust|talk]]) 15:47, 20 May 2020 (MDT) | |||
Latest revision as of 21:47, 20 May 2020
The game "SD Gundam Gaiden - Knight Gundam Monogatari 2: Hikari no Kishi" (PRG-ROM CRC 73AC76DB) is listed on NesCartDB as using an X24C02P (256-byte serial EEPROM), but the game's code interacts with it as if it were an X24C01P (128-byte serial EEPROM). The game claims to have two (128-byte) save slots, and the game even calls its "read from EEPROM" ($08:$9CEC) and "write to EEPROM" ($08:$9D22) routines with addresses greater than 128, only to have the upper bit get masked off (to replace it with the R/W bit) - as a result, both save slots always contain the same data. Is this for real, or am I losing my mind? --Quietust (talk) 09:41, 20 May 2020 (MDT)
- I have not checked the original Nintendulator, but NintendulatorNRS has the game provide two independent save slots. I don't see anything at PC $9CEC in particular, but the address byte is set at PC $9C92, where it is given as an input in $D2, copied to $D3, with a loop counter in $D4. In every iteration, $D3 is shifted one bit to the left, with carry deciding whether a 0 or 1 bit is sent. I don't see where anything is masked off and replaced with R/W. NewRisingSun (talk) 11:43, 20 May 2020 (MDT)
- The routines at $9CEC and $9D22 take the input address from $D2 and send it to the EEPROM with the high order bit either set (to read) or clear (to write). I tried setting a breakpoing at $9C92 and it never got hit - maybe the game has code to support both types of EEPROMs and something in my mapper code is causing it to go the wrong way? --Quietust (talk) 15:35, 20 May 2020 (MDT)
- Turns out that's exactly what's happening - apparently, the X24C02P responds with data=1 when reading in certain "invalid" states while the X24C01P responds with data=0, and this game relies on that to detect what type of chip is attached. Time to go back to the datasheets... --Quietust (talk) 15:47, 20 May 2020 (MDT)
- The routines at $9CEC and $9D22 take the input address from $D2 and send it to the EEPROM with the high order bit either set (to read) or clear (to write). I tried setting a breakpoing at $9C92 and it never got hit - maybe the game has code to support both types of EEPROMs and something in my mapper code is causing it to go the wrong way? --Quietust (talk) 15:35, 20 May 2020 (MDT)
