Youkai Douchuuki PCB image with Namco-163 Removed

[Ben Boldt]

I removed the Namco-163 chip from Youkai Douchuuki for a homebrew Final Fantasy project I'm working on. This reveals the traces beneath the Namco-163. I thought I would share hi-res images of it in case it is useful to anyone.

[B00daW]

What are those extra edge connectors at the top of the board? Seems like they're connected to just about everything. Some sort of debugging/test clip?

[lidnariq]

Yeah. Whatever that test/QA harness is, it includes the mysterious N163 pin 44. (It's the narrow line without a real pad)

If I follow the 16 possible contacts (three are narrow, two are covered with resist) from left to right (the same side and direction from famicom pin 60 downto 31), they are, in order:
CHR ROM /CE
PRG RAM /CE
CHR A11
Mystery N163 pin #44 (narrow)
CHR A13
CHR A14
CHR A17 (covered with resist)
CHR A16
CHR A15
CHR A12
PRG A16
PRG A14
PRG A13
PRG A15
PRG A17 (covered with resist)
PRG ROM /CE

So they're basically just for verifying banking.

[Ben Boldt]

I built a new cartridge with this removed Namco-163, including CHR-RAM which seems to have never been done before, at least that I can find online. This was for a Final Fantasy hack that makes the game run on Namco-163 for expansion audio support. This hack runs great in emulators and it has a cool new custom sound engine that is proving to be really amazing.


(Note: Not working yet in the above picture, still experimenting with CHR-RAM when this was taken.)



When I built the hardware for this hack, I had to wire some of the CHR-RAM address pins directly to the PPU and 1 of them to the N163, or else there were graphical problems.

Originally, I connected all A10, 11, 12, 13 all to the N163 and that didn't work. Then I connected all 4 of them directly to the PPU and that acted better but also didn't work. I ended up wiring A10, A11 and A13 directly to PPU and A12 to N163. I'm not sure why it needs this combination, or even what the difference is between N163 and PPU versions of these pins. Notably, the original MMC1 Final Fantasy also connected only its CHR-RAM-A12 to the MMC1, but MMC1 doesn't have its own pins for CHR A10 or A11. So, maybe this is an artifact of how the original Final Fantasy software was written.

The ROM file does emulate properly in Nestopia, but it could be that the emulator is wrong and it should not work without further modification to the Final Fantasy software. At the very least, with the pinout that I ended up with, it matches the N163 CHR-RAM implementation in Nestopia. I am interested in figuring out the "correct" connections and seeing if this ROM hack will run on that hardware. If not, it points to an issue with the emulator.

Here is where I originally posted this:

http://www.romhacking.net/forum/index.p ... #msg307516

Code: Select all

                    HM62256BLP
               256kbit (32K) SRAM
              For Namco-163 CHR-RAM
                _________________
                |       V       |
            0 --| A14       VCC |-- +5V
Namco CHR A12 --| A12       /WE |-- PPU /WR
       PPU A7 --| A7        A13 |-- 0
       PPU A6 --| A6         A8 |-- PPU A8
       PPU A5 --| A5         A9 |-- PPU A9
       PPU A4 --| A4        A11 |-- PPU A11 (Not Namco)
       PPU A3 --| A3        /OE |-- PPU /RD
       PPU A2 --| A2        A10 |-- PPU A10 (Not Namco)
       PPU A1 --| A1        /CS |-- PPU A13 (Not Namco)
       PPU A0 --| A0         D7 |-- PPU D7
       PPU D0 --| D0         D6 |-- PPU D6
       PPU D1 --| D1         D5 |-- PPU D5
       PPU D2 --| D2         D4 |-- PPU D4
          GND --| D3         D3 |-- PPU D3
                |_______________|

It works with these connections, but I am wondering if any gurus out there know if this configuration is expected. Is there is some value in wiring all 4 of these address lines back to the N163 and pulling up pin 44 to see what happens? There is some hint here in a footnote that it may have something to do with CHR-RAM:

http://wiki.nesdev.com/w/index.php/Namc ... ily_pinout

Not even being sure if pin 44 is an input or an actual GND rail connection, I think I would throw a 10k up to 5V first and see what happens. Let me know if anyone thinks these things I have talked about here are valuable or valid to experiment with, and I would be willing to give it a try. I would be pretty happy to uncover some extra info that we can put on the nesdev wiki page.

[lidnariq]

I ended up wiring A10, A11 and A13 directly to PPU and A12 to N163. I'm not sure why it needs this combination, or even what the difference is between N163 and PPU versions of these pins.

That sounds like the game isn't initializing the CHR banking registers at all, and Nestopia accidentally/intentionally has "useful" defaults, rather than the far more likely all-0 or all-random values.

(Which specific hack so I can check in a debugger?)

I am interested in figuring out the "correct" connections and seeing if this ROM hack will run on that hardware.

Did you play with pins 33 and 34?

I believe your initial assumptions are correct; namely, that you should have been able to connect 62256 A10..A14 up to N163 CHR A10..A14, and N163 CHR ROM/CE up to 62256/CE, and PPU /RD and /WR to 62256 /RD and /WR.

Not even being sure if pin 44 is an input or an actual GND rail connection

I suspect pin 44 isn't internally connected to ground. Since you have it on a breakout board you should be able to measure what resistance (and/or diode drops) it has to other known-ground pins.


I determined both the fabrication technology of the MMC5 (It's NMOS, not CMOS) as well as whether a pin was an input or an output by measuring the amount of current a pin would source. Specifically: I have a microammeter that has a series resistance of 1kΩ; if the current to ground was less than the 200µA maximum supported in that mode but nonzero, I assumed it was an NMOS/TTL input. You should be able to do something similar.

[Ben Boldt]

I connected pin 33 to PPU /RD of the Nintendo, and I grounded pin 34.

For /CS of the RAM chip, I had only tried PPU A13, N163 CHR A13, and ground. I had never tried N163 CHR ROM /CE on this pin. Maybe that's the problem!

Should I be hooking it up like this?:

Code: Select all

                    HM62256BLP
               256kbit (32K) SRAM
              For Namco-163 CHR-RAM
                _________________
                |       V       |
Namco CHR A14 --| A14       VCC |-- +5V
Namco CHR A12 --| A12       /WE |-- PPU /WR
       PPU A7 --| A7        A13 |-- Namco CHR A13
       PPU A6 --| A6         A8 |-- PPU A8
       PPU A5 --| A5         A9 |-- PPU A9
       PPU A4 --| A4        A11 |-- Namco CHR A11
       PPU A3 --| A3        /OE |-- PPU /RD
       PPU A2 --| A2        A10 |-- Namco CHR A10
       PPU A1 --| A1        /CS |-- Namco CHR ROM /CE
       PPU A0 --| A0         D7 |-- PPU D7
       PPU D0 --| D0         D6 |-- PPU D6
       PPU D1 --| D1         D5 |-- PPU D5
       PPU D2 --| D2         D4 |-- PPU D4
          GND --| D3         D3 |-- PPU D3
                |_______________|

Here is the file in question:

https://sites.google.com/site/benboldt2 ... wn.nes.zip

It comes from this thread:

http://www.romhacking.net/forum/index.p ... 907.0.html

[lidnariq]

I connected pin 33 to PPU /RD of the Nintendo, and I grounded pin 34.

Pin 33 probably wants to be ground. I don't know about pin 34. (It'd be nice to figure out what pin 34 is ...)

I believe (although I've lost the citation) that CHR ROM /CE (pin 41) is ORed with pin 33, so that a 128 KiB 28-pin CHR ROMs could be used. But with two enables, like is necessary with RAM...

There's the possibility that the N163 (among the short list of mappers that support ROM nametables) might just not support CHR-RAM in lieu of CHR-ROM. I don't think it's likely, but I can construct elaborate stories of how they could have unintentionally broken that.

Should I be hooking it up like this?:[...]

That is what I'd assume. (Plus changing n163 pin 33)

That sounds like the game isn't initializing the CHR banking registers at all, and Nestopia accidentally/intentionally has "useful" defaults, rather than the far more likely all-0 or all-random values.

Nope, I definitely found the CHR banking initialization present when using Nintendulator. Of course, Nintendulator doesn't know what to do without CHR ROM, but that's pretty justifiable.

[Ben Boldt]

I finally got around to testing this. I hooked everything up according to the most recent CHR-RAM pinout (above) plus I grounded pin 33 of the N163. This works great! The game is fully functional like this. I included the 2 extra address lines, so this technically has 32k of CHR RAM now.

I also hooked up N163 Pin 34 to a switch, where I could connect it to +5V on one side, open in the middle, and GND on the other side. I ran this switch outside of the Nintendo so I could toggle it while running. I put a 10 nF from pin 34 to GND just to be safe.

When I ground or open pin 34, it works normally. When I set it to +5V, the game can run and the Namco-163 expansion audio works fine, but the graphics are screwed up, showing predominantly this sort of binary pattern (found this example image online):



The color palettes are still correct when it is doing this.

If I power on the game with pin 34 at 5V, it starts with the binary pattern. Then, while running, if switch it to GND, the graphics become garbled.

If I power on the game with pin 34 at GND, the graphics start OK, then I change it to +5V, the graphics go to the binary pattern. But in this case, the graphics can return to normal when I change pin 34 back to GND.

I have a pretty nice digital oscilloscope if there are any signals that you think I should look at - let me know if you have any ideas.

[lidnariq]

When I set it to +5V, the game can run and the Namco-163 expansion audio works fine, but the graphics are screwed up, showing predominantly this sort of binary pattern

That sounds like you're seeing the "treat open bus as PPU tiles" pattern, which should look like this:

open-bus-as-chr.png (582 Bytes) Viewed 8595 times

The color palettes are still correct when it is doing this.

So the 163's CIRAM/CE output ignores this input.

If I power on the game with pin 34 at GND, then change it to +5V, the graphics go to the binary pattern, but the graphics can return to normal when I change pin 34 back to GND.

This is expected

I have a pretty nice digital oscilloscope if there are any signals that you think I should look at - let me know if you have any ideas.

Based on your description, I expect that both pin 33 and pin 34 are both ORed with the internal CHR ROM banking signal before emerging on pin 41.... except this:

If I power on the game with pin 34 at 5V, then change it to GND, the graphics become garbled.

This is confusing.

I'm not really certain what to think that could imply. Maybe try connecting pin 34 to some slow clocked signal, and looking at pin 34, pin 41(CHRROM/CE), and pin 35(PPU A13)?


Anyway, did you have a chance to look at pin 44 ? The only stab in the dark I have is, maybe it's the partial product that indicates whether CIRAM/CE or CHRROM/CE will be asserted? If so, it should look very similar to PPU A13.

[Ben Boldt]

Sorry for the late reply on this and really sorry about what I am about to say.

In fact, when I hooked up the switch, I went to pin 33 instead of pin 34. So, when I flipped the switch, I was changing the PPU /RD signal and had pin 34 always to GND.

So, I returned pin 33 to ground and hooked the switch to pin 34 as intended. I played the game for a bit flipping the switch once in a while, and I never saw any effect whatsoever from the switch in any of the 3 positions (GND, high impedance, +5V)

I have my pin 44 grounded and with a small cap to the +5V pin next to it. I would have to believe that I copied the original board when I grounded this pin. I will verify that on the original board. If so, I would imagine this is either a GND pin or an input to the Namco-163.

[lidnariq]

Weird, pin 44 is definitely floating in the original PCB.

Oh well.

[Ben Boldt]

Oh crap, so if it is an output pin then it is quite possible that I have broken it by grounding it... I am usually pretty good about making the right connections with these sorts of things but I really had some trouble with this one.

[krzysiobal]

Re-ed schematics:

BTW. Could anyone explain, what's the point of routing tracks and then drilling hole to break them?


Something similar I found on lot of famiclone joypads' PCBs.