nesdev.org

Posted: **Fri May 18, 2012 6:33 am**

In [url=http://nesdev.com/bbs/viewtopic.php?p=93977#93977]this post[/url], byuu wrote:v089 and above will only load images in the FC spec:
Code: Select all
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]

Posted: **Fri May 18, 2012 9:38 pm**

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: Select all

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

Posted: **Sat May 19, 2012 12:09 am**

byuu wrote:FitzRoy's spec is:
Code: Select all
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.

Posted: **Sat May 19, 2012 5:40 am**

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.

Posted: **Sat May 19, 2012 6:48 am**

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

Posted: **Sat May 19, 2012 7:24 am**

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?

Posted: **Sat May 19, 2012 8:01 am**

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.

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.

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.

Posted: **Sat May 19, 2012 8:18 am**

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

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.

Posted: **Sat May 19, 2012 4:15 pm**

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

Posted: **Sat May 19, 2012 6:00 pm**

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: Select all

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

Posted: **Sat May 19, 2012 6:09 pm**

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

Posted: **Sat May 19, 2012 6:13 pm**

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.

Posted: **Sat May 19, 2012 6:42 pm**

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!

Posted: **Sat May 19, 2012 9:02 pm**

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.

Posted: **Sat May 19, 2012 11:09 pm**

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.

nesdev.org

byuu's XML format

byuu's XML format