Hacked Famicom Cartridge cart - Need info for dump

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

labatt24
Posts: 26
Joined: Thu Oct 05, 2017 5:20 am

Hacked Famicom Cartridge cart - Need info for dump

Post by labatt24 » Thu Oct 05, 2017 5:32 am

Hello !

Around a year ago, I tried to dump my 700-in-1 Famicom cartridge using the Kazoo dumper but it seems I don't have many info on the cart (size, PPU_ROM, CPU_RAM, CPU-ROM, Memory bank/size, CHK_PRG, etc).

Someone have experience with Famicon cart? See some pictures.

I use a Famicom converter to make it work on my NES console.

Thanks !

Guy
Attachments
11252688_10153174891136645_7660918871319488794_o.jpg
10658824_10153174891091645_9177965291743260778_o.jpg

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

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by lidnariq » Thu Oct 05, 2017 1:05 pm

I swear I've seen those big silkscreened "MK008" and "MK009" somewhere else recently, but I can't remember where.

Since it's a pirate multicart, it'll probably need a custom kazoo script. Given that the only hardware on the board is two 74'174s, a 74'139, and a 74'153, it'll be pretty easy to reverse-engineer it even without knowing what mapper it corresponds to.

Ideally, we'll find that "MK008" ROM somewhere in a thread and be able to write—or maybe even find already existing—the kazoo script from that data.

BUT IF WE CAN'T: this board is simple enough that we know approximately how it's going to work: Twelve of the pins on the two '174s are going to connect to the card edge; two will go to the 74'153, and the other ten will go to the three ROMs. Sitting down with a multimeter and determining what pins connect to what pins will let us tell you exactly what the hardware is doing, and then write a script from that.

User avatar
Dwedit
Posts: 4297
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by Dwedit » Thu Oct 05, 2017 1:10 pm

The real question is what actual games are on it?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

labatt24
Posts: 26
Joined: Thu Oct 05, 2017 5:20 am

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by labatt24 » Fri Oct 06, 2017 7:49 am

Dwedit wrote:The real question is what actual games are on it?
It's a 700-in-1 special games exactly like the 260-in-1.

labatt24
Posts: 26
Joined: Thu Oct 05, 2017 5:20 am

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by labatt24 » Fri Oct 06, 2017 7:53 am

lidnariq wrote:I swear I've seen those big silkscreened "MK008" and "MK009" somewhere else recently, but I can't remember where.

Since it's a pirate multicart, it'll probably need a custom kazoo script. Given that the only hardware on the board is two 74'174s, a 74'139, and a 74'153, it'll be pretty easy to reverse-engineer it even without knowing what mapper it corresponds to.

Ideally, we'll find that "MK008" ROM somewhere in a thread and be able to write—or maybe even find already existing—the kazoo script from that data.

BUT IF WE CAN'T: this board is simple enough that we know approximately how it's going to work: Twelve of the pins on the two '174s are going to connect to the card edge; two will go to the 74'153, and the other ten will go to the three ROMs. Sitting down with a multimeter and determining what pins connect to what pins will let us tell you exactly what the hardware is doing, and then write a script from that.
It's a lot of informations!

TBH, I am new on this and I don't know how the cartridge work. I was hoping an existing script to be able to dump the cart.

What would be the steps on how to build/write the script?

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

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by lidnariq » Fri Oct 06, 2017 9:45 am

GoodNES has something called "260-in-1" that's mapper 231. But our documentation about mapper 231 doesn't support an image that's as big as the 4 MiB image in GoodNES.
GoodNES also has something called "700-in-1" that's mapper 221; we don't have any documentation about mapper 221.
Finally, GoodNES has something called "Super 700-in-1" that's mapper 62; but that requires more than 12 bits of state (the two 74LS174s visible in your picture)



Sometimes we can reverse-engineer a cart from just pictures, but here I think too many traces go under the ICs to be able to do that. Sometimes people desolder all the ICs in order to get a bare PCB, which makes reverse engineering easy.



IF you're willing to make/have and use a continuity (multi-)meter, then, the testing basically goes something like this:

* Some combination of CPU address and data lines will connect to the inputs ("D") of the two 74LS174s.

* Some combination of CPU address lines, /ROMSEL, M2, R/W, and the outputs from the 174s ("Q") will connect to the inputs ("E" and "A") of the 74LS139.

* The outputs of the 74LS139s ("Y") will connect to the CLOCK input of the 174s and the ROMs' "OE" input.

* The outputs from the 174s ("Q") will connect to the ROM's address lines, and to the "S" and "E" inputs on the 74LS153.



Well, I found MK001 and MK004... Could be the same cart hardware, dunno. Certainly it has the same support ICs.

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

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by lidnariq » Sat Oct 07, 2017 8:13 pm

Assuming that it is mapper 235, hopefully something like this should work:

Code: Select all

 board <- {
   mappernum = 235,
   cpu_rom = {
      size_base = 32768, size_max = 4194304, banksize = 0x8000
   }, 
   ppu_rom = {
      size_base = 0, size_max = 0, banksize = 0
   },
   ppu_ramfind = false, vram_mirrorfind = true
};

function cpu_dump(d, pagesize, banksize) {
  for (local i = 0; i < pagesize; i += 1) {
    cpu_write(d, 0xF800 | (i & 31) | ((i << 3) & 0x300, i);
    cpu_read(d, 0x8000, 0x4000);
    cpu_read(d, 0xc000, 0x4000);
  }
}
It may well not be mapper 235, and since your board has three ROMs it may not be compatible with the existing way emulators decode mapper 235 anyway. But it's something you can try.

labatt24
Posts: 26
Joined: Thu Oct 05, 2017 5:20 am

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by labatt24 » Wed Oct 11, 2017 8:29 am

lidnariq wrote:Assuming that it is mapper 235, hopefully something like this should work:

Code: Select all

 board <- {
   mappernum = 235,
   cpu_rom = {
      size_base = 32768, size_max = 4194304, banksize = 0x8000
   }, 
   ppu_rom = {
      size_base = 0, size_max = 0, banksize = 0
   },
   ppu_ramfind = false, vram_mirrorfind = true
};

function cpu_dump(d, pagesize, banksize) {
  for (local i = 0; i < pagesize; i += 1) {
    cpu_write(d, 0xF800 | (i & 31) | ((i << 3) & 0x300, i);
    cpu_read(d, 0x8000, 0x4000);
    cpu_read(d, 0xc000, 0x4000);
  }
}
It may well not be mapper 235, and since your board has three ROMs it may not be compatible with the existing way emulators decode mapper 235 anyway. But it's something you can try.
Thanks a lot for your time. Didn't know it was complicated like that. I will read on how the cart works.

I will try the script for sure and I will let you know the outcome.

To be continued!

Guy

labatt24
Posts: 26
Joined: Thu Oct 05, 2017 5:20 am

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by labatt24 » Wed Oct 11, 2017 7:24 pm

lidnariq wrote:Assuming that it is mapper 235, hopefully something like this should work:

Code: Select all

 board <- {
   mappernum = 235,
   cpu_rom = {
      size_base = 32768, size_max = 4194304, banksize = 0x8000
   }, 
   ppu_rom = {
      size_base = 0, size_max = 0, banksize = 0
   },
   ppu_ramfind = false, vram_mirrorfind = true
};

function cpu_dump(d, pagesize, banksize) {
  for (local i = 0; i < pagesize; i += 1) {
    cpu_write(d, 0xF800 | (i & 31) | ((i << 3) & 0x300, i);
    cpu_read(d, 0x8000, 0x4000);
    cpu_read(d, 0xc000, 0x4000);
  }
}
It may well not be mapper 235, and since your board has three ROMs it may not be compatible with the existing way emulators decode mapper 235 anyway. But it's something you can try.
I tried to dump using anago wx and I have the following error :

AN ERROR HAS OCCURED [expression expected]

CALLSTACK
*FUNCTION [dump()] dumpcore.nut line [15]

LOCALS
[increase_ppu] 1
[increase_cpu] 11
[mappernum] 235
[script] "MULTI.ad"
[d] USERPOINTER
[this] TABLE

Is there a way to force dump or the script is missing something?

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

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by lidnariq » Wed Oct 11, 2017 7:48 pm

... I failed to balance my parentheses.

Try adding the paren in red:

cpu_write(d, 0xF800 | (i & 31) | ((i << 3) & 0x300), i);

labatt24
Posts: 26
Joined: Thu Oct 05, 2017 5:20 am

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by labatt24 » Wed Oct 11, 2017 7:58 pm

lidnariq wrote:... I failed to balance my parentheses.

Try adding the paren in red:

cpu_write(d, 0xF800 | (i & 31) | ((i << 3) & 0x300), i);
Thank you for your reply.

I have a CPU jam under Nestopia.

But, the size of the rom is only 32ko : it is normal?

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

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by lidnariq » Wed Oct 11, 2017 8:04 pm

Nope.

No idea how big those two big mask ROMs (MK008, MK009) are, but 1 MiB each seems likely. The UVEPROM in the corner is 32 KiB, so if this is still mapper 235, I'd expect 4 MiB of data containing the 32 KiB of ROM repeated 32 times, an empty 1 MiB, and 2 MiB of data, in some unknown permutation.

Try changing "size_base = 32768" to "size_base = 4194304" to just force the matter.

labatt24
Posts: 26
Joined: Thu Oct 05, 2017 5:20 am

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by labatt24 » Wed Oct 11, 2017 8:18 pm

lidnariq wrote:Nope.

No idea how big those two big mask ROMs (MK008, MK009) are, but 1 MiB each seems likely. The UVEPROM in the corner is 32 KiB, so if this is still mapper 235, I'd expect 4 MiB of data containing the 32 KiB of ROM repeated 32 times, an empty 1 MiB, and 2 MiB of data, in some unknown permutation.

Try changing "size_base = 32768" to "size_base = 4194304" to just force the matter.
Thanks again for your reply.

I was able to do a dump of 4MiB. I loaded the ROM using Nestopia and I have no video but no CPU Jam.

Here a picture of what Nestopia can see from the ROM (iNes Header).

Is there a better emulator to test the ROM?
Attachments
ROM Info - Nestopia.PNG

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

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by lidnariq » Wed Oct 11, 2017 8:46 pm

You ... could try this?

cpu_write(d, 0xF800 | (i & 31) | ((i << 4) & 0x200) | (i << 2) & 0x100), i);

There's this problem that iNES only really handles the notion of contiguous memory. However, that assumption isn't true for either the known mapper 235 hardware, and is also unlikely for yours.

The known mapper 235 hardware has only ROMs #s "0" and "2", but the iNES dump stores them contiguously. So we can try doing the same reordering—the above line will dump the ROMs in the order of 0,2,1,3 ...

You could also PM me the image you have and I can tell you if the dump worked at all.

labatt24
Posts: 26
Joined: Thu Oct 05, 2017 5:20 am

Re: Hacked Famicom Cartridge cart - Need info for dump

Post by labatt24 » Wed Oct 11, 2017 8:56 pm

lidnariq wrote:You ... could try this?

cpu_write(d, 0xF800 | (i & 31) | ((i << 4) & 0x200) | (i << 2) & 0x100), i);

There's this problem that iNES only really handles the notion of contiguous memory. However, that assumption isn't true for either the known mapper 235 hardware, and is also unlikely for yours.

The known mapper 235 hardware has only ROMs #s "0" and "2", but the iNES dump stores them contiguously. So we can try doing the same reordering—the above line will dump the ROMs in the order of 0,2,1,3 ...

You could also PM me the image you have and I can tell you if the dump worked at all.
A ( was missing on your code.

cpu_write(d, 0xF800 | (i & 31) | ((i << 4) & 0x200) | ((i << 2) & 0x100), i);

Still dumping the cart!

Post Reply