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.
