Kazzo USB rom dumper / dev cart programmer
Moderator: Moderators
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Kazzo USB rom dumper / dev cart programmer
If it's always the mapper chip that's affected and never the ROM chips, I suspect that the culprit must be on one of the lines that only goes to the mapper chip. Does the Kazzo raise and lower the cartridge connector's M2 line at the same rate as on the NES, or at a higher rate? How are the IRQ and CIRAM lines connected?
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Kazzo USB rom dumper / dev cart programmer
FWIW, I was never able to make sense of the original firmware enough to answer detailed questions like this which is why I started fresh with my own implementation.NewRisingSun wrote:Does the Kazzo raise and lower the cartridge connector's M2 line at the same rate as on the NES, or at a higher rate? How are the IRQ and CIRAM lines connected?
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Re: Kazzo USB rom dumper / dev cart programmer
Isn't the kazzo lacking the M2 clock anyway? It has been said that some cartridges using M2 for a reset detection weren't dumpable as-is with a kazzo.
Re: Kazzo USB rom dumper / dev cart programmer
Control over the M2 pin is present, but is just manually controlled, not a clock. (Control is necessary in order to access addresses below $8000)
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Kazzo USB rom dumper / dev cart programmer
So can a mapper IC heat up from waiting for an M2 cycle that never occurs?
Re: Kazzo USB rom dumper / dev cart programmer
I don't see an obvious way for that to happen. (Not saying it can't, but it'd involve extra effort for no obvious benefit)
Re: Kazzo USB rom dumper / dev cart programmer
It looks like hot swapping is part of the reason. I just checked some of the cartridges for which I had seen this behavior by inserting them in the device before plugging the USB and while it did not start to overheat on Earthworm Jim 2 (Super Game), it did manifest itself again with Kaiser Doki Doki Panic (PAL overheating slowly but surely).
Looks like I'm kind of responsible there. I expected the device to not provide power to the cartridge connector in idle mode... I was definitely a fool for believing that (but Kaiser DDP still implies that something not right is happening).
Maybe it's worth pointing out those issues in the documentation, by the way.
Looks like I'm kind of responsible there. I expected the device to not provide power to the cartridge connector in idle mode... I was definitely a fool for believing that (but Kaiser DDP still implies that something not right is happening).
Maybe it's worth pointing out those issues in the documentation, by the way.
Re: Kazzo USB rom dumper / dev cart programmer
Anyone got a dumping script for mapper 184 (Atlantis no Nazo)? Or Sunsoft-1 in general? Thanks!
Re: Kazzo USB rom dumper / dev cart programmer
Try this modified version of the CNROM script:
Code: Select all
board <- {
mappernum = 184,
cpu_rom = {
size_base = 0x8000, size_max = 0x8000
banksize = 0x8000
},
ppu_rom= {
size_base = 0x2000, size_max = 0x8000,
banksize = 0x1000
},
ppu_ramfind = false, vram_mirrorfind = true
};
function cpu_dump(d, pagesize, banksize)
{
cpu_read(d, 0x8000, 0x4000);
cpu_read(d, 0xc000, 0x4000);
}
function ppu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i++){
cpu_write(d, 0x6000, i);
ppu_read(d, 0, banksize);
}
}
Re: Kazzo USB rom dumper / dev cart programmer
Hej
It gives me the correct rom size and checksum.
Here is my script to dump Akumajou Densetsu:RPGMaster57 wrote:Is there a way to use the Kazzo to dump Akumajou Densetsu? I cannot find a script for VRC6a. I placed a support ticket on the website for InfiniteNESLives, and I was sent a link to a VRC6a script modified from the VRC6b script. Unfortunately, whenever I try to dump the game, I get this error message that is similar whether I use the VRC6a script or VRC6b script. I have included the error message at the bottom. What can I do to dump this game? I apologize if I am posting in the wrong place; I am new here.
m_database not found
AN ERROR HAS OCCURED [the index 'ppu_rom' does not exist]
CALLSTACK
*FUNCTION [dump()] dumpcore.nut line [22]
LOCALS
[ppuarea_memory] NULL
[vram] 0
[increase_ppu] 1
[increase_cpu] 11
[mappernum] 26
[script] "vrc6a.af"
[d] USERPOINTER
[this] TABLE
Code: Select all
board <- {
mappernum = 24, vram_mirrorfind = false, ppu_ramfind = false,
cpu_rom = {
size_base = 0x40000, size_max = 0x40000,
banksize = 0x2000,
},
ppu_rom = {
size_base = 0x20000, size_max = 0x20000,
banksize = 0x0400,
}
};
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i += 1){
cpu_write(d, 0xc000, i)
cpu_read(d, 0xc000, banksize)
}
}
function ppu_dump(d, pagesize, banksize)
{
cpu_write(d, 0xb003, 0x0020)
for(local i = 0; i < pagesize; i += 1){
cpu_write(d, 0xd000, i)
ppu_read(d, 0, banksize)
}
}
Re: Kazzo USB rom dumper / dev cart programmer
The PRG dumps fine but CHR is all messed up. I'm trying to make a Mario's Treasure Hunt (Atlantis no Nazo) on a Kanshakudama Nage Kantarou no Toukaidou Gojuusan Tsugi board.
Since the board had glob tops only I used a CNROM board and connected the Sunsoft-1 as described on the Wiki.
https://wiki.nesdev.com/w/index.php/Sunsoft_1_pinout
With no success so far. Attached the CHR dump of the cart + original for comparison.
Thanks for the help!
Since the board had glob tops only I used a CNROM board and connected the Sunsoft-1 as described on the Wiki.
https://wiki.nesdev.com/w/index.php/Sunsoft_1_pinout
With no success so far. Attached the CHR dump of the cart + original for comparison.
Thanks for the help!
- Attachments
-
- CHR.zip
- (11.15 KiB) Downloaded 325 times
Re: Kazzo USB rom dumper / dev cart programmer
... Er, 12K? Is that truncated?
Looking at those two as picture data, I'm not convinced they're the same original dump at all. Dividing "chroriginal" into twelve 1 KiB banks 0x0 through 0xB, "chrdump" contains 4, 5m, 6m, 7m, 0, 1, 2, 3, 0, 1, 2, 3.
Looking at those two as picture data, I'm not convinced they're the same original dump at all. Dividing "chroriginal" into twelve 1 KiB banks 0x0 through 0xB, "chrdump" contains 4, 5m, 6m, 7m, 0, 1, 2, 3, 0, 1, 2, 3.
Re: Kazzo USB rom dumper / dev cart programmer
Oh, poop. Yeah.
chroriginal.bin is the CHR Data found from Mario's Treasure Hunt while chrdump.bin is the CHR dumped with Kazzo using your script (with the pinout from Wiki).
Either way, after looking at the Atlantis no Nazo PCB on BootGod I somehow managed this schematic working fine for Atlantis no Nazo. Tested and dumped the cart again using my schematics. All data is equal and the game works fine.
Looks like CHR A12/A14/A13 are different here as supposed to be A14/A13/A12 as seen on the Wiki.
chroriginal.bin is the CHR Data found from Mario's Treasure Hunt while chrdump.bin is the CHR dumped with Kazzo using your script (with the pinout from Wiki).
Either way, after looking at the Atlantis no Nazo PCB on BootGod I somehow managed this schematic working fine for Atlantis no Nazo. Tested and dumped the cart again using my schematics. All data is equal and the game works fine.
Code: Select all
.---\/---.
PPU A12 -> |01 16| -- VCC
M2 -> |02 15| -> CHR A12
PRG /CE -> |03 14| -> CHR A14
PRG A13 -> |04 13| -> CHR A13
PRG A14 -> |05 12| <- CPU R/W
PRG D5 -> |06 11| <- PRG D0
PRG D4 -> |07 10| <- PRG D1
GND -- |08 09| <- PRG D2
`--------'
Re: Kazzo USB rom dumper / dev cart programmer
Well, that's clearly my fault.
Unfortunately, I can't find where I placed the old trace data when I made the page, so I can't even figure out how I made the mistake.
Unfortunately, I can't find where I placed the old trace data when I made the page, so I can't even figure out how I made the mistake.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Kazzo USB rom dumper / dev cart programmer
What exactly does that mean? I am trying to have a multicart dumped, with the outer bank register in the $6xxx range, that keeps mysteriously flipping back to one specific outer bank register value regardless of what I write to it. Could this be caused by a lack of explicit M2 control? Maybe because the hardware falsely detects a Reset? If so, what would I have to write into the Kazzo dumping script to raise and lower the M2 pin correctly?lidnariq wrote:Control over the M2 pin is present, but is just manually controlled, not a clock. (Control is necessary in order to access addresses below $8000)