It is currently Tue Dec 18, 2018 7:01 am

All times are UTC - 7 hours





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

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7026
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: 20896
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: 7026
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: 47
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: 709
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: 47
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: 7026
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  
 
PostPosted: Wed Nov 21, 2018 10:47 am 
Offline
User avatar

Joined: Sat Apr 18, 2009 4:36 am
Posts: 281
Location: Russia (UTC+3)
I think than VEG's proposal is better.
The same data (list of supported and a preferred system) is already available in the NSFe format.
So, it will be a feature parity between at least NSFe and NES 2.0


Top
 Profile  
 
PostPosted: Wed Nov 21, 2018 1:18 pm 
Offline

Joined: Mon Nov 11, 2013 2:55 pm
Posts: 47
Location: Minsk, Belarus
I have created a dedicated topic about it, with some additional details: viewtopic.php?f=3&t=18060
I hope that it will help to involve other people into the discussion.


Top
 Profile  
 
PostPosted: Wed Nov 21, 2018 3:01 pm 
Offline

Joined: Mon Nov 11, 2013 2:55 pm
Posts: 47
Location: Minsk, Belarus
NewRisingSun wrote:
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.
First of all, UNIF is supported by popular emulators. And I see no any reasons to remove its support. Second, it is not a mere header, it is much more complex. This format is an overkill for most cases, that's why it is not wide adopted. But it is used on special cases. For example, COOLGIRL multicarts use it, and UNIF really suits better this rare case.


Top
 Profile  
 
PostPosted: Thu Dec 06, 2018 3:09 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 713
Regarding the exponent * multiplier way of determining ROM size, I think this is how it works :

Galaxian 8KB PRG-ROM = 2^13 * 1 = #00110100 = $34

Here are some non-power of 2 PRG-ROM sizes I know of that can be represented by this system :

Vs. Tetris 24 = 2^13 * 3
Vs. Gumshoe 40 = 2^13 * 5
Vs. Raid on Bungeling Bay 40 = 2^13 * 5
Vs. Mahjong 48 = 2^14 * 3
Pegasus 5 in 1 1280 = 2^18 * 5
Action 52 1536 = 2^19 * 3
I can't get it to work for these PRG-ROM sizes, but fortunately they are encompassed within a single submapper :

Nantettatte!! Baseball Ko-Game Set '91 Kaimakuban 144
Nantettatte!! Baseball OB All Star Hen 144

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Last edited by Great Hierophant on Fri Dec 07, 2018 3:55 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Thu Dec 06, 2018 3:19 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
For 144 KiB, you just denote 9 16 KiB banks. The exponent-multiplier system is only used for sizes that could not be expressed before.


Top
 Profile  
 
PostPosted: Thu Dec 06, 2018 5:20 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 713
NewRisingSun wrote:
For 144 KiB, you just denote 9 16 KiB banks. The exponent-multiplier system is only used for sizes that could not be expressed before.


I was trying to get the number using the exponent-multiplier system, but it only went up to seven. I forgot that original system is 16K * 2^(Byte 4).

I am pleased we can finally express Galaxian's 8KB in an understandable format. Now everyone just needs to shut up and embrace the future of NES ROM identification 8-)

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Thu Dec 06, 2018 5:39 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
In hindsight, having the table be {1,3,5,9} would make more sense than {1,3,5,7} — you can only get 7 by having three ROMs — but I really don't care enough to do anything more than point this out.


Top
 Profile  
 
PostPosted: Thu Dec 06, 2018 10:37 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
How I love it when people care enough to post how much they don't care. :P

Great Hierophant wrote:
I forgot that original system is 16K * 2^(Byte 4).
No, the original iNES system is just 16K *(Byte 4), and with NES 2.0, 16K * (Byte 4 OR ((Byte 9 AND $0F) SHL 8)).


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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