The 16-byte header is pretty cramped anyways, there's over 500 bytes of room for the future with the using the trainer for info idea I mentioned in the other thread.

I read up on the trainer and apparently it's located at $7000-$71FF, so using it for extra space wouldn't be a good idea since it would affect the game on pre-iNES 2.0 emulators. On the other hand, maybe most emulators ignore it.

It's not the emulator that ignores it but the game that ignores it. Except for Low G Man, which relies on open bus in $4018-$7FFF, most games seem to be able to tolerate an 8 KiB PRG RAM at $6000 loaded with arbitrary data loaded into $7000-$71FF, as long as the trainer doesn't overwrite the existing content of the battery-backed RAM. The game's checksum routines will just see it as invalid data and destroy it.

I've been hard at work on the NES 2.0 headers the last 2 or 3 days. So far, I have processed around 1400 ROMs out of 3200. Out of those 1400, only 17 have NES 2.0 headers. I did fix *a ton* of bad headers though. I've fixed probably 70 or 80 bad headers! Mirroring being wrong topped the list of problems, followed by a few incorrect mapper assignments which caused scrambled CHR or crashes later on in the game.

I am concentrating on the discrete mappers so far, and got most of them done, so I am now getting into the harder stuff such as MMC3 and MMC5.

I hope to have something to show for the effort in a week or less. Tomorrow I'm moving to my new house, and the internet is SUPPOSED to be turned on there (hehe) so the transition should be pretty smooth. I may disappear for a bit however if the internet doesn't work for some reason.

Yes, it is mapper 134. There's actually TWO games on the cart, but it is wired to only allow you to play one! I guess they figured the other game was buggy or something? I dunno. If you dump it as MMC3, it will play the one game. If dumped as mapper 134, and a dipswitch is set, it will show a menu and let you select 1 of 2 games. (Incidentally, this is a good example of a "metamapper"- a mapper that works "on top of" an MMC3. This metamapper controls the upper address lines from the MMC3 and to the ROM, so it can restrict how much ROM the MMC3 "sees", and thus you can put multiple games on one cart of varying sizes without wasting space.)

Yes, it is mapper 134. There's actually TWO games on the cart, but it is wired to only allow you to play one! I guess they figured the other game was buggy or something? I dunno. If you dump it as MMC3, it will play the one game. If dumped as mapper 134, and a dipswitch is set, it will show a menu and let you select 1 of 2 games. (Incidentally, this is a good example of a "metamapper"- a mapper that works "on top of" an MMC3. This metamapper controls the upper address lines from the MMC3 and to the ROM, so it can restrict how much ROM the MMC3 "sees", and thus you can put multiple games on one cart of varying sizes without wasting space.)

Thank you very much

Are dipswitch which you say four jumpers on PCB?
The way of Dump is not known. It and Emulator which supports mapper 134 do not exist.

By the way, this Cart is strange.
If this Cart is used by Original Famicom, only FAMILY KID will work.
However, if this Cart is used by TwinFamicom (Sharp), "2-in-1menu" will display ???
Also when it Dump by Mapper4, "2-in-1 menu" displays.

Yes, I completed most of the work. But it looks like another goodNES was released recently that fixes headers. grrrr

I dunno if I want to go thru and fix everything AGAIN. Hopefully it won't be too hard to integrate and track changes between them.

Tonight, I dumped all the EPROMs from my Vs boards and I netted around 17 Vs ROMs from that. The NES 2.0 Vs. byte is working very nicely for this. I have them all set up now and I'm hammering out the changes and stuff on my FPGA to match.

But it looks like another goodNES was released recently that fixes headers. I dunno if I want to go thru and fix everything AGAIN. Hopefully it won't be too hard to integrate and track changes between them.

Run program which saves headers from all your .nes files. Run GoodNES on all your .nes files. Run program to save these modified headers. Compare saved headers from both. I take it GoodNES does not allow access to its database of "correct" headers? Also, why does a new release of GoodNES matter at all with regard to your corrections that use the proposed iNES 2.0 extensions?

Why does a new release of GoodNES matter at all with regard to your corrections that use the proposed iNES 2.0 extensions?

Because then everybody will be using GoodNES to get incorrectly "fixed" headers (and removing any NES 2.0 data), making it significantly more difficult for NES 2.0 to gain a foothold unless kevtris manages to get the functionality built into the next GoodNES release.

_________________Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

A thing that might be cool to see inbedded in a new header format, would be a small game-banner, just like the NintendoDS/GameCube games has.
An icon that could be a part of the boxart, the game logo/whatever. Might perhaps be cool in emulators, to present the game with it's banner instead of the filename (or in combination).

A thing that might be cool to see inbedded in a new header format, would be a small game-banner, just like the NintendoDS/GameCube games has. An icon that could be a part of the boxart, the game logo/whatever. Might perhaps be cool in emulators, to present the game with it's banner instead of the filename (or in combination).

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum