It is currently Thu Jan 17, 2019 7:00 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 35 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: Updated iNES
PostPosted: Fri Jul 14, 2006 4:58 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1849
This is a spinoff of what was starting to be discussed in this thread.

The general idea:

To update the iNES format and create an auditing utility to solve various iNES ambiguities, and to correct common iNES header screw-ups (I can't tell you how many games are headered wrong). All while retaining backwards compatibility with prior versions of iNES.


Why not just go with UNIF?:

The obvious question. Since UNIF ROMs are pretty much all labelled properly, and leave nothing to question... why bother with updating iNES? Why not just go with UNIF?

UNIF has some difficulties which prevent it from (ever?) becoming a full replacement to iNES:

- UNIF board name list is incomplete. While it's true that most US releases have a proper UNIF dump, many foreign games, and some rare games do not. Therefore an iNES->UNIF converter won't be able to convert every ROM... making iNES a remaining necessity

- ROM hackers and translators use iNES pretty much exclusively. Even if UNIF were a full replacement, its floating block format is incompatible with IPS (another depricated, yet widely popular format). In addition, every NES ROM editor on the planet is built to work with iNES roms. I'm not aware of any that have UNIF support. So unless every hack, translation, and ROM hacking utility are updated to work with UNIF, there will be a large portion of the emulation community who will refuse to switch.

- Many ROM sites distribute iNES, but not UNIF. Some of the more "major" ROM sites even keep current with GoodNES sets. If we can just take over the next GoodNES release from Cowering, there's a good chance the new ROMs will get injected into the emulation community and begin circulating. UNIF, which has already been around a while, still hasn't really got anywhere.




What do we want out of the updated format:

Blargg brought up a very good point in that other thread:

Quote:
The most important thing is to limit the scope of what is being attempted. As I understand it, the goal is to remove the ambiguity in specifying which mapper is being used (and possibly some extra hardware). Attempting to throw in a kitchen sink would definitely ruin the effort.


I couldn't have said it better myself. UNIF aready does the job of ironing out every tiny thing you can think of. All we're trying to do here is get the ROMs playable without game specific hacks or runtime CRC checks.

What this thread is to accomplish:

I'd really like to outline ideas on what you think will be the best way to approach this. We're stuck with a 16 byte header, of which several bytes are already used.

The things we need to do with this format are:

1) Create something like a "sub-mapper" number which differentiates incompatible mappers which share the same mapper number. For example, MMC3 might be 004:0, while MMC6 might be 004:1 (aaa:b, a = mapper number, b = mapper sub). Most 071 games might be 071:0, and Fire Hawk (1-screen) might be 071:1.

2) Actually get things headered right. Fix ALL the damn mirror mode errors present in 30% of the iNES ROMs floating out there. Remove that DiskDude crap, etc.

3) Actually get a space which tells on-cartridge WRAM and CHR-RAM sizes. None of that "0 defaults to 8k" stuff that's in iNES.

4) Reliable NTSC/PAL/Dual value

5) Perhaps a "Bus Conflicts" flag like the one in the 'unofficial' update listed on the wiki?


That's pretty much all I can think of that the new format should cover. If iNES did all that I'd be perfectly satisfied with it.


But that's not all:

A new format is useless unless we have everything organized! We can shoot the breeze and talk about how awesome this would be all day, but that wouldn't change anything. SO -- in addition to outlining a new format... we need to do the following:


1) Outline DETAILS of the mapper number for every known ROM dump out there, and assign a mapper number:sub for each and every one of them. This is where UNIF falls short in a big way, and if this format update is to have any snowball's chance in hell of working, this is really where we need to have a jump on. If we just slap together something vague, we'll just be back here again in a few months with all the same problems (assuming the format even got anywhere).

2) Get these mapper numbers documented! This probably even has to be done before #1. Register descriptions, differences in sub mapper numbers, etc all has to be layed out clear as day. There HAS to be an official list of mapper numbers, and it HAS to keep current. This is where iNES went to hell, and we have to stay ahead of something like that happening again in the future.

3) All ROMs in the new format should be properly headered. There's no excuse... I don't know how iNES went to hell... but that is really unacceptable.

4) WE NEED AN AUDITOR WHICH WILL CONVERT ROMS AND UPDATE HEADERS. Without one, this project is a pipedream at best. I'd like to say I'd be willing to write one if I could get a list of CRCs for ROM dumps, but my job is keeping me pretty busy so I doubt I'll be able to. But if we can't get someone to write an auditor we might as well just stop now before we waste our time.

5) We need to get in touch with Cowering and tell him to either stop updating GoodNES, or hand off GoodNES to us so that his work doesn't conflict with ours. But of course before we ask him to do either we'll have to have our shit together.


That's about all I have on the subject. I'm too lazy to come up with a propsed new header format right now, but I might later once more ideas are on the table. What do you guys think?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 14, 2006 6:46 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
As Disch said, iNES is established, so improvements to it are much more likely to be successful than replacements. I don't know about all the esoteric mapper issues and how complex they are, but in my mind iNES is close enough to being sufficient that a replacement would have to dead-simple to handle otherwise it wouldn't be able to justify itself.

If this were carried out successfully, the current special case code in emulators would move to the iNES header upgrade tool ("auditor") and the emulator would then rely on the iNES header for unambiguously specifying the cartridge hardware. The additonal bits in the header should be defined in a way that minimizes the changes during updating, in most cases requiring no changes to the header. So in the MMC3/MMC6 case, an extra flag could be added that caused mapper 3 to be treated as MMC6. This seems preferable to defining a new mapper number, because it makes keeps the file usable in current emulators.


Last edited by blargg on Sat Jul 15, 2006 8:06 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Updated iNES
PostPosted: Fri Jul 14, 2006 7:11 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21002
Location: NE Indiana, USA (NTSC)
Disch wrote:
- Many ROM sites distribute iNES, but not UNIF.

By "ROM sites" do you mean pdroms.de? Otherwise, if we work with the pirates, will we get shut down by the fibbies?

Quote:
I'd really like to outline ideas on what you think will be the best way to approach this. We're stuck with a 16 byte header

O RLY? Isn't there a heck of a lot of space after the CHR? See my iNIF proposal.

Quote:
1) Create something like a "sub-mapper" number which differentiates incompatible mappers which share the same mapper number.

As I understand it, the board name is the perfect sub-mapper.

Quote:
2) Actually get things headered right. Fix ALL the damn mirror mode errors present in 30% of the iNES ROMs floating out there. Remove that DiskDude crap, etc.

Won't help. GoodNES is the IE of ROM tools, and it doesn't check the header.

Quote:
1) Outline DETAILS of the mapper number for every known ROM dump out there

Which may require re-finding prototypes. $$$ anyone?

Quote:
and assign a mapper number:sub for each and every one of them. This is where UNIF falls short in a big way

How is the board name an inadequate submapper number? Is it just that people aren't willing to track down rare games and open them?

Quote:
2) Get these mapper numbers documented! This probably even has to be done before #1. Register descriptions, differences in sub mapper numbers, etc all has to be layed out clear as day.

You mean like the effort on the wiki to distinguish all the different S*ROM variants?

Quote:
4) WE NEED AN AUDITOR WHICH WILL CONVERT ROMS AND UPDATE HEADERS. Without one, this project is a pipedream at best.

Who would accept the legal exposure of maintaining this?

Quote:
5) We need to get in touch with Cowering and tell him to either stop updating GoodNES, or hand off GoodNES to us so that his work doesn't conflict with ours. But of course before we ask him to do either we'll have to have our shit together.

And until we have our poo together, we can coexist with GoodTools. For several years, gba-renamer coexisted with GoodGBA, and now Nintenren carries on the gba-renamer tradition.


Top
 Profile  
 
 Post subject: Re: Updated iNES
PostPosted: Fri Jul 14, 2006 7:21 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1449
tepples wrote:
Quote:
1) Create something like a "sub-mapper" number which differentiates incompatible mappers which share the same mapper number.

As I understand it, the board name is the perfect sub-mapper.

Quote:
and assign a mapper number:sub for each and every one of them. This is where UNIF falls short in a big way

How is the board name an inadequate submapper number? Is it just that people aren't willing to track down rare games and open them?


Exactly what board names would you assign for unlicensed games which don't actually have meaningful labels on the cartridge PCBs? Acclaim boards and custom-made Konami PCBs have fun "names" such as 351258, 351298, 351908, 352026, 51555, 53361, 54425, 55741, 56504, and many Famicom cartridge PCBs don't have any board names at all. This is what doomed UNIF to failure.

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


Top
 Profile  
 
 Post subject: Re: Updated iNES
PostPosted: Fri Jul 14, 2006 7:24 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1849
tepples wrote:
Otherwise, if we work with the pirates, will we get shut down by the fibbies?


Who said we would be working with ROM sites? Making a ROM auditor is perfectly legit. That's all we'd be doing. Updated Goodsets would be picked up by ROM sites by them having run the auditor. We would not be distributing ROM sets.

Quote:
O RLY? Isn't there a heck of a lot of space after the CHR?


I suppose. We could go that route. Though personally I'd prefer to stick to the simple 16-byte header. Can't really support that with anything, it's just my personal preference (so much easier)

Quote:
As I understand it, the board name is the perfect sub-mapper.


It would be if we had all the board names. We don't. See my first point in the "Why not UNIF" section above. Unless this new format can cover every single ROM in existence, it's worthless. And guessing or making up board names defeats the whole point of going with board names in the first place.

Quote:
Won't help. GoodNES is the IE of ROM tools, and it doesn't check the header.


Which is why I said we need to make a new auditor. One to replace GoodNES. This one will check and correct/update the header.

Quote:
Which may require re-finding prototypes. $$$ anyone?


I didn't say re-dump the ROMs. I said document mapper details. IE - mapper documentation. The only thing that costs is time.

Quote:
How is the board name an inadequate submapper number?


See above and previous post

Quote:
Is it just that people aren't willing to track down rare games and open them?


Apparently. Like I said, if we had the board names, we could just use UNIF. We don't. So we can't.

Quote:
You mean like the effort on the wiki to distinguish all the different S*ROM variants?


Nothing that specific. Something like the EveryNES mapper section, except wikified and more accurate. Remember, the goal here is not 100% accuracy, it's to retain backwards compatibility and make all games operable without CRC checks or hacks.

You're looking at a different picture. You want something like UNIF. We're not trying to replace UNIF, we're trying to replace iNES.


Quote:
Who would accept the legal exposure of maintaining this?


What legal exposure? Since when is it illegal to make a ROM auditor?


Top
 Profile  
 
 Post subject: Re: Updated iNES
PostPosted: Fri Jul 14, 2006 9:14 pm 
Offline

Joined: Wed Jul 13, 2005 3:14 pm
Posts: 357
Disch wrote:
ROM hackers and translators use iNES pretty much exclusively. Even if UNIF were a full replacement, its floating block format is incompatible with IPS (another depricated, yet widely popular format).


This really doesn't seem to be a problem in my eyes, it would be a trivial task to make an IPS intended for iNES work on a UNIF ROM.

Disch wrote:
UNIF aready does the job of ironing out every tiny thing you can think of.


Actually I've run into situations where the board name is not enough. Some Camerica boards use the exact same board with a different mapper stuck in. BF9093 is the mapper most Camerica games use, BF9096 is the mapper for Quattro carts, but they sometimes share the same board name.

Also, things like MMC version can not always be derived from the board name. I don't think this is much of a problem, but someone just the other day pointed out that not knowing between MMC3B and MMC3C can cause problems.

Disch wrote:
Actually get things headered right. Fix ALL the damn mirror mode errors present in 30% of the iNES ROMs floating out there. Remove that DiskDude crap, etc.


Believe it or not, the next GoodNES version does have header fixing in it.

Disch wrote:
WE NEED AN AUDITOR WHICH WILL CONVERT ROMS AND UPDATE HEADERS.


I don't mean to be plugging here, but my database/dumping software does all this. Of course, it needs to have the info to be able to convert.

Quietust wrote:
Exactly what board names would you assign for unlicensed games which don't actually have meaningful labels on the cartridge PCBs? Acclaim boards and custom-made Konami PCBs have fun "names" such as 351258, 351298, 351908, 352026, 51555, 53361, 54425, 55741, 56504, and many Famicom cartridge PCBs don't have any board names at all. This is what doomed UNIF to failure.


Yes, this is one of the biggest problems. A lot of the UNIF board names just get "made up", especially pirates and the like.

This is a little OT, but I have been assigning the same names that Kevin Horton made up for non-standard boards. Often he assigned unlicensed boards like "UNL-CompanyAbbrBoardName" like UNL-TEN800032 for a Tengen 800032 board.

Rather than prefixing with UNL, what do you think of prefixing it with a company abbreviation instead? For example:

TEN-800032
AVE-NINA-06
CAM-BF9093 (actually Camerica boards are labelled BIC-xx, but as stated above, that is insufficient)

You could do this for the funky Konami and Acclaim boards too:
KON-351908
ACC-55741

I don't really think it's all that neccessary to always stick to board names. For instance, Color Dreams/Wisdom Tree/AGCI/etc. have many boards, all with odd names or no names at all, but the differences all have to do with lockout-defeat methods. So rather than having to support 10 different Color Dreams boards, you could just use CDR-LS377 instead.

Ideally this sort of thing should be discussed before just winging it and slapping whatever name in there. That's pretty much the same as just going ahead an assigning something to an "unused" mapper number.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 14, 2006 9:29 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21002
Location: NE Indiana, USA (NTSC)
The problem with including anything else in the 16-byte header is that ROMs that use it will likely make the anti-DiskDude! checks in current emulators fail. Barring that, I could see using bytes 12 and 13 for a two-character sub-mapper code. This code could be derived from a board name or from a game title, or it could be set to nul ('\0') bytes for the "default" behavior of the mapper.

Mapper 1:
  • default: 8 KB PRG RAM
    If CHR size >= 8 KB then CHR ROM else 8 KB CHR RAM
    If PRG size > 256 KB then a CHR bank line controls PRG ROM A18
    If PRG RAM banks > 1 then a CHR bank line controls PRG RAM A13
  • variant SG: 8 KB CHR RAM, no PRG RAM
  • variant SL: CHR ROM, no PRG RAM
Mapper 4:
  • default: MMC3 "generic" (EDIT: where "generic" means 3B)
  • variant 3A: force MMC3A
  • variant 3B: force MMC3B
  • variant 3C: force MMC3C
  • variant LG: MMC3 "generic" without PRG RAM (for Low G Man)
  • variant HK: MMC6
Mapper 71:
  • default: vertical or horizontal mirroring
  • variant FH: 1-screen mirroring (for Fire Hawk)


Last edited by tepples on Sat Jul 15, 2006 7:52 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 14, 2006 11:15 pm 
Offline

Joined: Sat May 13, 2006 1:05 pm
Posts: 76
Location: USA
tepples wrote:
Mapper 4:
  • default: MMC3 "generic"
  • variant 3B: MMC3B
  • variant 3C: MMC3C
  • variant LG: MMC3 "generic" without PRG RAM (for Low G Man)
  • variant HK: MMC6

MMC3B is the preferred default now, not MMC3A - see my post here.
(If you're not familiar with FCEU-mm, it's an unofficial FCE Ultra build by CaH4e3.)

_________________
This signature intentionally contains no text other than this sentence.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 15, 2006 12:18 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7648
Location: Chexbres, VD, Switzerland
The main problem would be backward-compatibility.

Since most people does think iNES work fine, and most people already have iNES roms on their PC, most people will just not care about the format, because most people are pissed about the SRAM sizes, CHR sizes, bus conflicts and whatever since their favourite games works. Most people don't care that some rare Famicom-only games does have glitches on their emulators.

You won't be able to tell to everyone "delete all your ROMs and download new ones, those have a fixed header system". They won't follow you.

Also, to fix every ROM out there, that'd be a lot of work. There is a long official list of licenced NES games in america, but I found none for Europe or Japan, and I think there is hundreds of FC only games that are small, rare and totally unknown, especially if their title is in japaneese.
Pirate games are even more unorganized than licenced games, so the only real purpose of this would be homebrew devloppement ?

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 15, 2006 1:30 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
tepples wrote:
The problem with including anything else in the 16-byte header is that ROMs that use it will likely make the anti-DiskDude! checks in current emulators fail. Barring that, I could see using bytes 12 and 13 for a two-character sub-mapper code. This code could be derived from a board name or from a game title, or it could be set to nul ('\0') bytes for the "default" behavior of the mapper.
Good point on the anti-DiskDude check, new iNES header bits shouldn't be at the start of the reserved bits. I also like your idea of 2-letter sub-mapper code: it's descriptive, and it would almost certainly be accurate even if the header contains garbage.

Quote:
The main problem would be backward-compatibility.
We'll try to keep it backwards-compatible, so it should still be ok on most older emulators.

Quote:
You won't be able to tell to everyone "delete all your ROMs and download new ones, those have a fixed header system". They won't follow you.
Not if their favourite emulator suddenly 'stops working'. Sure, common users will whine to the author having to implement a checksum database in his emulator, then they'll whine some more, and in the end redownload (or easier: audit).

Quote:
Also, to fix every ROM out there, that'd be a lot of work.
It's not a one-man's job. Yes, it would still be a lot of work but I don't see that as a problem. We can use the wiki for this.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 15, 2006 2:30 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1397
Fixing hacker memory maps in ROMs so emulators don't have to rely on CRC databases is a respectable goal, but rather unrealistic.
Have you considered ever consolodating an online CRC32+MD5+SHA-1 database for all games that can be downloaded in several formats and with tools and libraries in multiple languages (c, c++, vb, etc) for calculating the checksums and selecting the appropriate game? Since this is predominantly an emulator problem and not a user problem, you're likely to make a lot more progress this way.
Then if all of the top emulators were to start throwing out warning messages when a game doesn't match up in the CRC database, this would encourage fan translators and hackers to start using a new header system that bypasses the need for a CRC lookup.
I'm hesitant to make a database that includes CRCs for translations, as that will only lead to hacks being included pre-patched at ROM sites lacking any and all readmes that came with the original work, a method most ROM hackers do not want their work distributed. The ROM sites can still go out of their way to acquire these unofficial works and include them with the "hacker headers", but at least the indexing project is no longer taking a direct role in promoting the behavior.

Quote:
5) We need to get in touch with Cowering and tell him to either stop updating GoodNES, or hand off GoodNES to us so that his work doesn't conflict with ours. But of course before we ask him to do either we'll have to have our shit together.


Perhaps we're speaking of a different Cowering, but if it's the same one who wouldn't remove a single translation I was responsible for from his piracy database: you stand a snowball's chance in hell of convincing him to step down from an entire system because you have a slightly updated header format. However, I can't say I directly know him so maybe you really can convince him to do this. If so, I wish you luck. One less GoodTool is a GoodDay indeed for emulation.

Quote:
Not if their favourite emulator suddenly 'stops working'. Sure, common users will whine to the author having to implement a checksum database in his emulator, then they'll whine some more, and in the end redownload (or easier: audit).


With how many popular NES emulators there are, do you think you could get at least an 80% majority to outright block an old format from playing at all? If you have less than that, you'll only make another emulator more popular. Remember, end users don't care about accuracy or quality, so long as their favorite ten popular games "look" right and run full speed on their ten year old computers.
If you can get an alliance to do this, then you have your best chance of getting everyone to upgrade their ROM headers right there. But remember, any emulator that pops up and doesn't block these games will suddenly have a desirable end-user feature your emulator doesn't. And I would suspect open source emulators would end up with "patched" binaries floating around that bypass the block.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 15, 2006 3:06 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
Quote:
I'm hesitant to make a database that includes CRCs for translations, as that will only lead to hacks being included pre-patched at ROM sites lacking any and all readmes that came with the original work, a method most ROM hackers do not want their work distributed.
I'm with you on that, same goes for 'PD' programs/games.

Quote:
With how many popular NES emulators there are, do you think you could get at least an 80% majority to outright block an old format from playing at all?
The format revisions would be quite compatible with eachother. The current romset (GoodNES 2.01) would work as well as it does now on Nintendulator; an emulator without a built-in database or header corrections. Games with bogus headers, or games like Startropics wouldn't. 80% is too much (people still use the inactive NESticle and FCEU), but if Marty of Nestopia joins in, which I think is currently the most popular active NES emulator, it could succeed.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 15, 2006 8:05 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21002
Location: NE Indiana, USA (NTSC)
byuu wrote:
I'm hesitant to make a database that includes CRCs for translations, as that will only lead to hacks being included pre-patched at ROM sites lacking any and all readmes that came with the original work

New format suggestion: iNES+ZIP. It's built like a self-extracting PKZIP archive, except instead of being an unzipper followed by a zipfile, it's an iNES ROM followed by a zipfile. Store the README in the zipfile and there's no way that the casual user will separate them. Then the auditing program could make sure that the zipfile contents are correct too.

Quote:
Remember, end users don't care about accuracy or quality, so long as their favorite ten popular games "look" right and run full speed on their ten year old computers.

If you replace "ten year old" with "handheld" it's almost correct. People want their ROM collections to work on both PocketNES and PocketNES.

Quote:
If you can get an alliance to do this, then you have your best chance of getting everyone to upgrade their ROM headers right there. But remember, any emulator that pops up and doesn't block these games will suddenly have a desirable end-user feature your emulator doesn't.

Then pop up a dialog box:
Code:
  / \   This ROM is broken. Do you want ScoNES
 /_!_\  to fix it for you?

        [ Fix ]    [ Cancel ]


where pressing OK launches betternes --fix C:\nes\SMB1.nes

hap wrote:
I'm with you on that, same goes for 'PD' programs/games.

Excluding PD programs entirely would mean that you're including only pirated programs, which might get the developers indicted for "inducing" piracy. My policy is include those that work on NES hardware and exclude those that don't. For instance, include Tetramino but exclude GNOME vs. KDE and Mouser. But at least PD programs can display a URL of the manual.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 15, 2006 1:35 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7648
Location: Chexbres, VD, Switzerland
Quote:
Not if their favourite emulator suddenly 'stops working'. Sure, common users will whine to the author having to implement a checksum database in his emulator, then they'll whine some more, and in the end redownload (or easier: audit).

Nope. They'll keep the old version of their emulator on their PC with old ROMs, and say the last version of the emulator suck. A few of them will complain to the author, and he will additionnally recive lot of messages that are annoying to him

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 15, 2006 9:17 pm 
Offline

Joined: Fri Jul 29, 2005 3:40 pm
Posts: 345
Location: near chicago
i think if by adding more to the ines file format will just add to the mess that it is now. i am not familiar with the famicom games, but if they dont have a board number, then perhaps bump the unif version and add a section MMC, where that could state the mmc controller used in the event the board name will not work.

or, if you must add to the ines format, put unif chunks at the end of the file. either check to see if there is data at the end or use one of the unused bits in the ines header indicating unif chunks are at the end.

actually both these methods might work.

matt


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 35 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group