Page 1 of 1

file(1) magic(5) for iNES and UNIF ROMs

Posted: Sat Aug 11, 2012 2:06 pm
by lidnariq
If you use unix, you might use the file(1) command. You might, like me, want to be able to look at an rom image cursorally without having to manually decode the first 16 bytes of the .NES file. If so, you might like this. For NES2 roms, it produces output that looks like TetrisMMC3.nes: iNES2 ROM, Mapper 0x004, submapper 0, 0x002x16k PRG, 0x002x8k CHR, no PRGRAM, no CHRRAM, [NTSC], [Horz]

Copy or append it to /etc/magic or ~/.magic, depending on your version of file(1).

edit: Now that we have an attachment mechanism here, added to the forum instead; also changes in the syntax used by file(1) require a trivial change to the "default" directives.

Re: file(1) magic(5) for iNES ROMs

Posted: Sun Aug 12, 2012 3:10 pm
by zzo38
Can suppport also for NES 2.0, UNIF, DotFami, NSF, NSFe, and NSF2, be added?

Re: file(1) magic(5) for iNES ROMs

Posted: Sun Aug 12, 2012 6:36 pm
by Dwedit
I think the first post said that it already did NES 2.0 roms.

Re: file(1) magic(5) for iNES ROMs

Posted: Sun Aug 12, 2012 8:14 pm
by zzo38
Dwedit wrote:I think the first post said that it already did NES 2.0 roms.
Yes, you are correct, I just forgot about that at first but now I can see that you are correct. That still doesn't have to do with the other formats though.

Re: file(1) magic(5) for iNES ROMs

Posted: Sun Aug 12, 2012 9:19 pm
by lidnariq
Debian (and therefore Ubuntu) are already distributed supporting NSF parsing; I wasn't able / didn't try very hard to find a description for UNIF or the expansions to NSF.

I'll wait 'til you finish .FAMI before I look at supporting it.

Re: file(1) magic(5) for iNES ROMs

Posted: Sun Aug 12, 2012 10:36 pm
by zzo38
lidnariq wrote:Debian (and therefore Ubuntu) are already distributed supporting NSF parsing; I wasn't able / didn't try very hard to find a description for UNIF or the expansions to NSF.
OK.
I'll wait 'til you finish .FAMI before I look at supporting it.
OK.

Re: file(1) magic(5) for iNES and UNIF ROMs

Posted: Mon Aug 13, 2012 7:16 pm
by lidnariq
It turns out UNIF is even more obnoxious to implement using magic(5)'s syntax, but I've updated the archive (http://eamp.org/li/iNESmagic.zip) with two different implementations. Both have problems.

Because UNIF distributes its metadata all over the image, and file(1) only ever reads the first 100kB from disk, chances are semirandom as to whether you'll actually get any useful information out of any given UNIF image.

I initially tried going and using indirect math, but math made it impossible to calculate the location of a third tag in the file; additionally I'd have to encode tests for every permutation the tags can arrive in.

The first implementation (UNIF1.txt) uses magic(5)'s indirect command, which has the downside that it horribly pollutes the search space, and other files can be parsed as chunks of a UNIF file or vice versa.
It looks like: NES Color Bars Demo V2 by Quietust (PD) .unf: UNIFv7, [Vert], mapper:"NES-NROM-128", named:"Color Bars demo, version 2", [NTSC], 16384 B PRG, 8192 B CHR
The second implementation (UNIF2.txt) uses magic(5)'s search command, which doesn't follow the chunks and so can be tricked into parsing non-chunks as real data.
When all goes well it looks like NES Color Bars Demo V2 by Quietust (PD) .unf: UNIFv7, 16384 B PRG, 8192 B CHR, mapper:"NES-NROM-128", named:"Color Bars demo, version 2", [NTSC], [Vert]

Re: file(1) magic(5) for iNES ROMs

Posted: Mon Aug 20, 2012 6:38 am
by Jarhmander
I noticed on my Linux machine there's even file(1) support for iNES1 files, (shows mirroring PRG size and CHR size).
Your contribution is useful though because now it shows the MAPPER ;)

Thanks!

Re: file(1) magic(5) for iNES and UNIF ROMs

Posted: Tue Sep 26, 2017 8:24 pm
by lidnariq
I noticed that new versions of file(1) support naming headers, and invoking them at a specified offset into the file.

Which suddenly makes parsing chunked formats like UNIF headers really easy and robust! So here's my UNIF parser that uses these new-ish "name" and "use" commands. (It's almost identical to the previous version that used "indirect", but "indirect" just says "start over from scratch", and could match against things outside of our desired parse tree, as well as letting other things incorrectly match against internal headers)