Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)(Solved)

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-19 (#166438)

It seems very likely that there's some assumption made in the GAL's programming that allows the game to boot correctly on a famiclone that isn't true on the famicom.

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:

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

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-19 (#166451)

This is what find out so far:

Code:

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

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-19 (#166485)

Ok, so to finish:

Code:

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

There's a bunch of interesting questions here, although I'm not entirely certain whether any of them will help make it work.

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Ω)

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-20 (#166507)

The famiclone I had earlier was a Video Game GT-3300 and if I'm not totally wrong it runs with 5V.

So I guess pull ups wouldn't work here?

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-20 (#166515)

It's less likely that it would help, but nothing else immediately occurs to me.

What tools (logic tester, logic analyzer, oscilloscope, &c) do you have access to?

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-20 (#166518)

Only a digital multimeter, that's all.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-20 (#166519)

Hm. Can you use a pair of headphones or an LED or something to see if GAL→74LS670 /RE behaves the same on both the famicom and famiclone?

It should only be high for a few moments, and may or may not be high after a reset.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-20 (#166521)

For that I'd need to get a famiclone again. I sold mine some weeks ago since I got all other games working on the famicom now.

I can check with a LED later.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-20 (#166527)

So, I connected a LED and this is what happened:
-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?

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-20 (#166530)

Er, what orientation was the LED? It tentatively sounds like you connected the anode to /RE, and the cathode to ground? So lit = +5V, off = 0V, and somewhere inbetween = oscillating?

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.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-20 (#166533)

Exactly, that's what I did.

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.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-20 (#166535)

Absolutely. Some of the outputs will be simply combinatorial.
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.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-21 (#166574)

Might try that.

Also, I forgot to add. It ONLY works on NOAC clones.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-21 (#166578)

lidnariq wrote:

Code:

            +--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| -> SRAM 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
            +-----+

Some ideas...

M2 - Rather unlikely: Some carts seem to detect reset by measuring inactivity on M2 (aka PHI2), but I don't see how the hardware on the PCB could do that... it would require something to detect if M2 is inactive for a "longer period", ie. some kind of timer or capacitor.
Anyways, let's say it could somehow do that: Then the next problem would be that the 74670's don't have any reset-input, but resetting that work nethertheless: The GAL could issue a /WE=LOW signal to 74670's (and hope/assume that console does output D0-D7 all HIGH during reset; which might differ on real Famicom vs Famiclone).
But that idea wouldn't explain why the GAL outputs the /RE signal (apart from probably being unable to sense M2 inactivity).

/RE - More likely: /RE might get HIGH any time when reading from an address higher than FFC0h (the Reset code and reset vector are all located at FFD0h..FFFFh). So /RE wouldn't restricted to boot-up time, but would also keep affecting the memory mapping after booting (eg. if the game would fetch the IRQ vector from FFFEh; it doesn't use IRQs, and thus doesn't ever so though).
If you have some cartridge-dumping hardware (and can modify the dumping software): You could check if it's forcing FFC0h..FFFFh to be mapped to a fixed bank: There are four 8K ROM windows, the first three windows (at 8000h-DFFFh should allow to read the "plain" ROM content, but trying to read from the fourth window at E000h-FFFFh should always map the same data in last 40h bytes of each 8K bank).

For the 74640's open-bus outputs when /RE=HIGH. I've never seen an open-bus or HighZ signal being 2V, from my experiences open bus stuff is either a clean HIGH or a clean LOW level most of the time. The main problem might be raising edges being quite slow (not immediately reaching HIGH levels on LOW-to-open-bus transitions).
So the cartridge might require the console to output address FFC0h..FFFFh before and during booting. If a real Famicom outputs 0000h during Reset, then it might fail. And if the CPU should happen to output 'wrong' address values during executing the bootcode at FFD0h and up, then it might fail, too. I've never cared too much what the NES is doing in such cases - could it change the address levels on internal-opcode cycles? Or change the address levels for a few nanoseconds on gaps between opcode cycles?

Anyways, I would suggest to add pull-ups to 74670's outputs, too. Or did you already do that? Something like 10Kohm should be fine, or try 3.3Kohm if you want to be more aggressive and make sure that you get fast rising edges.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-21 (#166579)

Thanks for all the help. I will test pull-up resistors later.

As for dumping software. I have a Kazzo Dumper but no script for mapper 246 yet.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-21 (#166580)

The PRG ROM is 512Kbyte with 64 banks of 8Kbyte, so six resistors should do it (or just to be sure not to use the wrong pins: simply use 8 resistors, wired to all PRG bank outputs).

Dumper with scripts sounds as if it could be used to test if it's doing that special mapping for address FFC0h-FFFFh. Is there anybody familar with that script stuff?

One script (for dumping through the upper 8K window) should do this:
For i=0 to 3Fh: [6003h]=i, dump [E000h..FFFFh], next i
and another script (for dumping through another 8K window) should do this:
For i=0 to 3Fh: [6000h]=i, dump [8000h..9FFFh], next i
then use some filecompare utility to see if the output is same/different.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-21 (#166581)

Here's an example script of NROM (Mapper 0):

Code:

board <- { 
mappernum = 0,
cpu_romsize = 0x8000, cpu_banksize = 0x4000, 
ppu_romsize = 0x2000, ppu_banksize = 0x2000, 
ppu_ramfind = false, vram_mirrorfind = true 
}; 
function cpu_dump (d, pagesize, banksize) 
{ 
cpu_read (d, 0x8000, 0x4000); 
cpu_read (d, 0xc000, 0x4000); 
} 
function ppu_dump (d, pagesize, banksize) 
{ 
ppu_read (d, 0, banksize); 
}

Or more complex MMC3 (Mapper 4):

Code:

board <- {
   mappernum = 4, vram_mirrorfind = false, ppu_ramfind = true,
   cpu_rom = {
      size_base = 2 * mega, size_max = 4 * mega,
      banksize = 0x2000,
   }, 
   cpu_ram = {
      size_base = 0x2000, size_max = 0x2000,
      banksize = 0x2000,
   },
   ppu_rom = {
      size_base = 2 * mega, size_max = 2 * mega,
      banksize = 0x0400
   }
};

function cpu_dump(d, pagesize, banksize)
{
   cpu_write(d, 0xa001, 0); //disable W-RAM
   for(local i = 0; i < pagesize - 2; i += 2){
      cpu_write(d, 0x8000, 6);
      cpu_write(d, 0x8001, i);
      cpu_write(d, 0x8000, 7);
      cpu_write(d, 0x8001, i | 1);
      cpu_read(d, 0x8000, banksize * 2);
   }
   cpu_read(d, 0xc000, banksize * 2);
}
function ppu_dump(d, pagesize, banksize)
{
   for(local i = 0; i < pagesize; i+=4){
      cpu_write(d, 0x8000, 2);
      cpu_write(d, 0x8001, i);
      cpu_write(d, 0x8000, 3);
      cpu_write(d, 0x8001, i | 1);
      cpu_write(d, 0x8000, 4);
      cpu_write(d, 0x8001, i | 2);
      cpu_write(d, 0x8000, 5);
      cpu_write(d, 0x8001, i | 3);
      ppu_read(d, 0x1000, banksize * 4);
   }
}

/*
http://nesdevwiki.org/wiki/MMC3
 PRG RAM protect ($A001-$BFFF, odd)
7  bit  0
---- ----
RWxx xxxx
||
|+-------- Write protection (0: allow writes; 1: deny writes)
+--------- Chip enable (0: disable chip; 1: enable chip)
*/
function cpu_ram_access(d, pagesize, banksize)
{
   cpu_write(d, 0xa001, 0x80);
   cpu_ramrw(d, 0x6000, banksize);
   cpu_write(d, 0xa001, 0x40);
}

/*
CPU memory bank for T*ROM
cpu address|rom address    |page|task
$8000-$9fff|0x02000-0x03fff|1   |write 0x2aaa
$a000-$bfff|n * 0x2000     |n   |write area
$c000-$ffff|0x7c000-0x7ffff|fix |write 0x5555, boot area

PPU memory bank for TLROM TKROM TKSROM
ppu address|rom address    |page|task
$0000-$07ff|0x02800-0x02fff|0x0a|write 0x2aaa
$0800-$0fff|0x05000-0x057ff|0x14|write 0x5555
$1000-$1fff|n * 0x1000     |n   |write area
*/
function program_initalize(d, cpu_banksize, ppu_banksize)
{
   cpu_write(d, 0xa001, 0); //disable W-RAM

   cpu_command(d, 0x0000, 0xa000, cpu_banksize);
   cpu_command(d, 0x2aaa, 0x8000, cpu_banksize);
   cpu_command(d, 0x5555, 0xc000, 0x4000);
   cpu_write(d, 0x8000, 7);
   cpu_write(d, 0x8001, 0);
   cpu_write(d, 0x8000, 6);
   cpu_write(d, 0x8001, 1);

   ppu_command(d, 0x0000, 0x1000, ppu_banksize);
   ppu_command(d, 0x2aaa, 0x0000, 0x0800);
   ppu_command(d, 0x5555, 0x0800, 0x0800);
   cpu_write(d, 0x8000, 2);
   cpu_write(d, 0x8001, 0);
   cpu_write(d, 0x8000, 0);
   cpu_write(d, 0x8001, 0x0a);
   cpu_write(d, 0x8000, 1);
   cpu_write(d, 0x8001, 0x14);
}

function cpu_transfer(d, start, end, cpu_banksize)
{
   for(local i = start; i < end - 2; i += 1){
      cpu_write(d, 0x8000, 7);
      cpu_write(d, 0x8001, i);
      cpu_program(d, 0xa000, cpu_banksize);
   }
   cpu_program(d, 0xc000, cpu_banksize * 2)
}

function ppu_transfer(d, start, end, ppu_banksize)
{
   for(local i = start; i < end; i += 4){
      cpu_write(d, 0x8000, 2);
      cpu_write(d, 0x8001, i);
      cpu_write(d, 0x8000, 3);
      cpu_write(d, 0x8001, i | 1);
      cpu_write(d, 0x8000, 4);
      cpu_write(d, 0x8001, i | 2);
      cpu_write(d, 0x8000, 5);
      cpu_write(d, 0x8001, i | 3);
      ppu_program(d, 0x1000, ppu_banksize * 4);
   }
}

And last not least a 63in1 script:

Code:

board <- {
    mappernum = 130, //Need to convert to UNIF format with BMC-Ghostbusters63in1
    cpu_romsize = 0x180000, cpu_banksize = 0x8000,
    ppu_romsize = 0, ppu_banksize = 0x2000,
    ppu_ramfind = false, vram_mirrorfind = false
};

function cpu_dump(d, pagesize, banksize)
{
    // ROM Chip. Only 0, 2 and 3 are used
    for(local chip = 0; chip < 4; chip += 1){
        if (chip != 1) {
            // High bit for ROM chip select
            cpu_write(d, 0x8001, chip >> 1);

            // Bank. 512/32 = 16 banks per chip
            for(local i = 0; i < 16; i += 1){
                // Low bit for ROM chip select + bank select.
                cpu_write(d, 0x8000, ((chip & 1) << 7) + (i << 1));
                cpu_read(d, 0x8000, banksize/2);  //Read 32KB bank from $8000-FFFF
                cpu_read(d, 0xC000, banksize/2);  //Read 32KB bank from $8000-FFFF
            }
        }
    }
}

Maybe someone get the idea and could make a script for mapper 246 so I can dump the cartridge and provide the differences?

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-21 (#166582)

The only complexity for dumping the game comes from figuring out what conditions makes the GAL drive /RE low (assuming that it powers on as high).

Given that GAL pin 1 (the GAL's latch enable) is connected to /ROMSEL, it has to involve reading from or writing to some address in ROM.

After that, you should just be able to use something similar to MMC3's dumper script, with its 8 KiB banks.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-21 (#166585)

Just one more thing to make sure. For pull-up resistors: Do I just connect 10k Ohm resistors between Q1-Q4 to VCC or lift the pins and connect the 10k between Q1-Q4 and the holes they're connected to?

I haven't used any pull-up/pull-down resistors yet.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-21 (#166586)

Do not lift pins. This is just an extra thing, one resistor for each address line, connected to the address line on one side and +5V on the other.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-21 (#166596)

That's what I did.

Added a 10k resistor to each output of both PRG '670 and connected the other side to 5V.

Game didn't boot.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-22 (#166646)

I'm out of ideas, I'm sorry.

Somehow, the GAL has to be driving 74'670 /RE high or low according to specific reads or writes from some portion of the FC's memory, and short of desoldering the GAL and dumping its function, I have no idea what it's relying on that's making it work on a NOAC but not on a famicom.

If you want to send it to me in the US, I could take a look and see if I could figure out what's going on.
(There are other people who may be more accessible)

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-22 (#166651)

Okay, so I desoldered the GAL carefully and read it with my TL866.
This is what it gave me:

Code:

Device    :    GAL16V8D

Created By:    http://www.autoelectric.cn

Date      :    2016-03-22 16:41

*QP20

*QF2194

*G0

*F0

*L00000 11111111111111111111111111111111

*L00032 01010111101101011111111111111111

*L00256 11111111111111111111111111111111

*L00288 01010111101110011010101010101010

*L00512 11111111111111111111111111111111

*L00544 01010111101110011010100110101010

*L01792 11111111111111111111111111111111

*L01824 01100111011101010111010101010101

*L02048 00011111000000000000000000000000

*L02112 00000000111111111111111111111111

*L02144 11111111111111111111111111111111

*L02176 111111111111111111

*C2505

Also added the .JED for attachment.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-22 (#166654)

I found http://www.brouhaha.com/~eric/retrocomp ... mi/palasm/ which mentions jed2eqn, which in turn generates:

Code:

;$GALMODE MEDIUM

chip FONGSH~2 GAL16V8

i1=1 i2=2 i3=3 i4=4 i5=5 i6=6 i7=7 i8=8 i9=9 GND=10 /i11=11 o12=12 
f13=13 f14=14 f15=15 f16=16 o17=17 o18=18 o19=19 VCC=20 

[...]
equations

/o19 = i2 * i1 * i3 * /i4 * i5 * f16
o19.oe = vcc
/o18 = i2 * i1 * i3 * /i4 * /i5 * f16 * /i6 * /f15 * /i7 * /f14 * /i8 * /f13 * /i9 * i11
o18.oe = vcc
/o17 = i2 * i1 * i3 * /i4 * /i5 * f16 * /i6 * /f15 * /i7 * f14 * /i8 * /f13 * /i9 * i11
o17.oe = vcc
f16 = gnd
f16.oe = gnd
f15 = gnd
f15.oe = gnd
f14 = gnd
f14.oe = gnd
f13 = gnd
f13.oe = gnd
o12 = i2 * /i1 * i3 * i4 * i5 * f16 * i6 * i7 * f14 * i8 * f13 * i9 * /i11
o12.oe = vcc

which ... I'll have to sit down and convert these into the names we previously came up with.

Have to admit I'm pretty confused by /o19 = PRG RAM /CE = (/ROMSEL * CPU A14 * CPU A13 * CPU A11 * CPU/A12 * CPU M2). Maybe the disassembler is doing something wrong?

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by tepples on 2016-03-22 (#166657)

Normally (that is, in Family BASIC and a family of ASICs), WRAM /CE is NAND(/ROMSEL, M2, A14, A13). Something that looks like NAND(/ROMSEL, M2, A14, A13, /A12, A11) may fully decode a 2Kx8 SRAM at $6800-$6FFF.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-22 (#166672)

Are there any timing diagrams showing the NES bus signals (PHI2, R/W, ROMSEL, Address, Data)?
And diagrams for the NOAC clones, in case they have different timings?

Some diagrams that I've found are:
viewtopic.php?f=3&t=10029&start=15#p111615 - NES Addr, Phi2, PPU /CE
http://www.geocities.co.jp/SiliconValle ... glish.html - General 6502 stuff...
http://www.geocities.co.jp/SiliconValle ... Timing.png - General 6502 Write Timing
http://www.geocities.co.jp/SiliconValle ... Timing.png - General 6502 Read Timing

GAL logic dump is great! I just can't figure out how it's supposed to work...

The "o12 = i2 * /i1 * i3 * i4 * i5 * f16 * i6 * i7 * f14 * i8 * f13 * i9 * /i11" seems to translate to

Code:

  /ROMSEL=LOW           ;rather nonsense
  AND
  A14 ... A7 = HIGH     ;okay
  AND
  PHI2 = HIGH           ;uhm, why???
  AND
  A6 = LOW              ;uh, what LOW ???
  AND
  A5 ... A4 = HIGH      ;uh, what ???

So /RE would be HIGH for address FFB0h..FFBFh, which would be totally wrong.
It should HIGH for the Reset vector at FFFCh-FFFDh and for the bootcode at FFD0h..FFF9h (or just for the whole FFC0h..FFFFh area).
Could there still be some mistake in the GAL dump, or in the chip/pcb pinout? Especially A4,A5,A6 are looking totally wrong to me.

Decoding /ROMSEL and PHI2 doesn't make any sense for the /RE signal. At worst it could increase "open-bus issues" with the unstable raising edges on the HighZ outputs.

On the other hand, the thing that is really needed (and probably intended by the manufacturer) is checking that A14..A7 are all HIGH. You could cut the /RE signal, and produce your own /RE using some external AND gate. Or easier: Using 8 diodes and a pull-up resistor:

Code:

A7  ---|<|---.
             |
A8  ---|<|---+
             |
A9  ---|<|---+
             |       VCC
A10 ---|<|---+        |
             |        |
A11 ---|<|---+       .'.
             |       | |
A12 ---|<|---+       | |
             |       '.'
A13 ---|<|---+        |
             |        |
A14 ---|<|---+--------+-------- /RE

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-22 (#166674)

Quote:

PRG RAM /CE = /o19
= i1 * i2 * i3 * /i4 * i5 * f16
= /ROMSEL * A14 * A13 * /A12 * A11 * M2
-> 2 KiB from $6800 to $6FFF
PRGBANK/WE = /o18
= i1 * i2 * i3 * /i4 * /i5 * /i6 * /i7 * /i8 * /i9 * /i11 * /f13 * /f14 * /f15 * f16
= /ROMSEL * A14 * A13 * /A12 * /A11 * /A10 * /A9 * /A8 * /A7 * /A6 * /A5 * /A2 * R/W
-> writes only to $6000-$6003 (and $6008-$600B, $6010-$6013, $6018-$601B)
CHRBANK/WE = /o17
= i1 * i2 * i3 * /i4 * /i5 * /i6 * /i7 * /i8 * /i9 * /i11 * /f13 * f14 * /f15 * f16
= /ROMSEL * A14 * A13 * /A12 * /A11 * /A10 * /A9 * /A8 * /A7 * /A6 * /A5 * A2 * R/W
-> writes only to $6004-$6007 (and $600C-$600F, $6014-$6017, $601C-$601F)
PRGBANK/RE = o12
= /i1 * i2 * i3 * i4 * i5 * i6 * i7 * i8 * i9 * //i11 * f13 * f14 * f16
= //ROMSEL * A14 * A13 * A12 * A11 * A10 * A9 * A8 * A7 * //A6 * A5 * A2 * M2
-> bank is HiZ while accessing $FFE4-$FFE7 (and $FFEC-$FFEF, $FFF4-$FFF7, $FFFC-$FFFF)

~~In summary, wut. This doesn't make sense, and this still mostly disagrees with Disch's previous notes about mapper 246.~~

edit: nocash's observing the weirdness with the /i11 input
edit2: connected to CPU A2, not CPU A4

ON THE OTHER HAND, since you've desoldered the GAL and have access to the TL866 programmer, we can change the program for o12=PRGBANK/RE to be what we think it "should" be and see if that works any better. You should be able to play around with Opal Jr in dosbox until its functionality is what we think it should be instead (namely, /i11 becomes +i11, and remove f13 and f14). Socketing it would obviously be a good idea

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-22 (#166676)

Yes, that logic all doesn't make sense at all. For PRG RAM /CE, decoding A12,A11 might make sense, but not that way. Looks as if some of the "*" are meant to mean OR instead AND, or as if there've some other stuff missing in the disassembled formulas. Hmmm, or could that issue happen due to "a row of bits" being missing in the logic dump?

I've searched for "JED Disassembler" too. Here's another one, with source code and sample file: http://www.gen.eclipse.co.uk/GalDis/GalDis.html
The webpage says it supports "GAL22V10 and PAL16R4 devices. It could easily be modified to cover others"
Unfortunately, the "freeze.cfg" sample config file is for a 24pin "22v10" chip. So one would at least need to figure out how to configure 20pin chips.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-22 (#166678)

lidnariq wrote:

ON THE OTHER HAND, since you've desoldered the GAL and have access to the TL866 programmer, we can change the program for o12=PRGBANK/RE to be what we think it "should" be and see if that works any better. You should be able to play around with Opal Jr in dosbox until its functionality is what we think it should be instead (namely, /i11 becomes +i11, and remove f13 and f14). Socketing it would obviously be a good idea :)

Wait! First be sure that the old chip has been dumped successfully before reprogramming it!

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-22 (#166687)

As long as there is no lock on the code I can assure it was dumped correctly.
My TL866 never caused any problems from reading/writing from/to ICs.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-22 (#166700)

The only random idea that occurs to me right now is seeing if the dump on this cart is the same as that in GoodNES...
(That has PRG sha1sum 991968732e6f4f2289f8e751539b02b8a9d4853f, md5sum 355ef6cffa2f07c9b15a66fa2fa0f846, crc32 ea76fb00)

Oh, btw, the dump in GoodNES has the same 48 byte bootstrap stub at the end of every 32 KiB.

Also, it can't just be that the final 64 bytes of memory are always mapped to the final 64 bytes of ROM; I definitely see other things that look like vectors at other 8 KiB offsets.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-23 (#166710)

lidnariq wrote:

Also, it can't just be that the final 64 bytes of memory are always mapped to the final 64 bytes of ROM; I definitely see other things that look like vectors at other 8 KiB offsets.

Do you have some example, where is that seen, and what kind of vectors?
Leaving apart everything that we couldn't explain - I think the theory about the last some bytes (at least the last 30h bytes, maybe 40h or 80h bytes if they've rounded-up the required space) having fixed mapping is absolutely right. Even if there's useful inaccessible data at, say, Bank5:FFE0h, mind that the game could still access that useful data at Bank5:DFE0h, 5:BFE0h, or 5:9FE0h.

For the unexplainable stuff: How are chances that the GAL or whole cartridge somehow got damaged since when it was last working?
Did you recently test it on (somebody else's) NOAC-clone console to see if it still works?
Or other way around: When you still had a NOAC-clone, did you also test in on real Famicom back then?
Would be nice if you (or somebody else with the same cartridge) could post some confirmation that the game works on NOAC only (eg. somebody having swapped it several times between NOAC and Famicom, and having observed that it always worked perfectly on NOAC, and always failed on Famicom).

Btw. from what I know about Mapper 246, and also from specs at http://wiki.nesdev.com/w/index.php/INES_Mapper_246 the cartridge should distinguish between writes to 6000h..6003h (PRG bank) and 6004h...6007h (CHR bank), ie. it must decode CPU A2 somewhere, but the rev-enginieered GAL pinout doesn't show any connection to CPU A2, can you check that again?
The 74670's don't have any extra /WREN and WREN enable inputs that could be wired to CPU A2, so that part really must be handled by the GAL, after all the GAL does have two separate /WE outputs, which should differ only in respect to CPU A2.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-23 (#166711)

Chances are very low that it was destroyed.

When I first tried it on a NOAC famicom it booted up fine and worked.
Tested it in my RGB modde Famicom and it didn't work.
I assumed the cartridge connector pins were bent too much since I have problems with some other games (but I guess it's mostly an issue with dirt on the contacts, too).
So I fixed the cartridge connector pins, game didn't boot.

Used my FC to NES Adapter from Krikzz to test it in a RGB modded PAL NES and a RGB modded NTSC (using Dendy PPU/CPU) NES. Neither worked.

Tried again in a NOAC Famiclone. Worked fine.

I'm 100% sure the game is working properly.

Eventhough I can't dump the PRG yet (only get FF) but CHR seems to give me some data. I have yet to compare that with goodNES ROM.

As for confirmation: I got the game from prince tomato over at Famicomworld and he told me it only works on a NOAC Clone.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-23 (#166713)

lidnariq wrote:

i1=1 i2=2 i3=3 i4=4 i5=5 i6=6 i7=7 i8=8 i9=9 GND=10 /i11=11 o12=12
[...]
o12 = i2 * /i1 * i3 * i4 * i5 * f16 * i6 * i7 * f14 * i8 * f13 * i9 * /i11

Just spotted the "/i11=11" in the pin-assignment, so if "i11" is "NOT pin11" (aka "NOT A6"), then the "/i11" in the formula would mean "A6" (aka "NOT NOT A6").
Then /RE would be HIGH when A6=HIGH, ie. at FFF0h-FFFFh. That would at least make sense for the Reset vector (though not for the bootcode at FFD0h and up).

Ice Man wrote:

Eventhough I can't dump the PRG yet (only get FF) but CHR seems to give me some data. I have yet to compare that with goodNES ROM.

The PRG ROM area containing only FFh-bytes? Odd. The way how PRG ROM /OE and /CE are wired, you should always get data from the ROM, even if the bank number is wrong. There's at least one FFh-filled 8K-bank though, and in case of bad luck the hardware might be mapping that empty bank for some reason.

Currently I am thinking that you must have a different ROM version, one that has tiny bootstrap at FFF0h (instead FFD0h), and one that uses Port 6010h..6013h or so (instead of 6004h..6007h which would require CPU A2).
Would be nice if you could verify the GAL pin-out though (checked against the cart-edge pins, not the RAM/ROM pins (since you have reported stuff like "ROM A8 = CPU A5", so there might further cases where RAM Ax isn't same as CPU Ax)).

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-23 (#166715)

I will check every pin from the 74'670 and GAL and write a complete pinout to everything when I have some spare time later on. Hope that will help, since I desoldered everything for now.

If one wants a picture of the naked board I can take one from top and bottom side.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-23 (#166716)

Ice Man wrote:

If one wants a picture of the naked board I can take one from top and bottom side.

Yes, sure! Following traces on photos without multimeter can be painful, but yes, take photos before you solder the chips back in!

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-23 (#166721)

nocash wrote:

lidnariq wrote:

i1=1 i2=2 i3=3 i4=4 i5=5 i6=6 i7=7 i8=8 i9=9 GND=10 /i11=11 o12=12
[...]
o12 = i2 * /i1 * i3 * i4 * i5 * f16 * i6 * i7 * f14 * i8 * f13 * i9 * /i11

Just spotted the "/i11=11" in the pin-assignment, so if "i11" is "NOT pin11" (aka "NOT A6"), then the "/i11" in the formula would mean "A6" (aka "NOT NOT A6").

I'm not altogether what that means. The internal fabric of the 16V8 doesn't support the idea of inversion per input; instead every pin that's available in the AND array is always available as both normal and inverted.

Although when the 16V8 is operating in "registered" mode, pin 11 always goes via an inverter (and can only be used as an /OE for some subset of outputs), but the datasheet implies that inverter is bypassed when in "simple" mode. And given that the AND array supports both normal and inverted output, it's possible that they're just arguing that the synthesis tool should conceal that.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-23 (#166723)

Okay, desoldered everything except PRG and CHR as I have no hot air station and don't want to destroy anything. Complete pinouts will follow later.

Is 74'670 PRG <-> GAL <-> CPU enough or would you like 74'670 CHR too?

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-23 (#166728)

The "registered" mode feature sounds confusing, and even if the cartridge doesn't use that mode (hopefully), the disassembler seems to reproduce that confusion for some reason. But when trusting the disassembler output, it's clearly saying that the A6 is double-inverted ("clearly" in a confusing way though).
Here's some confirmation: http://forum.6502.org/viewtopic.php?p=12147#p12147 the source code on that page specifies "i11" in the formula, but the disassembler output (also shown on that page) comes up with "/i11" and "/i11=11".

Double inverted A6 would also make some more sense on the mapper ports (600xh and 601xh looks better than 604xh and 605xh). Only 601xh would require some slightly different ROM version, but if the ROM contains matching code then everything would be fine.
Well, except for SRAM allowing to access only 2K of the 8K chip; but the GAL might be actually programmed that way, intentionally or unintentionally (when looking at a .SAV file, the game seems to be really using only the 2K window at 6800h-6FFFh; but it might (try) to use more memory later in the game).

EDIT: http://www.progettoemma.net/mess/gioco. ... n&list=nes (and the "Clone" links on that page) show 3 different "baddump" PRG ROM checksums, so there might be different versions (or dumping is difficult or unreliable). The CHR ROM checksums are same for all versions.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-24 (#166765)

Okay, so I finally (and hopefully correctly) traced down every single connection. (Post below).

Also hopefully better HiRes pictures of the board (with just PRG and CHR on).
Front
Back

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-24 (#166779)

Nice photos & nice pinouts, thanks! (raw ascii txt version of the pinout would be nice too)

So I guess you could solder the chips back in now? I would stick with the original unmodified GAL for the memory dumping step, even if you may later need to desolder it again and reprogram it for fixing the famicom compatiblity issue. Or use a socket if there's enough space to fit carts with socketed GAL into the console and copier.

Did you already edit the dumper script? The "63in1" script looks easiest to modify. Just remove the "chip" loop, and change some values... like so:

Code:

board <- {
    mappernum = 246,
    cpu_romsize = 0x80000, cpu_banksize = 0x2000,
    ppu_romsize = 0, ppu_banksize = 0x2000,
    ppu_ramfind = false, vram_mirrorfind = false
};

function cpu_dump(d, pagesize, banksize)
{
            for(local i = 0; i < 64; i += 1){
                cpu_write(d, 0x6000, i);
                cpu_read(d, 0x8000, banksize);
            }
}

That would dump only the PRG ROM via the memory window at 8000h-9FFFh. If that works, then one could also test the window at E000h-9FFFh (which should supposedly produce some "bad" dump with reset vector mirrored at end of each bank). And of course add CHR ROM dumpin, too. And maybe SRAM dumping for seeing if there's really only 2Kbyte mapped...
But for now it might be best to try the above small script, to see if the edited script is working at all.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-24 (#166785)

RAW ASCII:

Code:

         U7 - 74'670 Upper PRG Side                  U6 - 74'670 Lower PRG Side
                  __  __                                   __  __
          PRG D5 |01\/16| +5V                      PRG D1 |01\/16| +5V
          PRG D6 |02  15| PRG D4                   PRG D2 |02  15| PRG D0
          PRG D7 |03  14| PRG A0                   PRG D3 |03  14| PRG A0
         CPU A14 |04  13| PRG A1                  CPU A14 |04  13| PRG A1
         CPU A13 |05  12| GAL16 Pin 18            CPU A13 |05  12| GAL16 Pin 18
              NC |06  11| GAL16 Pin 12            PRG A16 |06  11| GND
              NC |07  10| PRG A17 + 2nd 4.7k R.   PRG A15 |07  10| PRG A13
             GND |08  09| PRG A18                     GND |08  09| PRG A14
                  ------                                   ------
               
                           U4 - GAL16V8D
                            __  __
                   /ROMSEL |01\/20| +5V
                   CPU A14 |02  19| PRG RAM /CE
                   CPU A13 |03  18| 74'670 Pin 12 (PRG)
                   CPU A12 |04  17| 74'670 Pin 12 (CHR)
                   CPU A11 |05  16| CPU M2
                   CPU A10 |06  15| CPU R/W + SRAM /WE
                    CPU A9 |07  14| CPU A2 
                    CPU A8 |08  13| CPU A5 
                    CPU A7 |09  12| 74'670 Pin 11 (Upper PRG)
                       GND |10  11| CPU A6
                            ------               
            
         U8 - 74'670 Upper CHR Side                 U5 - 74'670 Lower CHR Side
                  __  __                                   __  __
          PRG D5 |01\/16| +5V                      PRG D1 |01\/16| +5V
          PRG D6 |02  15| PRG D4                   PRG D2 |02  15| PRG D0
          PRG D7 |03  14| PRG A0                   PRG D3 |03  14| PRG A0
         PPU A12 |04  13| PRG A1                  PPU A12 |04  13| PRG A1
       CIRAM A10 |05  12| GAL16 Pin 17          CIRAM A10 |05  12| GAL16 Pin 17
         CHR A17 |06  11| GND                     CHR A14 |06  11| GND
         CHR A16 |07  10| CHR A14                 CHR A13 |07  10| CHR A10
             GND |08  09| CHR A15                     GND |08  09| CHR A12
                  ------                                   ------
               
PRG = PRG ROM      CHR = CHR ROM      CPU = PRG Connector      PPU = CHR Connector

I hope this helps / works.

I will desolder everything tomorrow and sadly there's no space for a socket. Desoldering the GAL isn't a problem though!

Will also try the script then. Thanks.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-25 (#166815)

Yay, I was able to dump at least the PRG properly using this script:

Code:

board <- {
    mappernum = 246,
   cpu_rom = {
      size_base = 4 * mega, size_max = 4 * mega, banksize = 0x2000
   },
   ppu_rom = {
      size_base = 0, size_max = 0, banksize = 0x2000
   },
   ppu_ramfind = false, vram_mirrorfind = false
};

function cpu_dump(d, pagesize, banksize)
{
   for(local i = 0; i < pagesize - 1; i += 1){
      cpu_write(d, 0x6000, i);
      cpu_read(d, 0x8000, banksize);
   }
   cpu_read(d, 0xc000, banksize);
}

Opened the game in FCEUX and it works flawless, just CHR is missing.
If anyone could provide a script for CHR dumping then I can provide a full dump of this game.

Also, I saw 2 differences between my game and the ROM I have (but that doesn't make any sense to me, probably just a table).

Offset: 800C
Dump: 00 FF 00 FF
ROM: D0 FF D0 FF

Other than that, everything was equal.

EDIT: Added the missing CHR manually (copied from the ROM to my dump) and the game works without problems in an emulator. Still doesn't load on a original Famicom.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-25 (#166823)

Well, the emulator definitions are conspicuously different from what your hardware does.

Honestly, given Disch's documentation (and FCEUX's implementation), I'm surprised your hardware could possibly work at all; the ROM dump (since you say your dump is identical save for 2 bytes) is definitely writing to $6004-$6007 for CHR banking, not $6010-$6013. With the hardware as it seems to be, any CHR bank writes would erroneously change the PRG bank, leading to a crash.

So ... how on earth does it work in a famiclone? I have absolutely no idea.

I do think we could revise the GAL's fusemap to make it work. (We don't need CPU A4 or A5. Just CPU A6…A15 and A2).

How easily could you get your hands on a replacement GAL? I understand Nocash's hesitancy to reprogram the only original instance we have of it, in case there's something we're forgetting.)

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-25 (#166824)

Getting replacement GAL wouldn't be a problem at all. However, in case we do try this method I will desolder the original and use wires to connect it to the board since socketing does not work (no space left).

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-25 (#166829)

So, other than the confusingness between the registers that the program writes to relative to what is decoded, the other major difference has to do with PRG banking.

Namely, 74'670 PRG low (A13…A16) /RE is tied to ground, i.e. it's always emitting. There's no funny high-impedance thing to make sure that the right bank is available when it boots; instead the 74'670 simply has to power on (at least on the famiclone) with its $E000 bank set appropriately.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-26 (#166876)

Hmmmm, that cartridge is still good for surprises and doesn't make sense.

Ice Man wrote:

Code:

function cpu_dump(d, pagesize, banksize)
{
   for(local i = 0; i < pagesize - 1; i += 1){
      cpu_write(d, 0x6000, i);
      cpu_read(d, 0x8000, banksize);
   }
   cpu_read(d, 0xc000, banksize);
}

Ah, so the "pagesize" parameter is apparently meaning "number of banks" (the total size divided by banksize).
The minus 1 in "pagesize - 1" is wrong (that will exclude the last bank).
The "cpu_read(d, 0xc000, banksize)" is also wrong (that will read random garbage; since 6002h wasn't initialzed).
Fixing that two issues, the function should look as so:

Code:

function cpu_dump(d, pagesize, banksize)
{
   for(local i = 0; i < pagesize; i += 1){
      cpu_write(d, 0x6000, i);
      cpu_read(d, 0x8000, banksize);
   }
}

Can you try that please? It should produce more reliable data in last 8Kbytes.
And then, to test the mapping behavious on the reset vector area, change 6000h/8000h to 6003h/E000h. Like this:

Code:

function cpu_dump(d, pagesize, banksize)
{
   for(local i = 0; i < pagesize; i += 1){
      cpu_write(d, 0x6003, i);
      cpu_read(d, 0xe000, banksize);
   }
}

That could/might reveal what the cartridge is mapping to the "reset area".

Ice Man wrote:

Also, I saw 2 differences between my game and the ROM I have (but that doesn't make any sense to me, probably just a table).
Offset: 800C
Dump: 00 FF 00 FF
ROM: D0 FF D0 FF

That are the reset and irq/vectors in bank 3 (file offset 800Ch is PRG ROM offset 7FFCh) (in .NES files with 10h-byte header).
I would have assumed them to point to FFF0h, seeing them pointing to FF00h doesn't seem to make any sense.
But the cartridge is probably booting via reset vector in last bank (bank 63), so the weird vectors in bank 3 would have no effect.

If there are no further differences between your dump and the ROM that you've compared it to, then I can't understand how the CHR mapping via 6004h..6007h could work with your GAL. Unless the "ROM that you've compared it to" didn't use 6004h..6007h either.
Can you try it in no$nes on windows/wine, and enter "Ctrl+G, 0dab7" and check if the disassembler shows this code:

Code:

ROM2:DAB7 A5 25        mov  a,[25]
ROM2:DAB9 8D 04 60     mov  [6004],a
ROM2:DABC A5 26        mov  a,[26]
ROM2:DABE 8D 05 60     mov  [6005],a
ROM2:DAC1 A5 27        mov  a,[27]
ROM2:DAC3 8D 06 60     mov  [6006],a
ROM2:DAC6 A5 28        mov  a,[28]
ROM2:DAC8 8D 07 60     mov  [6007],a
ROM2:DACB 60           ret

If it's containing the same code (with 6004, 6005, etc.) then you have a "normal" version of the game - which theoretically couldn't work with your GAL.

And, one detail in the pinout: Pin 15 = SRAM R/W. There's something wrong. There should be a CPU R/W signal on cart bus, and there should be /CE, CE2, /OE, and /WE signals on the SRAM chip. But something called "SRAM R/W" shouldn't exist. I suspect that Pin 15 might be wired to both CPU R/W and to SRAM /WE ?

Using wires between PCB and GAL is a good idea. Then you could also attach a socket to the wires for swapping the chip more easily.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-26 (#166878)

Ok, so I dumped both PRGs one with 6000-8000 and one with 6003-E000 set (also attached them).

Both display:

Code:

ROM2:DAB7 A5 25        mov  a,[25]
ROM2:DAB9 8D 04 60     mov  [6004],a
ROM2:DABC A5 26        mov  a,[26]
ROM2:DABE 8D 05 60     mov  [6005],a
ROM2:DAC1 A5 27        mov  a,[27]
ROM2:DAC3 8D 06 60     mov  [6006],a
ROM2:DAC6 A5 28        mov  a,[28]
ROM2:DAC8 8D 07 60     mov  [6007],a
ROM2:DACB 60           ret

So I assume that's fine but the one with 6000-8000 still has the 2 bytes difference while the others has much more byte differences.

As for Pin 15 of the GAL. It is only connected to SRAM /WE only. I don't know why I wrote SRAM R/W, my bad for that. Will correct that in the ASCII.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-26 (#166881)

The differences in the dumps are interesting... and rather unexpected, as usually. If they are caused by /RE, then it looks as if A4 wouldn't be used in the /RE formula. And if /RE=HIGH would map the last bank, then the "different bytes" should be always taken from that bank, but they do look more random than constant.

Okay, new theory: The GAL has more than 20pins? Some more pins that aren't visible on the photos? Or you have photographed the PCB from another cartridge, not the Fong Shen Bang one? Just kidding, but there's so much everything that doesn't make sense. Or the Famiclone has different cart edge pinouts than Famicom?

The PCB photo DOES show a wire on the cart edge's CPU R/W pin. Are you sure that it isn't connected to the GAL? And if so, where else is that signal connected to? Also, GAL Pin15 should be an input, if it comes from SRAM /WE, then your SRAM would output something on it's /WE pin??? That's all looking like a weird joke, as if the manufacturer would have put fake part numbers on the chips.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-26 (#166885)

So, given the connectivity Ice Man indicated, it doesn't map the last bank. It only selects some random bank from the upper 256 KiB of PRG.

Which is utterly bewildering.

Anyway, I'm tracing the photos now, on the unlikely chance that I discover anything.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-26 (#166886)

Pin 15 of the GAL is indeed connected to CPU R/W + SRAM /WE. Just measured again. Sorry about that.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-26 (#166887)

I am looking at the photos, too. Especially the resistors/diodes. Here's what I came up with:

Attachment:

Mapper246.jpg [ 27.5 KiB | Viewed 5591 times ]

The components in the schematic are arranged same way as on the PCB top-side photo.
Like the other stuff on that cartridge, the schematic is very simple, and looks as if could work (almost), but doesn't make ANY sense at closer look (exept in terms of producing confusion).

The diode at the right side should prevent the (nonrechargeable) battery from being charged via NES VCC, the resistor next to it should probably prevent the battery from being discharged too quickly (in case of shortcuts or so). But then, going by the photo, the resistor/diode seem to be just shortcut with each other, making them totally nonfunctional. And worst, the battery should probably catch fire if the cartridge were ever connected to a console for real. Ice Man, what is that? Are you making strange jokes when posting that photos? Or forgot to mention some minor explosion? Is that the real reason why you've desoldered the battery?

The diode in the middle: That powers the SRAM from NES VCC, and also prevents the battery to be discharged from other components when NES VCC is off. That's the only part yet that appears to make sense.

The left-most resistor is just a pull-up for the signal going from GAL.Pin19 to SRAM /CE, there should be no pull-up needed there since the GAL can output a HIGH level on it's own, but maybe the pull-up is having some kind of use in preventing data loss during power-up or power-down.

The second-from-left resistor. That's a pull-up for U7 Pin 10. Which is... well... something:
1) As far as I can see U7.Pin10 isn't connected anywhere else (and a pull-up on an unused pin doesn't make sense).
2) If U7 is the upper-left chip in Ice Man's pinout chart, then U7.Pin10 is SRAM /CE (which seems just crazy).
3) If the cartridge would make sense, then U7.Pin10 should probably be PRG ROM A17 (which isn't found to be connected anywhere yet).
Either way, a pull-up on any of those pins... doesn't make sense?

Ice Man, the 74670's should be numbered U5, U6, U7, U8. Can you add that in your pin-out chart? And verify U7.Pin10?

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-26 (#166888)

Changed IC labels to U4-U8

U7 Pin 10 is indeed connected to the 2nd 4.7k Ohm resistor like shown in your diagram, which is then connected to the 1st 4.7k Ohm to SRAM /CE and GAL Pin 19.

How am I supposed to make jokes of this? I wish this cart would work and I try to help where ever I can. The last diode and resistor are not shortcut with each other though. Neither was there an explosion or batter catching fire happening.

The real reason the battery was desoldered is simple: The battery holder was broken and since then no battery was added cause I can't find the proper replacement.

EDIT: nocash, I could also send you the cartridge over since you're located in Germany, too. Would make things easier maybe? Let me know if you want to have a closer look at it.

EDIT2: At a closer look, I measured PRG A17 and it is connected to U7 Pin 10 as well. Corrected in my ASCII art, too.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-26 (#166889)

Well, yes, this just looks like the typical sinster plan, where you've invested loads of time in producing pixel-edited fake-photos, and then asked people if they could make any sense of it. Even if you are now saying that there is no connection between the two lower-right pins in the schematic. I could still swear that you've originally posted a picture showing a connection in that place (lower-left of PCB back side = lower-right in schematic):

Attachment:

Snippet.jpg [ 5.52 KiB | Viewed 5582 times ]

The two left-most resistors (left side in schematic) are pull-ups, both wired to VCC, but they are not interacting with each other (since VCC should be constant +5V) (leaving apart cases like power-off).

And the missing PRG A17 connection: Don't say that you didn't intentionally omit that signal - and then enjoyed your time waiting for somebody to figure out that there's no way on earth that you could have dumped a 512Kbyte PRG ROM from a cartridge without A17 signal!

EDIT: Having a look at the cartridge myself: Yes/no. I would love to - but I don't have a Famicom (or clone), only a NES console, so I couldn't do too much with it.
EDIT: Or I could maybe case-mod my NES and add a Famicom socket to it.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-26 (#166890)

Why on earth would I pixel edit a picture? You think I'm joking about this? I have better things to do than annoy people or faking pictures about real carts...

Either way, I'm no electrician or know any programming and my knowledge is near zero in this area to be honest, otherwise I'd trace and fix myself.

What you see as "connection" between those was caused by desoldering the resistors and yes, that spot is on the actual board, too. But it's not a connection between them, never was!

I know it's not possible without a missing A17 signal to dump the PRG properly but I honestly forgot/did not bother to measure if A17 was connected to the 74'670 since I only traced it to the resistor.

Oh, okay. I don't have any convertes I could send with that cart so you can test it in the NES.

EDIT: In case you do case-mod your NES and still want the cart, just send me a PM for further details.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-26 (#166893)

Ice Man wrote:

Why on earth would I pixel edit a picture? You think I'm joking about this?

Don't take me too serious! But yes, either you are totally innocent - or you are a disguised expert electrician making obscure jokes.

Either way, your cartridge is totally scary, so please don't be concerned about theories like prince tomato being an alien, whom hypnotized you without your knowledge. Everything else just doesn't make sense.

EDIT: Ehm, how did you make my schematic look like as if I had never drawn a connection between lower-right pins? And then asking why on earth you would pixel edit a picture in the next post!!! Like as if you had never done such a thing in your whole life! And then soldering and desoldering your chips all day long as if you never had any experiences in electronics.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-26 (#166894)

Yea, I don't have any other theories for that either anymore now.

It is indeed a scary cartridge.

But if there's something I can do to help more (and what's possible for me) I'm up for it.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-26 (#166910)

After having traced everything, I noticed that
1- The PRG is wired in order, not scrambled as I had initially misparsed.

2- GAL pin 14 is connected to CPU A2, not CPU A4. So the registers are where they're documented to be.
(Correspondingly, that means that the four outputs are, with the GAL fusemap, at:
Write to $6000-$6003, $6008-$600B, $6010-$6013, $6018-$601B → PRG bank write
Write to $6004-$6007, $600C-$600F, $6014-$6017, $601C-$601F → CHR bank write
Access $6800-$6FFF → PRG RAM I/O
Access $FFE4-$FFE7, $FFEC-$FFEF, $FFF4-$FFF7, $FFFC-$FFFF → instead access bank where PRG A17 is high instead (i.e. each second 128 KiB quarter)

In fact, Ice Man's dumps exactly agree with that:

Attachment:

via8000-vs-via-e000.gif [ 29.14 KiB | Viewed 5932 times ]

)

3- The battery switchover circuit that nocash is objecting to would be almost correct if that single trace was removed. Given how the traces look like "Autorouters Gone Wild!" I wouldn't be surprised if the connectivity had been specified by naming nodes and they accidentally used the same name for "battery voltage" and "UPS-ed voltage"

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-26 (#166915)

[-- wrote this before/while lidnariq posted the above --]

Yet another oddity: U6.Pin11 is GNDed.
So that PRG A13,A14,A15,A16 would always come from whatever is in U6 (which is uninitialized on power up).

On the contrary, U7.Pin11 is the "/RE" signal from GAL.Pin12.
So that PRG A17,A18 would be somehow affected by the GAL. PRG A17 with the additional 4.7K pull-up.

The differences in the "PRG 6000-8000" vs "PRG 6003-E000" dumps are somewhat related to the above wiring. The bytes seem to be read from the selected A13,A14,A15,A16 address bits, but A17 seems to be forced high (by the pull-up?) and A18 seems to be low.
Ie. the "different" bytes at offset 1FF4h, 3FF4h, 5FF4h, etc. in "PRG 6003-E000" are same as data at 21FF4h, 23FF4h, 25FF4h, etc. in "PRG 6000-8000". Which is, well, not actually explaining how it could ever map the reset vector on power-up.

There are more and more odds than ends. The only thing that is becoming clearer and clearer is that it's absolutely impossible that the cartridge could work on a NES or Famicom.
I've no idea how it could work on NOAC clones - the whole design seems to rely on electrosmog being produced by the Joypad or TV Set.

[-- after lidnariq's post --]

A4 is actually A2 ??? I thought that I had verified that signal on the photo, too. Gotta check again. But of course, that would explain at least half of the problems.
Yes, you are right. Maybe the shadow on the photo made it look as if the wire would be shorter, and would only go far enough to connect to A4, not to A2. But yup, it's A2.

For the battery-shortcut, the earlier photos in first post viewtopic.php?f=9&t=13969#p166351 actually show no connection in that place, so the "wire" seen in later photos seems to be just some dirt/scratch, not a real wire.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-26 (#166916)

Corrected the GAL pinout again.

Pin 14 to CPU A2
Pin 13 to CPU A5 (not to PRG A8 but to PRG A5, too).

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-26 (#166924)

Trying to understand what is happening on reset...
Maybe the circuit simply assumes that the 74670's tends to boot up with all-bits-set on power up, then all PRG banks would be initially 3Fh.
And the GAL's /RE output would somehow modify the upper two bits, A17=Pulled-HIGH and A18=Floating-LOW, thus changing bank 3Fh to 1Fh on certain addresses.

Then the reset vector at FFFCh and the bootcode at FFD0h..FFF9h would be processed as so:

Code:

  FFD0h..FFE3h  14h bytes  bank 3Fh                ;\
  FFE4h..FFE7h  4 bytes    redirected to bank 1Fh  ; bootstrap at
  FFE8h..FFEBh  4 bytes    bank 3Fh                ; FFD0h..FFF9h
  FFECh..FFEFh  4 bytes    redirected to bank 1Fh  ;    EDIT: during execution, the bootstrap will set [6003h]=03h,
  FFF0h..FFF3h  4 bytes    bank 3Fh                ;    so some of the later opcodes are from bank 03h, or
  FFF4h..FFF7h  4 bytes    redirected to bank 1Fh  ;    redirected to bank 13h
  FFF8h..FFF9h  2 bytes    bank 3Fh                ;/
  FFFAh..FFFBh  2 bytes    bank 3Fh                ;-NMI vector
  FFFCh..FFFFh  4 bytes    redirected to bank 1Fh  ;-Reset and IRQ/BRK vector

That would wildly toggle between bank 3Fh and 1Fh (edit: and bank 03h and 13h) during execution of the bootcode, but it could work as all of those banks seem to contain a copy of the bootcode. I've no idea if a 74670 would really tend to contain all-ones on power-up though.

And as for WHY the circuit might work as above:
Either the developer tried to implement some hardware logic (and then decided to store copies of the bootcode in different banks when it turned out that the logic didn't work as planned). Or, there is some idea behind it (like a copy-protection that would verify the exact behaviour of the crazy memory mapper at some later stage in the game).

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-26 (#166926)

nocash wrote:

And the GAL's /RE output would somehow modify the upper two bits, A17=Pulled-HIGH and A18=Floating-LOW, thus changing bank 3Fh to 1Fh on certain addresses.

As near as I can tell, A18 seems to be unchanged (as a HiZ output "should" be with the parasitic capacitance of the traces) ... and that's what I see in Ice Man's dumps.

Another inexplicable thing ... they seem to not even be using the PRG banking's features, and are just always writing N,N|1,N|2,N|3 to $6000 through $6003. i.e. it seems that you could replace the two 74'670s with just a 74'161.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-26 (#166930)

I actually have a 74HC161 over that I could try. But how exactly would I replace it for the 2 74'670 on the PRG side?

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-26 (#166931)

Nevermind, I just tested it in FCEUX and it crashed once the game actually started. Sigh.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-26 (#166937)

Ok, so:

The game relies on being able to change the NMI vector by changing the bank. This explains the otherwise-inexplicable inclusion of A2 in the formula for PRG BANK /RE . But specifically what it's doing is: the NMI vector is only valid when the bank at $E000 is bank 3, other banks instead point the NMI at the reset handler.

SO: the fixed bank at $FFD0-$FFFF is from ROM offset 0x6000, or: PRG A13, 14 high; A15..A18 low. I have absolutely no idea how this was ever supposed to work, unless the 74'670s just happened to, as we previously guessed, tend to power up with the value "3" in memory.

Similarly, I have no idea what the pullup on PRG A17 is doing. It has to be too slow to be relevant, because when the game fetches the NMI vector it fetches the good NMI vector of $8086 instead of the bad NMI vector of $FFD0.

With that in mind, we should be able to generate a fusemap for the GAL that will achieve the desired behavior without changing the PRG.
* If CPU accesses $FFFC-$FFFF (or corresponding addresses from $FFE4 up), set PRG BANK /RE high. The game doesn't use IRQs, so this catches only the reset vector (and reset handler)
* If CPU accesses $8xxx-$Bxxx, set PRG BANK /RE low
* Otherwise, PRG BANK /RE should be unchanged
* Disconnect PRG BANK LOW /RE from ground, and connect it to PRG BANK HIGH /RE
* Pullup resistors on PRG A13 and A14—this only needs to last for the initial powerup, and the initialization routine is present at the end of each 32 KiB so we don't need pullups on the other lines.

The fusemap should be
pin = pin AND NOT LOWERCONDITION OR RAISECONDITION
LOWERCONDITION = /ROMSEL=0 AND A14 = 1
NOT LOWERCONDITION = /ROMSEL=1 OR A14 = 0
pin12 = AND(pin12,/ROMSEL) OR AND(pin12,NOT A14) OR AND(NOT /ROMSEL,A14…A5,A2) ... that's only 2 ORs (GAL16V8 supports 6 or 7) so this should work.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-27 (#166956)

lidnariq wrote:

As near as I can tell, A18 seems to be unchanged (as a HiZ output "should" be with the parasitic capacitance of the traces) ... and that's what I see in Ice Man's dumps.

You mean, as if one of the previous bytes was fetched from a "normal" address (with /RE=low), then A18 would stay at the same level for next some microseconds for any bytes that are fetched from "floating" addresses (those with /RE=high). Yes, that would make sense, and seems to match better with Ice Man's dumps (as there are no "differences" occuring in last hundred kilobytes).

lidnariq wrote:

The game relies on being able to change the NMI vector by changing the bank.

Yes, no. The NMI vector is somewhere inbetween the weird /RE areas, but it isn't part of the obscure /RE=high regions.
The pull-up on A17 doesn't affect the NMI.
Concerning NMI, the cartridge is just working as it has been excepted throughout past some years.
All the game needs to do is never to set 6003h to other value than 03h, then NMI should work fine. If the game wants to access other PRG banks, then it must probably do that via other ports, like 6002h or so.

lidnariq wrote:

I have absolutely no idea how this was ever supposed to work, unless the 74'670s just happened to, as we previously guessed, tend to power up with the value "3" in memory.

Yes, sorts, of. The reset vectors exist at end of each 32K bank (aka at end of each fourth 8K bank), so the lower 2bit of the bank number must tend to "3" on power-up, but any other value with lower 2bits set should works too, like 7, 0Bh, 0Fh, 13h, etc. Most likely it's just all bits tending to be set, hence my guess on 3Fh being the initial 6bit bank number.

----

For reprogramming the GAL, I think two solutions should work:

1) the /RE stuff seems to be solely switching between "normal" and "floating" banks during execution of the bootstrap code, there is absolutely no good reason for doing that, so one could just program the GAL to always output /RE=low (or just leave the GAL as is, and instead shortcut /RE to GND; ie. wire U7.Pin11 to GND, and (to avoid a harmless shortcut) disconnect GAL.Pin12).
After all, emulators seem to work well without reproducing the /RE stuff.

2) the /RE stuff seems to be totally useless, but it shouldn't disturb anything. I think the famicom-compatibility issue is just caused by different M2 timing, M2 might be important for WRITE operations (like SRAM access, or I/O port access), but for READ operations it's rather nonsense to output the read-address ONLY during M2. So one could just use the GALs original formulasand omit M2 from the /RE formula and leave everything else unchanged.

EDIT: The "pin = pin AND NOT LOWERCONDITION OR RAISECONDITION" idea also looks elegant. I thought somebody told me that GALs or PALs wouldn't be too reliable about memorizing "states" (when trying to figure out if/how the SNES six-player adaptors could work). But if it works, then it would be fine. I don't understand how you came up with the "$8xxx-$Bxxx" area though (?)

Oh, or third idea: remove the second resistor from left, that one pulls A17 high when entering the "weird" /RE=high state, if /RE gets switched too early then it would smash A17, but without the resistor A17 might stay floating intact due to impedance reasons.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-27 (#166958)

Removed the 2nd 4.7k resistor. A white dot on the top left appeared on the monitor, but game still did not boot. With the resistor in place I only get a black screen.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by lidnariq on 2016-03-27 (#166963)

Ice Man, could you easily throw the 74'670s in a breadboard to find out what values your ICs tend to power up containing? Should be something easy like: tie /WE high, D0-D3 don't matter, Wa-Wb don't matter, Q0-Q3 to resistor+LEDs, /RE low, Ra-Rb high (or to switches)

nocash wrote:

All the game needs to do is never to set 6003h to other value than 03h, then NMI should work fine. If the game wants to access other PRG banks, then it must probably do that via other ports, like 6002h or so.

But it does. I added some tracing statements to FCEUX and got bank layouts like <00 01 02 03>, <08 09 0A 0B>, <08 2F 0A 0B>, <08 60 0A 0B>, <1C 1D 1E 1F>, <20 21 22 23>, <30 31 32 33>

nocash wrote:

I don't understand how you came up with the "$8xxx-$Bxxx" area though (?)

Just an arbitrary marker that the game is out of the reset bootstrap and wants "real" banking thereafter.

If for some reason the feedback path doesn't work, it also seems to work (at least in an emulator) to just force the memory region from $FFC0-$FFFF to always come from ROM offset $7FC0-$7FFF.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-27 (#166966)

Wish I had a breadboard for testing here. Sorry.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-27 (#166968)

Ice Man wrote:

Removed the 2nd 4.7k resistor. A white dot on the top left appeared on the monitor, but game still did not boot. With the resistor in place I only get a black screen.

Good to know that it didn't work that simple. Thanks for testing!

Ice Man wrote:

Wish I had a breadboard for testing here. Sorry. :(

I guess you could improve something if needed: Wire directly to the raw chip. Or make your own breadboard by wiring to socket (maybe with a small PCB to make the socket more robust).

Or try the idea about GNDing U7.Pin11. Maybe that works out, and it would be simple to do.

lidnariq wrote:

Yeah, would be nice to test that! But pick the right one (the one that you had marked "U6 - 74'670 Lower PRG Side"), the chips seem to be from different manufacturers, and might behave differently (at least I've spotted such effects in SRAMs from different manufacturers). I hope you still know which chip was U6 before you desoldered them - if you swapped the 74670's around then the cart might have stopped working even on NOACs.

lidnariq wrote:

I added some tracing statements to FCEUX and got bank layouts like <00 01 02 03>, <08 09 0A 0B>, <08 2F 0A 0B>, <08 60 0A 0B>, <1C 1D 1E 1F>, <20 21 22 23>, <30 31 32 33>

Oh, okay. Then I don't know how the game works in no$nes (or if works beyond reaching the title screen).
It might have NMI's disabled while switching banks without NMI vector; or take care to map bank 03h before vblank occurrs.

lidnariq wrote:

nocash wrote:

I don't understand how you came up with the "$8xxx-$Bxxx" area though (?)

Just an arbitrary marker that the game is out of the reset bootstrap and wants "real" banking thereafter.

Yah, that should be good enough to see if it gets the game working, although in reality in would work slightly different.

lidnariq wrote:

If for some reason the feedback path doesn't work, it also seems to work (at least in an emulator) to just force the memory region from $FFC0-$FFFF to always come from ROM offset $7FC0-$7FFF.

For the NMI, yes, should be so (=bank 03h).

For Reset, another oddity is that Ice Man's dump doesn't have a valid reset vector in bank 03h (almost everywhere else, but not in that bank). I think the A17 pull-up might be intended to force Reset to work (if bank 03h is selected, then it would become bank 13h).
If the initial bank on power-up is 3Fh, then the above pull-up would be needed only if somebody pushes reset-button while the game has mapped bank 03h. Dunno if the NOAC's have reset-buttons at all though.

For the different vectors in bank 03h dumps. I think that all ROMs might be always containing the values that Ice Man has dumped, the dumps that have FFD0h vectors in bank 03h might be due dumping the ROMs differently (by mapping 4 banks via 6000h..6003h, and then reading 32Kbytes at once from 8000h..FFFFh; that should theoretically replace FF00h from bank 03h by FFD0h form bank 13h).

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-27 (#166970)

nocash wrote:

Or try the idea about GNDing U7.Pin11. Maybe that works out, and it would be simple to do.

Will try that one later and report how it turns out!

nocash wrote:

I replaced all 74'670 with newer ones. Dumping the game didn't make any difference with either. Dumped it before and after replacing them.

However, how exactly would I improve to make a breadboard (using wires only). I mean, where would I connect the wires to after all?

EDIT: Connected U7.Pin11 to ground. Nothing happened, but after that the game always displays the white dot on the upper left corner on the monitor and upon reset I get a full screen of garbage of for a split second (this also happens in FCEUX but the game start). However, when CHR is missing (only PRG) the game does not restart but get stuck. Is it possible that the problem lies within CHR and not PRG?

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-27 (#166977)

Theroretically CHR could also cause problems. But I think it's rather unlikely. Of course, the whole cartridge works "rather unlikely".

A breadboard is just some test board that that allows you to connect wires to chips (via plugs, without soldering) - you could as well use a soldering iron to get the same effect. All you need is knowing where you want to connect the wires to. In this case, this connection could be fine:

Code:

                             74670
                         .----. .----.
                 +5V -- 1|D2  '-' VCC|16 -- +5V
                 +5V -- 2|D3       D1|15 -- +5V
                 +5V -- 3|D4      WA0|14 -- +5V
                 +5V -- 4|RA1     WA1|13 -- +5V
                 +5V -- 5|RA0     /WR|12 -- +5V
     test this -------- 6|Q4      /RD|11 --- GND
     test this -------- 7|Q3       Q1|10 ----------- test this
                GND --- 8|GND      Q2|9  ----------- test this
                         '-----------'

Some of the +5V pins would be don't care, but it should be easiest just to bridge all those pins without skipping don't care pins.
Important pins are VCC and GND as supply, and /WR=+5V to prevent the initial content on power up getting overwritten, and /RD=GND to cause the chip to output it's content. RA0 and RA1 to +5V selects the last bank value to be output (the one that affects E000h..FFFFh).
For the four pins marked as "test this", you could attach LEDs-with-resistor there, or just use a multimeter (in DC/volt mode) to measure the voltage (ie. connect the probes to GND and the "test" pins) (maybe also try probing GND and +5V, just to see if you got it right, it should show "5" volts then).
If the chip tends to boot up with all bits sets, then you should see around 5 volt on the test pins each time when the power supply is switched on.

If you are there, you might also try wiring /RD to +5V, just to see what kind of "floating" voltage is appearing on the four "test" pins.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-27 (#166980)

I'm tempted to buy a breadboard for this testing (and maybe for the future as well!). I'd need to desolder the U6 74'670 (or U7, too?) and put it in there, right?

Also, not to go offtopic too much but would that one be any good/work?

Link

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-27 (#166983)

I don't have a breadboard myself, but to me the link/photo looks about how those boards should look like. For the test circuit from previous post you could simply bridge all the 5V pins with a wire, that's almost easier as using a breadboard.

Didn't you already desolder the old 74670's and replaced them by new ones? When I said testing U6, I meant the chip that was originally installed as U6. Testing that chip would be best.

If you've thrown that chip away, or don't remember which chip has been the original U6, then... well, you could instead test any 74670 you want (and hope that it will behave the same as the original chip; the results would be interesting, but not 100% proof) (unless you tested if that chip works okay as U6 on a NOAC, then it should be 100% proof).

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-27 (#166984)

Oh, bummer. I've thrown them away after desoldering but they should be in the trash and findable!
I will know from the pictures which one was U6, that's not the problem, at last.

Going to buy that breadboard anyway and hope I can deliver results once it arrives!

EDIT: Hopefully getting a new NOAC as well to test even more accurate!

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-28 (#167067)

I can dump the CHR now as well.

Kazzo Script:

Code:

board <- {
    mappernum = 246,
   cpu_rom = {
      size_base = 4 * mega, size_max = 4 * mega, banksize = 0x2000
   },
   ppu_rom = {
      size_base = 4 * mega, size_max = 4 * mega, banksize = 0x0800,
   },
   ppu_ramfind = true, vram_mirrorfind = false
};


function cpu_dump(d, pagesize, banksize)
{
   for(local i = 0; i < pagesize; i += 1){
      cpu_write(d, 0x6000, i);
      cpu_read(d, 0x8000, banksize);
   }
}

function ppu_dump(d, pagesize, banksize)
{
   for(local i = 0; i < pagesize; i += 1){
      cpu_write(d, 0x6004, i);
      cpu_write(d, 0x8000, i);
      ppu_read(d, 0, banksize );
   }
}

And I noticed that one byte of CHR is also different.
BD7D8 is 07 instead of 27.

Other than, completely equal other than the reset and irq/vector at 800C-800F.

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by Ice Man on 2016-03-29 (#167130)

Game works on the Famicom!

Appearently the SRAM was corrupted or something.

I replaced it with a new one and the game boots up fine in an original Famicom with all 4x 74
'670 + 8KB PRG RAM replaced.

Thanks for the all the help guys!

Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
by nocash on 2016-03-29 (#167131)

Ice Man wrote:

Game works on the Famicom! Appearently the SRAM was corrupted or something.

Okay, that's a surprise solution, almost a bit disappointing that it's been that simple, and strange that the old SRAM worked on NOAC, maybe it's somehow related to SRAM manufacturer/timing/voltages that worked better on NOAC. If the SRAM tends to boot up with different content on different consoles, then it should at least work on Famicom once when it was initialized on NOAC (provided that the battery was alive and did hold the data; did the battery still have 3V, and was the battery installed when swapping the cart between NOAC and Famicom?).
Well, probably we'll never be able to say for sure what had happened there. But we've learned a good bit about the other oddities of the cartridge's mapping logic.

Just another thing that I had noticed (when checking if the game is doing anything unusual on software side):

Code:

8AAB AD 72 68     mov  a,[6872]
8AAE D0 29        jnz  8AD9
8AB0 A9 01        mov  a,01
8AB2 8D D9 8A     mov  [8AD9],a      ;<-- rom write (try to "smash" code?)
8AB5 A5 1E        mov  a,[1E]
8AB7 C9 20        cmp  a,20
8AB9 D0 0C        jnz  8AC7          ;<-- true (jumps)
8ABB 8D 72 68     mov  [6872],a
8ABE A9 16        mov  a,16
8AC0 85 38        mov  [38],a
8AC2 A9 88        mov  a,88
8AC4 85 00        mov  [00],a
8AC6 60           ret
8AC7 A5 1E        mov  a,[1E]
8AC9 C9 C0        cmp  a,C0
8ACB D0 0C        jnz  8AD9          ;<-- true (jumps to "smashed" opcode)
8ACD 8D 72 68     mov  [6872],a
8AD0 A9 18        mov  a,18
8AD2 85 38        mov  [38],a
8AD4 A9 88        mov  a,88
8AD6 85 00        mov  [00],a
8AD8 60           ret
8AD9 20 21 B1     call B121          ;<-- game tries to smash this opcode
8ADC A9 00        mov  a,00
8ADE 8D 00 20     mov  [2000],a  ;ppu ctrl 1

The ROM write shouldn't cause problems on real hardware (it should be just ignored). Either the write is just a bug, or it's some copy-protection against emulators or copiers that have the ROM-image stored in write-able RAM instead of real ROM.

The different CHR byte is also odd, did you dump it 2-3 times to see if it's stable, and only that byte being different as expected in each dump? Probably hard to say what the byte is doing (could be changing a pixel color anywhere in the game), unless it's something eye-catching like changing the year/date in the title screen.