Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)(Solved)
Moderators: B00daW, Moderators
Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
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.
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)
Wait! First be sure that the old chip has been dumped successfully before reprogramming it!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 :)
Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
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.
My TL866 never caused any problems from reading/writing from/to ICs.
Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
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.
(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)
Do you have some example, where is that seen, and what kind of vectors?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.
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)
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.
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)
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").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
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).
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.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.
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)).
Last edited by nocash on Wed Mar 23, 2016 6:19 am, edited 1 time in total.
Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
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.
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)
Yes, sure! Following traces on photos without multimeter can be painful, but yes, take photos before you solder the chips back in!Ice Man wrote: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)
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.nocash wrote: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").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
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)
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?
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)
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.
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)
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
Also hopefully better HiRes pictures of the board (with just PRG and CHR on).
Front
Back
Last edited by Ice Man on Sat Mar 26, 2016 9:42 am, edited 2 times in total.
Re: Fong Shen Bang - Zhu Lu Zhi Zhan (Mapper 246)
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:
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.
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);
}
}
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)
RAW ASCII:
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.
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 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.
Last edited by Ice Man on Sat Mar 26, 2016 2:22 pm, edited 7 times in total.