possibly a dumb iNES 2.0 header question :-)

possibly a dumb iNES 2.0 header question :-)
by proxy on 2011-04-21 (#77061)

I was just wondering about bytes 10 and 11. The say the following:

Code:

Byte 10:
7       0
---------
pppp PPPP

p: Quantity of PRG RAM which is battery backed (or serial EEPROM, see below)
P: Quantity of PRG RAM which is NOT battery backed

(and similar to CHR RAM)

I understand that a table is used to map the value given in these fields to actual sizes. And bviously it is up to mapping software to determine where the PRG RAM is mapped. But I have some (possibly dumb questions):

Firstly, if I understand this right, the *total* amount of PRG RAM is these two fields combined? So a value of byte 10 of 0xAA would mean 131,072 bytes of PRG RAM?

Next, if some of the PRG RAM is battery backed, which of it is battery backed? The first portion? The last?

So for typical carts which just use the usual 8K CHR RAM, non-battery backed, can I just expect a value 0x07? I know this last one seems obvious, just wanted to make sure I wasn't missing something :-)

.

Thanks

by koitsu on 2011-04-21 (#77062)

That information seems to be very, very strange. Please see this instead:

http://wiki.nesdev.com/w/index.php/INES

by proxy on 2011-04-21 (#77063)

@koitsu: Thanks, but I am talking about the NES 2.0 standard found here: http://wiki.nesdev.com/w/index.php/NES_2.0

Re: possibly a dumb iNES 2.0 header question :-)
by tepples on 2011-04-21 (#77065)

proxy wrote:
Firstly, if I understand this right, the *total* amount of PRG RAM is these two fields combined? So a value of byte 10 of 0xAA would mean 131,072 bytes of PRG RAM?

Correct. But they're not necessarily contiguous; see my next answer.

Quote:
Next, if some of the PRG RAM is battery backed, which of it is battery backed? The first portion? The last?

How bank numbers are translated to chip selects depends on the mapper. In MMC1, for example, the only board supporting multiple PRG RAM chips is SOROM, which provides 8 KiB at bank 0 and 8 KiB at bank 2. Bank 0 is always without battery, and bank 2 usually has a battery.

Quote:
So for typical carts which just use the usual 8K CHR RAM, non-battery backed, can I just expect a value 0x07?

Yes, or 0x70 if the battery bit is on.

by koitsu on 2011-04-21 (#77066)

Sorry, for some reason I thought they had been incorporated into the same Wiki page. I was obviously wrong.

I've read the section of the iNES 2.0 document you've referenced, and I agree -- it's vague/undefined and badly written.

A value 0xAA in byte 10 would mean, effectively, that you have two 65536 PRG RAM segments, one which lacks battery-backing, the other which has it. The specification does not say if this is permitted, or if only one type is permitted.

There is an example regarding a CHR-RAM cart, Racermate, having 64KB of CHR RAM, half of which was battery-backed and other half which wasn't. This seems to imply that both "types" (see above paragraph) are indeed permitted.

So, given that assumption -- my next question would indeed be "how does one specify which segment is battery-backed and which isn't?" I can't find an answer to this in the format.

Can the authors of this format please provide clarification?

by tepples on 2011-04-21 (#77067)

koitsu wrote:
A value 0xAA in byte 10 would mean, effectively, that you have two 65536 PRG RAM segments, one which lacks battery-backing, the other which has it. The specification does not say if this is permitted, or if only one type is permitted.

Both are permitted. In fact, both are required for extant SOROM and ETROM games.

Quote:
So, given that assumption -- my next question would indeed be "how does one specify which segment is battery-backed and which isn't?" I can't find an answer to this in the format.

Which is mapped to the lower bank numbers and which to the higher bank numbers depends on the mapper. I clarified the spec to what I strongly believe was KH's intent, given what I know about SOROM and what he said about Racermate.

by koitsu on 2011-04-21 (#77072)

tepples wrote:
Quote:
So, given that assumption -- my next question would indeed be "how does one specify which segment is battery-backed and which isn't?" I can't find an answer to this in the format.

Which is mapped to the lower bank numbers and which to the higher bank numbers depends on the mapper. I clarified the spec to what I strongly believe was KH's intent, given what I know about SOROM and what he said about Racermate.

Can you draw out for me an example ROM image (file offsets and lengths) of how this would work?

I guess I'm having some difficulty understanding the whole PRG RAM concept, given that there are already defined bank numbers (well, for PRG ROM) in the header, and how does PRG RAM fit into that? I guess I'm indirectly asking why designation of RAM vs. ROM is even needed for PRG. I imagine it's a way to allow the emulator to adjust itself ("yes this area of addressing space should actually be writeable!"), but if the "mappers controls all of that", then what's the point of the data in the header?

Help me out. :-)

by tepples on 2011-04-21 (#77077)

In NESTECH 2.00, koitsu wrote:
SRAM - Save RAM: RAM which is commonly used in RPGs such as Crystalis, the Final Fantasy series, and The Legend of Zelda.
WRAM - Synonymous with SRAM.

B. Memory Map
Code:
+---------+-------+-------+-----------------------+
| Address | Size | Flags | Description |
+---------+-------+-------+-----------------------+
| $0000 | $800 | | RAM |
| $0800 | $800 | M | RAM |
| $1000 | $800 | M | RAM |
| $1800 | $800 | M | RAM |
| $2000 | 8 | | Registers |
| $2008 | $1FF8 | R | Registers |
| $4000 | $20 | | Registers |
| $4020 | $1FDF | | Expansion ROM |
| $6000 | $2000 | | SRAM |
| $8000 | $4000 | | PRG-ROM |
| $C000 | $4000 | | PRG-ROM |
+---------+-------+-------+-----------------------+

"PRG RAM" is a name that has come into use among NES software developers and emulator developers for what was once called SRAM or WRAM. "SRAM" was deemed too confusing because the CHR RAM chips were also SRAM (static random access memory), and the chip mapped into $6000 might in fact be FRAM, PSRAM, or even I²C serial EEPROM.

koitsu wrote:
Can you draw out for me an example ROM image (file offsets and lengths) of how this would work?

SOROM: MMC1, 256 KiB PRG ROM, 8 KiB+8 KiB PRG RAM, 8 KiB CHR RAM

Ambitious General.nes (262160 bytes)
0x000000-0x00000F: header
iNES header (bytes 0-7) specifies mapper 1, 16*16384 bytes PRG ROM, no CHR ROM, and battery-backed PRG RAM
NES 2.0 extension (bytes 8-15) specifies 8192 bytes CHR RAM not battery backed, 8192 bytes PRG RAM not battery backed, 8192 bytes PRG RAM battery backed
0x000010-0x04000F: PRG ROM data
0x040010: EOF
Ambitious General.sav (8192 bytes)
0x000000-0x001FFF: Data in the battery-backed PRG RAM bank, which on SOROM is bank 2
koitsu wrote:
there are already defined bank numbers (well, for PRG ROM) in the header, and how does PRG RAM fit into that?

SOROM and SXROM provide two bank number registers: 4-bit PRG ROM bank at $E000, which is common to all MMC1 boards, and 2-bit PRG RAM bank at $A000, which only SOROM and SXROM have. This is a repurposing of a register in the MMC1 that ordinarily controls CHR ROM bankswitching, but because there's only 8 KiB of CHR RAM on all existing MMC1 boards with CHR RAM, it isn't needed for that purpose.

koitsu wrote:
I guess I'm indirectly asking why designation of RAM vs. ROM is even needed for PRG.

"PRG" has come to mean any memory ICs on the cartridge's CPU bus. Games have PRG RAM because they need extra space to decompress a destructible map or because they need to save more data across a power cycle than a password can comfortably hold.

by Bregalad on 2011-04-22 (#77084)

I agree it's badly defined, but in the end it would all be down to what the mapper does.
In MMC1's case, the following "official" combination should be permitted :

SOROM : 8k with battery, 8 k without battery :
bank 0 is without battery and bank 2 with battery. Banks 1 and 3 mirror banks 0 and 2 respectively

SOROM : 16k without battery.
bank 1 mirrors bank 0 and bank 3 mirrors bank 2.

SXROM : 32k with battery :
all 4 banks are saved

SXROM : 32k without battery :
4 banks are emuled but not saved.

Of course with another mapper (MMC5) it would end up completely different.

by kevtris on 2011-04-26 (#77237)

tepples wrote:
koitsu wrote:
A value 0xAA in byte 10 would mean, effectively, that you have two 65536 PRG RAM segments, one which lacks battery-backing, the other which has it. The specification does not say if this is permitted, or if only one type is permitted.

Both are permitted. In fact, both are required for extant SOROM and ETROM games.

Quote:
So, given that assumption -- my next question would indeed be "how does one specify which segment is battery-backed and which isn't?" I can't find an answer to this in the format.

Which is mapped to the lower bank numbers and which to the higher bank numbers depends on the mapper. I clarified the spec to what I strongly believe was KH's intent, given what I know about SOROM and what he said about Racermate.

You are right- It is not "Badly defined" It is mapper defined. The RAM size byte simply says how much of each kind of RAM is present- it does not specify where it goes, because this is a function of the mapper.

There's two nybbles in the spec for each kind of RAM, because it could have battery backed RAM, non-backed RAM, or both (and of course none).

If the mapper does not support any RAM, then of course you cannot legally set the RAM byte, since the mapper won't know what to do with it. This case is undefined, and each emulator will probably do something different. (the proper case is to reject the ROM saying it has a bad header IMO)

In the case of MMC5, there can be two 8K RAM chips on the cartridge- one battery backed, and one that isn't. Same with Racermate. This cartridge has two CHR RAMs. One is battery backed while the other isn't. Though to be fair that particular game doesn't get a special ines2.0 header because there is only one form of cartridge in existance.

MMC5 on the other hand (and MMC1) have multiple kinds of cartridges. For MMC5, the following exist:

8K non-backed
8K backed
16K (8K backed, 8K non-backed)
32K backed

MMC1 has the same set of RAM possibilities too.

It's up to the mapper to determine where these RAMs map, and they always map the same way for a given RAM configuration.

by tepples on 2011-04-26 (#77240)

Thanks for the clarification. But you raise another question:

kevtris wrote:
If the mapper does not support any RAM, then of course you cannot legally set the RAM byte, since the mapper won't know what to do with it. This case is undefined

Why not define it the same way that Family BASIC defines it and the same way that emulators have defined it since the dawn of NES emulation?

"Most discrete logic mappers never had any boards with PRG RAM. Others had only one or two releases with PRG RAM, such as Family BASIC on mapper 0. If a mapper doesn't natively provide PRG RAM support nor have any registers in $6000-$7FFF, emulators should extend the mapper in the same way that Family BASIC extends mapper 0: the header specifies up to 8192 bytes, decoded into $6000-$7FFF by a 74HC20 or 74LS139."

by tokumaru on 2011-04-26 (#77248)

I agree with tepple's suggestion. During development, PRG RAM can be used for outputting data. I for example enable PRG RAM temporarily just to record level demos. If emulators refused to load my ROM just because it has a mapper that doesn't officially support PRG RAM I wouldn't be able to do this.

by kevtris on 2011-04-27 (#77288)

tepples wrote:
Thanks for the clarification. But you raise another question:

kevtris wrote:
If the mapper does not support any RAM, then of course you cannot legally set the RAM byte, since the mapper won't know what to do with it. This case is undefined

Why not define it the same way that Family BASIC defines it and the same way that emulators have defined it since the dawn of NES emulation?

"Most discrete logic mappers never had any boards with PRG RAM. Others had only one or two releases with PRG RAM, such as Family BASIC on mapper 0. If a mapper doesn't natively provide PRG RAM support nor have any registers in $6000-$7FFF, emulators should extend the mapper in the same way that Family BASIC extends mapper 0: the header specifies up to
8192 bytes, decoded into $6000-$7FFF by a 74HC20 or 74LS139."

Yeah, this case is taken care of by ines 1.0. The idea with 2.0 is that it's only used when it is needed. Most cases will not need to use it. Mapping WRAM in for mappers that can use it, but do not need the 2.0 extensions should work like they always have up to this point using the original flavor of ines.

2.0 is designed mainly to disambiguate roms that cannot be properly described in 1.0. i.e. MMC1 extra RAM, or MMC5 extra RAM (16K+ RAM mainly).

My original idea was to have 2.0 disambiguate the corner cases and other oddities that are currently being done using CRC checks.

However, I don't see a problem with allowing a "stock" 8K of WRAM on any mapper in the 2.0 header even if the mapper doesn't natively support it. This could be used to advantage for specifying things such as 16K WRAM on mapper 66 (Memblers used this for his garage cart) or the 8K of WRAM for the family basic case.