nesdev.com

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!

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).

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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.

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/PzRP3c11Mz4

To 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.