UNIF database?

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

So as far as the database is concerned, one should only need to be given the options Horizontal, Vertical, and "Board Implied".

As for how the database handles ROMs, the way it is setup right now, each entry has a sub-table for each ROM contained on the board. The sub-table has the following items:
  • Name (eg. "HVC-EB-0 PRG")
    Size
    CRC32
    Type
The "type" item is a string which tells what the ROM is.
A typical entry would have 2 of these sub-tables, with types "PRG0" and "CHR0" or just "PRG0" in the cases where the board has VRAM instead.

The problem is though, what do you do when you have odd ROMs that don't fit into those categories. Specifically I'm thinking about PC10/VS boards where you run into palette ROMs and those PC10 menu ROMs. Do you set up more predefined types or should the type field be totally user-defined?[/list]
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust »

VS boards do not have "palette ROMs" that can be easily read - they have varying revisions of the RP2C0x PPU chip with different on-die palette tables.

However, Kevin Horton (aka kevtris) has a "3-in-1" board which he designed to read the palette out of a PC10/VS Unisystem PPU through an ADC (as well as monitor the PPU data/address bus and monitor the 'chatter' between two CIC chips), so if you have any VS PPUs he doesn't have, let him know so he can have them 'dumped'.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

Ok another interesting situation I've run into. What would be the best way to handle a game that uses multiple boards but the same data on the ROMs? I haven't even opened many games, and i've already run into this twice. TMNT and Metal Gear. These are a couple games I happen to have multiple copies off where this has occured.

Taking TMNT for example: One of them has the board NES-SLROM-05 and one of them has a board with just the number 351908 on it. The latter also has an LS7432 onboard, whereas the SLROM does not. Also the SLROM has a 32-pin VRAM chip and the other has a 28-pin chip.

This doesn't really pose a problem for the db at all, I'm just wondering what the best way to handle it for example when a user tries to convert to UNIF. Do you give them a choice of available boards or just automatically pick one? I'm sure functionally of the boards is the same, so it's probably not a big deal. Just figured I'd check :)
Great Hierophant
Posts: 780
Joined: Tue Nov 23, 2004 9:35 pm

Post by Great Hierophant »

Ok another interesting situation I've run into. What would be the best way to handle a game that uses multiple boards but the same data on the ROMs? I haven't even opened many games, and i've already run into this twice. TMNT and Metal Gear. These are a couple games I happen to have multiple copies off where this has occured.

Taking TMNT for example: One of them has the board NES-SLROM-05 and one of them has a board with just the number 351908 on it. The latter also has an LS7432 onboard, whereas the SLROM does not. Also the SLROM has a 32-pin VRAM chip and the other has a 28-pin chip.

This doesn't really pose a problem for the db at all, I'm just wondering what the best way to handle it for example when a user tries to convert to UNIF. Do you give them a choice of available boards or just automatically pick one? I'm sure functionally of the boards is the same, so it's probably not a big deal. Just figured I'd check
First of all, its VROM, not VRAM. Nintendo had some odd 28-pin 128x8 kilobit ROMs floating about and used the above configurations to use them instead of the more common 32-pin 128x8 kilobit ROMs. The TMNT boards are functionally identical, at least to the NES. Always pick the Nintendo board, no need to clutter up UNIF with weird, unnecessary board types.
Guest

Post by Guest »

I disagree, the entire point of UNIF is to *accurately* describe the game that it's a binary representation of.

If you're worried about emulators, then you can do a number of things:
1) Use the 'common' board-type as the UNIF board name, and include in a seperate chunk the true board type (not my preference, but works instantly with current UNIF emulators) or
2) Do it the other way around, listing the true board name in the board name field, which is WHAT IT IS THERE FOR, and have a seperate 'compatible-with' chunk, which would list acceptable board name substitutions.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper »

Hey guest... Calm down about the 'emulators'. Even if you forget them, the NES cannot read UNIF. ^_^;; The storage purpose is to give the binary data information (like you said), but emulation is not prohibited and not something that doesn't matter after all. Well, that's what I think about it. It's a nice format.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Fx3 wrote:Calm down about the 'emulators'. Even if you forget them, the NES cannot read UNIF. ^_^;;
Some people are under the impression that should we ever get a Star Trek style matter replicator, you should be able to give the replicator a UNIF file and get a mint-condition Game Pak out.
Guest

Post by Guest »

I have no problem with things being easy to implement for emulators, but I don't see why having extra information lying around is going to hurt anything, and it may help in the future. UNIF isn't just for making emulator authors lives easier, it isn't for making ROM whores lives easier, and it's not just for perfectly preserving everything about a ROM. It's a little bit of all of them, and it lacks something for all of them too. At least it's not iNES, and I think we can all agree that is a good thing.

Combining boards that are either totally identical, or differ only by preventing bus conflicts or inverting ROM select signals for different pinout ROMs is one thing, and I don't mind so much about that (although it would still be nice to list the different board types that this particular CRC of PRG came from, etc...)

However, some people have proposed things like getting rid of any notion of NROM and storing them as CNROM or GNROM or whatever. That's both incorrect, and saving space for no reason (i.e. just silly). Having one extra type doesn't hurt anything, and what about some odd/rare/badly written NROM game that writes to $8000+? The correct behavior is to ignore it, and you'd know that if you had it marked as NROM, rather than latching some bits for no reason (granted, the bits should do nothing if the emulator properly pages only the amount of memory indicated by the file info).
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch »

I agree 100% with 'Guest'.

What's the point of keeping an exact format if we're not going to keep it exact. If we start omitting differences that (in the present) we feel are unimportant, we'll be repeatnig the whole iNES fiasco all over again.

Plus things can change. Despite the differences we see between MMC3 and MMC6 now, back in the day they didn't feel it important to distinguish between the two. Are you really suggesting we take that same road? That'll just cause more problems down the line.
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

Great Hierophant wrote: First of all, its VROM, not VRAM. Nintendo had some odd 28-pin 128x8 kilobit ROMs floating about and used the above configurations to use them instead of the more common 32-pin 128x8 kilobit ROMs. The TMNT boards are functionally identical, at least to the NES. Always pick the Nintendo board, no need to clutter up UNIF with weird, unnecessary board types.
First of all, excuse the typo :) About the number of pins, I was under the impression the PRG ROMs could have up to 128KB in a 28-pin chip whereas the CHR ROM could only have up to 64KB with a 28-pin due to the way it's generally wired. I suppose the board just wires it different than normal, I didn't look too close. Anyways back on topic, I also agree with 'Guest' about the board names and I intended to have the DB take both without hassle. I was more wondering about how deal with it on the other side, when a user (or emulator) is dealing with it.
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

A little status update on the project for anyone that may care :P

I haven't had a ton of time to work on it, but it's coming along pretty good regardless. Most of the major functionality is done. It's down to mostly little things/polishing now. Some of the main things that still need to be done:

-Add UNIF read/write support. ATM, it only reads iNES files.

-Database file download. This feature will create a local copy of the DB, containing whatever data you specify. I'll keep the file format simple so it's easy for other programs to use.

-I still have to do the whole user registration/permissions junk.

-It doesn't really have proper support for PC10/VS systems yet, as in there are no means to add info about extra things like dip switches.

If I have time later tonight, I'll post the database table details. I think it's good where it's at, but I'd like some opinions on it.
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

Well I finally got some time today to work on this and it's pretty much ready to go now. Still have plenty to do with it, but all the important stuff is done. Tonight hopefully I can go online with it and get some testing done. I still have a ton of entries to add, but I wont let that hold it back.

There is one thing however I'm unsure how to go about regarding board names. As it is now, your supposed to enter the entire board name as it appears. Most US boards have a common name plus a revision number. So when it comes to saving it to UNIF, it looks for a revision number and drops it. That's fine and all, but then there is everything else. For unlicensed games it will prepend "UNL-" to whatever was entered. For pirates/multi-carts I really have no idea, because it seems most do not even have board names and are just made up.

So I'm thinking I need to add an additional item for "UNIF board name" along with the real board name. Even for licensed games this may be necessary. Example, I have 2 Pinball carts. One is a normal NES-NROM-128-04 board. The other is the japanese glob-top board HVC-PN with a NES-JOINT CIC pass-thru thing. But if you were to use "HVC-PN" for the UNIF file, I don't think there is an emulator out there that will accept it.

One more thing, are there not any emulators out there that support Tengen,Color Dreams,AVE,Camerica,etc in UNIF form?
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Nes Cart DB - Beta available for testing

Post by BootGod »

Ok I finally got time to do some online testing for this thing with a friend and it seems to be good enough for a public beta. It still lacks some features like a downloadable DB, but that isn't neccessary at this time.

You will need Win2k or WinXP to run this. It hasn't been tested on 2K but it should work. It requires unicode support as well. My friend wasn't able to get unicode chars to display properly, I'm not really sure why, as his browser was able to display them.

And of course to be useful you will need to have some NES carts and the means to open them. I've got about 80 entries in so far, only about 120 to go :shock:

Go here for the download. There is a separate download for a couple dll's you may or may not need. See the readme for more info
Post Reply