Talk:Bandai FCG board: Difference between revisions
From NESdev Wiki
Jump to navigationJump to search
NewRisingSun (talk | contribs) No edit summary |
No edit summary |
||
| 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) | 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) | :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) | |||
Revision as of 21:35, 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)
