User talk:Zzo38/DotFami

ROM size

I saw this in Recent Changes, and it looks like you left only 8 bits for "bnk: Number of 8K ROM banks." Action 52 and Chinese Final Fantasy VII already don't fit, having 2048 KiB (256 banks) each. --Tepples 18:30, 3 August 2012 (PDT)

And that is one reason why it is a draft (the other reason being that it is not complete). Thanks for telling me. Is 256 the maximum? (If so, the "bnk" can be one less than the number of 8K banks; if not, it can be expanded to a sixteen bit number of banks.) Other things that could be fixed is the "cpu" field for CPU flags; it could be entirely rewritten or expanded to sixteen bits whatever seems important; if you have ideas you can post. --Zzo38 20:35, 3 August 2012 (PDT)

By now, I'd probably just use a 32-bit integer for the number of bytes and be done with it. If I really wanted to pack it into 8 bits, I'd use a IEE754-like quarter-precision structure with a 2-or-3 bit significand and a 5-or-6 bit unsigned and non-offset exponent. Almost all—but not quite—NES roms use powers of two, and while the vast majority of things cataloged as not a power of two are complete garbage, there are a few that would require awkward padding without it. Of course, not having a power of two of data is already a strange concept, since at its most basic address lines are binary. (To answer your question: there are already 3 and 4MB PRG dumps known) --Lidnariq 01:15, 4 August 2012 (PDT)

Thanks for information. (However note that this format is not only for existing ROM dumps but also for homebrew games; some of which might use their own mappers as long as their components do not differ too much from the existing ones.) Perhaps I should just make the "bnk" field to indicate the number of address lines like you suggested so it is 2 to the power of the number 0 to 255 as number of bytes (obviously this can result in extremely larger than anyone will ever need). Another possibility is to use sixteen bits for a number of banks (of some size); see what is preferred. CPU flag (not only for CPU, actually) could also be fixed, expanded to 16 bits if necessary, including also such things as the PPU differences that are switched in some VS Unisystem games and that the intensity bits have a different meaning in some systems. --Zzo38 10:41, 4 August 2012 (PDT)

Plenty of NES games don't use a power of 2. Particularly games that use CHR ROM will often be 3 or 5 times a power of 2, and there's one game that's 136 KiB (Morita Shogi: SNROM, 128 KiB PRG ROM, 8 KiB CHR ROM). --Tepples 10:55, 4 August 2012 (PDT)

And here I was misreading your "number of 8kB blocks" meaning for each PRG and CHR. Yeah, the total size is usually going to be 2ⁱ+2ⁿ; the exceptions I was mentioning above were ones where the size of PRG wasn't a power of two. --Lidnariq 11:17, 4 August 2012 (PDT)

OK. Thank you. I could expand this field to sixteen bits, and then decide what to do with it (perhaps can be total number of 8K ROM banks, unless you have better idea). --Zzo38 11:50, 4 August 2012 (PDT)

CPU mode

What's your objective in supporting nonstandard clock frequencies? AFAIK, none of the famiclones support under- or over- clocking their NES-equivalents, so breaking hardware compatibility seems odd to me. --Lidnariq 11:17, 4 August 2012 (PDT)

OK, so there are none, I suppose there is no use, I can remove that. Thanks for notifying me; I think there is still more to fix about the CPU flags though (things to add, things to remove, things to change). --Zzo38 11:50, 4 August 2012 (PDT)

VRC7 Audio

The VRC7 only existed in one hardware instantiation, with 6 channels and an admittedly unknown but nonetheless fixed group of built-in instruments; allowing these to be configured by the ROM image specifically allows the description of things that don't exist in reality. (And if you want that, you may as well define a cartridge with a full OPL2; and if you want that, you may as well use some random FM tracker.)

I'm not actually clear where any of the mapper audio bits are referred to, come to think of it. They make it seem like this format is trying to be a replacement for both .NSF and .NES at the same time.

In general, the mapper audio needs to be tightly coupled to the mapper hardware described anyway, otherwise there's no way to play it; it feels odd to call it out separately. --Lidnariq 19:12, 5 August 2012 (PDT)

I do not intend to include full OPL2 and all that stuff; I don't want too many things which are not used in existing Famicom cartridges (although some simple things might be added on, if they are both easy to emulate and easy to build hardware). I removed the number of channels, but you could change the instrument setting since "VRC7 built-in instruments are not the same as OPLL instruments" so obviously if you change the hardware then you can change the music (especially since register layout is the same anyways; so you could use OPLL but just not use the rhythm channels). For where it is mentioned: "Note that you can have multiple instances of each and that their parameters can differ as well as how the address lines are connected by using other mapper codes." The mapper codes that will tell them to be connected simply is not yet described in this document (but eventually will be). But still it is draft so things are added, removed, and changed, in order to make improvement. --Zzo38 03:40, 6 August 2012 (PDT)