Hacked Famicom Cartridge cart - Need info for dump
Moderator: Moderators
Re: Hacked Famicom Cartridge cart - Need info for dump
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?
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
I checked with the 4MB and I have the same info as the 32kib with the hex editor.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?
Re: Hacked Famicom Cartridge cart - Need info for dump
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'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
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.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.
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
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.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.
- Attachments
-
- 700-in.1_32kib.zip
- (11.61 KiB) Downloaded 268 times
Re: Hacked Famicom Cartridge cart - Need info for dump
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?
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
In a zip, it's 748Ko. Picture in attachment.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?
Re: Hacked Famicom Cartridge cart - Need info for dump
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?
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
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.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?
EDIT : I'm using FCEUX. Already tried Nestopia which doesnt work with the zipped ROM.
Re: Hacked Famicom Cartridge cart - Need info for dump
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.
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
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:
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
Code: Select all
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);
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
It seems I can't run anything with the ROM. I just did a second dump with :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:I ... don't think I see something here that obviously corresponds to your hardware, however?Code: Select all
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);
Although ... given what I see above, I'd naively assume that a 4 MiB image like you have should work?
Code: Select all
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);
}
}
Re: Hacked Famicom Cartridge cart - Need info for dump
Now I am able to run the 4MB ROM with FCEUX! But still not able to play games.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:I ... don't think I see something here that obviously corresponds to your hardware, however?Code: Select all
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);
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
I have some difficulty using the PM system (mails stuck in the Outbox). I will document things here.labatt24 wrote:Now I am able to run the 4MB ROM with FCEUX! But still not able to play games.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:I ... don't think I see something here that obviously corresponds to your hardware, however?Code: Select all
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);
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
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
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.
It is a number defined by the emulation community that identifies the hardware on the cartridge board.