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

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

Ice Man
Posts: 546
Joined: Fri Jul 04, 2014 2:34 pm

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

Post by Ice Man » Mon Mar 21, 2016 3:40 am

Might try that.

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

nocash
Posts: 1261
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

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

Post by nocash » Mon Mar 21, 2016 5:59 am

lidnariq wrote:

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

Ice Man
Posts: 546
Joined: Fri Jul 04, 2014 2:34 pm

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

Post by Ice Man » Mon Mar 21, 2016 6:06 am

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.

nocash
Posts: 1261
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

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

Post by nocash » Mon Mar 21, 2016 6:30 am

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.

Ice Man
Posts: 546
Joined: Fri Jul 04, 2014 2:34 pm

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

Post by Ice Man » Mon Mar 21, 2016 7:40 am

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

Code: Select all

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: Select all

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: Select all

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?

lidnariq
Posts: 9875
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

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

Post by lidnariq » Mon Mar 21, 2016 8:01 am

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.

Ice Man
Posts: 546
Joined: Fri Jul 04, 2014 2:34 pm

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

Post by Ice Man » Mon Mar 21, 2016 8:49 am

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.

lidnariq
Posts: 9875
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

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

Post by lidnariq » Mon Mar 21, 2016 8:52 am

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.

Ice Man
Posts: 546
Joined: Fri Jul 04, 2014 2:34 pm

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

Post by Ice Man » Mon Mar 21, 2016 11:00 am

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.

lidnariq
Posts: 9875
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

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

Post by lidnariq » Tue Mar 22, 2016 7:09 am

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)

Ice Man
Posts: 546
Joined: Fri Jul 04, 2014 2:34 pm

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

Post by Ice Man » Tue Mar 22, 2016 8:44 am

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

Code: Select all

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.
Attachments
Fong Shen Bang.zip
(386 Bytes) Downloaded 139 times

lidnariq
Posts: 9875
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

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

Post by lidnariq » Tue Mar 22, 2016 9:41 am

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

Code: Select all

;$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?

tepples
Posts: 22162
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples » Tue Mar 22, 2016 10:55 am

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.

nocash
Posts: 1261
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

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

Post by nocash » Tue Mar 22, 2016 2:22 pm

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: Select all

  /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: Select all

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

lidnariq
Posts: 9875
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

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

Post by lidnariq » Tue Mar 22, 2016 2:46 pm

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 :)
Last edited by lidnariq on Mon Nov 07, 2016 8:29 am, edited 2 times in total.

Post Reply