It is currently Wed Nov 14, 2018 1:06 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Fri Feb 09, 2018 6:43 pm 
Offline
User avatar

Joined: Wed Oct 16, 2013 7:55 am
Posts: 134
https://vigrey.com/blog/this-nes-rom-also-zip-file

Pretty interesting. Vi Grey takes advantage of zip files' loose header specification to make a ROM that contains itself. The ROM can be burned to a cart, ripped later on, renamed to a zip, and then unzipped to retrieve the same ROM.


Top
 Profile  
 
PostPosted: Fri Feb 09, 2018 9:24 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20766
Location: NE Indiana, USA (NTSC)
tl;dr: A zipfile contains the following elements in order.

  1. A prefix, ignored by unzippers, often used to hold a self-extract tool.
  2. The zipfile body, which consists of compressed data, a directory structure, and an "end of central directory" beginning with a 4-byte marker (50 4B 05 06).
  3. Comment data. Some sources claim that this should not exceed 48000 characters (source), and the unzipper may fail to find the zipfile body if comment data contain the marker for the end of central directory.

I can see two ways to fit an iNES or NES 2.0 ROM into a zipfile: one by putting the the zipfile body in PRG ROM, the other by putting it in CHR ROM.

Zipfile body in PRG ROM
The prefix contains the 16-byte header and the executable part of PRG ROM. The zipfile body pads out the rest of PRG ROM up to just below the vectors (for NROM) or the fixed bank (for UNROM). Mappers with 32K bank switching and unspecified power-up state, such as BNROM or AOROM, are not usable, as they may power up within the zipfile body. The featured article uses this technique with NROM.

Zipfile body in CHR ROM
The prefix contains the 16-byte header, the entire PRG ROM, and the used portion of CHR ROM, and the zipfile body sits in the rest of CHR ROM. This would most commonly use oversize CNROM or another mapper that allows CHR ROM 2 to 4 times as large as PRG ROM, as the source code in the zipfile body has to correspond to everything that comes before it.

If anything, it's an interesting way to "force" GPL compliance on ROM sites.

Depending on what we get in NESdev Compo 2017 category 2, it might be possible to apply this in part to Action 53 volume 4. Of the 32 outer banks (each 32768 bytes), the entries use 21, and the menu uses 1. This leaves 10 banks or 320 KiB. The menu source zipfile is 123 KiB (or just under 4 banks) without the "make your selection now" WAVE file, which I could make lossy in the ROM version of the source code. So if we don't get more than 192 KiB of category 2 or post-compo material, I could hide the source code for the menu (even if not the individual games) in this manner. That way anyone who dumps it with a Kazzo can make a multicart.


Top
 Profile  
 
PostPosted: Sat Feb 10, 2018 11:03 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7568
Location: Chexbres, VD, Switzerland
tepples wrote:
tl;dr: A zipfile contains the following elements in order.

  1. A prefix, ignored by unzippers, often used to hold a self-extract tool.
  2. The zipfile body, which consists of compressed data, a directory structure, and an "end of central directory" beginning with a 4-byte marker (50 4B 05 06).
  3. Comment data. Some sources claim that this should not exceed 48000 characters (source), and the unzipper may fail to find the zipfile body if comment data contain the marker for the end of central directory.

The data doesn't have to be compressed I think, compression while most often used is fully optional.

Also I'm fairly sure there is a directory arborescence at the end of the file, something most other archive formats lacks; which makes zip unique as is it allows random access to any file without decompressing other files.


Top
 Profile  
 
PostPosted: Sat Feb 10, 2018 5:25 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10966
Location: Rio de Janeiro - Brazil
If the ROM contains a zipped copy of itself, it absolutely has to use compression, otherwise it won't fit.


Top
 Profile  
 
PostPosted: Sat Feb 10, 2018 6:28 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20766
Location: NE Indiana, USA (NTSC)
The ROM contains a zipped copy of its source code. Part of the "compression" could merely involve the source code generating some humongous LUTs.


Top
 Profile  
 
PostPosted: Sun Feb 11, 2018 7:16 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4104
If you wanted a RAR or 7Z file, you could literally just append it onto the end of the NES file.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Sun Feb 11, 2018 3:04 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20766
Location: NE Indiana, USA (NTSC)
The idea is that even if you burn the ROM image onto a cartridge and someone else dumps the cartridge to a ROM image, she can still extract a valid zipfile. The append trick is practical only for mappers that support large CHR ROM, not for CHR RAM mappers or NROM. For CHR RAM mappers, you need somewhere to put the fixed bank, and for NROM, you need somewhere to put the vectors and CHR ROM. This trick puts them in the file comment.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group