It is currently Wed Jul 17, 2019 12:20 am

View unanswered posts | View active topics


Board index » NES / Famicom » NES Hardware and Flash Equipment

All times are UTC - 7 hours





Post new topic Reply to topic  Page 3 of 6
  [ 87 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
  Print view Previous topic | Next topic 
Author Message
nocash
PostPosted: Tue Mar 22, 2016 3:06 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 936
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.
Top
 Profile  
 
nocash
PostPosted: Tue Mar 22, 2016 3:14 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 936
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!
Top
 Profile  
 
Ice Man
PostPosted: Tue Mar 22, 2016 4:13 pm 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
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.
Top
 Profile  
 
lidnariq
PostPosted: Tue Mar 22, 2016 7:37 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8479
Location: Seattle
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.
Top
 Profile  
 
nocash
PostPosted: Wed Mar 23, 2016 4:35 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 936
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.
Top
 Profile  
 
Ice Man
PostPosted: Wed Mar 23, 2016 5:06 am 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
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.
Top
 Profile  
 
nocash
PostPosted: Wed Mar 23, 2016 5:56 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 936
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)).


Last edited by nocash on Wed Mar 23, 2016 6:19 am, edited 1 time in total.

Top
 Profile  
 
Ice Man
PostPosted: Wed Mar 23, 2016 6:09 am 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
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.
Top
 Profile  
 
nocash
PostPosted: Wed Mar 23, 2016 6:17 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 936
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!
Top
 Profile  
 
lidnariq
PostPosted: Wed Mar 23, 2016 7:58 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8479
Location: Seattle
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.
Top
 Profile  
 
Ice Man
PostPosted: Wed Mar 23, 2016 8:30 am 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
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?


Attachments:
IMG_6807.JPG
IMG_6807.JPG [ 209.84 KiB | Viewed 2337 times ]
IMG_6805.JPG
IMG_6805.JPG [ 221.46 KiB | Viewed 2337 times ]
Top
 Profile  
 
nocash
PostPosted: Wed Mar 23, 2016 8:56 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 936
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.
Top
 Profile  
 
Ice Man
PostPosted: Thu Mar 24, 2016 3:28 am 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
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


Last edited by Ice Man on Sat Mar 26, 2016 9:42 am, edited 2 times in total.

Top
 Profile  
 
nocash
PostPosted: Thu Mar 24, 2016 2:30 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 936
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.
Top
 Profile  
 
Ice Man
PostPosted: Thu Mar 24, 2016 4:34 pm 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
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.


Last edited by Ice Man on Sat Mar 26, 2016 2:22 pm, edited 7 times in total.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 3 of 6
  [ 87 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

Board index » NES / Famicom » NES Hardware and Flash Equipment

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group