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
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.
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.
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.
Quote:
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!
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?
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.
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).
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.
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
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.
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}
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?
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.
Quote:
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.
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.
Remember the reserved bytes in the iNES header?
Why can't we just use those for some of these details?
That's exactly what Kevtris did with the iNES 2.0 specification. For some reason it didn't quite reach the finish line.
Drag wrote:
Remember the reserved bytes in the iNES header?
Why can't we just use those for some of these details?
Those bytes are reserved for the string "DiskDude!" only. ;-)
The fact that that string appears in some files doesn't prevent those bytes from being used for other purposes, as long as that use doesn't ever result in the same string appearing, otherwise it would be ambiguous. I think the agreed-upon approach was more defensive: if the last byte or two of the header is non-zero, then the last 8 or so bytes must be ignored. Thus, for an iNES 2.0 file, the last few bytes would be zero.
tepples wrote:
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.
maybe in 32-bit C environments.
Quote:
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.
bsdiff works fine already, as long as you don't compress.
I happen to like hong kong pirate games
crade wrote:
I happen to like hong kong pirate games
I wouldn't say I like them, but I certainly find some of them interesting. I can't seem to play them for very long because more often than not the physics is totally broken. I do believe that most mapper problems are related to pirate
multicarts, which usually don't have anything interesting that hasn't been already released by itself (and is properly described by iNES).
Sort of still along this topic; I'm curious as to how the process to add a new mapper number currently works? For instance, how did the later ones get standardized / agreed upon and added to (most) emulators without having conflicts?
crade wrote:
Sort of still along this topic; I'm curious as to how the process to add a new mapper number currently works? For instance, how did the later ones get standardized / agreed upon and added to (most) emulators without having conflicts?
They didn't -- random Internet people just started assigning certain values to certain mappers. There was no centralised communication or agreed upon list. There's no RFC for the .NES file format. :-)
Thanks, I figured it was probably something like that