nesdev.org

I think the right layout is either 64kB, iNES PRG*16=4, and the layout is $8000, $c000, blank, $4000, or 48kB, iNES PRG*16kB, and the layout is $4000, $8000, $c000.

A format that's neither "what's on the ROM" nor "what the CPU sees" makes no sense to me.

Just noticed that I messed up my post with proposed layout. I meant the '$8000, $c000, blank, $4000' layout, of course.

So, we have two options with pros and cons (as I see them):

64K $8000, $c000, blank, $4000

+ corresponds to the ROM, just cut header and burn it
- not straightforward from programmers point of view, that will create some trouble for romhackers

48K $4000, $8000, $c000.

- does not correspond to the ROM, a tool would be needed
+ straightforward

That makes choice difficult. Anyone have a major argument to consider that may make it easier? I only have a weak argument about empty space in the middle of the file, but I don't feel it important enough.

Doesn't the PowerPak not like uneven bank numbers as well? I know it likes things padded but IDK about uneven bank numbers. I realize the support isn't currently there, but when it is what would make more sense.

Now it can obviously be changed but it requires making a special case for this one mapper. For the NESDEV1 host software I assume that the ROM image must be powers of 2. Because in the past if you have a rom image that isn't power of 2, it's pretty safe to assume that your file is broke.

I realize it's a sore thumb and easy to recognize odd ROM sizes to flag you've got these weird mapper/ROM setups. As I see it is just as easy to recognize that a NROM mapper has more than 32KB and say "OH, this must be extented NROM." Same thing with CNROM and CPROM. It just seems like a mess to need these file types to require special operations out of tools that use them.

One other thing that complicates odd sizes is when someone tries to use a rom splitter or something to burn the image onto EPROMs. If this really does become popular IMO you'll make things confusing for novice trying to burn EPROMs.

As I see it the .nes file should be a dump of the ROM. Now it doesn't necessarily have to be in order, but it should be the entire ROM image.

infiniteneslives wrote:Because in the past if you have a rom image that isn't power of 2, it's pretty safe to assume that your file is broke.

Either broke or too big for the PowerPak's RAM. Action 52's PRG isn't a power of 2.

One could argue that action 52 IS BROKE.

Another minor thing to discuss is how to call extended NROM and CNROM. Should we still call it as normal NROM, like NROM-368, or make a new name to distinguish it easily? Like Extended NROM - ENROM (ECNROM), or maybe Super NROM (but there are SNROM and SROM already), or something else.

I think "Extended NROM" is fine, super also sounds like SNES. But if you want a combo of letters I'd stay away from things that start with E or S. They are too similar to MMC1 and MMC5 boards. Maybe something like NXROM, or NEROM?

For NROM, I'd go with NOROM to match the use of O for oversize in UOROM.

For what to call mapper 3 extended in this way, I'm not so sure. There are two ways to "oversize" that, one involving more than four banks of CHR ROM (implemented in Panesian games) and one like this.

NROM is the only series where there are multiple different letters meaning an equivalent board: SROM, HROM, RROM. Consequently, a board name like "EROM" or "XROM" might make sense.

All later boards were at least 5 characters (some more) and the first letter specified the class; SAROM, EWROM, &c: keeping with this would suggest a board name like NEROM or N4ROM.

NROM is also unique in that it's the only board series which specifies the size of PRG. NROM-128 and -256 would suggest -368. However, there is no such distinction between 16kB and 32kB PRG on CNROM, so if we want the same naming convention extension for both, this won't work. Which is unfortunate, because I like this choice best.

infiniteneslives wrote:I think "Extended NROM" is fine, super also sounds like SNES. But if you want a combo of letters I'd stay away from things that start with E or S. They are too similar to MMC1 and MMC5 boards. Maybe something like NXROM, or NEROM?

I'd like to help with this. If I understand it you're wanting emulator support for an iNES image that is mapper 0 with 32KB of appended ROM data. The 32KB appended is a repeat of the first 16KB ROM bank [which would otherwise be placed at $0], 2KB of pad bytes, and 14KB of extra ROM that is visible to the CPU at $4800.

I also understand Shiru is modifying another emulator...if you guys have what you need already I'll just add it so I can play whatever games he comes up with in my emulator!

We don't have everything that is needed yet. Still have to settle up on the iNES format for this extension. After this, an emulator would be needed to make a test code to test the design with a hardware prototype, then to create something that would be a reason for developers of other emulators and hardware to bother with adding support for the extension.

So, if you willing to help by adding support into your emulator, this would be great. Just wait until the format will be decided - this is a thing that is better to be well thought.

Shiru wrote:We don't have everything that is needed yet. Still have to settle up on the iNES format for this extension.

I vote:

64K $8000, $c000, blank, $4000

EDIT: and NROM-368

Shiru wrote:We don't have everything that is needed yet. Still have to settle up on the iNES format for this extension. After this, an emulator would be needed to make a test code to test the design with a hardware prototype, then to create something that would be a reason for developers of other emulators and hardware to bother with adding support for the extension.

If the iNES header of the NROM-368 file were to suggest that there were 3 16KB PRG banks wouldn't that be all that's necessary--for NROM.

lidnariq: I see nothing wrong with using NROM-368 for NROM to follow its convention and something else for CNROM -- CNOROM?

I just realized that's one letter short of MORONiC!

I think I'll just go add support for loading this extra bank and using it...then when the format is solidified I'll be ready with the back end done.

I don't get the $8000, $C000, blank, $4000 order.

Okay, this is the order you'll have to burn the data to the ROM.

HOWEVER, what really counts is what the CPU sees. I don't care at all how it's implemented in hardware, at least in iNES format.
If could be done with a single EPROM, a combination of 32k + 16k, or a combination of 16k + 16k + 16k, or something even more crazy - it's not my problem.

Therefore the only order who makes sense is $4000, $8000, $C000.
No blank bank or anything since we don't want a dump of a part that is hidden to the CPU anyways.

And if you need to re-arrange before burning due to your hardware implementation of this sheme, sorry but it's something different than the logical concept behind extending NROM.
As I already said you could do it as well with multiple EPROMs, then you would not need to reorder the data, but you'll need to split it apart. Again this is not the problem of the iNES ROM image.

PS : The "Super-NROM" name was originally my idea.
It was not intentional iit sounded like something related to the SuperNES.

Bregalad wrote: And if you need to re-arrange before burning due to your hardware implementation of this sheme, sorry but it's something different than the logical concept behind extending NROM.
As I already said you could do it as well with multiple EPROMs, then you would not need to reorder the data, but you'll need to split it apart. Again this is not the problem of the iNES ROM image.

PS : The "Super-NROM" name was originally my idea.
It was not intentional iit sounded like something related to the SuperNES.

I agree...emulation and burning are different realms.

This is also my vote for the $4000,$8000,$C000 iNES.