Like many Waixing games I tried to lift CHR ROM /OE Pin and connect it to Famicom cartridge connector pin 17.
But it was already properly connected. (Game is from C&E Soft, not from Waixing).
E28F004 (PRG-ROM) (below the SRAM)
Diodes + Resistors
Battery was removed to see the board properly.
Is there a way to fix this cart to work on a original Famicom, too?
EDIT: Added picture without SRAM, so PRG ROM is visible.
EDIT2: Measured contacts from PRG and all are properly connected.
I'm assuming it is the logic? If so, why?
Problem solved: Replaced the 74'670 + SRAM and it works now!
There's additionally the 8 KiB PRG-RAM, as you graciously desoldered.
Any chance you could provide better photographs (i.e. brighter light, no shadows, higher resolution), or else just sit down with a continuity meter and determine what pins connect to what? Some things are easy (e.g. we know that the register file outputs have to connect to PRG A13…A20 and CHR A11…A18; and their inputs at least mostly connect to CPU D0…D7), but knowing the rest of the connectivity would make diagnosing/debugging easier.
The biggest question for continuity are the pins on the GAL.
What I noticed is:
PRG /OE is connected to GAL16V8D Pin 1 and Cartridge connector #44.
PRG /CE is grounded.
The diodes and resistors are used for the SRAM+Battery (save circuit).
For example, Disch's notes for mapper 246 say that the PRG bank at $E000 is set to $FF on boot, which might be implemented using some logic in the GAL in combination with the 74'670's /OE pins, rather than actually writing a value to the '670 during boot.
The bright side is that, if we can figure out the full connectivity of the GAL, we should be able to generate a new fusemap for it that would let it work on a famicom as well. This is what I can tell from the photos, as far as the GAL is concerned:
Code: Select all
+--v--+ -> |01 20| -- Vcc -> |02 19| -> |03 18| CPU A12 and PRG RAM A12 -> |04 17| -> |05 16| CPU A10 -> |06 15| <- CPU M2 CPU A9 and ??? -> |07 14| <- PRG RAM A4 and PRG ROM A5 and CPU A4 -> |08 13| <- PRG RAM A5 and PRG ROM A8 and CPU A5 -> |09 12| -> 74'670 /RE = /OE Gnd -- |10 11| <- +-----+
Code: Select all
+--v--+ PRG /OE -> |01 20| -- Vcc Upper '670 Pin 4 (PRG) -> |02 19| -- PRG RAM /CE Lower '670 Pin 5 (PRG) -> |03 18| -- '670 Pin 12 (PRG) CPU A12 and PRG RAM A12 -> |04 17| -- '670 Pin 12 (CHR) CPU A11 and PRG RAM A11 -> |05 16| <- CPU M2 CPU A10 and PRG RAM A10 -> |06 15| -- SRAM /RW PRG RAM A9 -> |07 14| <- PRG RAM A4 and PRG ROM A5 and CPU A4 PRG RAM A8 -> |08 13| <- PRG RAM A5 and PRG ROM A8 and CPU A5 PRG RAM A7 -> |09 12| -> 74'670 /RE = /OE Gnd -- |10 11| <- PRG RAM A6 +-----+
Code: Select all
+--v--+ /ROMSEL -> |01 20| -- Vcc CPU A14 -> |02 19| -> PRG RAM /CE CPU A13 -> |03 18| -> 74'670 /WE (PRG) CPU A12 -> |04 17| -> 74'670 /WE (CHR) CPU A11 -> |05 16| <- CPU M2 CPU A10 -> |06 15| <- R/W CPU A9 -> |07 14| <- CPU A4 (PRG ROM A5) CPU A8 -> |08 13| <- CPU A5 (PRG ROM A8) CPU A7 -> |09 12| -> 74'670 /RE (PRG) Gnd -- |10 11| <- CPU A6 +-----+
First the random irrelevant musing:
Disch's notes suggest that only the 6 KiB of RAM from $6800-$7FFF are used, but if the registers are only decoded over $6000-$600F (as is possible if it's connected to CPU A4…A14, /ROMSEL, and M2), the RAM could be present over the entire 8KiB range, and only waste 4 bytes of it.
The /RE output has to be what's used here for initial power up. Somehow, the hardware has to assume that when /RE is high, the outputs of the '670s are HiZ (and then float high).
Mind, I'm not certain why they would float high; the 74LS series part should float to somewhere around 2V or so, which shouldn't be high enough for CMOS .... wait a moment. Do the famiclones run at 3V instead of 5V? If that's what's wrong, you could try adding large pullups to the PRG 74'670's outputs (around 10kΩ)
It should only be high for a few moments, and may or may not be high after a reset.
-Put in game into the Famicom
-Turned on the console
-LED was bright, then off for a milisecond and then always on but slightly dimmed.
Resetting the console did nothing to the LED.
Also, what did you mean with headphones? How can I test that method?
That's a little confusing.
Really, oscillating at all is confusing. With the GAL, I don't see how it could have enough leftover state to detect when the CPU has reset. It does sound like it's executing bad code, as you expected.
Anyway, the headphone thing: connect probe-10k resistor-headphones-ground. The 10k resistor will limit current to quiet enough that it won't be painful to hear, but enough current will still flow that you'll hear a click when the voltage changes.
Anode to '670 /RE
Cathode to GND
Yep, 5V = on, 0V = off and anything inbetween oscillating, since after some restarts (not reset) the LED wouldn't lit bright enough anymore but was darker.
Is there away to read the GALs code or fix this? If not I will just sell this game eventhough I'd love to keep it and play it on a real Famicom.
You should be able to use some of the tools mentioned here http://www.retro.co.za/ccc/mac/ReverseE ... /PALs.html
If you were using an ordinary LED without a current limiting resistor, you may have damaged it by running too much current though it.
Alternatively, Nocash is in Germany and maybe (maybe) might be interested in taking a look.