It is currently Mon Jul 23, 2018 6:59 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 622 posts ]  Go to page Previous  1 ... 38, 39, 40, 41, 42  Next
Author Message
PostPosted: Sun May 13, 2018 2:10 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7329
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 9:00 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 563
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".


Top
 Profile  
 
PostPosted: Sun May 13, 2018 9:08 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7329
Location: Seattle
Correct. This has come up in several threads here (e.g.); people have disabled the reset detector in order to get a dump.


Top
 Profile  
 
PostPosted: Sun May 13, 2018 10:04 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 563
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?


Top
 Profile  
 
PostPosted: Sun May 13, 2018 11:13 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7329
Location: Seattle
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...


Top
 Profile  
 
PostPosted: Wed May 16, 2018 3:45 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 563
Just reporting that the multicart in question has been successfully dumped on the first try using a CopyNES.


Top
 Profile  
 
PostPosted: Tue Jun 19, 2018 7:06 pm 
Offline

Joined: Sat Oct 02, 2010 5:49 pm
Posts: 28
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:
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);
   }
}


Top
 Profile  
 
PostPosted: Tue Jun 19, 2018 7:27 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7329
Location: Seattle
You just posted the CNROM script?

Mapper 87 should be something like
Code:
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.

Top
 Profile  
 
PostPosted: Tue Jun 19, 2018 7:58 pm 
Offline

Joined: Sat Oct 02, 2010 5:49 pm
Posts: 28
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:
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);
   }
}


Top
 Profile  
 
PostPosted: Tue Jun 19, 2018 8:59 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7329
Location: Seattle
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.

Quote:
However, when the first level starts the background are all messed up.
Yeah, sorry, I forgot to change the address after cpu_write

Quote:
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.


Top
 Profile  
 
PostPosted: Tue Jun 19, 2018 9:08 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20291
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Fri Jun 22, 2018 2:12 pm 
Offline

Joined: Sat Oct 02, 2010 5:49 pm
Posts: 28
Quote:
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?


Top
 Profile  
 
PostPosted: Fri Jun 22, 2018 2:18 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7329
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Fri Jun 22, 2018 2:36 pm 
Offline

Joined: Sat Oct 02, 2010 5:49 pm
Posts: 28
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:

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:
Program ROM: size 0x004000, crc32, 0x82bf334a
Character ROM: size 0x002000, crc32 0xdd45583b


Top
 Profile  
 
PostPosted: Fri Jun 22, 2018 3:15 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7329
Location: Seattle
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 622 posts ]  Go to page Previous  1 ... 38, 39, 40, 41, 42  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group