This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Hacked Famicom Cartridge cart - Need info for dump

Hacked Famicom Cartridge cart - Need info for dump
by on (#205582)
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
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205594)
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.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205595)
The real question is what actual games are on it?
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205612)
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.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205613)
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?
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205621)
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.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205659)
Assuming that it is mapper 235, hopefully something like this should work:
Code:
 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.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205788)
lidnariq wrote:
Assuming that it is mapper 235, hopefully something like this should work:
Code:
 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
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205815)
lidnariq wrote:
Assuming that it is mapper 235, hopefully something like this should work:
Code:
 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?
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205817)
... I failed to balance my parentheses.

Try adding the paren in red:

cpu_write(d, 0xF800 | (i & 31) | ((i << 3) & 0x300), i);
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205819)
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?
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205820)
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.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205821)
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?
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205824)
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.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205825)
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!
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205826)
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.


Hummm, no chance.

Any ideas? I am open to try anything ! I will do some search also on my side.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205827)
One first difficulty:
* This board has a diode that detects when user is pressing the reset button, and changes what bank is present at that time. I don't know if the Kazzo correctly drives its outputs to keep this from getting in the way, but if it doesn't, then modifying the board to support this will be required.

Other than that, there's basically two ways forward:

* Actually trace the connectivity of the parts on the board. Go back to what I said earlier, and use a multimeter or continuity meter to figure out what connects to what. I can write a Kazoo script for whatever that turns out to be.

* Send someone the first 32 KiB dump that you got, which is almost certainly the menu. It is likely possible to deduce what hardware the menu expects is present based on the contents.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205885)
lidnariq wrote:
One first difficulty:
* This board has a diode that detects when user is pressing the reset button, and changes what bank is present at that time. I don't know if the Kazzo correctly drives its outputs to keep this from getting in the way, but if it doesn't, then modifying the board to support this will be required.

Other than that, there's basically two ways forward:

* Actually trace the connectivity of the parts on the board. Go back to what I said earlier, and use a multimeter or continuity meter to figure out what connects to what. I can write a Kazoo script for whatever that turns out to be.

* Send someone the first 32 KiB dump that you got, which is almost certainly the menu. It is likely possible to deduce what hardware the menu expects is present based on the contents.

Will do. I will try to identify which pin goes to which pin and which chip.

I seems I have the same PCB than the 1001-in-1 multicart : http://justinpaulin.com/tag/pirate-carts/
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205923)
https://forums.nesdev.com/viewtopic.php?f=9&t=9866
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205924)
Hm, well, then we could try
cpu_write(d, 0xFC00 | (i & 31) | ((i << 4) & 0x200) | ((i << 2) & 0x100), i);


Nevermind, toggling the 0x400s bit wouldn't help; only the nametable modes change between krzsiobal's board and m235

It's so very close to m235 but just enough different... there may not be a mapper for it.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#205936)
labatt24 wrote:
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.


Does the cartridge has this label?

Image
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#206048)
krzysiobal wrote:
https://forums.nesdev.com/viewtopic.php?f=9&t=9866

Hummmm, it's pretty much the same cart !
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#206049)
MWK wrote:
labatt24 wrote:
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.


Does the cartridge has this label?

Image

Nope, I don't have the original case. 15 years ago, I remember we changed the case because the original was broken (threw it on the floor by accident).
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#206058)
labatt24 wrote:
15 years ago, I remember we changed [a pirate multicart's] case because the original was broken (threw it on the floor by accident).

I guess that's one way to tell a pirate cart: Official Game Paks are Tonka Tough.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#206069)
Since the m235 earlier dumper script should have worked to produce an accurate (if non functional) image, the only real question is whether you got a valid dump.

If you have a hex editor or similar, you could check if the entire file is the same 16 KiB repeated over and over.

If you don't have a hex editor, you could try just compressing the resultant 4 MiB image using zip or 7zip or rar or something. If the result is tiny (like, 16 KiB-ish) then that also indicates that the file contains a gazillion repeats of the same data.

If the entire file indicates the file is the same repeated 16 KiB over and over, then you'll either need to temporarily disable the reset detection circuit, or maybe there's a way to tell Kazoo/Anago/Unagi to drive M2.

We still would need to figure out how to encapsulate this image; with multiple noncontiguous ROMs it's a particularly bad mismatch to the iNES format.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#206970)
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.



Alright, I did a conductivity test on the board. Some pins seems not having conductivity or are connected to the PINS cart. Please tell me if something seems wrong on my readings. The first 9122VG (174) is the first starting at the left of the cart (front picture of the cart).

9122VG (174)

PIN1 : PIN1 of 2nd 174
PIN2 : PIN1 of EPROM, PIN3 of MK009 & PIN3 of MK008
PIN3 : PIN10 of EPROM, PIN12 of MK009, PIN12 of MK008
PIN4 : PIN9 of EPROM, PIN11 of MK009 & PIN11 of MK008
PIN5 : PIN2 of MK009 & PIN2 of MK008
PIN6 : PIN8 of EPROM, PIN10 of MK009 & PIN10 of MK008
PIN7 : PIN30 of MK009 & PIN30 of MK008
PIN8 : PIN16 of EPROM, PIN16 of MK009 & PIN16 of MK008, PIN14 of HY6264P, PIN 8 & 15 of 139, PIN8 of 2nd 174, PIN 8 & 15 of 153
PIN9 : PIN5 of 139, PIN9 of 2nd 174
PIN10 : PIN31 of MK009, PIN31 of MK008
PIN11 : PIN9 of MK009, PIN9 of MK008
PIN12 : PIN1 of MK009. PIN1 of MK008
PIN13 : PIN8 of MK009, PIN8 of MK008
PIN14 : PIN7 of MK009, PIN7 of MK008
PIN15 : NONE
PIN16 : PIN32 of MK009, PIN32 of MK008, PIN1, 26 & 28 of HY6264P, PIN16 of 139, PIN16 of 2nd 174, PIN16 of 153

9138 (139)

PIN1 : CART PIN
PIN2 : PIN32 of MK009, PIN32 of MK008, PIN1, 26 & 28 of HY6264P
PIN3 : CART CONNECTOR
PIN4 : NONE
PIN5 : PIN9 of both 174
PIN6 : NONE
PIN7 : PIN24 of MK009, PIN24 of MK008
PIN8 : PIN16 of MK009, PIN16 of MK008, PIN14 of HY6264P, PIN8 of both 174, PIN8 & 15 of 153.
PIN9 : PIN20 EPPROM
PIN10 : NONE
PIN11 : PIN22 of MK009
PIN12 : PIN22 of MK008
PIN13 : PIN5 of 2nd 274
PIN14 : PIN2 of 2nd 174
PIN15 : PIN14 of EPROM, PIN8 of 1st 174, PIN16 of MK009, PIN16 of MK008, PIN14 of HY6264P, PIN8 of 2nd 174, PIN8 & 15 of 153
PIN16 : PIN16 of both 174, PIN16 of 153, PIN32 of MK009, PIN32 of MK008, PIN1 & 26 & 28 of HY6264P

9122VG (174)

PIN1 : NONE
PIN2 : PIN14 of 139
PIN3 : PIN25 of EPPROM, PIN27 of MK009, PIN27 of MK008
PIN4 : PIN24 EPPROM, PIN26 of MK009, PIN26 of MK008
PIN5 : PIN13 of 139
PIN6 : PIN21 of EPPROM, PIN23 of MK009, PIN23 of MK008
PIN7 : NONE
PIN8 : PIN14 of EPPROM,PIN16 of MK009, PIN16 of MK008, PIN14 of HY6264P, PIN8 & PIN15 of 139, PIN8 & PIN15 of 153
PIN9 : PIN9 of 1st 174, PIN5 of 139
PIN10 : PIN14 of 9128
PIN11 : PIN22 of EPPROM, PIN25 of MK009, PIN25 of MK008
PIN12 : PIN11 & PIN13 of 153
PIN13 : PIN2 of EPROM, PIN4 of MK009, PIN4 of MK008
PIN14 : PIN26 of EPROM, PIN28 of MK009, PIN28 of MK008
PIN15 : NONE
PIN16 : PIN1 of both 174, PIN1 of 139, PIN1 of 153, PIN28 of EPROM, PIN32 of MK009, PIN32 of MK008, PIN1, PIN26 & 28 of HY6264P

9128 (153)

PIN1 : PIN7 of 2nd 174
PIN2 : PIN15 of 2nd 174
PIN3 : PIN23 of HY6264P
PIN4 : PIN23 of HY6264P
PIN5 : PIN21 of HY6264P
PIN6 : PIN21 of HY6264P
PIN7 : CART PIN
PIN8 : PIN8 of 1st 174, PIN15 of 139, PIN8 of 2nd 174, PIN14 of EPROM, PIN16 of MK009, PIN16 of MK008, PIN14 of HY6264P
PIN9 : PIN27 of EPROM, PIN29 of MK009, PIN29 of MK008
PIN10 : NONE
PIN11 : PIN12 of 2nd 174
PIN12 : NONE
PIN13 : PIN12 of 2nd 174
PIN14 : PIN10 of 2nd 174
PIN15 : PIN8 of both 174, PIN8 of 139, PIN14 of EPROM, PIN16 of MK009, PIN16 of MK008, PIN14 of HY2624P
PIN16 : PIN16 of both 174, PIN16 of 139, PIN28 of EPROM, PIN32 of MK009, PIN32 of MK008, PIN1, 26 & 28 of HY2624P
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#206975)
That's definitely "just" mapper an instance of the same hardware that's on 235. The existing dumping scripts should work... as long as the Kazzo is keeping the "clear the registers" pin from resetting things.

Did you ever look at the resulting file you got with a hex editor or something? If you have a bad dump, it should obviously repeat every 16 or 32 KiB. And you'll probably need to remove the resistor?

If you have a good dump, we may need to figure out how to adjust things in an emulator so that your multicart can be run correctly.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207004)
lidnariq wrote:
That's definitely "just" mapper an instance of the same hardware that's on 235. The existing dumping scripts should work... as long as the Kazzo is keeping the "clear the registers" pin from resetting things.

Did you ever look at the resulting file you got with a hex editor or something? If you have a bad dump, it should obviously repeat every 16 or 32 KiB. And you'll probably need to remove the resistor?

If you have a good dump, we may need to figure out how to adjust things in an emulator so that your multicart can be run correctly.


I will try this as soon as I can !

Regarding the resistor, it is that thing? (See attachment) Do I need to just desolder one pin and try to dump? Do I need to desolder the resistor itself and solder something else to keep the conductivity of the circuit?
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207009)
labatt24 wrote:
Regarding the resistor, it is that thing? (See attachment) Do I need to just desolder one pin and try to dump? Do I need to desolder the resistor itself and solder something else to keep the conductivity of the circuit?
The circuitry there should look something like:
Code:
M2 --|>|---+-+--- both 74ls174 pin 1
           | |
           C R
           | |
           gnd
If so, removing the resistor (desoldering one side is fine) should let the dumper work correctly. (the cartridge won't go back to the menu when you press the reset button until you resolder it)
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207133)
lidnariq wrote:
labatt24 wrote:
Regarding the resistor, it is that thing? (See attachment) Do I need to just desolder one pin and try to dump? Do I need to desolder the resistor itself and solder something else to keep the conductivity of the circuit?
The circuitry there should look something like:
Code:
M2 --|>|---+-+--- both 74ls174 pin 1
           | |
           C R
           | |
           gnd
If so, removing the resistor (desoldering one side is fine) should let the dumper work correctly. (the cartridge won't go back to the menu when you press the reset button until you resolder it)

Alright, I removed one side of the resistor. I tried a dump (4MB) and no chance. Here in attachment the first 32kib of the dump using the very first script you gave me.

Do you think I need to remove one side of the diode also?
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207134)
Oh dear. That's a big pile of nothing (hence why it compressed so well)

At best, that's the memory region that would correspond to the empty space in the PCB, but ... while the resistor-diode-capacitor was still present, it should have shown the contents of the ROM labeled "MK008".

Does the full 4 MiB dump also compress to a similarly high ratio?
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207135)
lidnariq wrote:
Oh dear. That's a big pile of nothing (hence why it compressed so well)

At best, that's the memory region that would correspond to the empty space in the PCB, but ... while the resistor-diode-capacitor was still present, it should have shown the contents of the ROM labeled "MK008".

Does the full 4 MiB dump also compress to a similarly high ratio?


I checked with the 4MB and I have the same info as the 32kib with the hex editor.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207136)
I don't see a particularly plausible way that all three ROMs would die at the same time, in the same way.

I'd vaguely wonder if the 74'139 is working?

Do you have a logic tester / voltmeter / resistor+LED of some sort? If so, you could test whether certain pins are high or low when go to dump it.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207138)
lidnariq wrote:
I don't see a particularly plausible way that all three ROMs would die at the same time, in the same way.

I'd vaguely wonder if the 74'139 is working?

Do you have a logic tester / voltmeter / resistor+LED of some sort? If so, you could test whether certain pins are high or low when go to dump it.

Yes, I do have a voltmeter. I can give it a try also. But, I'm not sure that some ROMs are deads because this cart was working before doing the dump things.

Can you confirm which script I need to use? (the final one).

I removed one side of the resistor and one side of the diode to be sure to have a good dump.

Thanks in advance !!
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207139)
lidnariq wrote:
I don't see a particularly plausible way that all three ROMs would die at the same time, in the same way.

I'd vaguely wonder if the 74'139 is working?

Do you have a logic tester / voltmeter / resistor+LED of some sort? If so, you could test whether certain pins are high or low when go to dump it.

I have something !!!! I just read on the Kazzo board "Famicom cartridge front side"...... I insert the cart correctly. Here in attachment the first 32kib.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207140)
Oh, yeah, that's totally plausible. I see part of a menu there.

The 4 MiB dump probably won't work in an emulator, but if you zip it up, is it approximately 1.5MiB in size?
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207141)
lidnariq wrote:
Oh, yeah, that's totally plausible. I see part of a menu there.

The 4 MiB dump probably won't work in an emulator, but if you zip it up, is it approximately 1.5MiB in size?

In a zip, it's 748Ko. Picture in attachment.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207142)
Hmm. That's a little better compression that I would have naively guessed. But not wholly out of the range of possibility...

At this point, I think it's likely that you have a good dump, but what we don't have is a good way to get you an emulator that supports it.

I don't suppose you're up to building an emulator from source?
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207143)
lidnariq wrote:
Oh, yeah, that's totally plausible. I see part of a menu there.

The 4 MiB dump probably won't work in an emulator, but if you zip it up, is it approximately 1.5MiB in size?

UH THIS IS ODD. I tried the zipped from and see what I have : a 100-in-1 version ??? The cart is a 700-in-1! I'm really surprised.

EDIT : I'm using FCEUX. Already tried Nestopia which doesnt work with the zipped ROM.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207144)
We already know that MK008 ROM exists in a different multicart that's using the same 74xxx ICs; it clearly reads from the UVEPROM to determine how many entries to display.

The "canonical" memory layout for mapper 235 (which is not the same as either your cart nor SkinnyV's in the link above) uses different mask ROMs in slots "0" and "2" instead of "0" and "3" (and in your case, also "1").

So the code inside MK008 clearly involves switching to that UVEPROM to choose how many entries to display.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207145)
Oh, huh, Nestopia's got some funny code going on with four different variants of what it calles Golden Game 260-in-1, handling up to 4 different sizes of PRG:
Code:
            selector
            (
               prg.Source().Size() == SIZE_1024K ? 0 :
               prg.Source().Size() == SIZE_2048K ? 1 :
               prg.Source().Size() == SIZE_3072K ? 2 : 3
            )
[...]
               static const byte slots[4][4][2] =
               {
                  { {0x00,0}, {0x00,1}, {0x00,1}, {0x00,1} },
                  { {0x00,0}, {0x00,1}, {0x20,0}, {0x00,1} },
                  { {0x00,0}, {0x00,1}, {0x20,0}, {0x40,0} },
                  { {0x00,0}, {0x20,0}, {0x40,0}, {0x60,0} }
               };

               uint bank = slots[selector][address >> 8 & 0x3][0] | (address & 0x1F);


I ... don't think I see something here that obviously corresponds to your hardware, however?

Although ... given what I see above, I'd naively assume that a 4 MiB image like you have should work?

Unless the problem is that Nestopia needs a NES2.0 header for a 4 MiB image? Try changing the header in a hex editor from
4e 45 53 1a 00 00 b2 e0 00 00 00 00 00 00 00 00 to
4e 45 53 1a 00 00 b2 e8 00 01 00 07 00 00 00 00
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207146)
lidnariq wrote:
Oh, huh, Nestopia's got some funny code going on with four different variants of what it calles Golden Game 260-in-1, handling up to 4 different sizes of PRG:
Code:
            selector
            (
               prg.Source().Size() == SIZE_1024K ? 0 :
               prg.Source().Size() == SIZE_2048K ? 1 :
               prg.Source().Size() == SIZE_3072K ? 2 : 3
            )
[...]
               static const byte slots[4][4][2] =
               {
                  { {0x00,0}, {0x00,1}, {0x00,1}, {0x00,1} },
                  { {0x00,0}, {0x00,1}, {0x20,0}, {0x00,1} },
                  { {0x00,0}, {0x00,1}, {0x20,0}, {0x40,0} },
                  { {0x00,0}, {0x20,0}, {0x40,0}, {0x60,0} }
               };

               uint bank = slots[selector][address >> 8 & 0x3][0] | (address & 0x1F);


I ... don't think I see something here that obviously corresponds to your hardware, however?

Although ... given what I see above, I'd naively assume that a 4 MiB image like you have should work?

It seems I can't run anything with the ROM. I just did a second dump with :

Code:
 board <- {
   mappernum = 235,
   cpu_rom = {
      size_base = 4194304, 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);
  }
}


Now the ROM is 210-in-1 with exactly 212 games. Again there, I can't play games : it reboot or pixelized.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207147)
lidnariq wrote:
Oh, huh, Nestopia's got some funny code going on with four different variants of what it calles Golden Game 260-in-1, handling up to 4 different sizes of PRG:
Code:
            selector
            (
               prg.Source().Size() == SIZE_1024K ? 0 :
               prg.Source().Size() == SIZE_2048K ? 1 :
               prg.Source().Size() == SIZE_3072K ? 2 : 3
            )
[...]
               static const byte slots[4][4][2] =
               {
                  { {0x00,0}, {0x00,1}, {0x00,1}, {0x00,1} },
                  { {0x00,0}, {0x00,1}, {0x20,0}, {0x00,1} },
                  { {0x00,0}, {0x00,1}, {0x20,0}, {0x40,0} },
                  { {0x00,0}, {0x20,0}, {0x40,0}, {0x60,0} }
               };

               uint bank = slots[selector][address >> 8 & 0x3][0] | (address & 0x1F);


I ... don't think I see something here that obviously corresponds to your hardware, however?

Although ... given what I see above, I'd naively assume that a 4 MiB image like you have should work?

Unless the problem is that Nestopia needs a NES2.0 header for a 4 MiB image? Try changing the header in a hex editor from
4e 45 53 1a 00 00 b2 e0 00 00 00 00 00 00 00 00 to
4e 45 53 1a 00 00 b2 e8 00 01 00 07 00 00 00 00

Now I am able to run the 4MB ROM with FCEUX! But still not able to play games.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207162)
labatt24 wrote:
lidnariq wrote:
Oh, huh, Nestopia's got some funny code going on with four different variants of what it calles Golden Game 260-in-1, handling up to 4 different sizes of PRG:
Code:
            selector
            (
               prg.Source().Size() == SIZE_1024K ? 0 :
               prg.Source().Size() == SIZE_2048K ? 1 :
               prg.Source().Size() == SIZE_3072K ? 2 : 3
            )
[...]
               static const byte slots[4][4][2] =
               {
                  { {0x00,0}, {0x00,1}, {0x00,1}, {0x00,1} },
                  { {0x00,0}, {0x00,1}, {0x20,0}, {0x00,1} },
                  { {0x00,0}, {0x00,1}, {0x20,0}, {0x40,0} },
                  { {0x00,0}, {0x20,0}, {0x40,0}, {0x60,0} }
               };

               uint bank = slots[selector][address >> 8 & 0x3][0] | (address & 0x1F);


I ... don't think I see something here that obviously corresponds to your hardware, however?

Although ... given what I see above, I'd naively assume that a 4 MiB image like you have should work?

Unless the problem is that Nestopia needs a NES2.0 header for a 4 MiB image? Try changing the header in a hex editor from
4e 45 53 1a 00 00 b2 e0 00 00 00 00 00 00 00 00 to
4e 45 53 1a 00 00 b2 e8 00 01 00 07 00 00 00 00

Now I am able to run the 4MB ROM with FCEUX! But still not able to play games.


I have some difficulty using the PM system (mails stuck in the Outbox). I will document things here.

Following the recommandation of lidnariq :
Try replacing "0xF800" with "0xF000"

It seems it did the work! Now I can play games. The ROM size in the ZIP is 2MB. The odd thing here is the cart is 700-in-1 and actually I have 210-in-1 BUT in a working condition. The 700-in-1 is exactly the same thing than the golden game 260-in-1 but without a music menu and without visual (only a black background, purple color menu and the mention 700-in-1 center upper.)

It is possible the cart is using a different mapper ?

And quick question, what is a mapper? It is determined by the hardware itself?
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207165)
Please see https://wiki.nesdev.com/w/index.php/Mapper

It is a number defined by the emulation community that identifies the hardware on the cartridge board.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207173)
labatt24 wrote:
I have some difficulty using the PM system (mails stuck in the Outbox).
Messages stay in the outbox until the recipient reads them; then they move automatically to "Sent"

Quote:
It seems it did the work! Now I can play games. The ROM size in the ZIP is 2MB. The odd thing here is the cart is 700-in-1 and actually I have 210-in-1 BUT in a working condition. The 700-in-1 is exactly the same thing than the golden game 260-in-1 but without a music menu and without visual (only a black background, purple color menu and the mention 700-in-1 center upper.)

It is possible the cart is using a different mapper ?
No, given Nestopia's source I'm pretty certain what you have is (pedantically) mapper 235.

However, mapper 235 is a bit of a mess. The 74xxx ICs seem to be always the same, as we've said ... but each of the four ROM slots can vary. Slot "0" has to be populated, but the other 3 could be, or could not be. So there's eight different variants, assuming it's just using 1 MiB ROMs. (One with one ROM, one with four ROMs, and three each with two or three ROMs)

This is one of those situations where the iNES / NES2.0 format shows how it's a bit of a bad match. Both UNIF and MAME's encoding would instead store the separate ROMs as separate blocks, and the emulator could just know whether each of the four slots had a ROM without the file needing explicit padding.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207231)
lidnariq wrote:
labatt24 wrote:
I have some difficulty using the PM system (mails stuck in the Outbox).
Messages stay in the outbox until the recipient reads them; then they move automatically to "Sent"

Quote:
It seems it did the work! Now I can play games. The ROM size in the ZIP is 2MB. The odd thing here is the cart is 700-in-1 and actually I have 210-in-1 BUT in a working condition. The 700-in-1 is exactly the same thing than the golden game 260-in-1 but without a music menu and without visual (only a black background, purple color menu and the mention 700-in-1 center upper.)

It is possible the cart is using a different mapper ?
No, given Nestopia's source I'm pretty certain what you have is (pedantically) mapper 235.

However, mapper 235 is a bit of a mess. The 74xxx ICs seem to be always the same, as we've said ... but each of the four ROM slots can vary. Slot "0" has to be populated, but the other 3 could be, or could not be. So there's eight different variants, assuming it's just using 1 MiB ROMs. (One with one ROM, one with four ROMs, and three each with two or three ROMs)

This is one of those situations where the iNES / NES2.0 format shows how it's a bit of a bad match. Both UNIF and MAME's encoding would instead store the separate ROMs as separate blocks, and the emulator could just know whether each of the four slots had a ROM without the file needing explicit padding.

Understood for the PM system.

The most important is we did a correct dump of this cart!

Since I don't have skill with those scripts, I don't know what to search on the net.

If you find something just tell me!

If you think I can do something, again there tell me!

Thanks you,

Guy
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207249)
I quicky cross-referenced the broken dump (the first half of each 32 KiB contained a copy of the second half, i.e. "PRG A14 was kept high during dumping") you'd sent me against everything in GoodNES, and found:

* The first 2 MiB are a perfect match for the first 2 MiB of what's called "260-in-1 [p1][!]"
* The first 1 MiB is ALSO a perfect match for what's called "150-in-1 (Mapper 43) [p1][!]" and "150-in-1 [a1][p1][!]" — clearly the "MK008" ROM
* The last 16 KiB are a match for a random subset of what's called "Super Mario Bros 2J + SMB1 Chars (Hack)" (starting at PRG offset 0x70000)
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207321)
lidnariq wrote:
I quicky cross-referenced the broken dump (the first half of each 32 KiB contained a copy of the second half, i.e. "PRG A14 was kept high during dumping") you'd sent me against everything in GoodNES, and found:

* The first 2 MiB are a perfect match for the first 2 MiB of what's called "260-in-1 [p1][!]"
* The first 1 MiB is ALSO a perfect match for what's called "150-in-1 (Mapper 43) [p1][!]" and "150-in-1 [a1][p1][!]" — clearly the "MK008" ROM
* The last 16 KiB are a match for a random subset of what's called "Super Mario Bros 2J + SMB1 Chars (Hack)" (starting at PRG offset 0x70000)

Seems logic. So there is 1 MiB somewhere that is not included in the .nes rom? It is a limitation of Kazzo scripts? Sorry for my ignorance!
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207324)
Of the 4 MiB of the partial dump you sent me, the first 2 MiB are accounted for; the next 1 MiB is what Kazzo sees as open bus ($FF), and the last MiB are the UVEPROM repeated to fill 1 MiB.

Unfortunately(?) I only have 16 KiB of the contents of the UVEPROM, and unlike the existing dumps of MK008/MK009, it's weirdly aligned (i.e. the 16 KiB I see, despite coming from a region where A14 is high, correspond to a previous dump in a ROM where A14 is low), so I don't actually have any guess what's in the half that I haven't received.

BUT: I wouldn't be surprised if it turns out that the 27C256 actually contains two copies of the same 16 KiB of source data.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207354)
lidnariq wrote:
Of the 4 MiB of the partial dump you sent me, the first 2 MiB are accounted for; the next 1 MiB is what Kazzo sees as open bus ($FF), and the last MiB are the UVEPROM repeated to fill 1 MiB.

Unfortunately(?) I only have 16 KiB of the contents of the UVEPROM, and unlike the existing dumps of MK008/MK009, it's weirdly aligned (i.e. the 16 KiB I see, despite coming from a region where A14 is high, correspond to a previous dump in a ROM where A14 is low), so I don't actually have any guess what's in the half that I haven't received.

BUT: I wouldn't be surprised if it turns out that the 27C256 actually contains two copies of the same 16 KiB of source data.

Do you think that thing could affect the dump? It seems connected to the 27C256.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#207359)
labatt24 wrote:
Do you think that thing could affect the dump? It seems connected to the 27C256.
The orange thing in the red circle is a capacitor; it's there for the 74'174s. Any connections should only be to the power supply pins (14 and 28).

I mean, I only have the bad dump, but given that the first 2 MiB of the dump you have now works and the bad dump you sent me doesn't, I have to assume that whatever you have right now is a good dump of the 27C256 also.
Re: Hacked Famicom Cartridge cart - Need info for dump
by on (#237816)
try this code
Code:
board <- {
   mappernum = 235,
   cpu_rom = {
      size_base = 0x4000, size_max = 4194304, banksize = 0x4000
   },
   ppu_rom = {
      size_base = 0, size_max = 0, banksize = 0
   },
   ppu_ramfind = false, vram_mirrorfind = true
};

function cpu_dump(d, pagesize, banksize) {
   local RomIndex = 0;
   local RomUpLow = 0;
   local ReadAddr = 0x4000;
   local pageindex = 0;
   for(local i = 0; i < pagesize; i += 1){
      pageindex = i / 2; //or  just i ?
      //http://wiki.nesdev.com/w/index.php/INES_Mapper_235
      if ((i / 4) == 0){
         RomIndex = 0;
      } else if ((i / 4) == 1){
         RomIndex = 2;
      } else if ((i / 4) == 2){
         RomIndex = 1;
      } else if ((i / 4) == 3){
         RomIndex = 3;
      };
      if ((i % 2) == 0) {
         ReadAddr = 0x8000;
         RomUpLow = 0;
      }else{
         ReadAddr = 0xC000;
         RomUpLow = 1;
      };
      //http://forums.nesdev.com/viewtopic.php?f=2&t=16551
      //cpu_write(d, 0xF800 | (pageindex & 31) | ((pageindex << 3) & 0x300, pageindex);
      cpu_write(d, 0xF800 | ((RomUpLow << 13) & 0x1000) | ((RomIndex << 8) & 0x0300) | (pageindex & 0x1F), 0);
      if ((i % 2) == 0) {
         cpu_read(d, 0x8000, banksize);
      }else{
         cpu_read(d, 0xC000, banksize);
      };
   }
}