NES-SFEXPROM-01: Anyone have a clue what the hell this is?

[BootGod]

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:

bootgod.dyndns.org.7777.downloads.sfexprom.jpg

Anyone have any idea what its purpose is?

[attachment fairy was here]

[kevtris]

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?

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.

[CaH4e3]

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...

[tepples]

Given that any game that uses expansion speech in 60-pin has to be converted to DMC for 72-pin, perhaps the DMC samples are in one chip and the code is in another.

[kevtris]

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.

[BootGod]

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?

[kevtris]

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?

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]

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?

[tepples]

Copy protection.

[kevtris]

Copy protection.

I highly doubt it- the lockout chip is pretty much all the copy protection you need.

No, I'm fairly certain it's a "ROM fixer" at this point.

[tepples]

Copy protection.

I highly doubt it- the lockout chip is pretty much all the copy protection you need.

Not for famiclones, which use the 60 pin connector.

[lidnariq]

Recent research in the Discord described the pinout of the EXP283:

Code: Select all

             NC ?? | 1   42 | -- +5V
             NC ?? | 2   41 | <- MMC1 PRG A17
             NC ?? | 3   40 | <- MMC1 PRG A15
             NC ?? | 4   39 | <- MMC1 PRG A14
             NC ?? | 5   38 | <- CPU A12
             NC ?? | 6   37 | <- CPU A13
             NC ?? | 7   36 | <- CPU A7
             NC ?? | 8   35 | <- CPU A8
             NC ?? | 9   34 | <- CPU A6
 PRG RAM +CE IN -> | 10  33 | <- CPU A9
            GND ?? | 11  32 | <- CPU A5
         CPU D7 <> | 12  31 | <- CPU A11
         CPU D6 <> | 13  30 | <- CPU A4
         CPU D5 <> | 14  29 | <- MMC1 PRG A16
         CPU D4 <> | 15  28 | <- CPU A3
         CPU D3 <> | 16  27 | <- CPU A10
         CPU D2 <> | 17  26 | <- CPU A2
         CPU D1 <> | 18  25 | -> PRG ROM /CE OUT
         CPU D0 <> | 19  24 | <- CPU A1
             NC ?? | 20  23 | <- MMC1 PRG /CE IN
            GND -- | 21  22 | <- CPU A0

and appears to have fully described the behavior:
* If the lower 15 bits of the PRG ROM address is $0180, drive $60 instead of $05; this replaces lda $0576 with lda $6076
* Reads from $6000-$6FFF copy MMC1 PRG ROM A15 through A17 to CPU D4 through D6; the other data lines are driven low.

On this board is an MMC1A, which cannot disable its own PRG RAM mapping; thus the above PRG RAM +CE IN pin must be part of the decoder.


There appears to have been a crash bug around NMI reentry, where $0576 was holding a shadow copy of the current PRG bank.

[TakuikaNinja]

I'm still not convinced on the original bug causing a crash yet (if anyone is able to replicate it on the rev 0 dump, please share a Mesen2 savestate) but the patching behaviour is corroborated by the fact that this game appears to convert JF-13 writes to MMC1 writes at runtime. (This is a localisation/port of Moero!! Pro Yakyuu, after all) If I'm understanding this correctly, the patched read would yield:

Code: Select all

7  bit  0
0CPP 0000
||||   ||
+|++------ Select 32 KiB PRG bank at $8000
 +-----++- Select 8 KiB CHR bank at $0000

Which is then converted to the MMC1 register writes shortly after. It appears that the ROM size was doubled from the original 128K to 256K (probably to fit the new DPCM samples), thus necessitating an extra PRG bank bit to be crammed into D7 of the original JF-13 register mirror.

[NewRisingSun]

No, just D~[.PPP ....]

Detailed results from CopyNES' BankWatch probe attached

[TakuikaNinja]

I've finally replicated the crash, here's what seems to happen:

1. NMI 1: $817D call sets $0576 = $20 but the bankswitch itself is interrupted by a nested NMI, so it's still bank 0.
2. NMI 2: Also calls $817D as part of far-calling the sound engine, saves the value in $0576 expecting it to be $00, saves $20 instead.
3. Sound engine call returns, restores $0576 = $20, bankswitches to bank 4.
4. RTS expecting bank 0, crash.

The EXP patch fixes step 2: the new $6067 read returns the correct bank number of 0, preventing the crash. Later revisions add code to set/use a "bail from NMI without doing anything" flag in $077A instead.

I have attached a ZIP file containing the Mesen2 savestate and the tracelog leading up to the crash.