I have a pirate cart of Tiny Toon 2 (J) and the board brings "VRC4". No matter the script, I have problems for getting the data. This game always crashes due to an unofficial opcode, or the dumped CHR ROM is smaller than it should be.
Same for Gradius II (J). This one I couldn't open the case because I glue it 30 years ago... and I'm not confortable to break it. I can't get valid data too, but it works in an emulator. Graphics are all messed up - I already inserted a good bank, but the same result - so, the PRG is bad.
Following the Tiny Toon 2 board for anyone that wants to analyse/help me.
I traced everything. Here's a transparent overlay you could place over the image of the epoxy side.
Nothing looks funny, just a 128K/128K VRC4 game that uses A2 and A3 to select registers.
lidnariq wrote:
I traced everything. Here's a transparent overlay you could place over the image of the epoxy side.
Nothing looks funny, just a 128K/128K VRC4 game that uses A2 and A3 to select registers.
"Funny" because
this game should be a KONAMI-VRC-7.
What revision/kind of VRC4 is it?
Yeah, clearly a mapper hack of some sort.
It appears to be what the wiki refers to as VRC4d. (See how the trace shows the pin order on the center epoxy blob at the bottom going counterclockwise as A13 A14 A2 A3 ?)
Are there VRC4 hack-variants, like the MMC3?
No matter what I do, the PRG CRC32 is always being 0x0d46a4db, 128KiB.
The dumped game does not work in mappers 21~25, or even 85.
There could be, but both VRC4 variants that use A2 and A3 exist as standard Konami-originated boards (VRC4d and VRC4e).
The only "pirate" VRC4 layout is VRC4f, which is the only layout where the registers are contiguous and in-order (A1 MSB; A0 LSB).
So, the
upstream VRC4 dumper works by setting the banks at $8000 and $A000 to subsequent banks, and the VRC4 to 8+8+16F mode (instead of 8F+8+8+8F). Is your copy of
vrc4.ai the same as what's there?
It would certainly be easy enough to try changing the extant
Code:
for(local i = 0; i < pagesize - 2; i += 2){
cpu_write(d, 0x8000, i);
cpu_write(d, 0xa000, i | 1);
cpu_read(d, 0x8000, banksize * 2);
}
to
Code:
for(local i = 0; i < pagesize - 1; i += 1){
cpu_write(d, 0xA000, i);
cpu_read(d, 0xA000, banksize * 1);
}
just to sidestep the question of the banking mode altogether.
Code:
cpu_romsize is not connected 0x042000/0x040000
AN ERROR HAS OCCURED [script logical error]
CALLSTACK
*FUNCTION [dump()] dumpcore.nut line [47]
LOCALS
[ppu_dumpsize] 262144
[cpu_dumpsize] 262144
[ppuarea_memory] 0
[vram] 0
[increase_ppu] 1
[increase_cpu] 1
[mappernum] 25
[script] "konami_vrc4d.ad"
[d] USERPOINTER
[this] TABLE
.... maybe try updating to the copy of dumpcore.nut that's in the osdn.jp repository?
Crap.
The same error, but line 49.
.... but line 49 is nesfile_save(d, mappernum, vram); ???
Indeed. In short words, your change isn't matching the prg bank size.
... What happens if you just use the version of the dumper from osdn.jp and ignore what's in arantius's repository?
... Alternatively, did you change the for() loop as well as the reading line?
I'm looking forward to this pirate cart game rom!
This dumper works fine for original carts larger than 64kib (I cannot dump DrMario, for example), but pirate carts do not work as expected. I tried the original anago and still unable to dump correctly.
The first 32 k program sent to me.
I try to analyze, and write dump script.
(I received the PRG earlier). It's pretty easy to describe what's happened:
"vrc4.ai" always reads from $8000-$BFFF. It tries to set the VRC4 into 8+8+16F PRG banking mode, and then set the two banks to consecutive banks.
However, what I received is instead
30 1 30 3 30 5 30 7 30 9 30 &c ...... 30 27 30 29 30 31M
(where 1 through 30 are identical to the original VRC7 version of TTA2 PRG, and 31M would be identical other than a 483-byte mapper hack)
As a result, it seems that this isn't quite fully compatible with an ordinary VRC4, because writing to $8000
doesn't change the bank at $8000.
Quickly enumerating the register changes in the mapper hack:
When the original wrote to
Code:
VRC7- This mapper hack-
$F008 $F40C
$F000 $F408
$E008 $F404:$F400 (LFDC6)
$E000 $9400
$D008 $E40C:$E408 (LFBA3)
$D000 $E404:$E400 (LFB41)
$C008 $D40C:$D408 (LFA4D)
$C000 $D404:$D400 (LFA3F)
$B008 $C40C:$C408 (LFA31)
$B000 $C404:$C400 (LFD90)
$A008 $B40C:$B408 (LFD82)
$A000 $B404:$B400 (LFD74)
$9008 no sound hardware
$9000 $9408 ... what?
$8008 $A400
$8000 $8400
Note that A10 is definitively
not connected to the center mapper IC; that's a false lead.
Even given that this could be more than
just a VRC4, since it looks like it
might support 8+8+8+8F banking like VRC7 instead of MMC3-style banking like the original VRC4, it doesn't explain why writing 0 to $9008 (as the default Kazzo script does) causes the bytes read from $8000-$9FFF to be from the wrong section of PRG ...
And it also doesn't explain why the change I suggested (to only read via the bank window at $A000-$BFFF) is causing the dumper program to fail.
No matter what script I use, the PRG ROM is always a block of $4000 kb long, repeated 8 times.
The original anago vrc7 script fails.
Code:
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] 25
[script] "vrc7.af"
[d] USERPOINTER
[this] TABLE
Note that my pirate Gradius II has a similar problem, but the dumped game works. No matter if I replace the CHR ROM bank - the graphics appears all corrupted on gameplay.
function vrc4p_cpu_dump(d, pagesize, banksize, r0, r1)
{
local a2 = 1 << r1;
cpu_write(d, 0x9408 | a2, 0);
for(local i = 0; i < pagesize - 2; i += 2){
cpu_write(d, 0x8400, i);
cpu_write(d, 0xa400, i | 1);
cpu_read(d, 0x8000, banksize * 2);
}
cpu_write(d, 0x9408 | a2, 0x02);
cpu_write(d, 0x8400, 0x1e);
cpu_read(d, 0xc000, banksize * 2);
}
function ppu_bank_set(d, addr, i, j, r0, r1)
{
local a1 = (1 << r0);
local a2 = (1 << r1);
local a3 = a1 | a2;
cpu_write(d, addr | a1, i >> 4);
cpu_write(d, addr, i & 0xf);
cpu_write(d, addr | a3, j >> 4);
cpu_write(d, addr | a2, j & 0xf);
}
function vrc4p_ppu_dump(d, pagesize, banksize, r0, r1)
{
for(local i = 0; i < pagesize; i += 8){
ppu_bank_set(d, 0xa400, i | 0, i | 1, r0, r1);
ppu_bank_set(d, 0xb400, i | 2, i | 3, r0, r1);
ppu_bank_set(d, 0xc400, i | 4, i | 5, r0, r1);
ppu_bank_set(d, 0xd400, i | 6, i | 7, r0, r1);
ppu_read(d, 0x0000, banksize * 8);
}
}
try...,mapper number Not sure.
if data not ok
try
function cpu_dump(d, pagesize, banksize)
{
vrc4p_cpu_dump(d, pagesize, banksize, 3, 2);
}
function ppu_dump(d, pagesize, banksize)
{
vrc4p_ppu_dump(d, pagesize, banksize, 3, 2);
}
3-2 replace ,2-3,1-2,2-1,0-1,1-0
No lucky. Tried all the combinations. The game crashes on illegal opcodes.
Maybe try
Code:
for(local i = 0; i < pagesize - 2; i += 2){
cpu_write(d, 0xa000, i);
cpu_read(d, 0xa000, banksize);
cpu_write(d, 0xa000, i | 1);
cpu_read(d, 0xa000, banksize);
}
?
Zepper wrote:
No lucky. Tried all the combinations. The game crashes on illegal opcodes.
dump data upload,I analyze
this mapper hack, is not working any emu.
write new mapper .
function vrc4p_ppu_dump(d, pagesize, banksize, r0, r1)
{
for(local i = 0; i < pagesize; i += 8){
ppu_bank_set(d, 0xb400, i | 0, i | 1, r0, r1);
ppu_bank_set(d, 0xc400, i | 2, i | 3, r0, r1);
ppu_bank_set(d, 0xd400, i | 4, i | 5, r0, r1);
ppu_bank_set(d, 0xe400, i | 6, i | 7, r0, r1);
ppu_read(d, 0x0000, banksize * 8);
}
}
this mapper is vrc4 hack,irq is standard vrc4 irq.
game vrc7 to vrc4.
port 9408 is ignore.
Dumped.
What ended up being the problems?
Addresses are written like $x400, $x404, $x408, $x40C. Plus, I had to guess the correct parameter for the dumper.
All thanks to zxbdragon.
Code:
board <- {
mappernum = 25,
cpu_rom = {
size_base = 1 * mega, size_max = 1 * mega,
banksize = 0x2000
},
ppu_rom = {
size_base = 1 * mega, size_max = 1 * mega,
banksize = 0x2000 / 8
},
ppu_ramfind = false, vram_mirrorfind = false
};
dofile("vrc4p.ai");
function cpu_dump(d, pagesize, banksize)
{
vrc4p_cpu_dump(d, pagesize, banksize, 2, 1);
}
function ppu_dump(d, pagesize, banksize)
{
vrc4p_ppu_dump(d, pagesize, banksize, 2, 3);
}
Zepper wrote:
Addresses are written like $x400, $x404, $x408, $x40C. Plus, I had to guess the correct parameter for the dumper.
All thanks to zxbdragon.
Code:
board <- {
mappernum = 25,
cpu_rom = {
size_base = 1 * mega, size_max = 1 * mega,
banksize = 0x2000
},
ppu_rom = {
size_base = 1 * mega, size_max = 1 * mega,
banksize = 0x2000 / 8
},
ppu_ramfind = false, vram_mirrorfind = false
};
dofile("vrc4p.ai");
function cpu_dump(d, pagesize, banksize)
{
vrc4p_cpu_dump(d, pagesize, banksize, 2, 1);
}
function ppu_dump(d, pagesize, banksize)
{
vrc4p_ppu_dump(d, pagesize, banksize, 2, 3);
}
this rom mapper UNL-820119-C-A1 or suggest nes 2.0 mapper 25.14
Zepper wrote:
Addresses are written like $x400, $x404, $x408, $x40C.
If the pictures of the PCB you posted are accurate, I flat-out disbelieve the 4 is necessary. CPU A10
does not connect to the mapper IC and cannot be required.
Quote:
vrc4p_cpu_dump(d, pagesize, banksize, 2, 1);
The only thing that effectively does is keeps the dumper script from writing to VRC4: 0x9008 (and instead writes to 0x9002, which should be the mirroring control register, and should be a no-op).
If there's any difference here between this VRC4 and a Konami-authentic VRC4, it's only in the behavior of the register at 0x9008, and it would be nice to find out what that difference is.
But given language barriers, this is going to be frustrating.
lidnariq wrote:
If the pictures of the PCB you posted are accurate, I flat-out disbelieve the 4 is necessary. CPU A10 does not connect to the mapper IC and cannot be required.
It isn't, I was just illustrating the addresses written to $8000-$FFFF. Basically, there are 2 cases looking at the last 4 bits: 0,1,2,3 and 0,4,8,C.
Quote:
vrc4p_cpu_dump(d, pagesize, banksize, 2, 1);
The only thing that effectively does is keeps the dumper script from writing to VRC4: 0x9008 (and instead writes to 0x9002, which should be the mirroring control register, and should be a no-op).
All the other combinations (3-2,2-3,1-2,1-0,0-1) were generating a bad PRG data. Only 2-1 worked here. By the way, it was more "try-and-error", so the CHR data was dumped only with the values 2-3, instead of repeating 2-1. There's a slim chance of being wrong though.
Quote:
If there's any difference here between this VRC4 and a Konami-authentic VRC4, it's only in the behavior of the register at 0x9008, and it would be nice to find out what that difference is.
But given language barriers, this is going to be frustrating.
I see it harder with zxbdragon. Well, it was all right after all.
The cart board pictures are fine, what else do you want to know about it?
Zepper wrote:
lidnariq wrote:
If the pictures of the PCB you posted are accurate, I flat-out disbelieve the 4 is necessary. CPU A10 does not connect to the mapper IC and cannot be required.
It isn't, I was just illustrating the addresses written to $8000-$FFFF. Basically, there are 2 cases looking at the last 4 bits: 0,1,2,3 and 0,4,8,C.
Quote:
vrc4p_cpu_dump(d, pagesize, banksize, 2, 1);
The only thing that effectively does is keeps the dumper script from writing to VRC4: 0x9008 (and instead writes to 0x9002, which should be the mirroring control register, and should be a no-op).
All the other combinations (3-2,2-3,1-2,1-0,0-1) were generating a bad PRG data. Only 2-1 worked here. By the way, it was more "try-and-error", so the CHR data was dumped only with the values 2-3, instead of repeating 2-1. There's a slim chance of being wrong though.
Quote:
If there's any difference here between this VRC4 and a Konami-authentic VRC4, it's only in the behavior of the register at 0x9008, and it would be nice to find out what that difference is.
But given language barriers, this is going to be frustrating.
I see it harder with zxbdragon. Well, it was all right after all.
The cart board pictures are fine, what else do you want to know about it?
harder ?
你的英語知識水平影響通話。我本身不說英語,而且還有困難。沒關係。最終,一切工作。
Your english knowledgement level makes the talking harder. I don't speak english natively, and even that I have difficulties. Don't worry. In the end, it's all right.
Zepper wrote:
what else do you want to know about it?
Very briefly: how it differs from a Konami-manufacturered VRC4.
As far as I can tell, that only means the register at $9008.
Naruko's original dumper always writes 0 to it; but for you that always put it in the wrong mode. What happens if you use a number other than 0? (Various powers of two from 1 to 16 would be the obvious things to test; especially "2" should produced the wrong mode that you kept on eliciting).
Also, I may have made a mistake in tracing the pins on the VRC4 pinout on the wiki, because the code you have indicates that what you have should be VRC4e, not VRC4d. This was even staring me in the face when
I summarized the mapper hack...