v089 and above will only load images in the FC spec:
Code:
Super Mario Bros.fc/
* program.rom (Super Mario Bros.nes sans first 16-bytes)
* manifest.xml
<cartridge>
<board type="NES-NROM-256"/>
<mirror mode="vertical"/>
</cartridge>
* save.ram (not for SMB, but for other games.)
... avoid my issue of trying to finalize an XML spec that is still changing between releases.
Have you considered using the same XML format Nestopia does? It seems to cover all cases of special mappers, dip switches, multiple ROM chips, etc. Also, you would then automatically get help from
bootgod since he exports his db in Nestopia's format.
[Split because we weren't really talking about FitzRoy's proposal from here on down --MOD]
Quote:
Have you considered using the same XML format Nestopia does?
Honestly, I think it looks really good for the most part.
But there are a few changes that I would have to make.
I've defined an XML markup for all systems I emulate: NES, SNES, GB, GBC, GBA. And although there are necessary concessions for each system, there are consistent elements that this spec doesn't match.
For instance, from Nestopia:
Code:
<cartridge system="Famicom" dump="ok" crc="078CED30" sha1="445EF49C918183F17EEF3D80C6FAF6E0CA8AC19E">
<board type="HVC-SKROM" mapper="1">
<prg size="128k" />
<chr size="128k" />
<wram size="8k" battery="1" />
<chip type="MMC1B2" />
</board>
</cartridge>
In this example, I use SHA256 because it's harder to fake. And will likely use SHA3 when it is out.
My size parameters are in decimal or hex notation, but there is no k/m/g modifiers.
This avoids getting into arguments with SI unit proponents ("Hey, let's call it 131.072KiB!" ... Yeah, let's not.)
So I would have prg size="131072".
Next, I try and avoid getting into "describe this memory chip's type or purpose", so "wram" or "sram" would be out.
Instead, I just call it "ram".
"battery" is a nice argument, but I wouldn't go with "0" or "1", but "true" or "false".
And further, it breaks down at the GBA level: FlashROM, EEPROM and FeRAM memory do not have a battery.
What the behavior is actually saying is, "this data is non-volatile and needs to be saved between runs."
So for now, I add nonvolatile="true" to the RAM argument to tell it to be preserved. Defaults to false if omitted so you can avoid the double-negative of nonvolatile="false". All the same, I don't like my name for that, but it is what it is.
My last, and most important, qualm with his format is that it's back to the useless mapper="number" system.
I want to do away with mapper numbers entirely. The big problem with this is that some of these boards are nameless.
My solution is basically to make up names for their board types, eg "BANDAI-FCG".
And I know the obvious problem with that: everyone will want to make their own names as well. Can't be helped.
I'd rather a descriptive text label than a magic number. If all we wanted were magic numbers, we could use a 16-bit value that becomes a specific board+chip size+pinout configuration. Which would be ugly.
Chip type is tricky, too. A lot of these boards are honestly just discrete logic chips in certain configurations.
In a sense it'd be nice to lose board entirely (except for aesthetics), and set up the board based on what chips it has, but then I don't think anyone is going to emulate a 74LS directly in XML ...
But right now, we're basically omitting chip entirely unless it's a complicated one like an MMC.
byuu wrote:
FitzRoy's spec is:
Code:
Super Mario Bros.zip/
* prg.mrom
* chr.mrom
Eh, neither of us have been using prg and chr abbreviations for a while now. In a post you may have skimmed over, I dumped extensions entirely from my spec. It's just "program" "character" "save" and "data" now. The initial reason for using extensions was to differentiate prg.sram from prg.mrom. But if we call backed prg.sram "save", then extensions aren't really needed. This seems to make sense based on the fact that there are NES games with backed and unbacked prg sram. There are also games that were released on eprom, prom, and mrom, so choosing one would be arbitrary. Point is, the type of chip data was stored on isn't important on the filename level.
byuu wrote:
In this example, I use SHA256 because it's harder to fake.
Is there an advantage of using sha256($prg.$chr) over separate sha256($prg) and sha256($chr)?
FitzRoy wrote:
Eh, neither of us have been using prg and chr abbreviations for a while now. In a post you may have skimmed over, I dumped extensions entirely from my spec. It's just "program" "character" "save" and "data" now. The initial reason for using extensions was to differentiate prg.sram from prg.mrom. But if we call backed prg.sram "save", then extensions aren't really needed.
RacerMate Challenge uses two CHR RAM chips, one of them battery-backed.
FitzRoy wrote:
Point is, the type of chip data was stored on isn't important on the filename level.
Maybe not on the filename level, but it does become important once you get to some of the newer proposed games that save to part of the PRG flash chip.
> Is there an advantage of using sha256($prg.$chr) over separate sha256($prg) and sha256($chr)?
There's no point in storing two hashes. PRG+CHR can be combined for generating the program hash.
I store PRG+CHR merged in the same file as program.rom with my spec.
I don't get into splitting them apart because I don't want to have to face that with other systems (eg SNES SPC7110 program+data ROM, coprocessor program+data ROMs, etc.)
Executables have code and data sections. They're useless separate, so I leave them combined.
> RacerMate Challenge uses two CHR RAM chips, one of them battery-backed.
A) is it officially licensed? B) does it also have PRG RAM that is battery backed?
If there's still only one battery backed file, I'll just call that one save.ram.
Likewise for the "battery back only part of the chip", just two arguments for size: <ram size="realsize" nvsize="partialsize" .../> or whatever. The idea of battery backing only part of a chip seems like nonsense, though. Nicer probably to just split it to two ram entries, only one with nonvolatile="true".
byuu wrote:
This avoids getting into arguments with SI unit proponents ("Hey, let's call it 131.072KiB!" ... Yeah, let's not.)
So I would have prg size="131072".
I like that much better than using units...but even the unitless 131072 has concerns...do you mean bits? bytes? nibbles?
byuu wrote:
Instead, I just call it "ram".
What the behavior is actually saying is, "this data is non-volatile and needs to be saved between runs."
So for now, I add nonvolatile="true" to the RAM argument to tell it to be preserved. Defaults to false if omitted so you can avoid the double-negative of nonvolatile="false". All the same, I don't like my name for that, but it is what it is.
What about volatile, default of "true"? That makes sense, avoids the double negative, and truly describes the behavior of most RAM devices. I don't understand why "RAM" became synonymous with "volatile memory"...Random Access has nothing to do with volatility. Instead, the two types should be ROM and RWM for the obvious reasons. Oh well...can't turn back time now.
byuu wrote:
Chip type is tricky, too. A lot of these boards are honestly just discrete logic chips in certain configurations.
In a sense it'd be nice to lose board entirely (except for aesthetics), and set up the board based on what chips it has, but then I don't think anyone is going to emulate a 74LS directly in XML ...
But right now, we're basically omitting chip entirely unless it's a complicated one like an MMC.
Doesn't MAME do something like this?
byuu wrote:
> RacerMate Challenge uses two CHR RAM chips, one of them battery-backed.
A) is it officially licensed?
Nope. In fact, it required cutting CIC pin 4, which the dealer presumably did as part of the purchase price, because it didn't have its own lockout defeat.
Quote:
B) does it also have PRG RAM that is battery backed?
No. I'm not aware of anything that has both battery-backed PRG RAM and battery-backed CHR RAM.
Quote:
Likewise for the "battery back only part of the chip", just two arguments for size: <ram size="realsize" nvsize="partialsize" .../> or whatever. The idea of battery backing only part of a chip seems like nonsense, though. Nicer probably to just split it to two ram entries, only one with nonvolatile="true".
SOROM and ETROM have the same deal: two PRG RAM chips, only the second one battery-backed.
cpow wrote:
even the unitless 131072 has concerns...do you mean bits? bytes? nibbles?
Probably bytes, like C sizeof(), the Python len(), or what the file system reports in ftell() and stat().
cpow wrote:
What about volatile, default of "true"? That makes sense, avoids the double negative, and truly describes the behavior of most RAM devices.
It takes more effort for the program to treat memory as persistent than to treat it as volatile. So I'd recommend persistent="false" for persistent RAM and persistent="true" for battery-backed RAM, serial EEPROM, or flash.
cpow wrote:
Doesn't MAME do something like this?
I think so in the comments, but I seem to remember the game driver code being slightly more hardcoded.
tepples wrote:
RacerMate Challenge uses two CHR RAM chips, one of them battery-backed.
It would still be written to disk as "save" though, because that's the kind of data it is. Heck, it's probably possible to have a timed life game where program and save data are both on battery backed sram chips. But we can't have two files called "program.ram".
Quote:
Maybe not on the filename level, but it does become important once you get to some of the newer proposed games that save to part of the PRG flash chip.
Behaviorally, yes, there's a difference between EEPROM save and SRAM save that needs to be attributed in each db entry. But I no longer see why that needs to be written out into the filename.
> I like that much better than using units...but even the unitless 131072 has concerns...do you mean bits? bytes? nibbles?
Bytes, always. I know of nothing that needs a bit-count not divisible by eight that I would ever emulate.
> What about volatile, default of "true"?
volatile=false looks unclear for "save this to disk", although I guess you probably should know what a word means if you are going to edit its setting.
I do like persistent. It's clear, to the point, and means something even to non-computer scientists.
> I don't understand why "RAM" became synonymous with "volatile memory"...Random Access has nothing to do with volatility.
I know. And FlashROM carts for the BS-X Satellaview are writable. I don't particularly like that either.
Getting back to the spec, some files in the folder need to be human-editable, eg the xml files.
So the manifest.xml and cheats.xml files can't be extensionless. And no, not going to make people 'know' to rename them with extensions to edit them, or manually open with another program.
From there, I still like the idea of files having extensions to indicate what they are.
And from there, BS-X may be writable, but I want BS-X carts to have the same name as NES carts, so that the GUI knows "folder + <this exact filename> + manifest.xml = cartridge folder"
So then, the only thing I can think is to go back to .bin for everything. But I hate .bin :(
> Nope. In fact, it required cutting CIC pin 4, which the dealer presumably did as part of the purchase price, because it didn't have its own lockout defeat.
Okay, then I don't personally care. I don't bother with bootleg stuff at all.
Even if that means no Gauntlet, it's better than having to defend not supporting Wisdom Tree games.
> Heck, it's probably possible to have a timed life game where program and save data are both on battery backed sram chips. But we can't have two files called "program.ram".
I don't deal with theoretics. If it doesn't exist in the official games for the system I emulate, I'm not going to worry about it. If I did, the format would become an ungodly monster of infinite complexity. Something like XRIF (okay, maybe not that bad ...)
> Behaviorally, yes, there's a difference between EEPROM save and SRAM save that needs to be attributed in each db entry. But I no longer see why that needs to be written out into the filename.
Glad to see we're one step closer to agreeance.
byuu wrote:
I don't deal with theoretics. If it doesn't exist in the official games for the system I emulate, I'm not going to worry about it. If I did, the format would become an ungodly monster of infinite complexity. Something like XRIF (okay, maybe not that bad ...)
But we do have examples of save data being on EEPROM, so what's the point of calling it ram always when the extensions aren't even used for anything?
Consider the following markup:
Code:
<cartridge title="Mahjong Taisen (NTSC)(Jap)(1.0).fc">
<board id="nes-txrom">
<chip id="mmc3" />
<chip>
<memory id="program" type="*rom" size="262144" hash="494353aa48fd3fe1a1f9ea3cd087ba3acee1c50d25f8a99a6186cb6166138bac" />
</chip>
<chip>
<memory id="save" type="sram" size="8192" />
</chip>
<chip>
<memory id="character" type="*rom" size="131072" hash="22e461e64d25475a029722128bace2635262cc9f496db8d7d7f00a5ec3a2e016" />
</chip>
</board>
</cartridge>
This
should tell the emulator everything it needs to know after it retrieves the txrom mapping. Retainment can be assumed by the id. "save" is the only id that is ever battery backed and it's always battery backed. Volatility and writing behavior can both be derived from the memory type attribute.
byuu wrote:
Okay, then I don't personally care. I don't bother with bootleg stuff at all.
Even if that means no Gauntlet, it's better than having to defend not supporting Wisdom Tree games.
The Color Dreams board is functionally GNROM with the nibbles swapped and 4 bits of CHR ROM bank address instead of 2. That's all.
I may be repeating something I said several pages ago, but if you make an emulator that can run games licensed by Nintendo but can't run homebrew, then you run the risk of a judge finding that your emulator doesn't have a "substantial non-infringing use".
Speaking of Gauntlet, Gauntlet has both unlicensed and licensed versions.
Licensed:
http://bootgod.dyndns.org:7777/profile.php?id=473
Unlicensed:
http://bootgod.dyndns.org:7777/profile.php?id=1084
So yes, Gauntlet can be supported by a db.
byuu wrote:
Okay, then I don't personally care. I don't bother with bootleg stuff at all.
That's really sad. So much new stuff being released these days for our beloved old consoles and you choose to be stuck in the past.
Homebrew games are giving new life to these consoles, proving that they're still fun and that they can do more than what was once thought they could, but you'll ignore that because of the stupid "it's only relevant if Nintendo gave their thumbs up" mindset? I am disappoint.
I know you like to strive for accuracy, but really, if your ultimate goal is just to run the licensed stuff, what's the point? Just make yet another rushed emulator and fix game-specific bugs with hacks, just like in the old days!
Unlicensed games are unlimited though and plenty of emulators already support them via iNES. It's just that iNES is a mess and as such, no emulator gets every licensed game correct. That a new emulator would try to do something that wasn't redundant shouldn't be frowned upon.
I have nothing against getting licensed games to run correctly, just against shunning homebrew games (which are and will forever be unlicensed, since Nintendo doesn't license NES games anymore, no matter how good they are) in the process.
I find the idea that "only licenced games are relevant" really stupid because licensing games doesn't even have anything to do with how good they are, it has obviously always been about Nintendo making money. Nintendo probably thought that developers who couldn't afford their demands probably couldn't make good games, but this didn't really work as a form of quality control, since there is a lot of licensed crap and a few unlicensed gems out there...
And I strongly believe that NES homebrewers will be more and more active from now on, releasing really good games (hopefully we'll get past the "single screen puzzle game" for good sometime soon - don't get me wrong, some of these are really cool and addicting, but they still can't compete with the top NES titles) that will help keep the NES alive, so I find it really sad when I see emulator developers, specially talented ones like byuu, not caring about that.
Huh? Is ZapFC is going XML now?
I see no logical progression from a year ago in the delimited file front.
Quote:
<cartridge title="Mahjong Taisen (NTSC)(Jap)(1.0).fc">
<board id="nes-txrom">
<chip id="mmc3" />
<chip>
<memory id="program" type="*rom" size="262144" hash="494353aa48fd3fe1a1f9ea3cd087ba3acee1c50d25f8a99a6186cb6166138bac" />
</chip>
<chip>
<memory id="save" type="sram" size="8192" />
</chip>
<chip>
<memory id="character" type="*rom" size="131072" hash="22e461e64d25475a029722128bace2635262cc9f496db8d7d7f00a5ec3a2e016" />
</chip>
</board>
</cartridge>
How is this not more redundant?
Are there cartridges without boards? Are there boards without chips? Are the chips not implied by the board? Are the memories not implied by the board? (All rhetorical.)
OK, supposing there was a purpose behind the tags and attributes, why not enumerate WRAM, VRAM and CHR-RAM too? They may not always have use in a ROM set but they are part of the configuration and should be defined since they're no more useless than the other info. Oh, and what about boards with MULTIPLE PRG-ROMs? The official ones? PCB jumpers?
(And "hash"? Is there only one hash function now?)
Why is the cartridge tag even "cartridge" when they're called cassettes in Japan and the format is called Zap
FC and takes the ".fc" extension?
Consistency is professional. There is no consistency. To me each "proposal" (as evidenced by the thread there really isn't anything democratic about them) is still just a biased, whiny iNES alternative that more or less follows each of iNES' shortcomings, now through a 500+ character XML element. Bravo.
kyuusaku wrote:
Are there cartridges without boards?
Are there cartridges with more than one board? Yes: anything that uses the Aladdin adapter.
Quote:
Are there boards without chips?
Are there boards with more than one chip? Yes. You still need a board element to contain all the chips.
Quote:
Are the chips not implied by the board?
Not always. The UNROM board covers both mapper 2 and mapper 180, with one of the discrete chips swapped.
Quote:
Are the memories not implied by the board?
Are there boards with spaces for memories that aren't soldered on? Yes. Some of the Bandai FCG boards don't have an EEPROM.
kyuusaku wrote:
Are the chips not implied by the board?
Usually, but not always. Crazy Climber (J) uses a nonstandard chip for UNROM. Boards also do not denote chip revisions on which some games might depend. We know this is true of some SNES titles like Pilotwings.
Quote:
Are the memories not implied by the board? (All rhetorical.)
Not at all. Just the tip of this iceberg: there are SxROM boards that have work ram but no video ram, video ram but no work ram, save ram and work sram, 32kb save ram, or no ram at all. It isn't just from consolidation either, SJROM itself can have no work ram, work ram, or save ram.
Quote:
OK, supposing there was a purpose behind the tags and attributes, why not enumerate WRAM, VRAM and CHR-RAM too? They may not always have use in a ROM set but they are part of the configuration and should be defined since they're no more useless than the other info.
They are, it's just that the entry I used as an example did not have that kind of ram in it. There isn't a game that has every kind of rom and ram possible in it. I've tried using faux entries in the past to show full markup and byuu gets confused by it.
Quote:
Oh, and what about boards with MULTIPLE PRG-ROMs? The official ones?
If the data was divided to save money and could be (or was) later released on a single chip, then it's a single file. If the data was divided because each part needed to be hooked up differently, then each piece is its own file.
Quote:
PCB jumpers?
It's an attribute of the board tag, like mirroring, etc.
Quote:
(And "hash"? Is there only one hash function now?)
There is no advantage to using multiple hashes when the hash you're using can't be spoofed. Thus there's no need to specify which type it is in the markup or change the markup language every time the hash type is changed (when SHA3 comes out, for example). It's obvious what type it is. I don't call "size" "bytes" either.
Quote:
Why is the cartridge tag even "cartridge" when they're called cassettes in Japan and the format is called ZapFC and takes the ".fc" extension?
It's a multi-system markup. The term cassettes died out in favor of cartridge. We're not going to change the markup for each system based on pedantic preferences that one era had over another.
Quote:
Consistency is professional. There is no consistency.
There is, you're just another misinformed iNES weirdo.
Really the only true answer to preservation and canonical representation is a format that completely describes the IC, board, and interconnect level circuitry of the NES and the things that can be plugged into it. Coming up with representations of what "groups" of particular circuits represent is *always* going to be fraught with exception. RAM is not always RAM. ROM, not always ROM, one MMC1 not entirely identical to the other, etc. Even sticking to licensed games each cartridge has variations that any format that attempts to describe them all concisely will fail in some regard.
tepples wrote:
Are there cartridges with more than one board? Yes: anything that uses the Aladdin adapter.
I could argue that they are separate cartridges instead of boards. Plus none of the ROM boards contain their own mapper hardware requiring configuration. Plus they're unlicensed.
Quote:
Are there boards with more than one chip? Yes. You still need a board element to contain all the chips.
You don't need the chips if they're implicit. All MMC3 boards will contain a MMC3. If the game behavior relies on a specific MMC3 then the MMC3 type can be specified, but it shouldn't need it's own element at all and especially not all the time, unless everything else should get an element out of fairness. But then you'd be replicating Bootgod's database.
Quote:
Not always. The UNROM board covers both mapper 2 and mapper 180, with one of the discrete chips swapped.
That's what tag attributes are for. Just give the Crazy Climber board a type="7408".
Quote:
Are there boards with spaces for memories that aren't soldered on? Yes. Some of the Bandai FCG boards don't have an EEPROM.
The board still defines whether or not solder pads exist at all. For all instances of the FCG board, if the game has saves, they're SEEPROM saves. There's only ambiguity is to someone who doesn't know, but then they should be going to a more complete resource. The emulator can't emulate strictly using the format's chip elements now so it still needs hardcoded context, which makes memory types redundant. I could however see this being used for altered board behavior such as emulating a Flash dev cart for whatever reason, but I doubt that was the idea.
kyuusaku wrote:
That's what tag attributes are for. Just give the Crazy Climber board a type="7408".
For one thing, the chips on a board are not board attributes. Secondly, you're creating a confusing system wherein blankness implies the most standard attribute, and what is "standard" could sometimes be quite arbitrary. What if X chip being used wasn't any more common or standard than Y chip being used? Which one is default and which one has to be explicated as the deviation? This conditional hackery line of thinking is just stupid and leads to more confusion. If there are multiple legitimacies for a given attribute, then that attribute should always be explicated.
FitzRoy wrote:
We know this is true of some SNES titles like Pilotwings.
Pilotwings has a different configuration using the same chips, so that surely doesn't make sense.
Quote:
Not at all. Just the tip of this iceberg: there are SxROM boards that have work ram but no video ram
? Yes, but what is populatable is defined by the board, it's not as if the emulator is going to have context without the board in any sense. The configuration is just as easily a board attribute as it is an element. I don't see why anything but memories loaded from files need child elements.
Quote:
If the data was divided to save money and could be (or was) later released on a single chip, then it's a single file. If the data was divided because each part needed to be hooked up differently, then each piece is its own file.
OK, how are each file treated in terms of filenames? I haven't seen this discussed at all.
Quote:
It's an attribute of the board tag, like mirroring, etc.
"Mirroring" itself is a backwards iNES concept in place of scrolling-oriented jumpers.
Quote:
There is no advantage to using multiple hashes when the hash you're using can't be spoofed
There certainly is an advantage for people who don't have cryptographical hardware acceleration.
Quote:
It's obvious what type it is.
This sums up the format. It's obvious to you how things are and should be, it is after all your creation and designed to your aesthetic. That doesn't mean your opinion is efficient, or logical, or that you're all knowing of industry conventions and make appropriate use of them. Hash algorithms have to be one of the least obvious strings of characters imaginable. The lack of extensibility just drives home the point that this format was created to suit your purposes, and exactly your purposes. Since that's the case do you even take feedback or are you just proselytizing?
Quote:
I don't call "size" "bytes" either.
Hm?
Size in bytes is a bad attribute for ROMs, they are never expressed that way because they aren't built that way. You can decode ROMs to any byte length desirable, but then you have ambiguities such as partial/full decoding. Are emulators supposed to take liberties with malformed unlicensed ROMs or is this being pedantic from copier days? Or perhaps just excessively verbose?
Famicom Disk System files are expressed in bytes. How does ZapFC deal with FDS? Are they disk images? Side images? HLE? LLE? Do they get paired with the RAM adapter board? This I have to hear.
Quote:
It's a multi-system markup.
That makes it even worse... Are Famicom Disk System images cartridges? Or does each peripheral require games to be organized as a child element?
It looks like this is all still being made up as you go along :/
FitzRoy wrote:
For one thing, the chips on a board are not board attributes.
Since they aren't being emulated I think they are.
Quote:
Secondly, you're creating a confusing system wherein blankness implies the most standard attribute
If by blankness you mean an unpopulated part then yes. It's logical since you must configure the board anyhow which instantiates parts.
Quote:
what is "standard" could sometimes be quite arbitrary.
Not really. What is first is standard. UNROM originally contained OR gates. If a large number of boards used AND gates then there's no harm in giving OR gate boards the type "7432" explicitly, but given what we know about UNROM the overwhelmingly default (and original) configuration has OR gates so I don't see your point. I didn't come up with a rule of "blankness".
Quote:
that attribute should always be explicated.
I disagree, but I didn't actually say that. I do agree they should be board attributes instead of elements though as they are not used for data, as elements "should" be, nor would chip elements have any attributes since netlist emulation isn't considered here.
--
At this point I don't see why you don't use bootgod's DB straight up. Who needs an intermediary format? All you have to do is extend his for other platforms.
kyuusaku wrote:
Pilotwings has a different configuration using the same chips, so that surely doesn't make sense.
No, it uses the same board as other DSP1x games, but it has bugs if the chip revision is DSP1B and not DSP1. This is a software revision example, but it's very likely that there are games out there relying on hardware revisions of chips that cannot be implied by the board or anything else. That needs accounted for because there are a crapton of chip revisions on the NES.
Quote:
? Yes, but what is populatable is defined by the board, it's not as if the emulator is going to have context without the board in any sense. The configuration is just as easily a board attribute as it is an element. I don't see why anything but memories loaded from files need child elements.
Video ram, work ram, and save ram aren't loaded from files and board ids don't definitively tell you whether a game had them.
It's a matter of preference whether or not chip should be a child element of board or an attribute of board. Personally, I don't think pinout variations and solder pads should be expressed on the same level as chip population. I also like a format that shows which chips stored what memory. MMC6 save data is inside the MMC6 chip.
Quote:
OK, how are each file treated in terms of filenames? I haven't seen this discussed at all.
Well, obviously, video and work ram aren't written to disk and have no filenames. Save data (on ram or eeprom) would be written as "save" and program data is "program" etc. Basically, the data is distinguished by what it is, not what kind of chip it comes on.
Quote:
"Mirroring" itself is a backwards iNES concept in place of scrolling-oriented jumpers.
Sounds like a different name for the same thing to me.
Quote:
There certainly is an advantage for people who don't have cryptographical hardware acceleration.
Since when does sha256 require a supercomputer to calculate?
Quote:
This sums up the format. It's obvious to you how things are and should be, it is after all your creation and designed to your aesthetic. That doesn't mean your opinion is efficient, or logical, or that you're all knowing of industry conventions and make appropriate use of them. Hash algorithms have to be one of the least obvious strings of characters imaginable.
It doesn't need to be dirt obvious to anyone other than the maintainer. Look at the emulator's parsing code once if you're that curious and confused. Calling it hash prevents having to change the parser to accept "sha3" when you change the hash format to it.
Quote:
The lack of extensibility just drives home the point that this format was created to suit your purposes, and exactly your purposes. Since that's the case do you even take feedback or are you just proselytizing?
You saying board x always had x ram and x chips with such wrong certainty that you bothered to be snarky isn't feedback. Nothing you have said makes any goddamn sense besides maybe your comment about the aladdin.
Quote:
Hm?
Size in bytes is a bad attribute for ROMs, they are never expressed that way because they aren't built that way. You can decode ROMs to any byte length desirable, but then you have ambiguities such as partial/full decoding. Are emulators supposed to take liberties with malformed unlicensed ROMs or is this being pedantic from copier days? Or perhaps just excessively verbose?
The size field is merely to validate the size of the data, it has nothing to do with finer points of emulation behavior. A database file is not an emulator, it's a mapping delivery scheme.
Quote:
That makes it even worse... Are Famicom Disk System images cartridges? Or does each peripheral require games to be organized as a child element?
It looks like this is all still being made up as you go along :/
A cartridge is the same thing as a cassette and gamepak. The tag only changes if the media is different.
Before you go any further with this, note that I did not resurrect this thread. There is no need to further the argument for db lookup here.
I have no idea what you're replying to because I'm not arguing against chip revisions or saying that board configurations are encoded in their "ID", I'm arguing against redundancy/being over-descriptive.
RE Pilotwings: my misunderstanding, I was talking about the mapping, but it happens to be a different board than SMK.
Quote:
Basically, the data is distinguished by what it is, not what kind of chip it comes on.
My point is that two PRG ROMs can exist that aren't decoded linearly. Since there aren't descriptive names for the ROMs this cannot be handled, unless it's tacked on as a special case. As a general purpose format there will be many instances where different ROMs on the same bus may need different loading or decoding methods. If the various unrelated parts are lumped together then it'll be back to the "binary blob" thing.
Quote:
Sounds like a different name for the same thing to me.
Jumpers decide the cause, mirroring explains the effect. I just find it ironic that you wouldn't go with the descriptive, empirical and official nomenclature instead of again doing something the iNES way.
Quote:
Since when does sha256 require a supercomputer to calculate?
The world is moving towards embedded. Why require more when it can be done with less? Think about the NES itself, it hates SHA256, no verification for it.
Quote:
The size field is merely to validate the size of the data, it has nothing to do with finer points of emulation behavior. A database file is not an emulator, it's a mapping delivery scheme.
It should, ROM size is part of the mapping delivery scheme. As I'm sure you know boards may accept 8M, 4M, 2M or 1M ROM in the same socket.
I give up though.
kyuusaku wrote:
Plus they're unlicensed.
So is just about everything that gets done on nesdev.com outside NESemdev.
But to humor you: Are there licensed "cassettes" with more than one board? Yes. FDS. There's the system card that sits horizontally, there's the small vertical board connecting the system card to the Famicom, and there's the board in the disk drive.
And if this is intended to run multi-system, I seem to remember some arcade system boards (really consoles with JAMMA I/O) with the game itself split across two boards.
FitzRoy wrote:
Since when does sha256 require a supercomputer to calculate?
One SHA-256 can be calculated on one core of a PC or a mobile device. Two SHA-256s can be calculated in parallel on two cores.
FitzRoy wrote:
Calling it hash prevents having to change the parser to accept "sha3" when you change the hash format to it.
Is it easier to change the parser or to change the entire ROM collection?
kyuusaku wrote:
I have no idea what you're replying to because I'm not arguing against chip revisions or saying that board configurations are encoded in their "ID"
You pretty much flat out said that board serials could imply everything. And I quote: "You don't need the chips if they're implicit." "Are the chips not implied by the board? Are the memories not implied by the board? (All rhetorical.)"
Quote:
My point is that two PRG ROMs can exist that aren't decoded linearly.
I'm going to have to ask for one good example because it's boy that cried wolf at this point.
Quote:
Jumpers decide the cause, mirroring explains the effect. I just find it ironic that you wouldn't go with the descriptive, empirical and official nomenclature instead of again doing something the iNES way.
Official, huh? Got any pcbs with that printed on it? Got any design documents? All I see is a big H and V next to solder pads. There are no jumper pins on which an actual jumper shunt would go, so your name sounds pretty inaccurate to me.
Quote:
The world is moving towards embedded. Why require more when it can be done with less? Think about the NES itself, it hates SHA256, no verification for it.
lol, suffice it to say, an emulator db is for emulators.
Quote:
It should, ROM size is part of the mapping delivery scheme
But the mapping code within the emulator isn't written with a specific size in mind. It basically expects a range of validities and will function according to what you give it.
tepples wrote:
Is it easier to change the parser or to change the entire ROM collection?
Why would you need to touch the roms if the hash in the database was changed?
tepples wrote:
So is just about everything that gets done on nesdev.com outside NESemdev.
Hey, I'm not making the rules.
Quote:
Yes. FDS. There's the system card that sits horizontally, there's the small vertical board connecting the system card to the Famicom, and there's the board in the disk drive.
There are copiers with active sub boards (mostly memory), two types even pass bankswitching logic through it for expansion.
Quote:
And if this is intended to run multi-system, I seem to remember some arcade system boards (really consoles with JAMMA I/O) with the game itself split across two boards.
I'm sure some arcade boards have more than 4 sub boards. I didn't know the format's ambition then.
> This I have to hear.
> It looks like this is all still being made up as you go along
This kind of thing adds nothing of value to the conversation.
Everyone here is free to do whatever they want with their time. If you really think a format is so bad, then you know it won't catch on and you can safely ignore it if you can't say anything nice.
But if you're afraid of it catching on, or point out the error of someone's ways, please ... leave the ad hominems out. All that does is create increased polarization. It makes both sides less likely to come to agreement on anything.
> Calling it hash prevents having to change the parser to accept "sha3" when you change the hash format to it.
Although this works well for your internal DB, it will not work as well for external databases.
Imagine a translation released with an included board file (or manifest as I call it.) It has "hash=(32 characters)". How does your emulator know how to match it ... is that SHA256, or SHA3? There's no guaranteeing future hashing algorithms won't use the same number of bits, and no guaranteeing old-style data won't be loaded in.
If you consider hash to be an integral part of the spec, where a change breaks the format, then I guess there's no use worrying about it. But if you want to allow for backward-compatibility, or just support when there are no hashes at all, then I would strongly recommend naming the hashing algorithm.
Others on the board: see how I raised an objection with logic and without insulting anyone's intelligence or attacking their character? FitzRoy may not agree with me still, and if he doesn't ... I tried. Time to move on.
> Think about the NES itself, it hates SHA256, no verification for it.
An NES would be a very unlikely candidate to emulate the NES.
SHA256 feels daunting, but it can be implemented in 4KB of C code. XML parsers are a bigger issue in terms of complexity. True, it's not as fast as CRC32, but it is easily handled by anything capable of emulating the NES in the first place, including the GBA for instance. Plus of course, NES games are small. The entire official NES set is ~60x smaller than the GBA set. All you really need is rotate by integer and bit-math opcodes.
Further, there's no obligation for the emulator to validate image hashes. If we were to imagine hashing a CD-ROM image (ignoring the difficulty in even dumping a bit-perfect CD image), then one could leave the hashes for a validation tool.
>> My point is that two PRG ROMs can exist that aren't decoded linearly.
> I'm going to have to ask for one good example because it's boy that cried wolf at this point.
The SNES loves to do this, which is why the SNES has the map mode+offset+size attributes.
*If* any NES games do this, then it's most likely a detail of the mapper. Mappers are kind of a recurring trend on the NES.
But again, add complexity only when it is needed. Show me a licensed NES game that maps 8000-8fff + a000-afff as two ROM chips, and we will talk about how to support that game.
> There are no jumper pins on which an actual jumper shunt would go, so your name sounds pretty inaccurate to me.
I will agree that mirroring doesn't sound great, especially if you have a board that supplies the extra RAM for four-screen in a non-software-controlled manner. But jumper isn't any more descriptive to someone who doesn't understand what it means.
At its core (without getting into the EE level of how it connects back internally to the NES), the distinction of horizontal/vertical is having half the available memory as your bus has, so deciding which bit of the address you are going to ignore (vertical=use A10, ignore A11; horizontal=use A11 as A10, ignore real A10.) This makes up the bulk of odd SNES memory mapping as well. The gist of the issue is that C programs like linear arrays, and circuit designs like not connecting address lines.
> I'm sure some arcade boards have more than 4 sub boards. I didn't know the format's ambition then.
I can't speak for FitzRoy's multi-system ambitions, but with my spec I adapt them to match the realities of each system. NES is based around describing board + chip revision and configurations, as well as RAM sizes. It's meant to fill in the data that is not provided by iNES1 (such as VRC type for some games like Contra JP and Goemon.) SNES is based around address decoding behavior (MAD1 or LSxxx, and how is it configured?), but is described in a way that is friendly to C code (manual bit twiddling would be far too slow, even for me.) GB/C only tells you RAM size and mapper type. GBA tells you about the external memory type and chip identifier (that programs can read and do verify.) If I ever emulate a system with multiple boards, I'll have multiple <board> tags inside of it. All the same, I'll share as many similarities as I can between systems. Eg SHA256 for hash type, <cartridge> for PCB-based systems and something else if I ever do CD-based systems.
FitzRoy wrote:
Quote:
My point is that two PRG ROMs can exist that aren't decoded linearly.
I'm going to have to ask for one good example because it's boy that cried wolf at this point.
I know of a commercial NES game with three 4 Mbit PRG ROM chips and a gap in their decoding, but it's unlicensed. In mapper 228 (Active Enterprises), there are slots for four PRG ROM chips, but only slots 0, 1, and 3 are populated.
Quote:
Quote:
Jumpers decide the cause, mirroring explains the effect. I just find it ironic that you wouldn't go with the descriptive, empirical and official nomenclature instead of again doing something the iNES way.
Official, huh? Got any pcbs with that printed on it? Got any design documents? All I see is a big H and V next to solder pads.
The H enables vertical mirroring, and the V enables horizontal mirroring. This strongly indicates to me that something like the "arrangement" nomenclature seen
here was official among licensed developers.
Quote:
tepples wrote:
Is it easier to change the parser or to change the entire ROM collection?
Why would you need to touch the roms if the hash in the database was changed?
For ROMs that happen not to be included in the database.
I guess whether to provide for unlicensed releases is a fundamental difference of opinion as to the scope of a format. Being an unlicensed NES game developer myself, I obviously prefer a format whose philosophy doesn't reject unlicensed games outright. But once you go multi-system, all hopes of only having to support licensed games are out the window for one simple reason: games for Sega consoles are obviously not licensed by Nintendo. Nor are Japan-only Famicom games licensed by NOA. Therefore, you need to support more than one licensing authority, and by that point, why not support RetroZone?
byuu wrote:
An NES would be a very unlikely candidate to emulate the NES.
But an NES can configure a cartridge board with an FPGA to emulate a different board, and that's what this XML file is supposed to do: describe how to simulate a board.
Just my two cents:
I don't see how one could expect their format to be accepted if it doesn't support unlicensed games especially homebrew. You'll never gain support from the majority of people here. Gaining acceptance from nesdev would be your first step to widespread use I imagine.
Don't forget hardware requires the use hardware description. If you make things difficult/impossible for PowerPak, NESDEV1, Infinitenes, or fpga NES's nesdev will likely never adopt your format.
> I don't see how one could expect their format to be accepted if it doesn't support unlicensed games especially homebrew.
No one except people who already have my SNES emulator, and don't feel like downloading a separate NES emulator, are going to use my NES emulation anyway. So you're talking about maybe two people ever being affected by my decision on homebrew here.
That said, the point of the XML spec is to describe every officially released board. If a homebrew game stays within hardware that was commercially licensed, then all it needs is a manifest file to work. You can usually generate them from iNES 1.0 headers, unless they are like the VRC pinouts or something that's not specified, then you'll have to make the manifest by hand to fill in the missing info.
If the homebrew starts getting crazy with custom mappers and non-linear mapping, then well ... too bad. If we have no limitation, then we have to account for any theoretical situation, which is untenable. iNES can't do that, iNES 2.0 can't do that either.
Further, I am not going to waste my time emulating bootleg mappers for shoddy PS1 to NES Chinese ports, sorry. If someone else wants to do that, and add the appropriate markup IDs to the XML format to run those carts, great! Be my guest. The nice thing about using XML is that it's infinitely extensible. So you can add stuff when you need to without breaking older stuff. So for that, you can do <crazybootlegchip><!-- describe segmented PRG, extra circuit boards attached to the initial board, whatever you want --></crazybootlegchip>, and leave the base spec we're discussing alone. Put all the PRG and CHR inside <crazybootlegchip> if you have to, whatever.
> If you make things difficult/impossible for PowerPak, NESDEV1, Infinitenes, or fpga NES's nesdev will likely never adopt your format.
I've been watching discussions on formats for a long time, it's a predictable pattern.
Guy comes up with format, most people throw a fit because iNES 1.0 is just fine, and they don't want to support anything more than their iNES+DB that's already working for them.
Guy tries to get more people on board, gathers suggestions, keeps adding to spec.
Eventually you end up with the complexity of UNIF, and nobody uses it.
Or maybe you streamline it to be fully backward-compatible like iNES 2.0, and nobody uses it.
Either way, most people will still give you grief about it being a new spec, no matter what you do.
Point being, iNES 1.0 is as eternal as CR-LF text files and IPS patches.
I'm not worried about it. The whole world can complain, my emulator will use XML, and come with tools to convert iNES to it. Don't like it and won't use the emulator as a result? Great, no loss to me.
Call it rude, arrogant, inconsiderate, whatever. This is the only way to create a new spec that will ever be used by anyone else: an emu author has to make it, implement it, and require it.
byuu wrote:
If a homebrew game stays within hardware that was commercially licensed, then all it needs is a manifest file to work.
Thank you. I can get behind a spec that supports at least the mappers currently available to homebrew, which for now means the common discretes supported by the ReproPak (NROM, CNROM, BNROM, GNROM, AOROM, UNROM, and flip-UNROM used by Crazy Climber), their oversize extensions as commonly interpreted by existing emulators, and MMC1. I guess some of my rage just spilled over from the "everything worthwhile to play is licensed by Nintendo; your righteous efforts in developing an original unlicensed game are like
filthy rags" tone of early ZapFC.
Quote:
Further, I am not going to waste my time emulating bootleg mappers for shoddy PS1 to NES Chinese ports, sorry.
I see your point about these. Someone else who cares about obscure mappers, such as CaH4e3, can supply a patch to support such a board. But some of these Chinese demakes, such as FFVII, run on mappers that don't provide much functionality beyond an oversize extension of BNROM anyway, so an xor.gz/ups/bps patch to turn such a game into a proper mapper 34 binary might be one solution until someone else implements a patch to support such a board.
Likewise, someone else who cares could write a tool to convert Pasofami manifests to XML manifests.
And technically, LJ65 might be considered a PS1 to NES demake, albeit not Chinese and using NROM-128 instead of a Chinese bootleg mapper. The series on which "Bottom rotation" is based began with a
game on a PS1-based Capcom ZN-2 board.
Quote:
Or maybe you streamline it to be fully backward-compatible like iNES 2.0, and nobody uses it.
As I see it, part of the problem with lack of adoption of NES 2.0 appears to have come from the fact that Nestopia hasn't had an update in four years.
Quote:
The whole world can complain, my emulator will use XML, and come with tools to convert iNES to it.
I can support that, just as I supported headerless .sfc files. My sticking point is making sure not to reject the following ROM images:
- Original homebrew programs that use a licensed board, which you have stated you will accept.
- Unlicensed games that your emulator's users are likely to have actually owned, such as those by Camerica and Color Dreams. I currently own a copy of Bee 52, and at various times, I have owned a copy of Bible Adventures, The King of Kings, and Exodus.
Thanks for that explanation byuu.
With your goals and purpose I agree this format is very fitting. I can definitely relate and support your decision to not support every crazy pirate mapper out there. And the fact a manefest file will allow a homebrew to work solves any rational complaints against your emu mapper support.
byuu wrote:
I've been watching discussions on formats for a long time, it's a predictable pattern.
Guy comes up with format, most people throw a fit because iNES 1.0 is just fine, and they don't want to support anything more than their iNES+DB that's already working for them.
Guy tries to get more people on board, gathers suggestions, keeps adding to spec.
Eventually you end up with the complexity of UNIF, and nobody uses it.
Or maybe you streamline it to be fully backward-compatible like iNES 2.0, and nobody uses it.
Either way, most people will still give you grief about it being a new spec, no matter what you do.
I believe
xkcd properly describes the situation with NES ROM formats:
Too bad there's one standard now and forever, iNES. In 10 years, iNES 2.0 will be there and this won't be anywhere. Deal with it and move on from this garbage.
This thread is amazing.
I think a comprehensive database for correcting ROM headers is really cool.
I'm not sure what the point is for a new format though. The database solves the problem of bad/inadequate headers; what problem does the new format solve?
The other problem to consider is that if you want to proliferate a new format you must make ROMs and distribute them. Presumably a big reason you want a database instead of just fixing the headers is that you don't want to open yourself up to the liability that distributing ROMs does.
I mean, you can easily make a corrected set of iNES ROMs of all licensed games (barring the few licensed games iNES is not good enough for). The real problem is getting it out there. With a new format you have the same liability problem that comes with distributing ROMs, combined with the format-inertia that has already been discussed.
Anyhow, good luck. I hope you maintain your database project, because I think that part is worthwhile. If you think you can get a new ROM format going, well, go ahead and try, but I think you have yet to present a compelling problem that this new format will solve that the database alone doesn't.
FitzRoy, I'm sorry if I've attacked your character. You are one stubborn, self-promoting dude (or dudette) though :D (aren't we all?)
FitzRoy wrote:
You pretty much flat out said that board serials could imply everything.
Not everything. Boards do decide which chips they accept in their layout, I never meant to imply that boards can imply when a chip location is populated, and with what. My argument is that there isn't a need for chips to be listed (unless everything was for completeness, or netlist emulation), and instead argue that the IC population are attributes of the board.
Sometimes you wouldn't even be able to list a chip when for example the name was scratched off. Also since many boards don't have IC designators this makes it a little tricky to pull off elegantly because you're listing ICs without context. What if a board may accept one, two or zero '139 all affecting mapping (they have pullups on their inputs)? When you just list some chips it may be difficult or impossible for the emulator to decide on the appropriate logic, much less put together the logic from the description. Or maybe the cart uses programmable logic (a few licensed FC games do) and it's extremely difficult to know if the logic is revised or not, it's difficult to even denote two revisions of the same chip without going back to arbitrary attributes.
Maybe I'm using the wrong paradigm, perhaps the board should enumerate each set of PCB pads and what's in them. That is a LOT of info for emulators with hardcoded logic though.
In my opinion the best formats won't have these kind of personal touches, but if they're necessary given software constraints, don't beat around the bush and make up complex solutions that still fall short, might as well take the easy, simple solution and make it elegant.
---
RE non-linear mapping: not only do SNES games do this, but a few Neo Geo games do it for graphics protection and lots of arcade games have several ROMs containing various types of tile layouts all on the same bus. Sometimes they can't be addressed linearly because the video logic pre-decodes the ROMs by their purpose. Sometimes instead of wasting resources on creating a virtual address space each ROM's address lines may come directly from its respective system. I don't have any specific instances of it but ROMs have been known to have their address lines swapped from their JEDEC pinout.
Quote:
There are no jumper pins on which an actual jumper shunt would go
Solder jumpers are jumpers too.
Quote:
But the mapping code within the emulator isn't written with a specific size in mind. It basically expects a range of validities and will function according to what you give it.
I'm not sure I understand. Since you are letting people input arbitrary byte-aligned ROMs there's ambiguity on how to interpret non-2^n values. Also if only 2^n values or a small series of them are valid, then it'd probably be better to not use a byte count at all instead opt for the industry-preferred kilobits, megabits etc.
Quote:
> This I have to hear.
I am genuinely interested, who here wouldn't be?
Quote:
An NES would be a very unlikely candidate to emulate the NES.
A NES doesn't have to, but since it can why not allow it to use an alternative (like 16-bit checksums) at the user's own risk? I wasn't thinking so much about the feasibility of hashing one file, more like the time to audit a ROM set on tomorrow's computing devices which may or may not have crypto-acceleration which may or may not be accessible under 3 layers of virtual machine to user programs.
Quote:
then one could leave the hashes for a validation tool.
Oh, right. I guess I'm still fuzzy about how the format is meant to be used.
After the emulator opens the ROM set, does it directly look up the game's name in the database or does it directly hash the program and character file if applicable and search for a match? Or does the ROM set now include the XML?
Edit edit: or is the XML meant to be used with a visual ROM loader?
> Unlicensed games that your emulator's users are likely to have actually owned, such as those by Camerica and Color Dreams. I currently own a copy of Bee 52, and at various times, I have owned a copy of Bible Adventures, The King of Kings, and Exodus.
In that case, I really hope Bible Adventures uses some non-standard hardware. Religious proselytization in a children's video game is disgusting :P
> In 10 years, iNES 2.0 will be there
Hahahahahahah, keep dreaming. I'll bet you all the money in my 401K that won't happen. Even No-Intro has zero interest in it.
Moving on from iNES requires more than 10% of people to agree on anything. Judging from this thread, that'll be one cold day in hell.
You
must remove support for iNES 1.0 first, and nobody here is idealistic enough to do that. Casual gamers will never upgrade their ROMs if you continue to support them in 1.0.
> and this won't be anywhere. Deal with it and move on from this garbage.
http://www.youtube.com/watch?v=XgRLG1tl9DE#t=47s
byuu wrote:
Imagine a translation released with an included board file (or manifest as I call it.) It has "hash=(32 characters)". How does your emulator know how to match it ... is that SHA256, or SHA3? There's no guaranteeing future hashing algorithms won't use the same number of bits, and no guaranteeing old-style data won't be loaded in.
Basically, the game would fail to load, which is what would and should happen. If a sha256 hash keeps working, then why would anyone switch to sha3?
But let's say you legacy supported everything and just pretended that people updated. You could write a version tag into every manifest file. If version 11 adds sha3 support, then the emulator would know by the version tag what hash type the manifest contains.
Quote:
The SNES loves to do this, which is why the SNES has the map mode+offset+size attributes.
*If* any NES games do this, then it's most likely a detail of the mapper. Mappers are kind of a recurring trend on the NES.
If the SNES did this, then you're referring to 1YAON boards and stuff where the program is multi-chip, but could have or was released single chip on a 1A0N. If the 1YA0N board behaves differently than a 1A0N board, but the behavior is superfluous in output to the 1A0N variant, then I see no reason to release the rom in both variations and give them each their own mapping entry. The destination is the same even if the journey was different, it's redundant.
who the hell says you have to remove support? that's why there's a 2.0 flag, to tell you when to use the extensions. You shouldn't need to change anything, people just have to write newer emulators. And oh yeah, like THIS is going to take over iNES. That'd be a colder day in hell.
> Basically, the game would fail to load, which is what would and should happen. If a sha256 hash keeps working, then why would anyone switch to sha3?
I am not catering to people who won't upgrade. Life is too short to convince people like those in this very thread. I'd have as much luck convincing people to switch religions and political parties.
Whatever, I tried. It's your format, so go with hash if you feel it is best.
> If the SNES did this, then you're referring to 1YAON boards and stuff where the program is multi-chip
Dude, if there's one thing where anyone should trust what I say, it's SNES stuff.
All games do this stuff. Banks $00-3f and $80-bf reserve A15=0 for I/O, RAM, and other uses. You can't map a 100% linear ROM in there unless its exactly 32KB.
It's not a big deal. I just use the manifest to tell the emulator where to mirror ROM to.
> And oh yeah, like THIS is going to take over iNES.
No one ever said it was going to.
I would actually prefer pessimists to stay away from my format entirely. I'd prefer all the casual gamers use your emulator instead (assuming you have one. But yeah, besides FitzRoy, who here doesn't?) Better you deal with them than me.
I wish I wasn't lumped into this thread in the first place. I'd rather discuss my format on my board.
Yeah, let's do that. If anyone would like to continue the discussion on my spec, post at board.byuu.org. This is the ZapFC thread, so discuss ZapFC here only please.
byuu wrote:
Dude, if there's one thing where anyone should trust what I say, it's SNES stuff.
All games do this stuff. Banks $00-3f and $80-bf reserve A15=0 for I/O, RAM, and other uses. You can't map a 100% linear ROM in there unless its exactly 32KB.
It's not a big deal. I just use the manifest to tell the emulator where to mirror ROM to.
I do, I just am not understanding programmer speak for what's going on here. When you were working with me on NES db markup, at no point did you say that it was necessary to define hex ranges and stuff in there. I know that you do that with the SNES manifests, but is it really necessary or is it a function of not having and calling "[board].cpp" like you do with NES?
Are you sure you want to discuss this here? It'll detract from your NES format discussion. But well, think of it like this:
On the NES, you can have the MMC1 or MMC3, and these chips control what ROM data is mapped to what bus address range (eg it controls what the CPU reads from certain areas.)
Their biggest use is that the NES is limited to 32KB ROM space. So you write to these chips to ask it to swap some (or all) of that space with other ROM data.
The only analogues on the SNES are the SPC7110, S-DD1 and the BS-X town cartridge. Possibly the SA-1 if you stretch the definition. And true to form, when those are described in my markup, they just say "these bus addresses can be remapped by these chips."
When it comes to all other SNES carts, they can easily map up to ~10-12MB into the existing address space without a bank mapper. So in all honesty, the bank remapping is pretty stupid. There was no SNES game that ever required that functionality. It just made SO and FEoEZ harder to develop.
So most SNES games had their own mapping chips. The most popular was the MAD-1, but it was overkill for the simplicity of games on eg 1A0N boards. Those just used simple logic gate chips like the 74LS series. What these chips do is translate SNES bus addresses to ROM and/or RAM chip addresses. It selects the appropriate chip for an address, and transforms the address to be linear for that individual chip.
So in a very real way, we could replace all of the <map address=... offset=... size=...> stuff with <mapper type="MAD-1" pinout="..."/>, and reproduce the map that way as well. But that's a lot like saying "we can eliminate half the board types on the NES", a lot of these boards are just simple 74LS logic chips once again. Only they're a tiny bit more advanced, since they have primitive bank mapping by way of being writable (they are decade counters, usually.)
So when we say "NES-CNROM", we are really saying "board with a 74LS decade counter connected to these pins of the ROM address line." And when we say "S-DD1", we are saying something similar about that mapper+ROM chip. And when you talk about a0=x,a1=y pinout on VRC-n boards, what you're really doing is describing the only pins that change between officially released titles. The real VRC chip probably has something like 20 - 80 different pins on it. It's a huge jump to allow arbitrary connection of those pins to support any possible configuration (even non-sensical ones like connecting +5V to bus audio left channel, for instance.)
Now it would be nice to come up with an implementation that allowed us to wire every pin between every chip in XML, but it would be an absolute nightmare to emulate such a beast, and performance would drop dramatically. Think about that Pong circuit simulator I used to talk about, or Visual 6502. And I think we both know that's not an option at this point anymore.
My SNES XML maps build a 16MB mapping table, so that when you read an address, all it has to do is a memory fetch to determine what type of memory is there, then call a function pointer form a table indexed by that type. That function can mask the address, and return the underlying memory. Even this is already painful, but it's very linear.
Trying to do a chip-level simulation would be far more complicated. And I'd be surprised if we didn't have NES carts with more than one 74LS chip.
There is also the fact that with the SNES, I'm more interested in homebrew development there. For instance, there would be no way to do the FEoEZ expansion nor run neviksti's Star Ocean 96mbit patch, if not for the XML remapping. And we don't even really have all the details of the pinouts for all logic mappers on the SNES side, so we couldn't simulate that even if we wanted to.
Technically, the SNES XML format I use can do everything SNES-used 74LS and MAD-1 chips can do, and much more. And it results in faster emulation. But it does make the spec more complex. The same, however, cannot be easily done on the NES, because unlike the SNES, the NES almost always needs to bank-swap in more ROM data. You can't describe something like that with just a plain list of range+offset+length entries. The underlying content changes dynamically.
This is basically the big problem I have with MAME/MESS. You can't mash every system ever into the same structure. It just makes them all overly complicated and confusing. Instead, you should take into account the realities of each system, and make something that works best for it. And I'll say right now, I don't currently have the expertise to do this for the NES, like I do for the SNES. So my spec is very much going to be evolving for the next several years as I learn more.
To be quite honest, I don't even think it's appropriate for emulators to share an XML game mapping. It's highly dependent upon how the emulator was developed. It really should all be done internally with a database for games. But the problem there is you just can't support homebrew that way, so at some point you -have- to describe something for board formats. And then you get people jumping down your throat thinking you're out to kill iNES 1.0, which is nonsense.
As such, worrying about a hypothetical NES cart with non-linear mapping of two PROMs is kind of silly. You're going to need a logic chip to decode the bus address and select the appropriate chip anyway. So we specify that logic chip in the markup, and the emulator will know what to do with it.
byuu wrote:
Are you sure you want to discuss this here? It'll detract from your NES format discussion.
It's probably a good idea to split at the revival point, seeing how little of this relates directly to FitzRoy's proposal.
Appreciate the split, but can we lock this thread and move the discussion to my forum? The people using my emulator are much more likely to be affected, and thus to have input on the spec. And it applies to much more than just the NES.
My forum is at board.byuu.org, and anyone who wants to continue the discussion can do so there. Thanks!
I'll lock it once my account there is activated.
byuu wrote:
Appreciate the split, but can we lock this thread and move the discussion to my forum?
tepples wrote:
I'll lock it once my account there is activated.
Seriously?
So, let me get this straight: byuu gets upset that the discussion isn't going his way and decides he only wants to discuss it on his own turf. Fine, whatever. But locking the thread to prevent others from continuing the discussion accomplishes what, exactly? Not a good precedent...
I think splitting may have killed the thread anyway.
James wrote:
So, let me get this straight: byuu gets upset that the discussion isn't going his way and decides he only wants to discuss it on his own turf. Fine, whatever. But locking the thread to prevent others from continuing the discussion accomplishes what, exactly? Not a good precedent...
Settle down, there's no conspiracy here. If we want to continue discussing byuu's format here we can. However, since byuu won't be participating, there's not much point. If he wants to discuss it on his forums, that's his right. If we want to complain and moan here with nobody listening, that's our right - just not very productive.
The only sensible solution is to fork byuu's format and start our own
/scarcasm
Seriously, leave the guy alone. He's drawn a line in the sand for his emulator and said he'll only support this new format. Who cares? He's done it deliberately, and with full knowledge of the landscape of the NES scene and the repercussions of that decision. He's not asking anyone else to use it, and isn't proposing it as a replacement for iNES. Let's turn our attention to more important things.
teaguecl wrote:
He's not asking anyone else to use it, and isn't proposing it as a replacement for iNES.
If byuu weren't providing a converter from iNES (1 and 2), he'd be asking other people to release their ROMs in his format. But as long as he provides a converter, we can consider this an "intermediate representation", an implementation detail of the emulator, just as GBA and DS games need to be "converted" to run on certain flash adapters.
It's pretty easy these days to deliver an emulator-specific rom format if one felt that the legacy standard was holding back compatibility gaurantees. A set of 2300 files uploaded to numerous hosting sites and linked to on several forums would eventually show up on filesearch engines and google. You can't convert a bad or missing header into a working file, any sort of tool would take significantly longer and be less reliable than finding one of these links where the conversion work has been done for you.
It's as if iNES is the worst thing in the world reading your guys posts. It's pretty laughable people really are going against it since it's perfect and even extendable by default.
"iNES sucks."
"You implement iNES 2.0 to fix every problem there could be in the future?"
"No, because it sucks and 2.0 doesn't exist yet because no ROM uses it"
"It's as if they don't need it yet....weird."