unif ?

mattmatteh · Post by **mattmatteh** » Tue Mar 24, 2009 9:27 pm

didnt want to high jack the original thread, http://nesdev.com/bbs/viewtopic.php?t=4983

what is wrong with unif? i thought that was the new. i actually didnt have any intension of supporting ines either. i use it now, but intend on converting to unif.

i know there is ines2, but that is ontop of ines1. i agree there needs to be a fix to the older version, but take out the garbage, remove the old and start over. anyone that is going to use a newer format will likely have a newer emulator to use the newer format.

at the moment i am relying on correct ines header info for mappers, but as i add more and improve i will need correct header information. i do not intend on adding a game database, that is a job for utility. fix once.

( and for those that say no one will be able to use my emu without ines: there are plenty out there to choose from, and mine will be open source, feel free to change it)

matt

tokumaru · Post by **tokumaru** » Tue Mar 24, 2009 9:53 pm

I hate UNIF simply because they are not hex editor friendly. Joining and splitting ROMs is pretty straightforward with iNES, but a pain in the ass with UNIF. Games still work with iNES, right? I hardly think that emulating those crappy HK pirate games is worth the trouble of using UNIF. Really, that's all I've seen UNIF being used for.

koitsu · Post by **koitsu** » Wed Mar 25, 2009 12:33 am

No one here's going to be able to answer your question with 100% accuracy. Tennessee no longer participates in NES development, and he explicitly asked me to remove his website content (which was the official site for the UNIF documentation), citing its stupidity and how embarrassed he was about how he acted/behaved back then.

caitsith2 · Post by **caitsith2** » Wed Mar 25, 2009 2:21 am

Actually, it is possible, because it exists on the wayback machine. UNIF_current.txt was the very last official revision of that format. boardtable.txt and boardnames are also relevent to the format.

Agreed though, the format is a pita.

Bananmos · Post by **Bananmos** » Thu Mar 26, 2009 2:37 pm

Tennessee no longer participates in NES development, and he explicitly asked me to remove his website content (which was the official site for the UNIF documentation), citing its stupidity and how embarrassed he was about how he acted/behaved back then.

Heh, I could almost see that coming... :P

And on a more general scale, I would say that it sure would be tragic if a person did NOT feel embarrassed about how they behaved 10 years ago. Naturally, people evolve and re-consider their viewpoints.

In another 10 years he just might feel embarrassed that he ever felt the need to feel embarrassed over what kind of person he was 10 years earlier in his life. Or alternatively, he might just have a good laugh about it, the same way I believe most of us will when we remember how we once were.

My impression of him from back then is similar to the impression I usually get from highly talented people such as him: a really cool guy in some ways, and really silly in other ways. And come to think of it, that's the best judgment I myself could hope for. :)

When you talk to him next time, tell him I said hi and hope he's doing well!

crade · Post by **crade** » Tue Mar 31, 2009 10:55 am

Is it just me, or aren't there some games that run on the original hardware that have only been emulated using unif format due to limitations in the ines2?

tokumaru · Post by **tokumaru** » Tue Mar 31, 2009 4:12 pm

crade wrote:Is it just me, or aren't there some games that run on the original hardware that have only been emulated using unif format due to limitations in the ines2?

Maybe, but only Hong Kong pirate multi-cart crap, AFAIK. Anything could run with iNES though, you just have to create a new mapper if the board is too weird. Mapper numbers will run out eventually, of course.

BMF54123 · Post by **BMF54123** » Mon Apr 06, 2009 2:50 am

iNES can't account for different revisions of the same mapper (i.e. MMC3A, B, and C), or games that expect open bus where SRAM should be (Low G Man).

Jon · Post by **Jon** » Mon Apr 06, 2009 9:26 am

BMF54123 wrote:iNES can't account for different revisions of the same mapper (i.e. MMC3A, B, and C), or games that expect open bus where SRAM should be (Low G Man).

Fair enough, but do we have to use UNIF to solve this? I only bother with iNES with my tools and toys because it is simple.

mattmatteh · Post by **mattmatteh** » Mon Apr 06, 2009 10:52 am

There was alot of discussion about a new file format, ines2 was the result. I would prefer a new format from scratch. I havent looked at it and probably wont for a while. I will have to spend some time reviewing the forums.

I would like to see a file format that can be used without relying on a checksum database and use meaningful terms for hardware instead of mapper numbers.

matt

BMF54123 · Post by **BMF54123** » Mon Apr 06, 2009 12:30 pm

Jon wrote:
BMF54123 wrote:iNES can't account for different revisions of the same mapper (i.e. MMC3A, B, and C), or games that expect open bus where SRAM should be (Low G Man).
Fair enough, but do we have to use UNIF to solve this? I only bother with iNES with my tools and toys because it is simple.

Oh, I was by no means endorsing UNIF, just stating some of iNES's biggest limitations.

Post by **tepples** » Mon Apr 06, 2009 5:35 pm

Another proposal: iNES+JSON.

iNES compatible header (16 bytes)
optional PRG RAM preload pattern (512 bytes)
PRG ROM data (16384*p bytes)
CHR ROM data (8192*c bytes)
new header, in JSON format (??? bytes)

This preserves the IPS patchability and the compatibility with old emulators.

The new header might look like this:
{"board":"SNROM","prg-ram":8192,"prg-ram-battery":true}

Jon · Post by **Jon** » Mon Apr 06, 2009 6:10 pm

Is the goal to maintain backward compatibility with iNES? Because a couple of utilities don't seem to tolerate junk on the end (including ones I wrote).

I'm not sure I'd like to parse anything beyond trivial JSON inside one of those trivial nes-on-a-chip or cheap NES playing cellphones.

Is gif/png style tagged format such a terrible thing? 4 character codes with a length for each chunk seems pretty easy to me. for attributes like board, mapper, features, etc as long as everyone can agree on a fourCC you're gold.

anyone has any links to status/info/draft on an ines2?

Post by **tepples** » Mon Apr 06, 2009 7:13 pm

Jon wrote:I'm not sure I'd like to parse anything beyond trivial JSON inside one of those trivial nes-on-a-chip or cheap NES playing cellphones.

JSON parsers are twelve for ten bells. It's not like it's XML or anything.

Is gif/png style tagged format such a terrible thing?

ROM hackers wouldn't be able to distribute their hacks as binary patches unless you design and implement a new chunked diff format and diff/patch tools. But then I might be biased because I have a ROM hacker cousin who goes by Nova Yoshi.

MottZilla · Post by **MottZilla** » Mon Apr 06, 2009 7:32 pm

This came up before and I was asking about it. iNES has a few problems and you'll just have to add special cases like hash checks to determine settings for the few games that can't be described perfectly by iNES. It's not a huge deal really and there is no alternative and there may never be one.