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

[nocash]

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.

[nocash]

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!

[Ice Man]

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.

[lidnariq]

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.

[nocash]

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.

[Ice Man]

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.

[nocash]

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

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

[Ice Man]

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.

[nocash]

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!

[lidnariq]

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.

[Ice Man]

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?

[nocash]

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.

[Ice Man]

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

[nocash]

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

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.

[Ice Man]

RAW ASCII:

Code: Select all

			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.