nesdev.org

Huh? Is ZapFC is going XML now?

I see no logical progression from a year ago in the delimited file front.

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

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.

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.

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.

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.

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.

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.

PCB jumpers?

It's an attribute of the board tag, like mirroring, etc.

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

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.

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.

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.

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

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.

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.

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.

It's an attribute of the board tag, like mirroring, etc.

"Mirroring" itself is a backwards iNES concept in place of scrolling-oriented jumpers.

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.

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?

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.

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.

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.

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

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.

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

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.

"Mirroring" itself is a backwards iNES concept in place of scrolling-oriented jumpers.

Sounds like a different name for the same thing to me.

There certainly is an advantage for people who don't have cryptographical hardware acceleration.

Since when does sha256 require a supercomputer to calculate?

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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:

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.

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.

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.