Kazzo USB rom dumper / dev cart programmer

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

It means that the Kazzo's AVR's pins are just directly controlled by the native instructions for doing so, and the pin M2 is modified in software whenever it wants to read or write from memory below $8000. (Probably also for above $8000, too, since e.g. N108 seems to rely on M2 as its clock instead of /ROMSEL)

The distinction I'm making is that M2 isn't continuously running, as it does in the actual NES/Famicom; reads and writes are effectively asynchronous in the Kazzo but synchronous in the NES.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by NewRisingSun »

That means that multicarts with M2-based reset detection cannot be dumped fully, then, at least unless somebody modifys the Kazzo firmware to allow "reading synchronously".
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

Correct. This has come up in several threads here (e.g.); people have disabled the reset detector in order to get a dump.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by NewRisingSun »

I suppose the CopyNES drives the M2 signal normally, given that it's a modified NES, and thus can be used for dumping such multicarts?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

Yeah, the CopyNES doesn't modify M2. I believe all the internal operations cycles on the copyNES look like access to $4800-$4FFF. This is fine with most carts, although is a problem for the N163.

When BootGod asked, I suggested that he change the corresponding control line to A10 instead of A11, moving the copyNES's active range to $4400-$47FF and $4C00-$4FFF. (Rewiring and re-building the firmware was necessary). No mappers that we yet knew of wholly collide with that functional range, so...
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by NewRisingSun »

Just reporting that the multicart in question has been successfully dumped on the first try using a CopyNES.
werewolfslayr925
Posts: 40
Joined: Sat Oct 02, 2010 5:49 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by werewolfslayr925 »

Sorry for the sudden change of subject. I'm trying to figure out a proper script for dumping Urusei Yatsura - Lum no Wedding Bell. From what I've gathered snooping around the wiki and the forums, it's unique in its design but similar to a CNROM cart. I've tried both CNROM and GNROM to little avail: the PRG dumps correctly according to bootgod's database, but the CHR gives a bad checksum. Perhaps it's possible to use Arantius' CNROM script as a base for making a working JF-10/mapper 101 script?

Code: Select all

board <- {
	mappernum = 3,
	cpu_rom = {
		size_base = 0x8000, size_max = 0x8000
		banksize = 0x8000
	},
	ppu_rom= {
		size_base = 0x8000, size_max = 0x8000,
		banksize = 0x2000
	},
	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)
{
	local security = 0; //0,1,2,3 or don't care
	security = security << 4;
	for(local i = 0; i < pagesize; i++)
       {
		cpu_write(d, 0x8000, security | i);
		ppu_read(d, 0, banksize);
	}
}

function program_initalize(d, cpu_banksize, ppu_banksize)
{
	cpu_write(d, 0x8000, 0x30);
	cpu_command(d, 0, 0x8000, cpu_banksize);
	cpu_command(d, 0x02aa, 0xc000, cpu_banksize);
	cpu_command(d, 0x0555, 0xc000, cpu_banksize);
	ppu_command(d, 0, 0x0000, ppu_banksize);
	ppu_command(d, 0x02aa, 0x0000, ppu_banksize);
	ppu_command(d, 0x0555, 0x0000, ppu_banksize);
}

function cpu_transfer(d, start, end, cpu_banksize)
	{
	if (cpu_banksize == 0x8000)
                {
		        cpu_program(d, 0x8000, 0x4000);
	        }
	cpu_program(d, 0xc000, 0x4000);
}

function ppu_transfer(d, start, end, ppu_banksize)

        {
	for(local i = start; i < end; i++)
        {
		cpu_write(d, 0x8000, 0xf0 | i);
		ppu_program(d, 0x0000, ppu_banksize);
	}
}
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

You just posted the CNROM script?

Mapper 87 should be something like

Code: Select all

oard <- {
   mappernum = 87,
   cpu_rom = {
      size_base = 0x8000, size_max = 0x8000
      banksize = 0x8000
   },
   ppu_rom= {
      size_base = 0x8000, size_max = 0x8000,
      banksize = 0x2000
   },
   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 & 2) >> 1) | ((i & 1) << 1));
      ppu_read(d, 0, banksize);
   }
}
edit: fix cpu_write address
Last edited by lidnariq on Tue Jun 19, 2018 9:00 pm, edited 1 time in total.
werewolfslayr925
Posts: 40
Joined: Sat Oct 02, 2010 5:49 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by werewolfslayr925 »

lidnariq wrote:You just posted the CNROM script?
Yeah, sorry. I thought that may have been a bit unclear. I was posting it just for easy reference/convenience. I tried the script you posted and it yielded a bootable ROM. However, when the first level starts the background are all messed up. I tried combining that script with INL's/tepples' advice found here and changed the single write command at the bottom of the code to 0x6000. This yielded a working ROM without any glitches! Here's the full code for the sole JF-10 / mapper 101 cart:

Code: Select all

board <- {
   mappernum = 101,
   cpu_rom = {
      size_base = 0x8000, size_max = 0x8000
      banksize = 0x8000
   },
   ppu_rom= {
      size_base = 0x8000, size_max = 0x8000,
      banksize = 0x2000
   },
   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 & 2) >> 1) | ((i & 1) << 1));
      ppu_read(d, 0, banksize);
   }
}
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

Mapper 101 is an erroneously-assigned duplicate of Mapper 87.

Lum no Wedding Bell is the "only" mapper 101 dump, because it should have been mapper 87, because the hardware is 100% identical to Jajamaru no Daibouken.
However, when the first level starts the background are all messed up.
Yeah, sorry, I forgot to change the address after cpu_write
cpu_write(d, 0x6000, ((i & 2) >> 1) | ((i & 1) << 1));
That's the mapper 87 definition. If it's working correctly in your emulator, either your emulator has a patch list that's fixing the header for you, or you haven't gotten to any part of the game that requires that banks 1 or 2 be shown.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Kazzo USB rom dumper / dev cart programmer

Post by tepples »

lidnariq wrote:Mapper 101 is an erroneously-assigned duplicate of Mapper 87.
I prefer to see it as an erroneously-assigned subset of mapper 140.
werewolfslayr925
Posts: 40
Joined: Sat Oct 02, 2010 5:49 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by werewolfslayr925 »

That's the mapper 87 definition. If it's working correctly in your emulator, either your emulator has a patch list that's fixing the header for you, or you haven't gotten to any part of the game that requires that banks 1 or 2 be shown.
The game's hard enough that I haven't gotten to the third level yet. I'll report back about it if I ever get to a point where the visual glitch again.

I'm also having problems with R.C. Pro-AM. I have the SEROM version and have tried several different scripts. An ANROM script yields a functioning program but without any visuals (except for a bunch of horizontal lines). The SEROM script given here doesn't yield a working ROM when using the 060 version of unagi and doesn't work at all when used with version 062 of unagi. Is there a working SEROM script that can be used to dump R.C. Pro-AM?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

I don't see why that SEROM dumping script shouldn't work. Does Unagi give any error message?

As they said before, one should be able to use the normal MMC1 dumping script to get the CHR, and a normal NROM dumping script to get the PRG, and combine them... but I don't know why that wasn't working.
werewolfslayr925
Posts: 40
Joined: Sat Oct 02, 2010 5:49 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by werewolfslayr925 »

lidnariq wrote:I don't see why that SEROM dumping script shouldn't work. Does Unagi give any error messages?
There's this when I use v. 060 (sorry, I think I got the errors backwards in my previous post):

Code: Select all


AN ERROR HAS OCCURED [the index 'cpu_romsize' does not exist]


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

LOCALS
[vram] 0
[increase_ppu] 1
[increase_cpu] 1
[mappernum] 1
[d] USERPOINTER
[this] TABLE
Using the same script in v. 062 yields a working script, but the checksums don't match bootgod's database and don't give a working ROM:

Code: Select all

Program ROM: size 0x004000, crc32, 0x82bf334a
Character ROM: size 0x002000, crc32 0xdd45583b
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

werewolfslayr925 wrote:Program ROM: size 0x004000, crc32, 0x82bf334a
Character ROM: size 0x002000, crc32 0xdd45583b
Yeah, those are both markedly smaller than they should be.
Weird.

If I take the goodNES dumps for the game, no 16KB or 8KB slice generates those CRCs either.

... wuh-oh. If I generate the CRC32s for every single 8KB or 16KB that are all the same byte, I get matches.
8 KiB of 0x7E ("~") has crc32 dd45583b
16 KiB of 0x7E ("~") has crc32 82bf334a

So that's pretty much garbage.

You should, theoretically, be able to dump the cart as through it were ANROM and SKROM, take the PRG from the former and the CHR from the latter, and combine them to get a functioning dump.

Or I could try to combine the dumping scripts ... but then I get the exact same thing that were in the zip you linked to.
Post Reply