It is currently Tue Nov 20, 2018 5:18 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 112 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8
Author Message
PostPosted: Sun Nov 04, 2018 4:19 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6961
Location: Canada
Emulators that haven't implemented that different meaning for $F aren't treating $F in a different way, they're not treating $F at all. It's simply an invalid size for a ROM, and no such ROM will ever exist. There is no conflict of meaning for it.


Top
 Profile  
 
PostPosted: Sun Nov 04, 2018 4:37 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20789
Location: NE Indiana, USA (NTSC)
The only practical sizes for PRG ROM or CHR ROM are 1, 3, and 5 times a power of 2.

  • 1 * 2k represents 1 ROM or 2 of equal size (e.g. After Burner CHR).
  • 3 * 2k represents 3 ROMs (e.g. Action 52 PRG) or 2 ROMs, the first twice as big as the second (many Super NES games).
  • 5 * 2k usually represents 2 ROMs, the first four times as big as the second (many Super NES games including Mega Man X and Street Fighter II Turbo).

A ROM size leading with $F is none of these.


Top
 Profile  
 
PostPosted: Sun Nov 04, 2018 4:55 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6961
Location: Canada
Also, hypothetically if there ever was a counterexample to this, for whatever insane reason, the only negative consequence is a small amount of padding (relative to the file size).

BTW the PowerPak ROM loader relies on only power of 2 sizes in these fields, because it constructs its bank bitmask as "size-1". That's actually a pretty reasonable implementation that will cover all but a small handful of ROMs which mostly couldn't run on the PowerPak anyway.


Top
 Profile  
 
PostPosted: Sun Nov 04, 2018 11:33 pm 
Offline

Joined: Mon Nov 11, 2013 2:55 pm
Posts: 40
Location: Minsk, Belarus
Guys, don't be so short-sighted. Nothing prevents anybody from creation of a custom cartridge with 64+8KiB of PRG ROM, for example. I provide this amount of ROM as an example because I considered creation of such a mapper for some special purposes just a few months ago.

And you argue with the least important point. The most important point is that it does not make any sense to imitate iNES header in this case. Introduction of such kludges have no any advantages over a completely new header format. Let's create a new proper header without these ugly hacks to cover situations which aren't covered by current NES 2.0 and can't be covered without breaking compatibility with old emulators.


Top
 Profile  
 
PostPosted: Sun Nov 04, 2018 11:39 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 696
You are not breaking compatibility with existing emulators: Along with the large ROM size must come a mapper that supports such large ROMs. An emulator not supporting the $F notation will also not support such mappers. When loading such a ROM, it will merely print "Mapper #342 not supported" and quit, not caring about the ROM size at all. A completely new NES header would instead produce a message such as "not a NES file" or "invalid file", which is much more confusing to the user. In the worst case, the old emulator compares the file size against the header ROM size before looking at the mapper number, and it would then complain about an unexpected end of file, which is no worse than getting "not a NES file".

Also, there already was a now-deprecrated iNES replacement that had DWORD size specifiers, called UNIF. One of the reasons for its deprecation was lack of popularity. That problem will be even greater here: nobody is going to support a new format just for a few large-size homebrew and pirate ROMs, but they might support an extension to an existing format plus one or two new mappers.


Top
 Profile  
 
PostPosted: Mon Nov 05, 2018 12:12 am 
Offline

Joined: Mon Nov 11, 2013 2:55 pm
Posts: 40
Location: Minsk, Belarus
Yeah, let's make the messy NES 2.0 header format even more messier. More kludges, more hacks, more ugliness. For the sake of chaos and increasing of entropy. :twisted:

Let's get back to the TV System byte, because it is the extension which would be really useful if added to the iNES, NES2.0 and UNIF formats.

Just a reminder of the proposition:
Code:
Byte 12 in NES 2.0 (or Byte 9 in iNES, or TVCI byte in UNIF):
7       0
---------
xdpn xxBP

The byte consists of two nibbles. The higher nibble describes which systems are supported, the lower nibble describes which system is preferred.

If higher nibble is 0, use legacy interpretation:
0000 0000 - NTSC only
0000 0001 - PAL only
0000 0010 - Supports NTSC and PAL, but NTSC is preferred
0000 0011 - Supports NTSC and PAL, but PAL is preferred

Otherwise, higher nibble describes supported systems:
d - Dendy
p - PAL
n - NTSC

Lower nibble (bits BP) describes preferred system:
00 - NTSC (a legacy emulator will use NTSC)
01 - PAL (a legacy emulator will use PAL)
10 - Dendy with fallback to NTSC (a legacy emulator will use NTSC)
11 - Dendy with fallback to PAL (a legacy emulator will use PAL), or just reserved

If the lower nibble chooses the system which is not marked as a supported system in the higher nibble, fallback to the legacy behavior. Bits 2,3 and 7 should be ignored by emulators, and should be 0 in ROMs.

Similar fields are already available in the NSFe format in the regn section. It would be nice to have the same ability in NES format also.

There is a list of supported systems by a ROM, and a preferred system selected in the ROM. A user of an emulator can choose a preferred system in the settings of the emulator: Auto, NTSC, PAL, Dendy, Force NTSC, Force PAL, Force Dendy. If Auto is specified, emulator will always use the preferred system specified in the ROM itself. If the user chooses NTSC/PAL/Dendy as preferred, the emulator checks if the preferred by user system is supported by the ROM, and if it is, it should use the preferred by user system. Otherwise, it should use preferred by ROM system. And if the user chooses to force NTSC/PAL/Dendy, the emulator just ignores the byte in the header and always uses the forced system.


I know that NewRisingSun don't like this proposal, he has an own one which extends the same byte in a different way. This comment is an invite for others to state their opinions about such an extension.


Last edited by VEG on Sat Nov 17, 2018 12:55 am, edited 4 times in total.

Top
 Profile  
 
PostPosted: Mon Nov 05, 2018 5:00 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6961
Location: Canada
VEG wrote:
Nothing prevents anybody from creation of a custom cartridge with 64+8KiB of PRG ROM, for example. I provide this amount of ROM as an example because I considered creation of such a mapper for some special purposes just a few months ago.

There are a lot of things preventing this. The primary thing is that it would be cheaper and easier to build a 128K cartridge than a 64+8 cartridge. You're making an argument based on a thing that is more or less absurd to make, and nobody is going to.

...and even if you DID build such a cart, you wouldn't need to use the extended bits anyway. It would just be listed as an 80k cartridge with the regular iNES 1 PRG size field, and there'd be 8k of padding. The point of the iNES 2 field (with or without the special $F proposal) is to extend the range of representable sizes, not accommodate pathologically hypothetical ROM sizes that fall in between the useful ones.

Quote:
Just a reminder of the proposition:

There is no need to duplicate that large block again here.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 112 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 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