I've created a tiny NES Header editor (NESHead). It comes with a GUI (yay!
) and should be pretty easy to use.
It's in beta-state so use at your own risk.
Download can be found here:
http://www.anes.se/FDSExplorer/
Hey, thanks! I can never remember which bit is which, so I always have to refer to the NES Header documentation when making a new header or changing something. Now this eliminates that crappiness. Thanks a bunch!
Thanks alot!
If you (or anyone else) has got any other ideas concerning this utility, feel free to tell me.
Suggestions:
1. Checksum (CRC32), PRG+CHR data (no header, of course).
2. Don't allow "free edit" fields, but selectable values, specially for PRG and CHR pages.
3. Check if the ROM size specified in the header (PRG*4000 + CHR*2000) matches the file size. This is important to avoid header conflicts.
4. Ability to add a header into a binary image.
5. Ability to remove the iNES header from a .NES file.
6. External database for proper fixes?
Anyway, your header editor is simple and easy. This is very important. My suggestions are turned to a ROM fixer, but if this isn't your goal, I understand.
Thanks FX3 for your great ideas. I'll probably make a few of the suggestions come true.
There's a serious lack of (userfriendly) NES-tools so I also think usability is important.
A good idea would be to be able to automatically found the PCB name from a header (if Nintendo mapper), altough I don't know if there would be an algorithm that would do that while being reliable.
Or at least show a list of known PCBs that correspond to this configuration of mapper + presence of lack of CHR ROM.
If anyone supply me with a list of known PCB's and it's mapper I might add it to my utility.
Look on the wiki for that.
Fx3 wrote:
Suggestions:
1. Checksum (CRC32), PRG+CHR data (no header, of course).
2. Don't allow "free edit" fields, but selectable values, specially for PRG and CHR pages.
3. Check if the ROM size specified in the header (PRG*4000 + CHR*2000) matches the file size. This is important to avoid header conflicts.
4. Ability to add a header into a binary image.
5. Ability to remove the iNES header from a .NES file.
6. External database for proper fixes?
Anyway, your header editor is simple and easy. This is very important. My suggestions are turned to a ROM fixer, but if this isn't your goal, I understand.
By the way, the external database would be cool. Not sure if it's the scoop of my project
but imagine this:
Assume a database located on a webserver that contains the ROM's CRC32 as ID.. The database could contain a description of the game and perhaps even boxscans. Wouldn't that be cool for use in emulators?
There is already a
database arround.
Bregalad wrote:
There is already a
database arround.
Uh... doesn't look like a .DAT file. :S
I've updated the utility so it has many of fx3's suggested changes:
* Header can now be inserted to another file
* Filesize checker (warns if filesize mismatch)
* CRC32 added
+ some other cosmetic stuff. Enjoy!
I'm currently using the specs that's on Marat Fayzullin's INES website..
http://fms.komkon.org/iNES/
iNES 2.0 is outlined in this thread:
http://nesdev.com/bbs/viewtopic.php?t=2090
Maybe you could give the user the option of using either iNES "1.0" or 2.0?
I don't know if this fits with NEShead's mission as a header editor opposed to a complete "ROM tool", but I believe some people may appreciate the ability to insert/remove/extract trainers, PRG/CHR ROMs and misc data appended after the CHR ROM for expansion. (Yes trainers; while they are frowned upon here, they are part of the iNES specification.)
I think header correcting through a database is also a great idea. It would be nice however if users could generate their own database from a directory, then quickly switch between files in the database using a select field, allowing people to correct many files quickly. From there it would make sense for them to be able to save (using a click button or hot key for speed), then update the database. Lastly the ability to fix files (with a warning/"Yes to all") using a database would allow your tool to fully replace GoodNES as well as other attempts to do so by clueless ROM groups.
- I don't see emulators with iNES 2.0 support... or am I missing them?
Who's to say personal-use emulators don't, or popular emulators won't, or emulator support is even necessary anyway? Maybe if iNES 2.0 was widespread through the use of NEShead, emulator authors would decide to remove the hacks on ambiguous mappers and embrace 2.0.
Some other suggestions I have are:
-file drag and drop support.
-the ability to refresh the "Hexdump" field without actually opening a file so one can simply generate a header.
-a choice between two different Hexdump options: "source code" or "hex editor" (?) mode where the output is strictly uppercase hex ie "4E45431A0000000000000000" so it may be pasted into a hex editor such as Hex Workshop.
-a choice between a few common source code byte directives? I know some assemblers only like ".db", others may allow ".db $4E, $45, $53" as well.
-maybe an option to auto-refresh the Hexdump?
-maybe an option to refresh the Hexdump and copy the text to the clipboard at the same time?
-maybe an Edit menu with Copy for people who don't know to CTRL+C?
kyuusaku: Thanks for all ideas.. Keep your eyes wide open for upcoming versions.
I've updated the program to a new version today:
Source/hex views are now updated in realtime and....
... I've also added some simple database functionality. You can create a simple database and add ROMs to it (well some basic information about them anyway).
This works like a look-up database. NESHead checks the database when you open up a ROM and if there's a match, the header is compared to the one in the database. If there's a mismatch you could replace your faulty header with the one found in the database.
New ROMs can easily be added to the database by picking one at a time (main-view) or simply adding an entire directory at the same time in the ROM-manager section.
Check it out if you're interested.
Remember, all this is highly experimental (and in beta-state) so beware..
http://www.anes.se/fdsexplorer/
When I have to change my header specs I find myself in this process - compile ROM with old header, edit header in emulator, hex edit header out of ROM, and save to header.bin. It's about as much work as editing header.bin in a hex editor to begin with.
If you could just make it possible to save header to a new file (and overwrite), rather than insert to an existing one, this would be about as good as it could get for me.
I always keep my header apart from my game source, assembler, and everything, since it's completely irrelevant to the NES and cartridge.
I'll add loading/saving of "header-only" files in the next version.
Just lobbing this out there since the database / DAT thing came up... You can download an XML containing whatever data you want with the DB client software. Well you could anyways, not at the moment because it is locked right now while I'm working on this transition. I'm also going to start posting pre-compiled snapshots of the DB for download, because doing it thru the client software can be painfully slow if your not local.
Also I will be writing a utility to convert between all formats (iNES,UNIF, and the XML/zip one). I suppose iNES 2.0 as well, if there is demand for it. Source will be included for it. I know this utility is long overdue, but I will get to it as soon as I get the new system online.
Quote:
I suppose iNES 2.0 as well, if there is demand for it. Source will be included for it. I know this utility is long overdue, but I will get to it as soon as I get the new system online.
You should definitely support iNES 2.0, maybe it's that programm that will extend the usage of it who knowns ?
In the olden days us kids were happy just using Matthew Conte's CajoNES. We all believed in having no friends and all that Nofrendo junk
Fixing the mappers and removing Diskdude from all our dirty iNes roms headers. Those were the good ol' days.
You kids don't know how good you have it these days. You don't have to look out for the dirty Diskdude in your iNES roms's headers. With all your goodie tooshoes sites about removing the trainers from your roms. Every iNes file is now practically sanitized. We may have had a dirty time in those days, but it was good enough for us all. US ALL.
/end stupid old ines rom header rant
Mista P wrote:
Fixing the mappers and removing Diskdude from all our dirty iNes roms headers. Those were the good ol' days.
I think I remember when I first learned about emulation (like 5 years ago, haha), I had to remove Diskdude from headers. It does bring back memories... of not knowing what I was doing
.
Mista P wrote:
In the olden days us kids were happy just using Matthew Conte's CajoNES.
Yep, but ever since the splash screen had been removed, it just hasn't been the same.
Memblers wrote:
Yep, but ever since the splash screen had been removed, it just hasn't been the same.
Tell me about it! I wish i had a copy of the old source to cajoNES just for that, but alas, it was lost when my machine was stolen back in 1998 or so.
My software hasn't been hanging nearly as low since then.