User talk:Zzo38/DotFami: Difference between revisions
From NESdev Wiki
Jump to navigationJump to search
mNo edit summary |
No edit summary |
||
| Line 5: | Line 5: | ||
::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) --[[User:Lidnariq|Lidnariq]] 01:15, 4 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) --[[User:Lidnariq|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 "<tt>bnk</tt>" 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. --[[User:Zzo38|Zzo38]] 10:41, 4 August 2012 (PDT) | |||
Revision as of 17:41, 4 August 2012
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)
