It is currently Fri Jun 22, 2018 8:36 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 85 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Fri Mar 25, 2016 9:07 am 
Offline

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


Top
 Profile  
 
PostPosted: Fri Mar 25, 2016 1:04 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7223
Location: Seattle
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.)


Top
 Profile  
 
PostPosted: Fri Mar 25, 2016 1:16 pm 
Offline

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


Top
 Profile  
 
PostPosted: Fri Mar 25, 2016 2:53 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7223
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 6:53 am 
Offline

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


Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 7:23 am 
Offline

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


Attachments:
Fong Shen Bang PRG Dumps.zip [381.53 KiB]
Downloaded 48 times
Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 8:23 am 
Offline

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


Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 9:20 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7223
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 9:41 am 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
Pin 15 of the GAL is indeed connected to CPU R/W + SRAM /WE. Just measured again. Sorry about that.


Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 9:52 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 560
I am looking at the photos, too. Especially the resistors/diodes. Here's what I came up with:
Attachment:
Mapper246.jpg
Mapper246.jpg [ 27.5 KiB | Viewed 1432 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?


Last edited by nocash on Sat Mar 26, 2016 10:09 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 10:03 am 
Offline

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


Attachments:
Mapper246.jpg
Mapper246.jpg [ 23.63 KiB | Viewed 1430 times ]
Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 10:40 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 560
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
Snippet.jpg [ 5.52 KiB | Viewed 1423 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.


Last edited by nocash on Sat Mar 26, 2016 10:56 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 10:54 am 
Offline

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


Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 11:25 am 
Offline

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


Last edited by nocash on Sat Mar 26, 2016 11:47 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Mar 26, 2016 11:45 am 
Offline

Joined: Fri Jul 04, 2014 2:34 pm
Posts: 335
Location: Germany
Yea, I don't have any other theories for that either anymore now. :P
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.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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:  
cron
Powered by phpBB® Forum Software © phpBB Group