It is currently Fri Nov 17, 2017 4:17 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Wed May 31, 2017 12:27 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3950
Should values of 255 for number of PRG/CHR pages be treated as the number 256?

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Wed May 31, 2017 1:12 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 946
No. If you're going to change your header logic, you might as well add NES2.0 byte9 support… in which case it's $FFF=$1000 instead of $FF=$100 that you'd be asking the question on.


Top
 Profile  
 
PostPosted: Wed May 31, 2017 1:32 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5821
Location: Canada
Dwedit wrote:
Should values of 255 for number of PRG/CHR pages be treated as the number 256?

Is there a ROM with a 4MB PRG / 2MB CHR that you are trying to accommodate? Is this something other emulators currently do?

Unless that's the case, I don't see why you should special case one value to not mean what it says. (...and iNES 2 is sufficient for new homebrew, if it should ever arise.)


Top
 Profile  
 
PostPosted: Wed May 31, 2017 5:28 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
I think it would be confusing as hell to give special treatment to a single value, while many others are just as useless. The proper way to handle PRG-ROM of sizes 4MB and up, as well as CHR-ROM of sizes 2MB and up, is the NES 2.0 format.


Top
 Profile  
 
PostPosted: Wed May 31, 2017 8:57 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5821
Location: Canada
tokumaru wrote:
The proper way to handle PRG-ROM of sizes 4MB and up, as well as CHR-ROM of sizes 2MB and up, is the NES 2.0 format.

Might also point out that in the new header format the "old" PRG byte will be 0, so if you're going to special case something to be 4 MB a value of 0 might make more sense than 255? (For PRG, at least.)

(Though I still don't understand its purpose unless an existing common ROM already uses it.)


Top
 Profile  
 
PostPosted: Wed May 31, 2017 10:26 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
rainwarrior wrote:
Might also point out that in the new header format the "old" PRG byte will be 0, so if you're going to special case something to be 4 MB a value of 0 might make more sense than 255? (For PRG, at least.)

Good point.

Quote:
(Though I still don't understand its purpose unless an existing common ROM already uses it.)

Yeah, still waiting for clarification on whether this is a suggestion for a new "feature" (in which case "absolutely no" would be my answer - if you're gonna add something to an emulator, better add NES 2.0 support than this hack) or if some existing ROM expects this to be the case.


Top
 Profile  
 
PostPosted: Thu Jun 01, 2017 9:44 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5821
Location: Canada
I do kind of agree with the sentiment that the spec is very wasteful, since there's only maybe 13 useful values in the 12-bit bitfield (or 9 in the 8-bit iNES 1 version).

It's also kind of hilarious that there is already a homebrew release that is 16k too large to fit in iNES 2:
http://www.retrousb.com/product_info.php?cPath=36&products_id=143

Feels like those 4 bits would have been better spent as a PRG * 2x multiplier instead of PRG * x. :P

In that respect, maybe not a 255 to 256 promotion since we do have a format that supports 4MB ROMs already, but what about 4095 to 4096 at the limit of the new format? Or you could add 4 more bits to the spec and wait for somebody to make the 1GB ROM that breaks it. :S


Top
 Profile  
 
PostPosted: Thu Jun 01, 2017 2:02 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7265
Location: Chexbres, VD, Switzerland
rainwarrior wrote:
Feels like those 4 bits would have been better spent as a PRG * 2x multiplier instead of PRG * x. :P

I agree, however it is still theoretically possible to combine different sized EPROMs get non-power-of-2 sizes on the NES, even if I don't think it was ever done. The only few Nintendo-made game that combines EPROMs combines two of the same size. On the SNES it was done frequently.


Top
 Profile  
 
PostPosted: Thu Jun 01, 2017 2:43 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5821
Location: Canada
Action 52 used 3 PRG ROMs. That's the only one I know of but there might be others. That's actually why I said 9 useful values instead of just 8.

Though, even that one is fine with theoretical power of 2 multiplier scheme I just proposed as a whim. The multiplier would just change the smallest representable multi-ROM unit from 16k to some other power of 2 size... you could still specify e.g. 113 * 1MB ROMs, for example, if that somehow wasn't insane. What's the downside? Overdumps if some very strange multi-ROM combination ever comes up? Is that even a real problem? We already have to do that for one 8k Famicom ROM. Any non-power-of-2 ROM size is going to be a custom mapper anyway to specify what happens to the "missing" address space (duplicate? open bus? used to control something else? ignored?), what does it matter if the ROM has slightly more data than necessary in it...? It'll just be zero fill that compresses to nothing anyway.

Anyhow, I'm not really proposing to change iNES 2, I'm just pointing out that it's already "not good enough" for one real homebrew, for basically the same reason OP started this thread. (How many existing ROMs are relying on the extended PRG size bits at this point anyway? Is it not too late to change? Would anyone want to?)


Top
 Profile  
 
PostPosted: Sun Aug 20, 2017 3:20 pm 
Offline

Joined: Wed Aug 16, 2017 12:15 am
Posts: 10
Location: Finland
A floating-point encoding would be very efficient here. With just six bits, PRG/CHR-ROM size (in bytes) could be encoded as 1.mm * 2eeee+13 (mm = mantissa bits, eeee = exponent bits), and we'd have the following options:

8 kB, 10 kB, 12 kB, 14 kB,
16 kB, 20 kB, 24 kB, 28 kB,
32 kB, 40 kB, 48 kB, 56 kB,
64 kB, 80 kB, 96 kB, 112 kB,
128 kB, 160 kB, 192 kB, 224 kB,
256 kB, 320 kB, 384 kB, 448 kB,
512 kB, 640 kB, 768 kB, 896 kB,
1 MB, 1.25 MB, 1.5 MB, 1.75 MB,
2 MB, 2.5 MB, 3 MB, 3.5 MB,
4 MB, 5 MB, 6 MB, 7 MB,
8 MB, 10 MB, 12 MB, 14 MB,
16 MB, 20 MB, 24 MB, 28 MB,
32 MB, 40 MB, 48 MB, 56 MB,
64 MB, 80 MB, 96 MB, 112 MB,
128 MB, 160 MB, 192 MB, 224 MB,
256 MB, 320 MB, 384 MB, 448 MB

[edit: of course there'd have to be a special code for no CHR-ROM]


Top
 Profile  
 
PostPosted: Mon Aug 21, 2017 1:08 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7265
Location: Chexbres, VD, Switzerland
qalle wrote:
[edit: of course there'd have to be a special code for no CHR-ROM]

And of course, it breaks compatibility with existing iNES headers, unless I've seriously mistaken something.


Top
 Profile  
 
PostPosted: Mon Aug 21, 2017 7:03 am 
Offline

Joined: Sat May 04, 2013 6:44 am
Posts: 22
Instead of re-interpreting bits that have already been defined, it would be easier to simply take advantage of the still-reserved bytes in the header. Bytes 14 and 15 are still undefined. If Byte 14's 8 bits were defined to be bits 13-20 of the PRG size field, then NES 2.0 would be able to specify 16 gigabytes of PRG. If we wanted to split byte 14 between PRG and CHR, then growing PRG's size field from 12 to 16 bits would still specify up to gigabyte of PRG.


Top
 Profile  
 
PostPosted: Mon Aug 21, 2017 8:13 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19221
Location: NE Indiana, USA (NTSC)
How likely are we to get multi-GB memories in a cartridge that aren't "seek and read a stream" memories like SPI, eMMC, or microSD flash? And a cartridge that does end up using seekable memory will still need a boot ROM. The other instances involving a boot ROM use two files, one for the boot ROM and one for the rest of the data.

  • Famicom Disk System: The menu is in one ROM file and the disk images are in other files.
  • PowerPak: The menu is in one file (whose source code is loader.asm here), the loadable modules are in other files (.map), and executables are in other files (.nes).

So I'd not be too hasty about defining a single-file format for these until we actually have an example. The first emulator for a game that uses seekable memory could use two files, just as emulators already do for FDS.


Top
 Profile  
 
PostPosted: Mon Aug 21, 2017 9:50 am 
Offline

Joined: Wed Aug 16, 2017 12:15 am
Posts: 10
Location: Finland
Bregalad wrote:
And of course, it breaks compatibility with existing iNES headers, unless I've seriously mistaken something.

Yeah, I was just thinking in hindsight how the size fields should've been implemented. I don't propose breaking the format.


Top
 Profile  
 
PostPosted: Wed Aug 23, 2017 8:54 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6437
Location: UK (temporarily)
tepples wrote:
How likely are we to get multi-GB memories in a cartridge that aren't "seek and read a stream" memories like SPI, eMMC, or microSD flash?
Never.

The largest parallel NOR flash ever manufactured is 2 Gibit (256 MiB).

Costs on these huge parallel NOR flash make them the ≈wrong choice for any modern design. There just isn't the demand for larger systems that use ROM and XIP instead of having a memory controller, so it's more economical to choose a microprocessor with the ability to boot from NAND flash and copy stuff on demand into RAM.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC - 7 hours


Who is online

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