NES-SFEXPROM-01: Anyone have a clue what the hell this is?
Moderator: Moderators
NES-SFEXPROM-01: Anyone have a clue what the hell this is?
I came across this oddball board in Bases Loaded (revision 0) today. It's some sort of SFROM board, except it has an extra 42-pin chip labeled "NES-LD-0-EXP283". It's labeled on the PCB as "EXP IC".
My other Bases Loaded carts do not use this, revision A uses plain SFROM and revision B uses SF1ROM.
Here's a bad picture of it:
Anyone have any idea what its purpose is?
My other Bases Loaded carts do not use this, revision A uses plain SFROM and revision B uses SF1ROM.
Here's a bad picture of it:
Anyone have any idea what its purpose is?
Re: NES-SFEXPROM-01: Anyone have a clue what the hell this i
I'm curious too as to what it does. I have a cart board somewhere with one of those on it. I was gonna poke around some time but I haven't had the chance to do it yet.BootGod wrote:I came across this oddball board in Bases Loaded (revision 0) today. It's some sort of SFROM board, except it has an extra 42-pin chip labeled "NES-LD-0-EXP283". It's labeled on the PCB as "EXP IC".
My other Bases Loaded carts do not use this, revision A uses plain SFROM and revision B uses SF1ROM.
Here's a bad picture of it:
Anyone have any idea what its purpose is?
/* this is a comment */
Japan version have extra sound chip.
http://cah4e3.shedevr.org.ru/misc/MOEPRO.TXT
http://cah4e3.shedevr.org.ru/misc/MoeProSound.zip
controlled by 0x7000 register, don't know what exactly, but it plays digital samples, selected by writing to register. (VirtuaNES supports it as I know)...
Bases loaded uses 0x7000 address too...
http://cah4e3.shedevr.org.ru/misc/MOEPRO.TXT
http://cah4e3.shedevr.org.ru/misc/MoeProSound.zip
controlled by 0x7000 register, don't know what exactly, but it plays digital samples, selected by writing to register. (VirtuaNES supports it as I know)...
Bases loaded uses 0x7000 address too...
OK, I think I know what the chip does.
I pinned it out tonight. A0-A17 and D0-D7 of the PRG ROM connect to it, along with /CE and WRAM /CE from the MMC1, and then /CE comes out of the chip and goes to the PRG ROM.
R/W and M2 are not connected to it. I suspect the chip is some kind of patcher, and possibly returns stuff at 6000-7FFFh. Some more examination on copyNES will be required.
I will then remove the ROM and drop in a resistor network to pull the data lines high or low, and then we'll see which bytes it replaces. Should be an interesting little experiment.
I pinned it out tonight. A0-A17 and D0-D7 of the PRG ROM connect to it, along with /CE and WRAM /CE from the MMC1, and then /CE comes out of the chip and goes to the PRG ROM.
R/W and M2 are not connected to it. I suspect the chip is some kind of patcher, and possibly returns stuff at 6000-7FFFh. Some more examination on copyNES will be required.
I will then remove the ROM and drop in a resistor network to pull the data lines high or low, and then we'll see which bytes it replaces. Should be an interesting little experiment.
/* this is a comment */
I'd be very suprised if it didn't read the patched value... HOWEVER, the chip also watches 6000-7FFFh. So viewing the ROM might shed some clues on it. They hooked up WRAM /CE to the chip also, so maybe some accesses to 6000-7FFFh trigger the "fix". This way, the ROM gets patched after it executes code /loads data once maybe. Just a guess.BootGod wrote:So he was right, someone else suggested this theory the other day. The byte it patches is 0x180 in each 8K bank. The value on the ROM is 0x60, it replaces it with 0x05.
Why is it that copynes wouldn't read it as the patched value? Doesn't it see it just as the NES would?
/* this is a comment */
That could be, worth a shot anyways. The data dumped using normal sxrom plugin actually does not boot. It also may be patching more than that one address, I figured the value is supposed to be 0x05 because the code nearby suggests that's what it should be and changing it to this allows the game to seemingly run fine.
On a side note, why the heck would they go thru this trouble to fix a bad ROM run? Wouldn't it be more cost effective just too run a new batch, rather than create a specialized PCB and throwing in the patch chip?
On a side note, why the heck would they go thru this trouble to fix a bad ROM run? Wouldn't it be more cost effective just too run a new batch, rather than create a specialized PCB and throwing in the patch chip?