It is currently Mon Nov 20, 2017 11:53 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sat Mar 11, 2017 9:17 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
http://bootgod.dyndns.org:7777/profile.php?id=3344
http://bootgod.dyndns.org:7777/profile.php?id=1602
http://bootgod.dyndns.org:7777/profile.php?id=1599
http://bootgod.dyndns.org:7777/profile.php?id=3842

There is a battery but no external RAM on the circuit board. Looking at what addresses Battle Fleet accesses when saving the game, it seems that the battery powers the 128 bytes of the Namco 163 chip that other games use for sound generation ($4800). How would this properly be described in the NES 2.0 header? The PRG-NVRAM field seems to always apply to the $6000 range, and the 128 bytes of the Namco 163 chip are emulated in all emulators regardless of the PRG-(NV)RAM field's content.


Top
 Profile  
 
PostPosted: Sat Mar 11, 2017 12:12 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6446
Location: UK (temporarily)
We haven't decided... see my comments on the wiki.

Reproduced here for ease of threading:
lidnariq wrote:
I'm torn about how to deal with RAM-inside-mappers. As far as I know, there are five ICs that have some: MMC5, MMC6, X1-005, X1-017, and Namco 163.

Some of these are easy: for the MMC6, X1-005, and X1-017, their internal RAM is at the exclusion of external RAM. The RAM size byte can just hold $40, $01, $10, or (per rounding up) $70 as appropriate.

For the MMC5, that RAM can be thought of as either of CPU or PPU memory, it's not clear whether it should be marked (and where it should be marked). Apparently no game ever battery-backed only the 1k internal RAM, so perhaps leaving the RAM size byte at 0 for MMC5s without external RAM is best, even if it's contradictory to the advice for the previous three. Only 2k, 8k, and 32k RAMs were available during the MMC5's commercial life, and they were only ever combined as (none, 8+0, 8+8, 32+0); clearly adding 1024 and rounding up would cause nonintuitive values here. (As an aside, there's also no way to express the 2+8 or 8+32 configurations in NES2.0; fortunately neither were used commercially)

The N163 came in 3 of the 4 possible variants: neither battery nor external RAM; battery but no external RAM; battery and external RAM. The first two would easily be $01 and $10, but the last worries me—adding internal+external and storing the rounded-up value in the "RAM size" means we'd have $80=16384 for 8192+128 battery-backed, or $60=4096 for 2048+128 battery-backed. This feels unintuitive to me. Simply always excluding internal RAM here (in addition to being contradictory to the advice given for the MMC6) means we'll have the nonsensical value 0 with the battery bit set in the rest of the header. Maybe the right answer is to only count the internal RAM when there's no external RAM? —13:43, 10 February 2013 (MST)

We can add the Datach system to the list. It provides a 256 byte EEPROM that is not strictly speaking part of the game, but rather the cartridge converter, and thus is shared between games. Perhaps here the byte should indicate whether the game uses the EEPROM, rather than whether it's available. —03:04, 14 August 2013 (MDT)


Top
 Profile  
 
PostPosted: Fri Sep 08, 2017 12:43 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
Having taken a closer look at all battery-bearing Mapper 19 games, no game seems to use both chip RAM and WRAM to store save data:

Games with battery that only powers the internal 128 bytes of chip RAM. They can be easily represented by setting PRG-NVRAM to 128 bytes:
Games with battery that powers only 8192 bytes of WRAM and use chip RAM for audio and thus cannot use it for save data. They can thus be represented by setting PRG-NVRAM to 8192 bytes and PRG-RAM to 128 bytes (the latter for consistency):NesCartDB does claim that King of Kings backs both chip RAM and WRAM, but that seems implausible given that the game uses expansion audio and has well-working save/restore in emulators that do not save chip RAM.

Juvei Quest has a battery that powers only the 8192 bytes of WRAM and doesn't access the chip RAM at all, especially not during restore/save. It can thus be represented by setting PRG-NVRAM to 8192 bytes and PRG-RAM to 128 bytes, since the chip registers do not need to be saved.

Dokuganryuu Masamune has 8K of WRAM which is not battery-backed. Accordingly, when selecting CONTINUE, only the 128 bytes of chip RAM are accessed, and during saving, the game state is output to chip RAM. This game can thus be represented by setting PRG-NVRAM to 128 bytes and PRG-RAM to 8192 bytes, since WRAM is not battery-backed.

If someone could confirm that King of Kings' chip RAM is not battery-backed, contrary to NesCartDB's entry, then the problem of 8192+128 NVRAM would not exist, and the NES 2.0 headers of these games would be as described.


Top
 Profile  
 
PostPosted: Fri Sep 08, 2017 1:21 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6446
Location: UK (temporarily)
With the N163, it's not possible to battery-back the 8 KiB PRG RAM without also battery-backing the 128B audio RAM.

I mean, there's basically three options here for the value desired in the header, right?

Code:
 ....................... | option 1 | option 2 | option 3
 ....................... | bat? B10 | bat? B10 | bat? B10
N163, no battery, no RAM | no    01 | no    01 | no    00
N163, battery, no RAM    | yes   10 | yes   10 | yes   00
N163, no battery, WRAM   | no    08 | no    07 | no    07 -- there aren't any of these, right?
N163, battery, WRAM      | yes   80 | yes   70 | yes   70


Option 1, per the "round up" rule, produces non-intuitive results. There isn't 16 KiB of anything.
Option 2 is internally inconsistent: the 128B are marked when they're the only thing present, but ignored when they're not.
Option 3 also has non-intuitive values. But it does accurately represent the amount of memory added.

I kinda like option 3 better ... it feels more uniform if the correct value for mappers with ASIC-internal storage is that they aren't counted.


Top
 Profile  
 
PostPosted: Fri Sep 08, 2017 1:28 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
No, there's a fourth option, which is the one I like best: for battery+WRAM games, pretend that the N163 isn't battery backed (B10=$71), even though it actually is, because it isn't used for save data, and so an emulator doesn't need to save it. It's only non-intuitive if you think of the NES 2.0 header as an all-purpose hardware description as opposed to a a set of instructions for an emulator.

If that is too kooky for you, then I opt for option 1 --- rounding up to 16K in the NES 2.0 header, and having the mapper code adjust the actual size of the SRAM file. Option 3 is bad for a Nintendulator Mapper DLL because the sum of PRG-RAM and PRG-NVRAM defines the maximum size that the SRAM file may take, so one would have to modify the main emulator core to implement such a thing. It would also create an inconsistency between Mapper 19 and the MMC6, which doesn't add any external WRAM on the PCB either.


Top
 Profile  
 
PostPosted: Fri Sep 08, 2017 8:01 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6446
Location: UK (temporarily)
NewRisingSun wrote:
Option 3 is bad for a Nintendulator Mapper DLL because the sum of PRG-RAM and PRG-NVRAM defines the maximum size that the SRAM file may take, so one would have to modify the main emulator core to implement such a thing
Surely that knocks out option 2, also?

I'm still uncomfortable with option 1.

There's certainly some merit to saying that the header value should indicate how it's actually used. It would resolve the Datach mess neatly—mark with $20 for the (singular, pack-in) game that uses the internal EEPROM, and mark with $10 for the games that use an external EEPROM.

On the other hand, it drastically increases the amount of effort that someone has to go to in order to choose a correct set of headers. It's not just enough to say "this is what's present" but now you have to exhaustively analyze the game to make sure whether something nonvolatile is never used. Is this an acceptable cost?


Top
 Profile  
 
PostPosted: Fri Sep 08, 2017 8:14 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
How about redefining value $F, which so far is "reserved", to something useful for this purpose. How about defining value $F to mean "mapper-specific size"? It would be defined as 5120 for Mapper 82, 8320 for Mapper 19, and 384 for Mapper 157. One would still have to modify the core emulator executable for this purpose (similar to options 1 and 2), but at least it would be for something that is clean and precise.


Top
 Profile  
 
PostPosted: Fri Sep 08, 2017 8:23 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6446
Location: UK (temporarily)
Tentatively, I like that, but I should sleep on it to see if I still think that sounds good tomorrow.

Alternatively, maybe some emudevs (Sour? Fhorse? YoukaiCountry? zeroone?) could pop in and offer an opinion?


Top
 Profile  
 
PostPosted: Sat Sep 09, 2017 5:53 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 299
I'd be tempted to say we shouldn't use the prg ram bits to count built-in mapper RAM that cannot be removed from the cart, but only any optional RAM that can.
e.g in this case, it will always have that 128 bytes of internal ram, there isn't even a way to remove it from the cartridge, so from my point of view, that's more or less part of the mapper's definition.

If the worry is to indicate whether or not that ram is battery backed, a submapper might be good enough? e.g: submapper 0: use battery flag, submapper 1: not battery backed. This would apply well to mapper 19 & 82, imo.
157 on the other hand is eeprom, so always "battery-backed" - since there are different non-standard memory sizes available for the mapper, submappers might be sufficient here too?

Using reserved as "mapper-specified" ends up having to use submapper numbers to specify different sizes if needed, too, so we might as well just use submappers directly and avoid using that altogether.

Just my opinion - I'm far from an expert on mappers, after implementing hundreds of them, you kind of lose track of what you did implement :p


Top
 Profile  
 
PostPosted: Sat Sep 09, 2017 6:53 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
So far I have regarded the PRG-NVRAM field always as a "size of the save file" field, and so does the Nintendulator main executable. Changing this definition to mean additional NVRAM would be a major change in that intuition, and would lead to MMC6, Mapper 80, 82 and several Mapper 19 games having the battery flag set with PRG-NVRAM value of "0", which even in the knowledge of its meaning bothers me greatly. It would also break compatibility with existing NES 2.0 emulator implementations that do assume that PRG-NVRAM also include internal RAM.

I'm opposed to excessive submapper use because you would be using the submapper to reflect something that the other fields are already supposed to reflect, but cannot because of the stupid decision (sorry for being blunt) to define the fields as powers of two. My proposal of using the previously reserved value 0xF as an "Other", with the mapper number providing the actual oddball size, would merely rectify that mistake for the rare cases where it's needed. It would keep compability with existing NES 2.0 emulator implementations for all games that do not use oddball sizes, because value 0xF has always been "special".

Sour is right in theory that one would have to use submappers anyway if there were more than one oddball size per mapper number. But in practice, there is no reason to believe that there is. So far, no unlicensed game is known that uses oddball NVRAM sizes at all, and only three mappers --- 19, 82 and 157, are known to use one oddball size per mapper number. And in the unlikely case that one turns up, we can go back to the submapper idea for those few cases after all.

Still yet another proposal could be to go for the 0xF value as "Other", but instead of then deducing the actual oddball size from the (sub)mapper number, one could define another header field to specify the exact size in some way. For example, PRG-NVRAM value 0xF could mean that the PRG-RAM value nibble no longer specifies the power-of two non-battery-backed RAM size, but one of sixteen pre-defined RAM-NVRAM-configurations having oddball sizes, e.g. 0x0:=8320 bytes NVRAM/0 RAM, 0x1:=5120 bytes NVRAM/0 RAM, 0x2:=384 bytes EEPROM, 0x3-0xF reserved for future use.

Let's see what the options proposed so far are (correct me if I misrepresent them):
  1. Include internal and external NVRAM in PRG-NVRAM field, always round up for oddball sizes. (Current NES 2.0 specification)
  2. Include internal NVRAM in PRG-NVRAM field only when there is no external NVRAM. Prevents oddball sizes resulting from the sum of internal and external NVRAM. Oddball sizes resulting from other reasons (Mapper 82) are still rounded up. (Lidnariq)
  3. Only include external NVRAM in PRG-NVRAM field. The mapper code itself has to know how many bytes of internal NVRAM to add. Will result in several headers with battery flag set and a PRG-NVRAM size of "0". If necessary, use submappers to denote if internal RAM is not battery backed but external RAM is. (Lidnariq, Sour)
  4. Include internal and external NVRAM in PRG-NVRAM field, use PRG-NVRAM value 0xF for oddball sizes whose actual value is derived from the mapper number, and should it be discovered that there are several oddball sizes for one mapper number, also from the submapper number. (NewRisingSun)
  5. Include internal and external NVRAM in PRG-NVRAM field, use PRG-NVRAM value 0xF for oddball sizes whose actual value is one of sixteen pre-defined configurations chosen by a repurposed PRG-RAM nibble. (NewRisingSun)


Top
 Profile  
 
PostPosted: Sat Sep 09, 2017 7:23 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19236
Location: NE Indiana, USA (NTSC)
NewRisingSun wrote:
Let's see what the options proposed so far are

Thank you for compiling them, so that one of us can take the list to kevtris in #nesdev for his thoughts.


Top
 Profile  
 
PostPosted: Sun Nov 05, 2017 6:26 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
Has kevtris given his thoughts in #nesdev within the past two months?


Top
 Profile  
 
PostPosted: Sun Nov 05, 2017 3:37 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19236
Location: NE Indiana, USA (NTSC)
You can add kevtris to proposal B, which I described to him as "Include mapper RAM in the count only if no dedicated RAM chip. This would mark the game as having 8192 bytes, to which the emulator adds 128 bytes because of mapper 19."


Top
 Profile  
 
PostPosted: Sun Nov 05, 2017 3:40 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
Thank-you for consulting him. :)


Top
 Profile  
 
PostPosted: Sun Nov 05, 2017 4:52 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 311
I am not comfortable making a decision about Mapper 19's NVRAM though until it is fully understood how the Save process in Dokuganryuu Masamune works, in particular, the role of the extra glob-top chip on the board. The Save procedure basically writes 126 bytes of data both to $4800 (the write address of the N163's wavetable RAM) and to $6000 (not indexed!) in the same loop. When selecting Continue, the 126 bytes are only read from $4800, not from $6000.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot], Google [Bot], tepples and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group