Talk:INES: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
m (→‎4-screen mirroring: should or must, am avoiding telling emu authors what they should have done, cause that doesn't help anyone know what they're going to run into)
(→‎4-screen mirroring: not quite impossible ;))
Line 21: Line 21:


:: Ah ok. This is super weird, such a behaviour would be almost impossible to pull out in real hardware.[[User:Bregalad|Bregalad]] ([[User talk:Bregalad|talk]]) 02:20, 13 January 2019 (MST)
:: Ah ok. This is super weird, such a behaviour would be almost impossible to pull out in real hardware.[[User:Bregalad|Bregalad]] ([[User talk:Bregalad|talk]]) 02:20, 13 January 2019 (MST)
::: As a curious aside, mappers [[NES 2.0 Mapper 356|356]] and [[NES 2.0 Mapper 512|512]] could do that if powered on in 4-screen mode. - [[User:Rainwarrior|Rainwarrior]] ([[User talk:Rainwarrior|talk]]) 12:35, 13 January 2019 (MST)


: How do you think this should be worded? The point I'm trying to be careful about is basically that there are only two ROMs that have ever put this bit to actual meaningful use (4, 206). The rest is "theoretical" because nobody's released a game or test ROMs to verify the hundreds of other mappers that could maybe apply it. Because of that I have very low confidence that "most emulators" will get a completely untested feature correct. Testing this would actually be quite a big research project though. I am trying to keep this describing what exists, and not making it into a rule of "emulator authors should/must do it this way" that might not match reality and give people the expectation that they can safely use such an untested feature. Can you help write an alternative/better way to express this? I'll switch the wording to say "largely untested" for starters, but I'm sure it could be said better. - [[User:Rainwarrior|Rainwarrior]] ([[User talk:Rainwarrior|talk]]) 12:28, 13 January 2019 (MST)
: How do you think this should be worded? The point I'm trying to be careful about is basically that there are only two ROMs that have ever put this bit to actual meaningful use (4, 206). The rest is "theoretical" because nobody's released a game or test ROMs to verify the hundreds of other mappers that could maybe apply it. Because of that I have very low confidence that "most emulators" will get a completely untested feature correct. Testing this would actually be quite a big research project though. I am trying to keep this describing what exists, and not making it into a rule of "emulator authors should/must do it this way" that might not match reality and give people the expectation that they can safely use such an untested feature. Can you help write an alternative/better way to express this? I'll switch the wording to say "largely untested" for starters, but I'm sure it could be said better. - [[User:Rainwarrior|Rainwarrior]] ([[User talk:Rainwarrior|talk]]) 12:28, 13 January 2019 (MST)

Revision as of 19:35, 13 January 2019

How does a PlayChoice hint screen work? --Zzo38 19:08, 21 September 2012 (MDT)

Last 4

Should this be "if the last 5 bytes are not all zero"? "A general rule of thumb: if the last 4 bytes are not all zero, and the header is not marked for NES 2.0 format, an emulator should either mask off the upper 4 bits of the mapper number or simply refuse to load the ROM." -Ulfalizer (talk) 03:45, 14 July 2013 (MDT)

When I wrote 4 as the rule of thumb, I didn't know how many not-widely-adopted extensions to original iNES were floating around, and I guessed that one or more might have used byte 11 for something, but all of the ROMs I saw with DiskDude and similar tags had at least something in the last four bytes of the header. --Tepples (talk) 07:48, 14 July 2013 (MDT)
Makes sense. Just wanted to check whether it was a typo. -Ulfalizer (talk) 09:06, 14 July 2013 (MDT)
Nestopia checks the last 6, and clears/ignores the last 9. (It also actually does pay attention to bytes 8 and 9)—Lidnariq (talk) 11:21, 14 July 2013 (MDT)
If the header contains "DiskDude!" or one of those other things (I forget now, but I knew at one time and figured this out), then bit2 of flags 7 will be set; otherwise bit2 and bit3 should both be cleared. This may be another way. --Zzo38 (talk) 19:51, 20 August 2013 (MDT)

4-screen mirroring

Reference needed I'm afraid.

"Theoretically bit 3 could be used for most mappers that had hard-wired mirroring to transparently provide 4KB of VRAM for 4-screen instead. However, many emulators will ignore this bit except for mappers with prior 4-screen variations."

I'm fairly confident most emulators will happily gives you 4-screen mirroring when asked for it, even if they are in mappers where such a possibility wasn't used. I remember at some point considering using 4-screen mirroring with CNROM and it worked well. Bregalad (talk) 01:55, 13 January 2019 (MST)

In my limited experience, most emulators will let you start with 4-screen layout, but if the mapper has a mirroring control register, using it will irrevocably remove the extra nametables. For example, this is what goes wrong when trying to run Vs. Goonies on FCEUX as mapper 75 instead of mapper 151. —Lidnariq (talk) 02:13, 13 January 2019 (MST)
Ah ok. This is super weird, such a behaviour would be almost impossible to pull out in real hardware.Bregalad (talk) 02:20, 13 January 2019 (MST)
As a curious aside, mappers 356 and 512 could do that if powered on in 4-screen mode. - Rainwarrior (talk) 12:35, 13 January 2019 (MST)
How do you think this should be worded? The point I'm trying to be careful about is basically that there are only two ROMs that have ever put this bit to actual meaningful use (4, 206). The rest is "theoretical" because nobody's released a game or test ROMs to verify the hundreds of other mappers that could maybe apply it. Because of that I have very low confidence that "most emulators" will get a completely untested feature correct. Testing this would actually be quite a big research project though. I am trying to keep this describing what exists, and not making it into a rule of "emulator authors should/must do it this way" that might not match reality and give people the expectation that they can safely use such an untested feature. Can you help write an alternative/better way to express this? I'll switch the wording to say "largely untested" for starters, but I'm sure it could be said better. - Rainwarrior (talk) 12:28, 13 January 2019 (MST)