Previous Thread
Next Thread
Print Thread
Page 6 of 6 1 2 3 4 5 6
Joined: May 2007
Posts: 1
M
Member
Offline
Member
M
Joined: May 2007
Posts: 1
You know. We also stopped using a.out about 8 years ago too smile. We have ELF now. God forbid file formats upgrade and improve over time.

Joined: Sep 2001
Posts: 192
P
Senior Member
Offline
Senior Member
P
Joined: Sep 2001
Posts: 192
Originally Posted By Heihachi_73

NES consoles don't break, they're not called a pee-ess-two. wink


I had 2 NES systems break, the cartridge reader part broke.

Hmmm, my PS2 is 2 years old, I'll bet it lasts longer than many XBOX360s!


-Emulation junkie since 1998...
-One of them "gamers" who plays games.
Joined: Jan 2005
Posts: 154
Senior Member
Offline
Senior Member
Joined: Jan 2005
Posts: 154
Regarding the central database idea, I have two (minor) objections. It would make an emulator more an "accessory to infringement", especially if the database is just commercial games. I'm also unclear on the motivation for dividing information for a given cartridge into two pieces that are stored separately. The main benefit I can imagine is that it allows easy repeated updating of the description of many cartridges at once, where storing the information individually in the cartridge files would require a batch of patches and application to each one every time. But why must this information be updated so often? Is it not possible to take a particular cartridge, dump it and examine the circuit board in full, then input a complete, correct description of it (in whatever format you want)? Or perhaps we want to be able to keep revising the database information, for example start out with just mapper names, then later add full hardware descriptions or something?

Quote:
You can't recreate a cartridge based on an iNES container

Even though an iNES file lacks scans of the circuit board, it still has sufficient information to make a cartridge. For example, the mapper number is a reference to a mapper description that's elsewhere (in an emulator's case, it's in the source code). Any description of a cartridge will have references to external material, no matter how detailed. There's no reason to describe the common aspects separately for each cartridge.

Joined: Mar 2001
Posts: 16,919
Likes: 57
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,919
Likes: 57
Well, yes, but iNES requires more reference to external material than most (is that mapper #119 varient #62 or #63?). And currently you have to get that material from the Anointed Priests of NESdev. That's really my goal with console emulation: make it so adults are in charge and nobody's lording anything over anyone else. Ville and Moogly did a wonderful job emptying an Uzi into the tires of N64 eliteness (with an unexpected assist from Ziggy), now it's other consoles' turns ;-)

Last edited by R. Belmont; 05/31/07 12:58 PM.
Joined: May 2007
Posts: 21
S
Member
Offline
Member
S
Joined: May 2007
Posts: 21
It would be hard and expensive to redump every rom, so for beginning the database would have to be filled with preliminary information taken from iNES headers. (I doubt all the betas and prototypes can be redumped, so this information would be unconfirmed).

A simple csv database would be easy to make, I guess.

Joined: Feb 2006
Posts: 13
G
Junior Member
Offline
Junior Member
G
Joined: Feb 2006
Posts: 13
Originally Posted By Marty
While this is an important subject and people are strongly opinionated around here, my personal main objective as an emulator author is foremost to know what the hell I'm supposed to emulate. A CNROM cart? A TKSROM cart? Or maybe a bootlegged multi-cart with "happy new year" labeled on the board? Obviously, NES cart information is absolutely necessary and where it should go is what's being debated here.

A database taking care of pure ROM files certainly has its uses. It keeps the implementation details away from the user and places the burden on someone else, i.e the db maintainers and emu authors. If something needs to be changed or updated, you do it once and in one place only. The one I personally maintain has surely been handy at times, especially as I can use it to store additional information about a cartridge which the iNES file doesn't have a clue about. Things like exact board used (SAROM/SJROM/SKROM/SXROM), chip revision (MMC1A/MMC1B2) and other things that helps bring up emulation accuracy.

However, as convenient for the user it may be, it's a hefty amount of work and not the most fun thing an emulator author can do - constantly having to keep track of new dumps and whatnot. The reason the database was put to use in the first place was so I could get around the limited design of the iNES file format and deal with some of the common widespread broken ROMs. I never really intended to have the database work as a full-fledged replacement for headered ROMs.

That being said, if an image shouldn't contain anything but pure ROM data it might as well be split into separate files so that PRG-ROM and CHR-ROM data can be distinguished. The full database proposal brings up a few interesting questions. Who will maintain it? What should go in there? Anything under the sun, including homebrews and hacks, or just games that was commercially released when the console was still being actively sold? Anything not in the database would be useless to an emulator since the emulator wouldn't know how to run it. Is that really ok?


Originally Posted By R. Belmont
Assuming the database thing went forward, here's how I'd answer:

As far as maintainers, the database itself should be GPL or a similar F/OSS license and maintained as a separate project.

What should go in there? I would suggest having separate databases for e.g. Japan official, US official, Europe official, Chinese hacks, homebrew, and so on. Bad dumps should never be added - that's my major beef with the Good* sets.

Is that OK? I'm guessing that anyone still creating NES homebrew is probably closely associated with NESdev and will be able to communicate their needs appropriately.

That all said, I prefer a more distributed approach.

You'd have separate PRG-ROM and CHR-ROM files in a zip (ideally separate per physical chip, but not strictly necessary) and a config file (ini or xml format) which would give the name of the board, the mapper chip details, and so on. IMO that would combine a lot of the advantages of the database and headered approaches.

- It's pretty easy for emulator authors, especially if the board descriptions are compatible with UNIF's
- Anyone can be the maintainer. Someone could pretty easily throw together a utility that used NEStopia's database file to split up current iNES ROMs into the "new" format
- Homebrew authors could easily write their own config file


I find these two comments to be of the most significance in this whole thread. So I'm going to give my opinion and my answer on these.

Some people are showing concern of loss of translation, hack, and home brew support if a new database is devised. This in my opinion is wholly illogical as just because we replace iNES does not mean the emulator must drop legacy support.

Included in each games 'set' I would not only include the split .PRG and .CHR file as well as the .XML file containing specific hardware and other useful information I would include an .NES file. The .NES file would be nothing more then a legacy iNES header and emulators that do not wish to conform to the new database would need only read the archive and combine the .NES .PRG and .CHR files in ram and run the ROM as if it was any common NES ROM found today. I find this to be a very simple and logical solution.

Such a database should only include official commercial games. Translations, Hacks, and home brew should only be supported with the above mentioned legacy iNES support. Should a user require the proper ROM to apply a translation's to a simple 'build iNES' option could be provided. You browse though your ROM list and find the game you need. Right click it or open a drop menu and along with other options such as 'play', 'audit', 'settings' you would find the 'build iNES' option.

the database itself should be treated very much like MAME. The emulator itself could also take a few hints from MAME. Instead of emulating different CPUs as drivers we treat the individual boards or mappers as drivers. I have really always felt the NES has much in common with arcade machine design rather then traditional game console design. Treating it as so seems logical to me.

Anyway these are just my opinions. I am no programmer or anything and my only real past experience with emulation advancement was a lot of work I put into NSRT (witch most people here including myself now hate) before that program fell to the dark side and started with the NSRT header BS and attempts to force the tool on people as well as the inclusion of fake ROMs in the database just to annoy the so called collectors. I used the early development of that program as a means of cleaning up a lot of the mess in SNES ROMs that was common at the time. Fixed a lot of interleave issues and tons of over dumps that have gone undetected for over a decade in some cases. SNES in my opinion is still a mess but it is a bit better. I'm kind of in the mood to see if I can do anything to help with NES now.

Joined: May 2007
Posts: 95
M
Member
Offline
Member
M
Joined: May 2007
Posts: 95
Instead of giving the task of converting to the older iNES format to the emulator, why not write a script to convert them? It can't be that hard.

Is the NES really so different from consoles of its era? Once again, I don't know the details, but it'd surprise me if the NES is the only one with various boards and expansions. Even the Super NES had different boards and expansions (did the Genesis? That console had the Sega CD and 32X to add capabilities, but I don't see any reason it can't be built-into the cart). By the 5th generation, Nintendo Power wrote that one reason the Nintendo 64 was better than the PlayStation was that cartridge-based systems could be expanded by extra hardware in the cart itself (though I can't think of any N64 game that actually did this, probably a contributing factor to Nintendo's choice of using DVDs in the next console (gameCube)); while that might also show some lack of foresight in Nintendo's engineering and marketting departments, it does show that such technology was so popular in the 3rd and 4th generations they felt it could last into the 5th. It's hard to believe that the NES had a unique feature. If you compare it to the 6th/7th generation consoles (5th gen too if you think of Saturn and PS1), sure, but you need to be fair and think in the cartridge-era of video games.

Joined: Mar 2001
Posts: 16,919
Likes: 57
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,919
Likes: 57
Yes, the NES *is* a unique case. No other console[1] had cartridges that 1) contained separate program and graphics ROMs 2) had over 150 unique kinds of cartridges. By contrast, there are maybe a dozen unique kinds of SNES carts, and half a dozen Genesis (Virtua Racing had a DSP to generate the polygons and thus it remains unemulated). By contrast, GBA and NDS carts are, with the exception of the 2 or 3 GBA tilt/rumble carts, differentiated only by save media type (none vs. EEPROM vs. battery SRAM vs. Flash) - the "mapper" is always exactly the same.

[1] The TI99-4/A computer also had "split" cartridges, but they weren't split by code vs. graphics and it wasn't a console.

Last edited by R. Belmont; 06/25/07 07:05 PM.
Page 6 of 6 1 2 3 4 5 6

Moderated by  Marty, R. Belmont 

Link Copied to Clipboard
Who's Online Now
2 members (Dorando, peter ferrie), 25 guests, and 9 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,100
Posts119,237
Members5,019
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com