It is currently Fri Oct 20, 2017 10:11 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 25 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: iNES Advanced
PostPosted: Tue Dec 14, 2004 7:52 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
Having seen the various limitations of the iNES format, but not wishing to introduce a new format like UNIF that does not have the full support of the emulation community, I propose a hybrid format. It uses the 16 byte iNES header with only the control bytes 6 and 7 changed. Byte 6 is devoted solely to the memory controller hardware, essentially what the game uses. In some cases, that and the PRG and CHR bytes are all the programmer needs to emulate the game correctly. Note all games with no CHR rom have 8KB of CHR RAM unless the mapper dictates otherwise. In other cases, byte 7 can be used to determine a submapping system. Also, in my system, the mapper numbers make sense, observe:

00 - NROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
01 - Nintendo MMC1 (note 512KB of PRG ROM is SUROM)
0 - SLROM or SGROM (No Save RAM)
1 - SKROM or SNROM (8KB Save RAM)
2 - SJROM (8KB Work RAM)
3 - SOROM (8KB Save RAM + 8KB Work RAM)
4 - NES EVENT (Nintendo World Championships)
02 - Nintendo MMC2 (PNROM)
03 - Nintendo MMC3
0 - TLROM or TGROM (No Save RAM)
1 - TKROM or TNROM (8KB Save RAM)
2 - TSROM (8KB Work RAM)
3 - TQROM (8KB CHR-RAM + CHR-ROM)
4 - TVROM (4-Screen Mirroring)
5 - TLSROM
6 - NES-QJ ('161 submapper)
7 - Super Mario Bros. + Tetris + Nintendo World Cup mapper
04 - reserved*
05 - Nintendo MMC5
0 - ELROM (No Save RAM)
1 - EKROM (8KB Save RAM)
2 - ETROM (8KB Save RAM + 8KB Work RAM)
3 - EWROM (32KB Save RAM)
06 - Nintendo MMC6 (HKROM)
07 - AOROM
08 - BNROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
09 - CNROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
0A - CPROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
0B - GNROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
0C - UOROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
0D - Tengen RAMBO-1
0E - AVE Nina-001 (Impossible Mission II)
0 - Horizontal Mirroring
1 - Vertical Mirroring
0F - AVE Nina-06
0 - Horizontal Mirroring
1 - Vertical Mirroring
10 - Maxi-15
11 - Codemasters/Camerica BF9096 (Quattro)
0 - Horizontal Mirroring
1 - Vertical Mirroring
12 - Codemasters/Camerica BF9097 (Firehawk)
13 - Color Dreams/Wisdom Tree
0 - Horizontal Mirroring
1 - Vertical Mirroring
14 - Active Enterprises
15 - Caltron/Myriad 6-in-1
FE - Tengen 80042 (Afterburner)*
FF - JSROM* (Batman: Return of the Joker)*

Now, this system may be more properly be called iNES limited, as its sole purpose is to emulate released NES games. It has some flexibility and there is room for expansion. It only emulates what needs to be emulated. Why should mirroring be set on MMC carts when the MMC sets the mirroring? Why should W-RAM be emulated when it isn't present? Why should board hacks be emulated with another mapper instead of with a modification to the current mapper? Its not like the functionality is drastically changed. It alo ensures that emulators do not have to keep databases for games that require special hacks or the like. It also eliminates the superflous trainer bit in iNES. It also eliminates the split byte method of signifying a mapper. Importantly, it keeps both the 16-byte header, which is easy to deal with. It also keeps roms to their full size regardless of how empty the pages are.

This system makes very little provision for Famicom games. It is designed to emulate NES games, about which much is known. It does not delve into the murky world of Japanese Famicom games. However, there is room for expansion, as mapper $04 is reserved for what would be the Nintendo MMC4 in a comprehensive Famicom mapping system. Also, the last two mappers refer to Namco and Sunsoft hardware and would be better off placed in a proper squence. With these mappers you can emulate any commercial NES game in existence. An emulator can advertise that it fully supports each mapper to be considered complete.

Edit: Main Mappers should be in bold.


Last edited by Great Hierophant on Tue Dec 14, 2004 9:11 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 14, 2004 9:01 pm 
Offline
User avatar

Joined: Mon Sep 20, 2004 4:07 pm
Posts: 34
Location: South Dakota
I like this idea. iNES seems to work well enough, except for its redundant/lacking mapper descriptions, which this addresses nicely. Would the $1A at the beginning also be updated?

On the subject of rom formats, I always thought it would be a nice feature to keep battery-backed RAM within the rom file itself, so you don't have to copy .sav's from one emulator's folder to another. Am I the only one who would like this?

_________________
- abonetochew


Top
 Profile  
 
 Post subject: Re: iNES Advanced
PostPosted: Wed Dec 15, 2004 12:42 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
Great Hierophant wrote:
00 - NROM
0 - Horizontal Mirroring
1 - Vertical Mirroring
[...]
09 - CNROM
0 - Horizontal Mirroring
1 - Vertical Mirroring

Is this really necessary? Isn't an NROM just a CNROM with 8 KB of PRG?

Quote:
05 - Nintendo MMC5
0 - ELROM (No Save RAM)
1 - EKROM (8KB Save RAM)
2 - ETROM (8KB Save RAM + 8KB Work RAM)
3 - EWROM (32KB Save RAM)

That doesn't stand for "External Work ROM", does it? Or have I been playing around on gbadev.org too much?

Quote:
Why should mirroring be set on MMC carts when the MMC sets the mirroring?

Because some boards have solder pads for H, V, or mapper controlled.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 15, 2004 10:51 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
[quote]Is this really necessary? Isn't an NROM just a CNROM with 8 KB of PRG? [/quote]

Correct, it wouldn't affect emulation at all. An NROM board could use BNROM, CNROM, GNROM or UOROM and still work properly. I keep it separate here because I don't want to rock the ship too much.

[quote]
Because some boards have solder pads for H, V, or mapper controlled.[/quote]

As far as I know, with MMC carts, the only boards with solder pads for mirroring selection are TEROM and TFROM. If one of the nine games that use these boards has solder on the H or V pad, then I wil include it. Otherwise, there is no need for it.

By the way, the default mirroring on the NES is horizontal, isn't it?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 15, 2004 12:33 pm 
Offline

Joined: Mon Sep 20, 2004 11:13 am
Posts: 134
Location: Sweden
abonetochew wrote:
On the subject of rom formats, I always thought it would be a nice feature to keep battery-backed RAM within the rom file itself, so you don't have to copy .sav's from one emulator's folder to another. Am I the only one who would like this?


I've been thinking the exact same thing, cause that's how the real games work. If we're gonna make a new format (again) then lets include it! :)
But I'm not so sure about a re-implementation of mapper numbers. What's wrong with board names? :?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 15, 2004 2:30 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
Nessie wrote:
I've been thinking the exact same thing, cause that's how the real games work. If we're gonna make a new format (again) then lets include it! :)


Well, that would be a problem if (like me) you tend to keep stuff on CD-ROMs. Those ROMs really would be read-only. :)

I rarely had a problem between emulators, just having them all point to the same /SAV/ directory for saves (when it's allowed).

But it would make sense to allow that for emulating something like a Game Action Replay (though having pre-programmed SRAM seems like an abomination to me, heheh).


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 15, 2004 4:00 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
Great Hierophant wrote:
By the way, the default mirroring on the NES is horizontal, isn't it?

"Default mirroring" depends entirely on the mapper. Some mappers start out in horizontal on reset; others in vertical.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 15, 2004 4:02 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
Memblers wrote:
But it would make sense to allow [storing SRAM state in the ROM image] for emulating something like a Game Action Replay (though having pre-programmed SRAM seems like an abomination to me, heheh).

If an SRAM cart is an abomination, then the Famicom Disk System is just as much an abomination.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 15, 2004 5:33 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
tepples wrote:
If an SRAM cart is an abomination, then the Famicom Disk System is just as much an abomination.


Problem is when it's like the GAR and battery-backed, when the battery loses power the cart is dead (reset routine and everything is in RAM). Only a modified NES (like CopyNES) can make it work again.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 15, 2004 9:53 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
I agree with Memblers, appending SRAM to carts is not a good idea. Bad enough that some carts with f*cked-up mappers don't set the battery backed RAM bit correctly as it is. However, even then it wouldn't be as bad as the Famicom Disk System images, which embed their save information somewhere on the disk. Good luck getting a fresh copy of Metroid, Hikari Shinwa: Partuena no Kagami, Zelda no Densetsu or Castlevania.

The mapper numbers are just a substitute for the boards. Can anyone explain to me why BNROM is #34 and GNROM is #66? Why are there gaps? Why should pirate crap be assigned low numbers, rather than high numbers we can safely forget about? It just looks better. The original mapper numbers were assigned willy-nilly years ago by different people at different times with far less knowledge of the hardware than we have today.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 16, 2004 4:31 am 
Offline

Joined: Mon Sep 20, 2004 6:47 am
Posts: 48
the entire ines format is hacked together


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 16, 2004 8:51 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
I could piece together a better system alltogether that doesn't discriminate against Famicom carts... theres no reason why the NES scene should leave it out, such a thought is ludicrous!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 16, 2004 6:24 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
The only reason I can see the Famicom games are left out of unif is because noone has them all, and has been willing to open them all up to see what boards they use.

And every company has their own board types, it's not like NES where they (mostly) used Nintendo boards.

So we have roms that work on iNES format with emu hacks, but the info to convert them to a more descriptive format is missing.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 16, 2004 7:14 pm 
Offline
User avatar

Joined: Sat Dec 04, 2004 8:45 pm
Posts: 3
Location: somewhere between anima and animus
Right. It's not a problem with the UNIF format itself, but it's a problem with the lack of proper information in order to make them work with UNIF properly, instead of with ugly hacks to iNES.

As for this "iNES Advanced" format, I'm against it. UNIF is by far more semantically correct; from what I could gather, the main difference between iNES and iNES-A is that iNES-A assigns TWO arbitrarily-chosen numbers to a board, rather than just ONE.
Furthermore, do we really need a *third* format? We're having a hard enough time getting a *second* format accepted, let alone a *third* as well.
And seeing as iNES and iNES-A are mutually incompatible, we'd *still* have to wait for emulators to roll out support for the new format. Granted, it wouldn't be as difficult to update an iNES-only emulator to support iNES-A as it would be to make it support UNIF, but, they'd still have to update their mapper number databases and mapper emulation cores to accomodate it... just like with UNIF.
Two mappers numbers may be more accurate; but outright *naming the board* is dead-on accurate. If we're going to go through the trouble to get everyone's emulator upgraded to support a new format, why take only one or two steps in the right direction (with iNES-A) when we could be taking *ten* steps (with UNIF)?

With that said, I'll chime in on the issue of keeping SRAM inside the ROM itself: that might be feasable, but, if implemented, it should by no means be made mandatory: as someone mentioned, it won't work if the ROM is on a read-only medium (such as a CD-ROM); it also won't work- at least not very well- if the ROM is stored inside a compressed archive, e.g. a .zip file.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 17, 2004 7:33 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
We could expand the actual iNES format, rather than a new one. In fact, UNIF is by far the most accurate ROM image packaging, bringing everything that really matters in a comprehensive way. Let's avoid this "spinning" and go support UNIF without taking out the "grandpa" iNES format.

_________________
Zepper
RockNES developer


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

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