Hey guys the recent topics of rom dumpers and dev cart programmers motivated me to complete a project I've been thinking about lately the "kazzo":
http://sourceforge.jp/projects/unagi/wiki/kazzo_intro_en
It's a pretty nifty little device, with USB ability to dump carts and flash dev carts. It does it with only two chips and a few discrete components. I ended up using 3 chips so I could use through hole D flip-flops because they were what I had sitting around. Turned out to be a blessing though because for some reason the software uses CHR /A13 as an active high signal. Not sure if it was some sort of bug in the supporting software or what though because the schematics have it all labeled as active low. It was an easy fix though since my flip-flops had inverted outputs available, I just swapped the wire over from the Q to /Q. I used the atmega164P, it's possible this bug was fixed in the later surface mount atmega16 layout who knows.
I know, I know, it would have been a LOT easier to do a PCB or give myself a LOT more room to work with. But I happened to have this board left over from other projects and was pre-cut to the size you see. Once I saw all the parts could fit I couldn't resist. I get some sort of sick enjoyment out of slamming circuits into as small as possible spaces as I can. Consider it practice for the NESDEV cart prototype. It definitely requires a lot of planning on paper before touching the soldering iron. But it was a success, worked first dump with a UNROM, but I had to make the CHR /A13 bug fix before I could dump other carts. I've successfully dumped UNROM, CNROM, MMC1: SLROM, MMC3: TLROM, TKROM.
I tried to dump a MMC1 SEROM but wasn't successful. They haven't supplied "dumping files" for every board so if I can't find them looks like I'll have to write a few but it doesn't seem too complex.
I also haven't tried the battery ram back up or flash dev cart abilities yet, but I'm looking forward to playing around with those options a little more.
Oh yeah and I had some 2.50mm pitch (40 something) pin connectors sitting around so I was able to slice em in half (or so) and take the ben heck approach to the 72 pin connector works great!
That's pretty awesome man
Is that a spliced-up IDE cable you're using to wire everything together?
qbradq wrote:
That's pretty awesome man
Is that a spliced-up IDE cable you're using to wire everything together?
It's very similar, normal IDE cable is around a 24 gauge, and is really good for bigger projects. I stopped hacking up old wires awhile ago though and just buy it in bulk from digikey. Just search ribbon cable if your looking for some.
This wire is a lot finer at 30 gauge. It's trickier to deal with stripping/separating and all but good for stuff like this.
Beautiful infinitelives, this is exactly the way I had imagined CopyCart working, and you've done it with less parts. This should be a very low cost device, and no need to rip parts out of an existing machine. I think that the feature set is good enough for this to replace CopyNES for most people. Well done!
How does the logic work with just the 8 bit D flip flop? Looks like you're using the output of that to provide about 20 or so signals to the cartridge. Could you explain how that works a little bit?
Pretty cool! I definitely want to build one of these too. Please share more information if you can! Like, what parts you used and how they're wired up.
teaguecl wrote:
Beautiful infinitelives, this is exactly the way I had imagined CopyCart working, and you've done it with less parts. This should be a very low cost device, and no need to rip parts out of an existing machine. I think that the feature set is good enough for this to replace CopyNES for most people. Well done!
How does the logic work with just the 8 bit D flip flop? Looks like you're using the output of that to provide about 20 or so signals to the cartridge. Could you explain how that works a little bit?
Yeah it ended up being around $10.
The kazzo link and download has most of the info you need. The schematic is a little hard to read. Look at the readme.txt it has a better list of the pin outs. You'll have to convert to 72 pin layout though if you're going to the NES.
The plans call out for a surface mount tristate output octal Dflipflop. You don't need the tristate though because as you can see in the schematic /OE is tied to ground. So I used a pair of quad D flipflops. Mine have a clear available but it's not used. I didn't have tristate output because I didn't need it like I said. I did have the dual Q and /Q outputs though that I would recommend because of the bug I explained with the CHR /A13 signal being active high. You could get around this though if modified the code. I'll post up my specific schematics this evening for you all.
Basically though it ties both CHR and PRG data busses together and that is also fed into the 8 D flip flops. Then the AVR has an "AHL" signal that clocks the flipflops to latch onto the value on the data bus. The output of the 8 flipflops are then used for the upper address bits Combined: A8-A13, CHR /A13, and PRG A14. The lower address byte (A0-A7) of the PRG and CHR busses are tied together and driven directly from the AVR. And all the control signals are driven directly off the AVR (PRG /CE, M2, CIRAM etc.)
There are even a few extra unused pins on the dip packaged Atmega164. So you could use them for additional features if you had more signals for sound or add another D flipflop to acess the EXP pins if you had some auxiliary function that you were using them for on a dev cart or something.
I really like the ease of the USB interface, it's always been a thorn in my side to get something like this working with USB.
Like I brought up before, it looks like the greatest room for improvement on this is the script files that allow you to dump/program all the different mappers and board configurations. There may be more available somewhere, but I'm not seeing them at the moment. I've also yet to compile the GUI and try that out. It's pretty easy to run from the command prompt though.
infiniteneslives wrote:
Like I brought up before, it looks like the greatest room for improvement on this is the script files that allow you to dump/program all the different mappers and board configurations. There may be more available somewhere, but I'm not seeing them at the moment. I've also yet to compile the GUI and try that out. It's pretty easy to run from the command prompt though.
I think the scripts you are referring to are the CopyNES plugins, which are in the copynes.zip file here:
http://kevtris.org/Projects/copynes/copyware.html
This has inspired me to build a ROM burner using this method. It's a lot better than my usual approach of using a low pin-count MCU and shift registers.
Hrm... I wounder if I could come up with a cart that re-purposes some expansion pins so I could program the ROMs while still in the cart using something similar to this setup.
Looks nice, MCUs sure are great. CopyNES is what I was thinking when I saw it, on the PC-side (or in the MCU?) you could emulate a 6502 to run the CopyNES plugins as a script in the "virtual machine". Then it would be cheap, and support everything, and sound fancy while doing it, heh.
I think you have a shot at DIY kit that many people would be interested in Infiniteneslives. If I were you, I would consider having a pcb made and sell it in your shop! I would definitly buy a pcb from you.
teaguecl wrote:
infiniteneslives wrote:
Like I brought up before, it looks like the greatest room for improvement on this is the script files that allow you to dump/program all the different mappers and board configurations. There may be more available somewhere, but I'm not seeing them at the moment. I've also yet to compile the GUI and try that out. It's pretty easy to run from the command prompt though.
I think the scripts you are referring to are the CopyNES plugins, which are in the copynes.zip file here:
http://kevtris.org/Projects/copynes/copyware.htmlIt's a little different animal than what the copy NES is running. Those scripts appear to be assembly written for the NES to dump the carts.
If you download the unagi client software from the bottom of the kazzo page you can see what I'm looking at. The dumping engine is the unagi software that gets ran on your PC. I'm running it in the command prompt and you need to supply it script files (.ad) for what type of MMC and board you're dumping. Here's an example of a generic MMC3 script that's provided:
Code:
board <- {
mappernum = 4,
cpu_romsize = 2 * mega, cpu_banksize = 0x2000,
ppu_romsize = 2 * mega, ppu_banksize = 0x0400,
ppu_ramfind = true, vram_mirrorfind = false
};
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize - 2; i += 2){
cpu_write(d, 0x8000, 6);
cpu_write(d, 0x8001, i);
cpu_write(d, 0x8000, 7);
cpu_write(d, 0x8001, i | 1);
cpu_read(d, 0x8000, banksize * 2);
}
cpu_read(d, 0xc000, banksize * 2);
}
function ppu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i+=4){
cpu_write(d, 0x8000, 2);
cpu_write(d, 0x8001, i);
cpu_write(d, 0x8000, 3);
cpu_write(d, 0x8001, i | 1);
cpu_write(d, 0x8000, 4);
cpu_write(d, 0x8001, i | 2);
cpu_write(d, 0x8000, 5);
cpu_write(d, 0x8001, i | 3);
ppu_read(d, 0x1000, banksize * 4);
}
}
I don't have a copyNES but I'm thinking this may make things a lot easier to play around with. For starters the USB plans aren't proprietary...
It appears to me they've really made the whole USB interface really transparent and the helper functions they're written make it really easy to write your own scripts. It seems refreshingly simple way to do whatever you wanted with an NES or dev cart.
qbradq wrote:
Hrm... I wounder if I could come up with a cart that re-purposes some expansion pins so I could program the ROMs while still in the cart using something similar to this setup.
This is the kind of stuff I'm talking about. I think there may be plans for a kazzo flash cart I saw something about somewhere. Depending on what type of memory you're using I think you could get away without using any of the EXP pins. You definitely could with battery backed SRAM or flash, and EEPROM or UVEPROM would depend on whether or not you needed greater than 5V signals. What signal (chips) were you thinking you'd need the extra pins for?
Memblers wrote:
Looks nice, MCUs sure are great. CopyNES is what I was thinking when I saw it, on the PC-side (or in the MCU?) you could emulate a 6502 to run the CopyNES plugins as a script in the "virtual machine". Then it would be cheap, and support everything, and sound fancy while doing it, heh.
That would be really nice to see, a little above my head on emulating the 6502 at the time being. It would solve the issue of supporting everything, but it would seem easier to write more of the scripts than the emulator to me.
Here's a list of what's already supported FYI guys:
CNROM, UNROM, UOROM,
mmc1 SLROM
mmc3, mmc5
VRC4, 5, and 7
There may be more I just haven't realized or will see in the GUI. It was a little confusing to figure what was going on between the unagi and anago softwares and the language barrier didn't help much.
SkinnyV wrote:
I think you have a shot at DIY kit that many people would be interested in Infiniteneslives. If I were you, I would consider having a pcb made and sell it in your shop! I would definitly buy a pcb from you.
I might consider it. If there was enough interest I may draw up my own boards and make a small order. there's too many crossing connectors for me to easily etch my own single sided PCB that would be friendly that's why I just used protoboard.
Is there a lot of interest in a kit that included all the components? If so I may consider putting a kit together with everything needed:
*Atmega164PA I would flash the kazzo firmware onto it for you (that way you don't have a need to buy your own AVR programmer)
*72 pin connector 2.50mm pitch - wrong pitch but I've fully tested them to work and discussed it in the related post.
*6ft USB cable
*discrete components (resistors, zeners, cap and resonator)
*2x quad flip-flops
*3"x4" protoboard (about twice the size of what I used)
*interconnecting wireing similar to IDE cable style
*optional IC socket strips for the MCU (as seen in my picture)
*optional male header for flashing the MCU
Going out and buying everything on your own would easily be over $20 plus shipping. You'd also have to invest in an AVR programmer if you don't have one already.
I think I could do the kit for around $30 shipped. If people would rather buy it all themselves I can put a detailed supplier list together. My goal isn't to make money off the deal, I would really like to see more of these out there so we can work on things like the scripts and other things sharing all the code with eachother. I know a lot of you have copyNES though, so I really don't know how much interest there would be for this stuff.
As far as protoboard vs. printed circuit board goes there are pros/cons:
protoboard- quick availability of kits but more difficult to assemble and cheap. With protoboard and a detailed assembly insturctions I could have kits available in a couple weeks. Here's the protoboard I'm looking at:
http://www.radioshack.com/product/index.jsp?productId=2103800# the extended traces would make soldering 3-4 wires to a single pin much easier.
printed circuit board - long turn around time, potentially expensive, easy to assemble. We'd be looking at more like the end of the summer to for me to beable to ship these at a low cost that is still around $10 compared to the $3 protoboard.
This is really all up to you guys. If there's something I can do to help those without the skills of finding all the right parts and flashing an MCU, I'm more than willing to help.
Side note:
There appears to be a PCB rev 2 that includes 72 pin connector and a smaller MCU with more D flipflops seen and linked below. I'm not sure if they're available somewhere or if the board cad files are available.
http://sourceforge.jp/projects/unagi/wiki/pcb2.1_place_ja
[Wide picture]
Sorry for the double post but I wanted to deliver what I had for pinouts and board layout:
Here's the pinouts of all the chips I used. I stole the Atmega164 pinout from the readme.txt in the kazzo.zip download from the site. You have to convert things from FC to NES but it's pretty simple (VIRAM to CIRAM etc...) Note the chips are top view and 72 pin is bottom view so pay attention if you're using this to solder up your own
EDIT: I also made the change to the pinout for the CHR /A13 bug, and there's an arrow showing the change below.
Before I build anything with protoboard I draw everything out on graphing paper including exact size of my PCB and everything. If you do this be sure to do it all as a bottom view because that's where you're soldering...
If enough people ask me for kits, I'll put together a better assembly document along with things to check along the assembly process to make sure you don't mess anything up badly enough to let magic smoke out.
Hopefully this helps make sense of how I put it together. Let me know if you're confused about anything.
qbradq wrote:
Hrm... I wounder if I could come up with a cart that re-purposes some expansion pins so I could program the ROMs while still in the cart using something similar to this setup.
Look in this thread, something like that is standardized already on EXP0.
http://nesdev.com/bbs/viewtopic.php?t=7313
If it's high, writes at $8000+ go to mapper, if it's low, mapper writes are disabled and writes go to the memory chip. I made a UNROM flash cart that requires that for rewriting, I believe the PowerPak-Lite might use that too but I haven't checked.
My custom mappers put the registers at $5xxx to avoid that whole issue (for rewriting without extra hardware).
infinite: All the CopyNES sources in 6502 and QBASIC (and a drawn schematic) are available on kevtris' site, Retrozone's USB version is sorta just a clone version. Parallel ports suck though, in practice, heheh.
Memblers wrote:
infinite: All the CopyNES sources in 6502 and QBASIC (and a drawn schematic) are available on kevtris' site, Retrozone's USB version is sorta just a clone version. Parallel ports suck though, in practice, heheh.
Yeah I've seen that stuff, but I was just trying to say the 6502 assembly and QBASIC doesn't directly port over to the scripts needed for the Kazzo like I though people may have been implying.
I thought about doing the parallel CopyNES but decided not to after not getting a reply from Kevin and deciding I didn't want to play around with the parallel ports.
I was about to break down and buy the USB version but had a hardspot with the price and not being able to play around with the source code myself. I would have liked to be able to buy a kit and assemble everything myself as well.
The kazzo has been everything and more than I was hoping to solve these issues including the joy of making it myself
My main interested is the PCB, but depending on the price I would also buy a full kit with component to save hassle. But the most important for me is the PCB as it is usualy the only stuff hard to produce for me.
Very good. Possibly it could be modified to work for direct emulation (no mapper detection required) as well, but I am unsure if low speed is fast enough.
If there is a good way to make a programmable Flash or SRAM cart to be used with this thing I'd pay $50 for this kit. If it's just a dumper then I wouldn't, but I know a few folks outside of this community that would. The kind of folks that refuse to download an NES ROM, but still want to play on emulators
qbradq wrote:
If there is a good way to make a programmable Flash or SRAM cart to be used with this thing I'd pay $50 for this kit. If it's just a dumper then I wouldn't, but I know a few folks outside of this community that would. The kind of folks that refuse to download an NES ROM, but still want to play on emulators
My next step is to take my dev/multicart prototype and program the SRAM I'm using as PRG and CHR ROMS with it. I figure I'll just battery back it then test it out on the NES.
I think it's basically already set up for this I just need to sit down with it again.
Well if you get that working I'll buy a dumper / burner kit and a dev cart kit if you'll make 'em
On a side note, this setup would satisfy my requirements for the NESDEV development cart I've been on about (assuming it supported at least an MMC1 SRAM cart). It's a USB cable that lets you write a dev cart. That's really all I'm after
Count me in as well if you make a Kit or even preassembled especially. since my soldering skills are horrible even on a great day.
Oh yea, I forgot to mention through-hole only components would be preferable. I recently soldered a MOD chip onto a PSOne and I nearly pulled my hair out, and that was only like 4 fine pitch legs
There's a difference between soldering smd component to an unpopulated board and solderimg wire to the legs of an already installed smd ic. It's really not as bad as some people thing but then again the part he
used for the prototype are all dip anyway.
Yeah if I do the kit it'll all end up being all through hole.
I could do assembled kits, but I wouldn't really be able to do it for a protoboard for a reasonable price I spent around 8 hours working on this over the weekend.
If there were enough requests for assembled boards I would more seriously consider drawing up the PCB layout and ordering some PCBs. I would be able to assemble those a lot quicker and could ship everything for $50-60 I'm guessing.
It appears there is a lot more benefit to drawing up the PCB and making an order. Theres a local place that makes PCBs for a good price but they only fulfill orders every month or so. I'll ask them when they estimate the next round of boards and see when I would have to get in by. It's possible we could to a preorder for those interested including assembled kits.
In the mean time if anyone has any ideas on how to upgrade the current circuit post it up. I'll add options to the PCB if possible like providing access to the unused pins on the AVR and EXP pins on the cart, perhaps tying them together. For possible future mods or personal hacking. It would be easy, free, and no effect those not planning to make use of the added options on the board.
Now I know this has been a topic of debate lately with the lack of availability of 2.50mm female connectors. The only real option I see for this is using the 2.54mm connectors I've tested out and had success with. So if this is a deal breaker for you be warned now. If anyone has a better idea I'm all ears. I've had good success with Nintendo's boards but I would like to try out Retrozone boards and some unlicensed games I have to see if we can try and come up with a list of tested carts. I don't have any retrozone carts but I was thinking about picking up Battle kid so now might be a good time to buy. The only other real option I see is buying some 36 pin connectors to remove some of the error from the cart edges with the ben heck approach. But theres a bit more work involved with that approach to get the seam to work like my prototype. My only other ideas involve toploader sacrifice and I'm going to go out of my way to support that.
Alright well I was able to gain more info from the website than last time I visited.
Looks like to get in on the next PCB board run I have to submit the order by July 8th (next Friday). It looks like the I would receive the boards around the end of July.
I sent the owner an email to confirm everything but ASSUMING everything goes as planned on the website the following should apply:
The cost of the PCB is around $15 compared to the $3 protoboard. Here's what we'd be looking at for pricing including shipping:
Kit with protoboard: $30 (earlier quote)
Kit with printed circuit board: $42
Fully assembled on a printed circuit board: $55
I'll take orders for all three versions. If you're undecided on whether or not you'd like me to assemble the board you could wait to make that decision for a couple more weeks.
I think it should be entirely possible to ship the kits by the end of July, and very possibly assembled kits as well. I would keep everyone posted if there were known delays.
So here's what's going to need to happen to make this a reality.
I would need all printed circuit board orders placed by the end of next week including at least a $20 deposit as payment via paypal. For those unaware I do have a reputation to uphold with my somewhat related business and have a high ebay feedback. If you don't trust me with your money for some reason let me know your concerns.
I think the best way for me to officially keep track of orders is for people to send me an email with a request for their order, and I can send paypal bills appropriately. I'll keep a list of people who've expressed interest (no obligation but good for me to know) and people with orders placed including full/partial payment.
There will be a minimum order of only 3 PCBs, but it looks like there are already a few interested so this doesn't sound like much of a problem.
People Interested:
SkinnyV
qbradq (pending devcart testing)
OldNESJunkie
Orders placed including payment:
None
Other notes:
I will accept email orders as of now but I won't bill anyone until I have confirmation on this with an email back from the PCB supplier. Hopefully early next week.
I've only tested this out on Windows XP 32bit thus far. I've got a windows 7 64 bit machine and I plugged it in but was unable to get the driver installed. There is one provided but I couldn't get it running with the 2-3 minutes I spent playing with it. I'll make more of an effort on this if it's a deal breaker for anyone.
If you're seriously interested but pending on one thing or don't have funds until after next week let me know. We may very possibly have to wait until next their next board order in a month if everyone's not ready to jump in by the end of the week.
I promise to but a detailed assembly instructions together providing steps along the way to check things with a DMM to ensure things are working properly before you plug it into your PC or put a cart in.
I'm open to any comments or suggestions. This is happening because people have asked me to and I have a lot of fun with projects like this.
One last note I'll be camping from Thurs till Saturday without the internets obviously. So I'll catch up with all the emails and everything Sunday. I just don't want anyone getting concerned when I vanish for a couple days.
Your homemade connector seem to me like a nice compromise. And if I hear anyone even me thinking of cannibalizing top loader for the connector I'll go berserk lol. Seriously, I have enough trouble accepting when we need to butcher cart to make repro or devcart (I did it twice,and still feel bad about it lol) so a top loader would be ludacris. There's always game genie connector but the same principle apply to that and plus I don't think those connector are that much better if I recall. Personally, I would be comfortable with your hacked Frankenstein connector even if it mean adjusting the cart position every once in a while.
As for ordering PCB, if you do not want any bad surprise I would suggest making a quote before sending it in because some people might change idea if the price turn up more expensive than they thought
Edit: Look like you replied while I was writing my reply:) I would be ordering a PCB for sure and have no problem pre-paying to avoid you the stress of ordering a batch and having people change their mind. As long as you don't mind selling a PCB alone. But I was thinking, don't you need a few days to design a PCB and check for error? It would be cool to have a quick peek at it so that the other guru on the forum can take a look at it.
SkinnyV wrote:
Your homemade connector seem to me like a nice compromise. And if I hear anyone even me thinking of cannibalizing top loader for the connector I'll go berserk lol. Seriously, I have enough trouble accepting when we need to butcher cart to make repro or devcart (I did it twice,and still feel bad about it lol) so a top loader would be ludacris. There's always game genie connector but the same principle apply to that and plus I don't think those connector are that much better if I recall. Personally, I would be comfortable with your hacked Frankenstein connector even if it mean adjusting the cart position every once in a while.
As for ordering PCB, if you do not want any bad surprise I would suggest making a quote before sending it in because some people might change idea if the price turn up more expensive than they thought
Edit: Look like you replied while I was writing my reply:) I would be ordering a PCB for sure and have no problem pre-paying to avoid you the stress of ordering a batch and having people change their mind. As long as you don't mind selling a PCB alone. But I was thinking, don't you need a few days to design a PCB and check for error? It would be cool to have a quick peek at it so that the other guru on the forum can take a look at it.
I'd be willing to supply smaller connectors or a bigger 76 pin or something that could be cut in half and sand them on your own. It's kinda a pain to do, it is a nice option though. If enough people asked I'd think about it, but would have to charge to make it worth my time IDK $5-$10 more and I would want to solder it in the board for you too. If someone didn't care keeping the exp connectors it would make it easier but I really don't recommend this option.
Now that I think about it I would much rather just offer the 72 pin connector I tested out with the other project. If you want to do something else I can take the $4.50 off your bill. Not saying I can't be convinced otherwise but I feel more comfortable with this. The only thing I'm genuinely concerned about is retrozone's boards working with it. I'd like to ensure that people have options to not use donors as dev carts.
If that's really a HUGE problem we could order up some of our own simple devboards with wider tolerances to both connector sizes.
I wouldn't have to order any connectors until around mid July though so that would give more time for testing of retrozone carts.
Who's the board guru? I am placing some stress on myself to make up this board on Sunday/Monday when I'd rather be drinking and shooting off fireworks. But I'm okay with it. The circuit really isn't that bad and should be pretty easy with 2-4 layers. I'd be happy to post up the files though for someone else to lay eyes on it. If someone's interested in writing the board file that'd be cool too, I'll cut you a deal or something let me know.
I don't expect the price to change much, as I know a couple people who've worked with them before. The thing I see more likely is a delay and placing orders next month or something if there isn't enough serious interest.
infiniteneslives wrote:
Who's the board guru? I am placing some stress on myself to make up this board on Sunday/Monday when I'd rather be drinking and shooting off fireworks. But I'm okay with it. The circuit really isn't that bad and should be pretty easy with 2-4 layers. I'd be happy to post up the files though for someone else to lay eyes on it. If someone's interested in writing the board file that'd be cool too, I'll cut you a deal or something let me know.
I'm not implying you can't do it by yourself, you certainly are what I consider one of the board gurus! Personally, I don't have the knowledge to offer any suggestions at all but I was just thinking that sometime it's nice to have others offer their insight when it's something within their field of knowledge, specially when you are on a dead line and try to finish something quick. Certainly don't feel offended or insulted at my comment, personally I am just curious to see the design and I thought some peoples like Memblers, Kevtris and all the other might get idea or suggestion while looking at the board design.
SkinnyV wrote:
infiniteneslives wrote:
Who's the board guru? I am placing some stress on myself to make up this board on Sunday/Monday when I'd rather be drinking and shooting off fireworks. But I'm okay with it. The circuit really isn't that bad and should be pretty easy with 2-4 layers. I'd be happy to post up the files though for someone else to lay eyes on it. If someone's interested in writing the board file that'd be cool too, I'll cut you a deal or something let me know.
I'm not implying you can't do it by yourself, you certainly are what I consider one of the board gurus! Personally, I don't have the knowledge to offer any suggestions at all but I was just thinking that sometime it's nice to have others offer their insight when it's something within their field of knowledge, specially when you are on a dead line and try to finish something quick. Certainly don't feel offended or insulted at my comment, personally I am just curious to see the design and I thought some peoples like Memblers, Kevtris and all the other might get idea or suggestion while looking at the board design.
No offense taken, I'd be more than happy to share my layout with anyone who'd like to see it when I'm done.
Got an answer back already on the boards, wow email response at 10pm on a Tuesday...
Good news! We can get a better deal on an order of at least 6 boards for $10 each.
I'll lower the official quotes above if we get that many orders. Savings of $5 on PCB orders.
That's good news. Let's try to get an official headcount guys, so if you are interested (and willing to pay soon), let Infinitesneslive know as this kind of project is hard to start with people saying they're interested but then change their mind. Count me in for the PCB and will be paying with paypal as soon as we're ready.
Think it might be useful to put room for a Famicom connector along with NES (it's 2.54mm 60-pin)? I've thought about making an FC cart, and something like that might help. The pins would be right across from eachother on the NES/FC connectors, and routes from the interface would be split between the "outside" halves of the NES and FC connectors, but I'm not sure if I'm visualizing it right). Of course you wouldn't want to plug 2 carts in at the same time.
I'd be interested in a kit, I'm still kinda leery of the 2.54mm pitch though. If the FC connector was there, worst that could happen would be needing to use an NES->FC adapter.
Maybe I could help with the board layout if you're having trouble.
I'm ready with my money for a complete kit, as like I said before, my soldering skills suck. Might as well solder with a mop
So my only concern here is the "Flash Memory Cartridge" mentioned on the Kazzo page. It doesn't have much detail about how to construct one. I get the general idea of connecting /CE to PRG /CE, /WE to PRG R/W and /OE to ~PRG R/W. What makes me nervous is that I already have an NROM board wired up like that but writing does not work (on my FamiClone anyway...).
Anyhow, I'm down for a PCB kit. I have no problems pre-paying. I am going to speak with a few of my co-workers today and see if they would be interested as well. One is a "I don't want to download ROMs" type, the other is an insane collector
I'm more of a software guy. If you would, put me down for a fully-assembled kit and a fully-assembled flash cartridge. I can pay with PayPal or Dwolla (lower fees than PayPal).
Actually the creator does sell kits
http://sourceforge.jp/projects/unagi/wiki/order_ja
I've ordered two but have yet to put them together.
Edit: Did sell them they are sold out now sorry about that.
On the topic of a devcart though I was thinking I would find the most compatible donor to cover the most mappers. I figured I could make like 7 devcarts and hopefully cover most of the mappers. (yes I know powerpak would probably be simpler in this case but I want to get better at projects like these)
I was going to look at modifying my
MMC1 repro board I bought from RetroZone. If that's not feasible I can always sack that Ultima: Exodus cart.
Wow, I really threaten that cart a lot. It's like at least once a week
Memblers wrote:
Think it might be useful to put room for a Famicom connector along with NES (it's 2.54mm 60-pin)? I've thought about making an FC cart, and something like that might help. The pins would be right across from eachother on the NES/FC connectors, and routes from the interface would be split between the "outside" halves of the NES and FC connectors, but I'm not sure if I'm visualizing it right). Of course you wouldn't want to plug 2 carts in at the same time.
I'd be interested in a kit, I'm still kinda leery of the 2.54mm pitch though. If the FC connector was there, worst that could happen would be needing to use an NES->FC adapter.
Maybe I could help with the board layout if you're having trouble.
I had the FC thought too. If I can keep it from taking up too much more space I'll do it. I haven't tested them yet but a 60 pin connector for FC should be less trouble. It's only the last 2-3 pins that I start to get concerned about on a 72 pin connector.
qbradq wrote:
I was going to look at modifying my MMC1 repro board I bought from RetroZone. If that's not feasible I can always sack that Ultima: Exodus cart.
So we've got a couple people interested in using this thing in combination with a dev cart of sorts. I actually ordered the two repropak boards from Retrozone last night (U/C/ANROM and MMC1). I think these boards are the best options to start with. The cost per square inch is better than I can get at these quantities. I want to do some more testing with these boards and the connectors and figure out some of the flash cart details before sealing the deal on this. If I get the stuff from retrozone early next week I think it's possible to still place an order by the end of the week.
But it's starting to get tight. I want to play it by ear for now but I may end up pushing the project a couple weeks because I want to ensure dev cart capabilities now. The major down side of not meeting the deadline of next week is the price on boards. He's doing a special run at a discounted rate and getting in on that is what drops the price from $15 to $10 per board. But it's not like we'd have to wait a full month for his next board run, he makes standard 2 layer runs every week at the $15 price.
As far as other options go on the board along the lines with a dev cart and exp pins go. I'm thinking about adding connections for another set of D flipflops or two and porting that to the EXP pins. There are a few extra AVR pins too. I would use one for a signal similar to the AHL I'll call it AHX for now. This would also allow for a couple direct lines to the EXP pins. Sound is EXP6 as I remember so I'd probably give that one a designated AVR pin and maybe a few more unflipflopped signal lines for user defined functions. I'm open to input on this so let me know in the next couple days. I need to look over that old post about assigned EXP pins to get some more ideas.
Just to be clear all of these extra options would not affect someone who wasn't interested in using them. You could just leave off the extra Flipflops from the board or not use the 60 pin holes. And you could always easily upgrade it in the future if you did want to use it for user defined dev cart use.
And I'll look into Dowolla Tepples, I haven't heard of it before. Paypal is only around $1 of fees I'm guessing.
On a related note what's the status of boards for the compo multicart? Do we want to try and combine these board orders?
Currently the compo multicart will be mapper 34 (BNROM oversize), and I was under the impression that Memblers would provide boards. I've never tried to make BNROM with a
discrete ReproPak board, but as I understand the
instructions (PDF), I guess you configure everything for mapper 7 (AOROM) but bridge VERT instead of ONE. Everything but Lawn Mower runs as either VERT or ONE, but Lawn Mower needs VERT because its scrolling code assumes horizontal arrangement (that is, vertical mirroring) of the nametables.
Just as an FYI I don't think I'd be interested in the dev cart kit now that I know it's basically what I've already made.
Also, have you had a chance to test this on Windows 7 yet?
I think this thing may benefit from a hardware compatible firmware and client software made to be a bit more compatible with Windows Vista / 7. You can easily make this use a standard HID interface and not have to use custom unsigned drivers. I'll look into this a bit more, especially once I have the hardware.
infiniteneslives wrote:
I had the FC thought too. If I can keep it from taking up too much more space I'll do it. I haven't tested them yet but a 60 pin connector for FC should be less trouble. It's only the last 2-3 pins that I start to get concerned about on a 72 pin connector.
Be careful, when I laid out the CopyCart pcb, the 72 pin header is a nightmare. I could only do a two layer board (much less expensive), and routing all those lines with only two layers is a very tough problem. Doing it with both a 60 and 72 would not have been possible. I think having a 4 layer pcb opens things up considerably, and it sounds like that's an option for you.
You can see the problem in this (very blurry) photo of my board:
http://dl.dropbox.com/u/477050/IM000225.jpg
http://dl.dropbox.com/u/477050/IM000226.jpg
You can also see the mistake I made with this revision - there's solder mask over the card edge, doh!
Yeah, the NESdev compo cart will use a simple board with just a 74HC161 for the mapper. I'll get those ordered soon. It won't be much use to combine with another order, I already paid the setup fee a couple years ago (with myropcb.com). Because it's the ultimate in cheapness, it's also the only NES board I've made that only takes EPROM, so this interface won't be able to program it. Maybe it could test the CHR-RAM for production (I use SMT so I can't just drop them into the Willem). Otherwise I figured I would add a hidden self-test into the program, that's easy enough too.
I do have a UNROM board that uses Flash (writing controlled with EXP0 for CopyNES), that could be pretty good to use with this cart interface. I wouldn't want to supply them though unless it can be proven to work reliably with this "non-standard" connector. I'm working on another (relatively cheap but nice) board with a custom mapper that would be good for this too. I'll post more about that one when it's ready.
qbradq wrote:
Just as an FYI I don't think I'd be interested in the dev cart kit now that I know it's basically what I've already made.
Also, have you had a chance to test this on Windows 7 yet?
I think this thing may benefit from a hardware compatible firmware and client software made to be a bit more compatible with Windows Vista / 7. You can easily make this use a standard HID interface and not have to use custom unsigned drivers. I'll look into this a bit more, especially once I have the hardware.
I got it installed on my Windows 7 64bit machine this evening. I ended up creating a driver for it with libusb inf wizard. But I'm having an issue dumping games. It stops in a different place every time but usually early on. I was able to get several dumps successfully but it's not stable. I'm not sure if it's an issue with the driver or what. It still works great on my netbook still. It's giving me a message: "device_read" "No error" but something is obviously wrong because I don't even get a partial rom image. IDK I'll have to play around with it some more.
As far as the whole devcart thing goes I want to clarify my thoughts here. I'm looking at the use of the repro pak flash cart for the kazzo, and need to do some more research on the flash cart that's already designed to work with the Kazzo. I'm considering this separate from the NESDEV1 which I'm still planning to complete but it wouldn't be for another 6-9 months. The main difference between the two being ability to configure mappers on a CPLD. The flash cart would be a lighter version of the NESDEV in essence, you would need a Kazzo or copyNES to program it. Really I think one could use a board as simple as a donor cart if you wanted. There should be many ways one could make a flash cart to work with the kazzo as I see it.
teagueci: One thing that should make it a little easier is I'm not connecting to a cart edge, just some holes on the board. So I'll be able to run traces between and behind others more easily than you were able to on the cart edge. That's not to say it'll be easy but I'll have a better idea when I start drawing it all out.
Memblers: Just to make sure I understand, is it a high voltage required for progamming that you're saying wouldn't allow the kazzo to program the EPROM?
infiniteneslives wrote:
Memblers: Just to make sure I understand, is it a high voltage required for progamming that you're saying wouldn't allow the kazzo to program the EPROM?
It's more than that, on most mappers the mapper registers overlap ROM, and most of the 74xx-based ones ones also require having the byte you write already existing in ROM at the written address or there will be a bus conflict.
So that's why hardly anyone made RAM carts for CopyNES. I made my UNROM board, and bunnyboy made the PowerPak Lite, AFAIK no-one else has built any others besides NROM-size. Well, except that kevtris made an NSF one that supports NSF format's 4KB banking, heheh.
BTW, The PPak Lite is probably what you guys would want, instead of modifying a "ReproPak". I can tell from looking at the picture of the ReproPak board that it doesn't use pin 16, which would be the needed mapper disable control.
So it's not really as easy as just rewiring a donor cart unless the mapper registers are somewhere else, I think you'll have to add a chip. My UNROM flash board added a 74hc139 and a pull-up resistor for when the pin16/EXP0 signal isn't available.
edit: whoops, forgot the PowerPak lite is RAM, so it's not going to hold it's programming. If you could add a battery to it..
Memblers wrote:
infiniteneslives wrote:
Memblers: Just to make sure I understand, is it a high voltage required for progamming that you're saying wouldn't allow the kazzo to program the EPROM?
It's more than that, on most mappers the mapper registers overlap ROM, and most of the 74xx-based ones ones also require having the byte you write already existing in ROM at the written address or there will be a bus conflict.
So that's why hardly anyone made RAM carts for CopyNES. I made my UNROM board, and bunnyboy made the PowerPak Lite, AFAIK no-one else has built any others besides NROM-size. Well, except that kevtris made an NSF one that supports NSF format's 4KB banking, heheh.
BTW, The PPak Lite is probably what you guys would want, instead of modifying a "ReproPak". I can tell from looking at the picture of the ReproPak board that it doesn't use pin 16, which would be the needed mapper disable control.
So it's not really as easy as just rewiring a donor cart unless the mapper registers are somewhere else, I think you'll have to add a chip. My UNROM flash board added a 74hc139 and a pull-up resistor for when the pin16/EXP0 signal isn't available.
edit: whoops, forgot the PowerPak lite is RAM, so it's not going to hold it's programming. If you could add a battery to it..
Similar to your fix I was thinking of just placing an or gate on the PRG R/W line going to the 161 on a UNROM for example. Then you would just invert a pulled up EXP0 signal and then or that with PRG R/W to drive the /LOAD on the 161. Easiest way I see to implement it is a 74LS00 (a pair of NAND gates)
That would basically be creating a /WE (write enable) signal for the PRG memory. When EXP0 was high or hi-Z input it would act as a normal UNROM and PRG W/R signals would bankswitch as normal. I guess you may want to do the inverse of this for the PRG R/W line going to the actual memory if you were using SRAM because you would want to prevent erroneous /WR signals. That way you could only write to the "ROM" when EXP0 was low.
For the bus error issue of normal PRG-ROMs that byte wouldn't have to be written there because we'd actually be sending a write signal to the memory so the data pins would be Hi-Z. So we wouldn't have to worry about the byte already residing there. Correct???
I think I pretty much just repeated what you said Memblers, but I wanted to go into detail about the solution in my mind to make sure my thoughts were sound.
Yeah, creating a /WR enable for the ROM is exactly it. Any logic that prevents the ROM /WR and /LOAD on the '161 from being active at the same time, should be fine. I used the '139 because I had them around already. I also used the other half of the '139 with PRG /CE and R/W to create a ROM /RD, which isn't really necessary but it eliminates the bus conflict (during 'normal' operation) if it's there.
My board used a solder jumper so you could build it without the '139 for a non-writable version. Also had jumpers to select EPROM/Flash, 28 or 32-pin ROM, it sure made my schematic tough to read.
Pics btw if you're curious:
back and
front
This is my solution I posted this a while back, it makes programming easy. Alternatively you can use a single gate, a 1-bit MUX for either polarity or a '157 if you have multiple clock sources.
Well I've got some decent progress made with this in the past day. I've managed to fit everything from my original kazzo plus a FC connector and an additional D flipflop for some of the EXP pins. Everythings on a 2"x4" board with some tiny ass 6 mil traces for the signals.
I've had some thoughts and questions I need your guy's feedback on though:
*AVR Programmer connection pinout: This isn't necessarily applicable to everyone. But if people are looking to play around with the firmware or if we came up with our own upgraded version of the firmware it might matter. The best standare I've found is like sparkfun's programmer:
http://www.sparkfun.com/products/9825 I think thier pin out is similar to what I've seen most often in a 3x2 male header on our board. It's not what my programmer uses but it's something that's easily adaptable if it were a problem for someone outside of the norm like myself in the future.
The main thing I see that would require someone to have a firmware upgrade is making use of the EXP pins. I've provided access to them as I discuss below. But I haven't made any changes to the firmware to make use of them. It was easy for me to provide hardware that allowed improvements in the software to use said hardware. The only added cost is a 50cent Dflipflop that could be left out if one chose. I'm planning to also include IC socket strips for the MCU. That way someone could pull off the chip and send it to a freind who could flash it for them without shipping the whole board. The IC strips are cheap in larger quantities so I figure why not.
*CHR /A13 bug: I've talked about this earlier but here's the issue. I think the fix to use the /Q output instead of Q may backfire. It's kinda silly for the code not to address it as an active low signal, and we shouldn't be using hardware to fix code. Also if the code were to make it active low it would have allowed for using 1-2 74HC374 (octal single O/P tristate D flipflops) vice 3-4 74HC175 (quad dual O/P resetable D flipflops). I would have liked to use 2x 374's using the first for the same design as the official kazzo (upper Addr bits) And then use the second to reach all EXP pins.
I was going to play around with the source code but I wasn't sure of the extent of the bug without digging in deep and testing some things I currently don't have the ability to test. Is it just an issue with Dumping or is it Flashing too??? IDK... It puzzles me why this isn't an issue if the original schematic didn't have issues. Perhaps it's something to do with NES/FC differences but I don't see how.
* That gives me an idea though * I should go recompile the source code and make sure they aren't just distributing an old version of the .hex file that I used to quickly flash my MCU. I'll have to get back on that I guess.
My solution was to provide a jumper on the CHR /A13 line to allow the user to select between the active high or active low (Q or /Q output of the flipflop) That way it would work now with the firmware available and if/when the bug gets fixed it would be as simple as swapping over the jumper if one chose to upgrade to the new debugged firmware.
*EXP pins: So I had 5 free pins on the MCU and 10 EXP pins to play around with (2 unused sound pins on the FC)
Here's what I did:
AVR EXP FC
PD0 Directly to EXP0 pin 45
PD1 Directly to EXP1
PD6 Directly to EXP6 pin 46 (Sound out) My understanding is these pins are similar on both systems so I paired them)
PD7 Directly to EXP2
PC3 XHL: EXP high latch signal (similar to the current AHL:address high latch but for the EXP pins vice upper address pins)
XHL clocks an additional 175 D flipflop to provide addressing below:
Data bit EXP (the order is a little messed up from providing EXP6 with it's direct pin to the MCU so I just picked up the slack here)
D0 EXP3
D1 EXP4
D2 EXP5
D3 EXP7
EXP pins 8 and 9: I didn't have a direct use for these. I figured it might be nice to have a way to get high voltage on the board for some EPROM programming abilities. So I provided some pads off to the side of the board with EXP 8, 9 and GND in one continent location.
Writing this all out I'm starting to wonder if this would make more sense if EXP were being used as a bus, you would just mask the proper bits with everything matched up in order: (from an avr coding standpoint you would just write the byte to both ports and toggle the XHL pin to get your byte on the EXP bus simply)
AVR EXP FC
PD0 Directly to EXP0 pin 45 (Sound in)
PD1 Directly to EXP1
PD6 Directly to EXP6 pin 46 (Sound out)
PD7 Directly to EXP7
PC3 XHL: EXP high latch signal (similar to the current AHL:address high latch but for the EXP pins vice upper address pins)
XHL clocks an additional 175 D flipflop to provide addressing below:
Data bus EXP (now the order is straightened up a bit)
D3 EXP3
D4 EXP4
D5 EXP5
D7 EXP7
There's no good reason not to do it this way so I think I'll make the simple change. Unless someone has a better suggestion.
One last thing: I was thinking it would be nice to have this thing in a case. I picked up a little black project box from radio shack for around $5.
http://www.radioshack.com/product/index.jsp?productId=2062281 It's 5"x2.5"x2" LxWxH. I wish it was only 1" high but I won't have to mess with the board much to fit it in there with proper mounting holes. A cart would be a little deep in there ~1.7" due to the depth of the box but it looks like the best choice. Then if you wanted to use the lid all you'd need was a slot for the cart and a hole in the side for the USB cord. I figured these would be easy for people to pick up themselves. I could resell them for $5 as is or I might think about pre cutting them for people (w/ drill and dremel) for an extra $5 a box.
The only issue I see with it is use of a FC cart. you would have to chop off 2 of the 4 drill posts that are used to screw down the lid. It would still work well, or you could come up with your own solution but the mounting holes would be designed for that box specifically.
I've yet to reroute the board with the components moved around to make best use of the box but I don't suspect much trouble. I'm also waiting to hear back from the board supplier to find out some more details on his minimum requirements. But I think it's entirely possible to make an order by the end of the week still. The only thing that may hold me back is receiving my own repropaks from retrozone. I would like to test them in the connectors if possible and it doesn't appear that my stuff got shipped before the weekend.
I'm not in any real time crunch here other than saving you guys $5 on the board cost if I place the order by the end of the week. But it also doesn't look like we've met the 6 required to get the lower rate yet anyways... I've yet to get any emails which is okay because I'm not quite ready to bill people but here's my current list of interested people:
People Interested:
qbradq (and possible coworkers)
OldNESJunkie
Memblers
Tepples (would like devcart as well, still much work to be done here)
Board only:
SkinnyV
So in conclusion while it may be possible to order them this week and save everyone $5, it may be better in the long run to wait another couple weeks before making an order. I'll let you guys drive this decision though, if you give me your input.
You should try to put a bootloader in there, I couldn't find one on Atmel's site, but there is this one:
http://www.fischl.de/avrusbboot/. Maybe my Willem can program it, but the board's existing USB connection should be enough.
I'm not sure why the MCU would connect to the audio pins, it seems like only an ADC and/or DAC would be usable.
Please try to keep this pinout in mind, too:
http://nesdev.com/bbs/viewtopic.php?t=7313
Other than the audio and CopyNES mapper disable pins, nothing ever used expansion port. So I proposed that standard, there is still time to revise it if needed. I'm just saying, I don't want to see the cart interface done in a way that could possibly damage stuff later. The same situation could arise if carts were made to a different standard and plugged into an NES that had an expansion board connected.
I'm not in any big hurry to get it, really I'd rather have it when the firmware is finished (or includes a bootloader), so I don't have to bother with more programming adapters.
I like the idea of the bootloader. Looks like that would only use up one more pin. (Used to tell the MCU to switch to bootloader mode.
So if we started from scratch we would have 4 pins left. Then assuming we have one used as XHL to I/O extend, we've got 3 pins left that we can run directly to the EXP pins.
Memblers wrote:
I'm not sure why the MCU would connect to the audio pins, it seems like only an ADC and/or DAC would be usable.
I didn't really intend for it to be used for sound. Since how the FC carts don't have any extra pins hanging around and most games don't use the sound pins I figured a developer may want to use the sound pins for other features like mapper disable which would seem highly desirable for someone developing on UNROM or whatnot. We could connect them to ADC into the AVR and that wouldn't take a pin since how we weren't using that one anyways. You're the only one that was asking for FC connector though Memblers, so I'll most likely do it how you see best. One free option could be to provide solder jumper for selection of analog or digital input to the MCU.
Now for everything else here's what you've came up with previously:
Memblers wrote:
Regarding the expansion pins on NES cartridges, that normally aren't used. It's time to use them, here is what I'm proposing:
Code:
EXP0: in - CopyNES mapper disable
EXP1: I/O - CAN bus H
EXP2: out - A0 (PRG)
EXP3: out - A1
EXP4: out - A2
EXP5: out - /CE for parallel port device
EXP6: out - audio out
EXP7: Ground
EXP8: I/O - CAN bus L
EXP9: out - PRG R/W
Originally I thought I would use EXP7 for audio in (from the NES), it'd be nice to have but I'm not sure it's needed. So I put another ground there, to give the CAN bus some help (and maybe hope for higher speeds).
This standard would apply to both expansion port devices, and NES cartridges (and requires both to work, of course). So I'm curious if anyone has any thoughts on it, or other alternatives.
I think we're all agreed to make EXP0 mapper disable, and since I see this as a common "multiuse" pin I think it would be good to give it one of the 3 pins we have left. Leaving us with 2. (This is what I also wanted to assign to FC "audio in" pin 45)
If someone were actually making use of the CAN bus then you'd like it to be I/O for the MCU. So those could be the last two free pins. (EXP1 and EXP8)
And if you were thinking EXP7 as an additional ground then it would be a good candidate for not being assigned. Just leave a connection for it on the side of the board for the user to do whatever they please.
This leaves EXP2,3,4,5,9 and EXP6 which is already made use of with Audio out, but that doesn't mean someone couldn't want to use it for something else.
So I'm trying to see how to best integrate what I have with what you have in mind here with what we're doing here. By "out" I'm assuming you mean out of the cart and "in" whatever's connected to the EXP bus. Your assignments are all OUT when I was thinking of them as more of an IN. The real difference here would be using a shift register vice d flipflops (or just tieing them to the data bus which sounds like a bad idea)
While I can see why it would be OUT for use in a console, I can't see why they would be anything but IN for a dev cart. I'm thinking of using a octal D flipflop with tristate outputs. That way we could reach the rest of the pins and have some flipflops left over for something else possibly. The use of tristate outputs would allow them to be invisible to the cart, to prevent any issues if the user wanted to do something completely different there wouldn't be any damage. Granted the /OE of the flipflops would then need something to drive it (MCU pin, switch, or jumper) I would lean toward just placing pads on the board that we would plan to solder bridge for now, but could be used to implement a switch or something else in the future.
I know it may seem like we're scope creeping a lot here. But these EXP pins are really of little to no cost right now, aside from talking. If we're smart with them now a few of these simple things would really open up possibilities for what someone could do with this thing in the future. So if you've got an idea/opinion lets hear it! I have a feeling we'll end up pushing a few weeks until I can test out the retropak boards and bootloader anyways which I think would be fairly important to most of us.
Previously I've used bootloaders that always check for active communications when powering up, but using a switch for it sounds OK too. The former method I've done over RS232, I don't know if going through USB would affect things.
Quote:
I didn't really intend for it to be used for sound. Since how the FC carts don't have any extra pins hanging around and most games don't use the sound pins I figured a developer may want to use the sound pins for other features like mapper disable which would seem highly desirable for someone developing on UNROM or whatnot.
Problem is that they are always used. When there's not a sound expansion, the audio in and out pins are shorted together to pass the audio through.
But yeah, if there's an ADC pin free, then connecting the audio out couldn't hurt anything. Anyways, if I make an FC dev board, the mapper registers aren't going to overlap memory, so nothing special will be needed.
Quote:
While I can see why it would be OUT for use in a console, I can't see why they would be anything but IN for a dev cart.
Right, there are a lot of outputs from the cart. You probably know that the data bus is shared with the exp port, so when the cart is in the NES there is plenty of I/O since this standard provides the /CE and even some address lines. Other than the mapper disable, I just can't imagine what kind of input a cart could possibly use though, when it's outside the NES. Maybe in-circuit programming for an MCU or CPLD, but stuff like that I believe is better served by adding a dedicated connector to the cart and leaving the EXP pins free. Such as the programming voltage you mentioned, it makes more sense (IMHO) to have it on another connector instead of through the EXP connector. Mostly since it's all more of a one-time use thing (when initially building the cart) that is pretty boring for normal users. But programming voltages are a thing of the past, that would have been more useful 20 years ago instead of today, heheh. In fact, I believe there were some Atari 2600 carts (I wouldn't call them dev carts, more like homemade OTP bootlegs) where the cart does plug into a stand-alone programmer to burn an onboard ROM.
No big deal what happens with the exp pins on this interface really I suppose, sounds safe enough with the tri-state buffer. If there are some I/Os from the MCU left over, I'd hook them up to some status LEDs or something. Everyone can appreciate some blinkenlights.
Main reason I'm so concerned over the EXP port, is that no one else has yet to use it for anything (other than CopyNES in rare cases, and PowerPak sound more commonly, and that dumb unreleased gambling modem thing). The cheap dev cart I'm making will use them however, I just want to make sure if people want to use it with an interface like this I don't have to give them special firmware to do it, or tell them to move jumpers around, etc, sorta defeats the convenience of it all. I don't think people would be too thrilled if the first real use of the expansion port includes multiple standards :/
And yeah maybe that GND connection could be unassigned. I'm just overly paranoid about getting noise in the audio, so I put it next to that. Keep in mind these EXP port signals are planned to come out (with the rest of the EXP signals) on a 50-pin IDC cable (with multiple ends!), which could be kinda long-ish. Since we can't easily fit a board underneath the NES without some kind of fancy physical supports.
At this point I will probably change my mind and go for a full kit instead of just a PCB so you can put me down for one.
Memblers wrote:
Problem is that they are always used. When there's not a sound expansion, the audio in and out pins are shorted together to pass the audio through.
But yeah, if there's an ADC pin free, then connecting the audio out couldn't hurt anything. Anyways, if I make an FC dev board, the mapper registers aren't going to overlap memory, so nothing special will be needed.
No big deal what happens with the exp pins on this interface really I suppose, sounds safe enough with the tri-state buffer. If there are some I/Os from the MCU left over, I'd hook them up to some status LEDs or something. Everyone can appreciate some blinkenlights.
Yeah I agree with what you're saying here. I didn't really see a large use for the EXP pins aside from mapper disable. But I figured if there was board space why not atleast provide the pads on the board for someone to make use out of the EXP pins.
I was kinda thinking along the lines of MCU/CPLD programming too. And you've got a good point about an external connector being better suited. I don't think it would necessarily have to be a one time use though. If someone were using it as a dev cart they may want to program things often. I just thought the idea of using the EXP pins would be nifty, atleast to be available anyways.
Quote:
Main reason I'm so concerned over the EXP port, is that no one else has yet to use it for anything (other than CopyNES in rare cases, and PowerPak sound more commonly, and that dumb unreleased gambling modem thing). The cheap dev cart I'm making will use them however, I just want to make sure if people want to use it with an interface like this I don't have to give them special firmware to do it, or tell them to move jumpers around, etc, sorta defeats the convenience of it all. I don't think people would be too thrilled if the first real use of the expansion port includes multiple standards :/
I'm onboard with the multiple standards. Maybe the best answer is to only standardize the pins already used with copyNES, powerpak, and sound.
Then the standard for the rest of the pins should be more of "rule" like the pins should be able to be grounded without damage. So something like the use of tristate outputs would satisfy this.
I like the blinkly lights idea... I'll have to think about how that could be set up. Maybe if there one were able to have LEDs on the outputs of the Dflipflop I was already using for the EXP pins. I don't know if I want to devote board space to this especially if someone were to mount it in a box they wouldn't want them on the board anyways. Maybe just provide a row of pads on the board for all the EXP pins. Then that would make it easy to add whatever you wanted LEDs, programmers, external devices, whatever your heart pleased.
@SkinnyV I'll plan to get you the full kit.
Well no one's had any gripes about delaying the Kazzo board order, so it looks like the delay and $5 isn't a deal breaker for anyone. So I want to wait until my retrozone boards show up to test the connectors and play around with a simple Flash/dev cart amongst other things left to play around with. My goal is to order everything by the end of the month. I'm expecting a couple weeks turn around time so I'd be looking at shipping kits mid August. Feel free to bump the post if you want an updated status.
And if others becomes interested in a kit the price may be able to come down based on the components. I suspect more people may be attracted with a little devcart testing, so I'll post up my progress as it happens.
Wow, there's a lot to miss in six days
FYI my co-workers are a no-go. They did like the idea, but I get the distinct impression they'll be borrowing mine
I am confused on the CHR /A13 bit. Shouldn't this be high when accessing CHR-ROM? This should always be the inverse of CHR A13.
Please do include an ISP header on the board. That way folks like me can easily work on the firmware. Here are the standard
Atmel Pinouts. The six-pin header is used in current products. The ten-pin header is pretty old. Also, please do not include actual pin headers soldered onto the board, just leave plated-through holes. That way we can solder on male or female headers to match our programmer hardware.
Please check out
BootloaderHID. This is a USB-only self-programming boot loader using the same USB library that Kazzo uses (and therefore can be made compatible with Kazzo's hardware arrangement). Better still it communicates as a standard HID so there are no drivers to install.
qbradq wrote:
I am confused on the CHR /A13 bit. Shouldn't this be high when accessing CHR-ROM? This should always be the inverse of CHR A13.
Yes exactly it's an active low signal. Now I'm not sure it it's always the inverse of CHR A13, because I don't know enough about where those signals are coming from. But the Kazzo gave CHR /A13 a separate signal from A13. Presumably because it uses A13 for the PRG memory also, so for the Kazzo atleast CHR /A13 is not always the inverse of A13 because it's basically CHR /CE.
The issue is when I wired everything up like the schematic asked CHR /A13 was acting as an active high signal. So my easy fix was just swap the signal to the inverted output of the flipflop. I've yet to spend time finding the bug location in the firmware source code to properly fix this.
As far as the 6pin header that was my plan and thanks for bringing up V-USB's bootloader, that's probably the one I'll be implementing.
Okay so I've made some forward progress here guys.
CHR A13 "bug" turned out to not be a bug at all. Really it was just an error in the labeling on some documents mixing up CHR A13 and /A13. Thanks to Farid for posting up his FC NROM schematic I raised the question and coincidentally found my error and fixed my board. I tested out after the fix and it works great. So that will give some more board space which will be nice.
We also were able to write a dumping script for NROM because there wasn't one. So it was nice to sucessfully write a dumping script even though it was a simple one.
We've also been researching on the Flash cart abilities. I found a guy who made a CNROM flash cart and he has a link to "backflips" NROM flash cart.
site:
http://ponrevival.blogspot.com/2010/05/3.html
poor google translation:
http://translate.google.com/translate?hl=en&sl=ja&tl=en&u=http%3A%2F%2Fponrevival.blogspot.com%2F2010%2F05%2F3.html
With this I was able to figure out some of the details about the flashing scripts and commands. I guess there was no need for mapper disabling because NROM and CNROM don't need it. With the CNROM he must have had CHR banks swapping all over the place while he was programming the PRG rom but when programming the CHR rom he must have switched the banks as needed via the normal PRG controlled bankswitching.
I still have testing out the bootloader, I've only been able to look into it thus far. But I hope have that working by the end of the week.
So aside from the bootloader the big thing left to iron out is testing out the dev cart programming abilities of this thing. I think I've got all the script details and wiring needed to be able to atleast test out a NROM devcart. I've got ideas of how to make a mapper disable to be able to support U/A/C/BNROM also making use of EXP0 as a mapper disable. Originally I though I might be able to use the repropak to do this. While it would be possible, it's really not wired up like I need it to be specifically for the /WR signals and making use of EXP0 and what ever hardware I add for mapper disabling.
I'm planning on making myself a "discrete mapper" devcart that would incorporate all this stuff supporting N/U/C/A/BxROM layouts. I would probably use a bunch of dip switches or jumpers to allow for all those layouts somewhat similar to the repropak. I was thinking about using battery backed SRAM because I need SRAM for A/UxROM and it would have to be battery backed for NROM etc. Now I could use Flash for the PRG rom but to keep things simple and similar on both sides I think I'll just stick with SRAM these could be in various sizes as well. I'm thinking 256KB for PRG and 32KB for CHR to support CNROM.
I'm basically looking at this as sort of a lite version of the NESDEV1 that we'll be working on over the next school year.
I was wondering if there was any interest in having me make up more of these to go with the Kazzo (or separatley if you had another use) Really I think Tepples was the only one who expressed interest but he may have been referring to the NESDEV1 with the large mapper capabilities making use of a CPLD.
I'm not certain on the cost of such a cart but the memory should be less than $10 and the board should be $15. A few dollars for discrete parts and shipping and we'd be looking at around $30 as a kit (WITHOUT cart plastics) and with the Kazzo kit included like $75 all together. But really this is around the target cost of the NESDEV1 without all the mapper capabilities. I don't want people to think I'm trying to sell this for my own gain. I don't really expect anyone to buy a simple devcart and dumper especially when most of you already have copyNES and the Powerpak which are vastly more capable than the Kazzo and simple descrete dev cart. I didn't really expect people to ask for the kazzo kit but you have, so I figure I may as well ask if anyone's interested in a dev cart to go with it since how I'm going through all the effort of making one myself it'd be simple enough to order stuff for more of them.
As far as schedule goes, I plan to use the next week to work on the bootloader and some simple devcart stuff. So I should be ready to order kits at the end of the month, as soon as I've got most everyone's money I'll order so assuming that doesn't take long we'd be looking at delivery around mid August.
One thing I was still wondering though, was anyone besides Memblers interested in the FC connector? (there is always the option of a 60 to 72 pin converter) Or any interest in the ability to put the kazzo in the box I found from Radioshack? I think I can make it work now that I can use smaller Dflipflops and only leaving pads for a programmer, but last time I tried to wire a board with a FC connector and clearance to put everything in the box I had issues. So I'd appreciate feedback on this and also the ideas about the EXP bus and everything. I'm leaning towards my earlier idea I posted of just leaving pads so you could wire up LEDs, jumper over to whatever EXP pin you wanted, or whatever your heart desired. But that comes at the cost of board space as well. So let me know what you guys value most.
I would be interested in having the space to solder a famicom connector. I always end up with pirate FC cart that I would be happy to have some way of connecting to the dumper without the use of an adapter. If you can find the space I think it would be useful for some. Look at Farid, he almost only deal with FC cart, so i'm sure some people would use it.
SkinnyV wrote:
I would be interested in having the space to solder a famicom connector. I always end up with pirate FC cart that I would be happy to have some way of connecting to the dumper without the use of an adapter. If you can find the space I think it would be useful for some. Look at Farrid, he almost only deal with FC cart, so i'm sure some people would use it.
Thanks for backup
yes I am only working on Famicom. By the way my name is Farid not Farrid
Sorry, it was typo, I corrected it
Good news!
I got the USB bootloader working just now. It works beautifully! Thanks for the input on adding this guys. I think I'll be including a bootloader on all my projects from now on!
For those unaware what this means: It's super easy to upgrade the firmware on the kazzo. You just plug it in via USB and close a jumper. It enters boot mode and then you're able to use a GUI to select new firmware and load it onto the device. So now you won't need a AVR Programmer in order to make use of any firmware changes. I don't really expect a need for this if you're just using it as a dumper. But it's especially nice if you're looking to do special things with the EXP pins or something like that with a customized dev cart.
I can see it was definitly worth the extra wait!
Alright, well I've played around with this thing enough to call her good. I've figured out most of the details on getting a flash or sram cart working. I got a NROM SRAM dev cart working for the most part using the retrozone board. I had to play around with the wiring and do a 2min ugly battery back up rig that still needs work but I was able to flash Tepples' Croom onto the cart and play it in my FC mobile as you can see.
Not sure how many people are really thinking about using this for devcart programming but I wanted to play around with it a little to find out more of the capabilities it already had. There are a few bugs to figure out with the SRAM cart but they are pretty minor and I think it would actually be easier to use Flash so I may try that soon as well. Basically anago is set up for Flash so it doesn't erase SRAM properly. I didn't expect it to be a big deal but turns out if the byte to program is 0xff it doesn't bother programming that byte. This actually allowed me to make use of the bootloader a bit and prove some versatility with the kazzo. I ended up writing a quick program for the MCU that would cycle through erasing every byte. So I basically used the bootloader to quickly swap between the kazzo firmware and my erasing program via USB and manipulation of some switches/jumpers. But revising the software and recompiling would be a better fix, that was just an easy bandaid that allowed me to test out more features of the kazzo. I've also though about throwing my atmega644 in there and programing a cart directly from storing the rom image on the AVR's program memory just to play around with it and for troubleshooting use.
I've got some other problem where there are 5 specific bytes that aren't programmed properly when I redump the game and compare hex files. But I think that the kazzo tests to see if there is SRAM because it notes there is in the NES header it creates. So it might be killing some of my data to do so, I've got a few other ideas why as well.
Anyways, I'm going to be finalizing the board layout in the next couple days and start collecting everyone's money. As soon as the money comes in I'll make the order for boards and parts. I'd like to get the money this week and order next week. To make it easy I'd appreciate if everyone interested could shoot me an email with any details of what you'd like. Then I'll send paypal bills to that email. I'll track down people and see if there is still interest but this would make it easier for me. Let me know if you have any issues with coming up with the money I'll see what we can work out. email:
paul@infiniteneslives.com
I'll post the board layout here for people to take a gander at. But I'll be keeping a FC connector and adding a few buttons/switches for reset and bootloader I really wished I had them working on this so I'll be putting them in. I might ditch the radioshack project box if anything, didn't get much interest in that, you could always fit it in your own larger case if one desired.
Thanks for the emails so far guys I'll be following up on those in the next day or so confirming individual prices and start billing through paypal.
So I've come pretty close to finalizing a circuit with your guys' input. I'm keeping the FC connector, have access to all EXP pins with the lessened chip count of solving the CHR /A13 "bug". Playing around with the bootloader alot recently showed how necessary a reset button and bootloader switch was. I've also added a single LED for indications that helped me out a lot with debugging.
The thing I think I'm going to have to ditch though is the use of that specific box from Radioshack. Didn't seem like too many people were interested and you could always throw it in some other enclosure if you really wanted one. I'll figure something out for you Tepples like I promised.
So just so everyones clear on the parts included in the kit:
PCB
72pin connector *2.54mm pitch*
Atmega164P 40 pin DIP (with both the bootloader and kazzo firmware programmed on and tested.)
2x 74HC374: D flipflops 8 channel, with non-inverted tristate outputs. One is for the high address bits and the other for EXP pins. I also made it so you could tristate the outputs going to the EXP pins by control with the AVR.
USB cord- no socket just strip and solder to pads on board
discrete: 16mhz res, resistors, diodes, LED.
IC socket strip for the microcontroller (like my original picture)
SPDT switch for bootloader
tactile momentary switch for reset
shipping of course
Total cost for unassembled kit all parts above: $42 (original quote with cost of $15 PCB, we couldn't get the discount)
I didn't include the FC connector or the box from radioshack. I found 60 pin connectors from digikey for about $4. I haven't tested them but they're are 2.54mm also and from the same manufacturer
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&itemSeq=101992933&uq=634474221142130779
I'd bet money they'll work but can't guarantee it at this point. If you wanted to add it to your order just add $4 to the cost.
Fully assembled kits with no enclosure. Basically all the parts above soldered together and fully tested. I'll just stick with my original quote for $55.
Anything outside of this let me know what you'd like. So far I've gotten emails from:
qbradq
Memblers
SkinnyV
Tepples
From what I recollect NESOLDjunkie was the only other one interested. If anyone else is now's the time to speak up. I want to order the boards and parts over the weekend/Monday morning.
About the USB connection, it would be nice if the pcb still had the contact to solder a USB socket for those that would prefer that to soldering the wire directly.
SkinnyV wrote:
About the USB connection, it would be nice if the pcb still had the contact to solder a USB socket for those that would prefer that to soldering the wire directly.
Yeah I was kinda thinking about that. Space is already tight as it is on a 2x4in board with keeping the FC connector. I may need to increase to 2x4.5in anyways to keep everything already planned. If I can find room I'll put it on there. But really I have a hard time seeing the benefit of the added cost.
Well I didn't think it would be adding cost to it. Personally I would prefer having a place to solder the socket otherwise I'll have to live with a dangling socket not attached to board. No big deal but I wouldn't want to use it with a directly soldered USB cable as I have multiple device that use the USB power and I like just swapping the USB cable between the device. It's not a big deal if you can't implement space for it if it is adding cost, I did not know we were so tight on board space.
I agree a USB socket would be preferable, but as I can't source them locally I am fine soldering cables directly onto boards. I've done it quite a few times
I'll see what I can do. The socket itself is $1.35 on digikey for a standard B sized socket. Smaller sizes are around $3-4 and I don't have the cords on hand but I wouldn't necessarily need to supply a cord since I'm guessing most people have extras sitting around. I guess it's really a matter of preference. Personally I hate to track down cords and like it when they're attached permanently.
Permanently attached (or "captive" in USB parlance) cables often tend to be way too short, needing a hub as an extension. If you can't fit the USB B jack on the device, perhaps it could have a USB B jack on a 6-inch permanently attached cable.
tepples wrote:
Permanently attached (or "captive" in USB parlance) cables often tend to be way too short, needing a hub as an extension. If you can't fit the USB B jack on the device, perhaps it could have a USB B jack on a 6-inch permanently attached cable.
I had planned on a 6ft USB cable because that's what I've got sitting around. But it looks like pretty much everyone would like to have the socket so if we need more board space so be it. I think I'll just make it work with the standard sized USB B socket and then you guys can just supply your own cord with whatever length you prefer and I'll be able to keep the price the same. Sound good?
Sound good to me! You don't even have the include the socket, people that want it will easily be able to find one and people that doesn't need one are still going to be able to solder the cable directly.
I cannot easily source a B connector. I would have to order one. Either way it'll work for me though. I don't mind captive cables.
The kit will officially have B connectors now instead of cables
Thanks for making it work out with your board design! I wonder if anyone will give coding new script a try. Personally, I will be limited by what's already available as I lack the knowledge to do such thing but it will be interesting to see what people with skill will come up with. Too bad there's no way of just using the already made copynes mapper support file though!
SkinnyV wrote:
Thanks for making it work out with your board design! I wonder if anyone will give coding new script a try. Personally, I will be limited by what's already available as I lack the knowledge to do such thing but it will be interesting to see what people with skill will come up with. Too bad there's no way of just using the already made copynes mapper support file though!
I was able to make the USB work fairly well because the majority of the socket is designed to hang off the side of the board. So it wasn't that big of a deal in the end.
For the scripts like I've posted here I have already written NROM dumping and Flashing scripts. They aren't too bad. But I was wondering where we should keep scripts that we've written so we can share them with others? Let me know and I can post up the ones I've done so far. I can do up some sort of txt for the command arguments I've got a grasp of so far also. There is documentation out there like I said but it's all in Japanese for the most part.
I've got some pictures for you guys. To give you an idea what it'll look like. I'll send paypal bills now, once I find out who wants a 60pin connector in the kit as well. Like I've said before I haven't tested them, but expect them to work. And they are an extra $4.
Final costs:
unassembled NES kit: $42 (still has pads for FC connector if you wanted to add later.
Addition of FC connector $46
Assembly: $10
There wasn't much interest in fitting in those radioshack boxes but it should still fit. The final board is 2x4.1" There would be a little bit if cutting to do internally to make it fit but there are always other enclosures if you really wanted one. Nothing really says you need one aside from setting it on top of a coin or something conductive.
Sweet, I haven't been on for awhile, decided to check on this and BAM! sweet, I'll shoot you an e-mail later tonight or tomorrow...
So I ordered the boards last week and paid for them. I'm still waiting on payment from Tepples and OldNESJunkie before I make the order from Digikey for the rest of the parts.
I need to know whether you guys want to pay the extra $4 for a 60pin or not. and what email address to send the paypal bill.
Please send me an email without using the email link. I haven't gotten responses from either of you when I reply to emails you've sent me in that manner.
Please email me directly outside of nesdev:
paul@InfiniteNesLives.com
OldNESJunkie wrote:
Sweet, I haven't been on for awhile, decided to check on this and BAM! sweet, I'll shoot you an e-mail later tonight or tomorrow...
I tried to reply to your email but the email address tied to the nesdev email failed.
Alright I've got everyone but OldNESJunkie. I'm going to order the parts today or tomorrow. If I don't hear from you by then OldNESJunkie I'm just going to assume you don't want the FC 60 pin connector.
I'm hoping I'll get the boards back around the same time the parts show up and I'll be able to ship late next week or there abouts.
infiniteneslives wrote:
Alright I've got everyone but OldNESJunkie. I'm going to order the parts today or tomorrow. If I don't hear from you by then OldNESJunkie I'm just going to assume you don't want the FC 60 pin connector.
I'm hoping I'll get the boards back around the same time the parts show up and I'll be able to ship late next week or there abouts.
Are you going to do more than 1 run on these? Im interested in one but dont have cash at the moment. Thanks
Tormenter wrote:
infiniteneslives wrote:
Alright I've got everyone but OldNESJunkie. I'm going to order the parts today or tomorrow. If I don't hear from you by then OldNESJunkie I'm just going to assume you don't want the FC 60 pin connector.
I'm hoping I'll get the boards back around the same time the parts show up and I'll be able to ship late next week or there abouts.
Are you going to do more than 1 run on these? Im interested in one but dont have cash at the moment. Thanks
I would be willing to do more runs of them. I figured after these get out to a couple people it will spark more interest. It all really depends on what people ask for. I'll need minimum 3 people interested before I make another run though, so if anyone else is interested just let me know.
Update: The boards and parts are all ordered to be here late next week. So kits should be able to get out on the 20th-22nd
Parts showed up today. Checked out the 60pin connectors and they look really good. The pitch difference is very slight with only 60 pins. I did a quick check for shorts with my multimeter and a couple FC games and everything was good.
Still waiting on the boards that are supposed to show up late this week. I'll post up when they do and fully test the 60 pin connectors.
@OldNESJunkie: I'm still waiting on you email and payment. I can't promise how long I'll keep it around waiting on you. I've got money invested with your kit, so if someone else offers to buy it I'll be quick to take them up if I still don't have your email address. Don't use the email button because it provides an email for you that's invalid. Email me directly please:
paul@InfiniteNesLives.com
Well I've got some disappointing news. Apparently there are some new features with design spark PCB layout tool I used that the board manufacture's computers don't recognize and the boards are missing the top layer of copper.
But good news is it wasn't my fault so he had me resubmit the board with a modification to the gerbers. So it looks as though we're set back two weeks. Sorry guys, not much I can do.
On a side note if there happens to be a couple people interested in a board or kit in the future let me know. If I've got three people interested like @Tormenter I may order 3 more boards with this run. I'm guessing not, but figured I would check.
So the board files have been sent off again with the fix. I went ahead and made a few minor changes mostly to the silkscreen adding some labeling and stuff. I did make a few clearance changes and added some board mounting holes. So while the set back of two weeks was a downer, the constellation was I had a chance to get the board in my hands and place all the components. By doing such I of course had several ideas what would be nice to add, and you all will get it in the final product.
And I have been able to get in contact with everyone that's signed up for the kit now. And they are scheduled to show up here Sept 3rd. So I should be able to ship everything Monday the 5th.
Here's some pictures from playing around with the layout. BTW the deep purple board color seems coincidentally fitting for the nesdev color scheme
Wow this is really awesome!
Is this project free? If so please provide PCB layout file and software.
FARID wrote:
Wow this is really awesome!
Is this project free? If so please provide PCB layout file and software.
Yeah check it out here:
http://sourceforge.jp/projects/unagi/wiki/kazzo_intro_en
I've got the .pcb and .sch files for the modified version I'm providing here. What's the best way for me to share those with everyone?
Looks so cool!
こんにちわ。kazzo を設計した naruko です。時々覗いていましたが、写真を見てうれしかったです。
一つお願いがあります。revision を 3.0 にしていますが、私が1年前に採番しています。作り直すことがあれば、 1.1 以降を使ってください。最初の数字はいままで公表していませんが、利用した MCU で決めています。
1.x Atmega16 or Atmega164P (40pin)
2.x Atmega168 or Atmega168P (28 pin)
3.x Atmega8U2 or Atmega16U2 (AVR USB 32pin)
8U2 を利用した reivision 3.0 は作りかけたまま、開発の資料や時間が整わず私の部屋で眠っています。
Very nice! You really seem to have done a great job at this infiniteneslives! Look very clean and professionnal and the PCB look amazing. And the nesdev themed color is a plus
I'm very happy to see this thing becoming a reality and can't wait to see what kind of support the nesdev community will give in regard to new script/plugging writing. This is an exciting time indeed.
I wonder how much it'd cost to get these mass-produced to sell to the general public as a legit source of ROMs for emulators on PCs and smartphones.
What would be cool would be to add support for sega genesis and snes, at a later point in the future of course. Then it would be a kick ass alternative to the retrode. Correct me if I'm wrong but dumping support for snes (with exception of special chip like sa-1, sdd-1, cx4 and the like) or genesis cart wouldn't be too complicated for a device like the Kazzo. I mean, the hard part is already done for dumping nes cart and I'm sure people will start sharing custom dumping script for unsupported mapper once it get shipped out so new console support could be something cool to hope for in the future imo.
naruko wrote:
Looks so cool!
こんにちわ。kazzo を設計した naruko です。時々覗いていましたが、写真を見てうれしかったです。
一つお願いがあります。revision を 3.0 にしていますが、私が1年前に採番しています。作り直すことがあれば、 1.1 以降を使ってください。最初の数字はいままで公表していませんが、利用した MCU で決めています。
1.x Atmega16 or Atmega164P (40pin)
2.x Atmega168 or Atmega168P (28 pin)
3.x Atmega8U2 or Atmega16U2 (AVR USB 32pin)
8U2 を利用した reivision 3.0 は作りかけたまま、開発の資料や時間が整わず私の部屋で眠っています。
Google translation: Looks so cool!
Hello. I'm naruko who designed the kazzo. Peeps were sometimes glad Look at the pictures.
One might ask. 3.0 has to revision, and a year ago and I Numbering. If you have to recreate, please use the 1.1 and later. The first number is not published until now, has determined that use of the MCU.
1.x Atmega16 or Atmega164P (40pin)
2.x Atmega168 or Atmega168P (28 pin)
3.x Atmega8U2 or Atmega16U2 (AVR USB 32pin)
Reivision 3.0 times using the 8U2 is still building, sleeping in my room 整Wazu development resources and time.
Thanks for commenting naruko! I didn't realize you were here on the forum, I should have checked. I've had several questions I meant to ask but didn't try to ask mainly due to the language barrier. I'll try to do so by use of PMs in the near future.
I appreciate the clarification on the revision numbers. I only saw 1.0 and 2.0 and decided to name mine 3.0 without much thought. So this version of the kazzo shall officially be Kazzo 1.1 nevermind the print of 3.0 on the board
I'll make that correction for any future runs or builds.
SkinnyV wrote:
Very nice! You really seem to have done a great job at this infiniteneslives! Look very clean and professionnal and the PCB look amazing. And the nesdev themed color is a plus Laughing I'm very happy to see this thing becoming a reality and can't wait to see what kind of support the nesdev community will give in regard to new script/plugging writing. This is an exciting time indeed.
Thanks again for asking me to do this SkinnyV, I've had some fun with it. Yeah the purple PCB is really just a coincidence the supplier let's you choose any color you'd like just as long as it's purple
tepples wrote:
I wonder how much it'd cost to get these mass-produced to sell to the general public as a legit source of ROMs for emulators on PCs and smartphones.
Price could be cut a lot lower by using surface mount parts and the atmega8/16 from the 2.0 and 3.0 versions. It would also allow for the board to be smaller. Even the connectors price is cut in half with quantities in the 100's. I would guess it could be made for a cost of around $15 if a couple hundred were made and sell for $20-30. But I'm just throwing numbers out there.
SkinnyV wrote:
What would be cool would be to add support for sega genesis and snes, at a later point in the future of course. Then it would be a kick ass alternative to the retrode. Correct me if I'm wrong but dumping support for snes (with exception of special chip like sa-1, sdd-1, cx4 and the like) or genesis cart wouldn't be too complicated for a device like the Kazzo. I mean, the hard part is already done for dumping nes cart and I'm sure people will start sharing custom dumping script for unsupported mapper once it get shipped out so new console support could be something cool to hope for in the future imo.
I don't know a lot about SNES/Sega, but I think it would almost be simpler than the NES. The main reason being the mappers, from what I under stand that's why the retrode doesn't attempt NES.
By quick glance SNES only has 24 address lines, 16 Data, and 14 some control signals. Sega's about the same. So the kazzo could easily be adapted to connect up even if you sucked up 16 pins for the data bus. You could just I/O extend with a few more D-flipflops for the high address lines and uncommon control signals similar to what's done with the Kazzo.
They're HERE!
I slapped one together and am going through trying to test everything out before I send em off. Even after triple checking everything a mistake still got through... I swapped up the D+ and D- pins on the AVR
Good news is it's an easy fix. I fixed the one by cutting the two traces and making the two connections manually that are only about 1/4" and 1/8" long. The other tricky way is to solder the two resistors in funky. Basically they were intented to be parallel to eachother, but really the board is wired up to have them criss-cross each other or they could wrap around one another. Either way there is still room and clearance for the AVR above.
For the guys getting kits just let me know what you'd like to do. I'll do whatever you'd like. I'll even solder in the affected components however you prefer if you feel uncomfortable about it. Just let me know.
EDIT: oh and the FC 60 pin connector works great too.
If I understand correctly it is fixable just by crossing the resistor? If so, not a big deal IMO.
SkinnyV wrote:
If I understand correctly it is fixable just by crossing the resistor? If so, not a big deal IMO.
Yeah that's it. Not a big issue just more of an embarrassment.
Haha well that was to be expected, you really tried to make that board fast and you were dealing with a lot of stuff at the same time for ordering part etc... Could have been way worse!
I was wondering though, how long does it take for someone to figure out and write a plugging for an unknown mapper? I mean someone with knowledge of such thing. I realize it is very relative and will depend on a lot of factor but I'm just trying to get an idea of the work involved.
SkinnyV wrote:
Haha well that was to be expected, you really tried to make that board fast and you were dealing with a lot of stuff at the same time for ordering part etc... Could have been way worse!
I was wondering though, how long does it take for someone to figure out and write a plugging for an unknown mapper? I mean someone with knowledge of such thing. I realize it is very relative and will depend on a lot of factor but I'm just trying to get an idea of the work involved.
Yeah I'm still happy with how they turned out, I guess these could be considered "limited edition"
It's also convenient that they are under the AVR so you actually can't even see the error and it's fix if you do the resistor cross or wrap around fix.
That's kinda a tough question to answer. The scripts would seem to be fairly simple for someone thoroughly knowledgeable with the NES and the mapper under question. I found the NROM mapper script online and have since become a little more familiar with the scripts with that I was able to modify the UNROM script to UOROM but that was a super simple change. The only script missing to allow dumping for the most common mappers is MMC1. There is a SLROM script but nothing for SEROM of the other common boards. I'm sure it would be an easy adaptation to make scripts for the other boards but I haven't spent any time with it yet.
This is probably the best site to help explain the scripts (google translated), other than that I referred to the source code when I played around with the flash scripts.
http://translate.google.com/translate?hl=en&sl=ja&tl=en&u=http%3A%2F%2Funagi.sourceforge.jp%2Fcgi-bin%2Fhiki%2Fhiki.cgi%3Fhow%2Bto%2Bdescribe%2Bmapper%2Bscripts
Here is my uorom.ad script all I had to do was change the cpu rom size of the UNROM.ad. But I think there is another way to do it by denoting 2x size of the UNROM script.
Code:
board <- {
mappernum = 2,
cpu_romsize = 2 * mega, cpu_banksize = 0x4000,
ppu_romsize = 0, ppu_banksize = 0x2000,
ppu_ramfind = false, vram_mirrorfind = true
};
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize - 1; i += 1){
cpu_write(d, 0x8000, i);
cpu_read(d, 0x8000, banksize);
}
cpu_read(d, 0xc000, banksize);
}
I thought it would have been provided with the code download but it wasn't. So here's a nrom.ad script I found here some kind of project page with flash carts and stuff:
http://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Fbakutendo.blog87.fc2.com%2Fcategory14-1.htmlnrom.ad (note: .ad is for dumping scripts and .af is for flash scripts)
Code:
board <- {
mappernum = 0,
cpu_romsize = 0x8000, cpu_banksize = 0x4000,
ppu_romsize = 0x2000, ppu_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)
{
ppu_read (d, 0, banksize);
}
nrom.af
Code:
board <- {
mappernum = 0, vram_mirrorfind = true,
cpu = {banksize = 0x4000, maxsize = 0x8000},
ppu = {banksize = 0x2000, maxsize = 0x2000},
};
function initalize(d, cpu_banksize, ppu_banksize)
{
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)
{
cpu_program(d, 0x8000, cpu_banksize);
cpu_program(d, 0xc000, cpu_banksize);
}
function ppu_transfer(d, start, end, ppu_banksize)
{
ppu_program(d, 0x0000, ppu_banksize);
}
There's some other project pages that can be found with some simple google searches. Just be ready with the translator
Thanks for the info, I'll read a bit about it but I really doubt this is within my realm as I do not know any programming language and lack the required knowledge for such a thing. I was asking because I have a bunch of pirate famicom cart from the same maker (or at least it look that way) that I would like to be able to dump with the kazzo.
Memblers and SkinnyV your kits shipped out today.
OldNESJunkie and Tepples yours will ship on Tuesday.
A note on the bootloader: So I actually was able to corrupt the bootloader sector the other day playing around with the bootloader software. It resulted in needing to reload the bootloader firmware with an AVR programmer. Not a great situation if you don't have one, but I would be happy to help out reloading it for someone who may have an issue.
I'm not certain but I think it happened as a result of not following the 3 steps in the HIDbootflash software. First you connect to the device, then select .hex file to be loaded, and finish by flashing the AVR. I was being a little sloppy and disconnected before flashing. So when I reconnected the software still was in the connected state and let me try to flash even though I should have reconnected. The flash failed and then I couldn't reconnect no matter what I did.
It shouldn't really be an issue especially if you never play around with the bootloader and it's software. But just be aware if you do, to flow the proper steps if in doubt just reconnect before trying to flash. But aside from that one time I've swapped back and forth from the kazzo firmware and my own firmware dozens of times with ease.
EDIT: here's some pictures of all that's included with the kit (FC connector optional)
the purple pcb looks so cool
Had some requests for the .pcb and .sch files I've also included the library files I created with all the NES/FC connectors and everything. I used Design Spark to create the boards
kazzo rev1.1
How can I open the files?
I coundn't use Protel 99 and Proteus to open them. Which software (and version) should I use?
FARID wrote:
How can I open the files?
I coundn't use Protel 99 and Proteus to open them. Which software (and version) should I use?
http://www.designspark.com/
Current version is what I used
I just want to make sure, is it DesignSpark PCB version 2 with 73.3MB size and free?
http://designspark.eu/downloads/released/programs/Setup.exe
FARID wrote:
I just want to make sure, is it DesignSpark PCB version 2 with 73.3MB size and free?
http://designspark.eu/downloads/released/programs/Setup.exeShould work. You'll have to add the library files to see the connector and a few other things. I think I may have put the switches and other items in a different library though. If its an issue let me know which components and I'll gather up those libraries as well for you.
I just received my kit today and went straight to assemble it. Only problem I had was I soldered the cap without thinking it needed to be layed flat since the MCU is right on top:) I hope it didnt break because I had already cutted the excess pin so It was a challenge to get it to lay flat with the little ammount of pin lenght left. Oh well it would be trivial to go buy another cap in case of a problem anyway. I didn't had the time to really test it past installing the driver and using the test executable coming with the software package and even then I'm not sure if it told me it was find or not. Only thing is the led doesn't light up. I'm pretty sure I soldered it the right way though. Is it supposed to light when the switch is set to ON or to show transfer activity?
SkinnyV wrote:
I just received my kit today and went straight to assemble it. Only problem I had was I soldered the cap without thinking it needed to be layed flat since the MCU is right on top:)
Sorry about that I shouldn't have assumed that was obvious to people besides myself. If you need an extra cap I'll send you one no problem just say the word.
Quote:
Only thing is the led doesn't light up. I'm pretty sure I soldered it the right way though. Is it supposed to light when the switch is set to ON or to show transfer activity?
The led isn't in the current version of kazzo firmware. That's something you guys requested so I added into the hardware. So it never actually lights up if you don't touch the firmware. I've been playing around with the bootloader making my own simple firmware programs to do things like erase dev carts or overwrite single bytes and such. For things like that you can easily make use of the LED and I have for simple indication/debugging purposes. Make sure you put the LED in properly though. If you look inside the lens of the LED the fat internal lead is the ground side.
Also don't worry about any of the jumpers with the current firmware. I need to formally put everything together this weekend about what changes I made to the circuit so someone could figure out how to make use of them with firmware upgrades or their own firmware.
I got mine tuesday and assembled it. I haven't had time to do much of anything at home lately, I need to catch up on stuff..
Seems to work somewhat OK, I got a lot of bad dumps but got good ones eventually. The bad dumps were almost always 100% different even when I didn't touch anything between attempts. On one bad dump, only the first 256 bytes were bad (software bug?). I'm surprised that the connector works, but it seems to. No shorts, even if I slide the board towards either side.
Pretty cool device, but it definitely doesn't compare favorably to CopyNES (except for it being a convenient little stand-alone device). It's virtually impossible to get a bad dump with CopyNES (you can play the game before/after dumping it - bad connections are a huge problem with NES, as we all know). I was also a little surprised by how slow this is - it took about 19 seconds to copy 128kB of PRG-ROM, which is about 7kB/sec. CopyNES (original version) I guess transfers around 30kB/sec, but I don't know how fast the USB CopyNES clone is.
Hopefully it could get better with some software updates.
Tanks for the offer about the cap, I don't think it is broken and if it were I have an electronic part shop 5 min away from my house that sell anything and everything. I was just too excited to assemble it that I didn't think of the space needed for the MCU:) I just started playing with it but couldn't find my old nes cart at the moment and all I had to test was a Vegavox music album cart from Alex Mauer, Super Mario Bros. and a famicom UNROM socketed cart that I use with EPROM or flash chip. I was able to dump duck tale from the Famicom dev cart without problem. Well, except for when I carelessly put my flash chip backward and it started to overheat like crazy with the smell of burned silicon and plastic but that was my own mistake and not something that could happen with regular cart:0 Surprisingly, the chip was ok, the data was all wiped out but it was fine after cooling off and being erased by my eprom programmer. As for the Vegavox and Mario cart, I might be stupid but couldn't figure out how to dump those as I couldn't find any script for such a board.
Memblers wrote:
Seems to work somewhat OK, I got a lot of bad dumps but got good ones eventually. The bad dumps were almost always 100% different even when I didn't touch anything between attempts. On one bad dump, only the first 256 bytes were bad (software bug?).
What mapper are you dumping off of? I've never had an issue with different dumps without touching anything. Usually if I have a bad dump it's because of a dirty connection and a good blow and replug solves the issue.
Quote:
I'm surprised that the connector works, but it seems to. No shorts, even if I slide the board towards either side.
Seeing is believing
I know I there was a lot of doubt for most people to whether they worked as well as I claimed, but it's hard to deny when you see it yourself.
Quote:
Pretty cool device, but it definitely doesn't compare favorably to CopyNES (except for it being a convenient little stand-alone device).
Yeah I had intentions to get a CopyNES for quite awhile. I like the kazzo because it's cheap and isn't proprietary like the USB CopyNES. And you don't have to hack up a NES to make it. But it does come at it's cost of speed and short comings in the mapper support.
One of the big things I like about it is by use of things like the bootloader you can quickly and easily interface a mcu with a cart. Mainly a plus for me since I've yet to get up to speed programming on the NES.
Quote:
Hopefully it could get better with some software updates.
That's one of the big things I'd like to see as well.
SkinnyV wrote:
As for the Vegavox and Mario cart, I might be stupid but couldn't figure out how to dump those as I couldn't find any script for such a board.
What mapper does the Vegavox use? Which version of SMB? There are several different mappers SMB was built with: NROM, MHROM, MMC1 (SFROM) which one you've got would dictate which mapper script you needed and the only one on that list with a script currently written is NROM. So we'd have to get a script together if you had anything besides the standalone SMB.
I figured it was NROM but if you are saying there is different version, I am not sure. To be honest I am too lazy to go get my gamebit to open it up since I have no interest in actually dumping it and was only using it to test the kazzo as it was the only cart I found at the moment. As for the vegavox, I'm pretty sure it's NROM too. To be honest I am surprised to hear dumping SMB could be something unsupported, I figured it would be the most trivial cart to dump. I couldn't find any NROM script in the available one though unless I missed something.
SkinnyV wrote:
I figured it was NROM but if you are saying there is different version, I am not sure. To be honest I am too lazy to go get my gamebit to open it up since I have no interest in actually dumping it and was only using it to test the kazzo as it was the only cart I found at the moment. As for the vegavox, I'm pretty sure it's NROM too. To be honest I am surprised to hear dumping SMB could be something unsupported, I figured it would be the most trivial cart to dump. I couldn't find any NROM script in the available one though unless I missed something.
Yeah I was suprised about there not being a nrom.ad file included as well...
That's why I posted it
infiniteneslives wrote:
nrom.ad
Code:
board <- {
mappernum = 0,
cpu_romsize = 0x8000, cpu_banksize = 0x4000,
ppu_romsize = 0x2000, ppu_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)
{
ppu_read (d, 0, banksize);
}
Well, I received mine today, but I feel like a tard since I cannot figure out how to use it, cannot get Win7 to install the driver from the Kazzo sourceforge page. I'm sure it's probably me, but any help would be great.
EDIT:
OK, with InfiniteNESLives help I was able to get this working on my laptop with Win7 64-bit without issue so far. My problem was the switch was flipped to bootloader mode, um heheh.
infiniteneslives wrote:
I got it installed on my Windows 7 64bit machine this evening. I ended up creating a driver for it with libusb inf wizard. But I'm having an issue dumping games. It stops in a different place every time but usually early on. I was able to get several dumps successfully but it's not stable. I'm not sure if it's an issue with the driver or what. It still works great on my netbook still. It's giving me a message: "device_read" "No error" but something is obviously wrong because I don't even get a partial rom image. IDK I'll have to play around with it some more.
I had to go here:
http://sourceforge.net/apps/trac/libusb-win32/wiki to get the driver working like I said above.
But I was still having an issue where I was getting a device read error before the dump even starts or half way through. If I tried over and over I could eventually get a full dump. I don't know if it's an issue with my computer or what. I'm running windows7 on a 64 bit machine. I haven't had an issue once with my 32bit XP machine.
Thansk for the nrom script, the thread got so long I forgot you posted it before. I was able to dump Duck Tale (UNROM) and Vegavox (NROM) without issue. Now I'm trying to figure out how to flash a cart as the documentation say it should be possible to just program a flash chip that was soldered in a game cart. I can't seem to find the supported flash chip list though. I have a 256k winbond and 256k amic but as of now didn't managed to flash it using the kazzo. I'll continu to play with it though. I just wish I could write script to dump some of my pirate famicom cart. Can you do some mapper research with the kazzo like you can with copynes?
SkinnyV wrote:
Thansk for the nrom script, the thread got so long I forgot you posted it before.
No worries, I have a hard time finding things I posted myself on this tread.
Quote:
Now I'm trying to figure out how to flash a cart as the documentation say it should be possible to just program a flash chip that was soldered in a game cart. I can't seem to find the supported flash chip list though. I have a 256k winbond and 256k amic but as of now didn't managed to flash it using the kazzo.
This is the best resource for flash carts. If you google around or look back on this tread there are some japanese sites with NROM, CNROM, and UNROM flash carts but they aren't of much help explaining how it all works.
Translated:
http://translate.googleusercontent.com/ ... yo3yvzOtkQI used battery backed SRAM for my flash cart because it's simpler with the whole write command issues of flash memory. The flashdevice.nut file is where you can see all the flash memories currenty supported. That's the file you'd have to modify to add a option for your flash. Look through the ones there and you might find a different brand or something that has the same write commands and page sizes and such and just use that one if you're lucky.
Quote:
I just wish I could write script to dump some of my pirate famicom cart. Can you do some mapper research with the kazzo like you can with copynes?
What game is it? Do you know anything about the mapper? Are there already dumps of that game out there?
I'm not sure what you mean by research. Does the copyNES have functions to investgate the operations of an unknown mapper? You could conceivably do something like that with the kazzo but you'd have to write all the scripts and programs yourself and share. There's nothing already set up like that to my knowledge.
By mapper research I ment a way of visualising or debugging to figure out how to dump the cart. The pirate cart in question were all made recently in 2011 and their mapper is unknown as far as I know. There's nothing too special about them except maybe for a 4 in 1 pokemon cart with what seem mostly bad gfx hack but also what appear to be a realy crappy HKO pokemon sidescroller and clone of dragon ball z super butoden (wouldn't be surprised if this one was dumped). Not much to be learn by opening them as they have the tiniest pcb I ever seen in a gamepak with only a single small glop top and nothing else but some of them still hold complex game like a 4 in 1 nekketsu game that normaly use different mapper.
SkinnyV wrote:
By mapper research I ment a way of visualising or debugging to figure out how to dump the cart. The pirate cart in question were all made recently in 2011 and their mapper is unknown as far as I know. There's nothing too special about them except maybe for a 4 in 1 pokemon cart with what seem mostly bad gfx hack but also what appear to be a realy crappy HKO pokemon sidescroller and clone of dragon ball z super butoden (wouldn't be surprised if this one was dumped). Not much to be learn by opening them as they have the tiniest pcb I ever seen in a gamepak with only a single small glop top and nothing else but some of them still hold complex game like a 4 in 1 nekketsu game that normaly use different mapper.
Yeah sounds like you've got yourself a bit of a challenge there
Thanks for your pcb and sch!
And I made the pcb done.
But I don't know how to it works?
I need the detail,Can you Help me?
byemu wrote:
Thanks for your pcb and sch!
And I made the pcb done.
But I don't know how to it works?
I need the detail,Can you Help me?
I got curious, where are you from?
You need to download the kazzo driver and unagi/anago client from the sourceforge page:
http://sourceforge.jp/projects/unagi/wiki/kazzo_intro_en
You can then use anago.exe to interact with the kazzo. It's a command line application so you need to feed it the correct command for what you're trying to do. Example, ''anago.exe d unrom.ad unrom.nes'' if you were to dump the rom from a UNROM cart.
byemu wrote:
Thanks for your pcb and sch!
And I made the pcb done.
But I don't know how to it works?
I need the detail,Can you Help me?
download the unagi and anago programs:
http://sourceforge.jp/projects/unagi/releases/49771
Then run anago from the command prompt with the proper dumping script depending on what mapper the game has.
naviagate to the folder where anago is and you command should look something like this:
anago d unrom.ad contra.nes
anago is the program
d for dump
unrom.ad is the dumping script
contra.nes is the name you want to give the rom you're dumping
infiniteneslives wrote:
byemu wrote:
Thanks for your pcb and sch!
And I made the pcb done.
But I don't know how to it works?
I need the detail,Can you Help me?
download the unagi and anago programs:
http://sourceforge.jp/projects/unagi/releases/49771Then run anago from the command prompt with the proper dumping script depending on what mapper the game has.
naviagate to the folder where anago is and you command should look something like this:
anago d unrom.ad contra.nes
anago is the program
d for dump
unrom.ad is the dumping script
contra.nes is the name you want to give the rom you're dumping
thank you,I'll try later.
Well, I've been busy dumping my collection with the Kazzo, but looks like I'm gonna have to learn about the NES memory map to write my own scripts for dumping some, any pointers on where to start ? I have found a couple of games I couldn't get to dump, only 2 so far, some I had to remove the PC board from the cart to get a good dump due to the weird way the board was. The only 2 I have had no luck with so far are A Boy & His Blob and Bases Loaded 2 with the included dumping scripts, I've dumped about 142 games so far out of the 702 I have.....
my probleam~`
run \kazzo_test.exe
found 2 busses
Could not find USB device "kazzo" with vid=0x16c0 pid=0x5dc
byemu wrote:
my probleam~`
run \kazzo_test.exe
found 2 busses
Could not find USB device "kazzo" with vid=0x16c0 pid=0x5dc
Does your computer recognize the kazzo when you plug it in? What operating system are you running?
Did you flash the microcontroller properly?
infiniteneslives wrote:
byemu wrote:
my probleam~`
run \kazzo_test.exe
found 2 busses
Could not find USB device "kazzo" with vid=0x16c0 pid=0x5dc
Does your computer recognize the kazzo when you plug it in? What operating system are you running?
Did you flash the microcontroller properly?
How to flash the microcontroller properly?
infiniteneslives wrote:
byemu wrote:
my probleam~`
run \kazzo_test.exe
found 2 busses
Could not find USB device "kazzo" with vid=0x16c0 pid=0x5dc
Does your computer recognize the kazzo when you plug it in? What operating system are you running?
Did you flash the microcontroller properly?
I don't know how to install the firmware(the bootload not worked?)！
If it is done！I think i can dump successful,because i know the mapper's elements.
byemu wrote:
infiniteneslives wrote:
byemu wrote:
my probleam~`
run \kazzo_test.exe
found 2 busses
Could not find USB device "kazzo" with vid=0x16c0 pid=0x5dc
Does your computer recognize the kazzo when you plug it in? What operating system are you running?
Did you flash the microcontroller properly?
I don't know how to install the firmware(the bootload not worked?)！
If it is done！I think i can dump successful,because i know the mapper's elements.
The bootloader was only on the microcontrollers I provided kits for. The bootloader still needs to be flashed onto the microcontroller with a AVR programmer. Don't forget you'll also need to program the fuse bytes as well.
You basically just got a blank microcontroller from wherever you bought it. You'll need a AVR programmer something like this:
http://www.sparkfun.com/products/9046
EDIT: looks like that is just a 10pin to 6pin converter. Here's the actual programmer
http://www.sparkfun.com/products/9825 My PCB was set up for a 6pin programmer but I'm guessing you didn't make boards that look identical to mine. You could go with either a 10pin or 6pin it doesn't really matter, just wire up your PCB to go with whatever your programmer has.
If you don't plan on playing around with the firmware much I would recommend just loading the firmware released with the download that came with the software. Speaking of I need to share the bootloader and clipped kazzo firmware for anyone else who may need it.
It sounds like this is your first microcontroller project, if you'd rather do something like mail me your microcontroller I can flash it for you free of charge. I would have you cover the return shipping though. Send me a PM or email if you're interested. The programmer isn't that expensive but if you don't really have a use for one aside from this one time this option might be simpler and easier.
infiniteneslives wrote:
byemu wrote:
infiniteneslives wrote:
byemu wrote:
my probleam~`
run \kazzo_test.exe
found 2 busses
Could not find USB device "kazzo" with vid=0x16c0 pid=0x5dc
Does your computer recognize the kazzo when you plug it in? What operating system are you running?
Did you flash the microcontroller properly?
I don't know how to install the firmware(the bootload not worked?)！
If it is done！I think i can dump successful,because i know the mapper's elements.
The bootloader was only on the microcontrollers I provided kits for. The bootloader still needs to be flashed onto the microcontroller with a AVR programmer. Don't forget you'll also need to program the fuse bytes as well.
You basically just got a blank microcontroller from wherever you bought it. You'll need a AVR programmer something like this:
http://www.sparkfun.com/products/9046If you don't plan on playing around with the firmware much I would recommend just loading the firmware released with the download that came with the software. Speaking of I need to share the bootloader and clipped kazzo firmware for anyone else who may need it.
It sounds like this is your first microcontroller project, if you'd rather do something like mail me your microcontroller I can flash it for you free of charge. I would have you cover the return shipping though. Send me a PM or email if you're interested. The programmer isn't that expensive but if you don't really have a use for one aside from this one time this option might be simpler and easier.
Thank you very much！
I know how to do it！
waiting to hear my good news.
byemu wrote:
Thank you very much！
I know how to do it！
waiting to hear my good news.
Yeah just make sure you pay attention to my EDIT I made in that last post if you plan on buying a programmer from the link I sent. Initially I only linked to an adapter.
I am write kazzo_mega16.hex to my atmega16A
but my dumper still doesn't worked.
byemu wrote:
I am write kazzo_mega16.hex to my atmega16A
but my dumper still doesn't worked.
Did you program the fuse bits?
There should be a high fuse byte and low fuse byte that you need to program according to the readme and makefiles with your download
infiniteneslives wrote:
byemu wrote:
I am write kazzo_mega16.hex to my atmega16A
but my dumper still doesn't worked.
Did you program the fuse bits?
There should be a high fuse byte and low fuse byte that you need to program according to the readme and makefiles with your download
yes，the fuse bits i programmed！
I use the “progisp1.72” and the “avr fighter” write the fireware！
byemu wrote:
yes，the fuse bits i programmed！
I use the “progisp1.72” and the “avr fighter” write the fireware！
Can you give any more details besides "it doesn't work"?
Things like:
-What operating system your using
-If the kazzo is even being recognized by the computer.
-What kind of errors your getting with the kazzo.
-Is everything dumping but your just getting bad dumps?
-details details details...
Can you provide a good close up picture of the circuit board to see if you have any apparent issues with the board?
infiniteneslives wrote:
byemu wrote:
yes，the fuse bits i programmed！
I use the “progisp1.72” and the “avr fighter” write the fireware！
Can you give any more details besides "it doesn't work"?
Things like:
-What operating system your using
-If the kazzo is even being recognized by the computer.
-What kind of errors your getting with the kazzo.
-Is everything dumping but your just getting bad dumps?
-details details details...
Can you provide a good close up picture of the circuit board to see if you have any apparent issues with the board?
I use windows xp and windows 7 x64
My computer can not find the new usb device when i INSERT my dumper！
byemu wrote:
I use windows xp and windows 7 x64
My computer can not find the new usb device when i INSERT my dumper！
Well if you've flashed the AVR properly and set the fuses properly, then there is really only one likely issue.
Is your computer giving you a warning that the "device is not recognized" when you plug it in?
For windows 7 you will need to install the lib32usb drivers, but you shouldn't need to do anything for windows XP. Atleast that's how it worked for me and everyone else to my knowledge.
Assuming everything above is true I would venture to say you have an issue with your circuit. My guess is you've connected something up wrong. If you provide a close up picture I *might* be able to give advice on what to check. Without that I can't really help much, just keep checking all your connections for shorts and opens with a multimeter...
hi infiniteneslives！
How do you writen the firmware?
How do you know that i written the firmware right?
byemu wrote:
hi infiniteneslives！
How do you writen the firmware?
How do you know that i written the firmware right?
You could perform a verification of the firmware with the AVR programmer. But the only way to really be sure I guess is that is works...
Without knowing too many details about what you're working with I can't really be of much help, sorry.
Unfortunately I wouldn't put this up there with projects that would be good for your first microcontroller project.
So I've found a bug/issue with the PCB on the kits I sent out.
I made the mistake of assuming the kazzo firmware left the pin I used for the bootloader as a floating or pulled up input. Turns out the firmware ties the pin to ground and when the bootloader switch is up in kazzo mode the board is wired to pull that pin to Vcc. So yeah theres a bit of current there and the mcu gets a little warm to the touch but no damage has been seen yet...
There are a couple temporary fixes.
The layman's fix: just toggle the switch down to BL immediately after the kazzo has been plugged in. This still allows for normal operation because the bootloader switch is only checked once when it boots up. So the switch only needs to be up in normal kazzo mode when you first apply power to the mcu. After that you can take the switch down to BL and remove the high current condition.
The other fix is probably how I should have designed the board. You could desolder the bootloader switch and clip the top pin off the switch and solder it back in. That way the BL switch toggles between floating to GND instead of Vcc to GND like I made it.
The preffered fix I think is to whip up another firmware version that changes that pin to a input with pull up instead of output GND like the current release.
I tried to recompile the firmware and was sucessful in resolving the high current issue by changing the DDR. But I couldn't get successful dumps having issues with CHR data for some reason a couple bytes are wrong when dumping.
I haven't spent a lot of time yet trying to fix this. But if someone is able to help out heres some more detail.
All I did was comment out the original first line and replace it with the one below. It's line 58 of bus_access.c It's not really needed but the pullup could be enabled as well.
Code:
//USB_MISC_DIR = (0b1100 << 4) | 0b0011; //empty pin use OUT
USB_MISC_DIR = (0b1000 << 4) | 0b0011; //bootloader board bug! configure the bootloader pin as input!
Now that I've got a better understanding of all this bootloader stuff, I'm realizing that the original kazzo DID have a bootloader. It was done somehow through the cartridge interface. I'm guessing you could load the new firmware onto a flashcart or WRAM or something... IDK but it really doesn't matter aside from getting things to compile properly. I ended up compiling everything and then just deleting the bootloader section of the firmware from the hex file.
That's basically how I came up with the firmware that shipped with the kits. Speaking of it's here:
http://dl.dropbox.com/u/18341918/kazzo_mega164p_clipped.hex
and the AVR bootloader software is here amongst other places:
http://dl.dropbox.com/u/18341918/HIDBootFlash.exe
If you compare my clipped version to the firmware in the release:
http://dl.dropbox.com/u/18341918/kazzo_mega164p_original.hex
you can see I just clipped of the chunk that resided in the bootloader space (0x38000 and beyond)
I may as well put this up too:
http://dl.dropbox.com/u/18341918/KazzoBootloader.hex That's the bootloader's firmware that MUST be programmed via an AVR programmer.
Oh and the fuses should be low: 0xc0, high: 0x9f, and extended: 0xff.
Now if you don't really know what you're doing with the bootloader I would say your best not to play around with it. If we get a new release of the firmware I can give SPECIFIC instructions and files to complete the update (basically steps 4-7 below with the new firmware). It's not hard, but if you load the wrong files you'll brick the kazzo until you get your hands on a AVR programmer.
So just to be clear these were the steps I took in flashing the mcu's I sent out:
1) program the fuse bits using AVR programmer. (high 0x9f, low 0xc0) These are DIFFERENT than the released documents due to differences in bootloader and whatnot.
2) flash KazzoBootloader.hex with an AVR programmer.
3) Now toss the AVR programmer to the side and load up the HIDbootFlash.exe software.
4) Place the bootloader switch down to BL and THEN, plug in the USB cable.
5) follow the three software steps, find device, load/navigate to firmware: this is where you'd select kazzo_mega164p_clipped.hex then click flash device.
6) Now you can take the switch up to normal (non-bootload mode). Either unplug and plug back in, or just tap the reset button.
7) the device should now be recognized as the kazzo.
So if you don't own an AVR programmer the one thing you would NOT want to do with the bootloader is try to program the mcu with a hex file that had anything residing in address 0x380000 and beyond. If you do that the bootloader will actually start to write over itself. It will actually overwrite everything until it overwrites the code it's actually operating from. Then you'd get a failure and you would have successfully "bricked" the kazzo and need to reflash the mcu with an AVR programmer.
Hopefully that's clear enough... If anyone doesn't want to deal with any of this you send me an email. Send me back your kazzo and I'll fix the bootloader switch as described above essentially correcting for the board "error"
oh,:(
But my U is Atmega16A!
How to edit my firmware?
byemu wrote:
oh,:(
But my U is Atmega16A!
How to edit my firmware?
None of this really applies to you. It really only applies to the people with the kits i supplied.
You would edit your firmware by just flashing your mcu with your avr programmer. It would seem that based on your sitiation updating the firmware should be of little concern to you. Just program your mcu with the released firmware.
infiniteneslives wrote:
byemu wrote:
oh,:(
But my U is Atmega16A!
How to edit my firmware?
None of this really applies to you. It really only applies to the people with the kits i supplied.
You would edit your firmware by just flashing your mcu with your avr programmer. It would seem that based on your sitiation updating the firmware should be of little concern to you. Just program your mcu with the released firmware.
But my PCB was same as your
byemu wrote:
infiniteneslives wrote:
byemu wrote:
oh,:(
But my U is Atmega16A!
How to edit my firmware?
None of this really applies to you. It really only applies to the people with the kits i supplied.
You would edit your firmware by just flashing your mcu with your avr programmer. It would seem that based on your sitiation updating the firmware should be of little concern to you. Just program your mcu with the released firmware.
But my PCB was same as your
How is it the same???
You're using the ATmega 16A atleast that's what you said.
Did you put the atmega16 in the PCB that I designed???
If you did, there's no wonder it doesn't work... My PCB was for the Atmega164. and the firmware is for the atmega164 not the atmega16. There may be a atmega16 version out there but you'll most likely have to rewrite it yourself. I think there are only atmega8 and atmega164 versions available if I remember correctly.
Why didn't you use the ATmega164?
infiniteneslives wrote:
byemu wrote:
infiniteneslives wrote:
byemu wrote:
oh,:(
But my U is Atmega16A!
How to edit my firmware?
None of this really applies to you. It really only applies to the people with the kits i supplied.
You would edit your firmware by just flashing your mcu with your avr programmer. It would seem that based on your sitiation updating the firmware should be of little concern to you. Just program your mcu with the released firmware.
But my PCB was same as your
How is it the same???
You're using the ATmega 16A atleast that's what you said.
Did you put the atmega16 in the PCB that I designed???
If you did, there's no wonder it doesn't work... My PCB was for the Atmega164. and the firmware is for the atmega164 not the atmega16. There may be a atmega16 version out there but you'll most likely have to rewrite it yourself. I think there are only atmega8 and atmega164 versions available if I remember correctly.
Why didn't you use the ATmega164?
I can not buy the Atmega164P
byemu wrote:
infiniteneslives wrote:
Why didn't you use the ATmega164?
I can not buy the Atmega164P
If you fill in the country field of
your profile, we might find it easier to understand why not.
tepples wrote:
byemu wrote:
infiniteneslives wrote:
Why didn't you use the ATmega164?
I can not buy the Atmega164P
If you fill in the country field of
your profile, we might find it easier to understand why not.
I was succeeded！
And I am already writen a new client for the dumpper
Congrats!
You've written a new windows client completely? I'd be interested to check it out if you're willing to share.
infiniteneslives wrote:
Congrats!
You've written a new windows client completely? I'd be interested to check it out if you're willing to share.
of course，here is the download url：
1.0
http://115.com/file/clsfvyeb#byemu1.0.rar
1.1
http://115.com/file/aqk1ogj7#dumping.rar
I couldn't download the file, it seem they require registration but since it's all in Chinese I can't be sure. I clicked on the green button that appear after the 30 second delay but it open a login window of some sort.
SkinnyV wrote:
I couldn't download the file, it seem they require registration but since it's all in Chinese I can't be sure. I clicked on the green button that appear after the 30 second delay but it open a login window of some sort.
Please go here:
http://refile.net/f/?cjS
or here:
http://www.sendspace.com/file/76livd
english doc
refile.net/f/?c5p
What is the advantage of that client over the old one since it still a appear to be a command line client?
SkinnyV wrote:
What is the advantage of that client over the old one since it still a appear to be a command line client?
command mode:
For Windows[V1.2] by byemu
Command:
H[h|?] Show this help infomation
r addr Read a byte data from pram(addr>=0x4000)
r addr Read a byte data from vram(addr<0x4000)
w addr val Write a byte(val) to pram(addr>=0x4000)
w addr val Write a byte(val) to vram(addr<0x4000)
d addr Show data from addr
a Disassembler data from Start
a addr Disassembler data from addr
ss file 6000-7fff wram write to file
sh file c000-ffff prom write to file
sl file 8000-bfff prom write to file
sv file 0000-1fff vrom write to file
sp file 8000-ffff prom write to file
q Exit this program
-
script mode ,please read the help info and doc！
I checked the readme and it doesn't say much. One of the doc is in chinese and the other one is just a few line long showing the command syntax to use. So I'm still not sure what is the advantage of that client over the old one.
SkinnyV wrote:
I checked the the readme and it doesn't say much. One of the doc is in chinese and the other one is just a few line long showing the command syntax to use. So I'm still not sure what is the advantage of that client over the old one.
The new client is easy use than old~
The most important is U can get more quickly technical support!
and grant update request about the program!
By the way ,I'll write the english doc for the script's readme.
So I'm finally trying out this dumper on a PC with Windows XP.
I downloaded the "kazzo_0.1.2.zip", unzipped it, opened the windows driver folder, right-clicked kazzo.inf, and chose "Install". Then I downloaded anago from
here and tried to dump an MMC1 cartridge with anago_wx, and all I got was "reader open error".
What should I try next? Do I need to restart my PC before installing kazzo.inf and using anago_wx?
EDIT: Problem solved. I restarted the PC, and then chose the driver folder in the Found New Hardware Wizard, and it worked.
I haven't played around with the gui much (anago_wx) But I know OldNESJunkie dumped most of his games with the gui.
I also didn't have to install the drivers to get it working on my windows XP machine. I just plugged it in and ran anago.exe from the command line for pretty much everything I've done with it. I only had to install the drivers with my win7 machine, but I still can't get consistently good dumps with it. But OldNESJunkie didn't have any issues on win7.
Don't forget you need to keep the bootloader switch up in the "normal" position when you plug it in. Then immediately after you plug it in you can take the bootloader switch down to BL, because of that PCB/firmware bug.
In regards to that bug I was able to recompile the firmware to remove the high current condition. But all the dumps ended up bad, something wrong with mirror sensing I think. I've had a lot of difficultly modifying all the code so I kinda just set it aside. I think the best fix right now is de-soldering the Vcc lead off the BL switch. If you want to shoot yours back my way I can take care of that for you, or anyone else for that matter.
Yes, I got about 2/3 of my collection dumped with the Windows GUI Anago_wx version, but still need some scripts to finish dumping my collection. I've tried & failed miserably to write my own :^(
Anybody has an idea why I keep getting this error since I formatted my computer:
m_database not found
AN ERROR HAS OCCURED [the index 'ppu_rom' does not exist]
CALLSTACK
*FUNCTION [dump()] dumpcore.nut line [22]
LOCALS
[ppuarea_memory] NULL
[vram] 1
[increase_ppu] 1
[increase_cpu] 11
[mappernum] 0
[script] "nrom.ad"
[d] USERPOINTER
[this] TABLE
I'm trying to dump a NROM board with the script included in this thread(used to work before)
Are you sure you're using the right script? It's been awhile but I've got that error before I think.
Make sure you copied over the nrom.ad NOT nrom.af (ad is for dumping af is for flashing)
Otherwise it's possible that you're running on a different version of the firmware than last time. Try going back to the version of the software from early in the summer, there was a release around mid summer that could be causing some issues.
you were right, I was able to use an older version of the command line tool. Too bad I can't do much with it though, I have a lot of pirate cart I wish I could dump, they seem to all work the same but can't even dump the menu like they did with the rockman 6 in 1 project and tapedump.
SkinnyV wrote:
you were right, I was able to use an older version of the command line tool. Too bad I can't do much with it though, I have a lot of pirate cart I wish I could dump, they seem to all work the same but can't even dump the menu like they did with the rockman 6 in 1 project and tapedump.
If you get down and dirty with the dumping scripts it should be possible. I actually use the command line more than the gui especially if you're playing around with the dumping scripts. The MMC3 portion is already done, you would just need to port over what they did with the tapedump for switching game banks.
I really like the hardware of the kazzo, but I had a hard time with the software and firmware. I don't know if it's just because of my skills or lack of commenting in the code though. I'm going to be using the hardware and completely different set of firmware and software for some of the prototyping work with the NESDEV1 cart. My goal is to make it much less abstracted than the kazzo software/firmware. So changes would actually be made at the code level, and have abilities to toggle pins and everything directly. Not sure if it would be helpful for others but it allows me to do what I'd like with the hardware which is more cartridge interfacing than dumping obscure carts.
Is there any PCB design ready to use for Kazzo? I want to scratch it at home.
yes but it's not something you could etch at home...
[/quote]
I gave the board files to you back on page 7 of this thread if you want em again.
If you go back to the beginning of the thread you can see how I made my first one on protoboard with connecting wire. If you're making it from scratch at home that's really the only reasonable method. Unless you make it on some hugely oversized double sided PCB and were really good at etching
infiniteneslives wrote:
If you go back to the beginning of the thread you can see how I made my first one on protoboard with connecting wire. If you're making it from scratch at home that's really the only reasonable method. Unless you make it on some hugely oversized double sided PCB and were really good at etching
Wow I stand corrected! I guess it helps that you've only got the one FC connector. leaving out the NES connector and extra FFs for the expansion pins opens up some breathing room.
I don't see anything at a glance. The built in checking with the software is really your best judge.
Nice work!
EDIT: did you use that proteus tool that you usually do again?
Yes again it is the power of Proteus v7.7 SP2
I used
Kazzo v0.1.3 to design it. [mcu16.txt and kazzo_pcb_1.png]
I hope I get some free time to make and test it.
What software should I use with this hardware? Which one is better : anago or unagi?
I use the anago command interface. Some people have had luck with the GUI version in a later release.
The scripts and things I've put on this post are all for anago. I've never got unagi to work actually.
So I've had some people asking me to make another run of these kits. Honestly time is a little strapped right now, but if I made a few dollars for my efforts compared to last run I'm willing to crank out some more.
The board will be nearly identical as before with the two errors I'm aware of fixed. (USB lines and bootloader switch)
I'd do the full unassembled kit with one connector only, for $60 including shipping (international first class mail).
Add $15 for assembly and $8 for the additional 72/60pin connector if you'd like them both. If you'd like a USB cable thrown in add $3.
Other than that it's the same deal as last time, just keep in mind there is no case.
If anyone else wants to get in I'll probably just add a paypal checkout to my site to make things easier that last time. I'm in contact with the pcb supplier to find out delivery time estimate but I would expect Late Jan/Early Feb.
In other news progress is being made to rewrite the firmware and host code from the ground up with something that is a lot quicker and more user friendly. I hope to have basic discrete mapper functionality in the next couple months. But I wouldn't hope to see anything with MMC1/3 etc for some time.
Ok I got my homemade Kazzo up and running :
Is there any new driver for Kazzo? My driver is 2005 :
FARID wrote:
Ok I got my homemade Kazzo up and running :
Wow looking good! What method of copper masking do you use? Is it iron on toner method? If so, what paper are you using?
As for the driver, I'm not sure off the top of my head what I'm running but it's probably the same. Why do you ask? Are you having issues with it?
Yes, I am using Print-Iron method with cheap glossy paper.
Having a new driver feels better
I'd be interested in the pcb and the connecter if you are making another run.
That looks pretty great
I saw some discussion about programmable dev carts, but I didn't see a firm conclusion. Does it play nicely with various repro pak configurations? I saw people talking about using expansion pins as a mapper disable, but I wasn't sure if that got implemented or not.
One thought I had was that since there are multiple 5V pins on the connector, you could make a dev cart that uses one of them as a mapper enable line (simply and the clock signal to the flip flops with it). When running in nes it will always be high, and when programming, you can drive it as needed, and all components will still be powered from the other line.
I am considering projects that use the expansion port, so I am a bit weary of using that line on my dev cart.
You could always solder a switch onto your dev cart to switch between using the expansion pin for a mapper disable vs. for something else.
Btw, I tried to put my kazzo on ebay and my listing was removed for Copyright Violation - Unauthorized Item, WTH
SkinnyV wrote:
Btw, I tried to put my kazzo on ebay and my listing was removed for Copyright Violation - Unauthorized Item, WTH
captncraig wrote:
I'd be interested in the pcb and the connecter if you are making another run.
Maybe you don't have to go to ebay?
They just don't know what is exactly legal and what's not. If it'd questionable they default to what's safer for them.
captncraig wrote:
I saw some discussion about programmable dev carts, but I didn't see a firm conclusion. Does it play nicely with various repro pak configurations? I saw people talking about using expansion pins as a mapper disable, but I wasn't sure if that got implemented or not.
One thought I had was that since there are multiple 5V pins on the connector, you could make a dev cart that uses one of them as a mapper enable line (simply and the clock signal to the flip flops with it). When running in nes it will always be high, and when programming, you can drive it as needed, and all components will still be powered from the other line.
I am considering projects that use the expansion port, so I am a bit weary of using that line on my dev cart.
Nothing has been implemented for the EXP pins on the official Kazzo softwares (anago and unagi) and wouldn't expect them to be since they are japanese based projects.
I tried to modify some code and things with their implementation and ran into a lot of issues compiling and grasping their code which lacked commenting (except the few Japanese ones).
The thing I really like and use the kazzo for is to just use the hardware and create my own firmware. I've done this for a few different things and am currently working on the first build of the NESDEV1's avrcode on it. That I will then port over to the final board. The run I made up (and posted plans) provide extra access to the EXP pins that the original kazzo did not. So with the hardware I made up you could do the EXP0 (or any EXP pin really) mapper disable with your own hardware. If people are interested I'll release my firmware after I get it cleaned up and everything. I don't have much plans to implement dumping of all kinds of mappers and such. But the USB read/write ground work would be there if someone wanted to do some development working with the mappers.
Your idea about anding the power pin is interesting, don't see why it wouldn't work. You would have to modify the hardware I made though since I just tied all the power pins to 5v.
I'm curious about your devcart, anywhere we can check it out? What are you gearing it towards/the goal of the project?
Just picked up a Kazzo (second hand;
thanks SkinnyV!). I hope to use it to power a custom-made nintendo: a small form factor PC inside a real NES case, that takes real NES carts and controllers. But puts out better video.
It seems to be *really* picky about the cartridges. I had to clean again games that even the original NES hardware seemed able to read, and generally got a lot of "maybe cartridge connection error" and "error: data is all 0xff".
But it's working. I managed to put together a few simple scripts so far for nrom, unrom, and gnrom which all seemed to be missing from the anago download. They're on GitHub:
https://github.com/arantius/anago-scripts
I don't think I have any more esoteric carts in my collection. The rest are almost all mmc1 or mmc3. But I might have some small tweaks for those as well. (Like, the default mmc3 script seems to always do 256k PRG. It seems to work anyway, but some carts are smaller than that.)
arantius wrote:
I hope to use it to power a custom-made nintendo: a small form factor PC inside a real NES case, that takes real NES carts and controllers. But puts out better video.
By power you mean emulate the NES on the atmega164??? I'd be interested to see how good you can get this. If you haven't checked out the UZEbox project already I would. It's open source and uses the Atmega644. You could actually swap the atmega164 in the kazzo out for a 644 and run the UZEbox on the kazzo if you played around a bit with the pinouts and everything. A good starting point if you're just getting going.
Quote:
It seems to be *really* picky about the cartridges. I had to clean again games that even the original NES hardware seemed able to read, and generally got a lot of "maybe cartridge connection error" and "error: data is all 0xff".
That's too bad, I don't really have much issue with mine. It might be worthwhile trying to clean out the connector.
Quote:
I managed to put together a few simple scripts so far for nrom, unrom, and gnrom which all seemed to be missing from the anago download.
good work, I've been meaning to put the gnrom together for a bit.
Quote:
I don't think I have any more esoteric carts in my collection. The rest are almost all mmc1 or mmc3. But I might have some small tweaks for those as well. (Like, the default mmc3 script seems to always do 256k PRG. It seems to work anyway, but some carts are smaller than that.)
I think it checks for 256KB by default but doesn't include the double up if it realizes it's a smaller ROM.
infiniteneslives wrote:
By power you mean emulate the NES on the atmega164???
Oh, no. Just let the PC know which cart has been inserted. Poor wording =)
infiniteneslives wrote:
I think it checks for 256KB by default but doesn't include the double up if it realizes it's a smaller ROM.
Not in my experience. The one try I did, it ran but the file was 128k too big.
FARID wrote:
Ok I got my homemade Kazzo up and running :
Is there any new driver for Kazzo? My driver is 2005 :
the lasted driver is 2012 （1.2.6）
Does anyone know about command how to transfering .sav file to original nes cartridge by kazzo ?
I've never played around with the gui "anago wx" much but it looks like it might not be to hard there for the boards that are supported already atleast.
There is a workram tab and you can select a few MMC1/MMC3 boards and upload your .sav file and click write.
If your board isn't listed though you'd have to write a script to support that board.
Are there any plans to have another round of kits produced?
Not currently. I've been making additional runs by request though. The only issues is the place I get the PCBs from requires multiples of 3. I might consider a different supplier though. That and I would kind of like to have more than one person interested if I were to go through the effort again. If anyone else is interested let me know.
Otherwise I'm willing to share the PCB files (think I did in a previous post) so you could order the PCBs yourself as well.
Easy wrote:
Does anyone know about command how to transfering .sav file to original nes cartridge by kazzo ?
use the write command~~
Had some questions about the drivers.
these files have always been able to get me set straight. Most of what you need is in the bin folder.
If you plug the device in and run inf wizard at one point you should see the device listed. Just select it and finish creating the inf file. Then from the device manager when installing device you can navigate to your newly created inf file.
Just don't be a derp like me & have the switch on BL when trying to create/install the driver
Hello there,
I have been encouraged to publicly announce my intention to purchase a Kazzo to drum up enough interest to meet the minimum order requirement.
Thanks,
Jim
Jim VanDeventer wrote:
Hello there,
I have been encouraged to publicly announce my intention to purchase a Kazzo to drum up enough interest to meet the minimum order requirement.
Thanks,
Jim
Well be glad you spoke up, I'm coincidentally planning to submit another board order this evening.
I'm probably going to order a small batch of 10. I hadn't really planned on publically selling them, but since you've asked so nicely I will. Anyone interested in reserving one, feel free to contact me via email:
Paul@InfiniteNesLives.comOn a side note I am planning to add SNES support, although I admit it'll be far from perfect. The connectors are NOT ideal for original NES carts due to the narrow pins. It's targeted more towards new SNES pcbs where the pins are 'normal NES' width for a separate project I'm working on.
One other spoiler, I'm also finally getting around to working on my own release of kazzo hardware compliant firmware and host PC software to alleviate some of the issues with the current kazzo firmware & software and add more custom flash cart capabilities.
Quote:
One other spoiler, I'm also finally getting around to working on my own release of kazzo hardware compliant firmware and host PC software to alleviate some of the issues with the current kazzo firmware & software and add more custom flash cart capabilities.
Will this make it simpler at all to create dumping scripts or are you gonna have some new ones with this as well?
OldNESJunkie wrote:
Quote:
One other spoiler, I'm also finally getting around to working on my own release of kazzo hardware compliant firmware and host PC software to alleviate some of the issues with the current kazzo firmware & software and add more custom flash cart capabilities.
Will this make it simpler at all to create dumping scripts or are you gonna have some new ones with this as well?
Which mappers did you have problems with? I had some problems with MMC3 awhile back and revised the dumping script and seemed to correct the issues I had. I think I shared it in a different thread, but I should probably post it here as well:
mmc3_full.adNot sure yet exactly how I'm going to manage the scripts and mappers with my own software/firmware. The easiest way to do it is just build them into the firmware. Then I could auto detect the mapper or allow the user to override the mapper via the host software. The U.S. licensed library of games should be pretty easy to fully encompass. It would be nice to have script support for my new firmware and software, but I'm kinda lazy and don't see the need to write a script parser and everything. Plus I think I can optimize and speed up the process which can't be done well with dumping scripts. The best alternative to a script I can offer is easy mapper templates that could be added into the includes when building the firmware. Might even be better for some since it would be entirely in C and I'll include some mapper specific helper functions. Then if one desired to write their own 'script' it'd actually just be a file included in the firmware build that one could fairly easily do themselves with the provided bootloader.
I will point out one 'flaw/bug' that I've noticed with the cuurent kazzo firmware/software/driver as a disclaimer. I've yet to hear anyone else report this issue and for awhile I assumed it was just my PC. But I have a problem where communications will drop mid-dump at random times. If I try enough I can usuallly get a dump to complete, but we're talking <5% success rate depending on the ROM size. I've seen this with two of my PC's now and every single Kazzo I've assembled (a dozen or so). All of those kazzo's work fine on my laptop. It's possible that it's a windows7 vs windowsXP problem, but I've heard reports from a few people that it works fine on windows7.
From what I can tell, it's a software/firmware issue (possilbly PC hardware), and not a kazzo hardware issue. Although I'm curious if trying some different values of USB D- pull up resistors might affect the results. I've seen similar bugs related to that resistor. But in using my own software and firmware this whole problem is non-existent. This is one of my main motives for writing my own software/firmware. I cannot stand behind and easily provide support for the software/firmware that's released by the original author as I have a hard time understanding and even re-compiling the firmware/software. There were several more techincal bugs I found related to flash carts that I was unable to resolve myself which basically forced me to write my own.
TL;DR Use the original software/firmware at your own risk. I can't provide technical support for it. However the software/firmware I write, I will provide technical support for.
Will this new firmware be compatible with the old run of the Kazzo? If so, sounds great!!!
OldNESJunkie wrote:
Will this new firmware be compatible with the old run of the Kazzo? If so, sounds great!!!
Answer depends slightly on which 'old' kazzo you're talking about and what you'd like to do with my firmware/software. If you're asking for dumping purposes only, the answer is yes. Every kazzo I've ever made/distributed is 'universally' compatible with original firmware/software and vice versa. Likewise, my software/firmware will be compatible with every kazzo I've ever made and even ones made to the official hardware design with the exception of flashing carts.
To answer the simple question: "Will my new firmware & software be compatible for dumping games using the official kazzo v1.0 OR the kazzo's I original made and distributed here." The answer is yes.
Where it gets confusing is if you're looking to use my firmware/software to program a flash cart. My firmware/software will assume that there is a connection to EXP0 for mapper write disabling. Additionally, if you'd like to do anything with the SNES capabilities I'm adding you'll need one of my newer boards currently in production.
My 'revision' to the kazzo's hardware was to add access to the EXP bus on NES carts. I only made use of un-used pins on the official kazzo design to do this. So my version, including the ones I originally made and distributed here had these changes. But in doing this my version of the kazzo is/was still fully compatible with the original firmware/software.
The main reason I added the EXP port access was for development and flash carts, specifically for disabling mapper writes to support writing to PRG-ROM. The official firmware/software isn't capable of interfacing with the EXP port like I designed.
So I just received my Kazzo a couple days ago (Thanks infiniteneslives!). So far so good dumping my NES collection. However, I am running into a few problem games, which sounds the same as what I'm reading in this thread. I'm wondering if anyone has found any workarounds or better scripts? The games I've noticed so far are:
Super Mario Bros 3 (MMC3)
The Legend of Zelda (MMC1)
and Dr. Mario (MMC1)
I've tried both "versions" of each corresponding mapper script included with the tool without success. I also tried the mmc3_full script infiniteneslives uploaded against Mario 3, but it actually just errors out and doesn't start
.
Since these are *very* common games, I'm sure someone else has run into the same issue. Any suggestions?
So far I've only tried 17/102 games in my collection, so I'm sure there's more to be added to the above list
Zelda and SMB3 worked for me and I used the command line version. Can't check now, but will later unless someone else figures it out in the meantime.
So I've never had much luck with the gui version personally. I've only really ever used the commandline. Others have had better luck than me though. I did notice that the format of the scripts varies between the commandline and gui version as well. It's a slight difference in the defining variable names IIRC. I've tried to fix the issues with the firmware and software that I've encountered, but I haven't been successful.
My solution is to rewrite it all myself, I've got mapper detection working for most common mappers to where a scripts wouldn't be necessary. After I get a few fires put out I'll start implementing the actual dumping feature hopefully in ~month.
What is the problem that you're running into? Does it dump, but the rom won't play? Or is it failing during the dump? I'd give the commandline version a try (named anago).
brief instructions:
open command prompt
cd to the anago directory
dump with the following command: anago d mmc3.ad romname.nes
(The anago is the executable, d is for dumping, then give script name and output file name.
Thanks guys. The command line version did the trick for Mario 3 and Zelda. No change on Dr. Mario, however. I'm not too bent out of shape for Dr. Mario, as I can always play the SNES version of that
.
To clarify what was happening before: the game would dump, but the resulting dump was unplayable. I would clean and re-try the dump and get a binary-identical dump to the previous attempt. I have also run into problems during the dump, but usually a re-try will fix that (assuming the cart is already clean).
I will be trying more games this weekend.
Yeah Dr. Mario is SEROM IIRC, the provided scripts don't work for SEROM since it's setup with max 32KB hardwired PRG ROM. If you took the PRG side of the NROM script and CHR side of the MMC1 script you should be able to create a SEROM script.
The alternative would be to rip the rom twice once using NROM for prg and once with MMC1 for CHR and then patch the roms together.
Sorry about not testing it quicker, but good to see you got it working.
infiniteneslives wrote:
Yeah Dr. Mario is SEROM IIRC, the provided scripts don't work for SEROM since it's setup with max 32KB hardwired PRG ROM.
Perhaps the cleanest way to make SEROM work in a future version of the script is to always drive the MMC1 in 32K mode.
infiniteneslives wrote:
Yeah Dr. Mario is SEROM IIRC, the provided scripts don't work for SEROM since it's setup with max 32KB hardwired PRG ROM. If you took the PRG side of the NROM script and CHR side of the MMC1 script you should be able to create a SEROM script.
Thank you sir. That's exactly what I did, and it worked flawlessly for Dr. Mario, Tetris and the Adventures of Lolo. I've uploaded my script to:
http://zerker.ca/misc/serom.adI ran into some strange problems with Kid Icarus. The MMC1 script detected the correct size and the lack of CHR rom, but it still came out garbled. Not entirely sure what happened there.
I've also run into some garbled graphics on Twinbee. The "list" I have says it's CNROM, but I suspect this isn't quite right. I'm having a hard time finding a clear answer as to what Twinbee uses.
Hello everyone,
I recently purchased a Kazzo and have been having trouble dumping the majority of my collection. Out of the the six or so games I have tried I have only been able to dump "Gauntlet". I'm running Windows 7 and i'm using the command line tool like so many here have suggested. However I keep getting ROMs that wont run at all or have graphical glitches. I've tried Teenage Mutant Ninja Turtles 2 & 3 which both have the same mapper as Gauntlet according to the list (
http://tuxnes.sourceforge.net/nesmapper.txt) I have, yet wont dump correctly.
I was wondering if the new firmware update infiniteneslives was talking about would fix this but whenever I update the firmware and run anago.exe it gives the error:
Could not find USB device "kazzo" with vid=0x16c0 pid=0x5dc
I'm assuming this is because the firmware update changes the device name from "kazzo" to "INL Retro-Prog" so it cannot find it. I also tried running the other tool "unagi" and changed unagi.cfg to the following:
Code:
#使用するハードのコメントを外してください
#DRIVER INL Retro-Prog
#DRIVER hongkongfc
#DRIVER onajimi
#hongkong fc の flash の書き込みができない場合はコメントを外して
#試してみてください
#HONGKONG_FLASH 0.5.3
thinking that I just needed to change the device name from kazzo but now I recieve this error when running unagi:
config error: hardware not selected or not found
Because of this I don't know how to run the command line program with the new firmware. Any ideas?
tl/dr: I can't dump very many ROMs and was looking for ideas of what to do differently
tepples wrote:
Perhaps the cleanest way to make SEROM work in a future version of the script is to always drive the MMC1 in 32K mode.
Yes, that would be the better solution. But it's a little complex to make that modification if you don't have an indepth knowledge of the MMC1. So that's why I suggested hacking the scripts.
Zerker wrote:
Perhaps the cleanest way to make SEROM work in a future version of the script is to always drive the MMC1 in 32K mode.
Thank you sir. That's exactly what I did, and it worked flawlessly for Dr. Mario, Tetris and the Adventures of Lolo. I've uploaded my script to:
http://zerker.ca/misc/serom.ad[/quote] Good work! thanks for sharing.
Quote:
I ran into some strange problems with Kid Icarus. The MMC1 script detected the correct size and the lack of CHR rom, but it still came out garbled. Not entirely sure what happened there.
I've also run into some garbled graphics on Twinbee. The "list" I have says it's CNROM, but I suspect this isn't quite right. I'm having a hard time finding a clear answer as to what Twinbee uses.
First off,
bootgod's database is your mapper list bible, not those downloaded lists.
Kid Icarus is SNROM which is MMC1 with CHR-RAM. What ever is causing it to detect CHR-ROM is wrong. Make sure the script is set to detect CHR-RAM. You could probably create a script for SNROM specifically that didn't dump CHR, similar to how the UNROM script only dumps PRG. You could also just modify the header of the dumped rom to set the CHR size byte to zero and that'll probably fix it. Any extraneous CHR data could be cut out of the end of the rom too for cleanliness sake. All that said, I've yet to have issues dumping SNROM games with the commandline version with the standard MMC1 script.
According to bootgod Twinbee is mapper 87 which isn't CNROM. So your suspicions are correct. Looking at Disch's doc on the wiki;
http://wiki.nesdev.com/w/index.php/INES_Mapper_087Looks like that mapper is basically identical to CNROM, EXCEPT the CHR bank select registers are at $6000-7FFF. CNROM places the register at $8000-FFFF. So you should be able to modify the CNROM script slightly to create your own mapper 87 script. Just change the $8000 writes to $6000 and I think that'll fix you up.
EDIT: Err, it's a little more mixed up as the bits are backwards...
Code:
Registers:
--------------------------
$6000-7FFF: [.... ..LH]
H = High CHR Bit
L = Low CHR Bit
This reg selects 8k CHR @ $0000. Note the reversed bit orders. Most games using this mapper only have 16k
CHR, so the 'H' bit is usually unused.
But it's only 16KB for most so that might make it a little easier. Basically CNROM counts up (0,1,2,3). But this mapper counts like this: 0,2,1,3. But you could cheat since you've only got 16KB (two banks). Instead of incrementing by one, try incrementing by two. Automatic size detection should resolve the rest, note that my suggestion won't work for 32KB CHR-ROM games.
Cfox7, If you can provide more details on the issues you're having I can probably help. Sounds like you might not be using the correct scripts. But not knowing which script your using for a specific title I can't really help.
As for the issues with not being recognized, sounds like you're trying to use my firmware (INL Retro-Prog) with the anago/unagi software. You can't do that. basically my firmware is only compatible with my software. The kazzo firmware is only compatible with the anago/unagi softwares. Once my firmware and software is complete enough to dump games, it will hopefully resolve some of the issues you're having. My firmware will try to autodetect the mapper and everything for you, so as long as its on the supported list, then you guys won't have to worry about selecting/creating the correct script and everything. Can't say when I'll be at that point, but progress is currently being made. I'm hoping to release something that supports common mappers within a month hopefully.
infiniteneslives wrote:
Looks like that mapper is basically identical to CNROM, EXCEPT the CHR bank select registers are at $6000-7FFF. CNROM places the register at $8000-FFFF. So you should be able to modify the CNROM script slightly to create your own mapper 87 script. Just change the $8000 writes to $6000 and I think that'll fix you up.
That'd work for
mapper 101. But mapper 87 swaps bank bits 1 and 0. In any case, dumping the cart as if it were 101 and storing it with 101 will still produce a working ROM.
tepples wrote:
infiniteneslives wrote:
Looks like that mapper is basically identical to CNROM, EXCEPT the CHR bank select registers are at $6000-7FFF. CNROM places the register at $8000-FFFF. So you should be able to modify the CNROM script slightly to create your own mapper 87 script. Just change the $8000 writes to $6000 and I think that'll fix you up.
That'd work for
mapper 101. But mapper 87 swaps bank bits 1 and 0. In any case, dumping the cart as if it were 101 and storing it with 101 will still produce a working ROM.
yeah I just caught that myself too, made an edit to my post accordingly.
infiniteneslives wrote:
tepples wrote:
Cfox7, If you can provide more details on the issues you're having I can probably help. Sounds like you might not be using the correct scripts. But not knowing which script your using for a specific title I can't really help.
As for the issues with not being recognized, sounds like you're trying to use my firmware (INL Retro-Prog) with the anago/unagi software. You can't do that. basically my firmware is only compatible with my software. The kazzo firmware is only compatible with the anago/unagi softwares. Once my firmware and software is complete enough to dump games, it will hopefully resolve some of the issues you're having. My firmware will try to autodetect the mapper and everything for you, so as long as its on the supported list, then you guys won't have to worry about selecting/creating the correct script and everything. Can't say when I'll be at that point, but progress is currently being made. I'm hoping to release something that supports common mappers within a month hopefully.
This pretty much answers all of my questions. Didn't realize your firmware didn't work with the anago/unagi software. Looking forward to when dumping games becomes that easy. Good luck
As for more details...
I dumped Gauntlet using the mmc3.ad script using the anago command line software and it works great everytime I dump it. When I dump Teenage Mutant Ninja turtles 2 & 3 with the mmc3.ad script (which is what the list said the mapper was) it never runs in an emulator. Heres the exact script:
Code:
board <- {
mappernum = 4,
cpu_romsize = 2 * mega, cpu_banksize = 0x2000,
ppu_romsize = 2 * mega, ppu_banksize = 0x0400,
ppu_ramfind = true, vram_mirrorfind = false
};
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize - 2; i += 2){
cpu_write(d, 0x8000, 6);
cpu_write(d, 0x8001, i);
cpu_write(d, 0x8000, 7);
cpu_write(d, 0x8001, i | 1);
cpu_read(d, 0x8000, banksize * 2);
}
cpu_read(d, 0xc000, banksize * 2);
}
function ppu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i+=4){
cpu_write(d, 0x8000, 2);
cpu_write(d, 0x8001, i);
cpu_write(d, 0x8000, 3);
cpu_write(d, 0x8001, i | 1);
cpu_write(d, 0x8000, 4);
cpu_write(d, 0x8001, i | 2);
cpu_write(d, 0x8000, 5);
cpu_write(d, 0x8001, i | 3);
ppu_read(d, 0x1000, banksize * 4);
}
}
it's the same script that came with the kazzo.zip file so it should be working?
Quote:
I dumped Gauntlet using the mmc3.ad script using the anago command line software and it works great everytime I dump it. When I dump Teenage Mutant Ninja turtles 2 & 3 with the mmc3.ad script (which is what the list said the mapper was) it never runs in an emulator.
I just recently got infiniteneslives' Kazzo too. Here are my experiences so far. I see a lot of suggestions to use the command line version, but I've dumped about 80 games so far, and I haven't run into any yet that I couldn't dump in the GUI Anago. (If I could dump it at all, I would get the same crc in both gui & command line, using 64bit Windows 7) I recommend using bootgod's database as already mentioned. It will show you what the crc code should be, because it's possible to get a bad connection and dump a game with fuzzy graphics (if a connection isn't perfect, like when you need to blow on a cart on real NES). If something like that happens, the rom would still work in an emulator, but you might not know it's a perfect dump unless you compare a known good dump's crc32.
I haven't dumped tmnt 2 or 3 yet, but I'll try those soon & let you know if I have the same issue as you. Also, a few times, I've gotten a good dump on PRG, but not CHR, and just had to re-seat the cartridge a couple times to get a good dump. Make sure they're clean, etc. etc.
I dumped TMNT3 yesterday without problems. Whenever I dump MMC3 games, I usually use the mmc3_v2.ad script with the version 60 command-line tool. I haven't had any problems with MMC3 games once I started using this combination, but a few games (i.e. Kirby's Adventure) required me to up the rom size using the d21 notation. (i.e. d21 would double the prog rom dumping size, but dump the "default" size for the chr rom).
I just dumped TMNT 2 & 3 to check the scripts for you. There's a script in the "062_GUI" version called mmc3.ag (not .ad) that I've successfully been using to dump all my MMC3 games in the GUI version.
Knowing there is a database out there to compare the crc32 to should help in verifying that there was a good dump I'll look into that for sure. I guess the problem is I am trying to script the whole process of dumping NES ROMs since I have over a 100 games to try to dump. I was opening them in an emulator to see if the ROM is good but now I can compare the crc32 to that database.
I switched to the command line script in the "062_GUI" version and used the mmc3.ag script like you suggested and got a good dump of TMNT2 however TMNT3 is still giving me some trouble even with the mmc3_v2.ad script. I'll have to see if I can give it a good cleaning or if the cartridge even works anymore on a NES
So I've succeeded in dumping every game I own save two: Twinbee and Faxanadu.
For Twinbee, I already have a way forward as suggested on the previous page. I will be trying that tomorrow. I did have problems with Kid Icarus, but that worked fine after I opened up the cartridge shell and gave it a better cleaning.
However, Faxanadu seems to thwart me at every turn. I opened it up, and the contacts look VERY clean. Attempting to clean them more doesn't even pick up anything on the Q-tip. However, the game keeps dumping with a different CRC every time, which makes me believe it's still not making proper contact. Potentially the contacts are just worn-down and aren't as thick as they should be? Any suggestions for improving the situation long enough to get a good dump?
Is it sensing CHR-RAM with faxanandu? If the cart is very heavily worn to the point where the PCB has narrowed lengthwise significantly it's conceivable that pushing the circuit board to the far right (side of the USB connector) would provide better success. I've never seen one worn that heavily though. Really your most likely issue is dirty/poor connection. Does the game play well in your NES?
I got it to work today. I did your suggestion of pushing it forward. I also blew on it, which may or may not have improved conductivity via the moisture from my breath. Shrug.
I also got Twinbee to work per your earlier suggestions. I implemented a 4-bank script even though Twinbee only has two banks. Here it is:
http://zerker.ca/misc/Mapper87.adSo that's everything!
Except my pirate cartridge
I gave it a first crack today. I actually managed to find documentation on the mapper scheme it uses:
http://code.google.com/p/usbcopynesblue ... c=svn3&r=3And cooked up a script:
Code:
board <- {
mappernum = 130, //Need to convert to UNIF format with BMC-Ghostbusters63in1
cpu_romsize = 0x180000, cpu_banksize = 0x8000,
ppu_romsize = 0, ppu_banksize = 0x2000,
ppu_ramfind = false, vram_mirrorfind = false
};
function cpu_dump(d, pagesize, banksize)
{
// ROM Chip. Only 0, 2 and 3 are used
for(local chip = 0; chip < 4; chip += 1){
if (chip != 1) {
// High bit for ROM chip select
cpu_write(d, 0x8001, chip >> 1);
// Bank. 512/32 = 16 banks per chip
for(local i = 0; i < 16; i += 1){
// Low bit for ROM chip select + bank select.
cpu_write(d, 0x8000, ((chip & 1) << 7) + (i << 1));
cpu_read(d, 0x8000, banksize/2); //Read 32KB bank from $8000-FFFF
cpu_read(d, 0xC000, banksize/2); //Read 32KB bank from $8000-FFFF
}
}
}
}
Anago did "process" 1.5 MB (0x180000), but when it finished it pared the file down to 96 KB! (0x18000). I'm not really sure what happened here, except perhaps I didn't end up switching banks, so the tool thought I just had the same thing repeated over and over.
I'll give it another go tomorrow. Of course, even when it dumps, I need to find a tool to convert it to UNIF format, or cook something up in Python.
Are you sure this is the same 63-in-1 ?
Unrelated to you dumping it, it'd be wonderful if you'd be willing to post pictures of both sides of the PCB.
I guess it's only mostly unrelated; such pictures would let us (and you) confirm that it's the same 63-in-1.
Your wish is my command:
https://plus.google.com/photos/11428733 ... 9qHxcOpvwEI also uploaded the screenshots I took years ago when I had my NES hooked up through an ATI all-in-wonder video card for a reference as to what is on it (and the menu apperance).
however, since it's a 63-in-1 and it has a Ghostbusters label, the Ghostbusters63in1 mapper seems a perfect fit
.
When I try again tomorrow, I'll try removing the pin converter and dump it as if it were a Famicom cart. I expect the Famicom pins are essentially pristine.
Why do you have the "& 1" in this write?
Code:
cpu_write(d, 0x8000, ((chip & 1) << 7) + (i << 1));
Doing so will prevent you from dumping the 2nd chip, you'll only read the 0th chip, and the 3rd chip twice.
Code:
0b10 & 0b01 = 0b11
Other than that if the doc matches your cart then I think it'll work. Although your comments don't agree with your code, this is really what's happening:
Code:
cpu_read(d, 0x8000, banksize/2); //Read 16KB bank from $8000-BFFF
cpu_read(d, 0xC000, banksize/2); //Read 16KB bank from $C000-FFFF
Just FYI, you should be able to replace your read with one read:
Code:
cpu_read(d, 0x8000, banksize); //Read 32KB bank from $8000-FFFF
Using the FC connector is a decent idea. If that doesn't work, one idea would be to try and dump it in 16KB mode just to try a different means available to you.
Some other ways you could try to get around the doubling detection would be to dump it with 3 separate scripts which use a fixed value in $8001. (0,1,2,3) and check if you're getting different data (and 0xFF for #1) to see if it agrees with the doc. If the returned data is all the same then that bit isn't working like you expect.
infiniteneslives wrote:
Why do you have the "& 1" in this write?
Code:
cpu_write(d, 0x8000, ((chip & 1) << 7) + (i << 1));
Doing so will prevent you from dumping the 2nd chip, you'll only read the 0th chip, and the 3rd chip twice.
Code:
0b10 & 0b01 = 0b11
Note the line outside the inner for loop:
Code:
cpu_write(d, 0x8001, chip >> 1);
I think you're mixing up your bitwise operators. & = AND, | = OR. In your example, 0b10 & 0b01 = 0b00. I'm filtering out ONLY the low-order bit and pushing it to the most-significant position in the register. The high order bit goes in a separate register.
infiniteneslives wrote:
Although your comments don't agree with your code, this is really what's happening:
Code:
cpu_read(d, 0x8000, banksize/2); //Read 16KB bank from $8000-BFFF
cpu_read(d, 0xC000, banksize/2); //Read 16KB bank from $C000-FFFF
Just FYI, you should be able to replace your read with one read:
Code:
cpu_read(d, 0x8000, banksize); //Read 32KB bank from $8000-FFFF
This was copied verbatim from another script. Those comments aren't mine
. I actually tried your suggestion and anago gave me a "logic error" for whatever reason.
infiniteneslives wrote:
Some other ways you could try to get around the doubling detection would be to dump it with 3 separate scripts which use a fixed value in $8001. (0,1,2,3) and check if you're getting different data (and 0xFF for #1) to see if it agrees with the doc. If the returned data is all the same then that bit isn't working like you expect.
Thanks. I was thinking of this too. I'll try this next.
Zerker wrote:
I think you're mixing up your bitwise operators. & = AND, | = OR. In your example, 0b10 & 0b01 = 0b00. I'm filtering out ONLY the low-order bit and pushing it to the most-significant position in the register. The high order bit goes in a separate register.
Damn, I guess it was too early for simple logic...
Quote:
Although your comments don't agree with your code, this is really what's happening:
Code:
cpu_read(d, 0x8000, banksize/2); //Read 16KB bank from $8000-BFFF
cpu_read(d, 0xC000, banksize/2); //Read 16KB bank from $C000-FFFF
Just FYI, you should be able to replace your read with one read:
Code:
cpu_read(d, 0x8000, banksize); //Read 32KB bank from $8000-FFFF
This was copied verbatim from another script. Those comments aren't mine
. I actually tried your suggestion and anago gave me a "logic error" for whatever reason.
Yeah, I'm actually not too surprised. This should work, but for some reason (bug in the software/firmware?) it doesn't. There are several oddities like this that prevent things from working as you'd think they should. Could there be other things like that causing issues? Who knows... That's where I got the motivation to drop development on kazzo-anago/unagi scripts and just create my own firmware/software from the ground up.
I didn't see any 100 nF caps. I was told there would be caps.
The cap is a lie.
Tonight in #nesdev, someone pointed out that this and other boards might be more reliable with a few changes:
- Wider traces for power and ground.
- A 100 nF bypass cap for each +5V pin on each IC.
- A 10 µF cap close to where power enters the board.
- Less spaghetti routing, more thought into how to "bus things real nice and neat".
Just a bit of constructive criticism to help with the next HW revision before the INL-ROM v2 comes out.
Pasky wrote:
I didn't see any 100 nF caps. I was told there would be caps.
? on the kazzo? What were you told by who, and for what? Maybe I'm missing something... There's a 1nF noise cap and a 22uF power cap on the current boards.
Quote:
Tonight in #nesdev, someone pointed out that this and other boards might be more reliable with a few changes:
What reliability issues are being seen?
I'll break em down. I'm not trying to be defensive here, I appreciate the constructive criticism. But I try to make my desisions based on cost and history of what's works reliably.
Quote:
Wider traces for power and ground.
I'll take the hit on 12mil Vcc traces could be wider. But I've never had an issue with them and that's what I've always used. Ground can't get much bigger as the entire board has poured ground plane on both sides.
Quote:
A 100 nF bypass cap for each +5V pin on each IC.
I've always used 1nF which is what I understood as the standard. The kazzo only has one, I don't see much point in giving the flipflops their own. Maybe that's not the rule, but I all three chips are in close proximity to the caps and I've yet to see an issue. My INL-ROM v2 boards do have a cap per chip for most configs, although the CIC and CHR are close enough I have them share. Depending on the config, there are other places caps are shared. For those spots, if caps weren't shared I'd litterally end up with two caps sitting right next to eachother in which case it wouldn't be a gain anyways.
Quote:
A 10 µF cap close to where power enters the board.
It can't get much closer to the entrance on the kazzo. INL-ROM boards have it on the left and similar location as the original boards. Moving it closer to the bottom would also move it away from the regulator. v2 boards it's really only an inch away. Although if you're talking about that kazzo board I made years ago, I'd agree with you.
Quote:
Less spaghetti routing, more thought into how to "bus things real nice and neat".
Why? That would be a deal breaker for many things I make as I see it. And I fail to see the benefit. The kazzo is 'bussed' to some degree where the routing was easy. Bussing on INL-ROM boards would mean more expensive boards, and less mapper/board options for a given board. Looking at original NES boards it's hard for me to consider them 'bussed' nice and neat. Either way I still don't see the benefit or gain in reliability. Although now I look at your link and you're linking to my original kazzo which I made 3 years ago now. I thought you were talking about my current boards. The current version isn't auto-routed like that one was, to some degree it's more 'bussed' and is nice and neat as I see it. IMO the auto routing is more messy unpreferred. That board was the first and last PCB I ever auto-routed aside from a prototype one off. Perhaps the comments about noise cap were in reference to those old boards as well. Not sure why I didn't put them on that one... It'd be easy to add one to the original since it was through hole. It's on the current version.
Quote:
Just a bit of constructive criticism to help with the next HW revision before the INL-ROM v2 comes out.
I've started shipping them in place of v1 boards with flash upgrades for people interested in them.
Realizing that the comments might have been all about that initial kazzo board I made which was my first PCB ever, I agree with all points actually. Aside from the fact that image was pre-ground pouring. The discussion of my other boards made me think the comments were directed to all my boards.
Here's a trace shot of my 'final' version with the SNES connector and everything handrouted and such.
infiniteneslives wrote:
Pasky wrote:
I didn't see any 100 nF caps. I was told there would be caps.
? on the kazzo? What were you told by who, and for what?
joke, I guess.
Quote:
22uF power cap on the current boards
That's a good step.
Quote:
What reliability issues are being seen?
I'll have to review the relevant logs, but the keyword was "flaky". Still, the square button Famicom was "flaky" as well.
Quote:
I'll take the hit on 12mil Vcc traces could be wider. But I've never had an issue with them and that's what I've always used.
I'm no EE, just parroting what I've been told. But I guess that when they're real thin, they start picking up noise, and there's resistance to getting the power out of the 22 uF. That's what the 100 nF next to each Vcc pin is for.
Quote:
I don't see much point in giving the flipflops their own.
Yeah, you can probably get away with sharing a cap among simple chips that are close together. At least Nintendo appears to have done so on cart boards. I plan to ask about 1 nF vs. 100 nF bypass caps.
Quote:
Although if you're talking about that kazzo board I made years ago, I'd agree with you.
And now I realize you've improved this in newer revisions. Thanks for explaining. I'll ask about this new revision.
Quote:
The kazzo is 'bussed' to some degree where the routing was easy.
He said the old kazzo looked like you tossed all the chips in and let the autorouter sort it out.
So I showed the new kazzo to these #nesdev regulars. One thought the new layout was "slightly less horrid"; another thought it was even worse. Mixing DIP and SMD and the way you did power/ground fill allegedly wastes space and makes the PCB messy. And I hope they were joking when they said you "should just not make boards, period", and that we'll never run out of donor carts. Fortunately, one of them defended you a little: "well everyone has a learning period".
Given the constraint of a reasonably small 2-layer board for cost and fabrication speed reasons, I doubt they could do better.
Anyway: low speed, digital, 5V logic? They're making mountains out of molehills.
Well they've past the point of trying to provide constructive criticism and shown their true colors. Guess I can stop feeling like I might be missing out on something by not frequenting the IRC if those are the comments by the 'regulars'. Please don't bother in presenting my response to them and then continuing with the talking through you. I don't mind you posting things that were brought up in the IRC if it's constructive. But if they're just trying to poop on my face because they some how feel their donors are threatened by my work that discussion can stay on the IRC and I'll stay here. If they feel inclined to discuss it further they can post themselves or PM/email me.
For anyone who's curious of why I choose the DIP package on the mcu, I have made that decision based on what I thought users would appreciate. I think it's the same reason the arduino is all smt aside from the main mcu. The board size cost of going with a DIP for the mcu was negligible. Going SMT on the avr would have only reduced the board size by ~1cm on the one edge which is only ~12% at most. The bigger cost is the socket, and time needed to hand solder through hole compared to baking on SMT. If I were being selfish I would have much rather have gone SMT to be honest. Going with the socketed DIP was a cost that I deemed worth it to the benefit of the user. Without a case and due to the nature of a project like this, people are pretty quick to start tinkering and might somehow kill their mcu. With a SMT mcu most people would have to toss it in the trash. But this route allows me to ship off a $2 mcu and they can pop it in themselves. Or even acquire their own mcu if they have access to an avr programmer. The smt parts I do use pose little risk for damage, and allowed for sizable asse [EDIT: think I was trying to say "allowed for significant increase in ease of assembly"]
infiniteneslives wrote:
Well they've past the point of trying to provide constructive criticism and shown their true colors. Guess I can stop feeling like I might be missing out on something by not frequenting the IRC if those are the comments by the 'regulars'.
Yeah, I figured. I thought it was constructive at first, but then it devolved into "can't tell if serious".
I wouldn't worry about it INL...haters gotta hate
I personally recommend your products to anyone whos looking into repros or development. They are really easy to use, and the fact that you are willing to tailor boards to a users' needs is absolutely phenomenal. I've made a few orders from you so far, and I will be back for more soon enough I'm sure!
Hey, we're not a bad bunch of #nesdev regulars. The board design does look rather...complicated, but hey, if it works, that's the important thing, right?
The problem is that even if it works in your environment, it might not work in someone else's.
A production board needs to be more reliable than the prototype that works in your lab because it will be used with end users' equipment that might be running in electrically noisier or otherwise harsher conditions. Things fail based on temperature, humidity,
phase of the moon, etc. A 1 nF cap isn't beefy enough to properly reject sags in an IC's power supply. Though you did add ground fill, some of the ground traces appear so narrow they look like resistors (
follow the current). Better busing means fewer vias and a smaller board. Lining up chips end-to-end may look cute, but it can make routing harder.
Case in point: Someone mentioned a Codemasters game that works on a front-loading NES Control Deck but crashes on the NES-101, because whoever manufactured the board for Camerica forgot to populate a bypass cap somewhere on the board. He soldered in the proper cap, and it worked perfectly.
Case in point 2 (added 2014-02-19):
Adding caps worked for magno.
I'm not trying to dis; I too have had similar problems in software-ville where things blew up when trying to run insufficiently robust code out of its original environment. A bug in initializing memory led to a humorous graphical problem in Thwaite (player missiles being drawn with the balloon graphic), and a bug in palette copying led to graphical corruption in Concentration Room. Neither problem occurred when the game was run in isolation; they appeared when the games were included in the multicart. A few programs by Shiru and Nioreh had a similar problem: when clearing nametables, they ended up clearing the pattern tables too if run on a CHR RAM cart. But fortunately, all these problems were documented and fixed in time for the STREEMERZ multicart.
Quote:
The problem is that even if it works in your environment, it might not work in someone else's.
I've got several thousand data points saying my methods of PCB design are doing just fine for the classification of signals I'm working with.
Quote:
Better busing means fewer vias and a smaller board. Lining up chips end-to-end may look cute, but it can make routing harder.
I'm perfectly content with the board size of my current designs. I agree fewer vias, and bussing makes boards smaller. However setting guidelines for 'perfect' busing would require boards at least twice the size for my current designs. I bus signals within the limits of what I've determined as the minimum board size based on component selection and placement. One of the biggest factors for me which isn't being considered by any comments thus far, is design for manufacturing. The discretes aren't all lined up to be "cute" they're lined up that way for ease of manufacture.
Quote:
Case in point: Someone mentioned a Codemasters game that works on a front-loading NES Control Deck but crashes on the NES-101, because whoever manufactured the board for Camerica forgot to populate a bypass cap somewhere on the board. He soldered in the proper cap, and it worked perfectly.
I can understand how partially assembled boards can have different results on one system compared to another. That's not necessarily the fault of the PCB design though...
Quote:
I'm not trying to dis; I too have had similar problems in software-ville where things blew up when trying to run insufficiently robust code out of its original environment.
If someone can show me where the problem is in practice, i.e. evidence that my designs aren't robust, I'll take advice on how to solve it. Currently I have had no bugs or flakiness reported on these boards.
Hrm...
Can I not take a few month sabbatical without this place falling to the trolls?
INL, don't you worry bro. Your products are rock-solid. The haters out there complaining that your buses ain't straight are also the guys that have never shipped a damn thing. You've done so much more for this community than any of them ever have! Hold your head up high! You should be proud of the things you've accomplished, and comforted in the thought that the community as a whole has benefited from your labors.
Before you came along the only way to get a development system was to either slice up an existing cart (I'm looking at
YOU Ultima: Exodus
) or buying a bare PCB from a guy that sells pirated games (not getting into that here). Now you can get a reusable flash cart and a reliable USB-based flasher for under $40 USD from a reputable manufacturer.
THIS MAKES MY MIND ESPLODE!!!So thank you,
THANK YOU INL for all of your hard work and contributions to this community. They are, in my opinion, among the most important we have seen.
Consider: If we didn't the hardware hackers we wouldn't understand the hardware like we do. If we didn't have the developers we wouldn't have homebrew to play. If we didn't have you we wouldn't have easily accessible flashcarts to play homebrew on, or develop with, or to hack the hardware with.
So yea, ignore the bastards and let's hope they all die in a fire. Tepples, you can copy / paste that last bit in IRC if you'd like
I agree: thank you INL. Even if your products are comparable in quality to the "cheap Chinese crap" flashers that kickstarted the GBA and DS homebrew scenes (and I'm not necessarily claiming that they are), you still have the advantage of a command of English to be more responsive to feature requests from customers in Europe and the Americas. But the only way I know to make an argument stronger is to find the points that the IRC crowd is likely to jump on.
infiniteneslives wrote:
I can understand how partially assembled boards can have different results on one system compared to another. That's not necessarily the fault of the PCB design though...
The implication was that "we didn't really need that cap anyway" appeared to have been a design change: early boards produced with it, later without it to save pennies.
infiniteneslives wrote:
If someone can show me where the problem is in practice, i.e. evidence that my designs aren't robust, I'll take advice on how to solve it. Currently I have had no bugs or flakiness reported on these boards.
Good point. The critics claim that flakiness has already been reported. If I can get them to cough up specifics, I'll let you know.
qbradq wrote:
The haters out there complaining that your buses ain't straight are also the guys that have never shipped a damn thing.
One of these critics claims to design control modules for industrial freezers as his day job, as I understand it. Perhaps having to work at both room temperature and sub-freezing temperature, unattended for long periods of time, with a single failure causing beaucoup bucks of real-world damages, changes how much reliability one feels like he has to design into a product.
qbradq wrote:
Consider: If we didn't the hardware hackers we wouldn't understand the hardware like we do.
Except one of these hardware hackers who produced a bunch of mapper docs is also the freezer guy. Another sells CF to N64 adapters, if I remember correctly.
qbradq wrote:
If we didn't have the developers we wouldn't have homebrew to play.
And if in the fourth quarter of 2008 I hadn't bought a CF to NES adapter produced by that guy who's winding down his pirated game business, I'd probably be coding 2.5-D platformers for the PeeCee.
tepples wrote:
I agree: thank you INL. Even if your products are comparable in quality to the "cheap Chinese crap" flashers
Is this supposed to be a compliment?
I'm saying that even if the IRC crowd is right, INL is still making a positive contribution to the scene. Edited for clarity. It's hard for me to be the go-between when 1. I have mild autism that affects my assessment of my own tact, and 2. we have an IRC crowd claiming I'm making them look bad to the BBS crowd and vice versa. I'm not interested in winning an argument, just improving the product should it need improvement.
I get it, I just found that particular sentence funny.
Most people in the same position as you would most likely not care, thinking that "nobody is forced to buy hardware they think is crap" and "if the haters hate it so much they should either do better or shut up". But I get that you are trying to get something positive out of this, conveying whatever can be considered constructive criticism to a person who might be able to provide even better products to the community.
tepples wrote:
I'm saying that even if the IRC crowd is right, INL is still making a positive contribution to the scene. Edited for clarity. It's hard for me to be the go-between when 1. I have mild autism that affects my assessment of my own tact, and 2. we have an IRC crowd claiming I'm making them look bad to the BBS crowd and vice versa. I'm not interested in winning an argument, just improving the product should it need improvement.
"irc crowd" chiming in here. I was the one was mentioned making us look bad.
What I meant by that is that the "hater" in particular was making sarcastic quips at the design in response to certain comments mostly. Thing is that by the time it hits the Irc to forum translator this context might be lost. On top of that this person has been known to not always be quite as...tactful as he could be (he's usually completely right though) Another thing that doesn't quite translate over well when you got a middle man.
I appreciate the support and constructive discussions. I could do without the drama, or at least deal with it somewhere besides this thread. I feel that's a fair request being the OP and all. The kazzo is an open source design and isn't all about me. If people want to have a discussion about my general design techniques in a separate thread or in another media be my guest. Thank you.
qbradq is spot on, if these "experts" can do better, let them, so far they're contributing nothing of any constructive use (very unlike INL), so their opinions are effectively worthless, despite any technical validity, which hasn't been conclusively proved anyway.
IMO, "strengthening" any arguments is unnecessary and just fanning the flames/leading to the addition of wholly undeserved stress/drama to INL's life. I'd suggest a seperate thread (which INL should probably just ignore unless anyone has anything actually useful to say
) and/or lock this one.
Meanwhile, back at the point, I've been trying to get the INL Retro software working on Debian Linux AMD-64 and am running into some issues. The Mono runtime throws a type loading error when loading LibUsbDotNet. The stack trace is completely useless, as all module and file references are empty (just says <Module> or FileName: "").
I downloaded what I thought was the latest version of LibUsbDotNet (2.2.8) from
here and executed the Test_Info.exe program with the Mono runtime. It detected the Kazzo board just fine and displayed all of the information. So I copied the LibUsbDotNet.dll file from that package back over to the INL Retro directory and ran the software again. This time I got the another TypeLoadError exception, but with no stack trace.
One thing I did notice was that the LibUsbDotNet.dll I downloaded was dated a year earlier than the one you provided, and was about 100k larger.
I know you don't officially support Linux, but could you help me out a bit on this? Could you let me know what version of the library you referenced and where you downloaded it from? Any chance you'd be willing to release the source code, or let me look at it under an NDA?
M'kay, so what I've figured out is you're using LibUsbDotNet version 1.0.1. That explains some of the confusion I was having. I've traced the actual problem to not having the Visual C++ 10 redist DLLs in the app directory. The error message Mono was throwing was unhelpful, and I had to use an strace log to figure that out
When I go home for lunch I'll see how far I get after adding those DLLs.
Let me know how it goes. I'm more than willing to share the source code for the firmware and software. With everything still under development I haven't taken the time to clean things up and make them available. Make sure if you're using my host software that you're also using my firmware. The original kazzo firmware isn't compatible with my host app, and vice versa.
Check out my
readme.txt for more details and history of where everything came from. That might help your efforts getting things up and running in linux.
INL,
I'd really appreciate the source code. That might get me up and running with your software.
I have attempted to use the original Kazzo firmware with the original software, but it keeps saying that m_database is not found. I might dig deeper into that, dunno.
I am using your firmware when attempting to run your software. Right now I can't even get the GUI up
Your software runs fine under Wine, just Wine doesn't play well with LibUSB (as in not at all). I'm trying to get it to run under 32-bit Mono at the moment with the Wine core libraries, but I keep getting stack traces with no source to compare them to and it's very hard to get anywhere like this
I've still got a ways to go before I want to start doing regular builds to hardware, but I just can't wait to see this thing work
*Grumble Grumble*
So Anago 0.62 has... issues. So I took a fork of Anago 0.60 (the last command-line version) and ported it to Linux. I was even able to dump my first cart with it tonight! My MMC1 SMB / Duck Hunt / Track and Field bonded chip cart.
I threw out all the legacy parallel port stuff, restructured the build to make it a little less of a headache to navigate and updated the documentation. It should still compile on Windows but I can't test it at the moment (if I had a Windows box to use this would be a moot point).
I've yet to write up the notes on how to configure udev to grant the right permissions to the USB device though. If anyone needs to use this thing on Linux and needs help, reply to the thread and I'll write them up. Until I hear back I'm assuming I'm the only one that actually uses this stuff
Attached is a compiled x86_64 binary with sources. You'll need to compile from source if you're on another architecture. Compilation instructions and dependency documentation included.
Edit: I wouldn't recommend using this for flashing carts (with any hardware). The Anago software in general seems to have... issues.
INL was kind enough to share his work-in-progress sources with me. Due to Managed C++ being quite lame it's not portable to Linux, but I was able to create a command-line utility that takes an iNES file and writes it to an INL-ROM board.
So, if anyone needs this in the future, here it is. And if anyone wants to port it to Mac or Windows, it should be fairly straight-forward (it's ANSI-C).
In order to use the device on a udev-based Linux system (which is just about every Debian system I've seen), you'll need to add a rule for udev, then reload the rules.
Code:
sudo echo ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev" >> /etc/udev/rules.d/10-local.rules
sudo udevadm control --reload-rules
Following this, unplug your programmer (if it was already plugged in) and plug it back in.
I was just about to post something on here asking if it was possible to get anago working on linux so this is fantastic
I'll give this a shot and let you know how well it works for me.
私は長い間このスレッドを見ていませんでしたが、 kazzo がいつの間にか進化していることに驚いています。
anago のソースコード、 0.62 に問題があることは Linux での command line support を打ち切ったからと解釈しているようですが、その通りではありません。 GUI 化は Windows, Linux ともに行いました。Windows では1つの実行ファイルで GUI と command line をサポートすると、都合が悪かったので別の実行ファイルを作るように compile option を追加しました。
Linux では1つの実行ファイルで両方をサポートできると思ったのでこのような形にしています。Linux でも Windows に似せた compile option を使えば、 commandl ine only の実行ファイルは作れると思っています。
私は通常は Windows XP を使用し、 Linux は当時の開発の時だけに使っていたのでサポートは不十分かもしれません。
最近私のPCを WIndows XP から WIndows 7 に変更したため、対応作業をする予定です。(Vista, 7 でインストールに困っている人の意見を何度か見たことがある) Linux だけにしろ 64bit support はとてもよいことですので、対応作業に合わせてソースをマージするかもしれません。
naruko wrote:
I was not looking at this thread a long time, but I am surprised that kazzo has evolved imperceptibly.
It seems to interpret that there is a problem of source code anago, to 0.62 and broke off from the command line support on Linux, but it is not as that. Made both Windows, Linux GUI is mosquitoes. When you support the command line and GUI on a single executable file In Windows, added compile option to make the executable file another convenience about the poor.
It has something like this because I thought that it can support both in a single executable file on Linux. It is hoped that if I use the compile option that are similar to a Windows even Linux, you can make a run file of commandl ine only.
Support may be insufficient to using Windows XP normally, since I use only when the development of Linux at the time I am.
Due to a change in WIndows 7 WIndows XP from my PC recently, we plan to support the work. 64bit support because it is a very good white (have seen several times the opinions of people who are in trouble to install Vista, 7) the only Linux, you might want to merge the source to match the response efforts.
Note: Above is from Google Translate into EnglishI had a number of problems compiling Anago 0.62 for Linux with GCC 4.7.2. The Anago 0.60 sources required less effort for me to get working, so I went with that. I understand that Anango 0.62 is intended to support both platforms. I think the language barrier may be getting in our way though.
私の主語が抜けていてソースのマージをqbradqさん(you)に指示する翻訳になっていました...
私は指示をする意図はなく、ソースコードの対応は私がやるつもりで書きました。ごめんなさい。(日本語は主語を省きやすい言語です)
当時私が使っていた gcc のバージョンは3.4.5 でした。 バージョン 4 以降から -Wall がさらに厳しくなったことは記憶しております。
3年前の対応なので私の記憶が曖昧ですが、 nescartdb 配布の xml ファイルを参照することにしたことが原因かな? コマンドラインを使うにしろ wxWidgets の xml pharser が必須になったかもしれません。個人的にデータベース参照は重要と思ってはいないのですが、ユーザーの方の要望や展示時に合わせて急いで私が実装しました。ですから、コマンドライン専用版はそこらへんがまずいかも。
パラレルポートサポートは私も不要と感じていたので削除する予定でした。
Yea, I wasn't terribly interested in providing community support for Anago. The port was just a quick job to make sure the hardware was working. I shared it in case anyone else could get use from it. My main interest is using INL's board for flashing his custom flash carts for development and production.
Thank you for your kind responses.
infiniteneslives wrote:
Well they've past the point of trying to provide constructive criticism
Given
new evidence, I withdraw my objections to your design, citing
Matthew 7:3.
In any case, I have a really old Kazzo from years ago, and I wonder how I'd go about converting it to the new firmware. There are people asking me to add support for some famiclone controllers to a game I made, and the PowerPak I have doesn't support famiclones. Is it as easy as plugging it in and uploading the new firmware?
tepples wrote:
Is it as easy as plugging it in and uploading the new firmware?
Yeah it should be pretty straight forward, I haven't changed much with it in regards to the bootloader. The only thing I did start doing was change the fuses so the bootloader can't overwrite itself any more. So just make sure you don't write the original kazzo firmware to it which hasn't been clipped. If you only use the .hex files in the firmware folder of the .zip download from my site you'll be safe. If you run into issues let me know and I can send a new avr with the bootloader locked.
See the readme for explict instructions, they should apply to all kazzos I've ever made, athough the SNES stuff obviously doesn't apply to my first few batches which lacked SNES connectors and that cap.
I was curious on what progress has been made on that new firmware update for the kazzo. The one that would automatically detect common mappers. I saw it being mentioned back in Sept. But haven't seen anything since then...
I had inserted a bug in my code right around that time which was causing troubles when flashing nes boards. That set me back a bit as I didn't have as good of version control as I should and lost the working source. I've been waiting on fixing that before releasing a new version, good news is I finally found the problem last night and corrected it. So I'm officially moving forward again.
Here's roughly my current task list on my firmware in order of priority.
- Add support for flashing discrete mapper boards. (In-progress, small amount of time needed ~week?)
- Make flashing SNES boards 'smarter' to handle things like interleaved roms, 6MB roms, and auto-doubling (faked mirroring) to make large boards look smaller. (Not started, medium amount of time needed to accomplish ~month?).
- Allow software/firmware to accept .nes and .smc files. Gets a little complicated with all the variants of everything, but the idea is to make it almost as easy as loading a file into an emu. (Not started, large amount of development time in relation to others.)
- The inverse of the above, aka auto-dump carts by sensing the hardware and building the dumped rom. (Not started, about same time as previous.)
I would say these things are reasonable to do within a couple months. I do have NES mapper sensing operational by use of mirroring. Sensing variants and rom size will be a separate effort. I probably got ahead of myself a little shooting for Sept based on the higher priority items like smarter NES/SNES flashing coming first. The other consideration is that I'll be devoting more of my development time to the nesdev compo for the next ~3months... Can't make any promises on the above, just inform you of where I'm at with things.
Glad to hear things are back on track! This is still a wonderfully useful tool, and by far the cheapest and easiest NES hardware development tool I've ever owned!
On the topic of firmware updates, I have a question and suggestion.
1. Do you update the original Kazzo firmware in your file bundle when it's released (is it even updated anymore)?
2. It may be worth adding a date/firmware version to the site so people can quickly check if they're up to date.
I released a new one ~2 weeks ago.
I agree about the versioning, right now the only way to tell is the date. Next release I'll try to make this more clear and make note of things in a change log.
infiniteneslives wrote:
I released a new one ~2 weeks ago.
I agree about the versioning, right now the only way to tell is the date. Next release I'll try to make this more clear and make note of things in a change log.
Just DLed the latested, and had a couple questions. I've been using the 2013-8-19 firmware, do I need to do a fresh install of the whole 2013-12-22 Kazzo.zip, or can I just replace the firmware folder with the newer build? Comparing the two zip packages, only found a difference with the firmware folders, did I miss something else?
ATM, the 2013-8-19 is working fine for me with the two boards (SXROM) I have, are there new features or is this a maintenance build?
Thanks for your very cool project!!
Yogi
Yeah only real change is the .hex file, so all you need to do is update the firmware with to update to this release. The only other thing may be the included erase files.
Added features for this release include support for flashing mapper28, mapper0, and nsf mapper.
infiniteneslives wrote:
Yeah only real change is the .hex file, so all you need to do is update the firmware with to update to this release. The only other thing may be the included erase files.
Added features for this release include support for flashing mapper28, mapper0, and nsf mapper.
OK great! Good to hear 'bout added support for Mapper 0, will be interested in your V3 boards when available.
Yogi
infiniteneslives wrote:
I released a new one ~2 weeks ago.
Ah, sorry about the confusion, I meant the firmware created by the Japanese dev who made the Kazzo.
MasterOfPuppets wrote:
infiniteneslives wrote:
I released a new one ~2 weeks ago.
Ah, sorry about the confusion, I meant the firmware created by the Japanese dev who made the Kazzo.
No idea... I had my share of frustrations with it which motivated me to write my own.
Having some weird trouble with my attempts to write a Little Samson game to a flash cart. I bought 3 of the same boards and had the upgraded to include the chips that I needed (128 chr and 256 prg) I split the rom into the correct segments (although I got an error saying it might be wrong). I then used the basic writing program and wrote to one board and got an error. Tested it anyway and it worked just fine!
Now a little while later, I try to do it again, using same chr and prg and I'm getting error -5 and -116. The game won't work and when I plug it into my top loader it says the prg isn't found, but chr is OK. While writing both I get an error..... not sure what's going on at all!
satashi26 wrote:
I bought 3 of the same boards and had the upgraded to include the chips that I needed (128 chr and 256 prg) I split the rom into the correct segments (although I got an error saying it might be wrong). I then used the basic writing program and wrote to one board and got an error. Tested it anyway and it worked just fine!
If you send a file that is smaller than the selected header size you'll get an 'error in page 0'. The write will have occurred, but the app sensed something strange as you didn't send it as much data as you told it you would.
Quote:
Now a little while later, I try to do it again, using same chr and prg and I'm getting error -5 and -116. The game won't work and when I plug it into my top loader it says the prg isn't found, but chr is OK. While writing both I get an error..... not sure what's going on at all!
Did you erase the flash? you can't rewrite the boards without erasing them first.
You're toploader says PRG isn't found, but CHR is okay? How exactly do you get that information from a top loader NES...?
Hey all. Just registered to ask some questions about this
I received a Kazzo board from INL a few weeks back and am trying to dump some games with it. However, I keep getting "reader open error" when I try to dump a game in the anago GUI. I am running Windows 8. The first thing I did was install the driver following the guide on NeoGAF, and when that didn't seem to work when it came time to dump a cart, I also tried using the Hardware Wizard to install the driver from the INL_Retro-Prog.inf file. They indicate that it was installed properly.
When I run "kazzo_test" that's included with the software I receive the notification "Could not find USB device "kazzo" with vid=0x16c0 pid=0x5dc."
Any suggestions?
infiniteneslives wrote:
satashi26 wrote:
I bought 3 of the same boards and had the upgraded to include the chips that I needed (128 chr and 256 prg) I split the rom into the correct segments (although I got an error saying it might be wrong). I then used the basic writing program and wrote to one board and got an error. Tested it anyway and it worked just fine!
If you send a file that is smaller than the selected header size you'll get an 'error in page 0'. The write will have occurred, but the app sensed something strange as you didn't send it as much data as you told it you would.
Quote:
Now a little while later, I try to do it again, using same chr and prg and I'm getting error -5 and -116. The game won't work and when I plug it into my top loader it says the prg isn't found, but chr is OK. While writing both I get an error..... not sure what's going on at all!
Did you erase the flash? you can't rewrite the boards without erasing them first.
You're toploader says PRG isn't found, but CHR is okay? How exactly do you get that information from a top loader NES...?
I think it was because I didn't have "header" selected when I erased them originally. I tried again with that being the only change and it worked just lovely fine.
How I got it from the top loader? I put the game in, clicked it on, and got a blue screen with an increasinly loud buzzing sound. On the screen it had lots of info kinda like the blue screen of death in Windows. It even had the INL url listed on it with InfinetNesLives tagged on the code. Was actually pretty cool to see, in a weird kind of way.
satashi26 wrote:
How I got it from the top loader? I put the game in, clicked it on, and got a blue screen with an increasinly loud buzzing sound. On the screen it had lots of info kinda like the blue screen of death in Windows. It even had the INL url listed on it with InfinetNesLives tagged on the code. Was actually pretty cool to see, in a weird kind of way.
It sounds like you're describing
Holy Diver Batman, the test program that INL loads into carts before shipping them.
Attachment:
holydiverbatman.png [ 897 Bytes | Viewed 2922 times ]
The buzzing noise is a test of the SRAM on the cart ("8K PRG RAM OK" in this screenshot).
If you're trying to write a ROM other than Holy Diver Batman, then something is interrupting the flashing process before it reaches the end.
xzx123 wrote:
Hey all. Just registered to ask some questions about this
I received a Kazzo board from INL a few weeks back and am trying to dump some games with it. However, I keep getting "reader open error" when I try to dump a game in the anago GUI.
It was probably shipped with my firmware on it. Look over the readme for explanation and instructions on how to flash the original kazzo firmware on there so you can run anago with it.
infiniteneslives wrote:
xzx123 wrote:
Hey all. Just registered to ask some questions about this
I received a Kazzo board from INL a few weeks back and am trying to dump some games with it. However, I keep getting "reader open error" when I try to dump a game in the anago GUI.
It was probably shipped with my firmware on it. Look over the readme for explanation and instructions on how to flash the original kazzo firmware on there so you can run anago with it.
Thanks! That solved it!
Mine has an issue. When I tried to dump games using the Kazzo firmware on my INL pcb.
It gets about 5% in and then it barks and growls at me and throws up an error message that says "No Error"
The documentation has nothing explaining this? Help?
GameMachineJames wrote:
Mine has an issue. When I tried to dump games using the Kazzo firmware on my INL pcb.
It gets about 5% in and then it barks and growls at me and throws up an error message that says "No Error"
The documentation has nothing explaining this? Help?
Sounds like the same issue I routinely have with the original firmware/software. I put a disclaimer on my site pointing
earlier in this thread. I find some of my PC's suffer from this issue worse than others. But it's only an issue with the original firmware/anago, with my firmware/app I don't experience this issue.
Just thought I would check in to see where INL was with his new firmware/dumping software solution.
I am looking for an .ad/.ag script for
Gumshoe, iNES Mapper 66. I believe this is the same mapper used for the combo
Super Mario Bros / Duck Hunt.
On that note, it might be helpful to setup a GitHub/SourceForge repository or something for all of the mapper scripts. It seems many exist, but they are not all in one place.
qbradq, are you still around? I was hoping you could confirm something for me - does dumping work under Linux? I saw your efforts relating to this, but I'm not quite certain where things currently stand. Can I just use the anago port you provided to dump my games through the Kazzo, or is there more to it than that? I saw you also discussing LibUsbDotNet and inlprog, but it looks like inlprog is a flasher and I'm not sure if LibUsbDotNet is really needed.
I recently discovered the Kazzo while searching for something to dump my NES games, having already gone through much of the rest of my library with my Retrode. Product looks great, but I'd like to confirm I can make this work under Linux before ordering.
Thanks, and thanks for your work getting this to work on Linux.
Just wondering if any more progress has been made on the software to be able to dump SNES games?
nitro322 wrote:
does dumping work under Linux? I saw your efforts relating to this, but I'm not quite certain where things currently stand. Can I just use the anago port you provided to dump my games through the Kazzo, or is there more to it than that? I saw you also discussing LibUsbDotNet and inlprog, but it looks like inlprog is a flasher and I'm not sure if LibUsbDotNet is really needed.
I have been using the Linux port to dump games for a few weeks now and I've had no real problems with it. I haven't done any flashing just dumping games.
The dropbox link on the product page no longer works
The drivers from the original kazzo page don't seem to install on my x64 Win7 system. I will try downloading WinAVR and compiling the drivers myself, but if there is any other advice to get this up and running, it'd be great!
After reading back a few pages, it looks like the firmware on the INL devices is not supported by the original kazzo source anyways.
If you wouldn't mind sharing the source, I would be open to helping to make (at least the dumper portion) cross platform. I would want to ideally use this on my mac or linux machines anyways.
The kazzo page states that the SNES connectors cannot dump SNES games. Is there anything known about if it can dump SNES prototype cartridges? Someone on another forum claims that it can do so (and better than the Retrode, for that matter). I'd like verification of this, and I'll probably buy one much sooner if it's the case (I was planning on getting one anyway, for NES protos I come across).
Anyone?
I tried emailing Paul, but haven't gotten an answer yet.
prototector wrote:
The kazzo page states that the SNES connectors cannot dump SNES games. Is there anything known about if it can dump SNES prototype cartridges? Someone on another forum claims that it can do so (and better than the Retrode, for that matter). I'd like verification of this, and I'll probably buy one much sooner if it's the case (I was planning on getting one anyway, for NES protos I come across).
Can't say 100%, don't have an INL SNES cart, but Paul has demoed using his SNES cart (storing a NES ROM) to mass prg his NES flash carts stand alone with just the Kazzo. So judging from that you should be able to dump from one of his flash carts, but don't know if it will work with a third party cart. Don't know how useful it would be, dumping the code that you loaded in the first place.
You may want to look at the thread for the INL FlashCart software
viewtopic.php?f=12&t=11020Not sure what enhancements are included but....
Yogi
Mainly looking to see if I can take a prototype cartridge of a video game, attach it to the Kazzo SNES slot and it can dump the data in the cart to the PC.
Is there a script to read/write the MMC6 PRG RAM for StarTropics and Zoda's Revenge? I tried editing the MMC3 scripts to dump and write the save files but couldn't get it to work for these games.
Ideally, you'd take the MMC3 script and make these changes:
- Write $20 to $8000 (enables access to internal PRG RAM in the first place)
- Write $F0 to $A001 (enables reading and writing both bank $7000 and bank $7200)
- Dump $7000 through $73FF instead of $6000-$7FFF
Did you make all three of these changes?
Yes, that's exactly what I did. I showed my work in
this topic. All I got from either game was garbage, and any operation deleted the save after setting 0x8000 and 0xA001 according to the documentation (at least it's doing
something!). I'd be glad if you could figure out how to get it to work.
I plan to do Kazzo. But a few things are not entirely clear. Can I replace the ceramic resonator quartz? According to the description corner 74HC574 manufacturer requires changes resistors. I have the opportunity to buy Texas Instruments SN74HC574.
And that the values of all the small parts can be replaced with slightly different? I have problems with the purchase of parts with perfectly the same values. And Can I use the 74LS/HCT574 instead HC574 ?
Can I please have some help? I have been trying to make backups of my nes games with the kazoo. I have been folowing this guide:
http://www.neogaf.com/forum/showthread. ... st72806661 anyways, every step worked fine but when I hit the "dump" button in ango_wx, it just says: reader open error
I have been recommended to restart my pc but that didn't do anything
any help would be appreciated!
-NESguy
bretts87 wrote:
Yes, that's exactly what I did. I showed my work in
this topic. All I got from either game was garbage, and any operation deleted the save after setting 0x8000 and 0xA001 according to the documentation (at least it's doing
something!). I'd be glad if you could figure out how to get it to work.
I replied to said topic, let me know how that script I made works as I haven't tested it.
sdm wrote:
I plan to do Kazzo. But a few things are not entirely clear. Can I replace the ceramic resonator quartz? According to the description corner 74HC574 manufacturer requires changes resistors. I have the opportunity to buy Texas Instruments SN74HC574.
And that the values of all the small parts can be replaced with slightly different? I have problems with the purchase of parts with perfectly the same values. And Can I use the 74LS/HCT574 instead HC574 ?
Yes you should be able to replace the ceramic resonator with a quartz crystal, I've modified my design to do the same. Any flipflops with similar control signals (rising edge clock control) should work. if you're asking about changing resistor or diode values I wouldn't recommend it.
NESguy wrote:
Can I please have some help? I have been trying to make backups of my nes games with the kazoo. I have been folowing this guide:
http://www.neogaf.com/forum/showthread. ... st72806661 anyways, every step worked fine but when I hit the "dump" button in ango_wx, it just says: reader open error
I have been recommended to restart my pc but that didn't do anything
any help would be appreciated!
-NESguy
yeah sounds like the same issue I have with several of my own PCs. If you have another PC that may resolve the issue. I put the
disclaimer on my site. Perhaps if I can push out a version of my own firmware soon that supports dumping that'd resolve your issues. From what I can tell it's only an issue with the original kazzo firmware. Submit a ticket on my website if you'd rather just return it.
I was using windows vista. Do you think it would work on my windows 8 computer? (I know how windows 8 is incompatible with tons of stuff
)
NESguy wrote:
I was using windows vista. Do you think it would work on my windows 8 computer? (I know how windows 8 is incompatible with tons of stuff
)
Worth a shot. My firmware and software works with windows8 after the driver signing hassle is bypassed, I'm not sure about the original kazzo firmware and anago app.
infiniteneslives wrote:
NESguy wrote:
I was using windows vista. Do you think it would work on my windows 8 computer? (I know how windows 8 is incompatible with tons of stuff
)
Worth a shot. My firmware and software works with windows8 after the driver signing hassle is bypassed, I'm not sure about the original kazzo firmware and anago app.
How do I bypass the driver signing stuff?
I finish my Kazzo
I use these memory chips: SST39SF020A, W29C020-12 and W49F002U-12B all work great.
By using the DIP32 stand, i use it as a flash chip programmer. I can write anything on memory flash - just only need to paste an NES header to BIN file. I can use the flash chips anywhere, not only in NES/FC cartridge (sega, atari, snes etc
I connect A16 to A16, A17 to A17 (not like in the description Kazzo where the A17 to A18). PRG A18 I have not connected because currently I do not have 4mbit flash.
BTW...
Based on Kazzo project, you can make very cheap USB flash memory programmer. You will need to: ATmega16, 74HC574, universal stand ZIF32, Kazzo resistors, capacitors, diode, usb etc. And a memory controller, eg. use NES cartridge MMC1 chip or done on the basis of 74LS161 (UNROM). All connections as described Kazzo, but only PRG ROM programmable (ZIF32). Memory will be programmed as PRG ROM only MMC1 board (A18 up to 29F040) or UNROM (A17 up 29F020 - but probably also the A18).
74xxx
or MMC1
Can anyone help me with figuring out how to dump
Wai Wai World 2? It uses VRC4 apparently, but regardless of whether I try to rip it using the command line version or the GUI version of anago, it doesn't come up with a functional ROM, regardless of which of the several VRC4-related scripts I use. I was especially hoping to get this game in particular to work since I don't currently have a way to play Famicom games on the original hardware.
EDIT: I got it to work! Apparently I had the cartridge in backwards? I tried to dump the game while having the label facing the direction of the cable plug-in, like I would for dumping any of my NES games, and it never worked that way. I tried flipping it this time around though, and it dumped perfectly. I feel kind of silly about it, but mostly I'm just glad I can play the game now
All sorts of reading and i'm still stuck, i need to dump Color Dreams (Mapper 11) roms, but i cannot find anything on how to do it. please help. sorry if its a spoon feed, but i'm stuck.
Hi, I've got a quick question. I've got a Zelda cart that doesn't want to surrender its SRAM to me. Strangely enough, I've got another Zelda cart that works just fine. Any idea what might be going on? I'm thinking it's a different board revision or something, but I'm not sure what changes I might need to make to the script file.
Some releases of Legend of Zelda use
MMC1B2, some use
MMC1. You'll probably need to both disable
SNROM's PRG RAM protection (set CHR bank size to 8 KiB and then manually clear CHR bank 0) and MMC1B's
later explicit PRG RAM protection (set PRG bank to something 16-31).
Hopefully that's it.
Sadly, I'm still a total NES newbie. I'm trying to make heads or tails of the changes I need to make to the SKROM routine. Should all those changes occur to the cpu_ram_access function? It's been a while since I've done a lot of microcontroller stuff (not cool!), so my brain is hurting a little bit.
Also, a really dumb question: do you folks pull USB power from the kazzo before you swap carts, or is it okay to hot-swap?
EDIT: Okay, I'm thoroughly confused now. It looks like the script is implementing at least some of the suggested changes?
Code:
function cpu_ram_access(d, pagesize, banksize)
{
mmc1_write(d, 0x8000, 1 << 3);
mmc1_write(d, 0xe000, 0);
mmc1_write(d, 0xa000, 0);
cpu_ramrw(d, 0x6000, banksize);
mmc1_write(d, 0xe000, 0xff);
}
It looks like the first part is putting the CHR Mode to 8k, the PRG Size to 16k mode, and something with the mirroring control that I'm not sure is important to this?
Next, writing a 0 here should enable the WRAM and set the PRG register bits to 0000.
The next line writes 0 to CHR Register 0? I'm assuming that's what's going on.
Then a read starting at 0x6000, of size 0x2000 (described further up). I think I understand that's where the WRAM is mapped, from 0x6000 - 0x7FFF.
Then disabling the WRAM again. What else would I need here? Sorry I'm being such a newbie with this...EDIT 2: Got it, got it, got it. Ignorance on my part. At the top, the PPU ROM banksize needs to be 8kB. I'm assuming this has to do with how the PRG RAM is mapped into memory. Learned a lot in the process, and have a working
Zelda save (from my childhood, no less!).
EDIT 3: I've run into a similar problem with
Zoda's Revenge as above. My original script had a screwup in it, and only partially nuked the save file. Using the downloaded one nukes it completely. I tried using 0xa0 instead of 0xf0 to keep the write protection enabled, but it didn't work, and things still get nuked. If anyone has any idea about this, let me know!
EDIT 4: Ha, should have checked the other thread about
Battletoads. Couldn't get the ANROM script to be agreeable at all, so I ended up dumping each bank separately (0x8000 to 0xc000 and 0xc000 - 0xffff), then busting out some trusty Python to rearrange things in the right order. Then I see the "d2" switch in another thread, which worked beautifully. Doh! Still, happy to be learning stuff.
Not sure it's useful for y'all, but I did some modifications to the MMC3 script to dump mapper 47 (QJROM, Super Spike V'Ball / Nintendo World Cup). Lots of hard-coded values, but I think this is the only game to use this particular setup.
I need help setting this up with linux. I was reading this page:
http://forums.nesdev.com/viewtopic.php?f=9&t=7912&start=240 about how qbradq was porting it to linux but when I tried to do it myself, I got completly lost (probobly becasue I got linux 2 days ago
) If someone could give me a clear explination on how to setup everything so I can dump roms again, I would greatly apreciate it!
-NESguy
Anyone ever try to read a non-standard NES cart through the Kazzo?
I'm trying to dump an odd MMC1 SKROM board that has a 256Kb CHR ROM. The spec for MMC1 states that 128KB CHR is the max, but in this case a 256Kb CHR is 100% in use and is necessary.
When I dump using the mmc1_skrom.ag script I get an equal 128Kb PRG and a 128Kb CHR. The game loads but the CHR GFX is off at parts.
I managed to modify the script and now I get a 128Kb PRG and 256Kb CHR but the GFX are totally screwed up.
Code:
board <- {
mappernum = 1, vram_mirrorfind = false, ppu_ramfind = true,
cpu_rom = {
size_base = 1 * mega, size_max = 2 * mega,
banksize = 0x4000,
},
cpu_ram = {
size_base = 0x2000, size_max = 0x2000,
banksize = 0x2000
},
ppu_rom = {
size_base = 2 * mega, size_max = 2 * mega,
banksize = 0x0400,
}
};
I assume that I need to adjust the other address values to tell the anago software to read the CHR ROM past 128Kb.
Any thoughts or suggestions would be greatly appreciated.
Thank you.
A 256 KiB CHR ROM requires 18 address inputs: A0 through A17. But the MMC1 has only five CHR ROM address outputs: CHR ROM A12 through A16. What wire goes to CHR ROM A17?
I'm trying to use the Kazzo to dump a Lolo 3 prototype, but am running in to problems.
The prototype cart uses a MMC1B2 mapper.
This is how the first 128 KB of PRG of the resulting dump I get compares to the released version of the game
0-16 KB - Match exactly the released version
16 KB - 32 KB - Same data that is contained in 64 KB - 80 KB of dumped ROM
32 KB - 48 KB - Match exactly the released version
48 KB - 64 KB - Matches 112 KB - 128 KB of released version
64 KB - 80 KB - Match exactly the released version
80 KB - 96 KB - Same data that is contained in 64 KB - 80 KB of dumped ROM
96 KB - 112 KB - Different from released version
112 KB - 128 KB - Matches 80 KB - 96 KB of released version
So basically some 16 KB chunks match the released version, some 16 KB chucks match but are out of order, some 16 KB chunks of data are repeated, and one 16 KB chunk is different.
Does anyone have any suggestions? The prototype works in a NES. Below are some pictures. Also, there is a label on the back of the prototype that states "SK EPROM 1 MEG x 1 MEG A9 MOD" I'm not sure what the "A9 MOD" means. I have tried using both the "mmc1_skrom.ag" and the "mmc1_surom.ag" scripts.
Quote:
A 256 KiB CHR ROM requires 18 address inputs: A0 through A17. But the MMC1 has only five CHR ROM address outputs: CHR ROM A12 through A16. What wire goes to CHR ROM A17?
Tepples, CHR ROM "A17" is routed to PRG ROM "VPP"
brian wrote:
I'm trying to use the Kazzo to dump a Lolo 3 prototype, but am running in to problems.
[...]
I have tried using both the "mmc1_skrom.ag"[...]
What problems are you running into? The 27C301 apparently only holds 128 KiB of data. (Is CHR not dumping at all? Or what do you get?)
lidnariq wrote:
brian wrote:
I'm trying to use the Kazzo to dump a Lolo 3 prototype, but am running in to problems.
[...]
I have tried using both the "mmc1_skrom.ag"[...]
What problems are you running into? The 27C301 apparently only holds 128 KiB of data. (Is CHR not dumping at all? Or what do you get?)
The dumped ROM is not usable. The CHR is dumping as well, but it is similar to what I see with the PGR when I compare to the released version - it matches in some sections but is completely different in others.
If you have a multimeter, can you check if the MMC1 is connected
the same way as normal NES-SKROM ?
lidnariq wrote:
If you have a multimeter, can you check if the MMC1 is connected
the same way as normal NES-SKROM ?
I have a multimeter, but unfortunately I'm not very familiar with it or what I would need to do to check this.
For each labelled pin on the wiki pinout of the MMC1, see if it connects to the corresponding pin on the 27C301s and/or the cartridge edge connector
27C301 pinout:
http://www.arcadiabay.de/images/elektro ... pinout.jpgCartridge edge connector:
http://wiki.nesdev.com/w/index.php/Cartridge_connectorThe multimeter hopefully has a "continuity" mode, perhaps indicated with a
o))) (three progressively larger parentheses) icon, that will beep if you touch the leads together. That's the easiest way to check this.
lidnariq wrote:
For each labelled pin on the wiki pinout of the MMC1, see if it connects to the corresponding pin on the 27C301s and/or the cartridge edge connector
27C301 pinout:
http://www.arcadiabay.de/images/elektro ... pinout.jpgCartridge edge connector:
http://wiki.nesdev.com/w/index.php/Cartridge_connectorThe multimeter hopefully has a "continuity" mode, perhaps indicated with a
o))) (three progressively larger parentheses) icon, that will beep if you touch the leads together. That's the easiest way to check this.
Ok, thanks for the hints - I was able to figure it out.
Everything mapped in the diagram for the MMC1 except for:
- MMC Pin 5 says it should map to PRG /CE (Pin 22) but on the proto it maps to PRG OE (Pin 2)
- I didn't check MMC Pin 6 (not sure where the WRAM CE would be to check?)
- MMC Pin 4 says it should map to PRG A17 but I don't see an A17 on the HN27C301 diagram. I checked the other pins on the PRG chip but it didn't map to any of them.
Thanks again for your help figuring this out!
For a ROM, /CE (chip enable) and /OE (output enable) do similar things. Pulling /CE high puts the ROM in a low-power state. Pulling /OE high keeps the ROM powered and just disconnects it from the data bus. The ROM responds faster to /OE than to /CE. So some games will use /OE as the primary chip enable to squeeze a little more speed out of the ROMs at the cost of power consumption.
tepples wrote:
For a ROM, /CE (chip enable) and /OE (output enable) do similar things. Pulling /CE high puts the ROM in a low-power state. Pulling /OE high keeps the ROM powered and just disconnects it from the data bus. The ROM responds faster to /OE than to /CE. So some games will use /OE as the primary chip enable to squeeze a little more speed out of the ROMs at the cost of power consumption.
Thanks for the info. So I'm assuming that probably would not explain why I can't get a good dump with the Kazzo. Do you or anyone else have any other ideas for what I could try or check? Thanks again for everyone providing suggestions and info
First thought: any visible rework anywhere on the PCB? "A9 MOD" implies something to do with address line 9 ... I'd naively assume PRG instead of CHR, but...
I have no idea what use there would be in modifying (as opposed to simply repairing) A9, though.
BootGod has some references PCB pictures from Skrybe
here, if anything's not obvious...
I don't suppose you have access to someone with a 'PROM programmer? At this point my best guess would be to try reading the ROMs directly...
What kind of EPROM programmer would be best to read these kind of chips? How difficult is it to remove the chips from their sockets? I've never done anything like this before.
There were a couple of reworked things on the back of the board, here are some pictures
brian wrote:
What kind of EPROM programmer would be best to read these kind of chips?
For chips that old, just about any EPROM programmer will do.
I have a Minipro TL866CS. To read those chips with it, I'd just have to choose a 128kx8 EPROM from the support list (it doesn't matter which one, since reading is the same for all of them) and click the button to save the chip's contents to a file.
brian wrote:
How difficult is it to remove the chips from their sockets?
Usually it's pretty easy. I like to use a screwdriver to gently pry the end of the chip up, alternating between both ends so it doesn't bend the pins too much. There are other methods as well, so if you're not comfortable doing that, I'm sure someone else can offer a better suggestion.
... Sure enough, "A9 MOD". Both PRG and CHR appear to have a diode clamping the voltage on that pin to not go above Vcc. (Is there any identifiable text or symbols on the black-and-blue cylinders?)
I can't figure out what why one'd need that, though; sure, many early EEPROMs have either identification or extra memory when A9 is raised to Vpp, but not the 27C301. (i.e. the modification doesn't match the UVEPROMs)
Joe wrote:
I have a Minipro TL866CS. To read those chips with it, I'd just have to choose a 128kx8 EPROM from the support list (it doesn't matter which one, since reading is the same for all of them) and click the button to save the chip's contents to a file.
The 27C301 is a subtly different pinout than the 27C1001 (with A16 and /OE swapped) so it wouldn't be
anything ... in fact, looking through my minipro's supported list, it doesn't obviously look like it could dump the entire ROM.
Actually, I'm really surprised that I've can apparently find plenty of NES-SKEPROM protos that all work with either 27C1001 and 27C301s on them and no obvious rework. That doesn't make sense to me...
brian wrote:
How difficult is it to remove the chips from their sockets?
I've had good luck with a thin screwdriver, gently inserted in-between the top of the socket and the underside of the CERDIP, and then gently rocked/rotated a little bit at a time to lift out all four corners are uniformly as possible.
http://www.dansdata.com/sbs10.htm seems to be strongly of the opinion—and I think I agree—that historical "DIP pullers" are awful.
lidnariq wrote:
The 27C301 is a subtly different pinout than the 27C1001 (with A16 and /OE swapped) so it wouldn't be anything ... in fact, looking through my minipro's supported list, it doesn't obviously look like it could dump the entire ROM.
Interesting, I hadn't noticed the difference in pinout. It's a small enough change that it's still pretty easy, as long as you don't mind
building an adapter.
Thanks again for all the help and suggestions.
The black-and-blue cylinders appear to have "R49" on them.
Are there any EPROM programmers that would be able to read these chips without having to make an adapter?
Do you think I would have any better results trying to dump with a CopyNES? Or would I probably have the same issue?
Thanks again!
This person is having pretty much the exact problem I am having when he tries dumping Metroid with the Kazzo:
viewtopic.php?f=9&t=12974&p=150508#p150508He said the first 16K is OK, but that "there are big portions that are not matching following that, but some of it does. I dont know if the script is reading the banks in the right order?". This is exactly what I am seeing when dumping the Lolo 3 prototype.
I checked a copy of Metroid that I have and sure enough it also has a MMC1B2 chip in it just like the prototype I am trying to dump.
So it appears that maybe the Kazzo scripts don't support the MMC1B2 chip?
Hey guys,
Just bought this lovely device and wondering if anyone had the same problem, seems like no other Windows 7 users have reported this to my knowledge.
I'm following the instructions to operate the Kazzo NES INL Retro Dumper but have been running into a problem. I keep getting "Windows has stopped this device because it has reported problems. (Code 43)" as an error code. It seems Windows is shutting the device down before I can even configure it when I try and generate drivers.
Windows 7 refuses to acknowledge the device, when I try and pick the dumper to install drivers on it claims its product id/vendor id is 0x0000 and putting the two proper ID's into the installer does not seem to help. There is an MI ID that I can place but I do not know this value.Any attempt to install drivers fails.
Is there any way to get Windows 7 to recognize this thing before it shuts it down? Is there a way to get drivers onto it via Windows 7 if it keeps doing this?
Thanks,
Steve
Hoping someone can help me with this.
I've fired up my Kazzo on my Windows XP machine finally. Followed all of the installation steps; everything seems to have gone smoothly, but the only difference is that even after changing the device's firmware to the Kazzo's (for dumping), it still appears as INL-Retro Prog in Device Manager (EDIT: Did a re-install and it now appears as Kazzo). I didn't think much of it because the whole installation process went otherwise problem-free.
I decided to get on with backing up some games. I have Blades of Steel and Duck Hunt North American carts for testing. BoS appears to be backing up fine, but it turns up a different checksum for the ROM every single time; of course, the ROMs don't work when testing on an emulator (update: some of the several more attempts created ROM files that do work in emulators, but again, they're different each time and also different from the known retail checksum). The cartridge has no issues and I've selected the correct script (UNROM). Duck Hunt simply won't be dumped at all, giving the error:
AN ERROR HAS OCCURED [the index 'ppu_rom' does not exist]
CALLSTACK
*FUNCTION [dump()] dumpcore.nut line [22]
LOCALS
[ppuarea_memory] NULL
[vram] 1
[increase_ppu] 1
[increase_cpu] 11
[mappernum] 0
[script] "nrom.ad"
[d] USERPOINTER
[this] TABLE
Also:
-When the cartridges are inserted, they are fitted, but can still wobble back and forth a fair amount. I'm fitting them with the orientation shown here:
http://www.neogaf.com/forum/showthread.php?p=72806661 (scroll down)
-What does the red light indicate? It turned on during the installation process, but hasn't since then.
Any help is appreciated.
UPDATE: I have now successfully dumped both cartridges. It turns out the culprit was the anago gui; command line version dumped both without a hitch. The BoS cart was being dumped incorrectly in the gui anago because I chose the unrom.af script (which was the only one); the folder for the command line version had the unrom.ad, so I copied that into the former's folder and checked if that would fix the issue. Instead, it gave the same error as for using nrom script. So it seems I'll have to settle with using the command line. Others have reported using the gui version without this problem, so perhaps I need to roll back my Kazzo firmware even further...?
Bump. Still hoping to get help on why the GUI anago is giving that error when dumping carts.
I'm curious, are there any scripts to dump TLSROM/TKSROM like Armadillo?
For a T*SROM game, try dumping it with the standard MMC3 script and then changing the mapper in the header after the fact. The relationship between these and standard MMC3 boards (T?ROM) is analogous to that between AMROM and BNROM: only mirroring differs.
Hi everyone. The Kazzo worked like a charm for dumping most carts; however, there were a few exceptions. I'll start with the most straightforward.
Two games are listed as using a mapper called AOROM. I can't tell from the list of included scripts if any are appropriate. I tried them all without success, though I am out of my element and may have missed something obvious to someone else.
The third game I am having trouble with is Tetris. It is listed as MMC1 and I tried both included scripts (skrom and surom.) Both resulted in a black screen. Then I tried MMC2 (just because) and it sort of worked. The title screen and menus appear as expected but then everything goes haywire when the game actually begins. Am I on the right path or barking up the wrong tree?
Any feedback would be appreciated. Thanks.
I read that for AOROM games, you can use this anrom script through the command line version of anago (instead of gui):
https://dl.dropboxusercontent.com/u/183 ... o/anrom.adIf it doesn't work, try this. Open the script in wordpad and put a 2 right after the d that's after cpu_dump (so it reads "(d2, pagesize..."), then try again.
On another note, would anybody know what's the purpose of the multiple mmc3 scripts? There is mmc3.ad, mmc3_v2.ad and mmc3.ag Is each specific to certain carts, or is one the most ideal to choose over the others?
SEROM is an MMC1 board whose maximum PRG ROM size is 256 kbit. MMC1 games on SEROM, such as
Tetris and
Dr. Mario, route A14 differently from most other MMC1 boards. Most MMC1 boards connect PRG ROM A14 to the MMC1's PRG ROM A14 output. But SEROM runs PRG ROM A14 directly to CPU A14. Try dumping the PRG ROM with the NROM plug-in and the CHR ROM with the MMC1 plug-in.
And now some conjecture about the very existence of SEROM:
- The different A14 routing is to allow use of cheaper slower PRG ROMs, as A14 out of the CPU settles sooner than A14 out of the MMC1.
- These games use MMC1 instead of CNROM solely to allow switching nametable mirroring or switching PPU $0000 and $1000 independently. Tengen's Tetяis, by contrast, used a board similar in capability to CNROM, GNROM, and MHROM, which behaves exactly like CNROM in the ROM size actually used.
Thanks tepples, that worked!
prototector wrote:
I read that for AOROM games, you can use this anrom script through the command line version of anago (instead of gui)
Well that was easy. Thanks.
tepples wrote:
Try dumping the PRG ROM with the NROM plug-in and the CHR ROM with the MMC1 plug-in.
Thanks for your suggestion. I wouldn't call the result a success but I'm not disappointed either. That's pretty wild.
I did manage to get Tetris working with a bit of, uhh, hackery. I examined the file with a hex editor and noticed it seems to start over at line 4010. I deleted lines 4010 through 1C010 and now it works as expected. I would like to figure out what exactly has been shoehorned in the middle of an otherwise good ROM but that will probably have to wait until the new year. Happy Holidays, y'all!
I just recently entered the kazzo world and I've been having fun dumping games.
I used the SEROM script found on page 14 of this thread to dump Tetris. It worked just fine:
viewtopic.php?f=9&t=7912&start=195#p118387The only game I am having trouble with is Bases Loaded. It is the only SFROM game I have. I've tried the SLROM script (mmc1_slrom.ad) because I thought it would be similar. The 64 KB CHR ROM dumps fine, but the PRG ROM is giving me problems. Bases Loaded's PRG ROM is 256 KB. I've been reading up about the MMC1 mapper on nesdev's wiki and I see that it has to be accessed serially with a shift register. I also see that the banks can be switched. If I'm reading it right, the SLROM script sets the PRG ROM configuration to switch banks at 0x8000 while keeping the last bank fixed at 0xc000. When I use 'd2' in the command (anago.exe d2 mmc1_slrom.ad "Bases Loaded.nes"), the cpu pagesize gets set to 16, so it reads 15 banks of PRG ROM (15 x 16 KB = 240 KB) from 0x8000 and then the last bank at 0xc000, for a total of 256 KB. However, the crc32 does not match any of the ones found in bootgod's database.
Has anybody been able to dump Bases Loaded successfully? Does it have a different switching configuration?
I am a total newbie to all of this, so I hope I am reading the scripts correctly.
You're right; SFROM should be identical to SLROM in terms of the script used.
I'm not really clear why you're having problems. If you take the dumped PRG, and split it into sixteen 16 KiB slices, are any of them identical? (Apparently the 9th, 11th, 13th, and 15th slices are. But only those.)
lidnariq wrote:
You're right; SFROM should be identical to SLROM in terms of the script used.
I'm not really clear why you're having problems. If you take the dumped PRG, and split it into sixteen 16 KiB slices, are any of them identical? (Apparently the 9th, 11th, 13th, and 15th slices are. But only those.)
Thanks for the response! None are identical except the ones you mentioned:
Bank crc32
1 B5241D95
2 C38065E3
3 35B01235
4 2AADA651
5 D6AF8977
6 BEB66FC2
7 E279FE5B
8 97F8314E
9 A7828A1D
10 43236FF7
11 A7828A1D
12 3F38BBDC
13 A7828A1D
14 733DB4BD
15 A7828A1D
16 6E653217
So, the script appears to be working correctly? I am baffled...
It's interesting to look at the different profiles for Bases Loaded on bootgod's site. Between the first release and revision A, the hardware changed from MMC1A to MMC1B2. My copy has the black Nintendo trademark circle, so it's one of the first versions. Does the fact that it's MMC1A hardware make a difference?
Nah, MMC1 revisions only how the PRG-RAM protect bit works. (
nesdevwiki:MMC1#Hardware )
Comparing your CRC32s to the values from the PRG0 image in GoodNES, I noticed something interesting:
a79ef47f 0 Bases Loaded (U) (PRG0) [!].nes.prg
c38065e3 1 Bases Loaded (U) (PRG0) [!].nes.prg270afbdf 2 Bases Loaded (U) (PRG0) [!].nes.prg
2aada651 3 Bases Loaded (U) (PRG0) [!].nes.prgc415609d 4 Bases Loaded (U) (PRG0) [!].nes.prg
beb66fc2 5 Bases Loaded (U) (PRG0) [!].nes.prgf0c317b1 6 Bases Loaded (U) (PRG0) [!].nes.prg
97f8314e 7 Bases Loaded (U) (PRG0) [!].nes.prgb53863f7 8 Bases Loaded (U) (PRG0) [!].nes.prg
43236ff7 9 Bases Loaded (U) (PRG0) [!].nes.prgb53863f7 10 Bases Loaded (U) (PRG0) [!].nes.prg
3f38bbdc 11 Bases Loaded (U) (PRG0) [!].nes.prgb53863f7 12 Bases Loaded (U) (PRG0) [!].nes.prg
733db4bd 13 Bases Loaded (U) (PRG0) [!].nes.prgb53863f7 14 Bases Loaded (U) (PRG0) [!].nes.prg
6e653217 15 Bases Loaded (U) (PRG0) [!].nes.prgSomething's trashing each lower 16 KiB. As to where exactly that's breaking ... who knows?
Very interesting, indeed! I guess having a half working ROM is better than having a completely wrong one...
Thanks for posting those crcs...now I have something to work toward.
Anything to do with
SFEXPROM, essentially an official counterpart to the Game Genie to fix a bug in the game after the mask ROMs had already been fabricated?
tepples wrote:
Anything to do with
SFEXPROM, essentially an official counterpart to the Game Genie to fix a bug in the game after the mask ROMs had already been fabricated?
Oh wow, I was wondering about that extra chip and what it did. That must be the version I have.
edit: That is the version I have! I went through and changed each value from 0x60 to to 0x05 at offset 0x180 and now the crc32s match up and the ROM works! Thank you so much for the help!
PatHawks wrote:
I am looking for an .ad/.ag script for
Gumshoe, iNES Mapper 66. I believe this is the same mapper used for the combo
Super Mario Bros / Duck Hunt.
On that note, it might be helpful to setup a GitHub/SourceForge repository or something for all of the mapper scripts. It seems many exist, but they are not all in one place.
18 months later...
I just got my kazzo in the mail today (thanks Paul!) and have been fussing with it all night. Had to switch to the old kazzo firmware and anago command line to get my games dumping (I'm used to the phrase "ripping", so excuse any transitional slang misuse) and have had most problems solved by trying variations on mmc1 through mmc3 for my anago scripts (.ad/.ag files) but my Mapper 66 game in particular, Super Mario Bros. / Duck Hunt, was not giving me any solutions.
I then found
arantius's anago-scripts repo which I think PatHawks is the same type of aggregate repo you are interested in. Not sure if arantius is you by another name, as I'm brand new to the NesDev community, with only light emulation/ripping work.
Anyways, there's a script for Mapper 66 games there! _gnrom.ad, but it doesn't seem to work with the version of anago in infiniteneslives' kazzo zip - so I tweaked it to address the error it was throwing ("the index 'cpu_romsize' does not exist") by copying bits of code from mmc3.ad, and
it seems to work!
So if anyone is trying to address 74161/32 (66) being the listed requirement for a Mapper in the nesmapper.txt file, my tweak on the _gnrom file seems to work with the latest anago from infiniteneslives. Let me know if there are any issues, or feel free to just modify it yourself!
EDIT: Y'know, I really should pay attention when there are only two contributors on a project to who the second guy is... looks like you are not arantius, but pathawks on github. Go figure!
Hello,
I just got into dumping NES games using the Kazzo and so far so good. I have been dumping a lot of my regular games but now I would like to dump some Gluk games. Specifically Gluk the Thunder Warrior. Since this is a hack if you will of the TXC original Thunder Warrior that used the Mapper 189 (
http://wiki.nesdev.com/w/index.php/INES_Mapper_189) I was wondering if anyone have done a dumper script supporting this? I anyone can help I would very much appreciate it and share the dumps with you.
... Could you pretty please take a picture of the back of the PCB? NesCartDB only has the front. -
http://bootgod.dyndns.org:7777/profile.php?id=4266Anyway, you should be able to dump the CHR of the game as though it were mapper 4/MMC3, and you should be able to adapt the dumper script for BNROM to dump the PRG.
Yes no problem! I took a picture on the front as well in case there are any confusions:
I do not have the knowledge on how to adapt the mapper scripts. I would like to learn (I tried to look at the script and compare it to the mapper 4 documentation) but I think and hope there are people out there that could help me with this resulting in this going faster.
Anyway, with no luck I will try get more information on how to make dump scripts on my own. I have several games I cannot find roms too which I would like to dump sharing with other collectors.
You should be able to start with the GNROM script here:
https://github.com/arantius/anago-scrip ... /_gnrom.adand change this line in cpu_dump:
Code:
cpu_write(d, 0x8000, i << 4);
to
Code:
cpu_write(d, 0x4120, i | (i<<4));
to get the PRG out of the cartridge.
Naruko's provided mmc3 script is complex enough that I'm a little afraid of it, but as I said, you should just be able to dump it twice once using each technique, split the resulting files and reassemble into something functional.
If it works (no promises!), this script should be the easiest way to dump that cartridge.
Code:
board <- {
mappernum = 189,
cpu_rom = {
size_base = 0x80000, size_max = 0x80000,
banksize = 0x8000
},
ppu_rom = {
size_base = 0x40000, size_max = 0x40000,
banksize = 0x400
},
ppu_ramfind = false, vram_mirrorfind = false
};
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i++){
cpu_write(d, 0x4120, i | (i << 4));
cpu_read(d, 0x8000, banksize);
}
}
function ppu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i+=4){
cpu_write(d, 0x8000, 2);
cpu_write(d, 0x8001, i);
cpu_write(d, 0x8000, 3);
cpu_write(d, 0x8001, i | 1);
cpu_write(d, 0x8000, 4);
cpu_write(d, 0x8001, i | 2);
cpu_write(d, 0x8000, 5);
cpu_write(d, 0x8001, i | 3);
ppu_read(d, 0x1000, banksize * 4);
}
}
I got this error:
ength range must be 0x000000 to 0x004000
AN ERROR HAS OCCURED [script logical error]
CALLSTACK
*FUNCTION [cpu_dump()] 189.ad line [19]
*FUNCTION [dump()] dumpcore.nut line [43]
LOCALS
[i] 0
[banksize] 32768
[pagesize] 16
[d] USERPOINTER
[this] TABLE
[ppu_dumpsize] 262144
[cpu_dumpsize] 524288
[ppuarea_memory] 0
[vram] 0
[increase_ppu] 1
[increase_cpu] 1
[mappernum] 189
[script] "189.ad"
[d] USERPOINTER
[this] TABLE
lidnariq wrote:
You should be able to start with the GNROM script here:
https://github.com/arantius/anago-scrip ... /_gnrom.adand change this line in cpu_dump:
Code:
cpu_write(d, 0x8000, i << 4);
to
Code:
cpu_write(d, 0x4120, i | (i<<4));
to get the PRG out of the cartridge.
Naruko's provided mmc3 script is complex enough that I'm a little afraid of it, but as I said, you should just be able to dump it twice once using each technique, split the resulting files and reassemble into something functional.
Sorry for being an idiot, how do I get the PRG/CHR only and how do I merge them later?
Werrock wrote:
I got this error:
ength range must be 0x000000 to 0x004000
AN ERROR HAS OCCURED [script logical error]
For whatever reason, anago can't read 32 KiB at a time, and must read 16 KiB at a time.
Replace
Code:
cpu_read(d, 0x8000, banksize);
with
Code:
cpu_read(d, 0x8000, 0x4000);
cpu_read(d, 0xc000, 0x4000);
Amazing!
mirroring Program ROM fixed
mirroring Charcter ROM fixed
gluk_189_try_2.nes, mapper 189
Program ROM: size 0x020000, crc32 0x3f60ac50
Charcter ROM: size 0x020000, crc32 0x9219bd34
And it works perfectly in the emulator. You Sir are a genius!
Where can upload a rom for public access and are there any legal issue with this?
Edit: We should also upload the mapper script, its really nice with more mappers to this great tool.
Edit 2: I got it uploaded to github, all credit to Joe.
https://github.com/arantius/anago-scrip ... txc_189.ad
Don't give
all the credit to me, most of it is copied from other scripts (especially the MMC3 script).
Is there some kind of script database? I'm sure I'm missing alot.
Either way: Mapper 246 (Fong Shen Bang) script:
Code:
board <- {
mappernum = 246,
cpu_rom = {
size_base = 4 * mega, size_max = 4 * mega, banksize = 0x2000
},
ppu_rom = {
size_base = 4 * mega, size_max = 4 * mega, banksize = 0x0800,
},
ppu_ramfind = true, vram_mirrorfind = false
};
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i += 1){
cpu_write(d, 0x6000, i);
cpu_read(d, 0x8000, banksize);
}
}
function ppu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i += 1){
cpu_write(d, 0x6004, i);
cpu_write(d, 0x8000, i);
ppu_read(d, 0, banksize );
}
}
If someone would like to make a nice neat .zip download of scripts that aren't currently distributed with my dropbox .zip along with the readme and drivers etc I can add them in.
Ice Man wrote:
Is there some kind of script database? I'm sure I'm missing alot.
Either way: Mapper 246 (Fong Shen Bang) script:
Code:
code
If I have you permission, I can upload this to the git repository.
infiniteneslives wrote:
If someone would like to make a nice neat .zip download of scripts that aren't currently distributed with my dropbox .zip along with the readme and drivers etc I can add them in.
Yeah, this would be great to have an updated list of scripts available.
Also, was a script made for mapper 11 Color Dreams games?
Ok, I have created a pull request, hopefully it will be accepted.
Next up I want to dump Policeman, it should use mapper 36:
http://wiki.nesdev.com/w/index.php/INES_Mapper_036Is the
https://github.com/arantius/anago-scrip ... /_gnrom.ad script supporting oversize? I doubt it looking at the max sizes. Is it enough to increase them or is the bank switching different on oversize?
"Theoretically the bank select register could be implemented with a 74HC377 octal D latch, allowing up to 512 KB of PRG ROM and 128 KB of CHR ROM. " I guess this is the oversizing? I will open the cart and have a look if this chip is in use.
Color dreams look very similar also to the gnrom. If anyone can create a mapper I can test it. I have all color dreams/bunch and wisdom tree games.
https://github.com/arantius/anago-scrip ... per_246.ad is published. Thank you Ice Man, one more down!
We don't know anything about mapper 36 beyond what the emulator source says, so pictures of the PCB would appreciated regardless.
To get a color dreams dumper from the gnrom one, swap these two lines:
Code:
cpu_write(d, 0x8000, i << 4);
and
Code:
cpu_write(d, 0x8000, i);
Werrock wrote:
Ice Man wrote:
Is there some kind of script database? I'm sure I'm missing alot.
Either way: Mapper 246 (Fong Shen Bang) script:
Code:
code
If I have you permission, I can upload this to the git repository.
Sure, go ahead and upload it.
I tried but it did not work. Black screen in emulator, Info from anago:
bible_adventures.nes, mapper 11
Program ROM: size 0x010000, crc32 0xb7941ad3
Charcter ROM: size 0x004000, crc32 0xd6a30cde
Cleaned it and works on NES, got new result (same inserting the cart three times now):
bible_adventures3.nes, mapper 11
Program ROM: size 0x010000, crc32 0x9b8e02c0
Charcter ROM: size 0x004000, crc32 0xd6a30cde
Starts in emulator but graphics is very messed up.
Hm. Somehow your CHR is much too small. But it's not 8 KiB, it's 16 KiB, so I'm kinda confused.
That said, this PRG checksum: 0x9b8e02c0 is consistent with revision 1.3 of the game.
We are close then!
Here is the picture of Policeman PCB:
http://sv.tinypic.com/r/sw6xpj/9The chip on the left is a 74LS175 and the right one 74LS138 so 74HC377 (mentioned as a chip used for over sizing) is not used.
I did the following test:
Code:
board <- {
mappernum = 11,
cpu_rom = {
size_base = 1 * mega, size_max = 1 * mega, banksize = 0x8000
},
ppu_rom = {
size_base = 1 * mega, size_max = 1 * mega, banksize = 0x2000
},
cpu_romsize = 1 * mega, cpu_banksize = 0x8000,
ppu_romsize = 1 * mega, ppu_banksize = 0x2000,
ppu_ramfind = false, vram_mirrorfind = false
};
Although I dont really understand the size_base, it seems to not work if lower than the max. The size_max I got from the wiki to be 128kB for both PRG and CHR so I fixed that.
New result is:
ba1.nes, mapper 11
Program ROM: size 0x010000, crc32 0x9b8e02c0
Charcter ROM: size 0x010000, crc32 0xb0a8c32a
Game now works perfectly in emulator!
Werrock wrote:
Here is the picture of Policeman PCB:
[...]
The chip on the left is a 74LS175 and the right one 74LS138 so 74HC377 (mentioned as a chip used for over sizing) is not used.
Oh dear. That's annoying full of things. The '175 assuredly latches to D0, D1, D4, D5 as CHR A13, A14, PRG A15, A16 respectively, but...
You could try using the GNROM script but replace both instances of
Code:
cpu_write(d, 0x8000,
with
Code:
cpu_write(d, 0x8400,
But it may or may not work.
Might you provide a picture of the back? And/or if you have a multimeter, measure what pins are connected to what? I'm not clear just how far we can get given that cryptically-named 05-00002-010 IC.
Code:
board <- {
mappernum = 36,
cpu_rom = {
size_base = 0x10000, size_max = 4 * mega, banksize = 0x8000
},
ppu_rom = {
size_base = 0x10000, size_max = 1 * mega, banksize = 0x2000
},
cpu_romsize = 4 * mega, cpu_banksize = 0x8000,
ppu_romsize = 1 * mega, ppu_banksize = 0x2000,
ppu_ramfind = false, vram_mirrorfind = false
};
function cpu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize; i += 1) {
cpu_write(d, 0x8400, 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, 0x8400, i);
ppu_read(d, 0, 0x2000);
}
}
The current code. No real luck, not workign atleast. Tried to play with size_base and maX_size but always get same result:
\anago\policeman.nes, mapper 36
Program ROM: size 0x008000, crc32 0x012ce0e2
Charcter ROM: size 0x002000, crc32 0xc2b55df5
I was expecting two 64kB blocks (
http://glukvideo.info/listado-juegos-gluk#policeman)
I will get picture of the back. Tomorrow I could try to map the pins.
Edit: Even without the update you gave me it still give me the same result indicating that the page switching does not work at all.
Edit 2: Picture of PCB backside:
http://sv.tinypic.com/r/155jtjo/9
Yeah. Sadly that's a common problem with under-documented hardware.
You could try random other addresses, but it'll be easiest just to figure out how the 74'138 is connected and choose a value accordingly.
Edit: funny thing ... the 74'175 seems to be only there for CHR banking, and the 05-00002-010 IC has to be handling PRG banking.
Werrock wrote:
I did the following test:
Code:
board <- {
mappernum = 11,
cpu_rom = {
size_base = 1 * mega, size_max = 1 * mega, banksize = 0x8000
},
ppu_rom = {
size_base = 1 * mega, size_max = 1 * mega, banksize = 0x2000
},
cpu_romsize = 1 * mega, cpu_banksize = 0x8000,
ppu_romsize = 1 * mega, ppu_banksize = 0x2000,
ppu_ramfind = false, vram_mirrorfind = false
};
Although I dont really understand the size_base, it seems to not work if lower than the max. The size_max I got from the wiki to be 128kB for both PRG and CHR so I fixed that.
New result is:
ba1.nes, mapper 11
Program ROM: size 0x010000, crc32 0x9b8e02c0
Charcter ROM: size 0x010000, crc32 0xb0a8c32a
Game now works perfectly in emulator!
I tried that script for dumping one of Color Dreams game, I got this error message:
Code:
AN ERROR HAS OCCURED [the index 'cpu_dump' does not exist]
CALLSTACK
*FUNCTION [dump()] dumpcore.nut line [43]
LOCALS
[ppu_dumpsize] 131072
[cpu_dumpsize] 131072
[ppuarea_memory] 0
[vram] 0
[increase_ppu] 1
[increase_cpu] 1
[mappernum] 11
[script] "colordreams.ad"
[d] USERPOINTER
[this] TABLE
lidnariq wrote:
...
Might you provide a picture of the back? And/or if you have a multimeter, measure what pins are connected to what? I'm not clear just how far we can get given that cryptically-named 05-00002-010 IC.
I used a mulimeter and tried to count and map to the pinout from:
http://wiki.nesdev.com/w/index.php/Cartridge_connectorHere is the result for the 138, let me know if of any use.
Code:
CPU A14 -[01 U 16]- 5V
/ROMSEL -[02 15]- NC
CPU A9 -[03 7 14]- NC
CPU A13 -[04 4 13]- NC
CPU R/W -[05 ' 12]- NC
M2 -[06 1 11]- NC
175P8 -[07 3 10]- NC
GND -[08 8 09]- NC
prototector wrote:
...
I tried that script for dumping one of Color Dreams game, I got this error message:
Code:
AN ERROR HAS OCCURED [the index 'cpu_dump' does not exist]
That was only the beginning of a script. I have submitted the whole script to the git repo, you can fetch the pending copy at:
https://github.com/Werrock83/anago-scri ... pper_11.adI have tested with a few color dreams games and it seems fine.
Werrock wrote:
Code:
CPU A14 -[01 U 16]- 5V
/ROMSEL -[02 15]- NC
CPU A9 -[03 7 14]- NC
CPU A13 -[04 4 13]- NC
CPU R/W -[05 ' 12]- NC
M2 -[06 1 11]- NC
175P8 -[07 3 10]- NC
GND -[08 8 09]- NC
Ok, that tells me that it's selecting for A14, /ROMSEL, A9 and M2 high; and A13 and R/W low. That means it's looking for writes to $4200 ? Weird. Well, ok, you should be able to dump the CHR—8 KiB at a time, like GNROM—with
cpu_write(d, 0x4200, i);As for the PRG, I have no idea; maybe the connectivity of the 05-00002-010 would help. This is clearly not the same board as what's described for Mapper 36.
https://github.com/libretro/libretro-fc ... s/01-222.cCode:
* 01-22110-200 (05-00002-010) (036 ) - MGC-014 Strike Wolf
* 01-22000-400 (05-00002-010) (036 ) - MGC-015 Policeman
Mapper and chip mentioned here for the game but I could not find any helpful information how it works.
foo.nes, mapper 36
Program ROM: size 0x008000, crc32 0x0d47f2b6
Charcter ROM: size 0x010000, crc32 0xf73ee39e
Using 4200 for CHR mapping. So it looks good better since it only read one page before and now 64kB which is the expected size! Too bad we cannot read the PRG.
Well, you could see if PRG just happens to also be at 0x4200 — cpu_write(d, 0x4200, (i<<4));
Or you could PM the 32 KiB of PRG you have for now.
Or you could sit down with the multimeter and additionally measure how the 05-00002-010 is connected.
Did that
didnt work. I will try map the chip tomorrow!
Werrock wrote:
prototector wrote:
...
I tried that script for dumping one of Color Dreams game, I got this error message:
Code:
AN ERROR HAS OCCURED [the index 'cpu_dump' does not exist]
That was only the beginning of a script. I have submitted the whole script to the git repo, you can fetch the pending copy at:
https://github.com/Werrock83/anago-scri ... pper_11.adI have tested with a few color dreams games and it seems fine.
Ah, ok! Sorry about that; I'll give the whole script a try. Thanks a lot for this! Did you use the GUI or command line version of Anago with it?
Updated PIN mapping:
Code:
CPU A14 -[01 U 16]- 5V
/ROMSEL -[02 15]- NC
CPU A9 -[03 7 14]- NC
CPU A13 -[04 4 13]- NC
CPU R/W -[05 ' 12]- NC
M2 -[06 1 11]- NC
175P9 -[07 3 10]- NC
GND -[08 8 09]- NC
5V -[01 U 16]- 5V
010P26 -[02 15]- NC
NC -[03 7 14]- NC
CPU D0 -[04 4 13]- CPU D3
CPU D1 -[05 ' 12]- U1P13
NC -[06 1 11]- NC
U2P27 -[07 7 10]- U2P1
GND -[08 5 09]- 138P7
NC -[01 U 24]- NC
NC -[02 23]- NC
U1P1 -[03 0 22]- NC
GND -[04 5 21]- CPU A13
5V -[05 ' 20]- CPU A14
NC -[06 0 19]- GND
5V -[07 X 18]- CPU R/W
NC -[08 2 17]- /ROMSEL
NC -[09 ' 16]- M2
NC -[10 0 15]- CPU A8
CPU D5 -[11 1 14]- CPU A1
CPU D4 -[12 0 13]- CPU A0
U1 is the PRG and U2 is the CHR EEPROM.
Alright, I tried it this time and it did create a ROM file for the games, however they're both 98 kb and don't work in emulators.
The games are prototypes, one is of the game Moon Ranger and the other is an unreleased title. Any additional information I could supply to look further into this?
I will test to dump Moon Ranger and get back to you later.
Werrock wrote:
Code:
NC -[01 U 24]- NC
NC -[02 23]- NC
PRG A15 -[03 0 22]- NC
GND -[04 5 21]- CPU A13
5V -[05 ' 20]- CPU A14
NC -[06 0 19]- GND
5V -[07 X 18]- CPU R/W
NC -[08 2 17]- /ROMSEL
NC -[09 ' 16]- M2
NC -[10 0 15]- CPU A8
CPU D5 -[11 1 14]- CPU A1
CPU D4 -[12 0 13]- CPU A0
Hm. Well, that's ... a thing.
I mean, it's nice to know it's only paying attention to A15,14,13,8,1,0 and R/W; so I looked more closely at the PRG dump you sent me. Try using
cpu_write(d, 0xFFA0+i, (i<<4));If that works, to get a more-nearly-complete description of what's going on, would you be willing to test a few other things?
Do you still get a full-sized PRG dump if you use
0xFFA0 without the
+i?
If so, repeat with 0xE000, 0xC100, 0xC000, 0xA100, 0xA000, and 0x8100 ? We already know that 0x8400 didn't work, so there's no need to test 0x8000.
We know there's a of four registers at 0x4100-0x4103, but what they're doing is unclear. I'm not certain what to check for there, though.
No luck with any of them, maybe I made a mistake with the pin mapping...
Looks like F-15 city war has a very similar PCB but without that special circuit:
Maybe I could try dump this game also.
Oh, that's very convenient. The bare PCB means I can verify the full connectivity visually.
Anyway, that shows that F-15 City War doesn't have any PRG banking.
Anyway, looking at the PRG one last time, try cpu_write(d, 0x4102, (i<<4));.
prototector wrote:
Alright, I tried it this time and it did create a ROM file for the games, however they're both 98 kb and don't work in emulators.
The games are prototypes, one is of the game Moon Ranger and the other is an unreleased title. Any additional information I could supply to look further into this?
mirroring Charcter ROM fixed
mr.nes, mapper 11
Program ROM: size 0x010000, crc32 0x124af039
Charcter ROM: size 0x010000, crc32 0x5f3a624f
I just dumped my moon ranger and it works perfectly in the emulator.
For idle curiosity, would you also be willing to see if the various NC pins on the 05-00002-010 are floating or driven high/low when the game is powered? Doesn't need to be in a NES/FC, just +5V and ground applied.
I have this idle hunch that pins 10 and 9 "should" be CPU D6 and CPU D7, and that pins 1 and 24 "should" be PRG A17 and A18. Completely unimportant, though.
lidnariq wrote:
Oh, that's very convenient. The bare PCB means I can verify the full connectivity visually.
Anyway, that shows that F-15 City War doesn't have any PRG banking.
Anyway, looking at the PRG one last time, try cpu_write(d, 0x4102, (i<<4));.
Still no luck. Will test some more...
lidnariq wrote:
For idle curiosity, would you also be willing to see if the various NC pins on the 05-00002-010 are floating or driven high/low when the game is powered? Doesn't need to be in a NES/FC, just +5V and ground applied.
I have this idle hunch that pins 10 and 9 "should" be CPU D6 and CPU D7, and that pins 1 and 24 "should" be PRG A17 and A18. Completely unimportant, though.
8, 9, and 10 are floating, 1 and 24 are at 5V.
... I'm confused. The game itself is doing this:
Code:
$FF50 A6 7B: ldx $7B ; PRG bank
$FF52 BD A0 FF: lda _data_7FA0_indexed,x
$FF55 05 60: ora $60 ; CHR bank
$FF57 9D A0 FF: sta _data_7FA0_indexed,x
$FF5A A9 00: lda #$00
$FF5C 8D 01 41: sta $4101 ; always writes 0 here
$FF5F BD A0 FF: lda _data_7FA0_indexed,x
$FF62 8D 02 41: sta $4102 ; writes PRG bank here
$FF65 A9 00: lda #$00
$FF67 8D 03 41: sta $4103 ; always writes 0 here
$FF6A 8D 00 41: sta $4100 ; and here
$FF6D A9 FF: lda #$FF
$FF6F 8D 03 41: sta $4103 ; and #$30 here
$FF72 8D FF FF: sta $FFFF
and although the CHR bankswitching is elsewhere, this is the only place where PRG goes.
I guess we could try parroting it completely?
cpu_write(d, 0xFFA0+i, (i<<4));
cpu_write(d, 0x4101, 0);
cpu_write(d, 0x4102, (i<<4));
cpu_write(d, 0x4103, 0);
cpu_write(d, 0x4100, 0);
cpu_write(d, 0x4103, 0xFF);
cpu_write(d, 0xFFFF, 0xFF);If
that works, then you could try removing random lines until it stops working?
OMG! Your code worked!
mirroring Charcter ROM fixed
pm.nes, mapper 36
Program ROM: size 0x010000, crc32 0x65fe1590
Charcter ROM: size 0x010000, crc32 0xf73ee39e
Game plays also
Edit: It plays but not perfectly, the game seems of. The player and enemy placement is not matching the background tiles.
Werrock wrote:
prototector wrote:
Alright, I tried it this time and it did create a ROM file for the games, however they're both 98 kb and don't work in emulators.
The games are prototypes, one is of the game Moon Ranger and the other is an unreleased title. Any additional information I could supply to look further into this?
mirroring Charcter ROM fixed
mr.nes, mapper 11
Program ROM: size 0x010000, crc32 0x124af039
Charcter ROM: size 0x010000, crc32 0x5f3a624f
I just dumped my moon ranger and it works perfectly in the emulator.
You used the script unedited or made a change? Sorry, I'm a real novice with all the code/terms.
Werrock wrote:
Edit: It plays but not perfectly, the game seems of. The player and enemy placement is not matching the background tiles.
Huh. Could be a misunderstanding of how the registers at $4100-$4103 are supposed to work. Which emulator are you testing with? IIRC things that are not FCEUX are more incorrect for this specific mapper.
Also, maybe check what lines you can remove from the sequence I gave you to see what's necessary?
Werrock wrote:
OMG! Your code worked!
mirroring Charcter ROM fixed
pm.nes, mapper 36
Program ROM: size 0x010000, crc32 0x65fe1590
Charcter ROM: size 0x010000, crc32 0xf73ee39e
Game plays also
Edit: It plays but not perfectly, the game seems of. The player and enemy placement is not matching the background tiles.
I compared the first level first screen between the game on NES an emulator and they use different tile placement, its not of just another page of memory or something. So not perfect yet, the enemy placement, sprite and movement is correct. But background graphics and obstacles are placed differently.
Hmm. I wonder what could be the problem then. It plays from the cartridge, just doesn't dump properly. It is a proto, however.
lidnariq wrote:
Werrock wrote:
Edit: It plays but not perfectly, the game seems of. The player and enemy placement is not matching the background tiles.
Huh. Could be a misunderstanding of how the registers at $4100-$4103 are supposed to work. Which emulator are you testing with? IIRC things that are not FCEUX are more incorrect for this specific mapper.
Also, maybe check what lines you can remove from the sequence I gave you to see what's necessary?
I can remove
Code:
cpu_write(d, 0x4101, 0);
cpu_write(d, 0x4103, 0);
cpu_write(d, 0x4103, 0xFF);
With same result.
I need either of
Code:
cpu_write(d, 0xFFA0+i, (i<<4));
or
Code:
cpu_write(d, 0x4102, (i<<4));
Code:
cpu_write(d, 0x4100, 0);
is needed and if i remove
Code:
cpu_write(d, 0xFFFF, 0xFF);
I can still readout a full image butthe CRC is different:
pm2.nes, mapper 36
Program ROM: size 0x010000, crc32 0x575d3d5a
Charcter ROM: size 0x010000, crc32 0xf73ee39e
It will also not load at all in the emulator (FCEUX 2.2.2).
prototector wrote:
Hmm. I wonder what could be the problem then. It plays from the cartridge, just doesn't dump properly. It is a proto, however.
Post a screenshot of you anago gui and let me see how you set all.
Werrock wrote:
I compared the first level first screen between the game on NES an emulator and they use different tile placement, its not of just another page of memory or something. So not perfect yet, the enemy placement, sprite and movement is correct. But background graphics and obstacles are placed differently.
Seems to work correctly if I fix the nametable mirroring. (It should be Vertical, not Horizontal).
I thought that the Kazoo detected that, but who knows.
Quote:
I can still readout a full image butthe CRC is different:
... PM me the broken image?
Werrock wrote:
if i remove
Code:
cpu_write(d, 0xFFFF, 0xFF);
I can still readout a full image butthe CRC is different:
pm2.nes, mapper 36
Program ROM: size 0x010000, crc32 0x575d3d5a
Charcter ROM: size 0x010000, crc32 0xf73ee39e
In summary, omitting the write to 0xFFFF flips the two PRG banks around. No idea what it'd do if there were more PRG banks, as on Strike Wolf.
Ok, now for more silly questions:
Does it matter what value is in
cpu_write(d, 0x4100, 0);? Currently the game writes 0; what happens if it's 0x10, 0x20, or 0x30?
Does it matter what value is written to 0xFFFF? Do the address lines matter at all, other than ≥ 0x8000?
Does it matter what the address lines are in
cpu_write(d, 0xFFA0+i, (i<<4));? e.g. what if it were 0x8000 instead of 0xFFA0+i ?
Its not a game I am collecting so unfortunately I cannot test it. But great work man getting the policeman working. I have not been able to find this rom anywhere online so its really nice to have it dumped.
I'll get back to you tomorrow. I got to pack it in for tonight. Thanks again.
Same here, will continue with this tomorrow, not in reach of stuff.
lidnariq wrote:
Does it matter what value is in cpu_write(d, 0x4100, 0);? Currently the game writes 0; what happens if it's 0x10, 0x20, or 0x30?
Seems not to matter, 0x10, 0x20, 0x30, 0xFF all works.
lidnariq wrote:
Does it matter what value is written to 0xFFFF? Do the address lines matter at all, other than ≥ 0x8000?
Value seems not to matter, 0x0 is ok and so is 0x5a. All addresses >= 0x8000 seems to work. 0x7FFF or lower gives the same result as removing the line.
lidnariq wrote:
Does it matter what the address lines are in cpu_write(d, 0xFFA0+i, (i<<4));? e.g. what if it were 0x8000 instead of 0xFFA0+i ?
Also works, 0x8000 and 0x8000+i works just as good.
And just a few more silly questions:
Does anything happen if you have multiple
cpu_write(d, 0x4100, whatever); in a row?
Does anything happen if you have multiple
cpu_write(d, 0xFFFF, 0xFF); in a row?
Could you measure the voltage on 05-00002-010 pin 3 = PRG pin 1 while you're dumping the game? It should either be high then low, or low then high.
It'd be nice if there were a way to get the Kazoo to read from the ports at 0x4100-0x4103 ... oh, maybe there's a way to repurpose Kazoo's save RAM reading:
Code:
board <- {
[...]
cpu_ram = {
size_base = 2500, size_max = 2500, banksize = 2500
},
[...]
function cpu_raw_access(d, pagesize, banksize) {
for (local w4100 = 0; w4100 < 5; w4100++) {
for (local w4101 = 0; w4101 < 5; w4101++) {
for (local w4102 = 0; w4102 < 5; w4102++) {
for (local w4103 = 0; w4103 < 5; w4103++) {
if (w4100 > 0) {
cpu_write(d, 0x4100, (w4100-1)<<4);
}
if (w4101 > 0) {
cpu_write(d, 0x4101, (w4101-1)<<4);
}
if (w4102 > 0) {
cpu_write(d, 0x4102, (w4102-1)<<4);
}
if (w4103 > 0) {
cpu_write(d, 0x4103, (w4103-1)<<4);
}
cpu_read(d, 0x4100, 4);
}
}
}
}
}
But I don't know if unagi will throw a fit for having 2500 bytes here, rather than a nice power of 2?
Thanks for having the patience and/or curiosity to actually figure out what's going on, even though you already have a functioning dump!
lidnariq wrote:
Does anything happen if you have multiple cpu_write(d, 0x4100, whatever); in a row?
Nope, works just as good, tried up to five writes.
lidnariq wrote:
Does anything happen if you have multiple cpu_write(d, 0xFFFF, 0xFF); in a row?
Also make no difference.
lidnariq wrote:
Could you measure the voltage on 05-00002-010 pin 3 = PRG pin 1 while you're dumping the game? It should either be high then low, or low then high.
Start at 5V after reset of Kazzo, starts dumping and it switches to 0V, half way through the PRG it goes back to 5V. If I remove the
cpu_write(d, 0xFFFF, 0xFF); line it will have the reverse behavior starting at 5V when you start duping and go to 0V after half the PRG.
lidnariq wrote:
Thanks for having the patience and/or curiosity to actually figure out what's going on, even though you already have a functioning dump!
No problem!
Sorry for the delay, had some real serious things to handle.
http://i.imgur.com/FQhctg9.pngNot too clear, but most settings are default exactly the way they are when the program is first downloaded. The only thing gets adjusted is of course the script. the colordreams script is available in the drop-down list.
Very unclear, I do not know how you made such an unreadable screen shot. Anyway, looks like you set the CHR ROm to x1, the memory is larger than that on moon ranger so try to set it to x4.
Thanks a lot, it worked!
Really glad there's progress on supporting mappers with this device.
No problem, yes it is fantastic, I just need to dig deeper to find a new challenge for lidnariq.
Heh. Did you ever try using the dumping script for reading from the 05-00002-010's ASIC registers? Did it even run?
I did encounter another funny/annoying thing when I was writing up the findings: There are five games that used the 01-22000-400 PCB (according to the glukvideo web site). Two with the ASIC, namely Policeman and Strike Wolf, and three without (Puzzle, Volley ball, F-15 City War).
But the latter three are supposedly emulated as mapper 79.
F-15 City War does have at least three different builds, courtesy No-Intro:
*
http://datomatic.no-intro.org/index.php ... =45&n=0683 (v1.0, GoodNES says "AVE v1.x")
*
http://datomatic.no-intro.org/index.php ... =45&n=0684 (v1.1, GoodNES says "AVE v1.1")
*
http://datomatic.no-intro.org/index.php ... =45&n=2699 (Gluk, not present in GoodNES)
The two builds present in GoodNES don't write to $4200 at all ...
edit: Ah, but I found a dump of Gluk's release somewhere else and it does write to $4200 ... as well as to $4120. Mystery solved, I guess.
Yesterday I recived my unit! Today I will try it out. Excited!!!
First question, will there be any drivers for Windows 10? Now I had to bring out an old laptop, and will try it with that.
Edit: Worked fine. Tried a N-rom 256 cart!
I dumped F-15 using the same script as for policeman:
f15.nes, mapper 36
Program ROM: size 0x008000, crc32 0x8406ed8b
Charcter ROM: size 0x008000, crc32 0xc470fadc
It starts in the emulator but the graphics is messed up. If I only modify the mapper to 79 (from 36) the game loads fine and the graphics is ok again.
Sorry but I have not had the possibility to try get more data from the Policeman PRG mapper.
Werrock wrote:
I dumped F-15 using the same script as for policeman
[...]It starts in the emulator but the graphics is messed up. If I only modify the mapper to 79 (from 36) the game loads fine and the graphics is ok again.
Yeah, that makes sense; currently there are no emulators that actually emulate what the PCB 01-22000-400 actually does.
Relatedly...
Quote:
Sorry but I have not had the possibility to try get more data from the Policeman PRG mapper.
No rush. Having an incomplete but correct description is already better than the astoundingly incorrect prior documentation.
I got a request to dump Pipemania fron NA forum as someone states it has not been dumped:
http://nintendoage.com/index.cfm?FuseAc ... 0&sID=1220Anybody know what mapper this game uses? Should be the same game as Pipe V from Sachen but I cannot cofirm it since I do not own that game.
Added PCB pictures, I added the tape since I always get nervous when I see EPROM windows:
http://postimg.org/image/ulv2koxpp/http://postimg.org/image/495ydt2yb/Very elegant design, only a few patches and some blobs of solder here and there.
Is
Pipe Mania another port of the game that BPS ported to NES as
Pipe Dream? If so, it joins
Othello and
Rainbow Islands as games that got NES ports by different companies in different regions.
Yes the two games are very similar in gameplay.
Werrock wrote:
Should be the same game as Pipe V from Sachen but I cannot cofirm it since I do not own that game.
Sachen's Pipe 5 is extremely different, with (according to GoodNES) more PRG and less CHR, and (according to FCEUX) a completely incoherent banking mechanism.
In any case, given that the PCB holds two 32 KiB UVEPROMs, this board is probably similar to CNROM. You should be able to dump the PRG as though it were NROM. I'll look at the photos some more and try to figure out the CHR banking.
edit:
Ok, I can't see all the signals, but I know it's latching CPU D0 and D1 when
* M2 high, R/W low, A13 low
* three other signals high ... probably A14, /ROMSEL, and ... A8?
If you could track down what 74'138 pins 1-3 are, that'd be sufficient to be able to dump the CHR. The board
might be compatible with NINA-03, and the silkscreening mentions the NINA CIC stunner (even if it's been replaced here by a messy pile of discretes)
Here is the pinout:
Code:
CPU A14 -[01 U 16]- 5V
/ROMSEL -[02 15]- NC
CPU A8 -[03 7 14]- NC
CPU A13 -[04 4 13]- NC
CPU R/W -[05 ' 12]- NC
M2 -[06 1 11]- NC
175P9 -[07 3 10]- NC
GND -[08 8 09]- NC
Nrom readout:
nrom_readout.nes, mapper 0
Program ROM: size 0x008000, crc32 0xb21f8131
Charcter ROM: size 0x002000, crc32 0xebd5b46a
Sending the rom in PM.
Yeah, that's definitely just mapper 79.
Start with the GNROM script again, but replace cpu_write(d, 0x8000, i); with cpu_write(d, 0x4100, i);
and replace cpu_write(d, 0x8000, i<<4); with cpu_write(d, 0x4100, i<<3);
The funny thing about this PCB is that it supports three different mappers:
- Populating both the '138 and '175 makes NINA-03/06 (m79)
- Populating only the '161 makes CNROM (m3)
- Populating only the '378 makes Color Dreams (m11)
Not fully working, I tried this and got:
test.nes, mapper 79
Program ROM: size 0x008000, crc32 0x713d51cc
Charcter ROM: size 0x004000, crc32 0xeac077bd
Game starts but graphics is messed up at intro but recovers later.
If this was 79 it should work as the F-15 game or? That game had this code:
Code:
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 += 1) {
cpu_write(d, 0x4200, i);
ppu_read(d, 0, 0x2000);
}
}
I tried this but I got less CHR memory:
test.nes, mapper 79
Program ROM: size 0x008000, crc32 0x713d51cc
Charcter ROM: size 0x002000, crc32 0xa12ffb3e
Still plays the same.
If I only change the mapper to 113 the games seems to work perfectly using your technique. You can test with the ROM I sent you.
test.nes, mapper 113
Program ROM: size 0x008000, crc32 0x713d51cc
Charcter ROM: size 0x004000, crc32 0xeac077bd
Sounds like mirroring issues again? The one you PM'd me works correctly, though, even though it's running as mapper 79 instead of 113.
Strange, I try them in the same emulator (fceux-2.2.2-win32):
With mapper 79:
http://postimg.org/image/ufp7bag57/With mapper 113:
http://postimg.org/image/j4mjmx9a3/
... Weird, it works for me in Nestopia and Nintedulator. And not in FCEU-0.98 nor FCEUX-2.2.1. ... and when I did deeper, FCEU/FCEUX is pretty clearly explicitly presenting the wrong bank (1) when the bankswitch is requested (to 0).
Oh. The answer is that FCEUX's implementation of NINA-03/06 is explicitly wrong (i.e. it pretends that mapper 79 is both NINA-03/06 AS WELL AS mapper 148), and this game is explicitly designed to work on both NINA-06 or a Color Dreams board (it writes $0E to $4120, but it writes $6D to $8014) and so it confuses that over-enthusiastic compatibility code.
Also, it's weird that the 32 KiB of CHR ROM there evidently contains only 16 KiB of tile data.
Has anyone ever dumped Nanjing or Waixing games?
I have an undumped game called Ye Ming Zhu [Night Pearl].
It seems to have PRG ROM (MBM29DL163BE70PFTN) and CHR RAM (BS62LV2000STC) only.
I assume it's another mapper 163 but not too sure.
Here's pictures of the PCB:
First step is usually trying to dump the game as though it were NROM and see what the game is doing. Our current best documentation of what mapper 163 is is basically just what's in FCEUX's source.
Waixing released many different hardwares, so it's hard to extrapolate what's going on just by knowing the distributor.
Ice Man wrote:
Has anyone ever dumped Nanjing or Waixing games?
I have an undumped game called Ye Ming Zhu [Night Pearl].
It seems to have PRG ROM (MBM29DL163BE70PFTN) and CHR RAM (BS62LV2000STC) only.
I assume it's another mapper 163 but not too sure.
Here's pictures of the PCB:
I have a CoolBoy cartridge with same "UNION131" PCB.
OldNESJunkie wrote:
Well, I've been busy dumping my collection with the Kazzo, but looks like I'm gonna have to learn about the NES memory map to write my own scripts for dumping some, any pointers on where to start ? I have found a couple of games I couldn't get to dump, only 2 so far, some I had to remove the PC board from the cart to get a good dump due to the weird way the board was. The only 2 I have had no luck with so far are A Boy & His Blob and Bases Loaded 2 with the included dumping scripts, I've dumped about 142 games so far out of the 702 I have.....
Has anybody been able to dump A Boy And His Blob with the kazzo? I've tried the mmc1_skrom.ag script with the GUI and the mmc1_slrom.ad script with the command line and I keep getting different (and wrong) crc32s every time. The contacts are clean, as the cart starts up fine when I put it in my NES.
TotoTek has a SNES dumper which uses a modified SMS cart slot:
http://www.tototek.com/store/images/SNE ... ash_01.jpgSMS slot used in the mod:
http://www.tototek.com/store/index.php? ... ucts_id=78Is the pitch of the SNES connector used on Kazzo USB dumper different from the slot above from TotoTek?
I'm willing to purchase a complete set (having only the SNES slot unsoldered). Does shipping to Brazil include a tracking code?
Thanks!
Did anyone have any luck building a functional UNROM cart for Kazzo?? I've followed this tutorial:
https://osdn.net/projects/unagi/wiki/flash_74161_enAnd here's the thing- I think this is kind of wrong since the console doesn't read the cartridge at all but it reads correctly if I connect /WE #31 pin of the flash chip to +5V, so I temporarily made a switch for that. While my Kazzo can program my MMC1 cart just fine (well, after many attemps actually since it stopped at some random address all the time), the Kazzo doesn't even try to program my UNROM cart. It ALWAYS hangs on one specific address and interrupts the programming sequence... Any ideas what I should do?? Please for reply and advices. Many thanks in advance!!
If you run my
current build of the firmware and using a SST 39SF0x0 flash chip, you'll be able to flash a UNROM board if you wire it up to the
UNROM-512 spec with a '139.
Another option would be to make use of EXP0 like I do for majority of my UNROM boards. PRG-ROM /WE pin is tied to EXP0 with a pull-up to Vcc. /OE is connected to /ROMSEL, and /CE is grounded. Should also work with my current firmware build when using 39SF0x0.
So, can you provide me any instructions kinda for dummies explaining how to build that cart?? Also, I didn't mention my cart is a Famicom one so I'm afraid I can't use any expansion pins on that
If you're using famicom you'll prob want to go with the UNROM-512 interface that'll work with just 60pins. The wiki shows the schematic, can't explain it much better than that.
Damn it, the cart would need a total reconstruction as it almost isn't an UNROM board anymore, I think it needs a new redesigned board for this purpose... Is there any easier solution for that while it only handles up to 256KB PRG??
You could use my EXP0 suggestion, but you'd have to use an "external" wire jumper to go from the atmega to the prg-rom /WE pin due to having 60pin restriction.
I just picked up a PowerJoy PJ-008 for cheap at a local Goodwill, and decided to try dumping it using Kazzo. Unfortunately, I'm no good at writing scripts for Kazzo in order to dump something like this.
I thought I could just find a ROM of PJ-008 on the Internet and download it and call it a day. After searching for a long while (seems like it's very rarely dumped/shared?) I finally found the ROM in GoodNES set and tried it out in the emulator, only to discover that the game list in that ROM is quite different from the game list on this cartridge, so I'm back to square one.
I'm going to resume trying to dump the cartridge - but in order to do that, I'll need to learn how to write a script for this particular cartridge. Is it possible for me to get a tutorial on how to write a script? I would like to learn so I won't have to ask for help every time I come across another "strange" cartridges. "Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime."
Here's what I know about this cartridge - it's a mapper 126 cartridge, PRG is 2048kb, CHR is 1024kb.
Thank you, everybody!
So my suspicion arose with the Kazzo with a recent attempt at a ROM dump.
I have a prototype game (MMC3) that I dumped, which only appeared to differ from the retail by one byte at a specific position in the header (booooo!). I found it peculiar because someone else dumped a different prototype copy of the same game last year and theirs showed the EXACT SAME single difference (location and value). One might assume both prototype copies have the same build, hence the same difference, and leave it at that. Except I decided to test this further.
I dumped one of my retail carts, Blades of Steel (unrom), and compared it to the publicly available download of it, which is supposed to be verified. Lo and behold, my Kazzo ROM dump differs by 1 byte from the download, at the exact same header location the prototype of the other game differs from its retail version.
More than that, the difference in hex value of the 2 games dumped by the Kazzo compared to the downloadable ones are the exact same. ie:
Hex value at position 06 of prototype of MMC3 game: 42
Hex value at position 06 of downloaded retail version of MMC3 game: 40
Hex value at position 06 of my Kazzo dump of Blades of Steel UNROM game: 23
Hex value at position 06 of downloaded retail version of the same: 21
So you see, it looks like the Kazzo is doing something weird where it dumps them with a hex value at 06 that is 2 higher than what it should be. Because of that, I think that my prototype (and the copy from the other guy) is actually 100% byte-wise identical to retail and it's just the Kazzo that dumped it this way.
What's the reason for this?
prototector wrote:
So my suspicion arose with the Kazzo with a recent attempt at a ROM dump.
I have a prototype game (MMC3) that I dumped, which only appeared to differ from the retail by one byte at a specific position in the header (booooo!). I found it peculiar because someone else dumped a different prototype copy of the same game last year and theirs showed the EXACT SAME single difference (location and value). One might assume both prototype copies have the same build, hence the same difference, and leave it at that. Except I decided to test this further.
I dumped one of my retail carts, Blades of Steel (unrom), and compared it to the publicly available download of it, which is supposed to be verified. Lo and behold, my Kazzo ROM dump differs by 1 byte from the download, at the exact same header location the prototype of the other game differs from its retail version.
More than that, the difference in hex value of the 2 games dumped by the Kazzo compared to the downloadable ones are the exact same. ie:
Hex value at position 06 of prototype of MMC3 game: 42
Hex value at position 06 of downloaded retail version of MMC3 game: 40
Hex value at position 06 of my Kazzo dump of Blades of Steel UNROM game: 23
Hex value at position 06 of downloaded retail version of the same: 21
So you see, it looks like the Kazzo is doing something weird where it dumps them with a hex value at 06 that is 2 higher than what it should be. Because of that, I think that my prototype (and the copy from the other guy) is actually 100% byte-wise identical to retail and it's just the Kazzo that dumped it this way.
What's the reason for this?
The header is not part of the ROM dump. The ROM dump is apparently coming out perfectly for you.
Traditionally, headers were created by hand by the person who dumped them, encoding information that you'd learn by inspecting the board or by trial and error.
You can look at the
iNES file format on the wiki to see what's in byte 6.
A difference of 2 indicates "battery backed RAM" in the header. Ther dumper doesn't know if a cart has a battery in it, so apparently it sets that bit by default just in case. You can manually change it with a hex editor (or use Nestopia's header editor, or
quietust's header editor).
Thanks for the fast response!
I see, now. I'm a total beginner with this aspect of ROM dumps, so that's good to know. Going by this, regarding several of the NES prototypes featured on Nintendoplayer.com that are only apparently different in the header, those would be the result of the dumper used as well? The site owner possibly uses a CopyNES, I need to check that. (the number of reported differences in the header varies among prototypes discussed on that site, fwiw).
Dumping programs aren't generally expected to create completely correct headers. There is only so much you can try to automatically detect, and a lot of dumping software doesn't really even try.
The primary thing a dumper does is read the ROMs from the cartridge.
The header is there to provide information to an emulator about how to run the ROM. Getting the header correct is the responsibility of a human. If you know what you're looking at, a visual inspection of the board might be enough to know what belongs in the header, though when this fails you might figure it out by trying different settings and seeing if it emulates properly. (You should also be inspecting the ROM to make sure it isn't overdumped, etc.)
If it's not a new dump, you can just look up the information you need to fill the header:
http://bootgod.dyndns.org:7777/There are plenty of good ROM dumps out there with bad headers on them. Headers aren't necessarily unique, either; very often there are inconsequential bits that may be set either way.
Ah, alright, this is good to know. Thanks for the help!
gaminginabox wrote:
I'm going to resume trying to dump the cartridge - but in order to do that, I'll need to learn how to write a script for this particular cartridge. Is it possible for me to get a tutorial on how to write a script? I would like to learn so I won't have to ask for help every time I come across another "strange" cartridges.
I'd love to help you with this, but it's kind of hard to summarize all the little things you might need to know without knowing what you already know.
What do you already know about how the NES works? Have you ever written any program in any programming language? Have you looked at the existing dumping scripts?
What hardware is inside the cartridge? (Epoxy blobs? Actual packaged ICs?)
Just wanted to make some announcements for recent hardware updates and upcoming software updates with our version of the kazzo to make people of interest aware. I made some improvements to the hardware that affected all units shipping out as of a couple weeks ago. And have some software/firmware redesign in the works slated to release within a couple months.
PTC resettable fuse added to incoming USB power. Relieves issue where users could damage SNES boards by inserting them into the kazzo backwards. Also offers some protection from short circuiting the power rails by mishandling a case-less device.
SNES connector pitch correction. As advertised (yet to be updated..) the differing pitch of the SNES connector made the device incompatible with original SNES cartridges and their narrow PCB pins. The previous solution was using a 60pin connector with the 46pin cart slid all the way to the right. The extra over hang of the 60pin female connector also mechanically prevented a SNES cart from being inserted while in it's case. You had to remove the board from the case to flash my SNES boards. The new solution uses the same widely available TE connectivity 60pin connector, but 'centers' the cartridge in the middle of the 60pins. Some bare PCB inserts are wedged in on each side of the female connector to 'trim' the 60pins down to 46pins. The removal of the 'slop' and proper centering removes enough of the pitch error to allow original SNES boards to make proper contact much in the same way that the NES connector does. This also makes it so the SNES cart can be inserted without removing the case. So the hardware will now make it possible to support dumping SNES games and backing up save data.
If there's interest I will entertain the idea of creating a pin adapter for older designs to correct this pitch issue on older devices.
The two changes above will should prevent issues people had accidentally inserting SNES boards backwards into the kazzo and SNES as the board can be left in the case at all times. The PTC fuse will protect if inserted properly into kazzo, and leaving the cartridge case on at all times prevents improper insertion to you SNES.
Minor component rearrangements to better support a case/housing. Some of the previous locations put switches and screw holes in difficult locations to support a case. I've got some prototype case designs made from plexiglass currently. Once I've got the upcoming code updates complete I'll be focusing on offering cases which can also be purchased separately. If there's enough interest I'll try to design some cases to work well enough with the old PCB layout as well.
Beyond the hardware updates above I'm working on a fresh build of the firmware and host app redesigned from the ground up. The code will be open source and I'll be making the project publicly available on github shortly once some basic functionality is complete enough to share. I'm open for suggestions/requests people may have, so feel free to chime in if you'd like and I'll take them into consideration. I'm starting development as I think all things should be with a command line interface only. My goal is to have a working version of this released around new year's 2017. Once basic functionality is complete via command line I'll work on adding a gui for windows at least. Here's some of what I have planned.
Host support for multiple operating systems Previous versions only supported windows XP through 10. I will be continuing windows support of course, but also be developing/testing on linux in tandem. I'm using libusb 1.0 drivers so the source code should support all OS's without much trouble. I don't currently have a mac to work and test with, but will probably pick one up to support a mac once I've released windows and linux.
Scripting support I will be adopting scripting similar to how the original kazzo firmware and anago/unagi works. I don't plan to support the original anago scripts however. Some planned improvements include making things more transparent and better documented compared to anago. Too much was handled behind the scenes and didn't allow user control or debugging. This includes things like rom header creation, rom size detection, etc. Additionally I'm planning to provide commands to directly toggle mcu pins and have user created read/write functions so you can dictate things like if m2 toggles, or EXP0 is controlled during a read/write operation which is can be helpful for certain flash cart operations.
My primary goal with the scripts is to allow features to be added to the app and firmware without necessitating rebuilding the source code for which is what's currently required with my app/fw solution. This structure also supports most of the intelligence to be handled on the host side where it belongs vs on the device side where I previously kept it. I started to reach the point where I exceeded the mcu's program flash and this will resolve that for the foreseeable future.
Support for other programming protocols I have plans to expand programming support beyond parallel memories including JTAG, SPI, I2C, etc. Having JTAG programabilty would allow users to a .svf file on the host and allow them to reconfigure the CPLD/FPGA on a flash cartridge. This ability will open up opportunities for me to offer new flash board products as well as an open programmer for other's to develop hardware with if they'd like. If there's interest I could be convinced to make a few tutorials of how to create a custom mapper from paper through logic synthesis and onto a cartridge along with a programming script to go along with it.
Speed boosts I'm sticking with the current hardware design for now as I don't want to 'discontinue' it, I've sold over a thousand of these programmers to date and I want to provide everyone who already owns one with these updates. Yes big-banging V-USB is slow, but there are many improvements which can be made. Most of these improvements can't be applied to dumping operations though, as they only improve flashing cartridges. Some low hanging fruit is doing things like designating the firmware to flash data into multiple locations to automatically double up a rom image for oversized flash chips. Some modest improvements are also possible with double buffering the mcu.
Another feature I'm considering to boost speed is to avoid erasing the entire flash chip. This will be beneficial for developers especially. If you only tweak one line of code the entire PRG-ROM probably doesn't need to be erased and re-written. Chances are only a few flash sectors are affected. And certainly not the CHR-ROM for this example. So performing a checksum on each sector and verifying it needs erased instead of blindly erasing and reprogramming all memories on board can drastically boost overall speed.
For situations where someone is producing a game and flashing the same rom image onto multiple boards I will providing means to have two cartridges inserted at once. So for example a .nes rom image could be stored on a SNES flash board, and then quickly copied over to a blank NES cartridge.
Auto-detection This is something that effectively doesn't exist in anago as the user must determine the correct script to use. And where it is done for header creation and rom size it's hard to override. My build's firmware used some auto-detection via mirroring tests to determine which flash algorithm to use. However I didn't have a means for the user to manually override and dictate which algorithm to use. The new design will make an attempt to detect what mapper and board config is inserted and notify the user. But then also allow the user a means of input to override things when auto detection isn't behaving as desired. The overall goal will make things easier for both novice and advanced users.
Rom patching I consider this more of a 'nice to have' wish list feature. Providing an option for user to designate a patch file to be applied to the rom. I like the idea of a user being able to insert an original game which gets dumped internally to the app, patch applied to it, and then programmed onto a flash cartridge. This would ride the line of the idea of making a "modified" copy of something to which you own. Legalities are debatable I know and that copy rule doesn't necessarily apply to binary roms, but this would be one of the most legitimate means to enjoy hacks/translations that I can think of. The ultimate legal solution for that would be a game genie like device which might temporarily store a patched copy in RAM or maybe some other ultra fast live patching means. This feature could be a stepping stone to such a device's creation.
Live cartridge probing/debugging This is one of my more advanced features I'd on my wish list, but can't promise I will make it around to this. Basically I'd like something like a terminal interface with the cartridge where commands can be issued in real time and read back. A simpler means of this might be to single step the current script. This would assist in mapper reverse engineering as well as hardware debugging with the addition of a multimeter/logic probe.
As for the future I do have some hardware improvements/additions in mind but I'm not going to fixate on them too much until this new build is released. I've been getting a number of requests to support other systems including but not limited to gameboy, GBA, sega, N64, colecovision, etc. Not certain if/when I'll tackle those and how, but bit banging large N64 roms exceeds my patience and would necessitate a hardware USB solution. I drafted up a design to accommodate that earlier this year, but I'm going to shelf it for the time being. I will say however that any such hardware improvement will be able to take advantage of the DIP socket used for the current mcu. Some basic soldering skills *might* still be required to retrofit older kazzo's, if that's the case I'll also be offering a upgrade service or trade in option for people looking to upgrade their device. Cartridge connector differences will be resolved via pin adapters which could insert into SNES/NES connector(s).
lidnariq wrote:
gaminginabox wrote:
I'm going to resume trying to dump the cartridge - but in order to do that, I'll need to learn how to write a script for this particular cartridge. Is it possible for me to get a tutorial on how to write a script? I would like to learn so I won't have to ask for help every time I come across another "strange" cartridges.
I'd love to help you with this, but it's kind of hard to summarize all the little things you might need to know without knowing what you already know.
What do you already know about how the NES works? Have you ever written any program in any programming language? Have you looked at the existing dumping scripts?
What hardware is inside the cartridge? (Epoxy blobs? Actual packaged ICs?)
Sorry about the delay in responding, this week has been a very hectic week for me.
I confess I don't know much about how NES works beyond what I've gleaned from various forums, etc, over the years. I've tried modifying scripts to reflect the larger sizes of CHR and PRG, but never had any success dumping the cartridge. Maybe we'll just forget the tutorial part and focus on trying to dump the cartridge instead?
Here's photos of the cartridge (linked to my site):
PowerJoy ExteriorPowerJoy InteriorThank you!
(EDIT TO ADD) Would having a ROM of the cartridge be handy in figuring out how to write a script to dump this cartridge? I do have a ROM on hand of a PowerJoy PJ-008 but with a different game list.
gaminginabox, have you taken a look at POWERJ.ASM in the CopyNES plugins? It's possible that the PowerJoy ROM dump you have is from my cart. My mom actually bought me one of those back in maybe 1999 when they were for sale everywhere. I loaned it to kevtris, he figured out the mapper and dumped it. I should still have the cart but I haven't seen it in a long time, I don't seem to have the dump of it either.
I'm pretty sure my board was different, haven't looked it in a long time but I seem to remember there being actual chips (sort-of, epoxy blobs on carrier boards, with diodes to lower the voltage to the VCC pin
) and the epoxy blob for the mapper. No guarantee it's the same mapper as yours, but I think there's a good chance that it is. Cart label seems the same as I remember it.
Also, you might know this, but if it's the PowerJoy 2 system you have, it also has more games built-in. Just turn it on without a cart. There are some funny hacked games in there.
Memblers wrote:
gaminginabox, have you taken a look at POWERJ.ASM in the CopyNES plugins? It's possible that the PowerJoy ROM dump you have is from my cart. My mom actually bought me one of those back in maybe 1999 when they were for sale everywhere. I loaned it to kevtris, he figured out the mapper and dumped it. I should still have the cart but I haven't seen it in a long time, I don't seem to have the dump of it either.
I'm pretty sure my board was different, haven't looked it in a long time but I seem to remember there being actual chips (sort-of, epoxy blobs on carrier boards, with diodes to lower the voltage to the VCC pin
) and the epoxy blob for the mapper. No guarantee it's the same mapper as yours, but I think there's a good chance that it is. Cart label seems the same as I remember it.
Also, you might know this, but if it's the PowerJoy 2 system you have, it also has more games built-in. Just turn it on without a cart. There are some funny hacked games in there.
Just spent the weekend trying to write the script - no success, I'm over my head here. Thanks for the POWERJ.ASM, though! Still working on it.
Question concerning the construction UxROM for Kazzo. On the unagi page writes:
"So far, HVC-UNROM-10 and HVC-UOROM-01 have been successfully tested. Other 74xx161-based boards not referenced in this document might not comply with the following instructions."
Are commercial PCB UNROM may differ connections controller? I have a NES-UNROM-02, if there is a possibility of difference UNROM-10? Many pirate UNROM have differences, so maybe commercial also depending on the revision?
I ask for assurance that there was no problem in this case when I was building UNROM.
Has anyone successfully dumped Akumajou Densetsu with this?
I purchased one to back up my library & am having trouble getting it to dump properly.
I spent the past few minutes making a cool batch file that will dump your game, open it in an emulator, and then delete it. It gives the illusion that it's running right off the cart!
But it's not If that didn't make any sense, my video example will probably give you a better idea of what this does:
https://youtu.be/PzRP3c11Mz4To use this file, there are only two steps. 1, you need to double click on a .nes rom. A screen asking you which app you want to use should appear. Click "look for another app on this pc" and locate your nes emulator. 2, Download and extract the batch file and place it in: /kazzo/kazzo original/unagi_client_windows_062_GUI/anago/. Now just run the bat file and you're good to go! I hope you all find this useful!
-Blake
Can anyone confirm if the Super Mario World hack called "Brutal Mario" works with the inl snes boards? I see people selling reproductions of it so I assume it runs on real hardware, but when I flashed the game and tried it out the snes played the coin sound effect and black screened upon booting up the game. If someone could test out the hack and see if it works, I'd greatly appreciate it!
Sounds like some great changes coming! And I'm definitely interested in a pin adapter, because I'd love to dump my SNES library. I'm also looking forward to using something more robust than the anago software for dumping NES games.
I can't dump the following cartridges:
- Rockman 4 (must dump as CHR RAM, even the mm3_full script gives an error);
- Tiny Toon 2 (pirate, the board with 3 black drops brings the inscription VRC4);
- Excitebike ("Super Bike" title, nrom choices gives ppu_rom error, same of Rockman 4 I guess);
- 600in1 (no clue which script to use).
EDIT: added board pictures, except Rockman 4, check the ZIP file.
Blake5100 wrote:
Can anyone confirm if the Super Mario World hack called "Brutal Mario" works with the inl snes boards? I see people selling reproductions of it so I assume it runs on real hardware, but when I flashed the game and tried it out the snes played the coin sound effect and black screened upon booting up the game. If someone could test out the hack and see if it works, I'd greatly appreciate it!
Yes I have burned both the Japanese and English rom hack of Brutal Mario
viewtopic.php?f=28&t=12963&start=15
Not giving up on dumping PowerJoy via Kazzo.
I've split PRG and CHR of existing PowerJoy ROM and got this as a note:
Program repetition: 1 time(s)
Character repetition: 1 time(s)
Program RAM size: 0KB
iNES format: 1.0
System: NES
Program Banks: 128 (16KB Each)
Character Banks: 128 (8KB Each)
Mapper: 126
Mirroring: Vertical
Trainer: No
Trying to dump PowerJoy with MMC3 script yields SOMETHING - garbled screen but still can scroll up and down the list and switch "pages". Other scripts also yielded something, but MMC3 seems to be the closest. So maybe I'll focus on tweaking the MMC3 script.
I've looked at the script writing tutorial at ungai site (via Google Translate) but there is no mapper 126 in VirtuaNES source so I can't follow along with the script writing tutorial.
Found source code to PowerJoy board in Nestopia source code. Going to see if I can use this.
Code:
////////////////////////////////////////////////////////////////////////////////////////
//
// Nestopia - NES/Famicom emulator written in C++
//
// Copyright (C) 2003-2008 Martin Freij
//
// This file is part of Nestopia.
//
// Nestopia is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// Nestopia is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with Nestopia; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
//
////////////////////////////////////////////////////////////////////////////////////////
#include "NstBoard.hpp"
#include "NstBoardMmc3.hpp"
#include "NstBoardBmcPowerjoy84in1.hpp"
namespace Nes
{
namespace Core
{
namespace Boards
{
namespace Bmc
{
#ifdef NST_MSVC_OPTIMIZE
#pragma optimize("s", on)
#endif
void Powerjoy84in1::SubReset(const bool hard)
{
if (hard)
{
for (uint i=0; i < 4; ++i)
exRegs[i] = 0;
}
Mmc3::SubReset( hard );
for (uint i=0x6000; i < 0x8000; i += 0x4)
{
Map( i + 0x0, &Powerjoy84in1::Poke_6000 );
Map( i + 0x1, &Powerjoy84in1::Poke_6001 );
Map( i + 0x2, &Powerjoy84in1::Poke_6001 );
Map( i + 0x3, &Powerjoy84in1::Poke_6000 );
}
}
void Powerjoy84in1::SubLoad(State::Loader& state,const dword baseChunk)
{
if (baseChunk == AsciiId<'B','P','J'>::V)
{
while (const dword chunk = state.Begin())
{
if (chunk == AsciiId<'R','E','G'>::V)
state.Read( exRegs );
state.End();
}
}
else
{
Mmc3::SubLoad( state, baseChunk );
}
}
void Powerjoy84in1::SubSave(State::Saver& state) const
{
Mmc3::SubSave( state );
state.Begin( AsciiId<'B','P','J'>::V ).Begin( AsciiId<'R','E','G'>::V ).Write( exRegs ).End().End();
}
#ifdef NST_MSVC_OPTIMIZE
#pragma optimize("", on)
#endif
uint Powerjoy84in1::GetExChrExBank() const
{
return
(
(~uint(exRegs[0]) << 0 & 0x080 & uint(exRegs[2])) |
( uint(exRegs[0]) << 4 & 0x080 & uint(exRegs[0])) |
( uint(exRegs[0]) << 3 & 0x100) |
( uint(exRegs[0]) << 5 & 0x200)
);
}
void NST_FASTCALL Powerjoy84in1::UpdatePrg(uint address,uint bank)
{
bank &= ~uint(exRegs[0]) >> 2 & 0x10 | 0x0F;
bank |= (exRegs[0] & (0x6U | (exRegs[0] & 0x40U) >> 6)) << 4 | (exRegs[0] & 0x10U) << 3;
if (!(exRegs[3] & 0x3U))
{
prg.SwapBank<SIZE_8K>( address, bank );
}
else if (address == (regs.ctrl0 << 8 & 0x4000))
{
if ((exRegs[3] & 0x3U) == 0x3)
prg.SwapBank<SIZE_32K,0x0000>( bank >> 2 );
else
prg.SwapBanks<SIZE_16K,0x0000>( bank >> 1, bank >> 1 );
}
}
void NST_FASTCALL Powerjoy84in1::UpdateChr(uint address,uint bank) const
{
if (!(exRegs[3] & 0x10U))
chr.SwapBank<SIZE_1K>( address, GetExChrExBank() | (bank & ((exRegs[0] & 0x80U) - 1)) );
}
NES_POKE_AD(Powerjoy84in1,6000)
{
if (!(exRegs[3] & 0x80U))
NES_DO_POKE(6001,address,data);
}
NES_POKE_AD(Powerjoy84in1,6001)
{
address &= 0x3;
if (exRegs[address] != data)
{
exRegs[address] = data;
if (exRegs[3] & 0x10U)
chr.SwapBank<SIZE_8K,0x0000>( GetExChrExBank() >> 3 | (exRegs[2] & 0xFU) );
else
Mmc3::UpdateChr();
Mmc3::UpdatePrg();
}
}
}
}
}
}
I have done two dev-cards, which are adapted to Kazzo (original anago) - SUROM and SNROM. SUROM programmed easily, but there is a problem with SNROM (there are problems with the CHR-FLASH). The status bar CHR hangs on "ERASING".
I suspect that the problem is the lack of profile SNROM. I have the opportunity to choose only mmc1_SKROM.ag and mmc1_SUROM.a in KazzoGUI. My guess is that CHR SNROM is not compatible with CHR SKROM? Can anyone send me the file / profile (*.ag) to SNROM?
I did also UNROM according to the description of this page:
https://osdn.net/projects/unagi/wiki/flash_74161_enChecked everything thoroughly, I do not know why you do not want to work. PCB has a DIP32 socket - if the memory is programmed external programmer it all works ok, but do not want to run the Kazzo programmer (I used the original game PCB - exactly HCV-UNROM-03, two types of flash memory have been tested - SST39SF020 and W49F002)
I've been trying to dump Super C with the kazzo, but only the CHR will dump properly. It appears that I have the "KONAMI-TLROM" version, according to bootgod's database. I'm assuming the pins are different from NES-TLROM and this is why I can't get it to dump properly. Of course, the pins still might be dirty and we all know what happens when we assume. Any ideas? Thanks.
Kind of curious if anyone else has had this issue with the Kazzo programmer. I went to burn Super Mario The Lost Adventure 3 yesterday and for the life of me could not get it to save. I swapped out a battery and still nothing. I burned the rom again and still nothing. I assumed that there was some how an issue with the rom itself and almost gave up. Today for whatever reason I tried a third battery and voila! It saved properly.
So with that in mind, how long does your guys kazzo carts batteries last? I bought my boards a year ago to two years max. My Aunt brought up some NES and SNES games for me on Thanksgiving that I played as a kid seriously 20-25 years ago and the saves are still good.
Please don't think I am complaining, more of curious if I am doing something wrong that could possibly be killing the batteries or if its possible I just got a bad batch of batteries from China ect.
This is a new one. I bought a copy of RoboCop and tried to dump it with the kazzo. After dumping the PRG, it would stop and generate an error:
libusb0-dll:err [control_msg] sending control message failed, win error: A device attached to the system is not functioning.
I thought my kazzo had stopped functioning, as I hadn't used it in awhile. So, I tried reinstalling the driver. Everything seemed fine. I tried other games, and it attempted to dump them properly.
I decided to open RoboCop up to clean it in case that was the problem. However, I discovered that the board inside is NES-TLBROM-01. I do not see this board in bootgod's database. I do not see this board anywhere. I see TBROM, but not TLBROM. What the hell is this? Does anyone have any idea?
The board has a PRG chip, a CHR chip, the lockout chip, the MMC3A chip, another chip up top, and what appears to be a resistor near the CHR chip.
Here's a pic of the board (sorry about the quality, my dumbphone's camera is not the greatest)
Attachment:
File comment: NES-TLBROM-01
0318171649-01.jpg [ 275.28 KiB | Viewed 3229 times ]
Any chance you have a scanner? OR would be willing to spend more timing fighting with your camera to get a picture that's in focus? If so, a picture of the back also would be lovely.
Also, please attach images to the forum so that we're not dependent on third parties not losing data.
From what I
can see, it looks similar to
NES-TL1ROM (but different; e.g. the CIC has moved, there's this bizarre extra SN74LS541N on the board)
The labels on your PCB's mask ROMs:
NES-CP-0 PRG
5M58-12-12-D253
894C5A1 JAPAN
NES-CP-0 CHR
5M58-12-D256
8940EAI JAPAN
seem to be a month earlier than the
previous one in NEScartDB.
My hunch is that the 74'541 is getting in a fight with the Kazzo, drawing too much power, causing the device to fall off the USB. On the bright side, there's no reason to think this dump is different from any other copy of US Robo Cop 1.
The
big list of 7400 series ICs on Wikipedia lists 74541 as a "non-inverting octal buffer, three-state outputs". It may be acting as an output enable mechanism to allow use of marginally slow CHR ROM, analogously to the 74HC245 ("octal bus transceiver, non-inverting three-state outputs") in
Holy Diver.
Thanks for the info, guys. Good stuff. I'll work on getting better images of it for you.
[Post had a bunch of incorrect assumptions and errors, purging...]
Pictures of novel PCBs are always appreciated, regardless of whether they're helpful!
I tentatively think your script matches the FCEUmm source code.
Here you go! The "KS127" chip appears to be the PRG chip.
Can't trace all of the board, but the big thing I see relative to the implementation in FCEUmm is that the latches latch the address bus, not the data bus.
If that's not enough, I think I'd need a connection list for the pins on the 74'157s, 74'161s, and PAL to be able to get any further.
That would be a bit out of my scope sadly, since this is, I should clarify, someone else's board and that the mask ROM seems to be custom and I don't know if the pinout for the it would be the same as others. I could ask for the cart to be sent off to kevtris but he's kinda busy with everything so... eh...
I do have a NROM readout of the cart if it would mean anything useful. For anyone who wants to take a shot, PM me.
The Mask ROM looks perfectly normal (other than being the standard JEDEC 28-pin 128 KiB ROM). I mean, I can tell the following from the picture:
Left '161: can't tell much, other than that its outputs probably connect to the left '157
Left '157: set up to emit either (output of right '157) or (value in left '161)
Right '157: set up to emit either (value of CPU address bus) or (lower three bits of right '161)
Right '161: definitely latches CPU A0-A3 when so instructed by the PAL
PAL:
[code]
1: ?A10?
2: /ROMSEL
3: A14
4: A13
5: A12
6: ?A11?
7: ?R/W?
8: ?PPU A11?
9: ?PPU A10?
10: Gnd
20: +5V
19: Latch1
18: Mux1
17: Latch2
16: ?Mux2?
15: PRGROM /OE
14: M2
13: ?PRGRAM /CE?
12: ?CIRAM A10?
11: Latch2Q3
Oops! I have missed that the mapper splits the address map into scrawny bits and splits the primary 4K bank space at 0xC800 into a 1K region at 6C00-6FFF and a 3K region at C000-CBFF whenever the cart does a read... So I modified the script to read those areas.
I'll get back to this thread once the guy runs the newer version of the script to see if anything has changed.
EDIT: Crap, uh, I just realized that anago can't read from the middle of the address space (i.e. 6000-7FFF returns with "address range must be" error). Is this a software or hardware limitation for the Kazzo?
EDIT: nevermind, cpu_ramrw exists
Some kind of anticipation for tracks under chips and restored schematics.
Hm, I made a bunch of different guesses about connectivity, especially under the right '157and left '161...
Right.... I'm close to giving up on trying to dump this with a Kazzo. Even with the correct cpu_ram fields, cpu_ramrw, in what I'm assuming should be write mode (writing the WRAM back to a file), just gives a "RAM image error" when trying to dump the 1K chunks at 6C00.
I guess I'll have to get the guy to send off the mask ROM to get dumped then...
Care to share your current kazzo script?
https://pastebin.com/WQSUqHNiMy plan was to dump the .NES file, take the extra 3K banks cpu_read dumps and combine them with the 1K banks cpu_ram_access dumps.
(the 1K goes first, then the 3K second) But I don't know how to work the Kazzo well, and of course I only have indirect access to it, so it just currently errors out for us when trying to dump from the workram tab.
And then, I still have other problems, not knowing what causes the banks to change only once regardless of whatever I write to 0x9000 afterwards...
Hm. Having now done by best to trace the board, this is wrong:
cpu_write(d, 0x9000, i);Your register writes should always look like
cpu_write(d, 0xN000+i, 0xFF); because the latches latch the address bus, not the data bus.
If I understand correctly, even though PRG ROM is readable directly from $8000 through $B7FF, you have to use reg0 to read out the bits that are hidden under the RAM ports at $B800-$D7FF.
So I
think you want something like
Code:
for (local i = 0; i < 8; i += 1) {
cpu_write(d, 0x8000+i, 0xFF);
cpu_read(d, 0x7000, 0x1000);
}
for (local i = 0; i < 16; i += 1) {
cpu_write(d, 0x9000+i, 0xFF);
cpu_read(d, 0xC000, 0xC00);
cpu_read(d, 0x6C00, 0x400);
}
RAM is not battery-backed so you shouldn't need to read it...
I fear that FCEUmm's source shuffles the 1KiB slices around, so even this won't be a match, even if it's closer to what's on the physical ROM.
That should work. Problem is, when I tried the method of directly reading 0x6000-7FFF earlier, according to the guy I'm dumping this cart for, anago always errors out with "address range must be 0x008000 to 0x010000". Does he happen to have an older version of anago?
Oh, huh.
That constraint is in script_dump.c, so it can't just be trivially fixed by changing some of the other scripting. Does anyone know how to rebuild anago without that constraint?
So that's why you were attempting to dump the other bits as though they were RAM.... (duh). Did anything go wrong, other than the bankswitching not happening at all?
Does that mean if someone were to make an NROM-368 cart, with a circuit to decode $4800-$FFFF, anago wouldn't be able to dump it? OMG DRM!
Pretty much nothing other than the "RAM image error" I described above.
Time to dig deep into the unagi source code!
...and I've already hit a error relating to API compatibility that I can't solve, despite using the correct version of libusb-win32.
Code:
In file included from ../reader_kazzo.c:8:0:
../usb_device.h:29:23: error: unknown type name ‘usb_dev_handle’
int usbGetStringAscii(usb_dev_handle *dev, int index, char *buf, int buflen);
^~~~~~~~~~~~~~
../usb_device.h:40:19: error: unknown type name ‘usb_dev_handle’
int usbOpenDevice(usb_dev_handle **device, int vendorID, char *vendorNamePattern, int productID, char *productNamePattern, char *serialNamePattern, FILE *printMatchingDevicesFp, FILE *warningsFp);
^~~~~~~~~~~~~~
../reader_kazzo.c:11:8: error: unknown type name ‘usb_dev_handle’
static usb_dev_handle *device_open(void)
^~~~~~~~~~~~~~
../reader_kazzo.c: In function ‘device_open’:
../reader_kazzo.c:13:2: error: unknown type name ‘usb_dev_handle’
usb_dev_handle *handle = NULL;
^~~~~~~~~~~~~~
../reader_kazzo.c: At top level:
../reader_kazzo.c:30:8: error: unknown type name ‘usb_dev_handle’
static usb_dev_handle *handle = NULL;
^~~~~~~~~~~~~~
../reader_kazzo.c:48:25: error: unknown type name ‘usb_dev_handle’
static void device_read(usb_dev_handle *handle, enum request r, enum index index, long address, long length, uint8_t *data)
^~~~~~~~~~~~~~
../reader_kazzo.c:89:26: error: unknown type name ‘usb_dev_handle’
static void device_write(usb_dev_handle *handle, enum request w, enum index index, long address, long length, const uint8_t *data)
^~~~~~~~~~~~~~
make[1]: *** [<builtin>: reader_kazzo.o] Error 1
If anyone else has experienced this error or knows how to build a Win32 build for anago with GCC 6.3, be my guest.
That looks like you don't have the libusb build headers installed? Or at least that it didn't include them and/or couldn't find them. usb_dev_handle is definitely in mine...
Ok, renaming the lusb0_usb.h header to usb.h solved it... But that's only a minor issue.
I now have to recompile libusb since the precompiled binary is incompatible for my mingw32 environment... and now that it's requiring "conio.h", which my mingw64 environment only has, and Visual Studio crap, it's making me go crazy.
... actually, I have a terrible idea.
Where's the exact program (exe) you're having him run?
(p.s. IDA free is adequate for my terrible idea)
I think he's just running the latest anago.exe paired with anago_wx.exe, grabben of the Kazzo site in the unagi_client_windows_062_GUI folder...
...........wait...... you thinking what I'm thinking? also:
Quote:
I fear that FCEUmm's source shuffles the 1KiB slices around, so even this won't be a match, even if it's closer to what's on the physical ROM.
I don't think that's true? According to the commit logs, the mask ROM for the Kaiser version was verified long ago, regardless of the comments in KS7030.c...
Quote:
new UNIF board for "Yume Koujou Doki Doki Panic (FDS Conversion)(Kaiser)(KS7030)[U][!] <---
What makes you think the 1K bit goes last instead of first?
I can't trivially test this, but try this:
Original file: anago_wx.exe, 658944 bytes, crc32: e6e94fef, md5sum: 3d63754d378d2cabbe6e3353475a8dee
This patch
should dummy out the lower bound check.
Attachment:
anago_wx.ips [15 Bytes]
Downloaded 93 times
Quote:
What makes you think the 1K bit goes last instead of first?
It doesn't, but the offset math in FCEUmm looked wrong to me. The lower 12 bits of the address lines should be unchanged before and after banking.
lidnariq wrote:
I can't trivially test this, but try this:
Original file: anago_wx.exe, 658944 bytes, crc32: e6e94fef, md5sum: 3d63754d378d2cabbe6e3353475a8dee
This patch
should dummy out the lower bound check.
Attachment:
anago_wx.ips
Doesn't work, still spouts the "address range" error.
Looks like I need to resort to figuring out how to actually compile this crap.
That's really weird.
Here's another possible couple patches that might help?
patch #2 should change the specific value for the lower bound check, changing it from 0x8000 to 0x4100.
Attachment:
anago_wx2.ips [14 Bytes]
Downloaded 97 times
patch #3 should disable the
upper bounds check. I don't see how this could be relevant, but applying both #1 and #3 should make it impossible for the bounds check to trigger... should.
Attachment:
anago_wx3.ips [15 Bytes]
Downloaded 98 times
It's not like testing these actually require the cartridge; just a physical Kazzo (which I don't have :/ )
Alright, the guy has to test the patch tomorrow, so I'll keep tight on how this goes. Man, all this trouble for one cart.
Hey, figured I'd drop by since I had just noticed this was discussed here.
The anago_wx.exe I have matches the given MD5.
I tried each IPS patch (with Lunar IPS), checked MD5 (if it was different after patching & checked consistency) as well each time with CertUtil -hashfile anago_wx.exe MD5. Each time it was still giving the 0x8000->0x10000 address error.
I'll try to recompile it on my old computer as well, might be able to… or not.
After a day of libusb errors and stretching around with Squirrel 2 on a slow computer, I've managed to get anago to dump the cart! Success!
...but it doesn't look like I can successfully emulate it in MAME anyways. The bank at 0x7000 appears to be the extra "BANK 0" that is mentioned within the comments. I combined the main 32K PRG chunk from the NROM readout, put the 32k and 64k chunks first, and the main 32K PRG chunk last to hopefully create a representation of what is in the actual mask ROM. The startup looks to be okay, but after a couple of bankswitches, the emulation freaks out and jumps to data.
Bump.
So, I'm having an issue with the kazzo. It's been working fine for almost a year now and I've been able to dump all sorts of games with it. However, my computer hasn't been able to recognize it.
- Using Windows 10
- Each time I plug it in, Windows says "the last USB device you connected malfunctioned, and Windows does not recognize it"
- Anago always displays a Reader open error message
- Vendor ID and product ID for the device read "0x0000" and "0x0002" respectively in the inf-wizard
- recently replaced the part where you plug the cable in (yay, soldering practice for the n00b!), BUT, even after the repair, it worked
- Tried loading the Microsoft OS with driver signature enforcement disabled, tried loading with it enabled
- Tried unplugging and replugging-in the dumper
- Tried two different computers
- Tried different cables
Is anyone willing to help diagnose/resolve the problem?
just replied to the ticket you sent me. Curious if it's recognized by windows in boot loader mode and if so, if you PC is able to recognize it when flashed with my firmware.
infiniteneslives wrote:
just replied to the ticket you sent me. Curious if it's recognized by windows in boot loader mode and if so, if you PC is able to recognize it when flashed with my firmware.
Just solved the issue! Thank you so much for your quick reply. The PC did recognize it in BL mode. I didn't quite know where to go from there when I first found that out, so I tried reinstalling the firmware and now it runs fine. Thanks so much.
In other news, I'm trying to dump a copy of Lagrange Point using the script found here:
http://svn.osdn.jp/svnroot/unagi/client ... mi_vrc7.agUnfortunately, it isn't yielding a workable ROM and the script only works in the 062 command line version of anago. The crc32 output is 0xcfb3e8b9. Does anyone know where I can find a working script for the game?
Edit: It turns out that it is yielding a ROM that works, but one only to an extent. The title screen shows and I can press start to get past it (with sound effect), but after that there's just a black screen.
Hello. I assembled the dumper according to this conceptual scheme -
I use the program - anago_wx
The cartridges are read correctly. Read 0,1,3,4 mappery - all is well!
But I can not understand how to record games on cartridges. I need to know where and what signals from FLASH memory need to be connected. I use memory - W29C020. I am very grateful for the help!
Hope I'm not breaking any rules here; it was recommended that I ask in this thread about the following problem.
I just got a copy of Ganbare Goemon Gaiden and it doesn't seem to want to be dumped. I've been trying to use the VRC2 scripts found
here and
here, but to no avail. The process always goes up to about 15/16 of the way through the CPU dump and then Kazzo gives me the following error:
Code:
libusb0-dll:err [control_msg] sending control message failed, win error: A device attached to the system is not functioning.
I've tried everything I can think of:
- opening and cleaned the cart several times
- using both versions of anago (60 and 62)
- doubling both the CPU and PPU rom dump ("d22" command in command prompt)
- exchanging the commands in the script to "dofile" for the script in the
vrc4.ai file- getting rid of the "dofile" line altogether
I've run the game through other scripts (e.g. mmc3.ag) as well just to see if it was only the script. I've also tested another game to see if I needed to reinstall the kazzo's firmware or something. Everything else checks out. Is the game corrupt? And if that's the case, is it just a matter of buying another copy?
werewolfslayr925 wrote:
libusb0-dll:err [control_msg] sending control message failed, win error: A device attached to the system is not functioning.
That message insinuates that the microcontroller has crashed, or is in an infinite loop, or is drawing more power than it's allowed to.
Ganbare Goemon Gaiden is an odd duck among the VRC2 carts, since it adds extra hardware to add support for RAM. Have you tried dumping it as though it were VRC4?
Quote:
Ganbare Goemon Gaiden is an odd duck among the VRC2 carts, since it adds extra hardware to add support for RAM. Have you tried dumping it as though it were VRC4?
I remember trying that because I saw that the VRC2 script pointed to something related to VRC4 anyway. I don't remember if it gave the same error or if it gave me a specific error for a particular line in the script. I'll have to wait to get home to find out.
If it does give the same error as mentioned above (libusb0 etc.), what would I need to do to dump it?
No idea.
Given that you do get through 15/16 of the PRG, it seems safe to assume that what's going wrong is somewhere in the last three lines
Code:
function vrc4_cpu_dump(d, pagesize, banksize, r0, r1)
{
local a2 = 1 << r1;
cpu_write(d, 0x9000 | a2, 0);
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);
}
cpu_write(d, 0x9000 | a2, 0x02); ←
cpu_write(d, 0x8000, 0x1e); ←
cpu_read(d, 0xc000, banksize * 2); ←
}
Honestly, I don't know why Naruko decided to special case reading the last page, instead of just making it part of the main loop, i.e.:
Code:
function vrc4_cpu_dump(d, pagesize, banksize, r0, r1)
{
cpu_write(d, 0x90ff, 0);
for(local i = 0; i < pagesize; i += 2){
cpu_write(d, 0x8000, i);
cpu_write(d, 0xa000, i | 1);
cpu_read(d, 0x8000, banksize * 2);
}
}
@lidnariq:
OMIGOSH! Yes! Now it's completing the process! I had to throw in one more "}", but that did the trick to make the code complete!
...
However, it isn't yielding a proper dump. I'm getting the following output:
Code:
Program ROM: size 0x020000, crc32 0xcaf8912c
Charcter ROM: size 0x020000, crc32 0x8a0691fd
The output should be different according to Bootgod's database:
http://bootgod.dyndns.org:7777/profile.php?id=3823Any ideas?
werewolfslayr925 wrote:
Code:
Program ROM: size 0x020000, crc32 0xcaf8912c
Charcter ROM: size 0x020000, crc32 0x8a0691fd
The output should be different according to Bootgod's database:
http://bootgod.dyndns.org:7777/profile.php?id=3823Any ideas?
Bootgod's database says they're both 256k (0x40000) chips, not 128k (0x20000).
All other VRC2-using games other than GGG1 max out at 128 KiB, so you might need to change the vrc2a/vrc2b header line to scan more total bytes.
rainwarrior wrote:
Bootgod's database says they're both 256k (0x40000) chips, not 128k (0x20000).
lidnariq wrote:
All other VRC2-using games other than GGG1 max out at 128 KiB, so you might need to change the vrc2a/vrc2b header line to scan more total bytes.
Oof, duh. Okay, so
@lidnariq: I'm not sure which part of the code you mean. Do I change this:
Code:
board <- {
mappernum = 25, vram_mirrorfind = false, ppu_ramfind = false,
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
}
};
to this:
Code:
board <- {
mappernum = 25, vram_mirrorfind = false, ppu_ramfind = false,
cpu_rom = {
size_base = 1 * mega, size_max = 1 * mega,
banksize = 0x4000
},
ppu_rom = {
size_base = 1 * mega, size_max = 1 * mega,
banksize = 0x4000 / 8
}
};
because I tried that and it gave me a whole mess of errors. Please forgive me, I'm not sure what you mean by the header line. What part of the code should I change and how?
Try instead changing each 1 * mega to 2 * mega.
1 megabit = 128k
2 megabits = 256k
A megabit is an 8 times larger number than a megabyte of the same size.
tepples wrote:
Try instead changing each 1 * mega to 2 * mega.
I thought that that might be the issue, and I tried that too, but to no avail. It's still giving me the following errors:
Code:
data range must be 0x000000 to 0x0000ff
CALLSTACK
*FUNCTION [vrc2a_ppubank_set()] vrc2gg.ad line [152]
*FUNCTION [ppu_dump()] vrc2gg.ad line [164]
*FUNCTION [dump()] dumpcore.nut line [45]
LOCALS
[a3] 3
[a2] 1
[a1] 1
[r1] 0
[r0] 1
[j] 129
[i] 128
[addr] 45056
[a3] USERPOINTER
[this] TABLE
[i] 128
[r1] 0
[r0] 1
[banksize] 1024
[pagesize] 256
[d] USERPOINTER
[this] TABLE
[ppu_dumpsize]262144
[cpu_dumpsize] 262144
[ppuarea_memory] 0
[vram] 0
[increase_ppu] 2
[increase_cpu] 1
[mappernum] 25
[script] "vrc2gg.ad"
[d] USERPOINTER
[this] TABLE
For reference, here's the code I've got so far:
Code:
/*
VRCII A0,A1 swap + charcter ROM address bus shiftx1
051744 jumper G?
VRC-CPU|databus
A0 - A1|A0: xxxx210x
A1 - A0|A1: xxxx6543
VRC-CHRCTER ROM
A11-A17 = A10-A16
*/
board <- {
mappernum = 25, vram_mirrorfind = false, ppu_ramfind = false,
cpu_rom = {
size_base = 2 * mega, size_max = 2 * mega,
banksize = 0x2000
},
ppu_rom = {
size_base = 2 * mega, size_max = 2 * mega,
banksize = 0x2000 / 8
}
};
function vrc4_cpu_dump(d, pagesize, banksize, r0, r1)
{
cpu_write(d, 0x90ff, 0);
for(local i = 0; i < pagesize; i += 2)
{
cpu_write(d, 0x8000, i);
cpu_write(d, 0xa000, i | 1);
cpu_read(d, 0x8000, 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 vrc4_ppu_dump(d, pagesize, banksize, r0, r1)
{
for(local i = 0; i < pagesize; i += 8)
{
ppu_bank_set(d, 0xb000, i | 0, i | 1, r0, r1);
ppu_bank_set(d, 0xc000, i | 2, i | 3, r0, r1);
ppu_bank_set(d, 0xd000, i | 4, i | 5, r0, r1);
ppu_bank_set(d, 0xe000, i | 6, i | 7, r0, r1);
ppu_read(d, 0x0000, banksize * 8);
}
}
function vrc4_program_initialize(d, cpu_banksize, ppu_banksize, r0, r1)
{
local a2 = 1 << r1;
cpu_write(d, 0x9000 | a2, 0);
cpu_write(d, 0x8000, 1);
cpu_write(d, 0xa000, 0);
cpu_command(d, 0, 0xa000, cpu_banksize);
cpu_command(d, 0x2aaa, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0xc000, cpu_banksize);
ppu_bank_set(d, 0xb000, 0x0a, 0x15, r0, r1);
ppu_bank_set(d, 0xc000, 0x00, 0x00, r0, r1);
ppu_command(d, 0, 0x0800, ppu_banksize);
ppu_command(d, 0x2aaa, 0x0000, ppu_banksize);
ppu_command(d, 0x5555, 0x0400, ppu_banksize);
}
function cpu_transfer(d, start, end, cpu_banksize)
{
for(local i = start; i < end - 2; i++)
{
cpu_write(d, 0xa000, i);
cpu_program(d, 0xa000, cpu_banksize);
}
cpu_program(d, 0xc000, cpu_banksize * 2);
}
function vrc4_ppu_transfer(d, start, end, ppu_banksize, r0, r1)
{
for(local i = start; i < end; i += 4)
{
ppu_bank_set(d, 0xd000, i | 0, i | 1, r0, r1);
ppu_bank_set(d, 0xe000, i | 2, i | 3, r0, r1);
ppu_program(d, 0x1000, ppu_banksize * 4);
}
}
function cpu_dump(d, pagesize, banksize)
{
vrc4_cpu_dump(d, pagesize, banksize, 1, 0);
}
function vrc2a_ppubank_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 >> 3);
cpu_write(d, addr, i << 1);
cpu_write(d, addr | a3, j >> 3);
cpu_write(d, addr | a2, j << 1);
}
function ppu_dump(d, pagesize, banksize)
{
local r0 = 1;
local r1 = 0;
for(local i = 0; i < pagesize; i += 8)
{
vrc2a_ppubank_set(d, 0xb000, i | 0, i | 1, r0, r1);
vrc2a_ppubank_set(d, 0xc000, i | 2, i | 3, r0, r1);
vrc2a_ppubank_set(d, 0xd000, i | 4, i | 5, r0, r1);
vrc2a_ppubank_set(d, 0xe000, i | 6, i | 7, r0, r1);
ppu_read(d, 0x0000, banksize * 8);
}
}
werewolfslayr925 wrote:
Code:
cpu_write(d, addr | a1, i >> 3);
cpu_write(d, addr, i << 1);
cpu_write(d, addr | a3, j >> 3);
cpu_write(d, addr | a2, j << 1);
Uh, what?
Oh, I see, you adapted the VRC2A code. Yeah, this is the VRC2A chr banking, not the VRC4b-style banking used by GGG1.
Replace those parameters with
i>>4 ;
i;
j>>4;
j
OMIGOSH! IT WORKED!!
The Program ROM is a bit off, but it's yielding a working ROM! What's more, I needed this so I could test a translation patch for the game (for someone else...). So fyi, that should be ready soon if anyone is interested!
Thank you
so much, tepples, lidnariq, and rainwarrior! Is there a master list of anago scripts to which I can contribute the script that successfully dumped the game? Should I contact Arantius so he can add it to his github or something?
EDIT:
Okay, so the patch doesn't seem to like the slightly off ROM too much and some of the text sprites are in very weird places. What would I need to change in the script to get a perfect dump of the ROM?
The results that the script yields are as follows:
Code:
Program ROM: size 0x040000, crc32 0x825cba9e
Charcter ROM: size 0x040000, crc32 0x99a563fe
I guess you could join GitHub, fork the project, add your script, and submit a pull request.
I wanna make sure I get a clean copy of the ROM first, though. According to Bootgod's database, the CPU of the dump I got is slightly off
Code:
Program ROM: size 0x040000, crc32 0x825cba9e
VS
0x8360FA88
What can I change in the code to fix that?
You don't directly change the code to make the CRC match. The CRC is just a signature of the data you dumped.
If the dump for Bootgod was different at all from your cartridge, the CRC will be different.
If you incorrectly dumped, then there is something you might change in the code, but your goal should be getting an accurate dump of your cart, not matching a CRC. Can you run the dumped ROM in an emulator?
If you have a copy of the dump Bootgod used downloaded from somewhere (GoodNES set or something?), you can also use some binary compare tool to check that ROM against yours to see what's different, which could give a better idea of whether your dump is correct or not.
rainwarrior wrote:
You don't directly change the code to make the CRC match. The CRC is just a signature of the data you dumped.
If the dump for Bootgod was different at all from your cartridge, the CRC will be different.
If you incorrectly dumped, then there is something you might change in the code, but your goal should be getting an accurate dump of your cart, not matching a CRC. Can you run the dumped ROM in an emulator?
It only runs in FCEUX. I've tried it in NEStopia and in NESticle as well, but the former declares a CPU jam and the latter doesn't display anything. I'm not sure why it runs in one and not the others. What should I change in the code?
werewolfslayr925 wrote:
rainwarrior wrote:
You don't directly change the code to make the CRC match. The CRC is just a signature of the data you dumped.
If the dump for Bootgod was different at all from your cartridge, the CRC will be different.
If you incorrectly dumped, then there is something you might change in the code, but your goal should be getting an accurate dump of your cart, not matching a CRC. Can you run the dumped ROM in an emulator?
It only runs in FCEUX. I've tried it in NEStopia and in NESticle as well, but the former declares a CPU jam and the latter doesn't display anything. I'm not sure why it runs in one and not the others. What should I change in the code?
pm send me you dumped data.
werewolfslayr925 that script for VRC7 should work for lagrange point. I used it but with x4 to get 512k, otherwise it was just 256k
To anyone who struggles with Kazzo cart's programming problems- please keep in mind that due to programming sequence, some carts can be programmed ONLY by using AM29F040B. Even though some other chips are supported like W29C020, W49F002U, I personally don't recommend any of them. It most probably has to do with memory sectors, while others are manufactured completely random, AM29F040B is divided into sectors 64KB each and it seems the best for Kazzo. While I could absolutely do NOTHING to make UNROM cart to work, AM29F040B finally did the job. Please note when you have any Kazzo programming errors, you should make sure that you use AM29F040B first
Does anybody have a working script for SEROM? The ones online don't work and trying to merge the PRG and CHR from different scripts just give me messed up textures.
EDIT: Nevermind, I managed to make a working one.
Does anyone know how exactly to dump a US copy of RC Pro-Am? I feel like I've tried every single thing conceivably possible to do with my cartridge. I've opened it up and cleaned it, I've turn it forward and backward inside the Kazzo's 72-pin slot, I've tried serom.ad, mmc1_slrom.ad, mmc1_slrom.af, mmc1_surom.af, I've tried typing d2 or d6 instead of just d when using the command line version of anago, etc. I have absolutely no idea what else to do. This game just does not want to dump a working ROM for me. Every single time I try to dump it, it just says "CPU Jam!" in NEStopia. ugh.
Are you sure your copy uses MMC1? There are two revisions out there, one with AxROM, the other with MMC1.
thefox wrote:
Are you sure your copy uses MMC1? There are two revisions out there, one with AxROM, the other with MMC1.
Mine says "REV-A" on the back.
X-pert74 wrote:
Mine says "REV-A" on the back.
"REV-A" is the revision of that sticker on that back of the cartridge, it doesn't actually refer to game contents.
You have to open the cart and look at the board to get any information about the actual game's revision/hardware. (Alternatively you can dump it and speculate based on the dump. Like if you try an AxROM dump and it works, it's probably AxROM.)
Apparently in this case you can also tell by the text when you pause the game:
https://tcrf.net/R.C._Pro-Am
rainwarrior wrote:
X-pert74 wrote:
Mine says "REV-A" on the back.
"REV-A" is the revision of that sticker on that back of the cartridge, it doesn't actually refer to game contents.
You have to open the cart and look at the board to get any information about the actual game's revision/hardware. (Alternatively you can dump it and speculate based on the dump. Like if you try an AxROM dump and it works, it's probably AxROM.)
Apparently in this case you can also tell by the text when you pause the game:
https://tcrf.net/R.C._Pro-AmHmm, okay then. I opened up my copy, and the top left of the board says "NES-ANIROM-01 CHR-ROM". So... I tried typing
anago d2 anrom.ad "RC Pro-Am.nes"... and it worked! Thank you for the help
It's nice to finally get this working, after like a hundred failed dumps.
Wanted to take a min to update my progress on rewriting the kazzo host app and firmware. I've made some decent progress on the goals I set for myself in
this post last Nov.
The biggest 'news' is that I'm officially planning to retire from the atmega164 and bit banged V-usb hardware. I've only got a couple month's supply of the current atmega164 boards on hand and once those are gone, I don't plan on making any more of them. I'm not abandoning them completely though, software updates will continue to support all devices I've shipped to date. I've decided to migrate to the stm32f070 with hardware USB 2.0 Full speed (12Mbps). This new hardware design is not compatible with the original unagi/anago firmware/software. Because of this, I can't actually release the new hardware design until the software makes it at least as capable as current kazzo including the original anago/unagi for dumping purposes, and my current release for flash board programming. So the heat is on for me to finally release my new software/firmware build, in my mind I must release it prior to running out of original kazzo board inventory.
Here's the primary goals of my upcoming release:
-compatible on all previous, current, and planned future hardware designs I've released.
-compatible on windows, mac, and linux
-host scripts to allow adding support for new mappers without need to compile anything.
-host app/scripts are hardware agnostic providing the hardware is physically capable of the task.
-device firmware as hardware/core agnostic as much as possible, at least while the AVR still has rom available.
-all software open sourced
I made lots of strong progress on my rewrite over Nov/Dec of last year, and got to the point where my new build was able to flash and dump NES NROM carts. Once I got to that point I really stumbled on how to implement script support. 100% of the host software (and AVR firmware) was written in C. Aside from personal preference, I chose C because it allowed me to share header files with both the device firmware and host software. C also helped gain compatibility with most OS's along with libusb drivers. But I got pretty hung up when it take time to implement my own scripting engine.
Around the same time I was struggling with scripts, I stumbled upon the beauty that is the stm32 mcu lineup and I fell in love. It became obvious that it was time for me to retire bitbanged V-usb on an 8bit AVR hardware design. I drafted up a new prototype over the spring, and have been making steady progress on the new software over the past month.
Thanks to the
excellent discussion on Lua recently, I opened my mind to using something besides C written almost entirely by myself. I was sold once I realized that the Lua interpreter is actually running in C, and allows me to stick with my cross platform goals. I'm now at the point where all the host app C code I wrote last winter is ported over to Lua. Nearly the entire host application runs in Lua. I've got one low level function that's written in C to interface between Lua and libusb drivers. The executable/main is also still in C, but doesn't do much other than connect to the USB device and pass command line arguments over to Lua. I'm very pleased with Lua, it's quite the perfect match for this project IMO.
It took a solid 2 weeks of effort to get the
low level USB drivers written for the stm32 device. I tried to tinker with some of the cortex mcu software interface standard (CMSIS), and hardware abstraction layer code, but things quickly bloated and the number of function calls needed to toggle a mcu pin quickly became absurd. I'm sure I was probably doing something wrong, but I can't stand IDE's and the driver code was a tangled mess. I opted for writing everything from scratch
starting with my own on baremetal. I struggled in the beginning, but it forced me to become more familiar with the hardware which paid off in the end as it always does..
I'm currently at the point where I've many of of the big ticket goals prior to releasing the software into the wild. I'm about to start working on mapper/memory detection logic, so I can call mapper specific scripts. With that I'll be able to beta release a commandline version on most OS's. Then I'll focus on a gui, currently have my sights set on
wxLua.
Once I've got that released I'll start focusing more on the new hardware release. Getting kind of long winded already, so I'll just tease with some eye candy and follow up with details depending on interest. I haven't fully decided what to call the new hardware, don't think I'll keep with the kazzo name as it's no longer compatible with the original kazzo project. I've named my new software release INLretro, currently thinking the hardware will carry a similar name..
Does anybody know why I can't write 128K .bin files to my SUROM board?
I can flash 256K and 512K ROMs just fine, but 128K files just don't want to work.
SUROM is 512KB PRG-ROM. You shouldn't be writing anything smaller than 512KByte to it. If you quadruple up your 128KB image to 512KByte and fill the chip it'll probably work.
Is there a way to use the Kazzo to dump Akumajou Densetsu? I cannot find a script for VRC6a. I placed a support ticket on the website for InfiniteNESLives, and I was sent a link to a VRC6a script modified from the VRC6b script. Unfortunately, whenever I try to dump the game, I get this error message that is similar whether I use the VRC6a script or VRC6b script. I have included the error message at the bottom. What can I do to dump this game? I apologize if I am posting in the wrong place; I am new here.
m_database not found
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] 26
[script] "vrc6a.af"
[d] USERPOINTER
[this] TABLE
RPGMaster57 wrote:
AN ERROR HAS OCCURED [the index 'ppu_rom' does not exist
That error implies the section that looks like this:
board <- {
mappernum = 0,
cpu_rom = {
size_base = 0x8000, size_max = 0x8000
banksize = 0x8000
},
ppu_rom= {
size_base = 0x8000, size_max = 0x2000,
banksize = 0x2000
},
ppu_ramfind = false, vram_mirrorfind = true
}; isn't present in this exact form. (Numbers are allowed to vary; words are not)
The current syntax in the release of vrc6b on the unagi svn repository looks like
Code:
board <- {
mappernum = 26, vram_mirrorfind = false,
cpu = {banksize = 0x4000, maxsize = 2 * mega},
ppu = {banksize = 0x0400, maxsize = 2 * mega},
}
, so maybe that's the problem.
Thank-you for the information. So do I just paste this information into the old file in the place of the previous section in something like Notepad? I have tried this and it does not seem to work. I'm not a programmer by any means, so I'm not really sure what to do. Is there a properly working script that I could use?
When it "does not seem to work", what error message or other misbehavior appears?
When I try to dump the cartridge using the VRC6a or VRC6b scripts, I either get a message like the one in my previous post or one like this.
m_database not found
AN ERROR HAS OCCURED [expected 'IDENTIFIER']
CALLSTACK
*FUNCTION [dump()] dumpcore.nut line [15]
LOCALS
[increase_ppu] 1
[increase_cpu] 11
[mappernum] -1
[script] "vrc6a.af"
[d] USERPOINTER
[this] TABLE
I am trying to modify the script with no success. I know that I am probably doing something wrong. This is my attempt to change the file.
/*VRC6 type B/351949A/address bus A0=R1, A1=R0
CPU memory bank
cpu address|rom address |page|task
$8000-$bfff|n * 0x4000 |even|write area + write 0x2aaa
$c000-$dfff|0x04000-0x05fff|2 |write 0x5555
-------------------------------------
$8000-$bfff|n * 0x4000 |odd |write area + write 0x5555
$c000-$dfff|0x02000-0x03fff|1 |write 0x2aaa
$e000-$efff|末尾 |fix |boot area, 未使用
PPU memory bank
ppu address|rom address |page|task
$0000-$03ff|0x02800-0x02bff|0x0a|write (0x2aaa & 0x03ff) + 0
$0400-$07ff|0x05400-0x057ff|0x15|write (0x5555 & 0x03ff) + 0x400
$1000-$1fff|n * 0x1000 |n |write area*/
board <- {
mappernum = 0,
cpu_rom = {
size_base = 0x8000, size_max = 0x8000
banksize = 0x8000
},
ppu_rom= {
size_base = 0x8000, size_max = 0x2000,
banksize = 0x2000
},
ppu_ramfind = false, vram_mirrorfind = true
};,
}
function cpubank_even_set(d, bank, cpu_banksize)
{
cpu_command(d, 0x2aaa, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0xc000, 0x2000);
cpu_write(d, 0x8000, bank)
cpu_write(d, 0xc000, 2)
}
function initalize(d, cpu_banksize, ppu_banksize)
{
cpubank_even_set(d, 0, cpu_banksize);
cpu_command(d, 0, 0x8000, cpu_banksize);
ppu_command(d, 0x2aaa, 0, ppu_banksize);
ppu_command(d, 0x5555, 0x0400, ppu_banksize);
ppu_command(d, 0, 0x0800, ppu_banksize);
cpu_write(d, 0xb003, 0); //work ram disable
cpu_write(d, 0xd000, 0x0a);
cpu_write(d, 0xd001, 0x15);
cpu_write(d, 0xd002, 0x00);
cpu_write(d, 0xd003, 0x00);
}
function cpu_transfer(d, start, end, cpu_banksize)
{
local i;
for(i = start; i < end - 2; i += 2){
cpubank_even_set(d, i, cpu_banksize);
cpu_program(d, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0x8000, cpu_banksize);
cpu_command(d, 0x2aaa, 0xc000, 0x2000);
cpu_write(d, 0x8000, i | 1)
cpu_write(d, 0xc000, 1)
cpu_program(d, 0x8000, cpu_banksize);
}
cpubank_even_set(d, i, cpu_banksize);
cpu_program(d, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0x8000, cpu_banksize);
cpu_command(d, 0x2aaa, 0xc000, 0x2000);
cpu_write(d, 0x8000, i | 1)
cpu_write(d, 0xc000, 1)
cpu_program(d, 0x8000, cpu_banksize);
}
function ppu_transfer(d, start, end, ppu_banksize)
{
for(local i = start; i < end; i += 4){
cpu_write(d, 0xe000, i | 0);
cpu_write(d, 0xe001, i | 1);
cpu_write(d, 0xe002, i | 2);
cpu_write(d, 0xe003, i | 3);
ppu_program(d, 0x1000, ppu_banksize * 4);
}
}
Have you tried the version I sent with the commandline build instead of the gui?
I did try that. I got the following error.
vrc6a.af line = (17) column = (2) : error expected 'IDENTIFIER'
vrc6a.af open error
I have tried dumping another game with the command line version, and it worked, so I don't know what's up.
I got my Kazzo a few days back and it works great I've dumped several Famicom games Successfully already, Such as Goonies 2 UNROM, Youkai Douchuuki Namcot Mapper 19 that was a though one to figure out. But I've tried every script I could find trying to Dump the one Sunsoft Game I have Atlantis no Nazo For Famicom and I think it should dump as CNROM as it exist on Mapper 3 as well as Mapper 184, none the Sunsoft scripts work, the game has only 32kb Prg Rom and is suppose to have 16kb Chr Rom as far as I know, when I dump it using the CNROM script I can not get it to double the Chr Rom from 8kb to 16 kb and any other Script I think may be compatible will dump a working 32kb prg rom but gives it only 8kb of chr and I can't double the chr when dumping I even tried the windows version after I learned how to use it all my dumps still come out with only 8kb of Chr Rom.
So I have about 12 different working dumps that have 8kb of chr rom and the graphics just are grabled but they all seem to play fine but I tried splitting them apart and then joining the PRG with the 16kb CHR from a Actual Dump but my dumps still come out with garbled graphics.
So Hoped maybe someone had a fix for dumping Atlantis no Nazo Correctly.
other than that I love my Kazzo..
A unrelated to Dumping question I had is has anyone ever attempted or considered turning a Kazzo Dumper into a Console or would such a thing be possible not that I'm very skilled I just have some strange thoughts sometimes. lol
Zoldark wrote:
So Hoped maybe someone had a fix for dumping Atlantis no Nazo Correctly.
Atlantis no Nazo is one of a very short list of mapper 184 games, using the Sunsoft-1 IC.
Just trying something super quick:
Code:
board <- {
mappernum = 184,
cpu_rom = {
size_base = 0x8000, size_max = 0x8000
banksize = 0x8000
},
ppu_rom= {
size_base = 0x8000, size_max = 0x8000,
banksize = 0x1000
},
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);
ppu_read(d, 0, banksize);
}
}
No promises, can't test.
Quote:
has anyone ever attempted or considered turning a Kazzo Dumper into a Console
Try looking up both the "Retrode" and the "Retron 5".
lidnariq wrote:
Zoldark wrote:
So Hoped maybe someone had a fix for dumping Atlantis no Nazo Correctly.
Atlantis no Nazo is one of a very short list of mapper 184 games, using the Sunsoft-1 IC.
Just trying something super quick:
Code:
board <- {
mappernum = 184,
cpu_rom = {
size_base = 0x8000, size_max = 0x8000
banksize = 0x8000
},
ppu_rom= {
size_base = 0x8000, size_max = 0x8000,
banksize = 0x1000
},
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);
ppu_read(d, 0, banksize);
}
}
No promises, can't test.
Quote:
has anyone ever attempted or considered turning a Kazzo Dumper into a Console
Try looking up both the "Retrode" and the "Retron 5".
awesome that did the trick for Atlantis no Nazo once I figured out what format to put the script in dumped my Game and it came out clean with the 32kb Prg and 16kb Chr and Works like it should. Thank you..
Here is the script as a file I uploaded it on my dropbox for convenience
https://dl.dropboxusercontent.com/s/ataxyadgl8hih5p/Sunsoft-1IC.ae I had heard of the Retron5 they claim it can play all Castlevania Games or something but I never cared for those, I own the dreaded Retron3 that doesn't or well won't play Famicom games, lucky I have a Game fillip "Nes On A Chip" "Famicom Clone" it doesn't play Namcot Mapper 19 Games and I own two of those Hydlide 3, and Youkai Douchuuki , I'm really not a fan of Consoles that are like Emulators on a chip "Nes Classic, Snes Classic, Etc" but I liked the Nes on A Chip Concept and Real Hardware Clones.
Anyone have any scripts for Famicom Multicarts I have a few like I have two different CoolBoy Carts 400in1 real game and 198in1 real game and I have another 132in1 or 150in1 on it's way from China I'm not sure yet what exactly it is. I haven't tried dumping them or took them apart for pictures yet. I'm not really concerned about dumping my Multi-carts, as I am for my normal games I have like 69+ different Famicom Games so far I have successfully dumped 10 of them not included Atlantis no Nazo but I'm bound to run into more problems. lol..
Right Now my trouble is with Dumping Operation Wolf for The NES it's a Taito game I tried the Taito scripts to no avail and all MMC1 Scripts and none will dump anything that works. Looking at the database my game is different than this one
http://bootgod.dyndns.org:7777/image.php?ImageID=3222 my board says NES-SL1ROM -01 U4MMC1 and the board is even shaped different and mine has the date of 1988 not 1987. My game
https://dl.dropboxusercontent.com/s/hbhnlvwuurjqw5v/OPWOLF1.png I am sorry for jumping the gun and uploading that script with out asking, I thought others might need it too though.. All the Best..
Sorry to double post but I was looking at the SNES Hi/Lo-ROM reproduction flash boards, and wondering can you program a NES Game to work on the SNES didn't Nintendo do that for some games as re-release from the Nes to Super I had thought I saw some games before somewhere but I can't remember where I tried looking but I know they did it for the Gameboy Advance.
Has anyone ever made a Case for the Kazzo Dumper I'm not very skilled at making such enclosures, although I did see some images where people had put peg legs on theirs I might try that. lol
And I found out I have the one Famicom Game "Senjou no Ookami" that Uses Mapper 94 which is similar to UNROM used by the US released Commando, I tried dumping it as such but it doesn't work on Mapper 2, I got it to dump using the _bnrom512.ad script it came out clean but is a huge over dump gave it 1024kb of prg rom instead of the normal 128kb that the game uses. If I knew how to reduce the size in the script or the command line BNROM Mapper 34 probably would work it is a clean dump as far as I can tell but it is just way big..
https://wiki.nesdev.com/w/index.php/INES_Mapper_094https://wiki.nesdev.com/w/index.php/INES_Mapper_034I still haven't found any solution for my Operation Wolf Game, however I found NesDev had another Kazzo Script for Mapper 81,
https://wiki.nesdev.com/w/index.php/INES_Mapper_081 http://forums.nesdev.com/viewtopic.php?f=3&t=16412
Zoldark wrote:
can you program a NES Game to work on the SNES didn't Nintendo do that for some games as re-release from the Nes to Super
Porting a game from NES to Super NES isn't too difficult. See, for example, how much code Nintendo reused from the original games to
Super Mario All-Stars. But it's usually not an automatic conversion (with
exceptions). And people who buy the Super NES version of a game you developed will expect Super NES graphics, not NES graphics.
Zoldark wrote:
I had thought I saw some games before somewhere but I can't remember where I tried looking but I know they did it for the Gameboy Advance.
The GBA's CPU is clocked nearly ten times as fast as that of the NES. The Classic NES Series for Game Boy Advance uses an emulator, presumably the same one used in
Animal Crossing Advance Play and the e-Reader.
Also have you heard of question marks?
tepples wrote:
Zoldark wrote:
can you program a NES Game to work on the SNES didn't Nintendo do that for some games as re-release from the Nes to Super
Porting a game from NES to Super NES isn't too difficult. See, for example, how much code Nintendo reused from the original games to
Super Mario All-Stars. But it's usually not an automatic conversion (with
exceptions). And people who buy the Super NES version of a game you developed will expect Super NES graphics, not NES graphics.
Zoldark wrote:
I had thought I saw some games before somewhere but I can't remember where I tried looking but I know they did it for the Gameboy Advance.
The GBA's CPU is clocked nearly ten times as fast as that of the NES. The Classic NES Series for Game Boy Advance uses an emulator, presumably the same one used in
Animal Crossing Advance Play and the e-Reader.
Also have you heard of question marks?
Yep I forgot to use question marks, I get carried away a lot, overly excited. Dumping my own games is like a life long dream of mine come true.
I hadn't thought of Selling Nes Games on a Super Nes, I just was wondering if it were possible cause I own a Retron3 that will not play Famicom Games with a converter, so thought maybe one could program a SNES Board with some NesCode for your own use, of course I should consider getting a RetroPort
https://www.estarland.com/product-description/SuperNintendo/RetroPORT-Play-NES-on-SNES-Adapter/40453 that Plays Nes Games on Snes Hardware and trying it with My Famicom Convertor but IDK if it will work with the Retron3 or not.
Back to Mappers I had this one game yesterday that did not even work in a Emulator yesterday and it like just Magically Start working, Kyuukyoku Harikiri Koushien and on a Different Mapper than it had yesterday I got go try to re-dump right now before it changes it's mind. Sorry. Thanks for the Info. Later.
Zoldark wrote:
"Senjou no Ookami" that Uses Mapper 94
Try this:
Code:
board <- {
mappernum = 94, vram_mirrorfind = true, ppu_ramfind = false,
cpu_rom = {
size_base = 0x20000, size_max = 0x20000,
banksize = 0x4000
},
ppu_rom = {
size_base = 0, size_max = 0,
banksize = 0x2000
}
};
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize - 1; i += 1){
cpu_write(d, 0x8000, i << 2);
cpu_read(d, 0x8000, banksize);
}
cpu_read(d, 0xc000, banksize);
}
Quote:
Operation Wolf
I guess
Werrock's script was never posted in its entirety.
Try this:
Code:
board <- {
mappernum = 36, vram_mirrorfind = true, ppu_ramfind = false,
cpu_rom = {
size_base = 0x8000, size_max = 0x20000,
banksize = 0x8000
},
ppu_rom = {
size_base = 0x2000, size_max = 0x20000,
banksize = 0x2000
}
};
function cpu_dump(d, pagesize, banksize)
{
cpu_write(d, 0x4101, 0);
cpu_write(d, 0x4103, 0);
for(local i = 0; i < pagesize; i += 1){
cpu_write(d, 0x4102, i << 4);
cpu_write(d, 0x4100, 0);
cpu_write(d, 0xffff, 0);
cpu_read(d, 0x8000, banksize);
}
}
function ppu_dump(d, pagesize, banksize)
{
for (local i = 0; i < pagesize; i += 1){
cpu_write(d, 0x4200, i);
ppu_read(d, 0, banksize);
}
}
lidnariq wrote:
Zoldark wrote:
"Senjou no Ookami" that Uses Mapper 94
Quote:
Operation Wolf
I guess
Werrock's script was never posted in its entirety.
Thank you that first code worked for Senjou no Ookami, but for some reason I can't get the Operation Wolf one to work for my cart I don't know if I'm formatting the script right or what.. I tried AD AE and AG.. It's likely something that I'm not doing correctly I'm about as sleepless as Molasses in January I'm going sleep on it. I do appreciate the help, thank you..
On Another Note I modified a existing script to Dump My Famicom Baseball Game I mentioned earlier Kyuukyoku Harikiri Koushien it's a Tatio Game and uses Mapper 82 though I could swore the other day it was using mapper 84, I modified the Taito X1-005 Script changed it over to mapper 82 and Increased the Chr Rom to have the correct amount the game uses which is 256kb, with a 128kb prg. My Code Dumps the game and it loads the title screen like is a good dump but then after that goes wild and doesn't work, so well I don't know what else should be fixed in the script.
To note this is a game that the first time it loads you'll think it doesn't work, but reload it again in an emulator and it does is very weird even my dump did the same thing it doesn't work at all the first time you load it. Is how I got Confused the other day..
here is the Code I have so far for Kyuukyoku Harikiri Koushien
Code:
/*
Taito X1-005
TFC-FM-5900 不動明王伝のみ Program ROM size は 2M
save RAM が存在するがアクセス方法は不明
*/
board <- {
mappernum = 82, ppu_ramfind = false, vram_mirrorfind = false,
cpu_rom = {
size_base = 1 * mega, size_max = 2 * mega,
banksize = 0x2000
},
ppu_rom = {
size_base = 2 * mega, size_max = 4 * mega,
banksize = 0x2000 / 8 //0x0800*2 + 0x0400 * 4
}
};
function cpu_dump(d, pagesize, banksize)
{
local i;
for(i = 0; i < pagesize - 2; i += 2){
cpu_write(d, 0x7efa, i);
cpu_write(d, 0x7efc, i | 1);
cpu_read(d, 0x8000, banksize * 2);
}
cpu_write(d, 0x7efe, i);
cpu_read(d, 0xc000, banksize * 2);
}
function ppu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i += 8){
local ar = [i, i|2, i|4, i|5, i|6, i|7];
cpu_write(d, 0x7ef0, ar);
ppu_read(d, 0x0000, banksize * 8);
}
}
That will dump the game with the correct sizes and mapper but is not a good working dump that or my cart is dirty or something, IDK it looks clean as heck and was hardly ever used cause it's Baseball, is like brand new really, but I will try bushing it up, later.
Re: Strike Wolf—how big is your resulting NES file?
Zoldark wrote:
Code:
cpu_write(d, 0x7efa, i);
cpu_write(d, 0x7efc, i | 1);
That's not how mapper 82 (which uses Taito's X1-017 IC) works, that's how mapper 80 (X1-005) works.
https://wiki.nesdev.com/w/index.php/INES_Mapper_082
lidnariq wrote:
Re: Strike Wolf—how big is your resulting NES file?
Zoldark wrote:
Code:
cpu_write(d, 0x7efa, i);
cpu_write(d, 0x7efc, i | 1);
That's not how mapper 82 (which uses Taito's X1-017 IC) works, that's how mapper 80 (X1-005) works.
https://wiki.nesdev.com/w/index.php/INES_Mapper_082For Operation Wolf the Code wouldn't dump My Game at all, it gives an error.
Code:
length range must be 0x000000 to 0x004000
AN ERROR HAS OCCURED [script logical error]
CALLSTACK
*FUNCTION [cpu_dump()] wolf.ag line [21]
*FUNCTION [dump()] dumpcore.nut line [43]
LOCALS
[i] 0
[banksize] 32768
[pagesize] 1
[d] USERPOINTER
[this] TABLE
[ppu_dumpsize] 8192
[cpu_dumpsize] 32768
[ppuarea_memory] 0
[vram] 1
[increase_ppu] 1
[increase_cpu] 1
[mappernum] 36
[script] "wolf.ag"
[d] USERPOINTER
[this] TABLE
As For the Mapper 82 Game that is correct "Although I had thought they worked the same" but I just had Manipulated the existing Mapper 80 Script forcing it to try and act as Mapper 82 but the result is it just doesn't work I was really starting to think there was something wrong with my game, as I don't have a script for Mapper 82 and I don't yet understand enough of how you actually write a script and I don't understand registers and all that stuff I barely figured out what was chr rom in the script. lol
I did Try Dumping it as normal Mapper 80 with the same script but the resulting dump wouldn't work at all Dumping it as mapper 82 it came out acting as though it would work but after the title screen it goes bad. This of all Famicom Baseball games had to be the one I bought.
Zoldark wrote:
For Operation Wolf the Code wouldn't dump My Game at all, it gives an error.
Oh derp. I forgot that.
Change
cpu_read(d, 0x8000, banksize);to
Code:
cpu_read(d, 0x8000, 0x4000);
cpu_read(d, 0xc000, 0x4000);
Quote:
Manipulated the existing Mapper 80 Script forcing it to try and act as Mapper 82 but the result is it just doesn't work
Mapper 82 and mapper 80 aren't the same! Both ICs are made by Taito, and
CHR banking works the same on both, but that's it.
In Mapper 80, the PRG banking registers are at 0x7EFA, 0x7EFC, and 0x7EFE. In Mapper 82, they're at 0x7EFA, 0x7EFB, and 0x7EFC. If you change the former to the latter, that ... should? be sufficient.
lidnariq wrote:
Zoldark wrote:
For Operation Wolf the Code wouldn't dump My Game at all, it gives an error.
Oh derp. I forgot that.
Change
cpu_read(d, 0x8000, banksize);to
Code:
cpu_read(d, 0x8000, 0x4000);
cpu_read(d, 0xc000, 0x4000);
Quote:
Manipulated the existing Mapper 80 Script forcing it to try and act as Mapper 82 but the result is it just doesn't work
Mapper 82 and mapper 80 aren't the same! Both ICs are made by Taito, and
CHR banking works the same on both, but that's it.
In Mapper 80, the PRG banking registers are at 0x7EFA, 0x7EFC, and 0x7EFE. In Mapper 82, they're at 0x7EFA, 0x7EFB, and 0x7EFC. If you change the former to the latter, that ... should? be sufficient.
That Fixed the Script as far as dumping is concerned but that is where I got confused that is not the same game I have I was trying to dump my Nintendo Game "Operation Wolf: Take no Prisoners" the US Release
http://bootgod.dyndns.org:7777/profile.php?id=180 just my chip is a bit different than what they have posted plus looks like I need to Clean it, I did not even know there was a game known as Strike Wolf, I'm sorry I had thought when you said Strike Wolf that it was a mistake.
https://dl.dropboxusercontent.com/s/hbhnlvwuurjqw5v/OPWOLF1.pngI only have like 4 actual Nintendo Games, as for that Mapper 82 game. How would one go about changing the PRG Banking registers?
On another note I was dumping My Famicom Game Family Boxing that is suppose to use Mapper 4 but I was looking at the existing dumps of Ring King and the Japan Version Family Boxing existed using horizontal mirroring so that is how it came out on Mapper 4 but it just wasn't a clean Dump, so I Tried every Variant of MMC3 Script I could and at the last remembered it was a Namcot "Namco" game and dumped it using the Namcot 108 3433 Mapper 88 it came out perfect with 64kb Prg and 64kb Chr and Vertical Mirroring as clean as Ring King is on Mapper 4, so I think that Family Boxing really is one the 4 games that is really Mapper 88
https://wiki.nesdev.com/w/index.php/INES_Mapper_088. I did try it on Mapper 206 too but it comes out garbled and doesn't work. In all truth the database I was looking at was way out dated and was not Nesdev. lol
Zoldark wrote:
that is not the same game I have I was trying to dump my Nintendo Game "Operation Wolf: Take no Prisoners" the US Release
<facepalm> That's just SLROM? Use an SKROM script.
Quote:
I only have like 4 actual Nintendo Games, as for that Mapper 82 game. How would one go about changing the PRG Banking registers?
lidnariq wrote:
In Mapper 80, the PRG banking registers are at 0x7EFA, 0x7EFC, and 0x7EFE. In Mapper 82, they're at 0x7EFA, 0x7EFB, and 0x7EFC. If you change the former to the latter, that ... should? be sufficient.
lidnariq wrote:
Zoldark wrote:
that is not the same game I have I was trying to dump my Nintendo Game "Operation Wolf: Take no Prisoners" the US Release
<facepalm> That's just SLROM? Use an SKROM script.
Quote:
I only have like 4 actual Nintendo Games, as for that Mapper 82 game. How would one go about changing the PRG Banking registers?
lidnariq wrote:
In Mapper 80, the PRG banking registers are at 0x7EFA, 0x7EFC, and 0x7EFE. In Mapper 82, they're at 0x7EFA, 0x7EFB, and 0x7EFC. If you change the former to the latter, that ... should? be sufficient.
Yep that did the Trick I had similar trouble when I first tried dumping Captain Skyhawk for Nes I thought it was AOROM but the Script didn't work til I realized there was another Script _aorom.af ran that and it worked.
I have managed to Dump 22 different games with help Thank you, I am going take a break for awhile, and try to study up on what Mappers my other 51 games use. I hope I get lucky like with a lot mine so far that used either CNROM or just NROM. I do have about 10 or so Jaleco Games and about 7 or 8 Bandai games, but I dumped all my Namcot Games, all Irem, all Capcom, and 3 of my four Taito games just have that Mapper 82 Famicom Baseball Game left.
For Nes
Trojan
Captain Skyhawk
Operation Wolf
Super Mario / Duck Hunt / Track Meet
For Famicom
Family Boxing
Youkai Douchuuki
10 Yard Flight
Zippy Race
Super Mario Bros
Adventure Island
Tatakai no Banka "Famicom Trojan"
The Tower of Druaga
Taito Grand Prix - Eikou heno License "A Taito Mapper 80 Game"
Senjou no Ookami "Famicom Commando"
Gyrodine
Formation Z
Dough Boy
Atlantis no Nazo
Aigiina no Yogen
Goonies 2, The - Fratelli Saigo no Chousen
Transformers Mystery Of Comvoy
Xevious
I did change out the registers for that Mapper 80 Script with what should be for Mapper 82 at least as best I could tell and re-dumped my game but it came out about the same with only a slight difference Shows the title screen like every thing is fine then goes wacko..
Zoldark wrote:
I did change out the registers for that Mapper 80 Script with what should be for Mapper 82 at least as best I could tell and re-dumped my game but it came out about the same with only a slight difference Shows the title screen like every thing is fine then goes wacko.
Is the dump you create 384 KiB in size?
Do the PRG and CHR checksums agree with the record in
NesCartDB ?
lidnariq wrote:
Zoldark wrote:
I did change out the registers for that Mapper 80 Script with what should be for Mapper 82 at least as best I could tell and re-dumped my game but it came out about the same with only a slight difference Shows the title screen like every thing is fine then goes wacko.
Is the dump you create 384 KiB in size?
Do the PRG and CHR checksums agree with the record in
NesCartDB ?
yes the dump comes out as 384kb in size.
However I just noticed that the CHR Checksum is correct but the PRG Checksum is not.
For My Dump
PRG 128kb CRC32 F5B15BAF
CHR 256kb CRC32 63CA0132
The Data Base
PRG0 D23-01 128 KB 265167E1
CHR0 D23-02 256 KB 63CA0132
So it seems my CHR part is correct but the PRG is dumping wrong. I just took My CHR and Joined it together with the PRG from an existing good dump, and the resulting Game came out like it should so the script just is not dumping the PRG correctly or the game I have is damaged but it plays fine in my Famicom Clone..
Is there anyway to fix a PRG CRC32?
Another question I have is. Can you erase your own NES or Famicom game boards? and then reprogram them? I realized that it was a stupid question they are not flash boards, the reason I asked is I was considering getting CNROM, NROM, and possibly a UNROM as those games are the easiest to get working, but also I would love to get a Famicom Flash Board or two. Does such a thing exist?
Well, yes, that means you got a bad PRG dump. You can only use the CRC32 as an indicator, not instructions for what to fix.
Why don't you post here (or PM me) the not-working dumper script you tried?
lidnariq wrote:
Well, yes, that means you got a bad PRG dump. You can only use the CRC32 as an indicator, not instructions for what to fix.
Why don't you post here (or PM me) the not-working dumper script you tried?
Code:
/*
Taito X1-005
TFC-FM-5900 不動明王伝のみ Program ROM size は 2M
save RAM が存在するがアクセス方法は不明
*/
board <- {
mappernum = 82, ppu_ramfind = false, vram_mirrorfind = false,
cpu_rom = {
size_base = 1 * mega, size_max = 2 * mega,
banksize = 0x2000
},
ppu_rom = {
size_base = 2 * mega, size_max = 4 * mega,
banksize = 0x2000 / 8 //0x0800*2 + 0x0400 * 4
}
};
function cpu_dump(d, pagesize, banksize)
{
local i;
for(i = 0; i < pagesize - 2; i += 2){
cpu_write(d, 0x7efa, i);
cpu_write(d, 0x7efc, i | 1);
cpu_read(d, 0x8000, banksize * 2);
}
cpu_write(d, 0x7efe, i);
cpu_read(d, 0xc000, banksize * 2);
}
function ppu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i += 8){
local ar = [i, i|2, i|4, i|5, i|6, i|7];
cpu_write(d, 0x7ef0, ar);
ppu_read(d, 0x0000, banksize * 8);
}
}
That is it but I have tried the same thing with the switched out PRG Banking Registers but still only the CHR comes out correct.
lidnariq wrote:
Zoldark wrote:
For Operation Wolf the Code wouldn't dump My Game at all, it gives an error.
Oh derp. I forgot that.
Change
cpu_read(d, 0x8000, banksize);to
Code:
cpu_read(d, 0x8000, 0x4000);
cpu_read(d, 0xc000, 0x4000);
Quote:
Manipulated the existing Mapper 80 Script forcing it to try and act as Mapper 82 but the result is it just doesn't work
Mapper 82 and mapper 80 aren't the same! Both ICs are made by Taito, and
CHR banking works the same on both, but that's it.
In Mapper 80, the PRG banking registers are at 0x7EFA, 0x7EFC, and 0x7EFE. In Mapper 82, they're at 0x7EFA, 0x7EFB, and 0x7EFC. If you change the former to the latter, that ... should? be sufficient.
Another trouble I have had is in the dumping of the Famicom Seicross Game, according to the database it's suppose to be NROM but when ever I try dumping it with any of the NROM Scripts the resulting dump doesn't work. How ever it does dump and work as CNROM but comes out with 32kb PRG and 32kb CHR with different checksum than what the database has
http://bootgod.dyndns.org:7777/profile.php?id=1703. Has anyone had a similar trouble with the Famicom Seicross or is there a fix?
Zoldark wrote:
That is it but I have tried the same thing with the switched out PRG Banking Registers but still only the CHR comes out correct.
There's nothing obviously wrong with that.
You could PM me the bad dump and maybe I'll be able to figure out what's going wrong.
Zoldark wrote:
Another trouble I have had is in the dumping of the Famicom game Seicross, according to the database it's suppose to be NROM but when ever I try dumping it with any of the NROM Scripts the resulting dump doesn't work. How ever it does dump and work as CNROM but comes out with 32kb PRG and 32kb CHR with different checksum than what the database has
http://bootgod.dyndns.org:7777/profile.php?id=1703. Has anyone had a similar trouble with the Famicom Seicross or is there a fix?
There were two releases of Seicross! One has
something pretending to be an anti-reproduction thing, but it's extremely
flimsy.
Unfortunately, this rerelease of Seicross is the one game that doesn't comply with the existing heuristic; FCEUX is currently hot-patching it to
mapper 181.
A CNROM dump should work fine.
lidnariq wrote:
Unfortunately, this rerelease of Seicross is the one game that doesn't comply with the existing heuristic; FCEUX is currently hot-patching it to mapper 181.
What's the current state of the
Mapper 185 Submapper proposal? I could not find a thread describing what still needs to be done to make this official.
Needs test ROMs, probably. I'd really rather formalize the latter version instead of the former.
Or codifying a different heuristic instead of submappers. I think that we could just get away with "writes to the bankswitching register toggle whether the CHR ROM is readable" but that'd need testing.
Just to clarify: does submapper 0 meaning "use heuristic" apply to any mapper, or just to Mapper 185?
Because the first proposal does not explicitly state that submapper 0 means "use heuristic", unless I misunderstand the "In the case that any of the bits are 'don't care', use 0." sentence. I understood the first proposal as implicitly stating No NES 2.0 Header->Use Heuristic, Have NES 2.0 Header->Use Submapper (blindly). That wpiöd force anyone who uses a NES 2.0 header to specify the correct submapper, but that is no more restrictive than requiring UNROM games to specify the 8K CHR-RAM in NES 2.0 headers.
Is it correct that the security diodes only matter for dumping, but not for emulation, which is the reason why the second proposal does not specify their configuration?
NewRisingSun wrote:
Just to clarify: does submapper 0 meaning "use heuristic" apply to any mapper, or just to Mapper 185?
Approximately, every mapper. Submapper 0 was decided to mean "compatibility with iNES 1 header" which in mapper 185's case means specifically "use heuristic", but a similar statement can be made about everything else.
You certainly can make the point that mapper 185 could be an exception.
Quote:
Is it correct that the security diodes only matter for dumping, but not for emulation, which is the reason why the second proposal does not specify their configuration?
Correct. It's perfectly possible to emulate mapper 185 dumps as though they were CNROM, by just having 1 or 3 banks of padding in the NES file's CHR ROM.
It's not clear that the latch + diode would necessarily win the fight over the PPU's output drivers, and so it's not clear what the result would do to the perceived CHR banks when the CHR ROM is enabled. I wouldn't be surprised if it turns out that it's the same wired-AND behavior of other things in the NES, and that any place where the diodes are configured to "require logic high" end up being a no-op.
lidnariq wrote:
It's perfectly possible to emulate mapper 185 dumps as though they were CNROM, by just having 1 or 3 banks of padding in the NES file's CHR ROM
Which, incidentially, is how Tecmo released Mighty Bomb Jack in the U.S. without removing the protection code.
I definitely prefer submappers over more a more elaborate heuristic. I suppose all the test ROM must do is detect the submapper number, and possibly whether the emulator is using the standard heuristic in the case of submapper 0?
NewRisingSun wrote:
Which, incidentally, is how Tecmo released Mighty Bomb Jack in the U.S. without removing the protection code.
Oh, neat.
Quote:
I definitely prefer submappers over more a more elaborate heuristic.
Does "count the number of times the latch has been written to and toggle readability" count as a more complex heuristic?
If it works, I'd prefer it.
Quote:
I suppose all the test ROM must do is detect the submapper number, and possibly whether the emulator is using the standard heuristic in the case of submapper 0?
Yeah, just saying "I wrote these four values, and CHR ROM only held the expected contents when the value was X which means this is submapper Y" should be adequate.
lidnariq wrote:
You could PM me the bad dump and maybe I'll be able to figure out what's going wrong.
Huh, weird.
The literal contents of that dump are
bank 0, bank 0, bank 0, bank 0
bank 1, bank 1, bank 1, bank 1
bank 2, bank 2, bank 2, bank 2
bank 3, bank 3, bank 3, bank 15
... derp. That's actually exactly what our documentation for mapper 82 says it does. Sorry!
Use these lines:
Code:
for(i = 0; i < pagesize - 2; i += 2){
cpu_write(d, 0x7efa, i << 2);
cpu_write(d, 0x7efc, (i | 1) << 2);
cpu_read(d, 0x8000, banksize * 2);
}
cpu_write(d, 0x7efe, i << 2);
Not clear what's going wrong, but you could try this?
cpu_write(d, 0x7efc, (i*4) + 4);
lidnariq wrote:
Not clear what's going wrong, but you could try this?
cpu_write(d, 0x7efc, (i*4) + 4);
That did the trick it didn't work at first but I went back and looked at one the early scripts switched out the PRG Banking Registers again and it worked perfect even the PRG Checksum is correct. Dumped it and the game works like it should. Thank you.. Awesome..
here is the working code..
Code:
/*
Taito X1-005
TFC-FM-5900 不動明王伝のみ Program ROM size は 2M
save RAM が存在するがアクセス方法は不明
*/
board <- {
mappernum = 82, ppu_ramfind = false, vram_mirrorfind = false,
cpu_rom = {
size_base = 1 * mega, size_max = 2 * mega,
banksize = 0x2000
},
ppu_rom = {
size_base = 2 * mega, size_max = 4 * mega,
banksize = 0x2000 / 8 //0x0800*2 + 0x0400 * 4
}
};
function cpu_dump(d, pagesize, banksize)
{
local i;
for(i = 0; i < pagesize - 2; i += 2){
cpu_write(d, 0x7efa, i << 2);
cpu_write(d, 0x7efb, (i*4) + 4);
cpu_read(d, 0x8000, banksize * 2);
}
cpu_write(d, 0x7efc, i << 2);
cpu_read(d, 0xc000, banksize * 2);
}
function ppu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i += 8){
local ar = [i, i|2, i|4, i|5, i|6, i|7];
cpu_write(d, 0x7ef0, ar);
ppu_read(d, 0x0000, banksize * 8);
}
}
Zoldark wrote:
cpu_write(d, 0x7efb, (i*4) + 4);
0x7EF
B ??
Oh derp. Of course.
I got to dumping some more games dumped about 20 of them with success, but wouldn't you know it I had trouble with yet another Baseball game.
This time it's the Nes Game Bases Loaded I think the problem is because it's MMC1 SFROM and SFROM is not like SKROM SEROM or SUROM and my version unlike the database isn't just SFROM it is SFEXPROM and has 3 big chips and reads MMC1A not MMC1B2.
Bases Loaded
http://bootgod.dyndns.org:7777/profile.php?id=627SxROM
https://wiki.nesdev.com/w/index.php/SxROMI did take and modify the SKROM script to make it dump the game with the correct sizes of 256kb PRG and 64kb CHR but the resulting dump doesn't work although it is the correct size of 320kb as both the PRG checksum and CHR checksum are incorrect. I did however take the same Modified Script and was able to correctly Dump, Bases Loaded II: Second Season that is SLROM and is more close to SKROM but wouldn't come out with the correct size of 384kb with the normal script. Worked fine with correct checksum.
Bases Loaded II: Second Season
http://bootgod.dyndns.org:7777/profile.php?id=14Here is My Modified SKROM Code
I just Increased the sizes of CPU_Rom and PPU_Rom
Code:
board <- {
mappernum = 1, vram_mirrorfind = false, ppu_ramfind = true,
cpu_rom = {
size_base = 2 * mega, size_max = 2 * mega,
banksize = 0x4000,
},
cpu_ram = {
size_base = 0x2000, size_max = 0x2000,
banksize = 0x2000
},
ppu_rom = {
size_base = 2 * mega, size_max = 2 * mega,
banksize = 0x1000,
I might should take a picture of my board as it is a bit different than the database but my Android is occupied at the moment. Actually I just re-dumped Bases Loaded and the CHR Checksum is correct but not the PRG Checksum. So is like before I guess, why do I have to get such strange games.. I'm sorry for having such troubles, I try to fix stuff myself but I end up still needing help.. All the best..
SFEXPROM is hilarious. Read this thread:
viewtopic.php?t=1371
lidnariq wrote:
That bad image of it is the same board I have for Bases Loaded everything matches. lol
it must be some sort Lock Out Chip.
As it has NES-LD-0 for the PRG then the other chip has NES-LD-0-EXP283 like it overrides or patches the PRG on start up.
Could you like cut it off or desolder it from the games board and have the game still work?
I may have to try getting another Cart of it and hope I get the MMC1B2 normal SFROM version. it's Bases Loaded, and baseball games are usually cheap.
I do have another complex board coming Roger Clemens' MVP Baseball but it's MMC3 MC-ACC but I've not had any trouble with MMC3 games most are compatible boards and I ordered the Mapper 79 F-15 City War, I'm hoping it dumps. Those are 2 the 6 more NES games I'm still waiting to receive. So far I've dumped 16 Nes games with success. I did only have 4 but I bought some more.. lol
Zoldark wrote:
[EXP283] must be some sort Lock Out Chip
Don't think so. You've read the thread. Like Kevtris concluded, I think the cost of getting a new run of Mask ROMs made must have been expensive enough that it was cheaper to get an IC that patches things than to make get an entirely new production run made.
Quote:
Could you like cut it off or desolder it from the games board and have the game still work?
No. Without the EXP283, you will get the same contents from the ROM that you get from the Kazzo; i.e. it won't work.
lidnariq wrote:
Zoldark wrote:
[EXP283] must be some sort Lock Out Chip
Don't think so. You've read the thread. Like Kevtris concluded, I think the cost of getting a new run of Mask ROMs made must have been expensive enough that it was cheaper to get an IC that patches things than to make get an entirely new production run made.
Quote:
Could you like cut it off or desolder it from the games board and have the game still work?
No. Without the EXP283, you will get the same contents from the ROM that you get from the Kazzo; i.e. it won't work.
yep, I miss took that part, it just patches or fixes the game to work or something, very weird.
I'll likely be buying some more games from estarland or somewhere and I might throw this one in there again when I do.
What to do with extra games or boards?
Actually I just got it on Ebay cost me 5 dollars but they showed the Board and it was a SFROM version I hope it dumps.
Just Realized I bought the Rev B version SF1ROM but it is more similar to SFROM then SFEXPROM with no patching of the PRG at start up. Cross Fingers that it doesn't give me trouble. SF1ROM is supposedly similar to SLROM-04 and that is more similar to SKROM or at least I hope so..
Got my New Bases Loaded Rev. B game, and Dumped it with my modified SKROM Script and it came out correct.
I was able to dump all my new games except I can't seem to dump F-15 City War, I read here
http://forums.nesdev.com/viewtopic.php?f=9&t=7912&start=405 and went back a few pages but I tried everything that was suggested and I just couldn't dump my game correctly when I do dump it, My dump comes out only with correct PRG as I can't get any script to dump it with more than 8kb of CHR it is suppose to have 32kb..
Did anyone come up with a sure fire way of dumping it? and what script do you use?
Please Help.
What publisher is your F15 City War cart from? There are relases by Idea-tek/TXC, AVE, and Gluk Video, with Idea-tek's original release being undumped. AVE should use Mapper 79, Gluk Video mapper 36 or 79, while Idea-tek's mapper is unknown but probably 136, which might be dumped with the Mapper136
a script linked
here.
NewRisingSun wrote:
What publisher is your F15 City War cart from? There are relases by Idea-tek/TXC, AVE, and Gluk Video, with Idea-tek's original release being undumped. AVE should use Mapper 79, Gluk Video mapper 36 or 79, while Idea-tek's mapper is unknown but probably 136, which might be dumped with the Mapper136
a script linked
here.
I think it is AVE, it has the same board as what is in the Database here
https://web.archive.org/web/20140408214540/http://bootgod.dyndns.org:7777/profile.php?id=965has AVE on one side and on the PRG Chip it has "Rev 11 2/19/92" I tried dumping it with the TXC_79 Script but it comes out with only 32 Kb PRG and 8kb CHR, the PRG has the correct checksum but it won't dump the CHR correctly.
No matter what I try I can't get it to Dump properly I just end up with a 40kb size dump and not 64kb.
What? Idea-Tek original release of F-15 is undumped? Let me help then. Will try the 136 script tomorrow.
Actually I Just was looking at my board Closer, and it is slightly different than the Database, for the CHR Chip.
My Board
https://www.dropbox.com/s/xywvg1h6zthmr49/Myboardf15cw.png?dl=0
The
txc_79 script that I have found on-line writes the CHR bank number to address $4200, which is not what the board expects
according to the nesdev wiki. The game writes to $4120 as well, not to $4200. Assuming your mapper 79 dumping script looks like the one I linked to, replace
Code:
cpu_write(d, 0x4200, i);
with
Code:
cpu_write(d, 0x4120, i);
and try again.
NewRisingSun wrote:
The
txc_79 script that I have found on-line writes the CHR bank number to address $4200, which is not what the board expects
according to the nesdev wiki. The game writes to $4120 as well, not to $4200. Assuming your mapper 79 dumping script looks like the one I linked to, replace
Code:
cpu_write(d, 0x4200, i);
with
Code:
cpu_write(d, 0x4120, i);
and try again.
Yep, that was it.. it dumped with the correct PRG Checksum and CHR Checksum.. Thank you...
I bought a few homebrew carts recently (Creepy Brawlers, City Trouble, Almost A Hero) but my kazzo is giving me an error when trying to dump them.
0x00e000/0x040000
libusb0-dll:err [control_msg] sending control message failed, win error: The I/O operation has been aborted because of either a thread exit or an application request.
Never dumped carts before so I am a bit lost...
Also, is there any .ag file that supports dumping the 8 bit music power carts? I believe they use a modified MMC3 mapper?
Did you flash the kazzo with the original bios (or whatever it's called) before using anago?
Yeah I put it in BL mode and flashed with the original kazzo.bat file
From what I can gather the Columbus Circle releases (8 Bit Music Power etc) doesn't work with Kazzo? But I am also having trouble with Creepin it Real and Creepy Brawlers, which the cart board says uses MMC3.
Does anyone has the scheme for Kazzo for professional printing pcb (V1) ? With DIP-style elements (not SMD).
duiz wrote:
From what I can gather the Columbus Circle releases (8 Bit Music Power etc) doesn't work with Kazzo? But I am also having trouble with Creepin it Real and Creepy Brawlers, which the cart board says uses MMC3.
What does your script look like? I've stumbled upon various MMC3 scripts and have had to double the dump at times (when dumping Kirby's Adventure, for example). Maybe we can compare scripts.
Speaking of mysteries, has anyone had any success dumping Quarth and/or the FamiCom Fantasy Zone? bootgod's database says Quarth is a CNROM, but that the hardware is a 74xx161. Would a general CNROM script work, or would I need to use something more particular to the game's specific chip? As for Fantasy Zone, does anyone even have a script for SUNSOFT-1 PCBs?
werewolfslayr925 wrote:
Would a general CNROM script work
Yes; CNROM is specifically implemented using a 74'161.
Quote:
As for Fantasy Zone, does anyone even have a script for SUNSOFT-1 PCBs?
Fantasy Zone will need its own dedicated dumping script, all by itself. (The hardware is unique functionality, different from the normal mapper 93 hardware). Try this modification of INL's UOROM script:
Code:
board <- {
mappernum = 93,
cpu_romsize = 2 * mega, cpu_banksize = 0x4000,
ppu_romsize = 0, ppu_banksize = 0x2000,
ppu_ramfind = false, vram_mirrorfind = true
};
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);
}
(can't test, I might have made a mistake)
board <- {
mappernum = 93,
cpu_romsize = 2 * mega, cpu_banksize = 0x4000,
ppu_romsize = 0, ppu_banksize = 0x2000,
ppu_ramfind = false, vram_mirrorfind = true
};
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize - 1; i += 1){
cpu_write(d, 0xCC75+i, i*0x10+1);
cpu_read(d, 0x8000, banksize);
}
cpu_read(d, 0xc000, banksize);
}
I have a concern regarding the Kazzo that has been backed up in the recent days. It is about chips overheating out of control in seconds. I have observed this highly undesirable behavior on various cartridges (pirates mostly, even good ones using quality components). When plugged, whatever it'd be in a dumping sequence or on standby, one or two chips goes out of control. It's usually the mapper, a chip associated to it or a PAL.
I had two cartridge pass out on the Kazzo in the past days. One from the overheating (I am confident it being the reason) and the other supposedly from likely an inappropriate script.
I know this has been seen by others and reported here and I was curious if something can be done about that? (Or is my INL-Retro defective?)
Because I can't keep up dumping rare (and eventually expensive) unlicensed cartridges with a product that has such an apparent flaw.
EDIT:
follow-up
MLX wrote:
I have a concern regarding the Kazzo that has been backed up in the recent days. It is about chips overheating out of control in seconds. I have observed this highly undesirable behavior on various cartridges (pirates mostly, even good ones using quality components). When plugged, whatever it'd be in a dumping sequence or on standby, one or two chips goes out of control. It's usually the mapper, a chip associated to it or a PAL.
I had two cartridge pass out on the Kazzo in the past days. One from the overheating (I am confident it being the reason) and the other supposedly from likely an inappropriate script.
I know this has been seen by others and reported here and I was curious if something can be done about that? (Or is my INL-Retro defective?)
Because I can't keep up dumping rare (and eventually expensive) unlicensed cartridges with a product that has such an apparent flaw.
I’ve never heard of any issues like this. Can’t imagine a bad script damaging the cart either. What do you mean “pass out”? The boards/carts aren’t getting inserted backwards accidentally are they? Units purchased from me after fall 2016 have resettable fuses to prevent this issue especially with snes. Do you have more details on the boards that had this problem (photos etc).
Well maybe my Kazzo is defective. Krzysiobal made a
similar comment some time ago. Bought my kazzo in early 2017, pcb is dark orange so it's the model you're describing.
The boards are the standard 3-4 globs PCB you'd expect from 90s pirates. I can take pics but I doubt you'll be satisfied by them as there are no signs of damage or anything they just stopped working after.
Yeah only thing I can think of is something about those pirate carts being easy to get into latch up due to hot plugging the cart. I'm not sure what the original kazzo firmware does with it's i/o when it's idle. My firmware disables output drivers and enables pullups which should help prevent from powering chips from the i/o lines while inserting. If the original kazzo firmware doesn't do this, that could be causing latch up I suppose. With this, I would say when using the original kazzo firmware one shouldn't insert the cart while the programmer is powered on. Disconnect USB cord, insert cart, connect USB cord, dump cart or whatever, remove USB cord, then remove cart.
I don't see how a defect could be causing something like this. And yes you've got the version with the resettable fuse, you can see the little green fuse next to the USB connector.
Will anago work with your firmware? Because I remember having to flash it with the original because it wouldn't with the preinstalled one.
MLX wrote:
Will anago work with your firmware? Because I remember having to flash it with the original because it wouldn't with the preinstalled one.
No all firmwares I've ever written, or will ever write will be completely incompatible with anago/unagi. When I first started tinkering with the kazzo I tried to adapt anago/unagi and the original firmware to meet my specific needs but the lack of documentation and high level of abstraction made it easier to start from scratch.
I've been working on a new firmware and software release over the past year that's intent is to make anago/unagi and original firmwares obsolete. All operations can be controlled by lua scripts on the host side allowing as low level of control as desired. I'm hoping to release in the next 2 weeks. But it may take me another month or more to get the mapper scripts built up to the breath of mapper support that anago/unagi currently supports.
Additionally I'm releasing a new hardware design which is completely incompatable with anago/unagi and original firmware as it's updating to an ARM core (STM32F070) and hardware USB 2.0 along with support for additional consoles. But all software and firmware releases I plan to make will be compatible with new (STM32) and old (AVR) hardware. So I'm not ceasing support for old hardware, but I have no plans to provide original hardware with an AVR mcu which will run the original firmware and anago/unagi. I'm hoping the new software and firmware will make those program obsolete but we'll see how that goes.
If it's always the mapper chip that's affected and never the ROM chips, I suspect that the culprit must be on one of the lines that only goes to the mapper chip. Does the Kazzo raise and lower the cartridge connector's M2 line at the same rate as on the NES, or at a higher rate? How are the IRQ and CIRAM lines connected?
NewRisingSun wrote:
Does the Kazzo raise and lower the cartridge connector's M2 line at the same rate as on the NES, or at a higher rate? How are the IRQ and CIRAM lines connected?
FWIW, I was never able to make sense of the original firmware enough to answer detailed questions like this which is why I started fresh with my own implementation.
Isn't the kazzo lacking the M2 clock anyway? It has been said that some cartridges using M2 for a reset detection weren't dumpable as-is with a kazzo.
Control over the M2 pin is present, but is just manually controlled, not a clock. (Control is necessary in order to access addresses below $8000)
So can a mapper IC heat up from waiting for an M2 cycle that never occurs?
I don't see an obvious way for that to happen. (Not saying it can't, but it'd involve extra effort for no obvious benefit)
It looks like hot swapping is part of the reason. I just checked some of the cartridges for which I had seen this behavior by inserting them in the device before plugging the USB and while it did not start to overheat on Earthworm Jim 2 (Super Game), it did manifest itself again with Kaiser Doki Doki Panic (PAL overheating slowly but surely).
Looks like I'm kind of responsible there. I expected the device to not provide power to the cartridge connector in idle mode... I was definitely a fool for believing that (but Kaiser DDP still implies that something not right is happening).
Maybe it's worth pointing out those issues in the documentation, by the way.
Anyone got a dumping script for mapper 184 (Atlantis no Nazo)? Or Sunsoft-1 in general? Thanks!
Try this modified version of the CNROM script:
Code:
board <- {
mappernum = 184,
cpu_rom = {
size_base = 0x8000, size_max = 0x8000
banksize = 0x8000
},
ppu_rom= {
size_base = 0x2000, size_max = 0x8000,
banksize = 0x1000
},
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);
ppu_read(d, 0, banksize);
}
}
Hej
RPGMaster57 wrote:
Is there a way to use the Kazzo to dump Akumajou Densetsu? I cannot find a script for VRC6a. I placed a support ticket on the website for InfiniteNESLives, and I was sent a link to a VRC6a script modified from the VRC6b script. Unfortunately, whenever I try to dump the game, I get this error message that is similar whether I use the VRC6a script or VRC6b script. I have included the error message at the bottom. What can I do to dump this game? I apologize if I am posting in the wrong place; I am new here.
m_database not found
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] 26
[script] "vrc6a.af"
[d] USERPOINTER
[this] TABLE
Here is my script to dump Akumajou Densetsu:
Code:
board <- {
mappernum = 24, vram_mirrorfind = false, ppu_ramfind = false,
cpu_rom = {
size_base = 0x40000, size_max = 0x40000,
banksize = 0x2000,
},
ppu_rom = {
size_base = 0x20000, size_max = 0x20000,
banksize = 0x0400,
}
};
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i += 1){
cpu_write(d, 0xc000, i)
cpu_read(d, 0xc000, banksize)
}
}
function ppu_dump(d, pagesize, banksize)
{
cpu_write(d, 0xb003, 0x0020)
for(local i = 0; i < pagesize; i += 1){
cpu_write(d, 0xd000, i)
ppu_read(d, 0, banksize)
}
}
It gives me the correct rom size and checksum.
The PRG dumps fine but CHR is all messed up. I'm trying to make a Mario's Treasure Hunt (Atlantis no Nazo) on a Kanshakudama Nage Kantarou no Toukaidou Gojuusan Tsugi board.
Since the board had glob tops only I used a CNROM board and connected the Sunsoft-1 as described on the Wiki.
https://wiki.nesdev.com/w/index.php/Sunsoft_1_pinoutWith no success so far. Attached the CHR dump of the cart + original for comparison.
Thanks for the help!
... Er, 12K? Is that truncated?
Looking at those two as picture data, I'm not convinced they're the same original dump at all. Dividing "chroriginal" into twelve 1 KiB banks 0x0 through 0xB, "chrdump" contains 4, 5m, 6m, 7m, 0, 1, 2, 3, 0, 1, 2, 3.
Oh, poop. Yeah.
chroriginal.bin is the CHR Data found from Mario's Treasure Hunt while chrdump.bin is the CHR dumped with Kazzo using your script (with the pinout from Wiki).
Either way, after looking at the Atlantis no Nazo PCB on BootGod I somehow managed this schematic working fine for Atlantis no Nazo. Tested and dumped the cart again using my schematics. All data is equal and the game works fine.
Code:
.---\/---.
PPU A12 -> |01 16| -- VCC
M2 -> |02 15| -> CHR A12
PRG /CE -> |03 14| -> CHR A14
PRG A13 -> |04 13| -> CHR A13
PRG A14 -> |05 12| <- CPU R/W
PRG D5 -> |06 11| <- PRG D0
PRG D4 -> |07 10| <- PRG D1
GND -- |08 09| <- PRG D2
`--------'
Looks like CHR A12/A14/A13 are different here as supposed to be A14/A13/A12 as seen on the Wiki.
Well, that's clearly my fault.
Unfortunately, I can't find where I placed the old trace data when I made the page, so I can't even figure out how I made the mistake.
lidnariq wrote:
Control over the M2 pin is present, but is just manually controlled, not a clock. (Control is necessary in order to access addresses below $8000)
What
exactly does that mean? I am trying to have a multicart dumped, with the outer bank register in the $6xxx range, that keeps mysteriously flipping back to one specific outer bank register value regardless of what I write to it. Could this be caused by a lack of explicit M2 control? Maybe because the hardware falsely detects a Reset? If so, what would I have to write into the Kazzo dumping script to raise and lower the M2 pin correctly?
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.
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".
Correct. This has come up in several threads here (
e.g.); people have disabled the reset detector in order to get a dump.
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?
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...
Just reporting that the multicart in question has been successfully dumped on the first try using a CopyNES.
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);
}
}
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
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);
}
}
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.
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.
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?
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.
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
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.
lidnariq wrote:
Mapper 101 is an erroneously-assigned duplicate of Mapper 87.
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.
Shoot. Turns out that the third stage does, in fact, have some scrambled sprites. Any ideas on how to get them unscrambled?
Also, I have a copy of GeGeGe no Kitarou 2 for which I have no leads for a script. Are there any scripts out there for dumping Bandai carts with mapper 152?
Just change the header to mapper 87, instead of mapper 101. (What emulator are you using?)
Basically:
mappernum = 87 [...] cpu_write(d, 0x6000, ((i & 2) >> 1) | ((i & 1) << 1));
mappernum = 101 [...] cpu_write(d, 0x6000, i);—
Mappers 152 and 70 are basically hybrids of GNROM with UNROM. Try this:
Code:
board <- {
mappernum = 152,
cpu_rom = {
size_base = 0x10000, size_max = 0x20000, banksize = 0x4000
},
ppu_rom = {
size_base = 0x4000, size_max = 0x20000, banksize = 0x2000
},
cpu_romsize = 2 * mega, cpu_banksize = 0x4000,
ppu_romsize = 2 * mega, ppu_banksize = 0x2000,
ppu_ramfind = false, vram_mirrorfind = false
};
function cpu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize - 1; i += 1) {
cpu_write(d, 0x8000, i<<4);
cpu_read(d, 0x8000, banksize);
}
cpu_read(d, 0xc000, banksize);
}
function ppu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize; i += 1) {
cpu_write(d, 0x8000, i);
ppu_read(d, 0, 0x2000);
}
}
(edit: For mapper 70, change "mappernum" to 70, increase cpu_rom's size_max to 0x40000, and change vram_mirrorfind to true)
Thanks so much for your help, lidnariq!
Unfortunately, the script for mapper 152 didn't yield a working ROM. Here are the results:
Code:
Program ROM: size 0x010000, crc32 0x4377a06f
Character ROM: size 0x0040000, crc32 0x4f46913b
As for fixing the script for Lum...
edit: ...maybe I should try actually reading your post. Doy. Jussasec...
...
Bingo! That did it. Wow. Silly me. lidnariq, you lidnaroq.
werewolfslayr925 wrote:
Program ROM: size 0x010000, crc32 0x4377a06f
That's half the PRG you should have gotten...
Quote:
Character ROM: size 0x0040000, crc32 0x4f46913b
That's twice as big as the CHR you should have gotten... How did that even happen? The script I provided shouldn't have been able to make a dump that big.
Quote:
you lidnaroq.
<guffaw> That's a new one on me.
lidnariq wrote:
werewolfslayr925 wrote:
Program ROM: size 0x010000, crc32 0x4377a06f
That's half the PRG you should have gotten...
Quote:
Character ROM: size 0x0040000, crc32 0x4f46913b
That's twice as big as the CHR you should have gotten... How did that even happen? The script I provided shouldn't have been able to make a dump that big.
I retried it just now to test and make sure I used the right script and everything. I
did use your script and got the same results. Then I tried a "d22" command to see if doubling the PRG dump would make a difference (and threw in doubling the CHR just for kicks/out of habit). I got a PRG that matches bootgod's database, but the CHR is still off:
Code:
Program ROM: size 0x020000, crc32 0x48f8d55e
Character ROM: size 0x008000, crc32 0x6853bd7c
The ROM doesn't work in FCEUX either
Quote:
Quote:
you lidnaroq.
<guffaw> That's a new one on me.
I'm simultaneously glad and surprised that nobody's used that before
werewolfslayr925 wrote:
Then I tried a "d22" command to see if doubling the PRG dump would make a difference (and threw in doubling the CHR just for kicks/out of habit). I got a PRG that matches bootgod's database
That doesn't seem right. The dump in GoodNES has 128KiB PRG but this same CRC32, and it's not a duplicate in the first and second halves.
While it's
possible to get an accidental collision with CRC32s —it's 1 in 2**16 odds, per the birthday paradox—I'd be surprised every time it does happen.
Quote:
Character ROM: size 0x008000, crc32 0x6853bd7c
Uh. Why don't you PM me your smaller dump and I'll see if I can figure out what's going on.
Thanks to lidnariq, I was able to dump GeGeGe no Kitarou 2 with the following script:
Code:
board <- {
mappernum = 152,
cpu_rom = {
size_base = 0x20000, size_max = 0x20000, banksize = 0x4000
},
ppu_rom = {
size_base = 0x20000, size_max = 0x20000, banksize = 0x2000
},
cpu_romsize = 2 * mega, cpu_banksize = 0x4000,
ppu_romsize = 2 * mega, ppu_banksize = 0x2000,
ppu_ramfind = false, vram_mirrorfind = false
};
function cpu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize - 1; i += 1) {
cpu_write(d, 0x8000, i<<4);
cpu_read(d, 0x8000, banksize);
}
cpu_read(d, 0xc000, banksize);
}
function ppu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize; i += 1) {
cpu_write(d, 0x8000, i);
ppu_read(d, 0, 0x2000);
}
}
If I understand bootgod's database correctly, this script might also work with
Arkanoid II,
Pocket Zaurus: Juu Ouken no Nazo, and
Saint Seiya: Ougon Densetsu.
EDIT: I also modified the script for Quinty on Arantius's GitHub. It didn't work for me: it gave an incorrect CPU dump and my faulty script gave an incorrect PPU dump, so I combined the working parts of each and got a successful script. The following can be used to dump Quinty:
Code:
/*
Namcot 118/119 chip with Charcter ROM A16 wired PPU A12
Quinty
*/
board <- {
mappernum = 88, vram_mirrorfind = true, ppu_ramfind = false,
cpu_rom = {
size_base = 0x20000, size_max = 1*mega,
banksize = 0x2000
},
cpu_ram = {
size_base = 0, size_max = 0, banksize = 0
}
ppu_rom = {
size_base = 0x20000, size_max = 0x20000,
banksize = 0x0400
}
};
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize - 2; i += 2){
cpu_write(d, 0x8000, [6, i, 7, i+1]);
cpu_read(d, 0x8000, banksize * 2);
}
cpu_read(d, 0xc000, banksize * 2);
}
function ppu_dump(d, pagesize, banksize)
{
local i;
//ROM offset 0x00000-0x0ffff can access from PPU address 0x0000-0x0fff
for(i = 0; i < (pagesize >> 1); i += 4){
cpu_write(d, 0x8000, [0, i, 1, i+2]);
ppu_read(d, 0x0000, banksize * 4);
}
//ROM offset 0x10000-0x1ffff can access from PPU address 0x1000-0x1fff
for(; i < pagesize; i += 4){
cpu_write(d, 0x8000, [2, i, 3, i+1, 4, i+2, 5, i+3]);
ppu_read(d, 0x1000, banksize * 4);
}
}
Apologies to the mods for the double post. lidnariq managed to craft another script, this time for
Ninja JaJamaru: Ginga Daisakusen (i.e. JF-25 and/or iNES mapper 18). We thought it should go here. If an edit is preferable, please let me know.
Code:
board <- {
mappernum = 18, vram_mirrorfind = false, ppu_ramfind = false,
cpu_rom = {
size_base = 1 * mega, size_max = 2 * mega,
banksize = 0x2000
},
ppu_rom = {
size_base = 1 * mega, size_max = 2 * mega,
banksize = 0x2000 / 8
}
};
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize - 2; i += 2){
cpu_write(d, 0x8000, i);
cpu_write(d, 0x8001, i >> 4);
cpu_write(d, 0x8002, i | 1);
cpu_write(d, 0x8003, i >> 4);
cpu_read(d, 0x8000, banksize * 2);
}
cpu_write(d, 0x9000, 0xE);
cpu_write(d, 0x9001, 0xF);
cpu_read(d, 0xc000, banksize * 2);
}
function ppu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i += 8) {
cpu_write(d, 0xa000, i);
cpu_write(d, 0xa001, i >> 4);
cpu_write(d, 0xa002, i|1);
cpu_write(d, 0xa003, i >> 4);
cpu_write(d, 0xb000, i|2);
cpu_write(d, 0xb001, i >> 4);
cpu_write(d, 0xb002, i|3);
cpu_write(d, 0xb003, i >> 4);
cpu_write(d, 0xc000, i|4);
cpu_write(d, 0xc001, i >> 4);
cpu_write(d, 0xc002, i|5);
cpu_write(d, 0xc003, i >> 4);
cpu_write(d, 0xd000, i|6);
cpu_write(d, 0xd001, i >> 4);
cpu_write(d, 0xd002, i|7);
cpu_write(d, 0xd003, i >> 4);
ppu_read(d, 0x0000, banksize * 8);
}
}
lidnariq wrote:
Just change the header to mapper 87, instead of mapper 101. (What emulator are you using?)
Basically:
mappernum = 87 [...] cpu_write(d, 0x6000, ((i & 2) >> 1) | ((i & 1) << 1));
mappernum = 101 [...] cpu_write(d, 0x6000, i);
Thank You.. I Couldn't figure out how to Dump my Mapper 87 games til I saw this dumped all 3 my games Argus, Jajamaru no Daibouken, and Ninja Jajamaru-kun, just by changing the CNROM Script.
I do have a question I was thinking of buying some more Programmable Flash Boards, One particular Board or the Other, I think what I need is a MMC1 Flash Board that has 512kb Program and No Char Rom, So was looking at MMC1 SUROM or MMC1 SXROM. Except I don't know which one I need, I want it to program my own Multi-Carts on it that I made or well put together on to a Rom using the Code by Mottzilla that uses MMC1 and only has 512KB of Program
https://thegaminguniverse.org/ninjagaiden4/mottzilla/homebrew.html Does anyone Know if either of those Boards can be Programed with a Code By Mottzilla Rom? Then does anyone know if it would work?
I have about 3 or 4 Multi-Carts I put together for my own use and I hope to play and test them on real Hardware if possible.
Edit: Looking at Bootgods database I am thinking of going with SXROM as there are not many games that used it so it will be fun to try, and is a combination of SOROM and SUROM so probably would be best. Then I have to have that New Mapper 30 UNROM512 Board too. The Best..
Is there a script for Mapper 78 ? Received my Copy of Holy Diver from Dragonshop today and there is no script in anago for mapper 78. Spend hours today to dump the game with no success. Hope someone can help me
Try this: Dump the PRG ROM with the UNROM script, then dump the CHR ROM with the Color Dreams script, and stitch them up and set the mapper to 78.3.
you can dump the PRG & CHR Rom separately ? I must say I am a total noob, when it comes to anago scripts. Have to search for the color Dreams script. Feel dump for asking but how do I stitch them up ? I know how to change the mapper in the GUI
Let me just copy and paste the two scripts together, it'll be easier than explaining how to do the same thing with the resulting files:
Code:
board <- {
mappernum = 78,
cpu_rom = {
size_base = 1 * mega, size_max = 1 * mega, banksize = 0x4000
},
ppu_rom = {
size_base = 1 * mega, size_max = 1 * mega, banksize = 0x2000
},
ppu_ramfind = false, vram_mirrorfind = false
};
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize - 1; i += 1){
cpu_write(d, 0x8000, i);
cpu_read(d, 0x8000, banksize);
}
cpu_read(d, 0xc000, banksize);
}
function ppu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize; i += 1) {
cpu_write(d, 0x8000, i << 4);
ppu_read(d, 0, 0x2000);
}
}
Was able to dump it, but only a gray screen or nothing in any emulator
https://www.dragonbox.de/en/789-holy-di ... 36733.htmlis that version different then the original one from 89 ?
It's certainly possible that their unlicensed reproduction isn't mapper 78. Comparing the dump you got from a known good dump is the easiest way to find out ... comparing the part numbers on the PCB inside with those of the
official release is the other.
I'll to compare it in the next days
thanks for helping me though
I checked the supported mapper list on gitlab for the new Kazzo device and it seems to support fewer mappers than I recall the older one did. Can any of the old scripts be brought over for use with the new device, or would they have to be re-written?
Little Holy Diver Update:
Thanks to the german shop Dragonbox, I can finally (at least) play the game on my original NES. Have to reset the game until the region switches to PAL.
The PRG-Rom,CHR-Rom & the mapper are the same, as a japanesese version. Maybe some of you guys could look into the rom itself. I have no clue, maybe it has to do with my wrong dumping,the pal ntsc changing etc
[I'd prefer not sharing full ROMs in public. Please send PM to Germansnake if you are interested in troubleshooting this. --MOD]
Hello everyone! Recently I'm trying to make a mapper3 flashcart using HVC-CNROM-256 board as a donor.
But I don't know how to wire the pins after I removed both ROM chips. So I'm here to see if you guys have ever made such a flashcart and are willing to give me some hints. Here are photos of my donor cart, both sides, with ROM chips and anti-piracy diodes removed, and H/V mirroring pads rewired to an external switch.
Donor cart originally Dragon Quest. And the Flash chip I'm planning to use is AM29F040B.
Found someone on youtube, that opened the holy diver cartridge
https://www.youtube.com/watch?v=R57EPBW385Qmaybe with that, we could find a working script for the kazzo
I think that's a COOLBOY board. Try using an MMC3 dumping script.
For reference, in the video:
RETRO-BIT-V5S PCB
- U1: CMD133- 2018.01.20
- U2: [Fujitsu] MALAYSIA 29F016A-90PFTN 0309 F85S
- U8: 8SOP ...ATtiny ?
- U9: 14SOP ... 74HC00Q ??
- on back, U5?: [MOSEL] 0032D V62C5181024L-35W
- unpopulated U3, 70-pin something (alternative PRG ROM?)
- unpopulated U4, on back, 28SOP (PRG RAM?)
- unpopulated IC6, 32TSSOP / 48TSSOP (CHR ROM?)
- unpopulated U7: voltage regulator, fortunately absent
- unpopulated: U10, 16SOP
edit: definitely coolboy.
compare pictures here
prototector wrote:
I checked the supported mapper list on gitlab for the new Kazzo device and it seems to support fewer mappers than I recall the older one did. Can any of the old scripts be brought over for use with the new device, or would they have to be re-written?
That is correct. The original kazzo is AVR based. Technically there is no "new kazzo". There's my old INLretro programmer dumper v1.x which was kazzo compatible. Then there's the lastest INLretro v2.x which is ARM cortex M0 based which IS NOT kazzo compatible meaning it won't run original kazzo firmware nor interface with kazzo softwares anago/unagi.
My latest software release is compatible with all versions of the INLretro programmer/dumper we've ever sold. There are separate firmware builds for v1.x AVR, and v2.x ARM hardware versions. Some features may not be supported on v1.x hardware due to lack of cartridge connections to things like the CIC pins, unidirectional EXP1-8 pins, or low level assembly functions ARM functions which haven't been translated to AVR yet.
To answer your question, No. The old kazzo scripts can't be directly brought over to my new inlretro software. The new software almost entirely uses lua (scripts) for the host application. I've still got a lot of work to do on the software and firmware to catch the new hardware up to the list of mappers supported by the original kazzo with anago/unagi.
My hope is this thread will remain focused on the original kazzo and scripts for anago/unagi even though we've discontinued production and sales of the device. There's quite a few of them out in the wild, we weren't the only hardware manufacturers and being open source, people can always make them their selves. Perhaps someone else will be motivated to keep manufacturing the decrepit V-USB based AVR hardware, but we stopped doing so in early 2018. Once I've got things better polished and some explanation of how to write/translate scripts for the latest inlretro software I'll start a separate dedicated thread.
I see. Thank you for the detailed response, it's really appreciated. It's because we're looking to get a sample game dumped and the Kazzo was the only reliable one do to it in terms of cost, simple setup, etc. I'll keep an eye out for the original device.
So, this is somewhat related to this thread and, since it involves the Kazzo, I thought it should go here. I got a copy of Nakayoshi to Issho and dumped it. However, because the game
is not in bootgod's database, I'm unable to confirm the CRC32s. Here's what I got using an MMC3 script and a d22 command (same I used for Kirby's Adventure):
Code:
Program ROM: size 0x020000, crc32 0x8ab9e1ea
Charcter ROM: size 0x040000, crc32 0x8a86b158
That was on a second attempt. First attempt the cartridge apparently still had a bit of gunge on it, because there were vertical lines through the sprites/backgrounds.
Can anyone confirm these hashes? And how would I go about submitting photos, board info, etc. to bootgod's database? I've noticed he hasn't updated it in years.
EDIT: I also got a copy of Madara that's giving me problems. I noticed someone else was having similar issues with another VRC6 board a few pages back. Here's the script I'm using:
Code:
/*VRC6 type B/351949A/address bus A0=R1, A1=R0
CPU memory bank
cpu address|rom address |page|task
$8000-$bfff|n * 0x4000 |even|write area + write 0x2aaa
$c000-$dfff|0x04000-0x05fff|2 |write 0x5555
-------------------------------------
$8000-$bfff|n * 0x4000 |odd |write area + write 0x5555
$c000-$dfff|0x02000-0x03fff|1 |write 0x2aaa
$e000-$efff|末尾 |fix |boot area, 未使用
PPU memory bank
ppu address|rom address |page|task
$0000-$03ff|0x02800-0x02bff|0x0a|write (0x2aaa & 0x03ff) + 0
$0400-$07ff|0x05400-0x057ff|0x15|write (0x5555 & 0x03ff) + 0x400
$1000-$1fff|n * 0x1000 |n |write area*/
board <- {
mappernum = 26, vram_mirrorfind = false,
cpu = {banksize = 0x4000, maxsize = 2 * mega},
ppu = {banksize = 0x4000, maxsize = 2 * mega},
}
function cpubank_even_set(d, bank, cpu_banksize)
{
cpu_command(d, 0x2aaa, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0xc000, 0x2000);
cpu_write(d, 0x8000, bank)
cpu_write(d, 0xc000, 2)
}
function initalize(d, cpu_banksize, ppu_banksize)
{
cpubank_even_set(d, 0, cpu_banksize);
cpu_command(d, 0, 0x8000, cpu_banksize);
ppu_command(d, 0x2aaa, 0, ppu_banksize);
ppu_command(d, 0x5555, 0x0400, ppu_banksize);
ppu_command(d, 0, 0x0800, ppu_banksize);
cpu_write(d, 0xb003, 0); //work ram disable
cpu_write(d, 0xd000, 0x0a);
cpu_write(d, 0xd002, 0x15);
cpu_write(d, 0xd001, 0x00);
cpu_write(d, 0xd003, 0x00);
}
function cpu_transfer(d, start, end, cpu_banksize)
{
local i;
for(i = start; i < end - 2; i += 2){
cpubank_even_set(d, i, cpu_banksize);
cpu_program(d, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0x8000, cpu_banksize);
cpu_command(d, 0x2aaa, 0xc000, 0x2000);
cpu_write(d, 0x8000, i | 1)
cpu_write(d, 0xc000, 1)
cpu_program(d, 0x8000, cpu_banksize);
}
cpubank_even_set(d, i, cpu_banksize);
cpu_program(d, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0x8000, cpu_banksize);
cpu_command(d, 0x2aaa, 0xc000, 0x2000);
cpu_write(d, 0x8000, i | 1)
cpu_write(d, 0xc000, 1)
cpu_program(d, 0x8000, cpu_banksize);
}
function ppu_transfer(d, start, end, ppu_banksize)
{
for(local i = start; i < end; i += 4){
cpu_write(d, 0xe000, i | 0);
cpu_write(d, 0xe002, i | 1);
cpu_write(d, 0xe001, i | 2);
cpu_write(d, 0xe003, i | 3);
ppu_program(d, 0x1000, ppu_banksize * 4);
}
}
And here's the error it's giving:
Code:
AN ERROR HAS OCCURED [the index 'ppu_rom' does not exist]
CALLSTACK
[ppuarea_memory] NULL
[vram] 0
[increase_ppu] 1
[increase_cpu] 11
[mappernum] 26
[script] "vrc6.af"
[d] USERPOINTER
[this] TABLE
After reading what lidnariq wrote about it, I tried swapping out the line
Code:
ppu = {banksize = 0x4000, maxsize = 2 * mega},
for something like
Code:
ppu = {banksize = 0x8000, maxsize = 2 * mega},
or
Code:
ppu = {banksize = 0x2000, maxsize = 2 * mega},
but to no avail. I'm guessing I'm quite off...
Also, a question that's been bugging me the past few times I used the kazzo: does the file extension on the scripts matter? I've noticed that some are ".ad", some are ".ag", and some are ".af" (which I always read in my head as ".asf**k"). Does this matter at all when using particular scripts?
Naruko changed the syntax at some point: "ppu" is wrong and it should be "ppu_rom", as the error says.
Compare the syntax from (e.g.) nintendo_mmc3_tkrom.ag
lidnariq wrote:
Naruko changed the syntax at some point: "ppu" is wrong and it should be "ppu_rom", as the error says.
Compare the syntax from (e.g.) nintendo_mmc3_tkrom.ag
Great! That fixed the problem.
Unfortunately, there's another syntax error. It now says that 'size_base' doesn't exist. Here's the current script:
Code:
/*VRC6 type B/351949A/address bus A0=R1, A1=R0
CPU memory bank
cpu address|rom address |page|task
$8000-$bfff|n * 0x4000 |even|write area + write 0x2aaa
$c000-$dfff|0x04000-0x05fff|2 |write 0x5555
-------------------------------------
$8000-$bfff|n * 0x4000 |odd |write area + write 0x5555
$c000-$dfff|0x02000-0x03fff|1 |write 0x2aaa
$e000-$efff|末尾 |fix |boot area, 未使用
PPU memory bank
ppu address|rom address |page|task
$0000-$03ff|0x02800-0x02bff|0x0a|write (0x2aaa & 0x03ff) + 0
$0400-$07ff|0x05400-0x057ff|0x15|write (0x5555 & 0x03ff) + 0x400
$1000-$1fff|n * 0x1000 |n |write area*/
board <- {
mappernum = 26, vram_mirrorfind = false,
cpu_rom = {banksize = 0x4000, maxsize = 2 * mega},
ppu_rom = {banksize = 0x4000, maxsize = 2 * mega},
}
function cpubank_even_set(d, bank, cpu_banksize)
{
cpu_command(d, 0x2aaa, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0xc000, 0x2000);
cpu_write(d, 0x8000, bank)
cpu_write(d, 0xc000, 2)
}
function initalize(d, cpu_banksize, ppu_banksize)
{
cpubank_even_set(d, 0, cpu_banksize);
cpu_command(d, 0, 0x8000, cpu_banksize);
ppu_command(d, 0x2aaa, 0, ppu_banksize);
ppu_command(d, 0x5555, 0x0400, ppu_banksize);
ppu_command(d, 0, 0x0800, ppu_banksize);
cpu_write(d, 0xb003, 0); //work ram disable
cpu_write(d, 0xd000, 0x0a);
cpu_write(d, 0xd002, 0x15);
cpu_write(d, 0xd001, 0x00);
cpu_write(d, 0xd003, 0x00);
}
function cpu_transfer(d, start, end, cpu_banksize)
{
local i;
for(i = start; i < end - 2; i += 2){
cpubank_even_set(d, i, cpu_banksize);
cpu_program(d, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0x8000, cpu_banksize);
cpu_command(d, 0x2aaa, 0xc000, 0x2000);
cpu_write(d, 0x8000, i | 1)
cpu_write(d, 0xc000, 1)
cpu_program(d, 0x8000, cpu_banksize);
}
cpubank_even_set(d, i, cpu_banksize);
cpu_program(d, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0x8000, cpu_banksize);
cpu_command(d, 0x2aaa, 0xc000, 0x2000);
cpu_write(d, 0x8000, i | 1)
cpu_write(d, 0xc000, 1)
cpu_program(d, 0x8000, cpu_banksize);
}
function ppu_transfer(d, start, end, ppu_banksize)
{
for(local i = start; i < end; i += 4){
cpu_write(d, 0xe000, i | 0);
cpu_write(d, 0xe002, i | 1);
cpu_write(d, 0xe001, i | 2);
cpu_write(d, 0xe003, i | 3);
ppu_program(d, 0x1000, ppu_banksize * 4);
}
}
werewolfslayr925 wrote:
Unfortunately, there's another syntax error. It now says that 'size_base' doesn't exist.
Compare the
entire line from the mmc3 script, not just that single word
lidnariq wrote:
werewolfslayr925 wrote:
Unfortunately, there's another syntax error. It now says that 'size_base' doesn't exist.
Compare the
entire line from the mmc3 script, not just that single word
Okay, so I got a script that works. I basically just copied the beginnings of the MMC3 script, which I figured would be wrong (it is). I got a (very incorrect) dump of the game:
Code:
Program ROM: 0x059dcdf0
Charcter ROM: 17257ddc
But at least the script doesn't give an error. Here it is:
Code:
/*VRC6 type B/351949A/address bus A0=R1, A1=R0
CPU memory bank
cpu address|rom address |page|task
$8000-$bfff|n * 0x4000 |even|write area + write 0x2aaa
$c000-$dfff|0x04000-0x05fff|2 |write 0x5555
-------------------------------------
$8000-$bfff|n * 0x4000 |odd |write area + write 0x5555
$c000-$dfff|0x02000-0x03fff|1 |write 0x2aaa
$e000-$efff|末尾 |fix |boot area, 未使用
PPU memory bank
ppu address|rom address |page|task
$0000-$03ff|0x02800-0x02bff|0x0a|write (0x2aaa & 0x03ff) + 0
$0400-$07ff|0x05400-0x057ff|0x15|write (0x5555 & 0x03ff) + 0x400
$1000-$1fff|n * 0x1000 |n |write area*/
board <- {
mappernum = 26, vram_mirrorfind = false, ppu_ramfind = true
cpu_rom = {size_base = 2 * mega, size_max = 4 * mega, banksize = 0x2000},
ppu_rom = {size_base = 2 * mega, size_max = 2 * mega,
banksize = 0x0400
},
}
function cpu_dump(d, pagesize, banksize)
{
cpu_write(d, 0xa001, 0); //disable W-RAM
for(local i = 0; i < pagesize - 2; i += 2)
{
cpu_write(d, 0x8000, 6);
cpu_write(d, 0x8001, i);
cpu_write(d, 0x8000, 7);
cpu_write(d, 0x8001, i | 1);
cpu_read(d, 0x8000, banksize * 2);
}
cpu_read(d, 0xc000, banksize * 2);
}
function ppu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize; i+=4)
{
cpu_write(d, 0x8000, 2);
cpu_write(d, 0x8001, i);
cpu_write(d, 0x8000, 3);
cpu_write(d, 0x8001, i | 1);
cpu_write(d, 0x8000, 4);
cpu_write(d, 0x8001, i | 2);
cpu_write(d, 0x8000, 5);
cpu_write(d, 0x8001, i | 3);
ppu_read(d, 0x1000, banksize * 4);
}
}
function cpubank_even_set(d, bank, cpu_banksize)
{
cpu_command(d, 0x2aaa, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0xc000, 0x2000);
cpu_write(d, 0x8000, bank)
cpu_write(d, 0xc000, 2)
}
function initalize(d, cpu_banksize, ppu_banksize)
{
cpubank_even_set(d, 0, cpu_banksize);
cpu_command(d, 0, 0x8000, cpu_banksize);
ppu_command(d, 0x2aaa, 0, ppu_banksize);
ppu_command(d, 0x5555, 0x0400, ppu_banksize);
ppu_command(d, 0, 0x0800, ppu_banksize);
cpu_write(d, 0xb003, 0); //work ram disable
cpu_write(d, 0xd000, 0x0a);
cpu_write(d, 0xd002, 0x15);
cpu_write(d, 0xd001, 0x00);
cpu_write(d, 0xd003, 0x00);
}
function cpu_transfer(d, start, end, cpu_banksize)
{
local i;
for(i = start; i < end - 2; i += 2){
cpubank_even_set(d, i, cpu_banksize);
cpu_program(d, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0x8000, cpu_banksize);
cpu_command(d, 0x2aaa, 0xc000, 0x2000);
cpu_write(d, 0x8000, i | 1)
cpu_write(d, 0xc000, 1)
cpu_program(d, 0x8000, cpu_banksize);
}
cpubank_even_set(d, i, cpu_banksize);
cpu_program(d, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0x8000, cpu_banksize);
cpu_command(d, 0x2aaa, 0xc000, 0x2000);
cpu_write(d, 0x8000, i | 1)
cpu_write(d, 0xc000, 1)
cpu_program(d, 0x8000, cpu_banksize);
}
function ppu_transfer(d, start, end, ppu_banksize)
{
for(local i = start; i < end; i += 4){
cpu_write(d, 0xe000, i | 0);
cpu_write(d, 0xe002, i | 1);
cpu_write(d, 0xe001, i | 2);
cpu_write(d, 0xe003, i | 3);
ppu_program(d, 0x1000, ppu_banksize * 4);
}
}
Any idea how to fix this?
werewolfslayr925 wrote:
Okay, so I got a script that works. I basically just copied the beginnings of the MMC3 script, which I figured would be wrong (it is). I got a (very incorrect) dump of the game:
Surely you've done enough of these by now to get a feeling for what these words and numbers mean? That they're just not just random gibberish?
lidnariq wrote:
werewolfslayr925 wrote:
Surely you've done enough of these by now to get a feeling for what these words and numbers mean? That they're just not just random gibberish?
Unfortunately, they're gibberish to me, though not quite random. I get a couple of the ideas behind the numbers (0x4000 = the size of a ROM(?)), and some of the words (e.g. I know "ppu_dump" means to dump the chip that contains the graphics).
However, I really suck at programming and nobody ever explains things relating to it in a way I can understand. I would love for someone to explain what the words and numbers mean and how it relates to the way each board is built. I really don't understand any of this. Is the commentary at the beginning of the script a blueprint for how the script is supposed to work?
Yup!
werewolfslayr925 wrote:
board <- {
mappernum = 26, vram_mirrorfind = false, ppu_ramfind = true
cpu_rom = {size_base = 2 * mega, size_max = 4 * mega, banksize = 0x2000},
ppu_rom = {size_base = 2 * mega, size_max = 2 * mega, banksize = 0x0400},
}
Every NES cartridge has two places for memory: the CPU and the PPU.
On the cartridge, the CPU must always be able to see ROM but may additionally have RAM ; the PPU may have either, or very rarely, both.
"ppu_ramfind" does exactly what it says: find out if the cartridge has RAM for the PPU, and if so, skip the PPU ROM dumping stage.
The PPU can use the data it sees in one of two different ways: one is a
set of small 8x8 pictures (a "pattern table") ; the other is how those 8x8 pictures are arranged on the screen (a "name table"). The NES includes RAM inside for the purpose of holding these name tables, but only two. However, it can logically address four nametables, so
those two name tables have to be arranged into four slots. Different cartridges provide different arrangements.
"vram_mirrorfind" is specifically used when the arrangement is a fixed function of the physical cartridge, instead of extra hardware on the cartridge making it adjustable as the game progresses. (hardware like NROM, CNROM, GNROM, among many others)
For each of the CPU and PPU roms:
size_base is the smallest dump to even begin trying to dump.
"mega" is 1048576 bits, or 131072 bytes.
size_max is the largest size ROM to ever support
A game for the NES could use up to 32 KiB of ROM for the CPU, and 8 KiB of ROM for the PPU. This got cramped quickly, and so people decided it'd be useful to add ICs to the game board that allows the game to see multiple different chunks of ROM at the same time. These "mappers" are where the name came from.
Different "mappers" support different divisions; from something like ANROM which can has to switch all 32 KiB at the same time (hence "banksize" = 0x8000) to something smaller like MMC3, which can switch 8 KiB at a time (hence banksize = 0x2000).
Similar constraints exist for PPU memory, ranging from CNROM's 8 KiB (banksize = 0x2000) down to MMC3's 1 KiB (banksize = 0x400).
Okay, that's all nice and kind of explains the numbers and commands towards the top of the script. What about all the stuff underneath that? And how do I get this all to function for the VRC6 or any other board? Is there a clear formula I can use to just plug in numbers?
EDIT: Okay, so taking another look at the commentary on the script, I'm guessing that the information there is for the "function cpu_dump" and "function ppu_dump" commands. How do I convert that information to a language the kazzo/anago program can understand?
What's the difference between "cpu_write" and "cpu_read"? How does the "for(local i = 0 etc.)" thing work into this?
See the problem? I'm not a programmer, and I don't understand this.
werewolfslayr925 wrote:
What's the difference between "cpu_write" and "cpu_read"? How does the "for(local i = 0 etc.)" thing work into this?
Anago uses a scripting language called "Squirrel" which looks similar to the C programming language. So a lot of these choices are explicitly designed to be familiar to someone who's already programmed in C, instead of anything else.
The NES's CPU and PPU both have the ability to "read" (get data from) and "write" (put data into) their associated memory.
These "mapper" ICs need to be configured by the game as the game progresses so that the game can read the data it wants to. This is almost always done by having the CPU write specific numbers to specific locations. But the very reason that we have several hundred different mappers is because so many different IC were used.
For example, one of the simplest mappers is
CNROM. The corresponding
script is similarly simple:
1- CNROM doesn't support more than 32 KiB of PRG, so:
1a-
cpu_rom = { size_base = 0x8000, size_max = 0x8000, banksize = 0x8000 },1b-
function cpu_dump(d, pagesize, banksize) { cpu_read(d, 0x8000, 0x4000); cpu_read(d, 0xc000, 0x4000); }(For some random reason, Anago doesn't support reading 32 KiB at a time, so dumping scripts must instead "read the first 16 KiB, then read the following 16 KiB")
2- CNROM supports four 8 KiB CHR banks, so:
2a-
ppu_rom = { size_base = 0x8000, size_max = 0x8000, banksize = 0x2000 },2b-
function ppu_dump(d, pagesize, banksize) { for(local i = 0; i < pagesize; i++) { cpu_write(d, 0x8000, i); ppu_read(d, 0, banksize); }}},Confusing naming: "pagesize" is the number of pages, not the size of the page. (it's the size in terms of pages)
The word "for" means "do the following bit some number of times". In this specific case, the "for ( local i = 0; i < pagesize; i++)" means "do this pagesize times, and the variable 'i' should have the value 0,1,2 ... up through one less than pagesize"
cpu_write(d, 0x8000, N); means "pretend to be the NES's CPU, and write the number i to the address 0x8000". By comparing against our documentation on the wiki, this should select the Nth bank.
ppu_read(d, 0, BANKSIZE); means "pretend to be the NES's PPU, and read BANKSIZE bytes starting at address 0 and going up"
Does this make sense?
Honestly, I was just hoping you might understand enough to be able to understand how to modernize the VRC6 script for the newer runtime, not wanting you to figure this all out on your own. I'm perfectly happy to continue helping with random new scripts.
(Have you encountered hexadecimal before?)
Would it be legal to name the pagesize variable pagecount instead?
lidnariq wrote:
Anago uses a scripting language called "Squirrel" which looks similar to the C programming language. So a lot of these choices are explicitly designed to be familiar to someone who's already programmed in C, instead of anything else.
I'm very unfamiliar with any programming language, really. I can make a some sense of a small fraction of what's going on, but only in the way that I know a handful of words in Greek or a tiny bit of kanji. I never studied this, never got pushed to do so, and don't really have the desire.
Quote:
The NES's CPU and PPU both have the ability to "read" (get data from) and "write" (put data into) their associated memory.
These "mapper" ICs need to be configured by the game as the game progresses so that the game can read the data it wants to. This is almost always done by having the CPU write specific numbers to specific locations. But the very reason that we have several hundred different mappers is because so many different IC were used.
Right! This I understand. I've read about it and discussed this with friends who are more knowledgeable about the hardware than I am.
Quote:
For example, one of the simplest mappers is
CNROM. The corresponding
script is similarly simple:
1- CNROM doesn't support more than 32 KiB of PRG, so:
1a-
cpu_rom = { size_base = 0x8000, size_max = 0x8000, banksize = 0x8000 },1b-
function cpu_dump(d, pagesize, banksize) { cpu_read(d, 0x8000, 0x4000); cpu_read(d, 0xc000, 0x4000); }Quote:
(For some random reason, Anago doesn't support reading 32 KiB at a time, so dumping scripts must instead "read the first 16 KiB, then read the following 16 KiB")
Okay, so the italicized bit explains something that's been puzzling me for a long time. Thanks for pointing that out.
2- CNROM supports four 8 KiB CHR banks, so:
2a-
ppu_rom = { size_base = 0x8000, size_max = 0x8000, banksize = 0x2000 },2b-
function ppu_dump(d, pagesize, banksize) { for(local i = 0; i < pagesize; i++) { cpu_write(d, 0x8000, i); ppu_read(d, 0, banksize); }}},Confusing naming: "pagesize" is the number of pages, not the size of the page. (it's the size in terms of pages)
The word "for" means "do the following bit some number of times". In this specific case, the "for ( local i = 0; i < pagesize; i++)" means "do this pagesize times, and the variable 'i' should have the value 0,1,2 ... up through one less than pagesize"
cpu_write(d, 0x8000, N); means "pretend to be the NES's CPU, and write the number i to the address 0x8000". By comparing against our documentation on the wiki, this should select the Nth bank.
ppu_read(d, 0, BANKSIZE); means "pretend to be the NES's PPU, and read BANKSIZE bytes starting at address 0 and going up"
Does this make sense?[/quote]
This part, not so much. I'm sorry
Quote:
(Have you encountered hexadecimal before?)
Of course. I make chiptunes using LSDJ. I also play lots of Japanese games which involves patching them and tweaking said patches in a hex editor. I've also tried my hand at translating a game which involved lots of hex-level editing.
I'm familiar with the hexadecimal numbering system. I get the amounts the numbers represent for the most part in the context of the Kazzo. I just don't understand the programming very well because I never formally studied programming nor did I ever successfully teach myself. Like I said, every time I try or someone tries to teach me, it's never done in a way I can grasp; I'm never given a clear paradigm for understanding a programming language.
Quote:
Honestly, I was just hoping you might understand enough to be able to understand how to modernize the VRC6 script for the newer runtime, not wanting you to figure this all out on your own. I'm perfectly happy to continue helping with random new scripts.
That's really generous of you. I really wouldn't know where to begin with the VRC6 script (obviously). I'm sorry I'm ignorant of the programming aspect of this
How should I change the script that I've got?
werewolfslayr925 wrote:
This part, not so much. I'm sorry
Hm.
How about:
"the code in the cpu_dump and ppu_dump sections are instructions how to imitate the NES's CPU in order to get data off the cartridge" ?
The specifics have to do with how each individual mapper works. Using the same example, CNROM says "display PPU bank # N when the game writes N to its 'register'". So the ppu_dump section says "count through every useful value of N, tell the cartridge to display that section, then retrieve that data to the computer"
Quote:
Like I said, every time I try or someone tries to teach me, it's never done in a way I can grasp; I'm never given a clear paradigm for understanding a programming language.
In my experience, having a big enough incentive is often the difference. Unfortunately, Squirrel isn't really a good choice for starting...
Quote:
I really wouldn't know where to begin with the VRC6 script (obviously). How should I change the script that I've got?
Right now, you have the bit at the very top (the stuff between /* */, a "comment" that is ignored by Anago) from the VRC6 script, and the rest is the MMC3 script. So that explains what went wrong.
You should hopefully be able to just start with the existing VRC6 script, change just the very first bit ("board", "mappernum", "cpu_rom", "ppu_rom") to look right, and shouldn't have to change the rest of the VRC6 script.
lidnariq wrote:
werewolfslayr925 wrote:
This part, not so much. I'm sorry
Hm.
How about:
"the code in the cpu_dump and ppu_dump sections are instructions how to imitate the NES's CPU in order to get data off the cartridge" ?
I think that makes more sense.
Quote:
Right now, you have the bit at the very top (the stuff between /* */, a "comment" that is ignored by Anago) from the VRC6 script, and the rest is the MMC3 script. So that explains what went wrong.
You should hopefully be able to just start with the existing VRC6 script, change just the very first bit ("board", "mappernum", "cpu_rom", "ppu_rom") to look right, and shouldn't have to change the rest of the VRC6 script.
Okay, so, here's what I got on my own (I'm not sure the numbers are right, because I'm not sure how to convert e.g. 256K as it says on the wiki to hex):
Code:
/*VRC6 type B/351949A/address bus A0=R1, A1=R0
CPU memory bank
cpu address|rom address |page|task
$8000-$bfff|n * 0x4000 |even|write area + write 0x2aaa
$c000-$dfff|0x04000-0x05fff|2 |write 0x5555
-------------------------------------
$8000-$bfff|n * 0x4000 |odd |write area + write 0x5555
$c000-$dfff|0x02000-0x03fff|1 |write 0x2aaa
$e000-$efff|末尾 |fix |boot area, 未使用
PPU memory bank
ppu address|rom address |page|task
$0000-$03ff|0x02800-0x02bff|0x0a|write (0x2aaa & 0x03ff) + 0
$0400-$07ff|0x05400-0x057ff|0x15|write (0x5555 & 0x03ff) + 0x400
$1000-$1fff|n * 0x1000 |n |write area*/
board <- {
mappernum = 26, vram_mirrorfind = false,
ppu_ramfind = true
cpu_rom = {size_base = 0x2000, size_max = 0x4000,
banksize = 0x4000},
ppu_rom = {size_base = 0x2000, size_max = 0x4000,
banksize = 0x0400}
}
function cpubank_even_set(d, bank, cpu_banksize)
{
cpu_command(d, 0x2aaa, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0xc000, 0x2000);
cpu_write(d, 0x8000, bank)
cpu_write(d, 0xc000, 2)
}
function initalize(d, cpu_banksize, ppu_banksize)
{
cpubank_even_set(d, 0, cpu_banksize);
cpu_command(d, 0, 0x8000, cpu_banksize);
ppu_command(d, 0x2aaa, 0, ppu_banksize);
ppu_command(d, 0x5555, 0x0400, ppu_banksize);
ppu_command(d, 0, 0x0800, ppu_banksize);
cpu_write(d, 0xb003, 0); //work ram disable
cpu_write(d, 0xd000, 0x0a);
cpu_write(d, 0xd002, 0x15);
cpu_write(d, 0xd001, 0x00);
cpu_write(d, 0xd003, 0x00);
}
function cpu_transfer(d, start, end, cpu_banksize)
{
local i;
for(i = start; i < end - 2; i += 2)
{
cpubank_even_set(d, i, cpu_banksize);
cpu_program(d, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0x8000, cpu_banksize);
cpu_command(d, 0x2aaa, 0xc000, 0x2000);
cpu_write(d, 0x8000, i | 1)
cpu_write(d, 0xc000, 1)
cpu_program(d, 0x8000, cpu_banksize);
}
cpubank_even_set(d, i, cpu_banksize);
cpu_program(d, 0x8000, cpu_banksize);
cpu_command(d, 0x5555, 0x8000, cpu_banksize);
cpu_command(d, 0x2aaa, 0xc000, 0x2000);
cpu_write(d, 0x8000, i | 1)
cpu_write(d, 0xc000, 1)
cpu_program(d, 0x8000, cpu_banksize);
}
function ppu_transfer(d, start, end, ppu_banksize)
{
for(local i = start; i < end; i += 4)
{
cpu_write(d, 0xe000, i | 0);
cpu_write(d, 0xe002, i | 1);
cpu_write(d, 0xe001, i | 2);
cpu_write(d, 0xe003, i | 3);
ppu_program(d, 0x1000, ppu_banksize * 4);
}
}
Unfortunately, the command prompt says that "the index 'cpu_dump' does not exist. I assume that means I have to give a command for "cpu_dump" (and ppu_dump as well) which I'm unsure how to do.
Honest question: if this is so easy for programmers and arantius has the scripts up on his GitHub, why don't these work? Why are the scripts incomplete?
.......
I'm just gonna be super embarrassed for a moment, because I hadn't looked closely enough to notice that the "konami_vrc6.af" file is only for
programming Flash memory transplanted onto a VRC6-using cart, not for downloading the contents of VRC6-using carts.
My fault.
Here's a quick & dirty attempt at a VRC6a/b dumping script:
(change mappernum to 24 for VRC6a; no other changes should be necessary)
Code:
board <- {
mappernum = 26,
cpu_rom = { size_base = 262144, size_max = 262144, banksize = 0x4000 },
ppu_rom = { size_base = 131072, size_max = 262144, banksize = 0x400 },
ppu_ramfind = false, vram_mirrorfind = false
};
function cpu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize - 1; i += 1) {
cpu_write(d, 0x8000, i);
cpu_read(d, 0x8000, banksize);
}
cpu_write(d, 0xc000, 0xFE);
cpu_read(d, 0xc000, banksize);
}
function ppu_dump(d, pagesize, banksize) {
cpu_write(d, 0xB003, 0x20);
for (local i = 0; i < pagesize; i += 1) {
cpu_write(d, 0xD000, i);
ppu_read(d, 0, banksize);
}
}
edit: fix ppu_rom / cpu_rom
lidnariq wrote:
.......
I'm just gonna be super embarrassed for a moment, because I hadn't looked closely enough to notice that the "konami_vrc6.af" file is only for
programming Flash memory transplanted onto a VRC6-using cart, not for downloading the contents of VRC6-using carts.
My fault.
Here's a quick & dirty attempt at a VRC6a/b dumping script:
(change mappernum to 24 for VRC6a; no other changes should be necessary)
Code:
board <- {
mappernum = 26,
cpu_romsize = 2 * mega, cpu_banksize = 0x4000,
ppu_romsize = 2 * mega, ppu_banksize = 0x400,
ppu_ramfind = false, vram_mirrorfind = false
};
function cpu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize - 1; i += 1) {
cpu_write(d, 0x8000, i);
cpu_read(d, 0x8000, banksize);
}
cpu_write(d, 0xc000, 0xFE);
cpu_read(d, 0xc000, banksize);
}
function ppu_dump(d, pagesize, banksize) {
cpu_write(d, 0xB003, 0x20);
for (local i = 0; i < pagesize; i += 1) {
cpu_write(d, 0xD000, i);
ppu_read(d, 0, banksize);
}
}
Okay, now the file types make sense to me:
.af = Anago Flash (for cart flashing)
.ad = Anago Dump (for dumping carts)
.ag = Anago ??? (typo maybe?)
Anyway...
The script you posted gave me the usual "cpu_rom does not exist", "ppu_rom does not exist", etc. errors, so I modified it accordingly to the best of my ability:
Code:
board <- {
mappernum = 26, vram_mirrorfind = false,
ppu_ramfind = true
cpu_rom = {size_base = 0x2000, size_max = 0x4000,
banksize = 0x4000},
ppu_rom = {size_base = 0x2000, size_max = 0x4000,
banksize = 0x0400}
};
function cpu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize - 1; i += 1) {
cpu_write(d, 0x8000, i);
cpu_read(d, 0x8000, banksize);
}
cpu_write(d, 0xc000, 0xFE);
cpu_read(d, 0xc000, banksize);
}
function ppu_dump(d, pagesize, banksize) {
cpu_write(d, 0xB003, 0x20);
for (local i = 0; i < pagesize; i += 1) {
cpu_write(d, 0xD000, i);
ppu_read(d, 0, banksize);
}
}
At this point it gave me an error that said:
Code:
cpu_romsize is not connected 0x004000/0x002000
AN ERROR HAS OCCURED [script logical error]
CALLSTACK
*FUNCTION [dump()] dumpcore.nut line [47]
LOCALS
[ppu_dumpsize] 8192
[cpu_dumpsize] 8192
[ppuarea_memory] 0
[vram] 0
[increase_ppu] 1
[increase_cpu] 1
[mappernum] 26
[script] "vrc6.ad"
[d] USERPOINTER
[this] TABLE
EDIT: Whoops! Just saw your edit. Dumping now...
...and we have a correct CPU dump! PPU is off, though: CRC32 = 297fa51a...
werewolfslayr925 wrote:
Okay, now the file types make sense to me:
.af = Anago Flash (for cart flashing)
.ad = Anago Dump (for dumping carts)
.ag = Anago ??? (typo maybe?)
also .ae ... and .ai (i = Include?)
I initially found a few .ag with both flashing and dumping support, but ... not all of them, so...
Quote:
cpu_rom = {size_base = 0x2000, size_max = 0x4000, banksize = 0x4000},
ppu_rom = {size_base = 0x2000, size_max = 0x4000, banksize = 0x0400}
Those numbers are wrong, unfortunately. Maybe I should try using decimal; it's obvious what 262144 is, in ways that 2*mega and 0x40000 aren't.
I edited my previous post to use the correct terminology.
Quote:
At this point it gave me an error that said:
Code:
cpu_romsize is not connected 0x004000/0x002000
I ... don't know what to do with that. I don't understand why sometimes it uses one set (Xpu_romsize) and sometimes the other (Xpu_rom.size_base). I
assume this is two different versions of the client, but really don't know.
... unless in this specific case it's saying that you can't have a size_base smaller than 0x4000 (16KiB, the smallest supported by the .nes fileformat)?
lidnariq wrote:
I edited my previous post to use the correct terminology.
I noticed! We have a correct CPU dump! However, the PPU dump is off and the title screen is glitchy. CRC32 is 297fa51a.
EDIT: WAIT! SPOKE TOO SOON! I doubled the PPU dump
Code:
anago.exe d12 vrc6.ad madara.nes
and it gave a dump that matches bootgod's database!! So here's a script for Madara (and the other VRC6b game):
Code:
/*
This script requires a doubled PPU dump
Use the following command in Anago:
anago.exe d12 [script_name].ad [file_name].nes
*/
board <- {
mappernum = 26,
cpu_rom = { size_base = 262144, size_max = 262144, banksize = 0x4000 },
ppu_rom = { size_base = 131072, size_max = 262144, banksize = 0x400 },
ppu_ramfind = false, vram_mirrorfind = false
};
function cpu_dump(d, pagesize, banksize) {
for (local i = 0; i < pagesize - 1; i += 1) {
cpu_write(d, 0x8000, i);
cpu_read(d, 0x8000, banksize);
}
cpu_write(d, 0xc000, 0xFE);
cpu_read(d, 0xc000, banksize);
}
function ppu_dump(d, pagesize, banksize) {
cpu_write(d, 0xB003, 0x20);
for (local i = 0; i < pagesize; i += 1) {
cpu_write(d, 0xD000, i);
ppu_read(d, 0, banksize);
}
}
Is anyone able to test this on a copy of Akumajou Densetsu and/or Esper Dream 2?
About a year and a half ago, I posted a very poor image of NES-TLBROM-01 that I found inside a RoboCop cart. I finally got a better phone, so I took some more photos of it, including the back. Hopefully, you guys can see it more clearly now. If you need anything else, let me know.
74LS541 is a non-inverting buffer with 3-state output.
TI's datasheet describes it as similar to the 74HC245, just with a different pin layout. I'm guessing it's used for the same reason as the
74HC245 on Holy Diver: to allow use of a slower or 28 pin ROM on the CHR side.
tepples wrote:
74LS541 is a non-inverting buffer with 3-state output.
TI's datasheet describes it as similar to the 74HC245, just with a different pin layout. I'm guessing it's used for the same reason as the
74HC245 on Holy Diver: to allow use of a slower or 28 pin ROM on the CHR side.
The 74xx541 chip allows to re-create clean voltage levels from a signal which have poor volate legls or is noisy or high-impedence. I don't see how it could possibly allow for a slower CHR-ROM; if the CHR-ROM is too slow so that it cannot retrieve data in time when it's fetched, there's nothing an external chip can do about it. Or what am I missing ?
By leaving the CHR-ROM enabled all the time, that eliminates the tCE and only cares about the tOE (or more precisely, the time of change of address to output valid, which is usually the same as tOE). Most ROMs seem to be at least twice as fast to respond in this situation.
Then again, like Holy Diver, they appear to be using a 28 pin 128 KiB CHR ROM; they might be using the '541 because it's cheaper than a 74'32. Possibly even both. (I know I traced Holy Diver's PCB and saw that its CHR ROM's output was always enabled)
I have several black block encapsulated game cards.
The mapper type is unknown.
One of them is 4-in-1, four 256K games.
I guess it mapper might be 45 176
Other possibilities are 43 57 58 90 201 202 203 205 212 225 226
I only searched 255, but the others were not found.
Please send these mapper dump codes.
Thank you.
我有几个 黑点 封装 的 游戏卡。
无法知道 mapper 类型。
其中一个是 4-in-1 4 个 256k 游戏。
我猜测 他的 mapper 可能是 45 176
其他的 可能是 43 57 58 90 201 202 203 205 212 225 226
我 只搜索到了 225 其他的 都没有找到
求大家 发 这几个 mapper 的 dump 代码。
谢谢 大家 了。
私はいくつかの黒いブロックカプセル化ゲームカードを持っている。
マッパー型は不明です。
そのうちの1つは4 - in - 1、256 kのゲームです。
私は、マッパーが45
他の可能性は、 43 57 58 90 201 202 203 205 212 225 226
私は225を捜しました、しかし、他は見つかりませんでした。
これらのマッパーダンプコードを送ってください。
ありがとう。
报
I don't think that there are dumping scripts for most of them. Please post an NROM (mapper 0) dump. By looking at the code that is initially executed, one can determine which mapper it is.
Note that if it turns out to be mapper 176, then the Kazzo will not be able to dump it.
wang_80919ms wrote:
I have several black block encapsulated game cards.
The mapper type is unknown.
One of them is 4-in-1, four 256K games.
I guess it mapper might be 45 176
Other possibilities are 43 57 58 90 201 202 203 205 212 225 226
I only searched 255, but the others were not found.
Please send these mapper dump codes.
Thank you.
我有几个 黑点 封装 的 游戏卡。
无法知道 mapper 类型。
其中一个是 4-in-1 4 个 256k 游戏。
我猜测 他的 mapper 可能是 45 176
其他的 可能是 43 57 58 90 201 202 203 205 212 225 226
我 只搜索到了 225 其他的 都没有找到
求大家 发 这几个 mapper 的 dump 代码。
谢谢 大家 了。
私はいくつかの黒いブロックカプセル化ゲームカードを持っている。
マッパー型は不明です。
そのうちの1つは4 - in - 1、256 kのゲームです。
私は、マッパーが45
他の可能性は、 43 57 58 90 201 202 203 205 212 225 226
私は225を捜しました、しかし、他は見つかりませんでした。
これらのマッパーダンプコードを送ってください。
ありがとう。
报
你是中国人？
Bumping this topic just to say, if anyone is interested in a Kazzo Dumper (for NES and FC), I have 3 left I could sell.
This is PCB 2.0 which uses Atmega168P. PM me if interested or for more info.
![[Wide picture]](http://sourceforge.jp/projects/unagi/wiki/pcb2.1_place_ja/attach/ohari.jpg){kind=link}
