Hmmmm, that cartridge is still good for surprises and doesn't make sense.
Ice Man wrote:Code: Select all
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize - 1; i += 1){
cpu_write(d, 0x6000, i);
cpu_read(d, 0x8000, banksize);
}
cpu_read(d, 0xc000, banksize);
}
Ah, so the "pagesize" parameter is apparently meaning "number of banks" (the total size divided by banksize).
The minus 1 in "pagesize - 1" is wrong (that will exclude the last bank).
The "cpu_read(d, 0xc000, banksize)" is also wrong (that will read random garbage; since 6002h wasn't initialzed).
Fixing that two issues, the function should look as so:
Code: Select all
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i += 1){
cpu_write(d, 0x6000, i);
cpu_read(d, 0x8000, banksize);
}
}
Can you try that please? It should produce more reliable data in last 8Kbytes.
And then, to test the mapping behavious on the reset vector area, change 6000h/8000h to 6003h/E000h. Like this:
Code: Select all
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i += 1){
cpu_write(d, 0x6003, i);
cpu_read(d, 0xe000, banksize);
}
}
That could/might reveal what the cartridge is mapping to the "reset area".
Ice Man wrote:
Also, I saw 2 differences between my game and the ROM I have (but that doesn't make any sense to me, probably just a table).
Offset: 800C
Dump: 00 FF 00 FF
ROM: D0 FF D0 FF
That are the reset and irq/vectors in bank 3 (file offset 800Ch is PRG ROM offset 7FFCh) (in .NES files with 10h-byte header).
I would have assumed them to point to FFF0h, seeing them pointing to FF00h doesn't seem to make any sense.
But the cartridge is probably booting via reset vector in last bank (bank 63), so the weird vectors in bank 3 would have no effect.
If there are no further differences between your dump and the ROM that you've compared it to, then I can't understand how the CHR mapping via 6004h..6007h could work with your GAL. Unless the "ROM that you've compared it to" didn't use 6004h..6007h either.
Can you try it in no$nes on windows/wine, and enter "Ctrl+G, 0dab7" and check if the disassembler shows this code:
Code: Select all
ROM2:DAB7 A5 25 mov a,[25]
ROM2:DAB9 8D 04 60 mov [6004],a
ROM2:DABC A5 26 mov a,[26]
ROM2:DABE 8D 05 60 mov [6005],a
ROM2:DAC1 A5 27 mov a,[27]
ROM2:DAC3 8D 06 60 mov [6006],a
ROM2:DAC6 A5 28 mov a,[28]
ROM2:DAC8 8D 07 60 mov [6007],a
ROM2:DACB 60 ret
If it's containing the same code (with 6004, 6005, etc.) then you have a "normal" version of the game - which theoretically couldn't work with your GAL.
And, one detail in the pinout:
Pin 15 = SRAM R/W. There's something wrong. There should be a CPU R/W signal on cart bus, and there should be /CE, CE2, /OE, and /WE signals on the SRAM chip. But something called "SRAM R/W" shouldn't exist. I suspect that Pin 15 might be wired to both CPU R/W and to SRAM /WE ?
Using wires between PCB and GAL is a good idea. Then you could also attach a socket to the wires for swapping the chip more easily.