Photos of SMB3 PCB (MMC3 entirely on discrete 74xx chips)

In case anyone would like to rev-en. Unfortunately those photos are not mine, I waited half of year for one man to take them for me.

Top:


Bottom:


Shell:

this mapper 106,two version dumped rom.

Parts:
74LS161 74LS04 74LS670 74LS32
74LS161 74LS670 74LS670 23C1024
74LS74 74LS670 74LS374
74LS74 74LS32 74LS374
74LS138
74LS20 74LS157 GM76C88 23C1024 23C1024
4040 74LS86
74LS393 74LS00
74LS32 74LS74 74LS32 74LS08

Findings:
Presence of 4040 and 76C88 means this is not a N108 clone. There is some kind of IRQ source (the 4040) and PRG RAM (the 76C88)

Edit: Summarizing FCEUX's mapper 106 code:
Register mask: $800F.
Writes to $8000 through $8007: Set eight 1 KiB CHR banks. Bottom four banks deny use of LSbit, like MMC3, but allow upper 7 bits to be set differently.
Writes to $8008 through $800B: Set four 8 KiB PRG banks. Banks at $8000 (reg $8008) and $E000 (reg $800B) force $10s bit high.
Write to $800C: Identical to MMC3 $A000 mirroring control
Write to $800D: Acknowledge and disable IRQ
Write to $800E: Set upper byte of 16-bit terminal count
Write to $800F: Set lower byte of 16-bit terminal count, and enable counter. Counts M2 cycles.

I'm not entirely convinced the enumerated parts match the functional description. I don't think I see enough possible simple logic to compare every bit of the 4040's output against latches.

That is awesome AF

I got the mapper 106 SMB3 version:


Probably the one from first post is unmodified SMB3.

this mapper 106 or 56

Yes, this is mapper 106. This version works only in NTSC/Dendy mode.
What is mapper 56, as FCEUX does not have it implemented?

mapper 56 is KAISER_KS7022C or KAISER_KS202

ines or nes 2.0 is Chicken ribs!

After a lot of days spend on rev-in this based only on those diffrent angle photos, I got the following results, but I would like to ask for help rev-ing out the interrupt part as not all connections are probably OK (other parts are 100% certain)


PRG banking, CHR banking, mirroring works exactly the same way like in MMC3 (which is really rare), with the exception that bit 7 and bit 6 of bank select register are trated as if b7=0 (CHR A12 inversion off) and b6=1 ($C000-$DFFF swappable, $8000-$9FFF fixed to second-last bank), but I think original SMB3 always uses the configuration above. (I dont have access to ROM of this bootleg so I don't have idea if the game was modified and how much). I think that probably the game was not modified at all, that's why the mapper is so much similar to MMC3.

Now the tricky part - interrupts and counters. This probably does not work in the same way as in MMC3 because there is only one 8 bit counter (2x74191) which is both preloaded and counted down. But again, as I have observed, original SMB3 preloads IRQ counter every frame in NMI.

I have doubts if all connections of interrupt part are OK (other parts are 100% ok).
Except those 2x74191 there is 4040 and 2x74393. Outputs of 4040 are connected to inputs of 7420 (those connections are certain).

I don't even know what is clocking this bootleg's counter. There is one modification on this PCB:


So they put R+C instead on PPU-!A12 (probably some kind of filter, maybe they wanted to filter out those 8 consecutive edges on PPU_A12) - i dont know value of C, only R can be read.

Next modification is cut trace on IC3A input 5 (probably slight change in prescaling)

However, this filtered PPU-!A12 does not seem to be clocking the unit, it's probably ANDED with cpu-romsel (inverted cpu-!romsel from the connector) but this is not 100% sure as critical tracks are under chips and only deduction is available.

That's a highpass filter, not a lowpass filter. Wouldn't be suitable for filtering a PPU signal to generate a clock per scanline.

I can't fathom any reason to AND /PPUA12 with /ROMSEL. The phase from sprite tile fetch to the next will end up clocking the counter one or two times:
... maybe there's something clever such that that always ends up the same integer, and not 113+2/3 ?

I can't figure out how the half of the 74'393 that you've labelled IC1A would ever let the '4040 run at all. (Every 8 clocks it'd clear the '4040?)

Could you annotate over the IRQ section of your schematic what parts you're confident of vs not?

I have this variant, if you're unsure about some traces I can check them with my multimeter. Also can dump it with kazzo. I *think* I tried at a point to dump it with MMC3_v2 but it didn't work? I need to check again.

That would be really great, could you please chceck those connections (chip name.pin name)

1) IC25.12 == IC28.11
2) IC25.13 == R3.2
3) IC25.11 == IC1.13
4) IC25.11 == IC1.1
5) IC25.11 == IC2.10
6) IC1.6 == IC15.5
7) IC1.6 == IC28.9
8) IC6.9 == IC4.9
9) IC1.9 == IC6.10
10) IC5.10 - does connect to any of IC25 pins?
11) IC1.12 - any other pins it connect to?
12) IC1.2 - any other pins it connect to?


If you cend me mmc3_v2, then I can modify it to work with this game.

You can find the mmc3_v2 script in the kazzo file library.
I'll try it tonight if I have time. I'm not a techy person so I may get lost a bit with your drawing heh.

Just use the chip & pin numbers from this photo:

The default Kazzo script tries to switch the MMC3 into 8+8+16F mode, which Krzysiobal says isn't supported by this hardware, so... that's probably why.

Added a note to 5)
Fixed error in 4)

While checking your wiring of the back, why did you connect IC3.5? the trace is cut.

Thank you so much!! Now everything is clear. Could you just check that?
ic2.10 == ic25.13
ic1.2 == ic25.11
ic1.12 == r3.2


Yes, I marked this on schematics as `trace is cut`, thank you for notifing.

a) yes
b) yes
c) no

This is fixed schematics according to MLX suggestion:


Assuming that SMB3 ROM was not modified at all, it should still work - after scanline counter is reset (*), it waits 13 scanlines (13*114 M2 cycles) and then every 114 M2 cycles, scanline counter is clocked.

(*) IC1A resets it when there are at least 8 CPU cycles outside $8000-$ffff (happens only when using OAM_DMA write or executing code from RAM?), so should automatically reset it one time per frame (in VBLANK)

Why 13 scanlines delay? SMB3 NTSC version resets scanline counter in VBLANK at scanline 248, 13 scanlines ahead before rendering next frame starts.

It is really awesome how those bootleggers at their time (this cart is dated for 89-09) have big knowledge and understanding of the NES hardware. Today, when there are really many NES freaks and access to common knowledge is not limited, still not everything is known.

I'll try to find where goes IC1.12 when I have some time. Maybe the trace is cut under the chip?
Also I hope I can bring back my PC back from work so I can dump the cartridge. but I don't know when I can do that.

I thought it will be ic1.12 == r3.2 because r3.2 is the only trace that it's not connected to anything but goes there.

Yes, it might me cut out totally and ic1.12 not connected to anything (so it will behave like would be connected to +5V).

That would be even most rational answer because it is responsible for second way of acknowledging interrupt and original MMC3 has only one way.

Alright so checked again and there's continuity from IC1.12 on the upper leg of C3.