Kazzo USB rom dumper / dev cart programmer

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Kazzo USB rom dumper / dev cart programmer

Post by rainwarrior »

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).
prototector
Posts: 44
Joined: Sun Aug 31, 2014 9:55 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by prototector »

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).
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Kazzo USB rom dumper / dev cart programmer

Post by rainwarrior »

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.
prototector
Posts: 44
Joined: Sun Aug 31, 2014 9:55 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by prototector »

Ah, alright, this is good to know. Thanks for the help!
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

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?)
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Kazzo USB rom dumper / dev cart programmer

Post by infiniteneslives »

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).
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
gaminginabox
Posts: 8
Joined: Sat Nov 12, 2016 10:10 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by gaminginabox »

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 Exterior
PowerJoy Interior

Thank 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.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Kazzo USB rom dumper / dev cart programmer

Post by Memblers »

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 :shock:) 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.
Attachments
POWERJ.ASM
PowerJoy cart reader plugin for CopyNES
(4.9 KiB) Downloaded 244 times
gaminginabox
Posts: 8
Joined: Sat Nov 12, 2016 10:10 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by gaminginabox »

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 :shock:) 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.
sdm
Posts: 410
Joined: Tue Apr 11, 2006 4:08 am
Location: Poland

Re: Kazzo USB rom dumper / dev cart programmer

Post by sdm »

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.
Eatitup86
Posts: 10
Joined: Wed Sep 21, 2016 12:29 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by Eatitup86 »

Has anyone successfully dumped Akumajou Densetsu with this?

I purchased one to back up my library & am having trouble getting it to dump properly.
Blake5100
Posts: 7
Joined: Wed Nov 23, 2016 1:39 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by Blake5100 »

:beer:
Last edited by Blake5100 on Tue Mar 07, 2023 1:46 pm, edited 1 time in total.
Blake5100
Posts: 7
Joined: Wed Nov 23, 2016 1:39 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by Blake5100 »

Can anyone confirm if Super Mario World works with the inl snes boards?
Last edited by Blake5100 on Tue Mar 07, 2023 1:45 pm, edited 1 time in total.
SargeSmash
Posts: 6
Joined: Mon Apr 13, 2015 6:25 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by SargeSmash »

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. :)
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Kazzo USB rom dumper / dev cart programmer

Post by Zepper »

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.
Attachments
zepper_carts.zip
(1.88 MiB) Downloaded 1117 times
Post Reply