Hello,
Sorry if this is posted in the incorrect section (I'm a noob with NesDev).
I'm trying to use the Kazzo cartridge "INL Retro" Dumper-Programmer to dump an NES library and I have been successful with all games except one (Romstar Thunder and Lightning). According to the following list from "http://tuxnes.sourceforge.net/nesmapper.txt" (which seems to be widely utilized), the game uses an MMC1 mapper. There is also a note indicating a bad dump. I suspect MMC1 is incorrect as the site "http://bootgod.dyndns.org:7777/profile.php?id=942" lists GNROM mapper 66. I've tried this mapper as well and it still does not seem to dump properly. Since I'm a noob, I don't have enough mapper knowledge to make my own script yet. I'd be happy to learn, but I'm not quite sure where to start. I'm hoping someone here has some knowledge that may identify the issue.
Thanks!
It is very likely GNROM, given the entry in NesCartDB.
Does your cart look the same as the picture on NesCartDB?
If you're willing/able to open it, does that look the same as the pictures on NesCartDB? Especially, look for a piece of text somewhere on the PCB. In the picture on NesCartDB, "GNROM" is in the top center, right below "©1986 Nintendo".
Where did you get the GNROM script that you tried using?
Hi. The script came from the anago script database at
https://github.com/arantius/anago-scripts. I have a picture of the opened up cart. It seems to match what is listed on that bootgod database. The script from anago is as follows:
/*
Written based on
http://tuxnes.sourceforge.net/mappers-0.80.txt*/
board <- {
mappernum = 66,
cpu_rom = {
size_base = 0x10000, size_max = 2 * mega, banksize = 0x8000
},
ppu_rom = {
size_base = 0x4000, size_max = 0x8000, banksize = 0x2000
},
cpu_romsize = 2 * mega, cpu_banksize = 0x8000,
ppu_romsize = 2 * mega, ppu_banksize = 0x2000,
ppu_ramfind = false, vram_mirrorfind = true
};
function cpu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize; i += 1) {
cpu_write(d, 0x8000, i << 4);
cpu_read(d, 0x8000, 0x4000);
cpu_read(d, 0xc000, 0x4000);
}
}
function ppu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize; i += 1) {
cpu_write(d, 0x8000, i);
ppu_read(d, 0, 0x2000);
}
}
Attached is a picture from a better angle noting the mapper. Maybe something in the GNROM mapper from the anago database is incorrect.
Also, when using the GNROM mapper from the anago database, the Kazzo creates a file that is only 49KB. I believe the correct size should be around 160KB.
No, the GNROM script is basically right. Not clear why it's not working for you.
Does unagi give any messages when you're trying it?
Sorry, I'm not sure what "unagi" is. If it's the anago_wx software that kazzo uses, then it does not give any error messages. With that said, I have run into instances where no error message was given, but the dump was still not right. I was using an incorrect script in those cases and dumped the correct file size once the proper script was found. The Super Mario/Duck Hunt combo was one of the carts that I went through similar headaches even though no error message was showing up. But, I eventually got it to work by finding a script someone else put together just for that game. Not sure why this one doesn't dump the correct file size with the GNROM script. I'm pretty sure the contacts are clean enough and it's not a connection issue. I'm consistently getting the same file size with no error message.
You say you end up with a 48 KB file. If you look at it (say, by loading it in an emulator, or by opening it with a hex editor, or by using a tool to split a .nes file into separate PRG and CHR), does it indicate 16 KiB PRG + 32 KiB CHR, or vice versa?
(In other words, does one half of the dumper script work correctly, or are both halves misbehaving?)
Theoretically, the GNROM dumper script shouldn't be capable of emitting a file smaller than 80 KiB—that's what size_base means here. (Don't look for less than 64 KiB of PRG or less than 16 KiB of CHR)
Alternatively, feel free to PM me your broken dump and I'll see what sense I can make of it.
If you're using the exact script you posted above, I'm guessing you're running into bus conflicts - with most of the discrete mappers, the value you write to the mapper register must match the value present in ROM at that address, otherwise your written value will be ANDed with the value in ROM to get the actual bank. Specifically, you can't just write your bank value to $8000, but must instead search through $8000-$FFFF for a value compatible with what you're writing.
Thanks for the feedback. I feel a little apprehensive about distributing the dump, but I did do a screen grab of what it looks like when using an emulator and what the top lines look like in a hex editor. I couldn’t do a screen grab of all the hex data for obvious reasons. If I know where to look for the PRG an CHR values, I can adjust the screen grab. I opened it up using HxD.
Also, I’m happy to tinker with some of the values if the script from GitHub is creating bus conflicts. Would there be different variations of a GNROM script depending on the game? Or, maybe the script on GitHub is simply incorrect for GNROM.
In any case, is there a reliable way to determine the proper value for the mapper register by examining the cart? Once this number is identified, which areas in the script would the “$8000 bank value” need to be changed? I noticed that the banksize appears to be listed in several areas (0x8000 and 0x2000 looks to be present throughout the script).
Okay, I hope I'm on the right track - I did some digging through some old posts and discovered that the GNROM script posted on GitHub was changed so that it could work with Super Mario Bros. / Duck Hunt in 2016. However, Super Mario Bros. / Duck Hunt uses MHROM according to
http://bootgod.dyndns.org:7777/profile.php?id=10. Does that make a difference if they are both mapper 66?
Thread that resulted in changing the GNROM Script:
viewtopic.php?f=9&t=7912&start=330Current GNROM Script on GitHub:
https://github.com/BlinksTale/anago-scr ... /_gnrom.adIn any case, is it possible to locate the older version of the GNROM script before it was changed by BlinksTale in 2016? I'd like to test that version to see if it will work with Romstar Thunder and Lightning. A screenshot of the post that described changing mapper 66 is attached.
MHROM is a subset of GNROM that supports only 64 KiB PRG ROM and 16 KiB CHR ROM. The difference between MHROM and GNROM is analogous to that between NROM-128 and NROM-256, or
SBROM and SFROM.
If one GNROM script works but another doesn't, they may be handling bus conflicts differently.
Thanks- that may explain the script issues that Romstar Thunder and Lightning is having. Do you (or does anyone else) know how to access the GNROM mapper on GitHub before the change occurred in 2016 to accommodate an MHROM game? I'm still learning how to navigate through GitHub. I'm hoping the older version is not lost.
Alternatively, maybe someone knows where to obtain a GNROM script from a source other than that GitHub page (or, as a last resort- tweak the GitHub script to accommodate GNROM rather than MHROM).
On the page for any file in a GitHub repository, you can click "History" to see
previous versions. The version prior to 2016 is
this version.
Perfect- thanks! Seems obvious now. I'll try this script later tonight.
Bummer- the older GNROM script still resulted in a bad dump of 49KB for Romstar Thunder and Lightning (instead of around 161KB). I was hoping I was on to something and I'm really not sure what may be the problem. I suppose it's back to square one. Is it possible to troubleshoot what may be the issue using a hex editor on the bad dump? I have a screenshot of the top lines and can adjust the screenshot if I know where to look. As a sidenote, I'm pretty sure it's not the game as it works fine in a legitimate NES and a Retron 5 as well.
What you've shown a picture of shows the second PRG bank out of 4, when you're trying to dump it.
I have no idea what's going wrong.
You could try changing cpu_rom { size_base to 0x20000 and ppu_rom { size_base to 0x8000
Beyond that ... dunno.
HOLY COW!!!!! IT WORKED!!!!!!!!!!!
Thank you a thousand times over! In case anyone ever needs to dump this game, the script that finally worked is below. I'm not sure if there are certain variations required for GNROM Mapper 66 dumps. But, I can say that at the very least- this one works for Romstar Thunder and Lightning.
board <- {
mappernum = 66,
cpu_rom = {
size_base = 0x20000, size_max = 2 * mega, banksize = 0x8000
},
ppu_rom = {
size_base = 0x8000, size_max = 0x8000, banksize = 0x2000
},
cpu_romsize = 2 * mega, cpu_banksize = 0x8000,
ppu_romsize = 2 * mega, ppu_banksize = 0x2000,
ppu_ramfind = false, vram_mirrorfind = true
};
function cpu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize; i += 1) {
cpu_write(d, 0x8000, i << 4);
cpu_read(d, 0x8000, 0x4000);
cpu_read(d, 0xc000, 0x4000);
}
}
function ppu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize; i += 1) {
cpu_write(d, 0x8000, i);
ppu_read(d, 0, 0x2000);
}
}